本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 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 上处于启用状态。在 [App Mesh 设置故障排除](troubleshooting-setup.md) 中提供的示例中，示例管理端点 URL 显示为 `http://my-app.default.svc.cluster.local:9901/`。
**注意**
管理端点不应暴露在公共互联网上。此外，我们建议您监控管理端点日志，这些日志由 `ENVOY_ADMIN_ACCESS_LOG_FILE` 环境变量默认设置为 `/tmp/envoy_admin_access.log`。
## 启用 Envoy DogStats D 集成以进行指标卸载
可以将 Envoy 代理配置为卸载 OSI 第 4 层和第 7 层流量以及内部进程运行状况的统计数据。虽然本主题展示了如何在不将指标转移到 CloudWatch 指标和 Prometheus. 之类的接收器的情况下使用这些统计信息，但将所有应用程序的这些统计数据放在一个集中的位置可以帮助您更快地诊断问题并确认行为。有关更多信息，请参阅[使用亚马逊 CloudWatch指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)和 [Prometheus 文档](https://prometheus.io/docs/introduction/overview/)。
您可以通过设置中定义的参数来配置 DogStats D 指标[DogStatsD 变量](envoy-config.md#envoy-dogstatsd-config)。有关 DogStats D 的更多信息，请参阅 [DogStatsD](https://docs.datadoghq.com/developers/dogstatsd/?tab=hostagent) 文档。您可以在 A [pp Mesh 中找到将指标卸载到 AWS CloudWatch 指标的演示，其中包含了 Amazon ECS 基础知识演练。](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-ecs-basics) GitHub
## 启用访问日志
我们建议您启用访问 [虚拟节点](virtual_nodes.md) 和 [虚拟网关](virtual_gateways.md) 上的日志，发现有关应用程序之间传输的流量的详细信息。有关更多信息，请参阅 Envoy 文档中的[访问日志记录](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/access_logging)。这些日志提供有关 OSI 第 4 层和第 7 层流量行为的详细信息。当你使用 Envoy 的默认格式时，你可以使用以下解析语句通过 Logs Ins [ights 分析访问CloudWatch 日志](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 调试日志记录
我们建议在预生产环境中将 Envoy 代理的日志级别设置为 `debug`。调试日志可以帮助您在将关联的 App Mesh 配置升级到生产环境之前识别问题。
如果您使用的是 [ Envoy 镜像](envoy.md)，则可以通过 `ENVOY_LOG_LEVEL` 环境变量将日志级别设置为 `debug`。
**注意**
我们建议不在生产环境中使用 `debug` 级别。[将级别设置为`debug`会增加日志记录，并且可能会影响性能和转移到日志等CloudWatch 解决方案的日志的总体成本。](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
当你使用 Envoy 的默认格式时，你可以使用以下解析语句通过 Logs Ins [ights 分析流程CloudWatch 日志](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)：
```
parse @message "[*][*][*][*] [*] *" as Time, Thread, Level, Name, Source, Message
```
## 使用 App Mesh 控制面板监控 Envoy 代理连接
我们建议您监控 Envoy 指标 `control_plane.connected_state`，确保 Envoy 代理与 App Mesh 控制面板通信以获取动态配置资源。有关更多信息，请参阅[管理服务器](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 *account ID* 和以下消息*Region*中的内容可能会有所不同，具体取决于您从哪个 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'
```
**解决方案**
此错误表示正在使用的任务执行角色无权与 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 无法连接到 App Mesh Envoy 管理服务
**症状**
您的 Envoy 代理无法连接到 App Mesh Envoy 管理服务。您将看到：
+ “连接被拒绝”错误
+ 连接超时
+ 解析 App Mesh Envoy 管理服务端点时出错
+ gRPC 错误
**解决方案**
确保您的 Envoy 代理可以访问互联网或私有 [VPC 端点](vpc-endpoints.md)，并且您的[安全组](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_SecurityGroups.html)允许端口 443 上的出站流量。App Mesh 的公有 Enoy 管理服务端点遵循完全限定域名（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 的连接。这会向 Envoy 管理服务发送一个有效但空的 gRPC 请求。
```
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 管理服务的连接正常。要调试 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## Envoy 与 App Mesh Envoy 管理服务断开连接，显示错误文本
**症状**
您的 Envoy 代理无法连接到 App Mesh Envoy 管理服务并接收其配置。您的 Envoy 代理日志包含如下所示的日志条目。
```
gRPC config stream closed: gRPC status code, message
```
**解决方案**
在大多数情况下，日志的消息部分应指出问题所在。下表列出了您可能看到的最常见的 gRPC 状态代码、其原因和解决方法。
| gRPC 状态码 | 原因 | 解决方案 |
| --- | --- | --- |
| 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 文件描述符，则版本 v1.24 及之前版本的 Envoy 中存在一个已知问题 [\$124136](https://github.com/envoyproxy/envoy/issues/24136) 无法获取凭证。当 Envoy 提供高流量服务时，就会发生这种情况。您可以通过在调试级别查看 Envoy 日志中是否有文本“A libcurl function was given a bad argument”来确认此问题。要缓解此问题，请升级到 Envoy 版本 v1.25.1.0-prod 或更高版本。 |
您可以使用以下查询通过 [Amazon CloudWatch Insigh](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) ts 查看来自 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'
```
**解决方案**
以下是补救步骤列表，具体取决于 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 从负载均衡器到网格端点的运行状况检查失败
**症状**
容器运行状况检查或就绪探测器认为您的网格端点运行状况良好，但是从负载均衡器到网格端点的运行状况检查失败。
**解决方案**
要解决此问题，请完成以下任务。
+ 确保与您的网格端点关联的[安全组](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)接受您为运行状况检查配置的端口上的入站流量。
+ 请确保在手动请求运行状况检查时始终如一地成功；例如，来自[您的 VPC 内的堡垒主机](https://aws.amazon.com/quickstart/architecture/linux-bastion/)。
+ 如果您正在为虚拟节点配置运行状况检查，我们建议您在应用程序中实现运行状况检查端点；例如，/ping for HTTP。这可确保 Envoy 代理和您的应用程序均可从负载均衡器路由。
+ 根据所需的功能，您可以针对虚拟节点使用任何类型的弹性负载均衡器。有关更多信息，请参阅 [弹性负载均衡功能](https://aws.amazon.com/elasticloadbalancing/features/#compare)。
+ 如果您正在为[虚拟网关](virtual_gateways.md)配置运行状况检查，我们建议使用[网络负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html)，并在虚拟网关的侦听器端口上进行 TCP 或 TLS 运行状况检查。这样可以确保虚拟网关侦听器已启动并准备好接受连接。
如果您的问题仍未解决，请考虑[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)或联系 Su [AWS pport](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
```
**解决方案**
要解决此问题，为网关指定的用户需要具有 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)或联系 Su [AWS pport](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 名称。
**解决方案**
这是一个已知问题。有关更多信息，请参阅 “[ VirtualServices 按任意主机名命名” 或 FQDN](https://github.com/aws/aws-app-mesh-roadmap/issues/65) GitHub 问题。App Mesh 中的虚拟服务可以被命名为任何名称。只要虚拟服务名称中有 DNS `A` 记录，并且应用程序可以解析虚拟服务名称，Envoy 就会代理请求并将其路由到相应的目的地。要解决此问题，请在任何非环回 IP 地址（例如 `10.10.10.10` 虚拟服务名称）中添加 DNS `A` 记录。在以下条件下可以添加 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 无法连接到虚拟服务后端
**症状**
您的应用程序无法与虚拟节点上定义为后端的虚拟服务建立连接。尝试建立连接时，连接可能完全失败，或者从应用程序的角度来看，请求可能会失败并显示 `HTTP 503` 响应代码。
**解决方案**
如果应用程序根本无法连接（未返回 `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，包括亚马逊 EKS，请确保通过 Helm 安装了最新的 App Mesh 控制器。有关更多信息，请参阅 Helm Hub 上的 [App Mesh 控制器](https://hub.helm.sh/charts/aws/appmesh-controller)或[教程：配置与 Kubernetes 的应用程序网格集成](https://docs.aws.amazon.com/app-mesh/latest/userguide/mesh-k8s-integration.html)。
+ 对于亚马逊 EC2，请确保已设置用于代理 App Mesh 流量的亚马逊 EC2 实例。有关更多信息，请参阅[更新服务](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 代理连接](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 代理时，如果您看到出口流量通过 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 无法连接到外部服务
**症状**
您的应用程序无法连接到网格之外的服务，例如 `amazon.com`。
**解决方案**
默认情况下，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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 无法连接到 MySQL 或 SMTP 服务器
**症状**
当允许到所有目的地（网格 `EgressFilter type`=`ALLOW_ALL`）的出站流量时，例如使用虚拟节点定义的 SMTP 服务器或 MySQL 数据库，您应用程序的连接将失败。例如，以下是尝试连接 MySQL 服务器时出现的错误消息。
```
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
```
**解决方案**
这是一个已知问题，可通过使用 App Mesh 镜像版本 1.15.0 或更高版本来解决。有关更多信息，请参阅[无法通过 App Mesh 连接到 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)服务或亚马逊 EC2 的[更新服务](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ec2.html#update-services)。
如果您的问题仍未解决，则可以向我们详细说明您在使用现有[GitHub 问题](https://github.com/aws/aws-app-mesh-roadmap/issues/62)时遇到的情况，或者联系 Su [AWS pp](https://aws.amazon.com/premiumsupport/) ort。
## 无法连接到 App Mesh 中建模为 TCP 虚拟节点或虚拟路由器的服务
**症状**
您的应用程序无法连接到使用 App Mesh [PortMapping](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_PortMapping.html)定义中的 TCP 协议设置的后端。
**解决方案**
这是一个已知问题。有关更多信息，请参阅[路由到同一端口上的多个 TCP 目的地](https://github.com/aws/aws-app-mesh-roadmap/issues/195) GitHub。由于 OSI 第 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)时遇到的情况，或者联系 Su [AWS pp](https://aws.amazon.com/premiumsupport/) ort。
## 成功连接到未列为虚拟节点虚拟服务后端的服务
**症状**
您的应用程序能够连接并发送流量到您的虚拟节点上未指定为虚拟服务后端的目的地。
**解决方案**
如果请求成功发送到未在 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 当虚拟服务有虚拟节点提供程序 `503` 时，某些请求会失败，并显示 HTTP 状态码
**症状**
您的应用程序的一部分请求无法发送到使用虚拟节点提供商而非虚拟路由器提供商的虚拟服务后端。使用虚拟路由器提供商提供虚拟服务时，请求不会失败。
**解决方案**
这是一个已知问题。有关更多信息，请参阅[上针对虚拟服务的虚拟节点提供商的重试策略](https://github.com/aws/aws-app-mesh-roadmap/issues/194)。 GitHub使用虚拟节点作为虚拟服务提供者时，您无法指定希望虚拟服务的客户端使用的默认重试策略。相比之下，虚拟路由器提供商允许指定重试策略，因为它们是子路由资源的属性。
要减少向虚拟节点提供商请求失败的情况，请改用虚拟路由器提供商，并在其路由上指定重试策略。有关减少应用程序请求失败的其他方法，请参阅[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)或联系 Su [AWS pport](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
```
**解决方案**
这是一个已知问题。之所以出现此错误，是因为与 Amazon EFS 的 NFS 连接发生在任务中的任何容器启动之前。此流量通过代理配置路由到 Envoy，此时不会运行。由于启动顺序的原因，NFS 客户端无法连接到 Amazon EFS 文件系统，任务也无法启动。要解决此问题，请在 Amazon ECS 任务定义的代理配置中`EgressIgnoredPorts`设置的值列表中添加端口 `2049`。有关更多信息，请参阅 [代理配置](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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 连接成功服务，但传入的请求未出现在 Envoy 的访问日志、跟踪记录或指标中
**症状**
尽管您的应用程序可以连接其他应用程序并向其发送请求，但您要么无法在访问日志中看到传入的请求，要么无法在 Envoy 代理的跟踪信息中看到传入的请求。
**解决方案**
这是一个已知问题。如需更多信息，请参阅 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 在容器级别设置`HTTP_PROXY`/`HTTPS_PROXY`环境变量不如预期的那样起作用。
**症状**
当 HTTP\$1PROXY/HTTPS\$1PROXY 被设置为环境变量时：
+ 任务定义中的应用程序容器启用了 App Mesh，发送到 App Mesh 服务命名空间的请求将从 Envoy sidecar `HTTP 500` 获得错误响应。
+ 任务定义中的 Envoy 容器启用了 App Mesh，从 Envoy sidecar 发出的请求将不会通过`HTTP`/`HTTPS`代理服务器，环境变量也无法工作。
**解决方案**
对于应用程序容器：
App Mesh 的功能是让任务中的流量通过 Envoy 代理。`HTTP_PROXY`/`HTTPS_PROXY`配置通过将容器流量配置为通过不同的外部代理来覆盖此行为。Envoy 仍会拦截流量，但不支持使用外部代理代理代理网格流量。
如果要代理所有非网格流量，请设置 `NO_PROXY` 为包括网格的 CIDR/命名空间、本地主机和凭证的端点，如下例所示。
```
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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 即使设置了路由的超时时间，上游请求也会超时。
**症状**
您为以下各项定义了超时：
+ 路由，但您仍然收到上游请求超时错误。
+ 虚拟节点侦听器以及路由的超时和重试超时，但您仍会收到上游请求超时错误。
**解决方案**
要使大于 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## Envoy 回复了 HTTP 错误的请求。
**症状**
对于通过网络负载均衡器 (NLB) 发送的所有请求，Envoy 用** HTTP 400 错误**请求进行响应。当我们查看 Envoy 日志时，我们会看到：
+ 调试日志：
```
dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD
```
+ 访问日志：
```
"- - HTTP/1.1" 400 DPE 0 11 0 - "-" "-" "-" "-" "-"
```
**解决方案**
解决方案是在 NLB 的[目标组属性](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-attributes)上禁用代理协议版本 2 (PPv2)。
到 PPv2 目前为止，使用 App Mesh 控制平面运行的虚拟网关和虚拟节点 Envoy 不支持它。如果您在 Kubernetes 上使用 AWS 负载平衡器控制器部署 NLB，请 PPv2 通过将以下属性设置为来禁用：`false`
```
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled
```
有关 NLB 资源属性的更多详细信息，请参阅[AWS 负载均衡器控制器注释](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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 无法正确配置超时。
**症状**
即使在虚拟节点侦听器上配置了超时时间，在通往虚拟节点后端的路由上配置了超时，您的请求仍会在 15 秒内超时。
**解决方案**
确保后端列表中包含正确的虚拟服务。
如果您的问题仍未解决，请考虑[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)或联系 Su [AWS pport](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 时可能遇到的常见问题。
## 将虚拟 node/virtual 网关的副本扩展到 50 个以上时，连接失败且容器运行状况检查失败
**症状**
当你将虚拟网关的副本数量（例如 Amazon ECS 任务、Kubernetes pod 或 Amazon EC2 实例）扩展到 50 以上的虚拟 node/virtual 网关时，对新的和当前正在运行的 Envoy 的容器运行状况检查开始失败。向虚拟 node/virtual 网关发送流量的下游应用程序开始看到请求失败并显示 HTTP 状态码`503`。
**解决方案**
App Mesh 对每个虚拟网 node/virtual 关的特使数量的默认配额为 50。当正在运行的 Envoy 数量超过此配额时，新的和当前正在运行的 Envoy 将无法通过 gRPC 状态码 `8`(`RESOURCE_EXHAUSTED`)连接到 App Mesh 的 Envoy 管理服务。这个配额可以提高。有关更多信息，请参阅 [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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## `503`当虚拟服务后端水平向外扩展或向内扩展时，请求会失败
**症状**
当后端虚拟服务横向扩展或向内扩展时，来自下游应用程序的请求会失败，并 `HTTP 503` 显示状态码。
**解决方案**
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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 在负载增加的情况下，Envoy 容器因段错误而崩溃
**症状**
在高流量负载下，Envoy 代理由于分段错误（Linux 退出代码 `139`）而崩溃。Envoy 进程日志包含如下语句。
```
Caught Segmentation fault, suspect faulting address 0x0"
```
**解决方案**
Envoy 代理可能违反了操作系统的默认 nofile ulimit，即一个进程一次可以打开的文件数量的限制。这种漏洞是由于流量导致了更多的连接，从而消耗了额外的操作系统插槽。要解决此问题，请增加主机操作系统上的 ulimit nofile 值。如果您使用的是 Amazon ECS，则可以通过任务定义的[资源限制设置](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits)上的 [Ulimit 设置](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 默认资源的增加未反映在服务限制中
**症状**
在增加 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 由于大量的运行状况检查调用，应用程序崩溃。
**症状**
为虚拟节点启用主动运行状况检查后，运行状况检查调用的数量会增加。由于向应用程序发出的运行状况检查调用的数量大大增加，应用程序崩溃。
**解决方案**
启用主动运行状况检查后，下游（客户端）的每个 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)或联系 Su [AWS pport](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 控制台中显示 X 射线追踪信息，或者 APIs。
**解决方案**
要在 App Mesh 中使用 X-Ray，必须正确配置组件，以实现应用程序、sidecar 容器和 X-Ray 服务之间的通信。请执行以下步骤确认 X-Ray 已正确设置：
+ 确保 App Mesh 虚拟节点侦听器协议未设置为 `TCP`。
+ 确保与您的应用程序一起部署的 X-Ray 容器公开 UDP 端口`2000`并以用户身份运行。`1337`有关更多信息，请参阅上的 [Amazon ECS X-Ray 示例](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/howto-ecs-basics/deploy/2-meshify.yaml#L374-L386) GitHub。
+ 确保 Envoy 容器已启用追踪。如果您使用的是 [App Mesh Envoy 镜像](envoy.md)，则可以通过将环境变量设置为将`ENABLE_ENVOY_XRAY_TRACING`环境变量设置为`1` 并将 `XRAY_DAEMON_PORT`环境变量设置为`2000`来启用 X-Ray。
+ 如果您在应用程序代码中使用一种[特定语言](https://docs.aws.amazon.com/xray/index.html)对 X-Ray 进行了检测 SDKs ，请按照您的语言指南确保其配置正确。
+ 如果前面的所有项目都配置正确，请查看 X-Ray 容器日志中是否存在错误，并按照[疑难解答](https://docs.aws.amazon.com/xray/latest/devguide/xray-troubleshooting.html)中的指导进行操作 AWS X-Ray。有关在 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 无法在 Amazon 指标中查看我的应用程序的 Envoy CloudWatch 指标
**症状**
你在 App Mesh 中的应用程序没有向指标发出 Envoy 代理生成的 CloudWatch指标。
**解决方案**
在 App Mesh 中使用 CloudWatch 指标时，必须正确配置多个组件，以实现您的 Envoy 代理、 CloudWatch 代理 sidecar 和 CloudWatch 指标服务之间的通信。请执行以下步骤确认 Envoy 代理的 CloudWatch 指标设置正确：
+ 确保您使用的是 App Mesh 的 CloudWatch 代理映像。有关更多信息，请参阅上的 [App Mesh CloudWatch 代理](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent) GitHub。
+ 确保按照平台特定的使用说明正确配置了 App Mesh 的 CloudWatch 代理。有关更多信息，请参阅上的 [App Mesh CloudWatch 代理](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent#usage) GitHub。
+ 如果前面的所有项目都配置正确，请查看 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 无法为 AWS X-Ray 跟踪配置自定义采样规则
**症状**
您的应用程序正在使用 X-Ray 跟踪，但您无法为跟踪配置采样规则。
**解决方案**
由于 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 tracer 配置本地化的自定义采样规则，请使用 `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 Cay 配置](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` 属性中采样规则清单配置的详细信息，请参阅[配置 X-Ray SDK for Go](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)或联系 Su [AWS pport](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`。
**解决方案**
为确定问题的根本原因，我们建议使用 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 客户端策略信任包中的一个证书颁发机构签名，并且符合中定义的标准 [传输层安全性协议 (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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。如果您认为自己发现了安全漏洞或对 App Mesh 的安全性有疑问，请查看[AWS 漏洞报告指南](https://aws.amazon.com/security/vulnerability-reporting/)。
## 应用程序源自 TLS 时无法连接到后端虚拟服务
**症状**
从应用程序而不是从 Envoy 代理发起 TLS 会话时，与后端虚拟服务的连接会失败。
**解决方案**
这是一个已知问题。有关更多信息，请参阅[功能请求：下游应用程序和上游代理之间的 TLS 协商](https://github.com/aws/aws-app-mesh-roadmap/issues/162) GitHub 问题。在 App Mesh 中，目前支持 Envoy 代理发起 TLS，但不支持应用程序发起 TLS。要在 Envoy 上使用 TLS 发起支持，请在应用程序中禁用 TLS 起源。这样，Envoy 可读取出站请求标头，并通过 TLS 会话将请求转发到相应的目的地。有关更多信息，请参阅 [传输层安全性协议 (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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。如果您认为自己发现了安全漏洞或对 App Mesh 的安全性有疑问，请查看[AWS 漏洞报告指南](https://aws.amazon.com/security/vulnerability-reporting/)。
## 无法断言 Envoy 代理之间的连接正在使用 TLS
**症状**
您的应用程序已在虚拟节点或虚拟网关侦听器上启用 TLS 终止，或者在后端 TLS 客户端策略上启用 TLS 启动，但是您无法断言 Envoy 代理之间的连接是通过 TLS 协商的会话进行的。
**解决方案**
本解析中定义的步骤使用了 Envoy 管理界面和 Envoy 统计信息。有关配置这些内容的帮助，请参阅 [启用 Envoy 代理管理界面](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface) 和 [启用 Envoy DogStats D 集成以进行指标卸载](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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。如果您认为自己发现了安全漏洞或对 App Mesh 的安全性有疑问，请查看[AWS 漏洞报告指南](https://aws.amazon.com/security/vulnerability-reporting/)。
## 使用 Elastic Load Balancing 排除
**症状**
尝试配置应用程序负载均衡器或网络负载均衡器以加密虚拟节点的流量时，连接和负载均衡器运行状况检查可能会失败。
**解决方案**
为确定问题的根本原因，您需要检查以下内容：
+ 对于执行 TLS 终止的 Envoy 代理，您需要排除任何配置错误。然后，遵循 [无法通过 TLS 客户端策略连接到后端虚拟服务](#ts-security-tls-client-policy) 中的步骤。
+ 对于负载均衡器，您需要查看负载均衡器的配置 `TargetGroup:`
+ 确保该 `TargetGroup` 端口与虚拟节点定义的侦听器端口相匹配。
+ 对于通过 HTTP 向您的服务发起 TLS 连接的应用程序负载均衡器，请确保将 `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)或联系 Su [AWS pport](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 中找到
**症状**
您已经使用 Kubernetes 自定义资源定义 (CRD) 创建了 App Mesh 资源，但是当您使用或时，您创建的资源在 App Mesh 中不可见。 AWS 管理控制台 APIs
**解决方案**
可能的原因是 App Mesh 的 Kubernetes 控制器出现错误。有关更多信息，请参阅上的 “[故障排除](https://github.com/aws/aws-app-mesh-controller-for-k8s/blob/master/docs/guide/troubleshooting.md)” GitHub。检查控制器日志中是否存在任何表明控制器无法创建任何资源的错误或警告。
```
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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 注入 Envoy sidecar 后，容器组 (pod) 无法进行就绪和活跃度检查
**症状**
您的应用程序的 pod 之前已成功运行，但是在 Envoy sidecar 注入容器组 (pod) 后，就绪和活跃度检查开始失败。
**解决方案**
确保注入到容器组 (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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## Pod 未注册或取消注册为实例 AWS Cloud Map
**症状**
您的 Kubernetes Pod 并未 AWS Cloud Map 作为其生命周期的一部分在中注册或注销。容器组 (pod) 可能成功启动并准备好提供流量，但无法接收任何流量。当容器组 (pod) 终止时，客户端仍可能保留其 IP 地址并尝试向其发送流量，但失败了。
**解决方案**
这是一个已知问题。如需了解更多信息，请参阅 [Kubernetes registered/deregistered 中的 Pod 无法自动](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/159)生成问题。 AWS Cloud Map 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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 无法确定 App Mesh 资源的容器组 (pod) 在何处运行
**症状**
当您在 Kubernetes 集群上运行 App Mesh 时，操作员无法确定给定的 App Mesh 资源的工作负载或容器在哪里运行。
**解决方案**
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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 无法确定容器组 (pod) 以哪个 App Mesh 资源运行
**症状**
在 Kubernetes 集群上运行 App Mesh 时，操作员无法确定给定的容器组 (pod) 以什么形式运行 App Mesh 资源。
**解决方案**
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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。
## 禁用后，客户特使无法与 App Mesh Envoy 管理服务通信 IMDSv1
**症状**
禁用 `IMDSv1` 后，客户 Envoy 无法与 App Mesh 控制面板（Envoy 管理服务）通信。`v1.24.0.0-prod`之前的 App Mesh Envoy 版本不提供支持 `IMDSv2`。
**解决方案**
要解决这个问题，你可以做这三件事之一。
+ 升级到 App Mesh Envoy 版本 `v1.24.0.0-prod` 或更高版本，该版本有 `IMDSv2` 支持。
+ 在运行 Envoy 的实例 `IMDSv1` 上重新启用。有关恢复的说明 `IMDSv1`，请参阅[配置实例元数据选项](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)。
+ 如果您的服务在 Amazon EKS 上运行，建议使用服务账户的 IAM 角色 (IRSA) 来获取凭证。有关启用 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)或联系 Su [AWS pport](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` 环境变量。
**解决方案**
如果定义了 `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)或联系 Su [AWS pport](https://aws.amazon.com/premiumsupport/)。