# 在 API Gateway 中排查响应流式传输问题
<a name="response-streaming-troubleshoot"></a>

以下故障排除指南可帮助解决使用响应流式传输的 API 问题。

## 一般故障排除
<a name="response-streaming-general-troubleshooting"></a>

您可以使用 [TestInvokeMethod](https://docs.aws.amazon.com/apigateway/latest/api/API_TestInvokeMethod.html) 或控制台的“测试”选项卡测试响应流式传输。使用测试调用功能进行响应流式传输时需注意以下事项：
+ 在测试方法时，API Gateway 会缓冲您的流式响应有效载荷。满足以下任一条件后，API Gateway 将返回包含缓冲的有效载荷的一次性响应：
  + 请求已完成
  + 已过去 35 秒
  + 已缓冲超过 1 MB 的响应有效载荷
+ 如果方法在 35 秒内未返回 HTTP 响应状态和所有标头，TestInvokeMethod 返回的响应状态为 0。
+ API Gateway 不会生成任何执行日志。

部署 API 后，可通过 curl 命令测试流式响应。建议使用 `-i` 选项在输出中包含协议响应标头。如需实时查看到达的响应数据，使用 curl 选项 `--no-buffer`。

## 排查 curl 错误
<a name="response-streaming-troubleshoot-curl-error"></a>

如果测试集成时出现 `curl: (18) transfer closed with outstanding read data remaining` 错误，需确保集成超时时间足够长。如果您使用的是 Lambda 函数，则需要更新 Lambda 函数的响应超时。有关更多信息，请参阅[配置 Lambda 函数超时](https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html)。

## 通过访问日志排查问题
<a name="response-streaming-troubleshoot-access-logging"></a>

可通过 REST API 阶段的访问日志记录并排查响应流问题。除现有变量外，还可使用以下访问日志变量：

`$context.integration.responseTransferMode`  
您的集成的响应传输模式。此值可以是 `BUFFERED` 或 `STREAMED`。

`$context.integration.timeToAllHeaders`  
从 API Gateway 建立集成连接到从客户端接收所有集成响应头之间的时间间隔。

`$context.integration.timeToFirstContent`  
API Gateway 建立集成连接到接收第一个内容字节之间的时间间隔。

`$context.integration.latency` 或 `$context.integrationLatency`  
从 API Gateway 建立集成连接到集成响应流完成之间间隔的时间。

下图展示了这些访问日志变量如何表示响应流的不同组成部分。

![\[API Gateway 中响应流的访问日志变量\]](http://docs.aws.amazon.com/zh_cn/apigateway/latest/developerguide/images/response-streaming-figure.png)


有关访问日志的更多信息，请参阅 [为 API Gateway 中的 REST API 设置 CloudWatch 日志记录](set-up-logging.md)。您也可以使用 X-Ray 来监控您的响应流。有关更多信息，请参阅 [在 API Gateway 中使用 X-Ray 跟踪用户对 REST API 的请求](apigateway-xray.md)。