VPC 对等互连因 TARGET_CONNECT_TIMEOUT 原因出现“503 服务不可用”错误

您正在查看 Apigee 和 Apigee Hybrid 文档。
此主题没有等效的 Apigee Edge 文档。

症状

此问题在 API Monitoring、Debug 或其他工具中显示为“503 - 服务不可用”错误。“TARGET_CONNECT_TIMEOUT”原因表示使用 VPC 对等互连时 Apigee 实例与目标之间的连接超时。

请勿将该错误与其他超时错误（如 504 网关超时）混淆。

错误消息

这是 Debug 会话或响应载荷中的典型错误。请注意原因： TARGET_CONNECT_TIMEOUT。

{"fault":{"faultstring":"The Service is temporarily unavailable",
"detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable",
"reason":"TARGET_CONNECT_TIMEOUT"}}}

可能的原因

请注意，这些原因特定于使用 VPC 对等互连设置的 Apigee。请参阅 Apigee 网络选项。如果目标是 PSC（端点连接），请改为参阅 PSC 策略方案。

原因	说明
路由配置错误	目标路由不会导出到与 Apigee 实例的对等互连。
目标处存在连接问题	目标并不总是能够接受 TCP 连接。
在目标处列入 IP 许可名单时未添加部分或全部 Apigee NAT IP	在目标处并非所有 Apigee NAT IP 地址都被列入许可名单。
NAT IP 端口耗尽	没有足够的 NAT 端口容纳流量。
connect.timeout.millis 值设置得太低	Apigee 端的连接超时设置过低。

常见诊断步骤

Debug 是用于捕获和评估问题的以下详细信息的重要工具：

• 请求的总时长。通常情况下，超过三秒（默认为 connect.timeout.millis）后就会发生连接超时错误。如果您发现时长较短，请检查目标端点配置。
• 目标主机名和 IP 地址。显示错误的 IP 地址可能表示存在 DNS 相关问题。 您可能还会注意到不同目标 IP 地址与问题之间存在关联。
• 频率。根据问题是间歇性问题还是持续性问题，需要采用不同的方法。

原因：路由配置错误

诊断

如果问题持续存在，即使问题最近才开始，也可能是由路由配置错误导致的。

这可能会影响内部（在对等互连 VPC 内路由）和外部（互联网）目标。

1. 首先，确定从 Apigee 实例解析的目标的 IP 地址。其中一种方法是使用 Debug 会话。在 Debug 中，导航到 AnalyticsPublisher（或传统版 Debug 中的 AnalyticsPublisher）：
   
   

   在屏幕右侧查找 target.ip 值。

   在此示例中，IP 地址为 10.2.0.1。由于此范围是专用的，因此需要采取特定的路由措施来确保 Apigee 能够到达目标。

   请注意，如果目标位于互联网上，并且为 Apigee 启用了 VPC Service Controls，则需要执行此步骤，因为这会阻止互联网连接。

2. 记下部署受影响的 Apigee 实例的区域。在 Cloud 控制台中的 Apigee 界面中，点击实例。在位置字段中，您可以找到该实例的确切区域。
   
   
   
3. 在与 Apigee 对等互连的项目中，导航到界面中的 VPC 网络 -> VPC 网络对等互连部分。请注意，如果您使用的是共享 VPC，则需要在宿主项目而不是 Apigee 项目中执行这些步骤。
   
   
4. 点击 servicenetworking-googleapis-com，选择servicenetworking-googleapis-com标签页，然后按第 2 步中获取的区域进行过滤。
   
   此示例将 10.2.0.0/24 路由显示为导出状态，并包含 10.2.0.1 示例目标 IP。如果您没有看到与您的目标相对应的路由，则会导致此问题。
   
   注意：如果目标是外部目标，则导出的路由中通常不存在路由，并且 Apigee 请求会直接路由到互联网。实际情况并非始终如此，因此请务必明确所需的网络拓扑。例如，如果启用了 VPC Service Controls，则还需要导出默认路由或其他路由才能访问外部目标。
   
   

解决方法

查看您的网络架构，并确保将路由导出到 VPC 与 Apigee 的对等互连。缺少的路由很可能是静态或动态路由。缺少必要的动态路由表示相应功能（例如 Cloud Interconnect）存在问题。

请注意，不支持传递性对等互连。换句话说，如果 VPC 网络 N1 与 N2 和 N3 对等互连，但是 N2 和 N3 未直接连接，则 VPC 网络 N2 不能与 VPC 网络 N3 通过 VPC 网络对等互连进行通信。

如需了解详情，请参阅南向网络模式。

原因：目标处存在连接问题

诊断

目标可能无法从 VPC 访问，也无法接受连接。您可以使用以下两个选项来诊断问题。

连接测试（专用目标 IP 地址）

