總結
本文說明為何 Azure 應用閘道會回傳特定的 HTTP 回應碼。 它提供常見原因與故障排除步驟，幫助您找出錯誤 HTTP 回應碼的根本原因。 應用閘道（Application Gateway）可對客戶端請求回傳 HTTP 回應代碼，無論該請求是否發起後端目標的連線。
備註
若用戶端連線在應用閘道回傳任何 HTTP 回應前失敗，則很可能是傳輸層安全（TLS）握手失敗。 常見原因包括 TLS 版本不符（例如用戶端使用 TLS 1.0 或 1.1，而閘道器則要求 TLS 1.2 或更高）以及不支援的密碼套件。 自 2025 年 8 月 31 日起，Azure 應用閘道停止支援 TLS 1.0 與 1.1。 欲了解更多資訊，請參閱 應用閘道 TLS 政策概述 及 配置 TLS 政策版本與密碼套件。
3XX 回應碼 (重新導向)
當用戶端請求符合已設定重定向的應用閘道規則時，應用閘道會回傳 300-399 個回應。 你可以在規則 as-is 或路徑圖規則上設定重定向。 如需重新導向的詳細資訊，請參閱應用程式閘道重新導向概觀。
301 永久轉接
當你指定帶有 永久 值的重定向規則時，應用閘道會回傳 HTTP 301 回應。
302 已找到
當你指定帶有 Found 值的重定向規則時，Application Gateway 會回傳 HTTP 302 回應。
303 參見其他
應用閘道在指定帶有 「查看其他 」值的重定向規則時，會回傳 HTTP 303 回應。
307 臨時轉址
應用閘道在你指定帶有 Temporary 值的重定向規則時，會回傳 HTTP 307 回應。
4XX 回應碼 (用戶端錯誤)
400-499 回應代碼表示客戶端發起的問題。 這些問題的範圍從用戶端起始要求到不相符的主機名、要求逾時、未經驗證的要求、惡意要求等等。
應用閘道收集捕捉 4xx/5xx 狀態碼分布的指標，並具備日誌機制，能捕捉如 URI 用戶端 IP 位址及回應碼等資訊。 計量和記錄可讓您進一步進行疑難排解。 用戶端也可能從用戶端與應用程式閘道之間的其他代理伺服器接收到 4xx 回應。 例如，CDN（內容傳遞網路）和其他驗證提供者。 如需詳細資訊，請參閱下列文章。
400 – 錯誤請求
你通常會在以下情況下看到 HTTP 400 回應代碼：
- 你用 HTTP 或 HTTPS 監聽器發起非 HTTP 或 HTTPS 流量到應用閘道。
- 你用 HTTPS 啟動 HTTP 流量給監聽者，且沒有設定重定向。
- 你設定了互助認證，但應用閘道無法妥善協商。
- 這個請求不符合 RFC 規定。
請求不符合 RFC 的常見原因包括：
| 類別 | 範例 |
|---|---|
| 請求行中的主機無效 | 包含兩個冒號的主機 (example.com:8090:8080) |
| 遺漏主機標頭 | 要求缺少 Host 標頭 |
| 存在格式不正確或不合法的字元 | 保留字元為 &,!.因應措施是將其編碼為百分比。 例如：%& |
| HTTP 版本無效 | 取得 /content.css HTTP/0.3 |
| 標頭欄位名稱和 URI 包含非 ASCII 字元 | GET /«úü？»¿.doc HTTP/1.1 |
| POST 要求遺漏內容長度標頭 | 不言自明 |
| HTTP 方法無效 | GET123 /index.html HTTP/1.1 |
| 標頭重複 | Authorization:<base64 編碼內容>, Authorization: <base64 編碼內容> |
| Content-Length 中的值無效 | Content-Length: abc、Content-Length: -10 |
當你設定互認證時，有幾種情境可能導致客戶端收到 HTTP 400 回應，包括：
- 你啟用了互助認證，但客戶端憑證沒有顯示。
- 你啟用了 Distinguished Name（DN）驗證，但客戶憑證的 DN 與指定憑證鏈的 DN 不符。
- 用戶端憑證鏈結不符合已定義的 SSL 原則所設定的憑證鏈結。
- 用戶端憑證過期。
- 你啟用線上憑證狀態協定（OCSP）用戶端撤銷檢查，憑證就會被撤銷。
- 你啟用了 OCSP 用戶端撤銷檢查，但應用程式閘道無法聯絡 OCSP 回應者。
- 你啟用了 OCSP 用戶端撤銷檢查，但憑證中沒有提供 OCSP 回應器。
如需疑難排解相互驗證的詳細資訊，請參閱錯誤碼疑難排解。
401 - 未經授權
若用戶端未被授權存取資源，應用閘道會回傳 HTTP 401 未經授權回應給用戶端。 401 錯誤碼的返回有幾個原因。 以下列出幾個原因及其可能的解決方法。
- 如果用戶端具有存取權，則可能含有已過時的瀏覽器快取。 請清除瀏覽器快取，然後嘗試重新存取應用程式。
若你設定後端池採用 NTLM 認證，應用閘道器可回傳 HTTP 401 未授權回應 AppGW 探測請求。 在這種情況下，應用閘道會將後端標記為健康狀態。 請使用以下其中一種方法解決此問題：
- 允許對後端集區進行匿名存取。
- 設定探測器，將請求傳送至另一個不需要 NTLM 的偽裝網站。
- 不建議這麼做，因為這個解決方案無法告訴我們應用程式閘道後方的實際站點是否仍在運作。
- 將應用程式閘道設定為允許 401 回應對探查有效：探查比對條件。
403 - 禁止
當你使用 WAF（Web Application Firewall）SKUS 並將 WAF 設定為預防模式時，Application Gateway 會顯示 HTTP 403 禁止。 若啟用 WAF 規則集或自訂拒絕 WAF 規則符合入站請求的特性，應用閘道會向用戶端呈現 403 禁止回應。
若要排解 WAF 誤報（被 WAF 規則阻擋的合法請求）：
- 啟用 WAF 診斷日誌 ，並檢視
ruleId_s欄位以找出阻擋請求的規則。 - 暫時將 WAF 切換到 偵測模式 ，以記錄匹配規則而不阻擋流量。 這種方法能幫助你在修改規則前確認誤判。 如需詳細資訊，請參閱 WAF 原則設定。
- 為觸發誤判的特定請求屬性（標頭、Cookie 或參數）建立 WAF 排除 。
- 如果某個受管理規則持續造成誤報且排除措施不足，請在 WAF 政策中 停用該個別規則 。
欲了解更多詳細指引，請參閱《 應用閘道故障排除 WAF 》及 WAF 最佳實務。
用戶端收到 403 回應的其他原因包括：
- h2c 協定升級嘗試：當用戶端使用 h2c 協定（HTTP/2 明文）從 HTTP/1.1 升級到 HTTP/2.0 時，Application Gateway 會回傳 403 錯誤。 應用閘道僅支援 HTTP/2 over TLS（HTTPS 監聽器）。 它不支援 HTTP 監聽器上的 h2c 協定升級。 這種行為不論為何種 WAF 模式都會發生。 用戶端應使用原生 HTTP/2 連線，或維持 HTTP/1.1 連線，無需升級嘗試。
- 你是用 App Service 作為後端，並且設定它只允許從 Application Gateway 存取。 此配置可能會由 App Services 回傳 403 錯誤。 此錯誤通常是因為重定向或 href 連結直接指向 App Services，而非指向應用閘道的 IP 位址所造成的。
- 如果你存取的是儲存區，而應用程式閘道器和儲存端點位於不同區域，那麼如果應用閘道的公開 IP 位址未被列入允許清單，就會回傳 403 錯誤。 請參閱授與網際網路 IP 範圍存取權。
404 – 找不到頁面
當你向應用程式閘道（V2 SKU）提出請求，且主機名稱不對應任何已設定的多站監聽器，且沒有 Basic 監聽器時，會產生 HTTP 404 回應。 欲了解更多，請參閱 聽眾類型。
408 – 請求暫停
當用戶端向應用閘道前端監聽者請求未在 60 秒內回應時，可以觀察到 HTTP 408 的回應。 你可能會因為本地網路與 Azure 之間的流量擁塞、虛擬設備檢查流量時，或是用戶端本身負載過重，而觀察到這個錯誤。
413 – 請求實體過大
當你在 應用閘道使用Azure Web Application Firewall 時，可以觀察到HTTP 413回應，且用戶端請求大小超過最大請求體大小限制。 要求主體大小上限欄位會控制整體要求大小限制 (不包括任何檔案上傳)。 要求主體大小的預設值為 128 KB。 更多資訊請參見 Web Application Firewall 請求大小限制。
499 – 用戶端關閉連線
如果你用 v2 SKU 向應用程式閘道發送的客戶端請求在伺服器回應結束前被關閉，就會顯示 HTTP 499 回應。 你可以在兩種情境中觀察到這種誤差。 第一個案例是將大型回應傳回給用戶端，而用戶端可能會在伺服器完成傳送大型回應之前關閉或重新整理應用程式。 第二個案例是用戶端逾時不足，且等候的時間不夠長，無法從伺服器接收回應。 在這種情況下，最好是延長客戶端設定的超時時間。 在使用 v1 SKU 的應用閘道中，當客戶端在伺服器完成回應之前就關閉連線時，可能會出現 HTTP 0 回應碼。
5XX 回應碼 (伺服器錯誤)
500-599 的回應碼表示執行請求時，應用程式閘道或後端伺服器出現問題。
500 – 內部伺服器錯誤
Azure Application Gateway 不應該回傳 500 個回應碼。 如果您看到這個代碼，請開啟支援要求，因為此問題是服務的內部錯誤。 關於如何開啟支援請求，請參見 建立 Azure 支援請求。
502 – 壞閘道
HTTP 502 錯誤可能有多種根本原因，包括：
- NSG （網路安全組）、UDR（使用者定義的路由），或自定義 DNS 封鎖對後端集區成員的存取。
- 虛擬機器擴展集的後端虛擬機器或其執行個體未回應預設的健全性探查。
- 無效或不適當的自訂的健康探測器組態。
- Azure Application Gateway 的 後端池沒有設定或空。
- 虛擬機器擴展集中的虛擬機器或執行個體全都狀態不佳
- 請求逾時或連線問題 在使用者請求Azure應用 Gateway V1 SKU 中，若後端回應時間超過後端設定中設定的逾時值，會發送 HTTP 502 錯誤。
如需深入了解發生 502 錯誤的案例以及疑難排解方式，請參閱針對不正確的閘道錯誤進行疑難排解。
503 – 無法提供服務
HTTP 503 回應表示應用閘道或後端伺服器暫時無法處理該請求。 常見的原因包括：
- 所有後端池成員皆被健康探測視為不健康，且沒有健康的伺服器可用來處理請求。
- 後端伺服器過載或正在維護中，直接將 503 返回應用程式閘道。
- Application Gateway V2 的自動擴展正在進行中，新的實例尚未準備好處理流量。
- 應用程式閘道或後端伺服器的連接已達到限制。
要排除 503 錯誤：
- 請在 Azure 入口網站的 後端健康 面板確認後端池成員狀態。
- 檢視健康檢查設定，確保探針不會錯誤地將健康的後端標記為不健康。 欲了解更多資訊，請參閱 健康探針概述。
- 透過直接存取後端應用程式，繞過應用程式閘道來驗證其運作。
- 檢查 Azure Monitor 中的應用程式閘道連線數量與容量單元利用率指標。
- 對於 V2 SKU，請檢視自動縮放設定，以確保流量高峰期間有足夠的最低實例數。
欲了解更多資訊，請參閱 「後端健康問題故障排除」。
504 – 閘道逾時
Azure Application Gateway V2 SKU 如果後端回應時間超過你在後端設定中設定的逾時值，會發送 HTTP 504 錯誤。
IIS（Internet Information Services網頁伺服器）
如果您的後端伺服器是 IIS，請參閱 網站的預設限制 來設定逾時值。 如需詳細資料，請參閱 connectionTimeout 屬性。 確保 IIS 的連線逾時與後端設定相符，或不超過後端設定的逾時。
Nginx
如果後端伺服器是 Nginx 或 Nginx Ingress Controller，且有上游伺服器，請確保 nginx:proxy_read_timeout 的值匹配或不超過後端設定的逾時值。
疑難排解案例
存取日誌中的「ERRORINFO_INVALID_HEADER」錯誤
問題： 存取日誌 顯示請求的「ERRORINFO_INVALID_HEADER」錯誤，儘管後端回應碼（serverStatus）是 200。 在其他情況下，後端伺服器回傳 500。
原因：用戶端傳送包含 CR LF 字元的標頭。
解決方案：將CR LF 字元取代為SP（空格元），並將要求重新傳送至應用程式閘道。
後續步驟
如果本文的資訊無法幫助你解決問題，請 提交客服單。