[後端設定] 可讓您管理從應用程式閘道資源到後端集區中伺服器所建立之後端連線的組態。 後端設定組態可以與一或多個路由規則相關聯。
應用程式閘道中的後端設定類型
雖然入口網站使用者只會看到 [後端設定] 選項，但 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。
清空連線
連線清空可協助您在已規劃的服務更新期間，毫無錯誤地移除後端集區成員。 它適用於從後端集區明確移除的後端執行個體。
您可以在後端設定上啟用連線清空，以將此設定套用至所有後端集區成員。 這可確保後端集區中的所有取消註冊執行個體不會在維護現有連線時收到任何新的要求/連線，直到設定的逾時值為止。 此過程也適用於 WebSocket 連線。
| 組態類型 | 值 |
|---|---|
| 未在後端設定中啟用連線清空時的預設值 | 30 秒 |
| 在後端設定中啟用連線清空時的使用者定義值 | 1 至 3600 秒 |
此程序的唯一例外是由於閘道管理的工作階段親和性而繫結用來取消登錄執行個體的要求。 這些要求會繼續轉送到取消登錄的執行個體。
附註
有一項限制是：在連線清空逾時之後，組態更新會終止進行中的連線。 若要解決這項限制，您必須將後端設定中的連線清空時間增加為高於預期用戶端下載時間上限的值。
通訊協定
應用程式閘道支援 HTTP 和 HTTPS，以將要求路由傳送至後端伺服器。 如果您選擇 HTTP，則流向後端伺服器的流量未加密。 如果無法接受未加密的通訊，則請選擇 [HTTPS]。
此設定與接聽程式中的 HTTPS 合併使用，可支援端對端 TLS。 這可讓您安全地將加密的敏感性資料傳輸至後端。 後端集區中每個已啟用端對端 TLS 的後端伺服器都必須已設定憑證，才允許安全通訊。
連接埠
此設定會指定後端伺服器接聽應用程式閘道流量的連接埠。 您可以設定 1 到 65535 範圍內的連接埠。
受信任的根憑證
在後端設定中選取 HTTPS 通訊協定時，應用程式閘道資源會利用其預設的受信任根 CA 證書存儲來驗證後端伺服器所提供的憑證鏈結和真實性。
根據預設，應用程式閘道資源包含熱門的 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 傳遞驗證，請確定已開啟專用後端連線設定。 此配置維護前端和後端連接之間的一對一映射，這對於保持這些身份驗證協定所需的會話完整性至關重要。
這很重要
專用後端連線會導致後端連線數目增加，因此可能需要更多資源來支援應用程式閘道和後端伺服器上增加的並行連線。 在應用程式閘道上，您需要考慮增加實例數量或啟用自動擴展。
當後端是遠端伺服器時，應用程式閘道執行個體會針對每個連線使用 SNAT 埠。 當每個用戶端連線建立專用後端連線時，SNAT 埠耗用量會相應增加。 因此，務必要考量潛在的 SNAT 連接埠消耗。 請瀏覽 架構最佳實務 以取得指引。
HTTP/2 不支援專用後端連線。