如果目标位于专用网络中，您可以使用连接测试功能诊断常见原因。

1. 确定从 Apigee 实例解析的目标的 IP 地址。一种方法是使用 Debug 会话。
   
   在 Debug 中，导航到 AnalyticsPublisher（或传统版 Debug 中的 AX）。 在屏幕右侧查找 target.ip 值。
   
   在此示例中，IP 地址为 10.2.0.1。这是一个专用 IP 地址，这意味着我们可以使用 Connectivity Tests。
   
   
2. 记下无法连接到目标的 Apigee 实例的 IP 地址。 在 Apigee 控制台的实例中，在 IP 地址字段中找到 Apigee 实例的 IP 地址。
   
   
3. 转到 Connectivity Tests，然后点击创建连接测试。请提供以下详细信息：
   1. 来源 IP 地址：使用在上述第 2 步中获取的 Apigee 实例 IP。请注意，这不是 Apigee 用于向目标发送请求的确切来源 IP，但它足以满足测试的要求，因为它位于同一子网中。
   2. 这是 Google Cloud 中使用的 IP 地址：除非该地址位于您的任何 Google Cloud 项目中，否则请勿选中该地址。如果要检查此值，请提供项目和网络。
   3. 将目标地址（第 1 步）和端口分别设置为目标 IP 地址和目标端口。
   
4. 点击创建，然后等待测试完成第一次运行。
5. 在连接测试列表中，点击查看以查看执行结果。
6. 如果结果为“无法访问”，则表示配置存在问题。该工具应该会将您转到 Connectivity Tests 状态文档以继续后续步骤。如果状态为“可访问”，则排除了许多配置问题。 但是，这并不保证目标可访问。尚未实际尝试与目标建立 TCP 连接。只有下面的下一条诊断才能有助于测试这一点。
   
   

虚拟机连接测试（所有目标）

1. 在与 Apigee 对等互连的同一 VPC 中，在 Linux 上创建虚拟机实例。
2. 从虚拟机执行连接测试，最好是在可从 Apigee 重现问题时。您可以使用 telnet、curl 和其他实用程序建立连接。此 curl 示例在超时时间为 3 秒的循环中运行。如果 curl 无法在三秒内建立 TCP 连接，则失败。

   for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done

3. 检查完整输出并查找以下错误：

   * Closing connection 0
    curl: (28) Connection timed out after 3005 milliseconds

   此错误的存在可确认问题在 Apigee 之外可重现。

   请注意，如果您看到其他错误，例如与 TLS 相关的错误、错误的状态代码等，它们不会确认连接超时，且与此问题无关。

4. 如果目标需要列入 IP 允许名单，您可能无法从虚拟机测试该目标，除非您也将虚拟机实例的来源 IP 列入许可名单。

解决方法

如果您根据 Connectivity Tests 发现了问题，请继续执行记录的解决步骤。

如果从虚拟机重现了超时，则没有有关如何在目标端解决问题的明确指导。一旦连接超时在 Apigee 之外可重现，请从 VPC 进一步解决问题。尝试测试尽可能靠近目标的连接。

如果目标位于 VPN 连接后面，您也可以从本地网络对其进行测试。

如果目标位于互联网上，您可以尝试在 Google Cloud 控制台之外重现问题。

如果问题发生在高峰时段，则目标可能会因为连接而不堪重负。

如果您需要在该阶段提交 Google Cloud 支持请求，则不再需要选择 Apigee 组件，因为现在可以直接从 VPC 重现该问题。

原因：在目标处列入 IP 许可名单时未添加部分或全部 Apigee NAT IP

诊断

这涉及启用了列入 IP 许可名单的外部目标（互联网）。请确保在受影响的目标端添加所有 Apigee NAT IP。如果目标上没有列入许可名单，则可以跳过此部分。

如果错误是间歇性的，则更容易识别问题，因为在这种情况下，您可能会发现特定 NAT IP 与错误之间存在关联。

如果问题仍然存在（所有调用都失败），请确保在 Apigee 上启用了 NAT IP，并按照以下步骤提取这些 IP：

列出实例的 NAT IP 地址：

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

示例响应：

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

如果输出中未收到任何地址，则不会在 Apigee 端添加 NAT IP。如果您获得了地址，但所有地址都未处于有效状态，则使用的所有地址都不允许访问互联网，这也是一个问题。

如果您至少有一个有效地址，则可以在目标处将其列入许可名单，因此 Apigee 端不会出现配置错误。在这种情况下，目标处的许可名单中可能会缺少地址。

如果问题是间歇性的，则可能表示只有一部分 NAT IP 地址已在目标处列入许可名单。为进行识别，请执行以下操作：

