應用程式閘道的運作方式
本文說明應用程式閘道如何接受傳入要求，並將其路由傳送至後端。
應用程式閘道如何接受要求
在用戶端將要求傳送至應用程式閘道之前，閘道會使用網域名稱系統 (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 型工作階段親和性、連線清空、後端的主機名稱選取項目等等。
注意
若後端集區：
- 是公用端點，應用程式閘道會使用其前端公用 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 值做出一致回應。
- 使用私人端點的私人 DNS 區域時，內部部署自定義 DNS 伺服器的使用者必須透過 Azure DNS 私人解析器 (建議) 或 DNS 轉寄站 VM 連線至 Azure DNS。
對要求的修改
應用程式閘道會將六個額外標頭插入所有要求，再將要求轉送至後端。 這些標頭是 x-forwarded-for、x-forwarded-port、x-forwarded-proto、x-original-host、x-original-url 和 x-appgw-trace-id。x-forwarded-for 標頭的格式是以逗號分隔的 IP:Port 清單。
x-forwarded-proto 的有效值為 HTTP 或 HTTPS。 X-forwarded-port 會指定要求在應用程式閘道的抵達連接埠。 X-Original-Host 標頭包含隨著要求送達的原始 Host 標頭。 此標頭適合用於 Azure 網站整合，其中的傳入 host 標頭會在流量路由傳送到後端之前先行修改。 如果啟用工作階段親和性作為選項，則會新增由閘道管理的親和性 Cookie。
X-appgw-trace-id 是應用程式閘道針對每個用戶端要求所產生的唯一 GUID，並在轉送的要求中呈現給後端集區成員。 guid 是由 32 個英數字元所組成，沒有虛線 (例如：ac882cd65a2712a0fe1289ec2bb6aee7)。 此 GUID 可用來將應用程式閘道所接收的要求相互關聯，並透過診斷記錄中的 transactionId 屬性起始至後端集區成員。
您可以使用重寫 HTTP 標頭和 URL 來設定應用程式閘道來修改要求和回應標頭和 URL，或使用路徑覆寫設定修改 URI 路徑。 不過，除非依此設定，否則所有連入要求都會代理至後端。