이 문제를 해결하는 방법에 대한 자세한 내용은 외부 승인이라는 Envoy 문서를 참조하고, failure_mode_allow 속성에 대한 정보를 참조합니다. 이 속성을 사용하면 오류 시 필터의 동작을 변경할 수 있습니다.
누락되거나 잘못된 JWT가 거부되지 않음
Envoy JWT 필터가 구성되지 않았기 때문일 수 있습니다.
유효한 API 키 실패
가능한 원인
Envoy가 원격 서비스에 연결할 수 없습니다.
사용자 인증 정보가 올바르지 않습니다.
대상 및 env에 대해 Apigee API 제품이 구성되지 않았습니다.
Envoy가 Apigee API 제품을 인식하지 못함
문제 해결 단계
Apigee에서 API 제품 확인
환경(test와 prod)에 사용 설정되어 있나요?
제품이 원격 서비스와 동일한 환경에 바인딩되어야 합니다.
액세스하는 대상에 결합되어 있나요?
Apigee 원격 서비스 대상 섹션을 확인합니다. 서비스 이름은 정규화된 호스트 이름이어야 합니다. Istio 서비스의 경우 이름이 helloworld.default.svc.cluster.localcode>와 같이 지정됩니다. 이 이름은 default 네임스페이스의 helloworld 서비스를 나타냅니다.
리소스 경로가 요청과 일치하나요?
/ 또는 /**와 같은 경로는 모든 경로와 일치합니다. 또한 일치에 '*' 또는 '**' 와일드 카드를 사용할 수도 있습니다.
개발자 앱이 있나요?
키 확인을 위해서는 API 제품이 개발자 앱에 바인딩되어야 합니다.
Apigee API 제품 operationConfigType이 remoteservice로 설정되어 있나요?
Apigee Management API를 사용하여 API 제품 구성을 확인하고 operationConfigType이 remoteservice로 설정되었는지 확인합니다.
[[["이해하기 쉬움","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-08-18(UTC)"],[[["\u003cp\u003eThis guide focuses on troubleshooting 404 errors, missing analytics, and API key/JWT rejection issues specifically within Apigee and Apigee hybrid environments.\u003c/p\u003e\n"],["\u003cp\u003eA common cause of 404 errors is conflicting wildcard Gateway definitions in Istio, requiring users to adjust or delete one of the conflicting gateways.\u003c/p\u003e\n"],["\u003cp\u003eDebugging 404 errors in Istio involves a systematic, layered approach, starting from the backend workload and moving outward through the sidecar and gateway.\u003c/p\u003e\n"],["\u003cp\u003eIssues with missing analytics can stem from delayed Apigee intake, incorrect Envoy gRPC Access Log configuration, or problems with Envoy or Remote Service connectivity.\u003c/p\u003e\n"],["\u003cp\u003eAPI key and JWT validation failures can be caused by improper configuration of \u003ccode\u003eext-authz\u003c/code\u003e, fail-open settings in the Remote Service, or incorrect setup of Apigee API Products, requiring checks of configuration and debug logging.\u003c/p\u003e\n"]]],[],null,["# Troubleshooting\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nIstio 404 (Not Found) error\n---------------------------\n\nDebugging a 404 (Not Found) error on Istio can be frustrating. Hopefully this will give you a\nplace to start tracking down where things may be going wrong.\n\n### Wildcard Gateway conflict\n\nThere can be only one Gateway definition that uses a wildcard \"\\*\" hosts value. If you've\ndeployed anything else that includes a wildcard Gateway, client calls will fail with a 404 status.\n\nExample: \n\n```\n$ istioctl get gateways\nGATEWAY NAME HOSTS NAMESPACE AGE\nbookinfo-gateway * default 20s\nhttpbin-gateway * default 3s\n```\n\nIf so, you'll need to delete or change one of the conflicting gateways.\n\nSearch for where the route is failing\n-------------------------------------\n\nIstio is like an onion (or, perhaps, an Ogre), it has layers. A systematic way to debug\na 404 is to work outward from the target.\n\n### The backend workload\n\nVerify you can access the workload from the sidecar: \n\n```\nkubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers\n```\n\n### The backend sidecar\n\nSet your service address and get the IP address of the workload pod. \n\n```\nSERVICE=httpbin.default.svc.cluster.local:80\n POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')\n```\n\nAccess the workload through the sidecar: \n\n```\nkubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve \"$SERVICE:$POD_IP\"\n```\n\nOr, if Istio mTLS is enabled: \n\n```\nkubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v https://$SERVICE/headers --resolve \"$SERVICE:$POD_IP\" --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure\n```\n\n### The gateway (or a frontend sidecar)\n\nAccess the service from the gateway: \n\n```\nkubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header\n```\n\nOr, if Istio mTLS is enabled: \n\n```\nkubectl -n istio-system exec $GATEWAY_POD -- curl -v https://$SERVICE/headers --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure\n```\n\nMissing analytics\n-----------------\n\n\nIf you aren't seeing analytics in the Analytics UI, consider these possible causes:\n\n- Apigee intake can be delayed a few minutes\n- Envoy gRPC Access Log not configured correctly\n- Envoy cannot reach Remote Service\n- Remote Service is failing upload\n\nMissing or bad API key not being rejected\n-----------------------------------------\n\n\nIf API key validation is not working properly, consider these possible causes:\n\n\n**Direct proxy**\n\n\nCheck the `ext-authz` configuration.\n**Sidecar**\n\n- Be sure listener is configured for intercept.\n- Check the `ext-authz` configuration.\n\n\n**Invalid requests are being checked and allowed**\n\n- Remote Service configured for fail open\n- Envoy not configured for RBAC checks\n\n\nFor information on how to address these issues, refer to the following Envoy documentation\ntopic: [External Authorization](https://www.envoyproxy.io/docs/envoy/v1.15.0/api-v3/extensions/filters/http/ext_authz/v3/ext_authz.proto.html),\nand refer to information about the `failure_mode_allow` property. This property\nallows you to change the filter's behavior on errors.\n\nMissing or bad JWT not being rejected\n-------------------------------------\n\n\nThe probable cause is that the Envoy JWT filter is not configured.\n\nValid API key fails\n-------------------\n\n### Probable causes\n\n- Envoy cannot reach the remote service\n- Your credentials are not valid\n- Apigee API Product not configured for target and env\n- Envoy is not aware of Apigee API Product\n\n### Troubleshooting steps\n\n#### Check your API Product on Apigee\n\n- *Is it enabled for your environment (test vs prod)?*\n\n The product must be bound to the same environment as your Remote Service.\n- *Is it bound to the target you're accessing?*\n\n Check the **Apigee remote service targets** section. Remember, the service name must be a\n fully qualified host name. If it's an Istio service, the name will be something like\n `helloworld.default.svc.cluster.local`code\\\u003e - which represents the `helloworld` service\n in the `default` namespace.\n- *Does the Resource Path match your request?*\n\n Remember, a path like `/` or `/**` will match any path. You may also use '\\*' or '\\*\\*' wildcards\n for matching.\n- *Do you have a Developer App?*\n\n The API Product must be bound to a Developer App to check its keys.\n- *Is Apigee API Product operationConfigType set to remoteservice?*\n\n Check the API Product configuration using the\n [Apigee Management API](/apigee/docs/reference/apis/apigee/rest/v1/organizations.apiproducts/get),\n and confirm that `operationConfigType` is set to `remoteservice`.\n\n#### Check your request\n\n- *Are you passing the Consumer Key in the `x-api-key header`*\n\n Example: \n\n ```\n curl http://localhost/hello -H \"x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo\"\n ```\n- *Are you using a good Consumer Key?*\n\n Ensure the Credentials from the App you're using are approved for your API Product.\n\n#### Check the Remote Service logs\n\n1. *Start the Remote Service with logging at the `debug level`. See [Setting remote service log levels](#settingremoteserviceloglevels).*\n\n Use `-l debug` option on the command line. For example: \n\n ```\n apigee-remote-service-envoy -l debug\n ```\n2. *Attempt to access your target and check the logs*\n\n Check the logs for a line that looks something like this: \n\n ```\n Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: []\n Selected: [helloworld]\n Eliminated: [helloworld2 doesn't match path: /hello]\n ```\n\nSetting remote service log levels\n---------------------------------\n\n\nUsing a command line flag, you can start the remote service in one of the following debug\nmodes, in order of verbosity, where `debug` is most verbose and `error` is least:\n\n- `debug` - The most verbose logging mode.\n- `info` - The default.\n- `warn`\n- `error` - Least verbose logging mode.\n\n\nFor example, to start the service at the `debug` level: \n\n```\napigee-remote-service-envoy -l debug\n```"]]
