View a markdown version of this page

App Mesh 连接故障排除 - Amazon App Mesh
无法解析虚拟服务的 DNS 名称无法连接到虚拟服务后端无法连接到外部服务无法连接到 MySQL 或 SMTP 服务器无法连接到 App Mesh 中建模为 TCP 虚拟节点或虚拟路由器的服务成功连接到未列为虚拟节点虚拟服务后端的服务当虚拟服务具有虚拟节点提供商时，某些请求会失败，并显示 HTTP 状态码 503无法连接到 Amazon EFS 文件系统成功连接到服务，但传入的请求未出现在 Envoy 的访问日志、跟踪或指标中在容器级别设置 HTTP_PROXY/HTTPS_PROXY 环境变量无法按预期工作。即使在设置了路由超时之后，上游请求也会超时。Envoy 使用 HTTP 错误请求进行响应。无法正确配置超时。
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

App Mesh 连接故障排除

重要

终止支持通知：2026 年 9 月 30 日， Amazon 将停止对的支持。 Amazon App Mesh 2026 年 9 月 30 日之后，您将无法再访问 Amazon App Mesh 控制台或 Amazon App Mesh 资源。有关更多信息，请访问这篇博客文章从 Amazon App Mesh 亚马逊ECS服务连接迁移。

本主题详细介绍了您在使用 App Mesh 连接时可能遇到的常见问题。

无法解析虚拟服务的 DNS 名称

症状

您的应用程序无法解析其尝试连接的虚拟服务的 DNS 名称。

解决方案

这是一个已知问题。有关更多信息，请参阅 “ VirtualServices 按任意主机名命名” 或 FQDN GitHub 问题。App Mesh 中的虚拟服务可以命名为任何名称。只要虚拟服务名称中有 DNS A 记录，并且应用程序可以解析虚拟服务名称，Envoy 就会代理请求并将其路由到相应的目的地。要解决此问题，请在任何非环回 IP 地址（例如 10.10.10.10 虚拟服务名称）中添加 DNS A 记录。可以在以下条件下添加 DNS A 记录：

  • 在 Amazon Route 53 中，如果名称以您的私有托管区域名称为后缀

  • 在应用程序容器的 /etc/hosts 文件中

  • 在您管理的第三方 DNS 服务器中

如果您的问题仍未解决，请考虑提出GitHub 问题或联系Amazon 支持部门。

无法连接到虚拟服务后端

症状

您的应用程序无法与定义为虚拟节点后端的虚拟服务建立连接。尝试建立连接时，连接可能完全失败，或者从应用程序的角度来看，请求可能会失败并显示 HTTP 503 响应代码。

解决方案

如果应用程序根本无法连接（未返回 HTTP 503 响应代码），请执行以下操作：

如果应用程序连接但请求失败并显示 HTTP 503 响应代码，请尝试以下操作：

  • 确保你正在连接的虚拟服务存在于网格中。

  • 确保虚拟服务有提供商（虚拟路由器或虚拟节点）。

  • 使用 Envoy 作为 HTTP 代理时，如果您看到出口流量通过 Envoy 统计数据进入 cluster.cds_egress_*_mesh-allow-all 而非正确的目的地，那么 Envoy 很可能没有正确路由请求。filter_chains这可能是使用不合格的虚拟服务名称的结果。我们建议您使用实际服务的服务发现名称作为虚拟服务名称，因为 Envoy 代理通过其名称与其他虚拟服务进行通信。

    有关更多信息，请参阅虚拟服务。

  • 检查 Envoy 代理日志中是否有以下任何错误消息：

    • No healthy upstream：Envoy 代理尝试路由到的虚拟节点没有任何已解析的端点，或者它没有任何运行正常的端点。确保目标虚拟节点具有正确的服务发现和运行状况检查设置。

      如果在部署或扩展后端虚拟服务的过程中对该服务的请求失败，请按照 当虚拟服务具有虚拟节点提供商时，某些请求会失败，并显示 HTTP 状态码 503 中的指导进行操作。

    • No cluster match for URL：这很可能是当向虚拟服务发送的请求与虚拟路由器提供商下定义的任何路由所定义的标准都不匹配时引起的。通过确保路径和 HTTP 请求标头正确，确保将来自应用程序的请求发送到受支持的路由。

    • No matching filter chain found：这很可能是通过无效端口向虚拟服务发送请求时造成的。确保来自应用程序的请求使用虚拟路由器上指定的相同端口。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系Amazon 支持部门。