1. 创建一个新的反向代理，其中在 TargetEndpoint 中指定受影响的目标。不过，您也可以重复使用现有代理并继续执行下一步：
   
   
2. 将 ServiceCallout 政策添加到请求 PreFlow 中。ServiceCallout 应该调用“https://icanhazip.com”，“https://mocktarget.apigee.net/ip”或会在响应中返回调用方 IP 地址的任何其他公共端点。将响应存储在“response”变量中，以便内容在 Debug 中可见。以下是 ServiceCallout 政策配置示例：
   

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
       <DisplayName>Service Callout-1</DisplayName>
       <Properties/>
       <Request clearPayload="true" variable="myRequest">
           <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
       </Request>
       <Response>response</Response>
       <HTTPTargetConnection>
           <Properties/>
           <URL>https://icanhazip.com</URL>
       </HTTPTargetConnection>
   </ServiceCallout>

   您还可以将响应存储在自定义变量中，但需要通过 AssignMessage 政策读取该变量的“.content”，以便在 Debug 工具中显示。

   确保目标的配置方式与受影响代理中的配置方式完全相同。

   注意：ServiceCallout 请求和 Target 请求都应在单个事务中进行。这是为了确保同一服务器处理请求，使受影响请求的 NAT IP 与从 ServiceCallout 获取的 NAT IP 匹配。
3. 运行 Debug 会话，然后点击 ServiceCallout 步骤：
   
   
4. 在右下角，您应该会看到响应内容部分，其中包含发出请求的 Apigee 实例的 NAT IP（在正文中）。 或者，如果您将 ServiceCallout 响应存储在其他位置，您应该会在该位置看到它。
   
   请注意，稍后在流中，代理将调用目标，并且响应内容将被错误或目标中的响应覆盖。
5. 尝试将 NAT IP 与问题相关联。如果您发现只有特定 IP 地址失败，这表明部分 IP 地址（但并非所有 IP 地址）已在目标中被列入许可名单。
6. 如果您没有看到 NAT IP 与错误之间的关联，例如，如果同一 IP 在一个请求中失败，但在另一个请求中未成功，则这很可能不是列入许可名单的问题。 这可能是 NAT 耗尽的原因。请参阅原因：NAT IP 端口耗尽。

解决方法

确保您已预配并激活 NAT IP，并确保在目标端添加所有 NAT IP。

原因：NAT IP 端口耗尽

诊断

注意：此原因不常见，如果无法从 VPC 或 Apigee 外部的任何其他位置重现，则此原因与问题相关。如果您尚未执行该测试，请参考上面的目标处存在连接问题部分获取指导。如果您未使用 NAT IP，则本部分内容也与问题无关。

如果问题只能从 Apigee 重现，并且为您的组织预配了 NAT IP，并且您发现不同目标同时发生该问题，那么您可能用完了 NAT 来源端口：

1. 记下问题的时间范围。例如：每天下午 5:58 到 6:08。
2. 确认在同一时间范围内是否有任何其他目标值受到该问题的影响。其他目标必须可通过互联网访问，并且不得托管在初始受影响目标所在的位置。
3. 确定错误是否只在超过 TPS 的某个流量时才发生。为此，请记下问题的时间范围，然后导航到代理性能信息中心。
4. 尝试将错误时间窗口与平均每秒事务数 (tps) 的升高相关联。

在此示例中，tps 在下午 5:58 增长到 1000。假设在此示例中，下午 5:58 正好发生该问题，并且该问题影响了两个或更多不相关的目标，这表示存在 NAT 耗尽问题。

解决方法

按照计算静态 NAT IP 要求中的说明重新计算您的 NAT IP 要求。

您还可以添加更多 NAT IP，看看能否解决问题。请注意，添加更多 IP 时，可能需要首先在所有目标上将其列入许可名单。

原因：connect.timeout.millis 值设置得太低

诊断

代理中的超时值配置可能不正确。

为了进行检查，请转到受影响的代理并检查相关的 TargetEndpoint。注意“connect.timeout.millis”属性及其值。在此示例中，该值为 50，即 50 毫秒，该值通常被认为太低，无法保证建立 TCP 连接。如果您看到低于 1000 的值，这可能是问题的原因。如果您没有看到这样的“connect.timeout.millis”属性，则表示已设置默认值，原因尚未确认。

解决方法

修复 connect.timeout.millis 值，务必注意时间单位为毫秒。默认值为 3000，即 3000 毫秒。如需了解详情，请参阅端点属性参考文档。

请与支持团队联系，获取进一步的帮助

如果按照上述说明操作后问题仍然存在，请收集 Google Cloud 支持团队的以下诊断信息：

1. 项目 ID 和 Apigee 组织名称
2. 代理名称和环境
3. 问题的时间范围
4. 问题出现的频率
5. 目标主机名
6. 包含问题的 Debug 会话
7. 针对上述可能原因执行的检查的结果。例如，虚拟机中的 curl 命令的输出