Questa pagina descrive come risolvere gli errori che ricevi in una risposta da una richiesta alla tua API.
Upstream backend unavailable
Se ricevi il codice di errore 14
e il messaggio upstream backend unavailable
, significa che Extensible Service Proxy (ESP) non riesce a raggiungere il backend del servizio. Verifica quanto segue:
- Assicurati che il servizio di backend sia in esecuzione. Il modo in cui devi farlo dipende dal backend.
- Per Compute Engine, consulta Risoluzione dei problemi di Cloud Endpoints su Compute Engine per i dettagli.
-
Per GKE, devi utilizzare SSH per accedere al pod e utilizzare
curl
. Per i dettagli, consulta Risoluzione dei problemi relativi agli endpoint in Google Kubernetes Engine.
- È stata specificata la porta dell'indirizzo IP corretto del servizio di backend:
-
Per GKE, controlla il valore del flag
--backend
ESP (l'opzione breve è-a
) nel file manifest del deployment (spesso chiamatodeployment.yaml
). -
Per Compute Engine, controlla il valore del flag
--backend
ESP (l'opzione breve è-a
) nel comandodocker run
.
-
Per GKE, controlla il valore del flag
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 è in grado di raggiungere il backend del servizio.
Per risolvere il problema, ricontrolla quanto segue.
Indirizzo backend
ESPv2 deve essere configurato con l'indirizzo di 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://
, mentre quelli gRPC devono esseregrpc://
. - Per ESPv2 di cui è stato eseguito il deployment in Cloud Run, lo schema dell'indirizzo di backend deve essere
https://
ogrpcs://
.s
indica a ESPv2 di configurare TLS con il backend.
Ricerca DNS
Per impostazione predefinita, ESPv2 tenta di risolvere i nomi di dominio negli indirizzi IPv6. Se la risoluzione IPv6 non va a buon fine, ESPv2 utilizza gli indirizzi IPv4.
Per alcune reti, il meccanismo di riserva potrebbe non funzionare come previsto.
Puoi invece 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 in Cloud Run. I VPC non supportano il traffico IPv6.
API is not enabled for the project
Se hai inviato una chiave API nella richiesta, un messaggio di errore come "API my-api.endpoints.example-project-12345.cloud.goog non è abilitata per il progetto" indica che la chiave API è stata creata in un progetto Google Cloud diverso dall'API. Per risolvere il problema, puoi creare la chiave API nello stesso progetto Google Cloud a cui è associata l'API oppure abilitare 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 è abilitata nel progetto.
Consulta Verifica dei servizi richiesti per assicurarti che tutti i servizi richiesti da Endpoints ed ESP siano abilitati nel tuo progetto.
Vedi Controllo delle autorizzazioni richieste per assicurarti che tutte le autorizzazioni necessarie per l'account di servizio siano associate all'istanza che esegue ESP.
Method doesn't allow unregistered callers
ESP risponde con l'errore Method doesn't allow unregistered callers
se hai specificato allow_unregistered_calls: false
nel file di configurazione dell'API gRPC, 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 all'API, consulta Creazione di una chiave API.
Method does not exist
La risposta Method does not exist
indica che non è stato trovato il metodo HTTP
(GET
, POST
o altro) nel percorso dell'URL specificato. Per risolvere il problema, confronta la configurazione del servizio di cui hai eseguito il deployment per assicurarti che il nome del metodo e il percorso dell'URL che stai inviando nella richiesta corrispondano:
Nella console Google Cloud, vai alla pagina Servizi endpoint relativa al tuo progetto.
Se hai più di un'API, seleziona quella a cui hai inviato la richiesta.
Fai clic sulla scheda Cronologia deployment.
Seleziona il deployment più recente per visualizzare la configurazione del servizio.
Transport is closing
Se ricevi un codice di errore 13
e il messaggio transport is closing
, significa che ESP non è raggiungibile.
Controlla i log degli errori ESP. Il modo in cui puoi farlo dipende dal backend. Vai ai seguenti argomenti per ulteriori informazioni:
Risposte impreviste
Se la risposta HTTP sembra binaria, è possibile che la richiesta raggiunga l'API utilizzando la porta HTTP2
quando intendevi usare la porta HTTP1
.
Controlla le opzioni di configurazione delle porte per ESP. Poiché i flag nel formato breve -p
(per HTTP1
) e -P
(per HTTP2
) sono simili, ti consigliamo di utilizzare invece i flag nel formato lungo: --http_port
per HTTP1
e --http2_port
per HTTP2
.
Anche un errore di configurazione del backend ESP potrebbe causare risposte impreviste. Assicurati che il flag di backend (-a
o --backend
) sia impostato su un URL gRPC, ad esempio --backend=grpc://127.0.0.1:8081
.
Per maggiori dettagli sui flag ESP, consulta Opzioni di avvio di ESP.
Controllo dei log di Cloud Logging
Per utilizzare i log di Cloud Logging per risolvere gli errori di risposta:
Nella console Google Cloud, vai alla pagina Logging.
Nella parte superiore della pagina, seleziona il progetto Google Cloud.
Utilizzando il menu a discesa a sinistra, seleziona API prodotta > [YOUR_SERVICE_NAME].
Modifica l'intervallo di tempo finché non viene visualizzata una riga che mostra l'errore di risposta.
Espandi il payload JSON e cerca
error_cause
.Se
error_cause
è impostato suapplication
, significa che c'è un problema nel codice.Se il
error cause
non è altro e non riesci a risolvere il problema, esporta il log e includilo in tutte le tue comunicazioni con Google.
Vai ai seguenti argomenti per ulteriori informazioni:
Per maggiori dettagli sulla struttura dei log in Esplora log, consulta la pagina di riferimento sui log degli endpoint
Inizia a utilizzare Esplora log.
Utilizza le query di log avanzate per filtri avanzati, ad esempio per ricevere tutte le richieste con una latenza superiore a 300 millisecondi.