无法连接到外部服务

症状

您的应用程序无法连接到网格之外的服务，例如 amazon.com。

解决方案

默认情况下，App Mesh 不允许来自网格内应用程序的出站流量到网格外部的任何目的地。要启用与外部服务的通信，有两个选项：

  • 将网格资源的出站过滤器设置为 ALLOW_ALL。此设置将允许网格内的任何应用程序与网格内部或外部的任何目标 IP 地址进行通信。

  • 使用虚拟服务、虚拟路由器、路由和虚拟节点对网格中的外部服务进行建模。例如，要对外部服务进行建模 example.com，您可以创建一个名为 example.com 的虚拟服务，该虚拟路由器和路由将所有流量发送到 DNS 服务发现主机名为 example.com 的虚拟节点。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系Amazon 支持部门。

无法连接到 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 GitHub 问题。之所以出现此错误，是因为由 App Mesh 配置的 Envoy 中的出站侦听器添加了 Envoy TLS Inspector 侦听器过滤器。有关更多信息，请参阅 Envoy 文档中的 TLS Inspector。该过滤器通过检查从客户端发送的第一个数据包来评估连接是否在使用 TLS。但是，使用 MySQL 和 SMTP 时，服务器会在连接后发送第一个数据包。有关 MySQL 的更多信息，请参阅 MySQL 文档中的首次握手。由于服务器发送了第一个数据包，因此过滤器的检查失败。

要根据您的 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 更新服务、亚马逊 ECS 更新服务或亚马逊 EC 2 更新服务。

如果您的问题仍未解决，则可以向我们详细说明您在使用现有GitHub 问题时遇到的问题，或联系客Amazon 服。

无法连接到 App Mesh 中建模为 TCP 虚拟节点或虚拟路由器的服务

症状

您的应用程序无法连接到使用 App Mesh PortMapping 定义中的 TCP 协议设置的后端。

解决方案

这是一个已知问题。有关更多信息，请参阅在的同一端口上路由到多个 TCP 目的地 GitHub。由于 OSI 第 4 层提供给 Envoy 代理的信息存在限制，App Mesh 目前不允许以 TCP 建模的多个后端目标共享同一个端口。为确保可将 TCP 流量正确路由到所有后端目标，请执行以下操作：

  • 确保所有目的地都使用唯一端口。如果您为后端虚拟服务使用虚拟路由器提供商，则可以更改虚拟路由器端口，而无需更改其路由到的虚拟节点上的端口。这样，应用程序可在虚拟路由器端口上打开连接，而 Envoy 代理可继续使用虚拟节点中定义的端口。

  • 如果以 TCP 建模的目标是 MySQL 服务器，或者服务器在连接后发送第一批数据包时使用的任何其他 TCP-based 协议，请参阅无法连接到 MySQL 或 SMTP 服务器。

如果您的问题仍未解决，则可以向我们详细说明您在使用现有GitHub 问题时遇到的问题，或联系客Amazon 服。

成功连接到未列为虚拟节点虚拟服务后端的服务

症状

您的应用程序能够连接并向未指定为虚拟节点上虚拟服务后端的目标发送流量。

解决方案

如果请求成功发送到未在 App Mesh API 中建模的目标，则最有可能的原因是网格的出站过滤器类型已设置为 ALLOW_ALL。当出站筛选器设置为 ALLOW_ALL 时，您的应用程序发出的与建模目的地（后端）不匹配的出站请求将发送到该应用程序设置的目标 IP 地址。

如果要禁止流量前往未在网格中建模的目的地，请考虑将出站过滤器值设置为 DROP_ALL。

注意

设置网格出站过滤器值会影响网格内的所有虚拟节点。

配置egress_filter为DROP_ALL和启用 TLS 不适用于非 Amazon 域流量的出站流量。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系Amazon 支持部门。

当虚拟服务具有虚拟节点提供商时，某些请求会失败，并显示 HTTP 状态码 503

