Risoluzione degli errori di risposta

Questa pagina descrive come risolvere i problemi relativi agli errori ricevuti in una risposta da una richiesta alla tua API.

BAD_GATEWAY

Se ricevi il codice di errore 13 e il messaggio BAD_GATEWAY, significa che che Extensible Service Proxy (ESP) non sia in grado di raggiungere il backend del servizio. Verifica quanto segue:

  • Assicurati che il servizio di backend sia in esecuzione. Il modo in cui puoi farlo dipende e il backend.

  • È stata specificata la porta dell'indirizzo IP corretto del servizio di backend:
    • Per GKE, controlla il valore del flag ESP --backend (l'opzione breve è -a) nel file manifest di deployment (spesso chiamato deployment.yaml).
    • Per Compute Engine, controlla il valore del flag ESP --backend (l'opzione breve è -a) nel comando docker run.

reset reason: connection failure

Se ricevi il codice HTTP 503 o il codice gRPC 14 e il messaggio upstream connect error or disconnect/reset before headers. reset reason: connection failure, significa che ESPv2 non riesce a raggiungere il backend del servizio.

Per risolvere il problema, controlla gli elementi riportati di seguito.

Indirizzo backend

ESPv2 deve essere configurato con l'indirizzo del backend corretto. I problemi più comuni includono:

  • Lo schema dell'indirizzo di backend deve corrispondere al tipo di applicazione di backend. I backend OpenAPI devono essere http:// e i backend gRPC grpc://.
  • Per ESPv2 di cui è stato eseguito il deployment su Cloud Run, lo schema dell'indirizzo del backend deve essere https:// o grpcs://. s indica a ESPv2 di configurare TLS con il backend.

Ricerca DNS

Per impostazione predefinita, ESPv2 tenta di risolvere i nomi di dominio in indirizzi IPv6. Se la risoluzione IPv6 non va a buon fine, ESPv2 torna agli indirizzi IPv4.

Per alcune emittenti, il meccanismo di riserva potrebbe non funzionare come previsto. In alternativa, puoi forzare ESPv2 a utilizzare indirizzi IPv4 tramite il flag --backend_dns_lookup_family.

Questo errore è comune se configuri un connettore VPC serverless per ESPv2 di cui è stato eseguito il deployment su Cloud Run. I VPC non supportano il traffico IPv6.

API is not enabled for the project

Se hai inviato una chiave API nella richiesta, viene visualizzato un messaggio di errore simile a "API my-api.endpoints.example-project-12345.cloud.goog non è abilitato per progetto" indica che la chiave API è stata creata in un altro ambiente Google Cloud rispetto all'API. Per risolvere il problema, puoi creare la chiave API nello stesso progetto Google Cloud a cui è associata l'API oppure attivare l'API nel progetto Google Cloud in cui è stata creata la chiave API.

Service control request failed with HTTP response code 403

Se ricevi il codice di errore 14 e il messaggio Service control request failed with HTTP response code 403, significa che l'API Service Control (servicecontrol.googleapis.com) non è abilitato sul progetto.

  1. Consulta la sezione Controllo dei servizi richiesti per assicurarti che nel progetto siano abilitati tutti i servizi richiesti da Endpoints ed ESP.

  2. Consulta la sezione Controllo delle autorizzazioni richieste per assicurarti che tutte le autorizzazioni richieste siano presenti nell'account di servizio associato all'istanza in cui è in esecuzione ESP.

Method doesn't allow unregistered callers

ESP risponde con l'errore, Method doesn't allow unregistered callers, quando hai specificato una chiave API nella sezione security del documento OpenAPI, ma la richiesta all'API non ha una chiave API assegnata a un parametro di query denominato key.

Se devi generare una chiave API per effettuare chiamate alla tua API, consulta Creare una chiave API.

Method does not exist

La risposta, Method does not exist, indica che il metodo HTTP (GET, POST o altro) nel percorso dell'URL specificato non trovato. Per risolvere i problemi, confronta la configurazione del servizio che hai disegnato per assicurarti che il nome del metodo e il percorso dell'URL che invii nella richiesta corrispondano:

  1. Nella console Google Cloud, vai alla pagina Servizi endpoint per del tuo progetto.

    Vai alla pagina Servizi endpoint

  2. Se hai più di un'API, seleziona quella a cui hai inviato la richiesta.

  3. Fai clic sulla scheda Cronologia deployment.

  4. Seleziona il deployment più recente per visualizzare la configurazione del servizio.

Se non vedi il metodo che stai chiamando specificato nella sezione paths del documento OpenAPI, aggiungi il metodo oppure aggiungi x-google-allow a livello superiore del file:

x-google-allow: all

Questo flag significa che puoi evitare di elencare tutti i metodi supportati nel tuo backend nel documento OpenAPI. Quando viene usato all, tutte le chiamate, con o senza un Chiave API o autenticazione dell'utente: passa attraverso ESP al tuo tramite Google Cloud CLI o tramite l'API Compute Engine. Per maggiori informazioni, visita la pagina x-google-allow.

Errori specifici dell'ambiente flessibile di App Engine

Questa sezione descrive le risposte agli errori delle API di cui è stato eseguito il deployment sul nell'ambiente flessibile di App Engine.

Codice di errore 502 o 503

App Engine potrebbe richiedere alcuni minuti per rispondere correttamente alle richieste. Se invii una richiesta e ricevi un server HTTP 502, 503 o un altro server Errore, attendi un minuto e riprova a eseguire la richiesta.

Messaggio di errore BAD_GATEWAY

Un codice di errore 502 con BAD_GATEWAY nel messaggio indica solitamente che App Engine ha terminato l'applicazione perché ha esaurito la memoria. La VM flessibile App Engine predefinita ha solo 1 GB di memoria, con solo 600 MB disponibili per il contenitore dell'applicazione.

Per risolvere il problema correlato al codice di errore 502:

  1. Nella console Google Cloud, vai alla pagina Logging:

    Vai alla pagina Esplora log

  2. Seleziona il progetto Google Cloud applicabile nella parte superiore della pagina.

  3. Seleziona Applicazione Google App Engine e apri vm.syslog.

  4. Cerca una voce di log simile alla seguente:

    kernel: [  133.706951] Out of memory: Kill process 4490 (java) score 878 or sacrifice child
kernel: [  133.714468] Killed process 4306 (java) total-vm:5332376kB, anon-rss:2712108kB, file-rss:0kB

    Se nel log viene visualizzata una voce Out of memory:

    1. Aggiungi quanto segue al file app.yaml per aumentare le dimensioni del VM predefinita:

      resources:
  memory_gb: 4

    2. Esegui nuovamente il deployment dell'API:

      gcloud app deploy

Se hai specificato l'opzione rollout_strategy: managed nella sezione endpoints_api_service del file app.yaml, utilizza il seguente comando per eseguire nuovamente il deployment dell'API:

  gcloud app deploy

Per ulteriori informazioni, consulta Eseguire il deployment dell'API e dell'ESP.

Controllo dei log di Cloud Logging

Per utilizzare i log di Cloud Logging per risolvere i problemi di risposta:

  1. Nella console Google Cloud, vai alla pagina Logging.

    Vai alla pagina Esplora log

  2. Nella parte superiore della pagina, seleziona il progetto Google Cloud.

  3. Nel menu a discesa a sinistra, seleziona API prodotta > [YOUR_SERVICE_NAME]

  4. Modifica l'intervallo di tempo finché non visualizzi una riga che mostra l'errore di risposta.

  5. Espandi il payload JSON e cerca error_cause.

    • Se error_cause è impostato su application, indica un problema nel codice.

    • Se error cause è diverso e non riesci a risolvere il problema, esporta il log e includilo in qualsiasi comunicazione con Google.

Vai ai seguenti argomenti per ulteriori informazioni:

Problemi con l'esempio Invoke-WebRequest

In alcune versioni di Windows PowerShell, l'esempio Invoke-WebRequest nei tutorial non va a buon fine. Abbiamo anche ricevuto una segnalazione secondo cui la risposta conteneva un elenco di byte non firmati che dovevano essere convertiti in caratteri. Se l'esempioInvoke-WebRequest non ha restituito il risultato previsto, prova a inviare la richiesta utilizzando un'altra applicazione. Ecco alcuni suggerimenti:

  • Avvia Cloud Shell e segui i passaggi per Linux nel tutorial che stavi utilizzando per inviare la richiesta.

  • Installa un'applicazione di terze parti, ad esempio l'estensione del browser Chrome Postman (offerta da www.getpostman.com). Quando crei la richiesta in Postman:

    • Seleziona POST come verbo HTTP.
    • Per l'intestazione, seleziona la chiave content-type e il valore application/json.
    • Per il corpo, inserisci: {"message":"hello world"}

    • Nell'URL, utilizza la chiave API effettiva anziché la variabile di ambiente. Ad esempio:

      • Nell'ambiente flessibile di App Engine: https://example-project-12345.appspot.com/echo?key=AIza...
      • Su altri backend: http://192.0.2.0:80/echo?key=AIza...

  • Scarica e installa curl, che devi eseguire nel prompt dei comandi. Poiché Windows non gestisce le virgolette doppie nidificate all'interno di virgolette singole, devi modificare --data dell'esempio per:

    --data "{\"message\":\"hello world\"}"