Cómo solucionar errores de respuesta

En esta página, se describe cómo solucionar errores que recibes en una respuesta de una solicitud a tu API.

BAD_GATEWAY

Si recibes el código de error 13 y el mensaje BAD_GATEWAY, 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. Esto depende del backend.

  • 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 llamado deployment.yaml).
    • Para Compute Engine, verifica el valor de la marca --backend del ESP (la opción corta es -a) en el comando docker run.

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 ser grpc://.
  • Para el ESPv2 implementado en Cloud Run, el esquema de la dirección de backend debe ser https:// o grpcs://. 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 solucionar este problema, puedes hacer lo siguiente: Crea la clave de API en el mismo proyecto de Google Cloud con el que está asociada la API, o bien de los habilitar la API en el proyecto de Google Cloud 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.

  1. 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.

  2. 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 has especificado una clave de la API en la sección security de tu documento de OpenAPI, pero la solicitud a tu API no tiene asignada una clave de la 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:

  1. En la consola de Google Cloud, ve a la página Servicios de Endpoints para tu proyecto.

    Ir a la página Servicios de Endpoints

  2. Si tienes más de una API, selecciona la API a la que le enviaste la solicitud.

  3. Haz clic en la pestaña Historial de implementaciones.

  4. Selecciona la última implementación para ver la configuración del servicio.

Si no ves el método al que estás llamando especificado en la sección paths de tu documento de OpenAPI, puedes agregar el método o la marca x-google-allow en el nivel superior del archivo:

x-google-allow: all

Esta marca significa que puedes evitar todos los métodos admitidos en tu backend de tu documento de OpenAPI. Cuando se use all, todas las llamadas, ya sea con o sin una clave de API o autenticación del usuario, pasan a través de ESP hasta tu API. Consulta x-google-allow para obtener más información.

Errores específicos del entorno flexible de App Engine

En esta sección, se describen las respuestas de error de las API implementadas en el entorno flexible de App Engine.

Código de error 502 o 503

App Engine podría tardar unos minutos en responder a las solicitudes de forma correcta. Si envías una solicitud y recibes un error HTTP 502, 503 o demás errores del servidor, espera un minuto y vuelve a enviar la solicitud.

Mensaje de error BAD_GATEWAY

Por lo general, un código de error 502 con BAD_GATEWAY en el mensaje indica que App Engine cerró la aplicación porque se quedó sin memoria. La VM predeterminada de App Engine solo tiene 1 GB de memoria, y solo 600 MB están disponibles para el contendor de la aplicación.

Para solucionar el código de error 502, sigue estos pasos:

  1. En la consola de Google Cloud, ve a la página Registros:

    Ir a la página Explorador de registros

  2. Selecciona el proyecto de Google Cloud aplicable en la parte superior de la página.

  3. Selecciona Aplicación de Google App Engine y abre vm.syslog.

  4. Busca una entrada de registro similar a la que muetra a continuación:

    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

    Si ves una entrada Out of memory en el registro, sigue estos pasos:

    1. Agrega lo siguiente a tu archivo app.yaml para aumentar el tamaño de la VM predeterminada:

      resources:
  memory_gb: 4

    2. Vuelve a implementar tu API:

      gcloud app deploy

Si la opción rollout_strategy: managed está especificada en la sección endpoints_api_service del archivo app.yaml, usa el comando siguiente para volver a implementar tu API:

  gcloud app deploy

Si quieres obtener más información, consulta Cómo implementar tu API y el 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:

  1. En la consola de Google Cloud, ve a la página Logging.

    Ir a la página Explorador de registros

  2. En la parte superior de la página, selecciona el proyecto de Google Cloud.

  3. En el menú desplegable de la izquierda, selecciona API producida > [YOUR_SERVICE_NAME].

  4. Ajusta el intervalo de tiempo hasta que veas una fila que muestra un error de respuesta.

  5. Expande la carga útil de JSON y busca error_cause.

    • Si error_cause está configurado como application, esto indica que hay un problema en tu código.

    • Si error cause es otra cosa y no puedes solucionar el problema, haz lo siguiente: exportar el registro e incluirlo en cualquier comunicación que tengas con Google.

Consulta los siguientes vínculos para obtener más información:

Problemas con el ejemplo Invoke-WebRequest

En algunas versiones de Windows PowerShell, el ejemplo Invoke-WebRequest en la instructivos falla. También recibimos un informe que indica que la respuesta contenía una lista de bytes sin firma que debían convertirse en caracteres. Si el ejemplo Invoke-WebRequest no mostró el resultado esperado, intenta enviar la solicitud con otra aplicación. A continuación, se muestran algunas sugerencias:

  • Inicia Cloud Shell. y sigue los pasos para Linux del instructivo que usaste para enviar para cada solicitud.

  • Instala una aplicación de terceros, como la extensión Postman del navegador Chrome (que ofrece www.getpostman.com). Cuando crees la solicitud en Postman, ejecuta el comando siguiente:

    • Selecciona POST como el verbo HTTP.
    • En el encabezado, selecciona la clave content-type y el valor application/json.
    • Para el cuerpo, ingresa: {"message":"hello world"}

    • En la URL, usa la clave de API real, en lugar de la variable de entorno. Por ejemplo:

      • En el entorno flexible de App Engine, usa: https://example-project-12345.appspot.com/echo?key=AIza...
      • En otros backends, usa: http://192.0.2.0:80/echo?key=AIza...

  • Descarga y, luego, instala curl, que debes ejecutar en el símbolo del sistema. Debido a que Windows no maneja las comillas dobles anidadas entre comillas simples, debes cambiar la opción --data en el ejemplo a:

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