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

故障診斷 Lambda Web 函數

從資源狀態、HTTP 回應和請求的日誌開始。Web 函數會公開函數、修訂版、端點和 MultiRegion或 PerRegion 端點的每個區域的不同狀態。一個資源中的失敗不一定會變更其他資源的狀態。

收集診斷資訊

部署和啟動問題

為了避免重複部署失敗，請先驗證測試修訂中的組態和啟動，再建立生產修訂。

CLI 和套件錯誤

HTTP 請求失敗

請求標頭限制

兩個限制適用於請求標頭。Lambda 會將標頭區塊限制為 128 KiB，並在到達您的函數之前拒絕較大的請求。函數中的 Node.js HTTP 伺服器也會限制其接受的標頭行數。兩者都會傳回 HTTP 431 請求標頭欄位太大，如下表所示。如需平台限制，請參閱 標頭限制。

大小限制會在用戶端傳送請求頭時計數每個位元組。這包括請求行、每個標頭行 （包括用戶端程式庫新增Host的任何標頭），以及行終端器。Lambda 新增的標頭不會計入大小限制。

當請求超過大小限制時，Lambda 會在到達您的函數之前拒絕該請求，因此請求不會產生叫用，也不會產生應用程式日誌項目。lambda-web-error-type 回應標頭可識別原因。

Node.js 計數限制計算標頭行，而不是不同的標頭名稱。重複三次的標頭會計數三次。因此，透過代理鏈累積x-forwarded-for或追蹤標頭的請求可以達到限制。沒有單一標頭需要看起來不尋常，才會發生這種情況。限制是根據函數收到的請求來衡量，其中包含 Lambda 新增的標頭。因此，傳送稍微少於 1，000 個標頭行的用戶端可以到達它。發生這種情況時，請求會到達您的執行環境，而Node.js伺服器會在剖析期間拒絕它。您的處理常式不會執行。回應會攜帶 lambda-web-request-id和 lambda-web-logstream標頭，但不會攜帶 lambda-web-error-type標頭。

如果您的應用程式必須接受超過Node.js預設允許的標頭行，請提高伺服器程式碼中的Node.js限制。將 server.maxHeadersCount設定為要接受的標頭行數，或將其設定為 0以停用Node.js計數檢查。128 KiB 大小限制仍然適用。

const server = http.createServer(handler);
server.maxHeadersCount = 2000;
server.listen(port, host);

您不需要變更Node.js標頭大小限制。受管Node.js執行時間會將其設定為符合平台限制，因此平台限制會套用至標頭大小。您無法從應用程式程式碼提高平台限制。

若要保持在限制內，請將大量狀態移出 標頭並移入請求內文、修剪 Cookie，以及在請求到達端點之前摺疊備援代理和追蹤標頭。如果 CloudFront 分佈位於端點前面，則僅轉送您的應用程式在原始伺服器請求政策中所需的標頭。

Web 函數錯誤類型

當對 Web 函數端點的請求失敗時，Lambda 會傳回lambda-web-error-type回應標頭，以識別錯誤。此值使用 格式<Prefix>.<ErrorReason>：字首 會告訴您錯誤發生的位置，以及原因指定原因。

例如， Runtime.RequestTimeout表示受管執行時間報告您的函數未在其設定的逾時內回應，而 Application.InitCodeError表示您自己的初始化程式碼擲出錯誤。

當錯誤是由請求本身或您的函數、其組態或其程式碼所造成時，Lambda 會包含 lambda-web-error-type標頭。Lambda 會針對內部服務錯誤和授權失敗省略 標頭，因此不會向未經授權的發起人揭露任何詳細資訊。值表示 Lambda 平台和函數之間的路徑發生問題。在請求路徑上，錯誤會識別請求失敗的位置。在回應路徑上，將 值與您的應用程式遙測一起使用，以了解發生的情況。

如需識別套用哪些限制的限流指標 （適用於 Platform.AccountRequestThrottle、Platform.AccountActiveVCPUArm64Throttle、 和 Platform.EndpointMaxEnvThrottle錯誤類型）Platform.EndpointRequestThrottle，請參閱 區域用量和限流指標。

日誌或指標遺失

如果完全沒有應用程式日誌出現，執行角色可能缺少 Amazon CloudWatch Logs 許可。將 AWSLambdaBasicExecutionRole受管政策連接至執行角色，或授予 logs:CreateLogGroup、 logs:CreateLogStream和 logs:PutLogEvents。如要了解必要的許可，請參閱 執行角色。

程式碼儲存和加密問題

MultiRegion 和 PerRegion端點的問題

使用 regionalEndpoints 欄位來識別受影響的區域。比較其 stateReason和 updateStatusReason與運作狀態良好的區域。檢查區域配額、 AWS KMS 金鑰複本、執行時間可用性，以及修訂的複寫狀態。修正原因後，重複端點更新。如需複寫模型，請參閱 多區域部署。

對於MultiRegion端點，以延遲為基礎的路由 （將請求導向測量到最低延遲的區域） 不保證每個請求都會進入最低延遲的區域。從受影響的用戶端位置進行測試，並檢查應用程式日誌，以判斷處理請求的區域。對於PerRegion端點，也請驗證外部 DNS 或前門路由組態。

網路和連線問題

大多數連線問題來自沒有連接器參考或參考舊版連接器的服務修訂版，或來自封鎖流量的連接器子網路、安全群組或路由。

使用下列序列來隔離連線問題：

常見的症狀包括下列項目。

沒有 Web Function 執行環境的互動式存取權。使用應用程式日誌、端點回應標頭、資源狀態欄位、CloudWatch 指標和 VPC 流程日誌來診斷失敗。

準備呈報套件

如果上述檢查無法識別原因，請在開啟 AWS 支援 案例之前收集下列資訊。這可讓支援工程師關聯控制平面操作、區域部署、請求和遙測：

相關資訊