本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# App Mesh 疑難排解
**重要**
支援終止通知：在 2026 年 9 月 30 日， AWS 將停止對 的支援 AWS App Mesh。2026 年 9 月 30 日之後，您將無法再存取 AWS App Mesh 主控台或 AWS App Mesh 資源。如需詳細資訊，請參閱此部落格文章[從 遷移 AWS App Mesh 至 Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)。
本章討論使用 App Mesh 時可能遇到的疑難排解最佳實務和常見問題。選取下列其中一個領域，以檢閱該區域的最佳實務和常見問題。
**Topics**
+ [App Mesh 疑難排解最佳實務](troubleshooting-best-practices.md)
+ [App Mesh 設定疑難排解](troubleshooting-setup.md)
+ [App Mesh 連線疑難排解](troubleshooting-connectivity.md)
+ [App Mesh 擴展疑難排解](troubleshooting-scaling.md)
+ [App Mesh 可觀測性疑難排解](troubleshooting-observability.md)
+ [App Mesh 安全性疑難排解](troubleshooting-security.md)
+ [App Mesh Kubernetes 疑難排解](troubleshooting-kubernetes.md)
# App Mesh 疑難排解最佳實務
**重要**
支援終止通知：在 2026 年 9 月 30 日， AWS 將停止對 的支援 AWS App Mesh。2026 年 9 月 30 日之後，您將無法再存取 AWS App Mesh 主控台或 AWS App Mesh 資源。如需詳細資訊，請參閱此部落格文章[從 遷移 AWS App Mesh 至 Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)。
我們建議您遵循本主題的最佳實務，對使用 App Mesh 時的問題進行疑難排解。
## 啟用 Envoy 代理管理界面
Envoy 代理隨附管理介面，可用來探索組態和統計資料，以及執行連線耗盡等其他管理功能。如需詳細資訊，請參閱 Envoy 文件中的[管理界面](https://www.envoyproxy.io/docs/envoy/latest/operations/admin)。
如果您使用 受管 [Envoy 影像](envoy.md)，根據預設，管理端點會在連接埠 9901 上啟用。中的範例會將範例管理端點 URL [App Mesh 設定疑難排解](troubleshooting-setup.md)顯示為 `http://my-app.default.svc.cluster.local:9901/`。
**注意**
管理端點絕不應公開至公有網際網路。此外，我們建議監控管理端點日誌，該日誌由`ENVOY_ADMIN_ACCESS_LOG_FILE`環境變數`/tmp/envoy_admin_access.log`預設為 。
## 為指標卸載啟用 Envoy DogStatsD 整合
Envoy 代理可設定為卸載 OSI Layer 4 和 Layer 7 流量的統計資料，以及內部程序運作狀態的統計資料。雖然本主題說明如何使用這些統計資料，而不將指標卸載至 CloudWatch 指標和 Prometheus 等目的地。將這些統計資料集中於所有應用程式的集中位置，可協助您更快速診斷問題和確認行為。如需詳細資訊，請參閱[使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)和 [Prometheus 文件](https://prometheus.io/docs/introduction/overview/)。
您可以透過設定 中定義的參數來設定 DogStatsD 指標[DogStatsD 變數](envoy-config.md#envoy-dogstatsd-config)。如需 DogStatsD 的詳細資訊，請參閱 [DogStatsD](https://docs.datadoghq.com/developers/dogstatsd/?tab=hostagent) 文件。您可以在 GitHub 上的 [App Mesh with Amazon ECS 基本概念中](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-ecs-basics)，找到指標卸載至 AWS CloudWatch 指標的示範。
## 啟用存取日誌
建議您在 [虛擬節點](virtual_nodes.md)和 上啟用存取日誌[虛擬閘道](virtual_gateways.md)，以探索應用程式之間傳輸流量的詳細資訊。如需詳細資訊，請參閱 Envoy 文件中的[存取記錄](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/access_logging)。日誌提供有關 OSI Layer 4 和 Layer 7 流量行為的詳細資訊。當您使用 Envoy 的預設格式時，您可以使用下列剖析陳述式，使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 分析存取日誌。
```
parse @message "[*] \"* * *\" * * * * * * * * * * *" as StartTime, Method, Path, Protocol, ResponseCode, ResponseFlags, BytesReceived, BytesSent, DurationMillis, UpstreamServiceTimeMillis, ForwardedFor, UserAgent, RequestId, Authority, UpstreamHost
```
## 在生產前環境中啟用 Envoy 偵錯記錄
我們建議在生產`debug`前環境中將 Envoy 代理的日誌層級設定為 。偵錯日誌可協助您在將相關聯的 App Mesh 組態完成至生產環境之前識別問題。
如果您使用的是 [Envoy 映像](envoy.md)，您可以透過`ENVOY_LOG_LEVEL`環境變數將日誌層級設定為 `debug` 。
**注意**
我們不建議在生產環境中使用 `debug`關卡。將層級設定為 可`debug`增加記錄，並可能影響效能，以及卸載至 [CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 等解決方案的日誌整體成本。
當您使用 Envoy 的預設格式時，您可以使用下列剖析陳述式，使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 分析程序日誌：
```
parse @message "[*][*][*][*] [*] *" as Time, Thread, Level, Name, Source, Message
```
## 使用 App Mesh 控制平面監控 Envoy Proxy Connectivity
我們建議您監控 Envoy 指標，`control_plane.connected_state`以確保 Envoy 代理與 App Mesh 控制平面通訊，以擷取動態組態資源。如需詳細資訊，請參閱 [Management Server](https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/mgmt_server.html)。
# App Mesh 設定疑難排解
**重要**
支援終止通知：在 2026 年 9 月 30 日， AWS 將停止對 的支援 AWS App Mesh。2026 年 9 月 30 日之後，您將無法再存取 AWS App Mesh 主控台或 AWS App Mesh 資源。如需詳細資訊，請參閱此部落格文章[從 遷移 AWS App Mesh 至 Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)。
本主題詳細說明您在 App Mesh 設定時可能遇到的常見問題。
## 無法提取 Envoy 容器映像
**徵狀**
您在 Amazon ECS 任務中收到下列錯誤訊息。以下訊息中的 Amazon ECR *帳戶 ID* 和*區域*可能不同，具體取決於您提取容器映像的 Amazon ECR 儲存庫。
```
CannotPullContainerError: Error response from daemon: pull access denied for 840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy, repository does not exist or may require 'docker login'
```
**Resolution**
此錯誤表示正在使用的任務執行角色沒有與 Amazon ECR 通訊的許可，而且無法從儲存庫提取 Envoy 容器映像。指派給 Amazon ECS 任務的任務執行角色需要具有下列陳述式的 IAM 政策：
```
{
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage"
],
"Resource": "arn:aws:ecr:us-west-2:111122223333:repository/aws-appmesh-envoy",
"Effect": "Allow"
},
{
"Action": "ecr:GetAuthorizationToken",
"Resource": "*",
"Effect": "Allow"
}
```
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 無法連線至 App Mesh Envoy 管理服務
**徵狀**
您的 Envoy 代理無法連線至 App Mesh Envoy 管理服務。您會看到：
+ 連線遭拒錯誤
+ 連線逾時。
+ 解決 App Mesh Envoy 管理服務端點的錯誤
+ gRPC 錯誤
**Resolution**
請確定您的 Envoy 代理可存取網際網路或私有 [VPC 端點](vpc-endpoints.md)，而且您的[安全群組](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_SecurityGroups.html)允許連接埠 443 上的傳出流量。App Mesh 的公有 Envoy 管理服務端點遵循完整網域名稱 (FQDN) 格式。
```
# App Mesh Production Endpoint
appmesh-envoy-management.Region-code.amazonaws.com
# App Mesh Preview Endpoint
appmesh-preview-envoy-management.Region-code.amazonaws.com
```
您可以使用以下命令對 EMS 的連線進行偵錯。這會將有效但空白的 gRPC 請求傳送至 Envoy Management Service。
```
curl -v -k -H 'Content-Type: application/grpc' -X POST https://appmesh-envoy-management.Region-code.amazonaws.com:443/envoy.service.discovery.v3.AggregatedDiscoveryService/StreamAggregatedResources
```
如果您收到這些訊息，則與 Envoy Management Service 的連線會正常運作。如需偵錯 gRPC 相關錯誤，請參閱 [Envoy 中與 App Mesh Envoy 管理服務中斷連線的錯誤與錯誤文字。](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes)
```
grpc-status: 16
grpc-message: Missing Authentication Token
```
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## Envoy 已中斷與 App Mesh Envoy 管理服務的連線，並顯示錯誤文字
**徵狀**
您的 Envoy 代理無法連線至 App Mesh Envoy 管理服務並接收其組態。您的 Envoy 代理日誌包含如下所示的日誌項目。
```
gRPC config stream closed: gRPC status code, message
```
**Resolution**
在大多數情況下，日誌的訊息部分應指出問題。下表列出您可能會看到的最常見 gRPC 狀態碼、其原因及其解析度。
| gRPC 狀態碼 | 原因 | Resolution |
| --- | --- | --- |
| 0 | 優雅中斷與 Envoy 管理服務的連線。 | 沒有問題。App Mesh 偶爾會中斷 Envoy 代理與此狀態碼的連線。Envoy 會重新連線並繼續接收更新。 |
| 3 | 找不到網格端點 （虛擬節點或虛擬閘道） 或其關聯資源之一。 | 再次檢查您的 Envoy 組態，以確保它具有其代表的 App Mesh 資源的適當名稱。如果您的 App Mesh 資源與其他 AWS 資源整合，例如 AWS Cloud Map 命名空間或 ACM 憑證，請確定這些資源存在。 |
| 7 | Envoy 代理未經授權執行動作，例如連線至 Envoy 管理服務，或擷取相關聯的資源。 | 請務必[建立具有 App Mesh 和其他 服務適當政策陳述式的 IAM 政策](proxy-authorization.md#create-iam-policy)，並將該政策連接至 Envoy 代理用來連線至 Envoy 管理服務的 IAM 使用者或角色。 |
| 8 | 指定 App Mesh 資源的 Envoy 代理程式數目超過帳戶層級服務配額。 | [App Mesh 服務配額](service-quotas.md) 如需預設帳戶配額以及如何請求提高配額的資訊，請參閱 。 |
| 16 | Envoy 代理沒有 的有效身分驗證憑證 AWS。 | 請確定 Envoy 具有適當的登入資料，可透過 IAM 使用者或角色連線至 AWS 服務。如果 Envoy 程序透過1024檔案描述項使用 ，則在 Envoy 版本 v1.24和 之前的 中，已知問題 \$1[24136](https://github.com/envoyproxy/envoy/issues/24136) 無法擷取登入資料。當 Envoy 提供高流量時，就會發生這種情況。您可以在文字「A libcurl function was given a bad argument」的偵錯層級檢查 Envoy 日誌，以確認此問題。若要緩解此問題，請升級至 Envoy 版本 v1.25.1.0-prod 或更新版本。 |
您可以使用下列查詢，透過 [Amazon CloudWatch Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 觀察來自 Envoy 代理的狀態碼和訊息：
```
filter @message like /gRPC config stream closed/
| parse @message "gRPC config stream closed: *, *" as StatusCode, Message
```
如果提供的錯誤訊息沒有幫助，或者您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)。
## Envoy 容器運作狀態檢查、準備程度探查或上線探查失敗
**徵狀**
您的 Envoy 代理在 Amazon ECS 任務、Amazon EC2 執行個體或 Kubernetes Pod 中運作狀態檢查失敗。例如，您可以使用下列命令查詢 Envoy 管理界面，並接收 以外的狀態`LIVE`。
```
curl -s http://my-app.default.svc.cluster.local:9901/server_info | jq '.state'
```
**Resolution**
以下是修復步驟的清單，取決於 Envoy 代理傳回的狀態。
+ `PRE_INITIALIZING` 或 `INITIALIZING` – Envoy 代理尚未接收組態，或無法從 App Mesh Envoy 管理服務連接和擷取組態。嘗試連線時，Envoy 可能會收到來自 Envoy 管理服務的錯誤。如需詳細資訊，請參閱 中的錯誤[Envoy 已中斷與 App Mesh Envoy 管理服務的連線，並顯示錯誤文字](#ts-setup-grpc-error-codes)。
+ `DRAINING` – Envoy 代理已開始耗盡連線，以回應 Envoy 管理介面上的 `/healthcheck/fail`或 `/drain_listeners`請求。除非您即將終止 Amazon ECS 任務、Amazon EC2 執行個體或 Kubernetes Pod，否則不建議在管理界面上叫用這些路徑。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 從負載平衡器到網格端點的運作狀態檢查失敗
**徵狀**
容器運作狀態檢查或整備探查會將您的網格端點視為正常運作，但從負載平衡器到網格端點的運作狀態檢查失敗。
**Resolution**
若要解決問題，請完成下列任務。
+ 確定與網格端點相關聯的[安全群組](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)接受您為運作狀態檢查設定的連接埠上的傳入流量。
+ 手動請求時，請確定運作狀態檢查持續成功；例如，來自 [VPC 中的堡壘主機](https://aws.amazon.com/quickstart/architecture/linux-bastion/)。
+ 如果您要為虛擬節點設定運作狀態檢查，建議您在應用程式中實作運作狀態檢查端點，例如 /ping for HTTP。這可確保 Envoy 代理和您的應用程式都可以從負載平衡器路由。
+ 您可以根據所需的功能，為虛擬節點使用任何彈性負載平衡器類型。如需詳細資訊，請參閱 [Elastic Load Balancing 功能](https://aws.amazon.com/elasticloadbalancing/features/#compare)。
+ 如果您要設定[虛擬閘道](virtual_gateways.md)的運作狀態檢查，建議您在虛擬閘道的接聽程式連接埠上使用具有 TCP 或 TLS 運作狀態檢查[的網路負載平衡](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html)器。這可確保虛擬閘道接聽程式已引導並準備好接受連線。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 虛擬閘道不接受連接埠 1024 或更少的流量
**徵狀**
您的虛擬閘道不接受連接埠 1024 或更少的流量，但接受連接埠號碼大於 1024 的流量。例如，您可以使用下列命令查詢 Envoy 統計資料，並接收零以外的值。
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "update_rejected"
```
您可能會在日誌中看到類似下列文字的文字，說明無法繫結至特權連接埠：
```
gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) lds_ingress_0.0.0.0_port_: cannot bind '0.0.0.0:': Permission denied
```
**Resolution**
若要解決問題，為閘道指定的使用者需要具有 linux 功能 `CAP_NET_BIND_SERVICE`。如需詳細資訊，請參閱 Linux 程式設計人員手冊中的[功能](https://www.man7.org/linux/man-pages/man7/capabilities.7.html)、ECS 任務定義[參數中的 Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_linuxparameters) 參數，以及 Kubernetes 文件中的[設定容器的功能](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container)。
**重要**
Fargate 必須使用大於 1024 的連接埠值。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
# App Mesh 連線疑難排解
**重要**
支援終止通知：2026 年 9 月 30 日， AWS 將停止支援 AWS App Mesh。2026 年 9 月 30 日之後，您將無法再存取 AWS App Mesh 主控台或 AWS App Mesh 資源。如需詳細資訊，請參閱此部落格文章[從 遷移 AWS App Mesh 至 Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)。
本主題詳細說明您使用 App Mesh 連線時可能遇到的常見問題。
## 無法解析虛擬服務的 DNS 名稱
**徵狀**
您的應用程式無法解析其嘗試連線之虛擬服務的 DNS 名稱。
**Resolution**
這是已知問題。如需詳細資訊，請參閱[依任何主機名稱命名 VirtualServices 或 FQDN](https://github.com/aws/aws-app-mesh-roadmap/issues/65) GitHub 問題。App Mesh 中的虛擬服務可以命名為任何項目。只要有虛擬服務名稱的 DNS `A`記錄，且應用程式可以解析虛擬服務名稱，請求將由 Envoy 代理並路由至其適當的目的地。若要解決問題，請將 DNS `A`記錄新增至`10.10.10.10`虛擬服務名稱的任何非傳回 IP 地址，例如 。DNS `A`記錄可在下列條件下新增：
+ 在 Amazon Route 53 中，如果名稱後面加上您的私有託管區域名稱
+ 在應用程式容器的 `/etc/hosts` 檔案中
+ 在您管理的第三方 DNS 伺服器中
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 無法連線至虛擬服務後端
**徵狀**
您的應用程式無法與虛擬節點上定義為後端的虛擬服務建立連線。嘗試建立連線時，連線可能會完全失敗，或者來自應用程式觀點的請求可能會透過`HTTP 503`回應碼失敗。
**Resolution**
如果應用程式完全無法連線 （未傳回`HTTP 503`回應碼），請執行下列動作：
+ 請確定您的運算環境已設定為使用 App Mesh。
+ 對於 Amazon ECS，請確定您已啟用適當的[代理組態](proxy-authorization.md)。如需end-to-end逐步解說，請參閱 [App Mesh 和 Amazon ECS 入門](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/appmesh-getting-started.html)。
+ 對於 Kubernetes，包括 Amazon EKS，請確定您已透過 Helm 安裝最新的 App Mesh 控制器。如需詳細資訊，請參閱 Helm Hub 上的 [App Mesh 控制器](https://hub.helm.sh/charts/aws/appmesh-controller)或[教學課程：設定 App Mesh 與 Kubernetes 的整合](https://docs.aws.amazon.com/app-mesh/latest/userguide/mesh-k8s-integration.html)。
+ 對於 Amazon EC2，請確定您已設定 Amazon EC2 執行個體來代理 App Mesh 流量。如需詳細資訊，請參閱[更新服務](https://docs.aws.amazon.com/app-mesh/latest/userguide/appmesh-getting-started.html#update-services)。
+ 請確定在運算服務上執行的 Envoy 容器已成功連線至 App Mesh Envoy 管理服務。您可以檢查欄位 的 Envoy 統計資料來確認。 `control_plane.connected_state`如需 的詳細資訊`control_plane.connected_state`，請參閱 **疑難排解最佳實務**中的[監控 Envoy Proxy 連線](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-best-practices.html#ts-bp-enable-envoy-control-plane-connected-state)。
如果 Envoy 最初能夠建立連線，但之後中斷連線且從未重新連線，請參閱 [Envoy 中斷與 App Mesh Envoy 管理服務的連線，其中包含錯誤文字](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes)，以疑難排解中斷連線的原因。
如果應用程式已連線，但請求失敗並顯示`HTTP 503`回應碼，請嘗試下列動作：
+ 請確定您連線的虛擬服務存在於網格中。
+ 確定虛擬服務有提供者 （虛擬路由器或虛擬節點）。
+ 使用 Envoy 做為 HTTP Proxy 時，如果您看到輸出流量透過 Envoy 統計資料傳入，`cluster.cds_egress_*_mesh-allow-all`而不是正確的目的地，則很可能 Envoy 未透過 正確路由請求`filter_chains`。這可能是使用不合格虛擬服務名稱的結果。我們建議您使用實際服務的服務探索名稱做為虛擬服務名稱，因為 Envoy 代理會透過其名稱與其他虛擬服務通訊。
如需詳細資訊，請參閱[虛擬服務](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_services.html)。
+ 檢查 Envoy 代理日誌是否有任何下列錯誤訊息：
+ `No healthy upstream` – Envoy 代理嘗試路由至 的虛擬節點沒有任何已解析的端點，或沒有任何運作狀態良好的端點。確定目標虛擬節點具有正確的服務探索和運作狀態檢查設定。
如果在部署或擴展後端虛擬服務期間，對服務的請求失敗，請遵循 中的指引[當虛擬服務有虛擬節點提供者`503`時，某些請求會失敗並顯示 HTTP 狀態碼](#ts-connectivity-virtual-node-provider)。
+ `No cluster match for URL` – 當請求傳送至不符合虛擬路由器供應商定義之任何路由所定義條件的虛擬服務時，最可能發生這種情況。確保路徑和 HTTP 請求標頭正確，以確保來自應用程式的請求傳送到支援的路由。
+ `No matching filter chain found` – 當請求傳送到無效連接埠上的虛擬服務時，最可能發生這種情況。確定來自應用程式的請求使用虛擬路由器上指定的相同連接埠。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 無法連線至外部服務
**徵狀**
您的應用程式無法連線到網格外的服務，例如 `amazon.com`。
**Resolution**
根據預設，App Mesh 不允許從網格內應用程式到網格外任何目的地的傳出流量。若要啟用與外部服務的通訊，有兩個選項：
+ 將網格資源上的[傳出篩選條件](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html)設定為 `ALLOW_ALL`。此設定將允許網格內的任何應用程式與網格內外的任何目的地 IP 地址通訊。
+ 使用虛擬服務、虛擬路由器、路由和虛擬節點建立網格中的外部服務模型。例如，若要建立外部服務 的模型`example.com`，您可以使用虛擬路由器建立名為 `example.com`的虛擬服務，並將所有流量傳送到具有 DNS 服務探索主機名稱 的虛擬節點`example.com`。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 無法連線至 MySQL 或 SMTP 伺服器
**徵狀**
允許傳出流量到所有目的地 (Mesh `EgressFilter type`=`ALLOW_ALL`) 時，例如使用虛擬節點定義的 SMTP 伺服器或 MySQL 資料庫，來自應用程式的連線會失敗。例如，以下是嘗試連線至 MySQL 伺服器的錯誤訊息。
```
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
```
**Resolution**
這是使用 App Mesh 映像 1.15.0 版或更新版本解決的已知問題。如需詳細資訊，請參閱[無法使用 App Mesh GitHub 連線至 MySQL ](https://github.com/aws/aws-app-mesh-roadmap/issues/62) 問題。 GitHub 發生此錯誤是因為 App Mesh 在 Envoy 中設定的傳出接聽程式新增 Envoy TLS Inspector 接聽程式篩選條件。如需詳細資訊，請參閱 Envoy 文件中的 [TLS Inspector](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/tls_inspector#config-listener-filters-tls-inspector)。此篩選條件會檢查從用戶端傳送的第一個封包，評估連線是否使用 TLS。不過，使用 MySQL 和 SMTP，伺服器會在連線後傳送第一個封包。如需 MySQL 的詳細資訊，請參閱 MySQL 文件中的[初始交握](https://dev.mysql.com/doc/internals/en/initial-handshake.html)。由於伺服器會傳送第一個封包，因此篩選條件的檢查會失敗。
**根據您的 Envoy 版本來解決此問題：**
+ 如果您的 App Mesh 映像 Envoy 版本為 1.15.0 或更新版本，請勿將 **MySQL**、**SMTP**、**MSSQL** 等外部服務建模為應用程式的虛擬節點後端。
+ 如果您的 App Mesh 映像 Envoy 版本早於 1.15.0，`3306`請將連接埠新增至 **MySQL** 服務`APPMESH_EGRESS_IGNORED_PORTS`中 的值清單，並做為您用於 **STMP** 的連接埠。
**重要**
雖然標準 SMTP 連接埠是 `25`、 `587`和 `465`，但您應該只將您正在使用的連接埠新增至 `APPMESH_EGRESS_IGNORED_PORTS`，而不是全部三個連接埠。
如需詳細資訊，請參閱[更新 Kubernetes 的服務](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-kubernetes.html#create-update-services)、[更新 Amazon ECS 的服務](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ecs.html#update-services)或[更新 Amazon EC2 的服務](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ec2.html#update-services)。 Amazon EC2
如果您的問題仍未解決，您可以提供我們使用現有 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/62)時所遇到情況的詳細資訊，或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 無法連線至 App Mesh 中建模為 TCP 虛擬節點或虛擬路由器的服務
**徵狀**
您的應用程式無法連線至使用 App Mesh [PortMapping](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_PortMapping.html) 定義中 TCP 通訊協定設定的後端。
**Resolution**
這是已知問題。如需詳細資訊，請參閱 GitHub [上相同連接埠上的路由至多個 TCP 目的地](https://github.com/aws/aws-app-mesh-roadmap/issues/195)。由於 OSI Layer 4 提供給 Envoy 代理的資訊有所限制，App Mesh 目前不允許多個建模為 TCP 的後端目的地共用相同的連接埠。為了確保 TCP 流量可以針對所有後端目的地適當路由，請執行下列動作：
+ 確定所有目的地都使用唯一的連接埠。如果您使用後端虛擬服務的虛擬路由器供應商，您可以變更虛擬路由器連接埠，而無需變更其路由之虛擬節點上的連接埠。這可讓應用程式在 Envoy 代理繼續使用虛擬節點中定義的連接埠時，在虛擬路由器連接埠上開啟連線。
+ 如果建模為 TCP 的目的地是 MySQL 伺服器，或伺服器在連線後傳送第一個封包的任何其他 TCP 型通訊協定，請參閱 [無法連線至 MySQL 或 SMTP 伺服器](#ts-connectivity-troubleshooting-mysql-and-smtp)。
如果您的問題仍未解決，您可以提供我們使用現有 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/195)時所遇到情況的詳細資訊，或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 連線成功連線到未列為虛擬節點虛擬服務後端的服務
**徵狀**
您的應用程式可以連接和傳送流量到未指定為虛擬節點上虛擬服務後端的目的地。
**Resolution**
如果請求成功到達未在 App Mesh APIs 中建模的目的地，則最可能的原因是網格的[傳出篩選條件](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html)類型已設定為 `ALLOW_ALL`。當傳出篩選條件設定為 時`ALLOW_ALL`，來自您應用程式的傳出請求與模型化目的地 （後端） 不相符，將會傳送至應用程式設定的目的地 IP 地址。
如果您想要不允許流量到未在網格中建模的目的地，請考慮將傳出篩選條件值設定為 `DROP_ALL`。
**注意**
設定網格傳出篩選條件值會影響網格內的所有虛擬節點。
將 `egress_filter`設定為 `DROP_ALL`並啟用 TLS 不適用於非 AWS 網域的傳出流量。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 當虛擬服務有虛擬節點提供者`503`時，某些請求會失敗並顯示 HTTP 狀態碼
**徵狀**
您應用程式的一部分請求失敗到使用虛擬節點提供者而非虛擬路由器提供者的虛擬服務後端。為虛擬服務使用虛擬路由器供應商時，請求不會失敗。
**Resolution**
這是已知問題。如需詳細資訊，請參閱 GitHub [上虛擬服務虛擬節點提供者的重試政策](https://github.com/aws/aws-app-mesh-roadmap/issues/194)。使用虛擬節點做為虛擬服務的提供者時，您無法指定虛擬服務的用戶端要使用的預設重試政策。相比之下，虛擬路由器供應商允許指定重試政策，因為它們是子路由資源的屬性。
若要減少虛擬節點供應商的請求失敗，請改用虛擬路由器供應商，並在其路由上指定重試政策。如需減少應用程式請求失敗的其他方法，請參閱 [App Mesh 最佳實務](best-practices.md)。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 無法連線至 Amazon EFS 檔案系統
**徵狀**
使用 Amazon EFS 檔案系統將 Amazon ECS 任務設定為磁碟區時，任務無法以下列錯誤開始。
```
ResourceInitializationError: failed to invoke EFS utils commands to set up EFS volumes: stderr: mount.nfs4: Connection refused : unsuccessful EFS utils command execution; code: 32
```
**Resolution**
這是已知問題。發生此錯誤是因為 NFS 與 Amazon EFS 的連線會在任務中的任何容器啟動之前發生。此流量由代理組態路由至 Envoy，目前不會執行。由於啟動順序，NFS 用戶端無法連線至 Amazon EFS 檔案系統，且任務無法啟動。若要解決問題，請將連接埠新增至 `2049` Amazon ECS 任務定義之代理組態中 `EgressIgnoredPorts`設定的值清單。如需詳細資訊，請參閱 [Proxy 組態](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#proxyConfiguration)。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 連線服務成功，但傳入的請求不會出現在 Envoy 的存取日誌、追蹤或指標中
**徵狀**
即使您的應用程式可以連線並傳送請求到另一個應用程式，您也無法在存取日誌中看到傳入的請求，或在 Envoy 代理的追蹤資訊中看到。
**Resolution**
這是已知問題。如需詳細資訊，請參閱 Github 上的 [iptables 規則設定](https://github.com/aws/aws-app-mesh-roadmap/issues/166)問題。Envoy 代理只會攔截其對應虛擬節點接聽之連接埠的傳入流量。對任何其他連接埠的請求會略過 Envoy 代理，並直接連線到其後方的服務。為了讓 Envoy 代理攔截服務的傳入流量，您需要將虛擬節點和服務設定為在相同的連接埠上接聽。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 在容器層級設定 `HTTP_PROXY`/`HTTPS_PROXY` 環境變數無法如預期運作。
**徵狀**
當 HTTP\$1PROXY/HTTPS\$1PROXY 在 設定為環境變數時：
+ 任務定義中已啟用 App Mesh 的應用程式容器，傳送至 App Mesh 服務命名空間的請求會從 Envoy 附屬取得`HTTP 500`錯誤回應。
+ 啟用 App Mesh 的任務定義中的 Envoy 容器、來自 Envoy 附屬的請求將不會通過 `HTTP`/`HTTPS` 代理伺服器，且環境變數將無法運作。
**Resolution**
對於應用程式容器：
App Mesh 函數透過讓任務中的流量通過 Envoy 代理。 `HTTP_PROXY`/`HTTPS_PROXY` 組態透過設定容器流量以通過不同的外部代理來覆寫此行為。Envoy 仍會攔截流量，但不支援使用外部代理代理來代理網格流量。
如果您想要代理所有非網格流量，請將 `NO_PROXY` 設定為包含網格的 CIDR/命名空間、localhost 和登入資料的端點，如下列範例所示。
```
NO_PROXY=localhost,127.0.0.1,169.254.169.254,169.254.170.2,10.0.0.0/16
```
對於 Envoy 容器：
Envoy 不支援一般代理。我們不建議設定這些變數。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 即使在設定路由的逾時之後，上游請求也會逾時。
**徵狀**
您已定義 的逾時：
+ 路由，但您仍然收到上游請求逾時錯誤。
+ 虛擬節點接聽程式、逾時和路由的重試逾時，但您仍然收到上游請求逾時錯誤。
**Resolution**
若要讓超過 15 秒的高延遲請求成功完成，您需要在路由和虛擬節點接聽程式層級指定逾時。
如果您指定的路由逾時大於預設的 15 秒，請確定也會為所有參與虛擬節點的接聽程式指定逾時。不過，如果您將逾時減少到低於預設值的值，您可以選擇更新虛擬節點的逾時。如需設定虛擬節點和路由時選項的詳細資訊，請參閱[虛擬節點](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html)和[路由](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html)。
如果您指定**了重試政策**，您為請求逾時指定的持續時間應始終大於或等於*重試逾時*乘以您在**重試政策**中定義的*重試次數上限*。這可讓您的所有重試請求成功完成。如需詳細資訊，請參閱[路由](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html)。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## Envoy 回應 HTTP 錯誤請求。
**徵狀**
Envoy 會對透過 Network Load Balancer (NLB) 傳送的所有請求回應 **HTTP 400 錯誤請求**。檢查 Envoy 日誌時，我們會看到：
+ 偵錯日誌：
```
dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD
```
+ 存取日誌：
```
"- - HTTP/1.1" 400 DPE 0 11 0 - "-" "-" "-" "-" "-"
```
**Resolution**
解決方法是停用 NLB [目標群組屬性](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-attributes)上的代理通訊協定第 2 版 (PPv2)。
目前，使用 App Mesh 控制平面執行的虛擬閘道和虛擬節點 Envoy 不支援 PPv2。如果您在 Kubernetes 上使用 AWS 負載平衡器控制器部署 NLB，請將下列屬性設定為 來停用 PPv2`false`：
```
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled
```
如需 NLB 資源屬性的詳細資訊，請參閱[AWS Load Balancer控制器註釋](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#resource-attributestrue)。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 無法正確設定逾時。
**徵狀**
即使在虛擬節點接聽程式上設定逾時，以及在通往虛擬節點後端的路由上設定逾時之後，您的請求也會在 15 秒內逾時。
**Resolution**
請確定後端清單包含正確的虛擬服務。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
# App Mesh 擴展疑難排解
**重要**
支援終止通知：2026 年 9 月 30 日， AWS 將停止支援 AWS App Mesh。2026 年 9 月 30 日之後，您將無法再存取 AWS App Mesh 主控台或 AWS App Mesh 資源。如需詳細資訊，請參閱此部落格文章[從 遷移 AWS App Mesh 至 Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)。
本主題詳細說明您在 App Mesh 擴展時可能遇到的常見問題。
## 虛擬節點/虛擬閘道擴展超過 50 個複本時，連線失敗且容器運作狀態檢查失敗
**徵狀**
當您為虛擬節點/虛擬閘道擴展 Amazon ECS 任務、Kubernetes Pod 或 Amazon EC2 執行個體等複本數量超過 50 時，Envoy 容器運作狀態檢查會開始失敗。傳送流量至虛擬節點/虛擬閘道的下游應用程式會開始看到 HTTP 狀態碼 的請求失敗`503`。
**Resolution**
App Mesh 每個虛擬節點/虛擬閘道的 Envoy 數量的預設配額為 50。當執行中的 Envoys 數量超過此配額時，新的和目前正在執行的 Envoys 無法以 gRPC 狀態碼 `8`() 連線至 App Mesh 的 Envoy 管理服務`RESOURCE_EXHAUSTED`。您可以提高此配額。如需詳細資訊，請參閱[App Mesh 服務配額](service-quotas.md)。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 當虛擬服務後端水平向外擴展或向內擴展`503`時，請求會失敗
**徵狀**
當後端虛擬服務水平向外擴展或向內擴展時，來自下游應用程式的請求會失敗，並顯示`HTTP 503`狀態碼。
**Resolution**
App Mesh 建議數種方法來緩解故障案例，同時水平擴展應用程式。如需如何防止這些失敗的詳細資訊，請參閱 [App Mesh 最佳實務](best-practices.md)。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 在負載增加的情況下，Envoy 容器因隔離故障而當機
**徵狀**
在高流量負載下，Envoy 代理會因為分段錯誤 (Linux 結束碼 ) 而當機`139`。Envoy 程序日誌包含如下所示的陳述式。
```
Caught Segmentation fault, suspect faulting address 0x0"
```
**Resolution**
Envoy 代理可能已違反作業系統的預設 nofile ulimit，即程序一次可以開啟的檔案數量限制。此違規是由於流量導致更多連線，這會消耗額外的作業系統通訊端。若要解決此問題，請增加主機作業系統上的 ulimit nofile 值。如果您使用的是 Amazon ECS，可以透過任務定義的資源限制[設定上的 Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) 設定來變更此限制。 [https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits)
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 預設資源的增加不會反映在服務限制中
**徵狀**
增加 App Mesh 資源的預設限制後，當您查看服務限制時，不會反映新值。
**Resolution**
雖然目前未顯示新的限制，但客戶仍然可以執行這些限制。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 應用程式因為大量的運作狀態檢查呼叫而當機。
**徵狀**
啟用虛擬節點的作用中運作狀態檢查後，運作狀態檢查呼叫的數量會增加。應用程式由於對應用程式進行的運作狀態檢查呼叫量大幅增加而當機。
**Resolution**
啟用作用中運作狀態檢查時，下游 （用戶端） 的每個 Envoy 端點都會將運作狀態請求傳送至上游叢集 （伺服器） 的每個端點，以做出路由決策。因此，運作狀態檢查請求的總數為 `number of client Envoys` \$1 `number of server Envoys` \$1 `active health check frequency`。
若要解決此問題，請修改運作狀態檢查探查的頻率，這會降低運作狀態檢查探查的總量。除了主動運作狀態檢查之外，App Mesh 允許將[極端值偵測](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_OutlierDetection.html)設定為被動運作狀態檢查的方法。使用極端值偵測來設定何時根據連續`5xx`回應移除特定主機。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
# App Mesh 可觀測性疑難排解
**重要**
支援終止通知：2026 年 9 月 30 日， AWS 將停止支援 AWS App Mesh。2026 年 9 月 30 日之後，您將無法再存取 AWS App Mesh 主控台或 AWS App Mesh 資源。如需詳細資訊，請參閱此部落格文章[從 遷移 AWS App Mesh 至 Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)。
本主題詳細說明您在 App Mesh 可觀測性方面可能遇到的常見問題。
## 看不到我的應用程式的 AWS X-Ray 追蹤
**徵狀**
App Mesh 中的應用程式不會在 X-Ray 主控台或 APIs 中顯示 X-Ray 追蹤資訊。
**Resolution**
若要在 App Mesh 中使用 X-Ray，您必須正確設定元件，以啟用應用程式、附屬容器和 X-Ray 服務之間的通訊。採取下列步驟來確認 X-Ray 已正確設定：
+ 確定 App Mesh Virtual Node 接聽程式通訊協定未設定為 `TCP`。
+ 請確定與應用程式一起部署的 X-Ray 容器公開 UDP 連接埠`2000`並以使用者 身分執行`1337`。如需詳細資訊，請參閱 GitHub 上的 [Amazon ECS X-Ray 範例](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/howto-ecs-basics/deploy/2-meshify.yaml#L374-L386)。
+ 確定 Envoy 容器已啟用追蹤。如果您使用的是 [App Mesh Envoy 映像](envoy.md)，您可以將`ENABLE_ENVOY_XRAY_TRACING`環境變數設定為 的值`1`，並將`XRAY_DAEMON_PORT`環境變數設定為 ，以啟用 X-Ray`2000`。
+ 如果您已使用其中一種[語言特定的 SDKs ](https://docs.aws.amazon.com/xray/index.html)在應用程式程式碼中檢測 X-Ray，則請依照語言的指南來確保設定正確。
+ 如果先前所有項目都設定正確，請檢閱 X-Ray 容器日誌是否有錯誤，並遵循[故障診斷 AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-troubleshooting.html)中的指引。如需 App Mesh 中 X-Ray 整合的更詳細說明，請參閱[將 X-Ray 與 App Mesh 整合](https://aws.amazon.com/blogs/compute/integrating-aws-x-ray-with-aws-app-mesh/)。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 無法在 Amazon CloudWatch 指標中查看我應用程式的 Envoy 指標
**徵狀**
App Mesh 中的應用程式不會將 Envoy 代理產生的指標發出至 CloudWatch 指標。
**Resolution**
當您在 App Mesh 中使用 CloudWatch 指標時，必須正確設定數個元件，以啟用 Envoy 代理程式、CloudWatch 代理程式附屬和 CloudWatch 指標服務之間的通訊。執行下列步驟以確認 Envoy 代理的 CloudWatch 指標已正確設定：
+ 請確定您使用 App Mesh 的 CloudWatch 代理程式映像。如需詳細資訊，請參閱 GitHub 上的 [App Mesh CloudWatch 代理程式](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent)。
+ 請確定您已遵循平台特定的使用說明，適當地設定 App Mesh 的 CloudWatch 代理程式。如需詳細資訊，請參閱 GitHub 上的 [App Mesh CloudWatch 代理程式](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent#usage)。
+ 如果先前所有項目都設定正確，請檢閱 CloudWatch 代理程式容器日誌是否有錯誤，並遵循 [CloudWatch 代理程式疑難排解](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html)中提供的指引。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 無法設定 AWS X-Ray 追蹤的自訂取樣規則
**徵狀**
您的應用程式正在使用 X-Ray 追蹤，但您無法設定追蹤的取樣規則。
**Resolution**
由於 App Mesh Envoy 目前不支援**動態 X-Ray 取樣組態**，因此提供下列解決方法。
如果您的 Envoy 版本是 `1.19.1`或更新版本，您有下列選項。
+ 若要只設定取樣率，請使用 Envoy 容器上的 `XRAY_SAMPLING_RATE`環境變數。值應指定為介於 `0`和 `1.00`(100%) 之間的小數。如需詳細資訊，請參閱[AWS X-Ray 變數](envoy-config.md#envoy-xray-config)。
+ 若要設定 X-Ray 追蹤器的當地語系化自訂取樣規則，請使用 `XRAY_SAMPLING_RULE_MANIFEST`環境變數在 Envoy 容器檔案系統中指定檔案路徑。如需詳細資訊，請參閱《 *AWS X-Ray 開發人員指南*》中的[取樣規則](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling)。
如果您的 Envoy 版本早於 `1.19.1`，請執行下列動作。
+ 使用 `ENVOY_TRACING_CFG_FILE`環境變數來變更您的取樣率。如需詳細資訊，請參閱[Envoy 組態變數](envoy-config.md)。指定自訂追蹤組態並定義本機取樣規則。如需詳細資訊，請參閱 [Envoy X-Ray 組態](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/trace/v3/xray.proto.html#config-trace-v3-xrayconfig)。
+ `ENVOY_TRACING_CFG_FILE` 環境變數範例的自訂追蹤組態：
```
tracing:
http:
name: envoy.tracers.xray
typedConfig:
"@type": type.googleapis.com/envoy.config.trace.v3.XRayConfig
segmentName: foo/bar
segmentFields:
origin: AWS::AppMesh::Proxy
aws:
app_mesh:
mesh_name: foo
virtual_node_name: bar
daemonEndpoint:
protocol: UDP
address: 127.0.0.1
portValue: 2000
samplingRuleManifest:
filename: /tmp/sampling-rules.json
```
+ 如需 `samplingRuleManifest` 屬性中取樣規則資訊清單組態的詳細資訊，請參閱[設定適用於 Go 的 X-Ray 開發套件](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling)。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
# App Mesh 安全性疑難排解
**重要**
支援終止通知：2026 年 9 月 30 日， AWS 將停止支援 AWS App Mesh。2026 年 9 月 30 日之後，您將無法再存取 AWS App Mesh 主控台或 AWS App Mesh 資源。如需詳細資訊，請參閱此部落格文章[從 遷移 AWS App Mesh 至 Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)。
本主題詳細說明您使用 App Mesh 安全性時可能遇到的常見問題。
## 無法使用 TLS 用戶端政策連線至後端虛擬服務
**徵狀**
將 TLS 用戶端政策新增至虛擬節點中的虛擬服務後端時，與該後端的連線會失敗。嘗試將流量傳送至後端服務時，請求會失敗，並顯示`HTTP 503`回應代碼和錯誤訊息：`upstream connect error or disconnect/reset before headers. reset reason: connection failure`。
**Resolution**
為了判斷問題的根本原因，我們建議您使用 Envoy 代理程序日誌來協助您診斷問題。如需詳細資訊，請參閱[在生產前環境中啟用 Envoy 偵錯記錄](troubleshooting-best-practices.md#ts-bp-enable-envoy-debug-logging)。使用下列清單來判斷連線失敗的原因：
+ 透過排除 中提到的錯誤，確保後端連線成功[無法連線至虛擬服務後端](troubleshooting-connectivity.md#ts-connectivity-virtual-service-backend)。
+ 在 Envoy 程序日誌中，尋找下列錯誤 （在偵錯層級記錄）。
```
TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
```
此錯誤是由下列一或多個原因所造成：
+ 憑證並未由 TLS 用戶端政策信任套件中定義的其中一個憑證授權單位簽署。
+ 憑證不再有效 （已過期）。
+ 主體別名 (SAN) 不符合請求的 DNS 主機名稱。
+ 請確定後端服務提供的憑證有效，並由 TLS 用戶端政策信任套件中的其中一個憑證授權單位簽署，且符合 中定義的條件[Transport Layer Security (TLS)](tls.md)。
+ 如果您收到的錯誤如下，則表示請求正在繞過 Envoy 代理並直接到達應用程式。傳送流量時，Envoy 上的統計資料不會變更，表示 Envoy 不在解密流量的路徑上。在虛擬節點的代理組態中，請確定 `AppPorts`包含應用程式正在接聽的正確值。
```
upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
```
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue-bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。如果您認為您找到安全漏洞或對 App Mesh 的安全性有任何疑問，請參閱[AWS 漏洞報告準則](https://aws.amazon.com/security/vulnerability-reporting/)。
## 當應用程式產生 TLS 時，無法連線至後端虛擬服務
**徵狀**
從應用程式而非 Envoy 代理產生 TLS 工作階段時，與後端虛擬服務的連線會失敗。
**Resolution**
這是已知問題。如需詳細資訊，請參閱[功能請求：下游應用程式與上游代理 GitHub 問題之間的 TLS 交涉](https://github.com/aws/aws-app-mesh-roadmap/issues/162)。 GitHub 在 App Mesh 中，目前支援來自 Envoy 代理的 TLS 起始，但不支援來自應用程式。若要在 Envoy 使用 TLS 起始支援，請在應用程式中停用 TLS 起始。這可讓 Envoy 讀取傳出請求標頭，並透過 TLS 工作階段將請求轉送至適當的目的地。如需詳細資訊，請參閱[Transport Layer Security (TLS)](tls.md)。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。如果您認為您找到安全漏洞或對 App Mesh 的安全性有任何疑問，請參閱[AWS 漏洞報告準則](https://aws.amazon.com/security/vulnerability-reporting/)。
## 無法宣告 Envoy 代理之間的連線正在使用 TLS
**徵狀**
您的應用程式已在虛擬節點或虛擬閘道接聽程式上啟用 TLS 終止，或在後端 TLS 用戶端政策上啟用 TLS 起始，但您無法宣告 Envoy 代理之間的連線是透過 TLS 交涉工作階段發生。
**Resolution**
此解析度中定義的步驟會使用 Envoy 管理界面和 Envoy 統計資料。如需設定這些項目的說明，請參閱 [啟用 Envoy 代理管理界面](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface)和 [為指標卸載啟用 Envoy DogStatsD 整合](troubleshooting-best-practices.md#ts-bp-enable-envoy-statsd-integration)。下列統計資料範例使用 管理界面以簡化操作。
+ 對於執行 TLS 終止的 Envoy 代理：
+ 請確定已使用下列命令在 Envoy 組態中引導 TLS 憑證。
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
在傳回的輸出中，您應該會看到 中至少一個用於 `certificates[].cert_chain` TLS 終止之憑證的項目。
+ 請確定與代理接聽程式的成功傳入連線數目與 SSL 交握數目加上重複使用的 SSL 工作階段數目完全相同，如下列範例命令和輸出所示。
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep downstream_cx_total
listener.0.0.0.0_15000.downstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.connection_error
listener.0.0.0.0_15000.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.handshake
listener.0.0.0.0_15000.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.session_reused
listener.0.0.0.0_15000.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
+ 對於執行 TLS 起始的 Envoy 代理：
+ 使用以下命令，確定已在 Envoy 組態中引導 TLS 信任存放區。
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
對於`certificates[].ca_certs`在 TLS 起始期間用於驗證後端憑證的憑證，您應該會在 中看到至少一個項目。
+ 請確定後端叢集的成功傳出連線數目與 SSL 交握數目加上重複使用的 SSL 工作階段數目完全相同，如下列範例命令和輸出所示。
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep upstream_cx_total
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.upstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.connection_error
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.handshake
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.session_reused
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。如果您認為您找到安全漏洞或對 App Mesh 的安全性有任何疑問，請參閱[AWS 漏洞報告準則](https://aws.amazon.com/security/vulnerability-reporting/)。
## 使用 Elastic Load Balancing 對 TLS 進行故障診斷
**徵狀**
嘗試設定 Application Load Balancer 或 Network Load Balancer 來加密虛擬節點的流量時，連線和負載平衡器運作狀態檢查可能會失敗。
**Resolution**
為了判斷問題的根本原因，您需要檢查下列項目：
+ 對於執行 TLS 終止的 Envoy 代理，您需要排除任何設定錯誤。請遵循 中上述提供的步驟[無法使用 TLS 用戶端政策連線至後端虛擬服務](#ts-security-tls-client-policy)。
+ 對於負載平衡器，您需要查看 的組態 `TargetGroup:`
+ 請確定`TargetGroup`連接埠符合虛擬節點定義的接聽程式連接埠。
+ 對於透過 HTTP 與您的服務產生 TLS 連線的 Application Load Balancer，請確定`TargetGroup`通訊協定設定為 `HTTPS`。如果正在使用運作狀態檢查，請確定 `HealthCheckProtocol` 設定為 `HTTPS`。
+ 對於透過 TCP 與您的服務產生 TLS 連線的網路負載平衡器，請確定`TargetGroup`通訊協定設定為 `TLS`。如果正在使用運作狀態檢查，請確定 `HealthCheckProtocol` 設定為 `TCP`。
**注意**
需要`TargetGroup`變更`TargetGroup`名稱的任何更新。
正確設定後，您的負載平衡器應使用提供給 Envoy 代理的憑證，提供安全的服務連線。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。如果您認為您找到安全漏洞或對 App Mesh 的安全性有任何疑問，請參閱[AWS 漏洞報告準則](https://aws.amazon.com/security/vulnerability-reporting/)。
# App Mesh Kubernetes 疑難排解
**重要**
支援終止通知：2026 年 9 月 30 日， AWS 將停止支援 AWS App Mesh。2026 年 9 月 30 日之後，您將無法再存取 AWS App Mesh 主控台或 AWS App Mesh 資源。如需詳細資訊，請參閱此部落格文章[從 遷移 AWS App Mesh 至 Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)。
本主題詳細說明當您搭配 Kubernetes 使用 App Mesh 時可能遇到的常見問題。
## 在 Kubernetes 中建立的 App Mesh 資源無法在 App Mesh 中找到
**徵狀**
您已使用 Kubernetes 自訂資源定義 (CRD) 建立 App Mesh 資源，但當您使用 AWS 管理主控台 或 APIs 時，您建立的資源不會顯示在 App Mesh 中。
**Resolution**
可能的原因是 App Mesh 的 Kubernetes 控制器發生錯誤。如需詳細資訊，請參閱 GitHub [上的故障診斷](https://github.com/aws/aws-app-mesh-controller-for-k8s/blob/master/docs/guide/troubleshooting.md)。檢查控制器日誌是否有任何錯誤或警告，指出控制器無法建立任何資源。
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller)
```
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 注入 Envoy 附屬裝置後，Pod 的整備和運作狀態檢查失敗
**徵狀**
您應用程式的 Pod 之前已成功執行，但在 Envoy 附屬插入 Pod 之後，準備和上線檢查會開始失敗。
**Resolution**
確定注入 Pod 的 Envoy 容器已使用 App Mesh 的 Envoy 管理服務引導。您可以參考 中的錯誤代碼來驗證任何錯誤[Envoy 已中斷與 App Mesh Envoy 管理服務的連線，並顯示錯誤文字](troubleshooting-setup.md#ts-setup-grpc-error-codes)。您可以使用下列命令來檢查相關 Pod 的 Envoy 日誌。
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller) \
| grep "gRPC config stream closed"
```
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## Pod 未註冊或取消註冊為 AWS Cloud Map 執行個體
**徵狀**
您的 Kubernetes Pod 在其 AWS Cloud Map 生命週期中並未在 中註冊或取消註冊。Pod 可能會成功啟動，並準備好為流量提供服務，但不會接收任何流量。當 Pod 終止時，用戶端仍然可以保留其 IP 地址，並嘗試傳送流量給它，但失敗。
**Resolution**
這是已知問題。如需詳細資訊，請參閱 [Pod 不會在具有 GitHub 問題的 Kubernetes 中自動註冊/取消註冊 AWS Cloud Map](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/159)。 GitHub 由於 Pod、App Mesh 虛擬節點和資源之間的關係 AWS Cloud Map ，適用於 [Kubernetes 的 App Mesh 控制器](https://github.com/aws/aws-app-mesh-controller-for-k8s)可能會取消同步並遺失資源。例如，如果在終止相關聯的 Pod 之前從 Kubernetes 刪除虛擬節點資源，就可能發生這種情況。
若要緩解此問題：
+ 請確定您正在執行適用於 Kubernetes 的 App Mesh 控制器最新版本。
+ 請確定虛擬節點定義中的 AWS Cloud Map `namespaceName`和 `serviceName` 正確無誤。
+ 刪除虛擬節點定義之前，請務必先刪除任何相關聯的 Pod。如果您需要協助識別哪些 Pod 與虛擬節點相關聯，請參閱 [無法判斷 App Mesh 資源的 Pod 正在執行的位置](#ts-kubernetes-where-pod-running)。
+ 如果您的問題仍然存在，請執行下列命令來檢查控制器日誌是否有錯誤，這些錯誤可能有助於顯示基礎問題。
```
kubectl logs -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
+ 請考慮使用下列命令來重新啟動控制器 Pod。這可能會修正同步問題。
```
kubectl delete -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 無法判斷 App Mesh 資源的 Pod 正在執行的位置
**徵狀**
當您在 Kubernetes 叢集上執行 App Mesh 時，運算子無法判斷工作負載或 Pod 為指定的 App Mesh 資源執行的位置。
**Resolution**
Kubernetes Pod 資源會使用與其相關聯的網格和虛擬節點進行註釋。您可以使用下列命令，查詢為指定虛擬節點名稱執行的 Pod。
```
kubectl get pods --all-namespaces -o json | \
jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'
```
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 無法判斷 Pod 執行的 App Mesh 資源
**徵狀**
在 Kubernetes 叢集上執行 App Mesh 時，運算子無法判斷指定 Pod 執行的 App Mesh 資源。
**Resolution**
Kubernetes Pod 資源會使用與其相關聯的網格和虛擬節點進行註釋。您可以使用下列命令直接查詢 Pod，以輸出網格和虛擬節點名稱。
```
kubectl get pod pod-name -n namespace -o json | \
jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'
```
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## Client Envoys 無法在停用 IMDSv1 的情況下與 App Mesh Envoy Management Service 通訊
**徵狀**
當 `IMDSv1` 停用時，用戶端 Envoys 無法與 App Mesh 控制平面 (Envoy Management Service) 通訊。在 之前的 App Mesh Envoy 版本上`IMDSv2`不支援 `v1.24.0.0-prod`。
**Resolution**
若要解決此問題，您可以執行這三件事之一。
+ 升級至`IMDSv2`支援 `v1.24.0.0-prod`的 App Mesh Envoy 版本 或更新版本。
+ 在執行 Envoy 的執行個體`IMDSv1`上重新啟用 。如需還原 的指示`IMDSv1`，請參閱[設定執行個體中繼資料選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)。
+ 如果您的服務在 Amazon EKS 上執行，建議針對服務帳戶 (IRSA) 使用 IAM 角色來擷取憑證。如需啟用 IRSA 的指示，請參閱[服務帳戶的 IAM 角色](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)。
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。
## 啟用 App Mesh 並注入 Envoy 時，IRSA 無法在應用程式容器上運作
**徵狀**
在 Amazon EKS 叢集上啟用 App Mesh 時，在 Amazon EKS 的 App Mesh 控制器的協助下，Envoy 和`proxyinit`容器會注入應用程式 Pod。應用程式無法擔任 `IRSA` ，而是擔任 `node role`。當我們描述 Pod 詳細資訊時，我們會看到 `AWS_WEB_IDENTITY_TOKEN_FILE`或 `AWS_ROLE_ARN`環境變數不包含在應用程式容器中。
**Resolution**
如果定義了 `AWS_WEB_IDENTITY_TOKEN_FILE`或 `AWS_ROLE_ARN`環境變數，則 Webhook 會略過 Pod。請勿提供其中一個變數，Webhook 會為您注入這些變數。
```
reservedKeys := map[string]string{
"AWS_ROLE_ARN": "",
"AWS_WEB_IDENTITY_TOKEN_FILE": "",
}
...
for _, env := range container.Env {
if _, ok := reservedKeys[env.Name]; ok {
reservedKeysDefined = true
}
```
如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。