502 网关无效 - TooBigBody

您正在查看 Apigee Edge 文档。
前往 Apigee X 文档。 信息

问题

客户端应用收到 HTTP 状态代码 502 Bad Gateway 和错误代码 protocol.http.TooBigBody ，以此响应 API 调用。

出错提示

客户端应用获取以下响应代码：

HTTP/1.1 502 Bad Gateway

此外，您可能会看到以下错误消息：

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

可能的原因

如果目标/后端服务器作为 HTTP 响应的一部分发送到 Apigee Edge 的载荷大小大于 Apigee Edge 中允许的限制，则会发生此错误。

以下是此错误的可能原因：

常见诊断步骤

您可以使用以下工具/方法来诊断此错误：

原因：响应载荷大小超出允许的限制

诊断

1. 使用 API 监控、Trace 工具或 NGINX 访问日志（如常见诊断步骤中的方案 1 所述）确定所观测到的错误的故障代码、故障来源和响应载荷大小。
2. 如果“故障源”的值为 target，则表示目标/后端服务器发送给 Apigee 的响应载荷大小大于 Apigee Edge 中允许的限制。
3. 验证根据第 1 步确定的响应载荷大小。
   • 如果载荷大小超过允许的 10 MB 限额，则会导致错误。
   • 如果载荷大小接近 10 MB 的允许上限，则响应载荷可能以压缩格式传递。前往 原因：解压缩后，响应载荷大小超出允许的限制。
