[[["容易理解","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-03 (世界標準時間)。"],[[["\u003cp\u003eThis page provides guidance on debugging common issues when using Istio with Apigee or Apigee hybrid, specifically addressing 404 errors and problems related to API key and JWT validation.\u003c/p\u003e\n"],["\u003cp\u003eA frequent cause of 404 errors in Istio is the presence of multiple Gateway definitions using wildcard hosts, which require resolving the conflict by modifying or deleting one of the gateways.\u003c/p\u003e\n"],["\u003cp\u003eDebugging 404 errors in Istio involves a layered approach, beginning with verifying access to the backend workload from the sidecar and then progressing outward to the service, sidecar and gateway.\u003c/p\u003e\n"],["\u003cp\u003eIssues with missing analytics data in the Apigee UI can often be traced to delays in data intake, misconfigurations of Envoy's gRPC Access Log, or connectivity problems between Envoy and the Remote Service.\u003c/p\u003e\n"],["\u003cp\u003eIf API key or JWT validation is not working, solutions may include verifying the \u003ccode\u003eext-authz\u003c/code\u003e configuration, ensuring the Envoy JWT filter is configured, or confirming that API Products are correctly set up in Apigee.\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\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\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\n- *Start the Remote Service with logging at the `debug level`*\n\n Use `-l debug` option on the command line.\n- *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 ```"]]
