應用程式閘道可作為用戶端的單一連絡點。 其會將傳入的應用程式流量分散到多個後端集區，其中包括 Azure VM、虛擬機器擴展集、Azure App 服務 和內部部署/外部伺服器。 為了分散流量，應用程式閘道會使用本文所述的數個元件。
前端 IP 位址
前端 IP 位址是與應用程式閘道相關聯的 IP 位址。 您可設定讓應用程式閘道擁有公用 IP 位址和 (或) 私人 IP 位址。 應用程式閘道支援一個公用 IP 位址或一個私人 IP 位址。 您的虛擬網路和公用 IP 位址必須與應用程式閘道位於相同的位置。 前端 IP 位址在建立好之後，會與接聽程式相關聯。
靜態與動態的公用 IP 位址
Azure 應用程式閘道 V2 SKU 可設定為同時支援靜態內部 IP 與靜態公共 IP 位址，或僅支援靜態公共 IP 位址。 你也可以只有在部署私人應用程式閘道，並將networkIsolationEnabled設為True時，使用靜態內部 (私人) IP 位址來加以設定。 關於支援的前端 IP 位址組合，請參見 前端 IP 位址配置。 關於僅限私有 IP 部署中的 DNS 行為，請參見 應用閘道 DNS 解析。
V1 SKU 可以設定為支援靜態或動態內部 IP 位址和動態公用 IP 位址。 應用程式閘道的動態 IP 位址不會在執行中的閘道上變更。 其只能在您停止或啟動閘道時變更。 其不會在系統失敗、更新、Azure 主機更新等時候變更。
與應用程式閘道相關聯的 DNS 名稱在閘道的存留期內不會變更。 因此，您應該使用 CNAME 別名，並指向應用程式閘道的 DNS 位址。
接聽程式
接聽程式是一種邏輯實體，可檢查傳入連線要求。 如果與要求相關聯的通訊協定、連接埠、主機名稱和 IP 位址，符合與接聽程式設定相關聯的相同元素，接聽程式就會接受要求。
使用應用程式閘道之前，您必須至少新增一個接聽程式。 可以有多個接聽程式連結至應用程式閘道，而且可以用於相同通訊協定。
接聽程式偵測到來自用戶端的傳入要求之後，應用程式閘道就會將這些要求路由傳送至規則中所設定後端集區中的成員。
接聽程式支援下列連接埠和通訊協定。
連接埠
連接埠是接聽程式用來接聽用戶端要求的位置。 您可以如下所示地設定 v1 和 v2 SKU 的連接埠。
| SKU | 支援的連接埠範圍 | 例外 |
|---|---|---|
| V2 | 1 到 64999 | 已啟用私人連結的閘道不支援使用連接埠 22。 53號埠 |
| V1 | 1 到 65502 | 端口3389 |
通訊協定
應用程式閘道透過第 7 層 Proxy 提供 Web 通訊協定 HTTP、HTTPS、HTTP/2 和 WebSocket 的支援。 此外，它透過第 4 層代理支援 TLS 和 TCP 協定，這些代理可在同一資源上設定。
- 選擇接聽程式設定中的 HTTP、HTTPS、TLS 或 TCP 通訊協定。
- 您可以使用 HTTPS 或 TLS 接聽程式來終止 TLS。 HTTPS/TLS 接聽程式會將加密和解密工作卸載至您的應用程式閘道，因此您的伺服器不會因 TLS 計算額外負荷而負擔。
- 系統會提供 WebSocket 和 HTTP/2 通訊協定的原生支援，且預設會啟用 WebSocket 支援。 使用者無法進行設定來選擇要啟用或停用 WebSocket 支援。 請搭配 HTTP 和 HTTPS 接聽程式使用 WebSocket。
下表總結了應用閘道如何支援各協定。
| 協定 | Proxy | 可選作監聽器協定 | 支援詳細資料 |
|---|---|---|---|
| HTTP | 第 7 層 | Yes | 透過第 7 層 Proxy 原生支援。 |
| HTTPS | 第 7 層 | Yes | 使用 HTTPS 監聽器來終止 TLS，讓閘道器將加密和解密工作從伺服器中卸除。 |
| HTTP/2 | 第 7 層 | No | 僅供連接應用程式閘道監聽器的用戶端使用。 與後端伺服器池的通訊始終透過 HTTP/1.1。 預設為停用;你可以選擇啟用它。 |
| WebSocket | 第 7 層 | No | 預設啟用，且沒有使用者可設定的選項來選擇性開啟或關閉。 請搭配 HTTP 和 HTTPS 接聽程式使用 WebSocket。 |
| TLS | 第 4 層 | Yes | 透過可在同一資源上設定的 Layer 4 代理 提供支援。 |
| TCP | 第 4 層 | Yes | 透過可在同一資源上設定的 Layer 4 代理 提供支援。 |
附註
HTTP/2 通訊協定支援僅適用於連線到應用程式閘道接聽程式的用戶端。 與後端伺服器集區的通訊一律會透過 HTTP/1.1 來進行。 預設已停用 HTTP/2 支援。 您可以選擇將其啟用。
自訂錯誤頁面
應用程式閘道可讓您建立自訂的錯誤頁面，而不是顯示預設的錯誤頁面。 您可以使用自訂錯誤頁面來搭配您自己的商標和版面配置。 應用程式閘道會在要求無法送達後端時顯示自訂錯誤頁面。
如需詳細資訊，請參閱應用程式閘道的自訂錯誤頁面。
接聽程式類型
接聽程式有兩種：
基本。 這一類接聽程式會接聽單一網域網站，在此網站中，其具有應用程式閘道 IP 位址的單一 DNS 對應。 當您在應用程式閘道後方裝載單一網站時，便需要此接聽程式設定。
多網站。 當您想要根據主機名稱或網域名稱，為同一個應用程式閘道上的多個 Web 應用程式設定路由時，便需要此接聽程式設定。 此功能可讓您將 100 多個網站新增到一個應用程式閘道，為您的部署設定更有效率的拓撲。 每個網站都可以導向到自己的後端集區。 例如，contoso.com、fabrikam.com 和 adatum.com 三個網域都指向應用程式閘道的 IP 位址。 您會建立三個多網站接聽程式，並針對個別的連接埠和通訊協定設定來設定每個接聽程式。
您也可以在多網站接聽程式中定義萬用字元主機名稱，並為每個接聽程式定義最多 5 個主機名稱。 若要深入瞭解，請參閱接聽程式中的萬用字元主機名稱。
如需如何設定多網站接聽程式的詳細資訊，請參閱使用 Azure 入口網站在應用程式閘道中裝載多網站。
您會在建立接聽程式之後，將其與要求路由規則產生關聯。 此規則會決定在接聽程式上收到的要求應如何路由傳送至後端。 要求路由規則也包含要作為路由傳送目的地的後端集區，以及提及後端連接埠、通訊協定等項目的 HTTP 設定。
要求路由規則
要求路由規則是應用程式閘道的關鍵元件，因為其會決定如何在接聽程式上路由傳送流量。 此規則會繫結接聽程式、後端伺服器集區和後端 HTTP 設定。
當接聽程式接受要求時，要求路由規則會將要求轉送至後端，或將其重新導向至其他地方。 如果要求轉送至後端，要求路由規則會定義要作為其轉送目的地的後端伺服器集區。 要求路由規則也會決定是否要重寫要求中的標頭。 一個接聽程式可以連結至一個規則。
要求路由規則有兩種：
基本。 相關聯接聽程式 (例如，blog.contoso.com/*) 上的所有要求，會使用相關聯的 HTTP 設定轉送至相關聯的後端集區。
路徑型。 此路由規則可讓您根據要求中的 URL，將相關聯接聽程式上的要求路由傳送至特定後端集區。 如果要求中的 URL 路徑符合路徑型規則中的路徑模式，規則就會路由傳送該要求。 其只會將路徑模式套用至 URL 路徑，而不會套用至其查詢參數。 如果接聽程式要求上的 URL 路徑不符合任何路徑型規則，則會將要求路由傳送至預設的後端集區和 HTTP 設定。
下表比較了這兩種規則類型。
| 規則類型 | 應用案例 | 路由基礎 | 支援的後端 |
|---|---|---|---|
| 基本 | 將所有監聽者接受的請求都傳送到同一個應用程式。 | 相關監聽器上的所有請求，例如 blog.contoso.com/*。 |
單一相關的後端集區，可透過相關的 HTTP 設定連線到該集區。 |
| 基於路徑的 | 根據要求的 URL，將到達單一接聽程式的要求路由至不同的應用程式。 | 請求中網址的路徑。 路徑模式僅適用於 URL 路徑，不適用於其查詢參數。 | 每個匹配路徑模式都有專屬的後端池，還有預設的後端池和 HTTP 設定，針對不符合任何路徑規則的請求。 |
如需詳細資訊，請參閱 URL 型路由。
重新支援
要求路由規則也可讓您重新導向應用程式閘道上的流量。 這是一般重新導向機制，讓您可以使用規則在您定義的任何連接埠進行出入重新導向。
您可以選擇重新導向目標來作為另一個接聽程式 (這有助於自動從 HTTP 重新導向至 HTTPS) 或外部網站。 您也可以選擇將重新導向設為暫時或永久，或將 URI 路徑和查詢字串附加至重新導向後的 URL。
如需詳細資訊，請參閱在應用程式閘道上重新導向流量。
重寫 HTTP 標頭和 URL
應用閘道器可以新增、移除或更新 HTTP（S） 請求與回應標頭，以及 URL 路徑和查詢字串參數，隨著流量在用戶端與後端池間流動。 完整說明與設定步驟請參閱「 重寫您的應用程式閘道上的 HTTP 標頭與網址」。
HTTP 設定
HTTP 設定，也稱為後端設定，是決定流量如何抵達後端伺服器的設定。 它定義了應用閘道用來連接這些伺服器的埠號和協定、連線的行為，以及閘道器如何監控後端健康狀況。 請求路由規則會指定在將請求轉發到後端池時應套用哪種 HTTP 設定。
HTTP 設定中使用的連接埠和通訊協定會決定應用程式閘道與後端伺服器之間的流量要加密 (提供端對端 TLS) 還是不加密。
此元件也可用來：
使用 Cookie 型工作階段親和性，決定使用者工作階段是否要保留在相同的伺服器上。
使用連線清空，正常移除後端集區成員。
與自訂探查產生關聯，以監視後端健康情況、設定要求逾時間隔、覆寫要求中的主機名稱和路徑，以及提供單鍵即可輕鬆指定 App Service 後端設定的功能。
後端集區
後端集區會將要求路由傳送至後端伺服器，以提供要求。 後端集區可以包含：
- NIC
- 虛擬機器擴展集
- 公用 IP 位址
- 內部 IP 位址
- FQDN（完全限定網域名稱）或短名稱（單標籤網域名稱），前提是你的 DNS 伺服器能解析它們
- 多租戶後端，例如 Azure App 服務 同 Azure 容器應用程式。 請參閱 《保護容器應用程式與應用閘道與 WAF 》以獲得實作指引。
應用程式閘道後端集區成員不會繫結至可用性設定組。 應用程式閘道就可以與所在虛擬網路外面的執行個體進行通訊。 因此，只要有 IP 連線能力，後端集區的成員就可以跨叢集、跨資料中心或位於 Azure 外部。
如果您使用內部 IP 作為後端集區成員，則必須使用虛擬網路對等互連或 VPN 閘道。 虛擬網路對等互連有受到支援，這對於平衡其他虛擬網路中的流量負載很有幫助。
如果允許流量，且內部部署伺服器透過 Azure ExpressRoute 或 VPN 通道來連線時，應用程式閘道也可與內部部署伺服器通訊。
您可以為不同類型的要求建立不同的後端集區。 例如，針對一般要求建立一個後端集區，然後針對應用程式的微服務要求建立另一個後端集區。
將虛擬機器擴展集新增為後端集區成員之後，您必須升級虛擬機器擴展集執行個體。 在升級擴展集執行個體之前，後端將處於狀況不良的狀態。
健康狀態探查
根據預設，應用程式閘道會監視其後端集區中所有資源的健康情況，並自動移除狀況不良的資源。 然後，會監視狀況不良的執行個體，並在其恢復可用狀態並回應健康狀況探查時，將其新增回狀況良好後端集區中。
除了使用預設的健全狀況探查監視，您也可以自訂健全狀況探查，以符合應用程式的需求。 自訂探查可讓您更細微地控制狀況監控。 使用自訂探查時，您可以設定自訂主機名稱、URL 路徑、探查間隔，以及要接受多少個失敗回應才會將後端集區執行個體標示為狀況不良、自訂狀態碼和回應主體相符等等。建議您設定自訂探查，以監視每個後端集區的健康情況。
附註
對於應用閘道 v2 上的 HTTPS 健康探測器，當啟用憑證主體名稱驗證時，探測所使用的 SNI 主機名稱必須與後端 TLS 憑證中的主體替代名稱（SAN）相符，若無 SAN 則與其通用名稱（CN）相符。 在設定探針前，請先參閱 探針流量的伺服器名稱指示（SNI）行為。 如果 後端健康 系統回報憑證名稱不符，請依照「 通用名稱（CN）不符」中的設定專屬指引操作。 此指引包含 主機名稱覆寫 選項。
如需詳細資訊，請參閱監視應用程式閘道的健康情況。
後續步驟
建立應用程式閘道：