Solucionar problemas de errores de respuesta

En esta página se describe cómo solucionar los 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 acceder al backend del servicio. Comprueba lo siguiente:

  • Asegúrate de que el servicio de backend se esté ejecutando. La forma de hacerlo depende del backend.

  • Se ha especificado el puerto de dirección IP correcto del servicio backend:
    • En GKE, comprueba el valor de la marca --backend de ESP (la opción abreviada es -a) en el archivo de manifiesto de tu implementación (a menudo se llama deployment.yaml).
    • En Compute Engine, comprueba el valor de la marca ESP --backend (la opción abreviada es -a) en el comando docker run.

reset reason: connection failure

Si recibes el código HTTP 503 o el código gRPC 14 y el mensaje upstream connect error or disconnect/reset before headers. reset reason: connection failure, significa que ESPv2 no puede acceder al backend del servicio.

Para solucionar el problema, comprueba los elementos que se indican a continuación.

Dirección de backend

ESPv2 debe configurarse con la dirección de backend correcta. Entre los más habituales se encuentran los siguientes:

  • El esquema de la dirección del backend debe coincidir con el tipo de aplicación del backend. Los back-ends de OpenAPI deben ser http:// y los de gRPC, grpc://.
  • En el caso de ESPv2 implementado en Cloud Run, el esquema de la dirección del backend debe ser https:// o grpcs://. El s indica a ESPv2 que configure TLS con el backend.

Petición de DNS

De forma predeterminada, ESPv2 intenta resolver los nombres de dominio en direcciones IPv6. Si la resolución de IPv6 falla, ESPv2 vuelve a las direcciones IPv4.

En algunas redes, es posible que el mecanismo de respaldo no funcione correctamente. En su lugar, puede forzar a ESPv2 a usar direcciones IPv4 mediante la marca --backend_dns_lookup_family.

Este error es habitual si configura un conector de VPC sin servidor para ESPv2 implementado en Cloud Run. Las VPCs no admiten tráfico IPv6.

API is not enabled for the project

Si has enviado una clave de API en la solicitud, un mensaje de error como "API my-api.endpoints.example-project-12345.cloud.goog is not enabled for the project" indica que la clave de API se ha creado en un proyecto de Google Cloud distinto al de la API. Para solucionar este problema, puedes crear la clave de API en el mismo proyecto Google Cloud al que está asociada la API o habilitar la API en el proyecto Google Cloud en el que se creó la clave de API.

Service control request failed with HTTP response code 403

Si recibes el código de error 14 y el mensaje Service control request failed with HTTP response code 403, significa que la API Service Control (servicecontrol.googleapis.com) no está habilitada en el proyecto.

  1. Consulta la sección Comprobar los servicios necesarios para asegurarte de que todos los servicios que requieren Endpoints y ESP estén habilitados en tu proyecto.

  2. Consulta la sección Comprobar los permisos necesarios para asegurarte de que la cuenta de servicio asociada a la instancia que ejecuta ESP tiene todos los permisos necesarios.

Method doesn't allow unregistered callers

ESP responde con el error Method doesn't allow unregistered callers cuando has especificado una clave de API en la sección security de tu documento OpenAPI, pero la solicitud a tu API no tiene ninguna clave de API asignada a un parámetro de consulta llamado key.

Si necesitas generar una clave de API para hacer llamadas a tu API, consulta Crear una clave de API.

Method does not exist

La respuesta Method does not exist significa que no se ha encontrado el método HTTP (GET, POST u otro) en la ruta de URL especificada. Para solucionar problemas, compara la configuración del servicio que has implementado para asegurarte de que el nombre del método y la ruta de URL que envías en la solicitud coincidan:

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

    Ir a la página Servicios de Endpoints

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

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

  4. Selecciona la implementación más reciente para ver la configuración del servicio.

Si no ves el método al que llamas especificado en la sección paths de tu documento de OpenAPI, añade el método o la marca x-google-allow en el nivel superior del archivo:

x-google-allow: all

Esta marca significa que puede evitar enumerar todos los métodos admitidos en su backend en su documento de OpenAPI. Cuando se usa all, todas las llamadas (con o sin clave de API o autenticación de usuario) pasan por ESP a 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 APIs desplegadas en el entorno flexible de App Engine.

Código de error 502 o 503

App Engine puede tardar unos minutos en responder correctamente a las solicitudes. Si envías una solicitud y recibes un error HTTP 502, 503 u otro error del servidor, espera un minuto y vuelve a intentarlo.

Mensaje de error BAD_GATEWAY

Un código de error 502 con BAD_GATEWAY en el mensaje suele indicar que App Engine ha terminado la aplicación porque se ha quedado sin memoria. La VM flexible predeterminada de App Engine solo tiene 1 GB de memoria, de los cuales solo 600 MB están disponibles para el contenedor de la aplicación.

Para solucionar el problema del código de error 502, haz lo siguiente:

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

    Ir a la página Explorador de registros

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

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

  4. Busca una entrada de registro similar a la siguiente:

    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:

    1. Añade lo siguiente a tu archivo app.yaml para aumentar el tamaño de la máquina virtual predeterminada:

      resources:
  memory_gb: 4

    2. Vuelve a desplegar la API:

      gcloud app deploy

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

  gcloud app deploy

Consulta más información en el artículo sobre desplegar tu API y ESP.

Consultar los registros de Cloud Logging

Para usar los registros de Cloud Logging y solucionar problemas de errores de respuesta, sigue estos pasos:

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

    Ir a la página Explorador de registros

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

  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 muestre el error de respuesta.

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

    • Si error_cause tiene el valor application, significa que hay un problema en tu código.

    • Si el error cause es otro valor y no puedes solucionar el problema, exporta el registro e inclúyelo en cualquier comunicación que tengas con Google.

Consulta las siguientes secciones para obtener más información:

Problemas con el ejemplo de Invoke-WebRequest

En algunas versiones de Windows PowerShell, el ejemplo Invoke-WebRequest de los tutoriales falla. También hemos recibido un informe que indica que la respuesta contenía una lista de bytes sin signo que se tuvieron que convertir en caracteres. Si el ejemplo Invoke-WebRequest no ha devuelto el resultado esperado, prueba a enviar la solicitud con otra aplicación. A continuación, te ofrecemos algunas sugerencias:

  • Inicia Cloud Shell y sigue los pasos para Linux del tutorial que estabas usando para enviar la solicitud.

  • Instala una aplicación de terceros, como la extensión del navegador Chrome Postman (ofrecida por www.getpostman.com). Cuando crees la solicitud en Postman, haz lo siguiente:

    • Selecciona POST como verbo HTTP.
    • En el encabezado, selecciona la clave content-type y el valor application/json.
    • En el cuerpo, escribe: {"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: https://example-project-12345.appspot.com/echo?key=AIza...
      • En otros backends: http://192.0.2.0:80/echo?key=AIza...

  • Descarga e instala curl, que se ejecuta en el símbolo del sistema. Como Windows no gestiona las comillas dobles anidadas dentro de comillas simples, debes cambiar la opción --data del ejemplo por lo siguiente:

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