應用程式閘道 HTTP 設定組態
應用程式閘道會使用您在這裡指定的設定，以將流量路由傳送至後端伺服器。 建立 HTTP 設定之後，您必須將其與一或多個要求路由規則產生關聯。
以 Cookie 為依據的親和性
Azure 應用程式閘道會使用閘道管理的 Cookie 來維護使用者工作階段。 使用者將第一個要求傳送至應用程式閘道時，會使用包含工作階段詳細資料的雜湊值以在回應中設定親和性 Cookie，讓具有親和性 Cookie 的後續要求路由傳送至相同的後端伺服器，以維持黏性。
當您想要將使用者工作階段保留在相同的伺服器時，以及將使用者工作階段的工作階段狀態本機儲存在伺服器時，此功能非常有用。 如果應用程式無法處理 Cookie 型親和性，則無法使用此功能。 若要使用，請確定用戶端支援 Cookie。
注意
某些弱點掃描可能會標示應用程式閘道親和性 Cookie，因為未設定 Secure 或 HttpOnly 旗標。 這些掃描不會考慮使用單向雜湊來產生 Cookie 中的資料。 Cookie 未包含任何使用者資訊，而且只用於路由傳送。
The Chromium 瀏覽器v80 更新帶來強制規定，其中必須將不含 SameSite 屬性的 HTTP Cookie 視為 SameSite=Lax。 針對 CORS (跨原始來源資源共用) 要求，如果必須在第三方內容中傳送 Cookie，則必須使用 SameSite=None; Secure 屬性，而且應該只能透過 HTTPS 予以傳送。 否則，在僅限 HTTP 案例中，瀏覽器不會在第三方內容中傳送 Cookie。 這個 Chrome 更新的目標是增強安全性，並避免跨網站偽造要求 (CSRF) 攻擊。
若要支援這項變更，從 2020 年 2 月 17 日開始，應用程式閘道 (所有 SKU 類型) 除了現有 ApplicationGatewayAffinity Cookie 之外，還會插入另一個稱為 ApplicationGatewayAffinityCORS 的 Cookie。 ApplicationGatewayAffinityCORS Cookie 已對其再新增兩個屬性 ("SameSite=None; Secure")，因此即使是跨原始要求，仍然會維護黏性工作階段。
請注意，預設親和性 Cookie 名稱為 ApplicationGatewayAffinity，而且您可以進行變更。 如果您要使用自訂親和性 Cookie 名稱，則會使用 CORS 作為尾碼來新增額外的 Cookie。 例如，CustomCookieNameCORS。
注意
如果設定 SameSite=None 屬性，則 Cookie 也必須包含 Secure 旗標，而且必須透過 HTTPS 進行傳送。 如果透過 CORS 需要工作階段親和性，則您必須將工作負載移轉至 HTTPS。 請參閱此處應用程式閘道的 TLS 卸載和端對端 TLS 文件 – 概觀、使用 Azure 入口網站來設定具有 TLS 終止的應用程式閘道、使用入口網站以利用應用程式閘道來設定端對端 TLS。
清空連線
連線清空可協助您在已規劃的服務更新期間，毫無錯誤地移除後端集區成員。 會套用至後端執行個體
- 從後端集區指定移除，
- 在相應縮小作業期間移除，或
- 健全狀態探查回報為狀況不良。
您可以在後端設定上啟用連線清空，以將此設定套用至所有後端集區成員。 這可確保後端集區中的所有取消註冊執行個體不會在維護現有連線時收到任何新的要求/連線，直到設定的逾時值為止。 WebSocket 連線也是如此。
| 組態類型 | 值 |
|---|---|
| 未在後端設定中啟用連線清空時的預設值 | 30 秒 |
| 在後端設定中啟用連線清空時的使用者定義值 | 1 至 3600 秒 |
唯一的例外是因閘道管理的工作階段親和性而限定為取消註冊執行個體的要求，而且會繼續轉寄至取消註冊執行個體。
通訊協定
應用程式閘道支援 HTTP 和 HTTPS，以將要求路由傳送至後端伺服器。 如果您選擇 HTTP，則流向後端伺服器的流量未加密。 如果無法接受未加密的通訊，則請選擇 [HTTPS]。
此設定與接聽程式中的 HTTPS 合併使用，可支援端對端 TLS。 這可讓您安全地將加密的敏感性資料傳輸至後端。 後端集區中每個已啟用端對端 TLS 的後端伺服器都必須已設定憑證，才允許安全通訊。
連接埠
此設定會指定後端伺服器接聽應用程式閘道流量的連接埠。 您可以設定 1 到 65535 範圍內的連接埠。
受信任的根憑證
如果您選取 HTTPS 作為後端通訊協定，則應用程式閘道需要受信任的根憑證，才能信任後端集區，以進行端對端 SSL。 根據預設，[使用已知的 CA 憑證] 選項會設定為 [否]。 如果您打算使用自我簽署憑證或內部憑證授權單位所簽署的憑證，則必須將後端集區將使用的相符公用憑證提供給應用程式閘道。 此憑證必須以 .CER 格式直接上傳至應用程式閘道。
如果您打算在後端集區上使用受信任的公用憑證授權單位所簽署的憑證，則可以將 [使用已知的 CA 憑證] 選項設定為 [是]，並略過上傳公開憑證。
要求逾時
此設定是應用程式閘道等待接收後端伺服器回應的秒數。
覆寫後端路徑
此設定可讓您設定要在要求轉寄至後端時使用的選擇性自訂轉寄路徑。 符合 [覆寫後端路徑] 欄位中自訂路徑的任何傳入路徑部分都會複製至轉寄的路徑。 下表顯示此功能的運作方式：
HTTP 設定附加至基本要求路由規則時：
原始要求 覆寫後端路徑 轉寄至後端的要求 /home/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ HTTP 設定附加至路徑型要求路由規則時：
原始要求 路徑規則 覆寫後端路徑 轉寄至後端的要求 /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /home/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /pathrule/ /pathrule/ /override/ /override/
使用自訂探查
此設定會將自訂探查與 HTTP 設定產生關聯。 您只能將一個自訂探查與一個 HTTP 設定產生關聯。 如果您未明確地關聯自訂探查，則會使用預設探查來監視後端的健康情況。 建議您建立自訂探查，以進一步控制後端的健康情況監視。
注意
除非對應的 HTTP 設定明確地與接聽程式相關聯，否則自訂探查不會監視後端集區的健康情況。
設定主機名稱
應用程式閘道允許建立至後端的連線使用與用戶端用來連線至應用程式閘道的主機名稱「不同」的主機名稱。 雖然此設定在某些情況下可能十分有用，但覆寫用戶端與應用程式閘道與應用程式閘道到後端目標之間不同的主機名稱時請小心。
在生產環境中，建議讓用戶端用於應用程式閘道的主機名稱與應用程式閘道用於後端目標的主機名稱相同。 這可避免絕對 URL、重新導向 URL 和主機繫結 Cookie 的潛在問題。
設定與此偏離的應用程式閘道之前，請檢閱架構中心更詳細討論的這類設定含意：保留反向 Proxy 與其後端 Web 應用程式之間的原始 HTTP 主機名稱
HTTP 設定有兩個層面會影響應用程式閘道用來連線至後端的 Host HTTP 標頭：
- 「從後端位址挑選主機名稱」
- 「主機名稱覆寫」
從後端位址挑選主機名稱
此功能會動態將要求中的「主機」標頭設定為後端集區的主機名稱。 其會使用 IP 位址或 FQDN。
如果後端的網域名稱與應用程式閘道的 DNS 名稱不同，而且後端依賴特定主機標頭來解析為正確的端點，則此功能有所幫助。
範例案例是作為後端的多租用戶服務。 應用程式服務是多租用戶服務，可使用具有單一 IP 位址的共用空間。 因此，只能透過自訂網域設定中所設定的主機名稱來存取應用程式服務。
根據預設，自訂網域名稱是 example.azurewebsites.net。 若要使用應用程式閘道，以透過應用程式服務中未明確註冊的主機名稱或透過應用程式閘道的 FQDN 來存取您的應用程式服務，您可以將原始要求中的主機名稱覆寫為應用程式服務的主機名稱。 若要這樣做，請啟用 [從後端位址挑選主機名稱] 設定。
針對現有自訂 DNS 名稱對應至應用程式服務的自訂網域，建議的設定是不要啟用 [從後端位址挑選主機名稱]。
注意
App Service 環境 (其為專用部署) 不需要此設定。
主機名稱覆寫
此功能會將應用程式閘道上傳入要求中的「主機」標頭取代為您所指定的主機名稱。
例如，如果在 [主機名稱] 設定中指定 www.contoso.com，則在將要求轉寄至後端伺服器時，原始要求 *https://appgw.eastus.cloudapp.azure.com/path1 會變更為 *https://www.contoso.com/path1。