總結
本文說明了為什麼 Azure 應用程式閘道 會回傳特定的 HTTP 回應碼。 其中提供常見的原因和疑難排解步驟，以協助您判斷錯誤 HTTP 回應碼的根本原因。 不論是否已起始對後端目標的連線，都會傳回用戶端要求的 HTTP 回應碼。
3XX 回應碼 (重新導向)
當用戶端要求符合已設定重新導向的應用程式閘道規則時，會顯示 300-399 回應。 您可以依原樣或透過路徑對應規則，在規則中設定重新導向。 如需重新導向的詳細資訊，請參閱應用程式閘道重新導向概觀。
301 永久重新導向
使用永久值指定重新導向規則時，會顯示 HTTP 301 回應。
302 已找到
使用已找到值指定重新導向規則時，會顯示 HTTP 302 回應。
303 參見其他
使用查看其他值指定重新導向規則時，會顯示 HTTP 302 回應。
307 暫時重新導向
使用暫時值指定重新導向規則時，會顯示 HTTP 307 回應。
4XX 回應碼 (用戶端錯誤)
400-499 回應碼表示問題來自於用戶端。 這些問題的範圍從用戶端起始要求到不相符的主機名、要求逾時、未經驗證的要求、惡意要求等等。
應用程式閘道會收集有關 4xx/5xx 狀態碼的計量，其中包括這些狀態碼的分佈。它也有一個記錄機制，可以擷取如 URI、用戶端 IP 位址與回應碼等資訊。 計量和記錄可讓您進一步進行疑難排解。 用戶端也可以從用戶端裝置與應用程式閘道之間的其他 Proxy 接收 4xx 回應。 例如，CDN（內容傳遞網路）和其他驗證提供者。 如需詳細資訊，請參閱下列文章。
- Application Gateway V2 SKU 支援的指標
- 診斷記錄
400 – 錯誤請求
HTTP 400 回應碼通常會在下列情況下產生：
- 非 HTTP/HTTPS 的流量由使用 HTTP 或 HTTPS 傾聽程式的應用程式閘道發起。
- 起始 HTTP 流量傳至使用 HTTPS 的接聽程式，且未設定重新導向。
- 相互驗證已設定，但未能正確協商。
- 要求不符合 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 回應傳回至用戶端，例如：
- 已啟用相互驗證，但未顯示客戶端憑證。
- DN （辨別名稱） 驗證已啟用，且客戶端憑證的 DN 不符合指定憑證鏈結的 DN。
- 用戶端憑證鏈結不符合已定義的 SSL 原則所設定的憑證鏈結。
- 用戶端憑證過期。
- OCSP （在線憑證狀態通訊協定） 客戶端撤銷檢查已啟用，並撤銷憑證。
- 已啟用 OCSP（在線憑證狀態通訊協定）用戶端撤銷檢查，但無法聯絡上。
- OCSP （在線憑證狀態通訊協定） 客戶端撤銷檢查已啟用，但憑證中未提供 OCSP 回應程式。
如需疑難排解相互驗證的詳細資訊，請參閱錯誤碼疑難排解。
401 - 未經授權
如果用戶端未獲授權存取資源，則會將 HTTP 401 未經授權的回應傳回給用戶端。 傳回 401 狀態碼的原因有幾個。 以下是可能修正的一些原因。
- 如果用戶端具有存取權，則可能含有已過時的瀏覽器快取。 請清除瀏覽器快取，然後嘗試重新存取應用程式。
如果後端集區已設定 NTLM 驗證，則可以將 HTTP 401 未經授權的回應傳回給 AppGW 探查要求。 在此情況下，後端會標記為狀況良好。 有幾個方式可以解決此問題：
- 允許對後端集區進行匿名存取。
- 設定探測器，將請求傳送至另一個不需要 NTLM 的偽裝網站。
- 不建議這樣做，因為這樣做不會告訴我們應用程式閘道背後的實際網站是否為作用中。
- 將應用程式閘道設定為允許 401 回應對探查有效：探查比對條件。
403 - 禁止
當客戶使用 WAF（Web 應用程式防火牆）skus 並將 WAF 設定為防禦模式時，會顯示 HTTP 403 禁止。 如果啟用的 WAF 規則集或自訂拒絕 WAF 規則符合輸入要求的特性，則會向用戶端顯示「403 禁止」回應。
用戶端收到 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 作為後端，且其設定為只允許從應用程式閘道存取。 應用程式服務可能會傳回 403 錯誤。 這通常是因為重新導向/href 連結直接指向應用程式服務，而不是指向應用程式閘道的 IP 位址。
- 如果您要存取儲存帳戶，但應用程式閘道和儲存端點位於不同的區域，則如果應用程式閘道的公用 IP 位址沒有被列入允許清單，會傳回 403 錯誤。 請參閱授與網際網路 IP 範圍存取權。
404 – 找不到頁面
對應用程式閘道 （V2 SKUs）提出要求時，若主機名未對應至任何已設定的多重網站接聽程式，且沒有基本型接聽程式存在，則會產生 HTTP 404 回應。 深入瞭解 聆聽者類型。
408 – 要求逾時
如果應用程式閘道前端接聽程式的用戶端要求沒有在 60 秒內回應，即會產生 HTTP 408 回應。 此錯誤可能因本地網路與 Azure 之間的流量擁塞而觀察到，當虛擬設備對流量進行檢查，或用戶端本身超載時。
413 – 要求實體太大
當在應用閘道使用
499 – 用戶端關閉連線
如果在伺服器完成回應之前，關閉傳送至使用 v2 sku 的應用程式閘道的用戶端要求，則會顯示 HTTP 499 回應。 在 2 個案例中可以觀察到此錯誤。 第一個案例是將大型回應傳回給用戶端，而用戶端可能會在伺服器完成傳送大型回應之前關閉或重新整理應用程式。 第二個案例是用戶端逾時不足，且等候的時間不夠長，無法從伺服器接收回應。 在此情況下，最好增加用戶端上的超時時間。 在使用 v1 SKU 的應用程式閘道器中，若在伺服器完成回應之前用戶端關閉連線，可能會出現 HTTP 0 回應碼。
5XX 回應碼 (伺服器錯誤)
500-599 回應碼表示執行要求時，應用程式閘道或後端伺服器發生問題。
500 – 內部伺服器錯誤
Azure 應用程式閘道 不應該顯示 500 個回應碼。 如果您看到這個代碼，請開啟支援要求，因為此問題是服務的內部錯誤。 關於如何開啟支援請求，請參見 建立 Azure 支援請求。
502 – 不正確的閘道
HTTP 502 錯誤的根本原因有幾個，例如：
- NSG （網路安全組）、UDR（使用者定義的路由），或自定義 DNS 封鎖對後端集區成員的存取。
- 虛擬機器擴展集的後端虛擬機器或其執行個體未回應預設的健全性探查。
- 無效或不適當的自訂的健康探測器組態。
- Azure 應用程式閘道 的 後端池沒有設定或空。
- 虛擬機器擴展集中的虛擬機器或執行個體全都狀態不佳
- 請求逾時或連線問題 在使用者請求Azure應用 Gateway V1 SKU 中，若後端回應時間超過後端設定中設定的逾時值，會發送 HTTP 502 錯誤。
如需深入了解發生 502 錯誤的案例以及疑難排解方式，請參閱針對不正確的閘道錯誤進行疑難排解。
504 – 閘道逾時
如果後端回應時間超過後端設定中設定的逾時值，Azure 應用閘道 V2 SKU 會發送 HTTP 504 錯誤。
IIS（Internet Information Services網頁伺服器）
如果您的後端伺服器是 IIS，請參閱 網站的預設限制 來設定逾時值。 如需詳細資料，請參閱 屬性。 請確定 IIS 中的連線逾時符合或未超過後端設定中設定的逾時。
Nginx
如果後端伺服器是 Nginx 或 Nginx Ingress 控制器，且具有上游伺服器，請確保 的值符合或不超過後端設定中的逾時值。
疑難解答案例
存取記錄中的「ERRORINFO_INVALID_HEADER」錯誤
問題：儘管後端回應碼 （serverStatus） 為 200， 存取記錄 檔仍會顯示要求的「ERRORINFO_INVALID_HEADER」錯誤。 在其他情況下，後端伺服器可能會傳回 500。
原因：客戶端會傳送包含CR LF字元的標頭。
解決方案：將CR LF 字元取代為SP（空格元），並將要求重新傳送至應用程式閘道。
後續步驟
如果本文中的資訊無法協助解決問題，請提交技術支援請求。