[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-05。"],[[["\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```"]]
