本文說明應用程式閘道如何接受傳入要求，並將其路由傳送至後端。
應用程式閘道如何接受要求
在用戶端將要求傳送至應用程式閘道之前，閘道會使用網域名稱系統 (DNS) 伺服器解析應用程式閘道的網域名稱。 Azure 會控制 DNS 項目，因為所有應用程式閘道都位於 azure.com 網域中。
Azure DNS 會將 IP 位址傳回給用戶端，此為應用程式閘道的前端 IP 位址。
應用程式閘道會在一或多個接聽器上接受傳入流量。 接聽程式是一種邏輯實體，可檢查連線要求。 其會設定前端 IP 位址、通訊協定和連接埠號碼，供用戶端連線至應用程式閘道。
若使用 Web 應用程式防火牆 (WAF)，應用程式閘道會根據 WAF 規則檢查要求標頭及本文 (若有的話)。 此動作會判斷要求是否為有效要求，還是安全性威脅。 如果要求有效，則會路由傳送至後端。 如果要求無效且 WAF 處於預防模式，則會視為安全性威脅並加以封鎖。 如果處於偵測模式，則會評估並記錄要求，但仍會轉送至後端伺服器。
Azure 應用程式閘道可作為內部應用程式負載平衡器或網際網路對向應用程式負載平衡器。 網際網路對向應用程式閘道會使用公用 IP 位址。 網際網路對向應用程式閘道的 DNS 名稱可公開解析為其公用 IP 位址。 因此，面向網際網路的應用程式閘道可以將來自網際網路的用戶端請求路由至適當的目的地。
內部應用程式閘道只會使用私人 IP 位址。 如果您使用自訂或私人 DNS區域，則網域名稱應可內部解析為應用程式閘道的私人 IP 位址。 因此，內部負載平衡器只能路由來自可存取應用程式閘道虛擬網路之用戶端的要求。
應用程式閘道如何轉送請求
如果要求有效且不受 WAF 封鎖，應用程式閘道會評估與接聽程式相關聯的要求路由規則。 此動作會決定將要求路由至哪個後端集區。
根據要求路由規則，應用程式閘道會決定要將接聽程式上的所有要求路由至特定後端集區、根據 URL 路徑將要求路由至不同的後端集區，或將要求重新導向至另一個連接埠或外部網站。
注意
在 v1 SKU 中，系統會依入口網站中列出的順序處理規則。 當應用程式閘道選取後端集區時，其會將要求至集區 (y.y.y.y) 中其中一個狀況良好的後端伺服器。 伺服器的健康情況是由健康探查所判定。 若後端集區包含多部伺服器，應用程式閘道會使用循環配置演算法，將要求導向狀況良好的伺服器。 此負載會平衡伺服器上的要求。
應用程式閘道判定出後端伺服器後，會根據 HTTP 設定與該後端伺服器建立新的 TCP 工作階段。 HTTP 設定會指定使用後端伺服器建立新工作階段所需的通訊協定、連接埠和其他路由相關設定。
HTTP 設定中使用的連接埠和通訊協定會決定應用程式閘道與後端伺服器之間的流量要加密 (因此完成端對端 TLS) 還是不加密。
當應用程式閘道將原始要求傳送至後端伺服器時，會接受 HTTP 設定中與覆寫主機名稱、路徑和通訊協定相關的任何自訂設定。 此動作會維護以 Cookie 為基礎的工作階段親和性、連線清空、以及從後端選取主機名稱等設定。
注意
當沒有後端池成員可用時，應用閘道器不會將請求轉發給 WAF
注意
如果後端集區：
- 是公用端點，應用程式閘道會使用其前端公用 IP 連線至伺服器。 如果沒有前端公用 IP 位址，則會為輸出外部連線指派一個位址。
- 包含可內部解析的 FQDN 或私人 IP 位址，則應用程式閘道會使用其執行個體私人 IP 位址，將要求路由至後端伺服器。
- 包含外部端點或外部可解析的 FQDN，應用程式閘道會使用其前端公用 IP 位址，將要求路由至後端伺服器。 如果子網路包含服務端點，應用程式閘道會透過其私人 IP 位址將要求路由至服務。 如果已進行設定，DNS 解析會以私人 DNS 區域或自訂 DNS 伺服器為基礎；否則會使用 Azure 預設提供的 DNS。 如果沒有前端公用 IP 位址，則會為輸出外部連線指派一個位址。
後端伺服器 DNS 解析
當後端集區的伺服器設定了完整網域名稱 (FQDN)，應用程式閘道會執行 DNS 查閱，以取得網域名稱的 IP 位址。 IP 值會儲存在應用程式閘道的快取中，以便在處理傳入要求時更快抵達目標。
應用程式閘道會保留此快取資訊，保留期間等同於該 DNS 記錄的 TTL (存留時間)，並在 TTL 到期後執行新的 DNS 查閱。 若在後續 DNS 查閱中，閘道偵測到 IP 位址變更，則會將流量路由至更新後的目的地。 如果 DNS 查閱無法接收回應，或記錄已不存在，閘道會繼續使用上次已知的正確 IP 位址， 將對資料路徑的影響降至最低。
重要
- 搭配 應用程式閘道 虛擬網絡 使用自定義 DNS 伺服器時，所有伺服器都一致地回應相同的 DNS 值是很重要的。 當您的 Application Gateway 執行個體發出 DNS 查詢時，它會使用最先回應的伺服器所提供的值。
- 內部部署自定義 DNS 伺服器的使用者在使用私人端點的 私用 DNS 區域時，必須確保透過 Azure DNS 私人解析程式（建議）或 DNS 轉寄站 VM 連線到 Azure DNS。
對要求的修改
應用程式閘道會將六個額外標頭插入所有要求，再將要求轉送至後端。 這些標頭分別為 x-forwarded-for、 x-forwarded-port、 x-forwarded-proto、 x-original-hostx-original-urlx-appgw-trace-id、 和 。 如果你的 TLS 交握使用來自 AppGwSslPolicy20220101 或更新版本的預先定義 SSL 原則，或使用類型為 CustomV2 或更新版本的自訂 SSL 原則，你的要求將會包含一個額外的標頭：x-azure-ja4-fingerprint。
x-forwarded-for標頭格式為逗號分隔的 IP：port 清單。
x-forwarded-proto 的有效值為 HTTP 或 HTTPS。 X-forwarded-port 會指定要求到達應用程式閘道時所使用的連接埠。 X-Original-Host 標頭包含請求到達時所帶有的原始 Host 標頭。 此標頭在 Azure 網站整合中很有用，因為傳入的主機標頭會在流量路由至後端之前先被修改。 若啟用工作階段親和性為選項，則會新增由閘道管理的親和性 Cookie。
X-Azure-JA4-Fingerprint 是 TLS 用戶端指紋，有助於識別並關聯跨服務的用戶端流量，以進行安全調查。
對於透過 Application Gateway 的私人端點接收的要求，Application Gateway 也會先新增 X-Azure-PrivateEndpoint-ID 標頭，再將要求轉送至後端。 標頭包含私有端點連線的小數點 LINKID ，並與應用閘道存取日誌中的屬性相符 LinkId 。 標頭不會被加到直接發送到公有或私有前端 IP 的請求中。 更多資訊請參閱 「識別來自私有端點的流量」。
X-appgw-trace-id 是應用程式閘道為每個用戶端要求所產生的唯一 GUID，並會顯示在轉送至後端集區成員的要求中。 該 GUID 是由 32 個英數字元組成，不含連字號 (例如：ac882cd65a2712a0fe1289ec2bb6aee7)。 此 GUID 可用於透過 診斷記錄 中的 transactionId 屬性，將應用程式閘道收到的要求與傳送至後端集區成員的要求建立關聯。
您可以使用重寫 HTTP 標頭和 URL 來設定應用程式閘道來修改要求和回應標頭和 URL，或使用路徑覆寫設定修改 URI 路徑。 不過，除非依此設定，否則所有連入要求都會代理至後端。