[後端設定] 可讓您管理從應用程式閘道資源到後端集區中伺服器所建立之後端連線的組態。 後端設定組態可以與一或多個路由規則相關聯。
應用程式閘道中的後端設定類型
雖然入口網站使用者只看到「後端設定」選項，API 使用者則有兩種設定權限。 您必須根據通訊協定來使用正確的設定。
- 後端 HTTP 設定 - 適用於支援 HTTP 和 HTTPS 通訊協定的第 7 層 Proxy 設定。
- 後端設定 - 適用於支援 TLS 和 TCP 通訊協定的第 4 層 Proxy （預覽） 組態。
以 Cookie 為基礎的同質性
Azure 應用程式閘道 使用閘道管理的 Cookie 來維護使用者會話。 當使用者將第一次要求傳送到應用程式閘道時，應用程式閘道會在回應中設定一個親和性 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 名稱。 如果您正在使用自訂的親和 Cookie 名稱，會新增一個名稱帶有 CORS 後綴的其他 Cookie。 例如：CustomCookieNameCORS。
附註
如果已設定 SameSite=None 屬性，則 Cookie 也必須包含 Secure 旗標，而且必須透過 HTTPS 傳送。 如果透過 CORS 需要工作階段親和性，則您必須將工作負載移轉至 HTTPS。 請參閱應用程式閘道的 TLS 卸載和端對端 TLS 文件。 請參閱 SSL 概觀、 使用 TLS 終止設定應用程式閘道，以及 設定端對端 TLS。
清空連線
連線清空功能幫助你在計畫中的服務更新、滾動部署、擴展事件或閘道設定更新時，優雅地移除後端池成員。 使用連線排水來減少當後端實例被明確從後端池中移除時，發生的間歇性 502 錯誤與連線中斷情況。
您可以在後端設定上啟用連線清空，以將此設定套用至所有後端集區成員。 這可確保後端集區中的所有取消註冊執行個體不會在維護現有連線時收到任何新的要求/連線，直到設定的逾時值為止。 此過程也適用於 WebSocket 連線。
| 組態類型 | 值 |
|---|---|
| 未在後端設定中啟用連線清空時的預設值 | 30 秒 |
| 在後端設定中啟用連線清空時的使用者定義值 | 1 到 3,600 秒 |
此程序的唯一例外是由於閘道管理的工作階段親和性而繫結用來取消登錄執行個體的要求。 這些要求會繼續轉送到取消登錄的執行個體。
附註
有一項限制是：在連線清空逾時之後，組態更新會終止進行中的連線。 為了解決這個限制，你必須在後端設定中將連線耗盡逾時增加到高於最大客戶端預期下載時間的值。
要用 Azure CLI 更新連線耗盡逾時，請執行 az network application-gateway http-settings update，並在後端 HTTP 設定中設定 --connection-draining-timeout。 若值為 0，則會停用連線排水功能；若為 1 到 3,600 秒之間的值，則會啟用此功能。
附註
如果您在部署、滾動更新或縮容事件期間觀察到間歇性的 502 錯誤，連線清空逾時時間可能過短。 將 --connection-draining-timeout 增加至大於你預期的最大用戶端傳輸時間的值。
通訊協定
應用程式閘道支援 HTTP 和 HTTPS，以將要求路由傳送至後端伺服器。 如果您選擇 HTTP，則流向後端伺服器的流量未加密。 如果無法接受未加密的通訊，則請選擇 [HTTPS]。
此設定與接聽程式中的 HTTPS 合併使用，可支援端對端 TLS。 這可讓您安全地將加密的敏感性資料傳輸至後端。 後端集區中每個已啟用端對端 TLS 的後端伺服器都必須已設定憑證，才允許安全通訊。
連接埠
此設定會指定後端伺服器接聽應用程式閘道流量的連接埠。 您可以設定 1 到 65535 範圍內的連接埠。
受信任的根憑證
當後端設定中選擇 HTTPS 協定時，應用閘道資源會利用其預設的受信任根憑證儲存庫來驗證後端伺服器所提供憑證的鏈條與真實性。
根據預設，應用程式閘道資源包含熱門的 CA 憑證，在後端伺服器證書由公用 CA 簽發時，允許順暢的後端 TLS 連線。 不過，如果您打算使用私有 CA 或自行產生的憑證，並進行完整的 TLS 驗證，則必須在後端設定組態中提供對應的根 CA 憑證 （.cer）。
後端 HTTPS 驗證設定
當 Azure 應用程式閘道 的後端設定中選擇 HTTPS 時，閘道器會進行完整的 TLS 握手驗證，同時建立與後端伺服器的安全連線。 這些驗證包括：
- 驗證憑證鏈，以確保憑證可信。
- 根據應用程式閘道所發送的伺服器名稱指示（SNI），驗證憑證的主體名稱。
- 驗證憑證到期，以確認憑證是否仍然有效。
預設驗證設定可確保閘道與後端服務之間的安全 TLS 通訊。 在某些情況下，可能需要調整一個或多個驗證設定。 為了滿足不同的客戶需求，應用程式閘道提供下列可設定的選項。 您可以視需要使用其中一個或兩個選項。
| 屬性 | 價值觀 |
|---|---|
| validateCertChainAndExpiry | 類型：布林值（true 或 false）。 預設設定為 true。 這會驗證或略過憑證鏈結和到期驗證。 |
| validateSNI | 類型：布林值（true 或 false）。 預設設定為 true。 它會確認後端伺服器所提供的憑證一般名稱是否符合應用程式閘道所傳送的伺服器名稱指示 （SNI） 值。 |
| sniName | 類型：字串。 只有在 validateSNI 設為 true 時，才需要此內容。 您可以指定 SNI 值，以符合後端憑證的通用名稱。 根據預設，應用程式閘道會使用傳入要求的主機標頭作為 SNI。 |
附註
- 建議您為生產環境啟用所有驗證。 建議停用部分或全部驗證，僅用於測試和開發目的，例如使用自我簽署憑證時。
- 新增自訂 Health Probe（健康探針）時，這些設定不適用於測試探針功能。 因此，當你將結果與定期健康探針相比較時，會發現結果有所不同。
- 目前不支援 TLS Proxy。
- PowerShell 和 CLI 即將得到支援。
要求逾時
此設定是應用程式閘道等待接收後端伺服器回應的秒數。 預設值為20秒。 不過，您也可以根據申請需求調整此設定。 可接受的值為1秒到86400秒（24小時）。
覆寫後端路徑
此設定可讓您設定要在要求轉寄至後端時使用的選擇性自訂轉寄路徑。 符合 [覆寫後端路徑] 欄位中自訂路徑的任何傳入路徑部分都會複製至轉寄的路徑。 下表顯示此功能的運作方式：
HTTP 設定附加至基本要求路由規則時：
原始要求 覆寫後端路徑 轉寄至後端的要求 /首頁/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ HTTP 設定附加至路徑型要求路由規則時：
原始要求 路徑規則 覆寫後端路徑 轉寄至後端的要求 /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /首頁/ /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 名稱不同，而且後端依賴特定主機標頭來解析為正確的端點，則此功能有所幫助。
一個例子是將多租戶服務作為後端。 App Service 是多租用戶服務，使用具有單一 IP 位址的共享空間。 因此，只能透過自訂網域設定中所設定的主機名稱來存取應用程式服務。
根據預設，自訂網域名稱是 example.azurewebsites.net。 若要使用應用程式閘道，以透過應用程式服務中未明確註冊的主機名稱或透過應用程式閘道的 FQDN 來存取您的應用程式服務，您可以將原始要求中的主機名稱覆寫為應用程式服務的主機名稱。 若要這樣做，請啟用 [從後端位址挑選主機名稱] 設定。
對於自定義網域，其現有的自定義 DNS 名稱已映射到應用服務，不建議的設定是啟用從後端位址選擇主機名稱。
附註
這個設定對 App Service 環境 來說不是必須的，因為 是專用部署。
主機名稱覆寫
此功能會將應用程式閘道上傳入要求中的「主機」標頭取代為您所指定的主機名稱。
例如，如果在 www.contoso.com[主機名] 設定中指定，當要求轉送至後端伺服器時，原始要求 *https://appgw.eastus.cloudapp.azure.com/path1 會變更為 *https://www.contoso.com/path1 。
專用後端連接
Azure 應用程式閘道 預設會重用閒置後端連線，以優化 TCP 連線對應用閘道與後端伺服器的資源利用率。 為了支援客戶資料路徑中需要每個用戶端獨特後端連線的安全功能，Azure 應用程式閘道 V2 提供後端伺服器的專用連線。
此功能可在前端和後端連線之間建立直接的一對一映射，確保每個用戶端的持久連線。
這很重要
在啟用應用閘道專用 後端連線 前，請先檢視以下考量事項：
- NTLM/Kerberos 支援：NTLM 與 Kerberos 直通認證需要前端與後端連線一對一對應，以維持會話完整性。 開啟專用後端連線以支援這些協定。
- 舊有客戶端：像 MSIE6 或使用舊版 User-Agent 簽名的應用程式，無法完全支援現代 HTTP 功能和連線管理行為。 為了提升可靠性並防止回應不完整或損壞等問題，Azure 應用程式閘道 預設會套用額外的相容性處理。 啟用專用後端連線功能時，這種相容性處理可能導致舊有 NTLM 用戶端的連線行為差異，進而造成連線不一致。 為了達到最佳的可靠性與可預測的行為，建議使用現代且符合標準的用戶端，或盡可能升級舊有用戶端。
- 容量規劃：專用後端連線會增加後端連線數量，因此可能需要更多資源來支援應用閘道與後端伺服器上的同時連線。 在 Application Gateway 上，增加實例數量或啟用自動擴展以容納負載。
- SNAT 埠消耗：當後端為遠端伺服器時，每個用戶端連線會佔用一個專用的 SNAT 埠，增加 SNAT 埠耗盡的風險。 如需指引，請參閱 架構最佳實務。
- 協定支援：HTTP/2 不支援專用後端連線。
解決專用後端連線的 4xx 錯誤問題
當後端設定啟用專用後端連線，且後端應用程式回傳 4xx 狀態碼時，請依以下指引診斷並解決問題。
驗證服務主體名稱（SPN）配置-認證機制如 NTLM 和 Kerberos 需要正確註冊的服務主體名稱。 確保 SPN 在目錄中正確配置且唯一，以允許成功認證。 更多資訊請參閱 Kerberos 文件。
檢視後端伺服器日誌中的子狀態碼-應用閘道僅顯示主要 HTTP 狀態（例如 401 未授權）。 為了找出根本原因，請查閱後端伺服器日誌以獲得更詳細的子狀態資訊。 如需指引，請參閱 Windows 認證設定.