4. 通过以下步骤检查实际响应，验证响应载荷大小是否确实超过了 10 MB 的允许限值：
   1. 如果您无法访问向目标/后端服务器发出的实际请求，请前往问题解决。
   2. 如果您有权访问向目标/后端服务器发出的实际请求，请执行以下步骤：
      1. 如果您是公有云/私有云用户，请直接从后端服务器本身或您获准向后端服务器发出请求的任何其他机器向后端服务器发出请求。
      2. 如果您是 Private Cloud 用户，也可以从某个消息处理器向后端服务器发出请求。
      3. 通过检查 Content-Length 标头，验证响应中传递的载荷的大小。
      4. 如果您发现载荷大小超过了 Apigee Edge 中允许的限额，则会导致此问题。

   后端服务器的响应示例：

   curl -v https://BACKENDSERVER-HOSTNAME/testfile
   

   * About to connect() to 10.14.0.10 port 9000 (#0)
   *   Trying 10.14.0.10...
   * Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
   > GET /testfile HTTP/1.1
   > User-Agent: curl/7.29.0
   > Host: 10.14.0.10:9000
   > Accept: */*
   >
   < HTTP/1.1 200 OK
   < Accept-Ranges: bytes
   < Content-Length: 11534336
   < Content-Type: application/octet-stream
   < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
   < Date: Wed, 30 Jun 2021 09:22:41 GMT
   <
   ----snipped----
   <Response Body>

   在上面的示例中，您可以看到 Content-Length: 11534336 (which is ~11 MB) 是导致此错误的原因，因为它超出了 Apigee Edge 中允许的限制。

分辨率

请参阅解决方法。

原因：解压缩后，响应载荷大小超出允许的限制

如果响应载荷以压缩格式发送，并且响应标头 Content-Encoding 设置为 gzip, ，则 Apigee 会解压缩响应载荷。在解压缩过程中，如果 Apigee 发现载荷的大小大于 Apigee Edge 中允许的限制，则会停止进一步解压缩，并立即返回 502 Bad Gateway 和错误代码 protocol.http.TooBigBody。

诊断

1. 使用 API 监控、Trace 工具或 NGINX 访问日志（如常见诊断步骤中的方案 2 所述）确定所观测到的错误的故障代码、故障来源和响应载荷大小。
2. 如果 Fault Source 的值为 target，则表示目标/后端应用发送给 Apigee 的响应载荷大小大于 Apigee Edge 中允许的限制。
3. 验证根据第 1 步确定的响应载荷大小。
   • 如果载荷大小超过允许的 10 MB 限额，则会导致错误。
   • 如果载荷大小接近 10 MB 的允许上限，则响应载荷可能会以压缩格式传递。在这种情况下，请检查压缩响应载荷的未压缩大小。
4. 您可以使用以下方法之一验证目标/后端发送的响应是否为压缩格式，以及未压缩的大小是否超过允许的限制：

   跟踪记录

   使用 Trace 工具：

   1. 如果您已捕获失败请求的跟踪记录，请参阅跟踪和
      中详述的步骤
      1. 确定 target.received.content.length 的值
      2. 验证客户端的请求是否包含 Content-Encoding: gzip 标头
   2. 如果 target.received.content.length 的值接近允许的 10 MB 限制，并且响应标头为 Content-Encoding: gzip，则会导致此错误。

   实际请求

   使用实际请求：

   1. 如果您无法访问向目标/后端服务器发出的实际请求，请前往问题解决。
   2. 如果您有权访问向目标/后端服务器发出的实际请求，请执行以下步骤：
      1. 验证响应中传递的载荷大小以及响应中发送的 Content-Encoding 标头。
      2. 如果您发现响应标头 Content-Encoding 设置为 gzip，并且载荷的未压缩大小超过了 Apigee Edge 中允许的限制，则这是导致此错误的原因。

         从后端服务器收到的响应示例：

         curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz
         

         * About to connect() to 10.1.0.10 port 9000 (#0)
         *   Trying 10.1.0.10...
         * Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0)
         > GET /testzippedfile.gz HTTP/1.1
         > User-Agent: curl/7.29.0
         > Host: 10.1.0.10:9000
         > Accept: */*
         >
         < HTTP/1.1 200 OK
         < Accept-Ranges: bytes
         < Content-Encoding: gzip
         < Content-Type: application/x-gzip
         < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
         < Testheader: test
         < Date: Wed, 07 Jul 2021 10:14:16 GMT
         < Transfer-Encoding: chunked
         <
         ----snipped----
         <Response Body>

         在上述情况下，系统会发送标头 Content-Encoding: gzip，并且响应中文件 testzippedfile.gz 的大小小于限制，但未压缩文件 testzippedfile 的大小约为 15 MB。

   消息处理器日志

   使用消息处理器日志：

   1. 如果您是私有云用户，则可以使用消息处理器日志来确定有关 HTTP 502 错误的关键信息。

   2. 检查消息处理器日志

      /opt/apigee/var/log/edge-message-processor/logs/system.log

   3. 搜索以查看特定时间段内（如果问题发生在过去）是否存在任何 502 错误，或者是否仍有请求失败并显示 502。您可以使用以下搜索字符串：

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. 您会发现 system.log 中的行与下图中所示的类似（TotalRead 和 chunkCount 可能因您的具体情况而异）：

      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
      TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
      TotalRead 10489856 chunkCount 2571
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
      HTTPClient$Context.onInputException() :
      ClientInputChannel(ClientChannel[Connected:
      Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
      useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
      isOpen=true).onExceptionRead exception: {}
      com.apigee.errors.http.server.BadGateway: Body buffer overflow
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR
      ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
      AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
      Body buffer overflow)

   5. 在解压缩过程中，当消息处理器确定总读取字节数大于 10 MB 时，它会停止并输出以下行：

      Message is too large. TotalRead 10489856 chunkCount 2571

      这表示响应载荷大小超过 10 MB，当大小开始超出 10 MB 的限制时，Apigee 会抛出错误，并将故障代码设置为 protocol.http.TooBigBody

分辨率

限制

Apigee 希望客户端应用和后端服务器不要发送大于 Apigee Edge 限制中针对 Request/response size 记录的允许限制的载荷大小。

1. 如果您是公共云用户，则请求和响应载荷大小的上限与 Apigee Edge 限制中针对 Request/response size 记录的上限相同。
2. 如果您是私有云用户 ，则可能修改了请求和响应载荷大小的默认最大限制（即使不建议这样做）。 您可以按照如何查看当前限制中的说明确定请求载荷大小上限。

如何查看当前限额？

本部分介绍如何验证消息处理器上的属性 HTTPResponse.body.buffer.limit 是否已更新为新值。

1. 在消息处理器机器上，在 /opt/apigee/edge-message- processor/conf 目录中搜索属性 HTTPResponse.body.buffer.limit，并检查已设置的值，如下所示：

   grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
   

2. 上述命令的示例结果如下所示：

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m

3. 在上面的示例输出中，请注意，属性 HTTPResponse.body.buffer.limit 已在 http.properties 中设置为值 10m。

   这表示 Apigee for Private Cloud 中配置的请求载荷大小上限为 10 MB。

如果您仍然需要 Apigee 支持团队提供任何帮助，请参阅 必须收集诊断信息。

必须收集的诊断信息

收集以下诊断信息，然后与 Apigee Edge 支持团队联系：

如果您是公共云用户，请提供以下信息：

• 组织名称
• 环境名称
• API 代理名称
• 用于重现 502 错误的完整 curl 命令
• API 请求的轨迹文件
• 来自目标/后端服务器的响应的完整输出，以及载荷的大小

如果您是私有云用户，请提供以下信息：

• 失败请求的完整错误消息
• 组织名称
• 环境名称
• API 代理软件包
• 失败的 API 请求的轨迹文件
• 用于重现 502 错误的完整 curl 命令
• 来自目标/后端服务器的响应的完整输出，以及载荷的大小

• NGINX 访问日志 /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  其中： ORG、ENV 和 PORT# 会替换为实际值。

• 消息处理器系统日志 /opt/apigee/var/log/edge-message-processor/logs/system.log