針對應用程式閘道中的App Service問題進行疑難排解

瞭解如何診斷並解決使用 Azure App 服務 作為具有 Azure 應用程式閘道 的後端目標時可能會遇到的問題。

概觀

在本文中,您將瞭解如何針對下列問題進行疑難排解,如架構中心所述: 保留反向 Proxy 與其後端 Web 應用程式之間的原始 HTTP 主機名稱

  • 不正確的絕對 URL
  • 不正確的重新導向 URL
    • 當重新導向時,應用程式服務 URL 會在瀏覽器中公開
    • 此範例:OIDC 驗證流程因主機名稱錯誤而中斷;這包括使用App Service 驗證和授權
  • Cookie 中斷
    • Cookie 不會在瀏覽器與App Service之間傳播
    • 此範例:App Service ARRAffinity Cookie 網域設定為 App Service 主機名稱,並系結至 「example.azurewebsites.net」,而不是原始主機。 因此,會話親和性會中斷。

上述徵兆的根本原因是安裝程式會覆寫應用程式閘道App Service到瀏覽器所見的不同主機名稱所使用的主機名稱。 主機名稱通常會覆寫到預設App Service 「azurewebsites.net」 網域。

Root cause - Application Gateway overwrites hostname to azurewebsites.net

範例組態

如果您的設定符合下列兩種情況之一,您的設定會受限於本文中的指示:

  • HTTP 設定中已啟用後端位址的 [挑選主機名稱]
  • 使用特定功能變數名稱覆寫 會設定為不同于瀏覽器要求的值

原因

App Service是多租使用者服務,因此它會使用要求中的主機標頭,將要求路由傳送至正確的端點。 應用程式服務的預設功能變數名稱 *.azurewebsites.net (假設 contoso.azurewebsites.net) 與應用程式閘道的功能變數名稱不同, (說 contoso.com) 。 後端App Service遺漏必要的內容,以產生與瀏覽器所見網域一致的重新導向 URL 或 Cookie。

解決方法

生產建議的解決方案是將應用程式閘道和App Service設定為不覆寫主機名稱。 依照使用 應用程式閘道 設定App Service中的「Custom Domain (建議) 」指示操作

請只考慮套用另一個因應措施 (,例如位置標頭的重寫,如下文所述,在評估含意之後) : 保留反向 Proxy 與其後端 Web 應用程式之間的原始 HTTP 主機名稱。 這些含意包括網域系結 Cookie 和絕對 URL 在位置標頭外部的可能性,以維持中斷狀態。

因應措施:重寫位置標頭

警告

此設定隨附限制。 建議您檢閱在用戶端與應用程式閘道之間,以及在後端中使用應用程式與App Service之間不同主機名稱的影響。 如需詳細資訊,請檢閱架構中心: 在反向 Proxy 與其後端 Web 應用程式之間保留原始 HTTP 主機名稱

將位置標頭中的主機名稱設定為應用程式閘道的功能變數名稱。 若要這樣做,請使用條件建立 重寫規則 ,以評估回應中的位置標頭是否包含 azurewebsites.net。 它也必須執行動作,以重寫位置標頭,讓應用程式閘道的主機名稱。 如需詳細資訊,請參閱 如何重寫位置標頭的指示。

注意

HTTP 標頭重寫支援僅適用于Standard_v2和WAF_v2 SKU應用程式閘道。 建議您 移轉至 v2 ,以使用 v2 SKU 進行標頭重寫和其他 進階功能

下一步

如果上述步驟無法解決問題,請開啟 支援票證