本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# App Mesh 连接故障排除
**重要**
终止支持通知：2026 年 9 月 30 日， Amazon 将停止对的支持。 Amazon App Mesh 2026 年 9 月 30 日之后，您将无法再访问 Amazon App Mesh 控制台或 Amazon App Mesh 资源。有关更多信息，请访问此博客文章[从迁移 Amazon App Mesh 到 Amazon ECS Service Connect](https://www.amazonaws.cn/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 [Amazon pport](https://www.amazonaws.cn/premiumsupport/)。
## 无法连接到虚拟服务后端
**症状**
您的应用程序无法与虚拟节点上定义为后端的虚拟服务建立连接。尝试建立连接时，连接可能完全失败，或者从应用程序的角度来看，请求可能会失败并显示 `HTTP 503` 响应代码。
**解决方案**
如果应用程序根本无法连接（未返回 `HTTP 503` 响应代码），请执行以下操作：
+ 确保您的计算环境已设置为可与 App Mesh 配合使用。
+ 对于 Amazon ECS，请确保已启用相应的[代理配置](proxy-authorization.md)。有关演 end-to-end练，请参阅 [App Mesh 和 Amazon ECS 入门](https://docs.amazonaws.cn/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.amazonaws.cn/app-mesh/latest/userguide/mesh-k8s-integration.html)。
+ 对于亚马逊 EC2，请确保已设置用于代理 App Mesh 流量的亚马逊 EC2 实例。有关更多信息，请参阅[更新服务](https://docs.amazonaws.cn/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.amazonaws.cn/app-mesh/latest/userguide/troubleshooting-best-practices.html#ts-bp-enable-envoy-control-plane-connected-state)。
如果 Envoy 最初能够建立连接，但后来断开连接且从未重新连接，请参阅 Envoy 与 [App Mesh Envoy 管理服务断开连接，并附上错误文本](https://docs.amazonaws.cn/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.amazonaws.cn/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 [Amazon pport](https://www.amazonaws.cn/premiumsupport/)。
## 无法连接到外部服务
**症状**
您的应用程序无法连接到网格之外的服务，例如 `amazon.com`。
**解决方案**
默认情况下，App Mesh 不允许从网格内应用程序到网格之外任何目的地的出站流量。要启用与外部服务的通信，有两个选项：
+ 将网格资源的[出站过滤器](https://docs.amazonaws.cn/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 [Amazon pport](https://www.amazonaws.cn/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.amazonaws.cn/app-mesh/latest/userguide/getting-started-kubernetes.html#create-update-services)、Amazon ECS [的更新](https://docs.amazonaws.cn/app-mesh/latest/userguide/getting-started-ecs.html#update-services)服务或亚马逊 EC2 的[更新服务](https://docs.amazonaws.cn/app-mesh/latest/userguide/getting-started-ec2.html#update-services)。
如果您的问题仍未解决，则可以向我们详细说明您在使用现有[GitHub 问题](https://github.com/aws/aws-app-mesh-roadmap/issues/62)时遇到的情况，或者联系 Su [Amazon pp](https://www.amazonaws.cn/premiumsupport/) ort。
## 无法连接到 App Mesh 中建模为 TCP 虚拟节点或虚拟路由器的服务
**症状**
您的应用程序无法连接到使用 App Mesh [PortMapping](https://docs.amazonaws.cn/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 [Amazon pp](https://www.amazonaws.cn/premiumsupport/) ort。
## 成功连接到未列为虚拟节点虚拟服务后端的服务
**症状**
您的应用程序能够连接并发送流量到您的虚拟节点上未指定为虚拟服务后端的目的地。
**解决方案**
如果请求成功发送到未在 App Mesh 中建模的目标 APIs，则最有可能的原因是网格的[出站过滤器](https://docs.amazonaws.cn/app-mesh/latest/APIReference/API_EgressFilter.html)类型已设置为`ALLOW_ALL`。当出站筛选器设置为 `ALLOW_ALL` 时，您的应用程序发出的与建模目的地（后端）不匹配的出站请求将发送到该应用程序设置的目标 IP 地址。
如果要禁止流量前往未在网格中建模的目的地，请考虑将出站过滤器值设置为 `DROP_ALL`。
**注意**
设置网格出站过滤器值会影响网格中的所有虚拟节点。
配置`egress_filter`为`DROP_ALL`并启用 TLS 不适用于非 Amazon 域的出站流量。
如果您的问题仍未解决，请考虑[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 [Amazon pport](https://www.amazonaws.cn/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 [Amazon pport](https://www.amazonaws.cn/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.amazonaws.cn/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 [Amazon pport](https://www.amazonaws.cn/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 [Amazon pport](https://www.amazonaws.cn/premiumsupport/)。
## 在容器级别设置`HTTP_PROXY`/`HTTPS_PROXY`环境变量不如预期的那样起作用。
**症状**
当 HTTP\_PROXY/HTTPS\_PROXY 被设置为环境变量时：
+ 任务定义中的应用程序容器启用了 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 [Amazon pport](https://www.amazonaws.cn/premiumsupport/)。
## 即使设置了路由的超时时间，上游请求也会超时。
**症状**
您为以下各项定义了超时：
+ 路由，但您仍然收到上游请求超时错误。
+ 虚拟节点侦听器以及路由的超时和重试超时，但您仍会收到上游请求超时错误。
**解决方案**
要使大于 15 秒的高延迟请求成功完成，您需要在路由和虚拟节点侦听器级别指定超时时间。
如果您指定的路由超时大于默认的 15 秒，请确保同时为所有参与的虚拟节点的侦听器指定了超时时间。但是，如果您将超时时间缩短到低于默认值的值，则可以选择更新虚拟节点的超时时间。有关设置虚拟节点和路由时选项的更多信息，请参阅[虚拟节点](https://docs.amazonaws.cn/app-mesh/latest/userguide/virtual_nodes.html)和[路由](https://docs.amazonaws.cn/app-mesh/latest/userguide/routes.html)。
如果您指定了**重试策略**，则您为请求超时指定的持续时间应始终大于或等于*重试超时*乘以您在**重试策略**中定义的*最大重试次数*。这样，您的请求就可以成功完成所有重试操作。有关更多信息，请参阅[路线](https://docs.amazonaws.cn/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 [Amazon pport](https://www.amazonaws.cn/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.amazonaws.cn/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-attributes)上禁用代理协议版本 2 (PPv2)。
到 PPv2 目前为止，使用 App Mesh 控制平面运行的虚拟网关和虚拟节点 Envoy 不支持它。如果您在 Kubernetes 上使用 Amazon 负载平衡器控制器部署 NLB，请 PPv2 通过将以下属性设置为来禁用：`false`
```
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled
```
有关 NLB 资源属性的更多详细信息，请参阅[Amazon 负载均衡器控制器注释](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 [Amazon pport](https://www.amazonaws.cn/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 [Amazon pport](https://www.amazonaws.cn/premiumsupport/)。