Compute Engine의 경우 docker run 명령어로 ESP --backend 플래그 값(단축 옵션은 -a)을 확인합니다.
reset reason: connection failure
HTTP 코드 503 또는 gRPC 코드 14와 upstream connect error or disconnect/reset before headers. reset reason: connection failure 메시지를 받은 경우 ESPv2가 서비스의 백엔드에 연결할 수 없음을 나타냅니다.
이 오류는 Cloud Run에 배포된 ESPv2의 서버리스 VPC 커넥터를 구성하는 경우에 일반적으로 나타납니다. VPC는 IPv6 트래픽을 지원하지 않습니다.
API is not enabled for the project
요청에 API 키를 전송한 경우 'API
my-api.endpoints.example-project-12345.cloud.goog가 프로젝트에 사용 설정되지 않았습니다.'와 같은 오류 메시지는 해당 API와 다른 Google Cloud
프로젝트에서 API 키를 만들었음을 나타냅니다. 이 문제를 해결하려면 API가 연결된 것과 동일한 Google Cloud 프로젝트에서 API 키를 생성하거나 API 키가 생성된 Google Cloud 프로젝트에서 API를 사용 설정하면 됩니다.
Service control request failed with HTTP response code 403
오류 코드 14와 Service control request failed
with HTTP response code 403 메시지가 수신되면 프로젝트에서 Service Control API(servicecontrol.googleapis.com)가 사용 설정되지 않은 경우입니다.
필수 서비스 확인을 참조하여 Endpoints 및 ESP에 필요한 서비스가 프로젝트에서 모두 사용 설정되었는지 확인하세요.
ESP 실행 인스턴스와 연관된 서비스 계정에 필요한 모든 권한을 확인하려면 필요한 권한 확인을 참조하세요.
Method doesn't allow unregistered callers
gRPC API 구성 파일에 allow_unregistered_calls: false를 지정했지만 API 요청에서 key라는 쿼리 매개변수에 API 키가 할당되어 있지 않으면 ESP가 Method doesn't allow unregistered callers 오류로 응답합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eThis document guides you through troubleshooting API response errors when using Extensible Service Proxy (ESP) or ESPv2, covering a variety of error messages and their causes.\u003c/p\u003e\n"],["\u003cp\u003eIf you encounter an \u003ccode\u003eupstream backend unavailable\u003c/code\u003e error, verify that the backend service is running and that the correct IP address and port are specified in the ESP's \u003ccode\u003e--backend\u003c/code\u003e flag.\u003c/p\u003e\n"],["\u003cp\u003eAn error indicating a connection failure or reset suggests that ESPv2 is unable to reach the service backend, often due to an incorrect backend address scheme (\u003ccode\u003ehttp://\u003c/code\u003e or \u003ccode\u003egrpc://\u003c/code\u003e), or issues with IPv6 resolution, especially in Serverless VPC Connector setups.\u003c/p\u003e\n"],["\u003cp\u003eWhen receiving an error that an API is not enabled for a project, you can fix this by either creating the API key in the same project or enabling the API in the project where the key was created.\u003c/p\u003e\n"],["\u003cp\u003eErrors like \u003ccode\u003etransport is closing\u003c/code\u003e or unexpected binary responses often point to issues with ESP configuration, such as incorrect port settings (\u003ccode\u003e--http_port\u003c/code\u003e or \u003ccode\u003e--http2_port\u003c/code\u003e) or an improperly configured backend flag, and the Cloud Logging can be utilized to diagnose the specific cause of other issues.\u003c/p\u003e\n"]]],[],null,["# Troubleshooting Response Errors\n\n[OpenAPI](/endpoints/docs/openapi/troubleshoot-response-errors \"View this page for the Cloud Endpoints OpenAPI docs\") \\| gRPC\n\n\u003cbr /\u003e\n\nThis page describes how to troubleshoot errors that you receive in a response\nfrom a request to your API.\n\n`Upstream backend unavailable`\n------------------------------\n\nIf you receive error code `14` and the message `upstream backend unavailable`,\nthis indicates that the Extensible Service Proxy (ESP) can't reach the\nservice's backend. Check the following:\n\n- Make sure the backend service is running. How you do that depends on the backend.\n - For Compute Engine see [Troubleshooting Cloud Endpoints on Compute Engine](/endpoints/docs/grpc/troubleshoot-gce-deployment) for details.\n - For GKE, you need to use SSH to access the pod and use `curl`. See [Troubleshooting\n Endpoints in Google Kubernetes Engine](/endpoints/docs/grpc/troubleshoot-gke-deployment) for details.\n\n \u003cbr /\u003e\n\n- The correct IP address port of the backend service is specified:\n - For GKE, check the ESP `--backend` flag value (the short option is `-a`) in your deployment manifest file (often called `deployment.yaml`).\n - For Compute Engine check the ESP `--backend` flag value (the short option is `-a`) in the `docker run` command.\n\n\u003cbr /\u003e\n\n`reset reason: connection failure`\n----------------------------------\n\nIf you receive HTTP code `503` or gRPC code `14` and the message `upstream connect error or disconnect/reset before headers. reset reason: connection failure`, this indicates\nthat ESPv2 can't reach the service's backend.\n\nTo troubleshoot, double check the items below.\n\n### Backend Address\n\nESPv2 should be configured with the correct backend address. Common issues include:\n\n- The scheme of the backend address should match the backend application type. OpenAPI backends should be `http://` and gRPC backends should be `grpc://`.\n- For ESPv2 deployed on Cloud Run, the scheme of the backend address should be either `https://` or `grpcs://`. The `s` tells ESPv2 to set up TLS with the backend.\n\n### DNS Lookup\n\nBy default, ESPv2 attempts to resolve domain names to IPv6 addresses.\nIf the IPv6 resolution fails, ESPv2 falls back to IPv4 addresses.\n\nFor some networks, the fallback mechanism may not work as intended.\nInstead, you can force ESPv2 to use IPv4 addresses via the\n[`--backend_dns_lookup_family` flag](/endpoints/docs/openapi/specify-esp-v2-startup-options).\n\nThis error is common if you configure a [Serverless VPC Connector](/vpc/docs/configure-serverless-vpc-access)\nfor ESPv2 deployed on Cloud Run. VPCs do not support IPv6 traffic.\n\n`API is not enabled for the project`\n------------------------------------\n\nIf you sent an API key in the request, an error message like \"API\nmy-api.endpoints.example-project-12345.cloud.goog is not enabled for the\nproject\" indicates that the API key was created in a different Google Cloud\nproject than the API. To fix this, you can either\n[create the API key](/docs/authentication/api-keys#creating_an_api_key)\nin the same Google Cloud project that the API is associated with, or you\ncan\n[enable the API](/endpoints/docs/openapi/enable-api)\nin the Google Cloud project that\nthe API key was created in.\n\n`Service control request failed with HTTP response code 403`\n------------------------------------------------------------\n\nIf you receive error code `14` and the message `Service control request failed\nwith HTTP response code 403`, this indicates that the Service Control API\n(`servicecontrol.googleapis.com`) isn't enabled on the project.\n\n1. See [Checking required services](/endpoints/docs/grpc/troubleshoot#checking_required_services)\n to make sure that all the services that Endpoints and\n ESP require are enabled on your project.\n\n2. See [Checking required permissions](/endpoints/docs/grpc/troubleshoot#checking_required_permissions)\n to make sure that all the required permissions to the service account associated with the instance running ESP.\n\n`Method doesn't allow unregistered callers`\n-------------------------------------------\n\nESP responds with the error,\n`Method doesn't allow unregistered callers`, when you have specified\n`allow_unregistered_calls: false` in your gRPC API configuration file, but the\nrequest to your API doesn't have an API key assigned to a query parameter\nnamed `key`.\n\nIf you need to generate an API key to make calls to your API, see\n[Creating an API key](/docs/authentication/api-keys#creating_an_api_key).\n\n`Method does not exist`\n-----------------------\n\nThe response, `Method does not exist`, means that the HTTP method\n(`GET`, `POST`, or other) on the specified URL path wasn't found. To\ntroubleshoot, compare the service configuration that you have deployed to make\nsure that the method name and URL path that you are sending in the request\nmatch:\n\n1. In the Google Cloud console, go to the **Endpoints Services** page for\n your project.\n\n [Go to the Endpoints Services page](https://console.cloud.google.com/endpoints)\n\n \u003cbr /\u003e\n\n2. If you have more than one API, select the API that you sent the request to.\n\n3. Click the **Deployment history** tab.\n\n4. Select the latest deployment to see the service configuration.\n\n`Transport is closing`\n----------------------\n\nIf you receive an error code `13` and the message `transport is closing`, this\nindicates that ESP is unreachable.\n\nCheck the ESP error logs. How you do that depends on the backend.\nSee the following for more information:\n\n- [Viewing logs on Compute Engine](/endpoints/docs/grpc/troubleshoot-gce-deployment#viewing_logs_on_the_vm_instance)\n- [Accessing ESP logs on GKE](/endpoints/docs/grpc/troubleshoot-gke-deployment#accessing_logs_from_extensible_service_proxy)\n\nUnexpected responses\n--------------------\n\nIf the HTTP response looks like it is binary, this might indicate that\nthe request is hitting the API by using the `HTTP2` port when you intended to\nuse the `HTTP1` port.\n\nCheck your port configuration options for ESP. Because the\nshort-form flags, `-p` (for `HTTP1`) and `-P` (for `HTTP2`), look similar, we\nrecommend that you use the long form flags instead: `--http_port` for `HTTP1`\nand `--http2_port` for `HTTP2`.\n\nA misconfiguration of the ESP backend might also cause\nunexpected responses. Make sure the backend flag (`-a` or `--backend`) is set to\na gRPC URL such as `--backend=grpc://127.0.0.1:8081`.\n\nFor more details on the ESP flags, see\n[ESP startup options](/endpoints/docs/grpc/specify-proxy-startup-options).\n\nChecking the Cloud Logging logs\n-------------------------------\n\nTo use the Cloud Logging logs to help troubleshoot response errors:\n\n1. In the Google Cloud console, go to the **Logging** page.\n\n\n [Go to the Logs Explorer page](https://console.cloud.google.com/logs/query)\n\n \u003cbr /\u003e\n\n2. At the top of the page, select the Google Cloud project.\n\n3. Using the drop-down menu on the left, select **Produced API** \\\u003e\n **\\[YOUR_SERVICE_NAME\\]**.\n\n4. Adjust the time range until you see a row that shows your response error.\n\n5. Expand the JSON payload and look for `error_cause`.\n\n - If the `error_cause` is set to `application`, this indicates an issue in\n your code.\n\n - If the `error cause` is anything else and you are unable to fix the issue,\n [export the log](/logging/docs/export/configure_export#configuring_logs_export_in_the_console_name_short)\n and include it in any communication that you have with Google.\n\nSee the following for more information:\n\n- For details on the structure of the logs in the Logs Explorer, see the\n [Endpoints logs reference](/endpoints/docs/grpc/ref-endpoints-logs)\n\n- Get started using the [Logs Explorer](/logging/docs/view/logs_viewer).\n\n- Use [Advanced log queries](/logging/docs/view/advanced_filters)\n for advanced filtering, such as getting all requests with a latency greater\n than 300 milliseconds."]]
