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

了解如何診斷並解決將 Azure App Service 作為後端目標與 Azure 應用程式閘道搭配使用時可能會遇到的問題。

概觀

本文可協助您了解如何針對下列問題進行疑難排解 (架構中心提供更詳細的說明)：保留反向 Proxy 及其後端 Web 應用程式之間的原始 HTTP 主機名稱 (機器翻譯)

• 錯誤的絕對 URL
• 錯誤的重新導向 URL
  • 重新導向時，應用程式服務 URL 會在瀏覽器中公開
  • 例子：OIDC 驗證流程因使用錯誤主機名稱重新導向而中斷，其中包括使用 App Service 驗證和授權 (機器翻譯)
• 中斷的 Cookie
  • Cookie 無法在瀏覽器與 App Service 之間傳播
  • 例子：應用程式服務 ARRAffinity Cookie 網域設定為應用程式服務主機名稱，且連結至「example.azurewebsites.net」，而非原始主機， 因而導致工作階段親和性中斷。

出現上述徵兆的根本原因，是應用程式閘道向 App Service 使用的設定將主機名稱覆寫為瀏覽器看見的其他主機名稱。 通常主機名稱會遭覆寫為預設 App Service「azurewebsites.net」網域。

範例設定

如果您的設定符合下列兩種情況的其中一種，便需按本文指示操作：

• HTTP 設定中已啟用 [從後端位址挑選主機名稱]
• 為 [以特定網域名稱覆寫] 所設的值與瀏覽器要求中的不同

原因

App Service 是多租用戶服務，因此會使用要求中的主機標頭，以便將要求路由傳送至正確的端點。 App Service 的預設網域名稱 *.azurewebsites.net (例如：contoso.azurewebsites.net) 與應用程式閘道的網域名稱不同 (例如：contoso.com)。 後端 App Service 缺少產生重新導向轉接 URL 或 Cookie 所需的內容，這些 URL 或 Cookie 與瀏覽器看到的網域一致。

解決方案

生產環境建議的解決方案是將應用程式閘道和App Service 設定為不要覆寫主機名稱。 請按照使用應用程式閘道設定 App Service 中的「自訂網域 (建議)」指示操作

請務必先評估文章中所述的影響後，再考慮採用另一項因應措施 (例如下方所述的位置標頭重寫)：保留反向 Proxy 及其後端 Web 應用程式之間的原始 HTTP 主機名稱 (機器翻譯)。 影響包括網域繫結 Cookie 以及位置標頭以外的絕對 URL 可能維持中斷狀態。

因應措施：重寫位置標頭

將位置標頭中的主機名稱設定為應用程式閘道的網域名稱， 做法是建立重寫規則 (機器翻譯)，條件為評估回應中的位置標頭是否包含 azurewebsites.net。 此條件也必須執行動作以重寫包含應用程式閘道主機名稱的位置標頭。 如需詳細資訊，請參閱如何重寫位置標頭 (機器翻譯) 中的指示。

下一步

若上述步驟無法解決問題，請開啟支援票證。