應用程式閘道中的 HTTP 回應碼

本文提供 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 和其他驗證提供者。 如需詳細資訊，請參閱下列文章。

應用程式閘道 V2 SKU 支援的計量診斷記錄

400 – 不正確的要求

HTTP 400 回應碼通常會在下列情況下產生：

• 使用 HTTP 或 HTTPS 接聽程式起始傳至應用程式閘道的非 HTTP/HTTPS 流量。
• 起始 HTTP 流量傳至使用 HTTPS 的接聽程式，且未設定重新導向。
• 已設定相互驗證，且無法正確交涉。
• 要求不符合 RFC 規範。

要求不符合 RFC 規範的一些常見原因如下：

類別	範例
要求行中的主機無效	包含兩個冒號的主機 (example.com:8090:8080)
遺漏主機標頭	要求不包含主機標頭
字元格式錯誤或不合法	保留字元為 &,!.因應措施是將其編碼為百分比。 例如：%&
HTTP 版本無效	Get /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 SKU 且已在防止模式中設定 WAF 時，會顯示「HTTP 403 禁止」。 如果啟用的 WAF 規則集或自訂拒絕 WAF 規則符合輸入要求的特性，則會向用戶端顯示「403 禁止」回應。

用戶端收到 403 回應的其他原因包括：

• 您要使用 App Service 作為後端，且其設定為只允許從應用程式閘道存取。 應用程式服務可能會傳回 403 錯誤。 這通常是因為重新導向/href 連結直接指向應用程式服務，而不是指向應用程式閘道的 IP 位址。
• 如果您要存取儲存體部落格，但應用程式閘道和儲存體端點位於不同的區域，則在不允許列出應用程式閘道的公用 IP 位址時，會傳回 403 錯誤。 請參閱授與網際網路 IP 範圍存取權。

404 – 找不到頁面

如果要求傳送至下列情況的應用程式閘道，則會傳回 HTTP 404 回應：

• 使用 v2 sku。
• 主機名稱不符合任何多網站接聽程式的定義。
• 未設定基本接聽程式。

408 – 要求逾時

如果應用程式閘道前端接聽程式的用戶端要求沒有在 60 秒內回應，即會產生 HTTP 408 回應。 由於內部部署網路與 Azure 之間的流量壅塞，若虛擬裝置檢查流量或用戶端本身出現超載情形，即會發生此錯誤。

413 – 要求實體太大

在應用程式閘道上使用 Azure Web 應用程式防火牆時，若用戶端要求大小超過要求本文大小上限，則可以觀察到 HTTP 413 回應。 要求主體大小上限欄位會控制整體要求大小限制 (不包括任何檔案上傳)。 要求主體大小的預設值為 128 KB。 如需詳細資訊，請參閱 Web 應用程式防火牆要求大小限制。

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 應用程式閘道 V1 SKU 就會傳送 HTTP 502 錯誤。

如需深入了解發生 502 錯誤的案例以及疑難排解方式，請參閱針對不正確的閘道錯誤進行疑難排解。

504 – 閘道逾時

如果後端回應時間超過後端設定中所設定的逾時值，Azure 應用程式閘道 V2 SKU 就會傳送 HTTP 504 錯誤。

IIS

如果您的後端伺服器是 IIS，請參閱網站的預設限制來設定逾時值。 如需詳細資料，請參閱 connectionTimeout 屬性。 請確定 IIS 中的連線逾時值符合或未超過後端設定中所設定的逾時值。

nginx

如果後端伺服器是 nginx 或 nginx 輸入控制器，且其具有上游伺服器，請確定 nginx:proxy_read_timeout 的值符合或未超過後端設定中所設定的逾時。

下一步

如果本文中的資訊無法協助解決問題，請提交支援票證。