本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 針對 API Gateway 中的回應串流問題進行故障診斷
<a name="response-streaming-troubleshoot"></a>

下列疑難排解指引可能有助於解決使用回應串流APIs 的問題。

## 一般性問題的故障診斷
<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_tw/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)。