En esta página, se describe cómo solucionar errores que recibes en una respuesta de una solicitud a tu API.
Upstream backend unavailable
Si recibes el código de error 14
y el mensaje upstream backend unavailable
, significa que el proxy de servicio extensible (ESP) no puede alcanzar el backend de servicio. Verifica lo siguiente:
- Asegúrate de que el servicio de backend se ejecute. Cómo hacerlo depende del backend.
- Si quieres obtener más detalles para Compute Engine, consulta Cómo solucionar problemas de Cloud Endpoints en Compute Engine.
-
Para GKE, debes usar SSH a fin de acceder al pod y usar
curl
. Consulta Solucionar problemas de Cloud Endpoints en GKE para obtener más detalles.
- Se especifica el puerto de la dirección IP correcto del servicio de backend:
- Para GKE, verifica el valor de la marca
--backend
del ESP (la opción corta es-a
) en tu archivo de manifiesto de implementación (a veces llamadodeployment.yaml
). - Para Compute Engine, verifica el valor de la marca
--backend
del ESP (la opción corta es-a
) en el comandodocker run
.
- Para GKE, verifica el valor de la marca
reset reason: connection failure
Si recibes el código HTTP 503
o gRPC 14
y el mensaje upstream connect error or disconnect/reset before headers. reset reason: connection failure
, significa que el ESPv2 no puede alcanzar el backend del servicio.
Para solucionar el problema, vuelve a revisar los siguientes elementos.
Dirección de backend
El ESPv2 debe configurarse con la dirección de backend correcta. Algunos problemas comunes son los siguientes:
- El esquema de la dirección de backend debe coincidir con el tipo de aplicación de backend.
Los backends de OpenAPI deben ser
http://
y los backends de gRPC deben sergrpc://
. - Para el ESPv2 implementado en Cloud Run, el esquema de la dirección de backend debe ser
https://
ogrpcs://
.s
le indica al ESPv2 que configure TLS con el backend.
Búsqueda de DNS
De forma predeterminada, el ESPv2 intenta resolver nombres de dominio a direcciones IPv6. Si la resolución de IPv6 falla, ESPv2 recurre a las direcciones IPv4.
En algunas redes, es posible que el mecanismo de resguardo no funcione según lo previsto.
En cambio, puedes forzar al ESPv2 a usar direcciones IPv4 a través de la --backend_dns_lookup_family
marca.
Este error es común si configuras un conector de VPC sin servidores para el ESPv2 implementado en Cloud Run. Las VPC no admiten tráfico IPv6.
API is not enabled for the project
Si envías una clave de API en la solicitud y aparece un mensaje de error como “API my-api.endpoints.example-project-12345.cloud.goog is not enabled for the project”, significa que la clave de API y la API se crearon en proyectos de Google Cloud distintos. Para solucionarlo, puedes crear la clave de API en el mismo proyecto de Google Cloud al que está asociada la API o habilitar la API en el proyecto de Google Cloud en el que se creó la clave de API.
Service control request failed with HTTP response code 403
Si recibes un mensaje de error 14
y el mensaje Service control request failed
with HTTP response code 403
, esto significa que la API de Control de servicios (servicecontrol.googleapis.com
) no está habilitada en el proyecto.
Consulta la sección sobre cómo verificar los servicios requeridos para asegurarte de que todos los servicios que Endpoints y ESP requieren estén habilitados en tu proyecto.
Consulta Verifica los permisos obligatorios para asegurarte todos los permisos necesarios a la cuenta de servicio asociada con la instancia que ejecuta el ESP.
Method doesn't allow unregistered callers
ESP responde al error Method doesn't allow unregistered callers
si especificaste allow_unregistered_calls: false
en tu archivo de configuración de la API de gRPC, pero la solicitud a tu API no tiene asignada una clave de API a un parámetro de consulta llamado key
.
Si necesitas generar una clave de API para realizar llamadas a tu API, consulta la sección sobre cómo crear una clave de API.
Method does not exist
La respuesta, Method does not exist
, significa que no se encontró el método HTTP (GET
, POST
o algún otro) en la ruta de URL especificada. Para solucionar este problema, compara la configuración del servicio que implementaste a fin de asegurarte de que coincidan el nombre del método y la ruta de URL que envías a la solicitud:
En la consola de Google Cloud, ve a la página Servicios de Endpoints de tu proyecto.
Si tienes más de una API, selecciona la API a la que le enviaste la solicitud.
Haz clic en la pestaña Historial de implementaciones.
Selecciona la última implementación para ver la configuración del servicio.
Transport is closing
Si recibes un código de error 13
y el mensaje transport is closing
, esto indica que ESP no está disponible.
Comprueba los registros de errores del ESP. Cómo hacerlo depende del backend. Consulta los siguientes vínculos para obtener más información:
Respuestas inesperadas
Si la respuesta HTTP parece ser binaria, esto podría indicar que la solicitud llega a la API mediante el puerto HTTP2
cuando tenía la intención de usar el puerto HTTP1
.
Verifica las opciones de configuración del puerto para ESP. Debido a que las marcas de forma abreviada, -p
(para HTTP1
) y -P
(para HTTP2
) tienen un aspecto similar, le recomendamos que uses las marcas de forma larga: --http_port
para HTTP1
y --http2_port
para HTTP2
.
Una mala configuración del backend del ESP también puede causar respuestas inesperadas. Asegúrate de que la marca del backend (-a
o --backend
) esté configurado para una URL de gRPC como --backend=grpc://127.0.0.1:8081
.
Para obtener más detalles sobre las marcas del ESP, consulta Opciones de inicio del ESP.
Verifica los registros de Cloud Logging
Si deseas usar los registros de Cloud Logging para solucionar problemas de errores de las respuestas, haz lo siguiente:
En la consola de Google Cloud, ve a la página Logging.
En la parte superior de la página, selecciona el proyecto de Google Cloud.
En el menú desplegable de la izquierda, selecciona API producida > [YOUR_SERVICE_NAME].
Ajusta el intervalo de tiempo hasta que veas una fila que muestra un error de respuesta.
Expande la carga útil de JSON y busca
error_cause
.Si
error_cause
está configurado comoapplication
, esto indica que hay un problema en tu código.Si
error cause
es distinto y no puedes solucionar el problema, exporta el registro y, luego, inclúyelo en cualquier comunicación que tengas con Google.
Consulte los siguientes artículos para obtener más información:
Para obtener más detalles sobre la estructura de los registros en el explorador de registros, consulta la referencia de registros de Endpoints
Comienza a usar el Explorador de registros.
Usa las consultas de registros avanzadas para aprovechar las funciones del filtro avanzado, como la obtención de todas las solicitudes con una latencia mayor a 300 milésimas de segundo.