症状

您的应用程序的一部分请求无法发送到使用虚拟节点提供商而非虚拟路由器提供商的虚拟服务后端。使用虚拟路由器提供商提供虚拟服务时，请求不会失败。

解决方案

这是一个已知问题。有关更多信息，请参阅针对虚拟服务的虚拟节点提供商的重试策略。 GitHub使用虚拟节点作为虚拟服务提供者时，您无法指定希望虚拟服务的客户端使用的默认重试策略。相比之下，虚拟路由器提供商允许指定重试策略，因为它们是子路由资源的属性。

要减少向虚拟节点提供商发出的请求失败次数，请改用虚拟路由器提供商，并在其路由上指定重试策略。有关减少应用程序请求失败的其他方法，请参阅App Mesh 最佳实践。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系Amazon 支持部门。

无法连接到 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
解决方案

这是一个已知问题。出现此错误是因为 NFS 与 Amazon EFS 的连接发生在任务中的任何容器启动之前。此流量由代理配置路由到 Envoy，该代理此时将不运行。由于启动顺序，NFS 客户端无法连接到 Amazon EFS 文件系统，任务也无法启动。要解决此问题，请在 Amazon ECS 任务定义的代理配置中EgressIgnoredPorts设置的值列表中添加端口 2049。有关更多信息，请参阅 代理配置。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系Amazon 支持部门。

成功连接到服务，但传入的请求未出现在 Envoy 的访问日志、跟踪或指标中

症状

尽管您的应用程序可以连接其他应用程序并向其发送请求，但您在访问日志或 Envoy 代理的跟踪信息中看不到传入的请求。

解决方案

这是一个已知问题。有关更多信息，请参阅 Github 上的 iptables 规则设置问题。Envoy 代理仅拦截其相应虚拟节点正在侦听的端口的入站流量。对任何其他端口的请求都将绕过 Envoy 代理，直接访问其背后的服务。为了让 Envoy 代理拦截您的服务的入站流量，您需要将虚拟节点和服务设置为在同一个端口上监听。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系Amazon 支持部门。

在容器级别设置 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/namespace、本地主机和凭证的端点，如以下示例所示。

NO_PROXY=localhost,127.0.0.1,169.254.169.254,169.254.170.2,10.0.0.0/16

对于 Envoy 容器：

Envoy 不支持通用代理。我们不建议设置这些变量。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系Amazon 支持部门。

即使在设置了路由超时之后，上游请求也会超时。

症状

您为以下内容定义了超时时间：

  • 路由，但您仍然收到上游请求超时错误。

  • 虚拟节点侦听器以及路由的超时和重试超时，但您仍会收到上游请求超时错误。

解决方案

要成功完成超过 15 秒的高延迟请求，您需要在路由和虚拟节点侦听器级别指定超时时间。

如果您指定的路由超时大于默认的 15 秒，请确保同时为所有参与的虚拟节点的侦听器指定了超时时间。但是，如果将超时值减少到低于默认值的值，则可以选择更新虚拟节点的超时时间。有关设置虚拟节点和路由时选项的更多信息，请参阅虚拟节点和路由。

如果您指定了重试策略，则您为请求超时指定的持续时间应始终大于或等于重试超时乘以您在重试策略中定义的最大重试次数。这使您的请求能够成功完成所有重试。有关更多信息，请参阅路线。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系Amazon 支持部门。

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 的目标组属性上禁用代理协议版本 2 (PPv2)。

到目前为止，使用 App Mesh 控制面板运行的虚拟网关和虚拟节点 Envoy 不支持 PPv2。如果您在 Kubernetes 上使用 Amazon 负载均衡器控制器部署 NLB，请通过将以下属性设置为来禁用 PPv2：false

service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled

有关 NLB 资源属性的更多详细信息，请参阅Amazon 负载均衡器控制器注释。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系Amazon 支持部门。

无法正确配置超时。

症状

即使在虚拟节点侦听器上配置了超时以及在通往虚拟节点后端的路由上配置了超时之后，您的请求也会在 15 秒内超时。

解决方案

确保后端列表下包含正确的虚拟服务。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系Amazon 支持部门。