設定 Azure 應用程式閘道

25 分鐘

應用程式閘道有一系列的元件，共同將要求路由傳送至 Web 伺服器集區，並檢查這些 Web 伺服器的健康情況。

Diagram showing how Azure Application Gateway routes requests to a pool of web servers

前端組態

您可設定讓應用程式閘道擁有公用 IP 位址、私人 IP 位址或兩者。若所裝載後端的用戶端必須透過網際網路對應的虛擬 IP 來存取網際網路，便需要公用 IP 位址。

後端組態

後端集區用於將要求路由傳送至可為要求提供服務的後端伺服器。後端集區可以包含 NIC、虛擬機器擴展集、公用 IP 位址、內部 IP 位址、完整網域名稱 (FQDN)，以及多租用戶後端，例如 Azure App Service。您可以為應用程式閘道建立空的後端集區，然後將後端目標新增至後端集區。

設定健全狀態探查

Azure 應用程式閘道預設會監視其後端集區中所有資源的健康狀況，並自動從集區中移除任何被視為狀況不良的資源。應用程式閘道會繼續監視狀況不良的執行個體，一旦其恢復可用狀態並回應健康狀況探查，就會將其新增回狀況良好後端集區中。應用程式閘道預設以後端 HTTP 設定中定義的相同連接埠，傳送健全狀態探查。您可以使用自訂的健全狀態探查來設定自訂探查連接埠。

應用程式閘道探查健康情況時使用的來源 IP 位址，取決於後端集區：

如果後端集區中的伺服器位址是公用端點，則來源位址是應用程式閘道的前端公用 IP 位址。
如果後端集區中的伺服器位址是私人端點，則來源 IP 位址來自應用程式閘道子網路的私人 IP 位址空間。

預設的健全狀況探查

如果您沒有設定任何自訂探查組態，應用程式閘道會自動設定預設健全狀態探查。監視行為是對後端集區中設定的 IP 位址或 FQDN，提出 HTTP GET 要求。關於預設探查，如果後端 http 設定設為使用 HTTPS，則探查會使用 HTTPS 來測試後端伺服器的健康情況。

例如：您將應用程式閘道設定為使用 A、B 和 C 後端伺服器來接收連接埠 80 上的 HTTP 網路流量。預設狀況監控每 30 秒測試三部伺服器是否有良好 HTTP 回應，每個要求的逾時為 30 秒。狀況良好的 HTTP 回應具有 200 到 399 之間的狀態碼。在此情況下，健全狀態探查的 HTTP GET 要求看起來像 http://127.0.0.1/。

如果伺服器 A 的預設探查檢查失敗，應用程式閘道會停止將要求轉送到此伺服器。預設探查會繼續每 30 秒檢查一次伺服器 A。當伺服器 A 成功回應預設健全狀態探查的一個要求時，應用程式閘道會再次開始將要求轉送至伺服器。

預設的健全狀況探查設定

下表列出預設的健全狀態探查設定：

探查屬性	值	說明
探查 URL	`<protocol>://127.0.0.1:<port>/`	通訊協定和連接埠會繼承探查相關聯的後端 HTTP 設定
間隔	30	在傳送下一個健康情況探查之前的等候時間，以秒為單位。
逾時	30	應用程式閘道在將探查標示為狀況不良之前等待探查回應的時間，以秒為單位。如果傳回狀況良好的探查，則對應的後端會立即標示為狀況良好。
狀況不良臨界值	3	控管在定期健康情況探查失敗時，應該傳送的探查數目。在 v1 SKU 中，將會快速連續傳送這些額外的健全狀態探查，以快速判斷後端的健康情況，而不會等待探查間隔。如果是 v2 SKU，健康情況探查會等待間隔。在連續探查失敗計數達到狀況不良閾值後，就會將後端伺服器標示為故障。

探查間隔

所有應用程式閘道執行個體會彼此獨立地探查後端。每個應用程式閘道執行個體都會套用相同的探查組態。例如，如果探查組態是每 30 秒傳送健康情況探查一次，而應用程式閘道具有兩個執行個體，則這兩個執行個體都每 30 秒傳送健康情況探查一次。

如果有多個接聽程式，則每個接聽程式會各自獨立探查後端。

自訂的健全狀況探查

自訂探查可讓您更細微控制狀況監控。使用自訂探查時，您可以設定自訂主機名稱、URL 路徑、探查間隔，以及將後端集區執行個體標示為狀況不良之前可接受的失敗回應次數等。

自訂的健全狀況探查設定

下表提供自訂健全狀況探查的屬性定義。

探查屬性	說明
Name	探查的名稱。此名稱用來識別並參考後端 HTTP 設定中的探查。
通訊協定	用來傳送探查的通訊協定。此屬性必須符合相關聯後端 HTTP 設定中定義的通訊協定
Host	伴隨傳送探查的主機名稱。在 v1 SKU 中，此值只用於探查要求的主機標頭。在 v2 SKU 中，它會同時作為主機標頭和 SNI 使用
路徑	探查的相對路徑。有效路徑的開頭為 '/'
Port	如果已定義，此屬性會作為目的地連接埠。否則會使用與相關聯 HTTP 設定相同的連接埠。僅 v2 SKU 中有此屬性
間隔	探查間隔 (秒)。此值是兩個連續探查之間的時間間隔
逾時	探查逾時 (秒)。如果在這個逾時期間內未收到有效的回應，則會將探查標示為失敗
狀況不良臨界值	探查重試計數。在連續探查失敗計數達到狀況不良閾值後，就會將後端伺服器標示為故障

探查比對

根據預設，狀態碼介於 200 和 399 之間的 HTTP(S) 回應視為良好。自訂的健全狀況探查額外支援兩個比對準則。比對準則可用來選擇性修改何謂良好回應的預設解讀。

以下為比對準則：

HTTP 回應狀態碼比對：探查比對準則，以接受使用者指定的 HTTP 回應碼或回應碼範圍。支援以逗號分隔的個別回應狀態碼或一個狀態碼範圍。
HTTP 回應主體比對：探查比對準則，其會查看 HTTP 回應主體，並與使用者指定的字串進行比對。這項比對只在回應本文中尋找有無使用者指定的字串，並不是完整的規則運算式比對。

您可以使用 New-AzApplicationGatewayProbeHealthResponseMatch Cmdlet 來指定比對準則。

設定接聽程式

接聽程式是一種邏輯實體，可使用連接埠、通訊協定、主機和 IP 位址來檢查傳入連線要求。設定接聽程式時，您輸入的值必須符合閘道上連入要求中對應的值。

當您使用 Azure 入口網站建立應用程式閘道時，您也可以為接聽程式選擇通訊協定和連接埠，以建立預設接聽程式。您可以選擇是否在接聽程式上啟用 HTTP2 支援。建立應用程式閘道之後，您可以編輯該預設接聽程式 (appGatewayHttpListener) 的設定，或建立新的接聽程式。

app gateway listener configuration

接聽程式類型

當您建立新的接聽程式時，必須選擇基本或多網站。

基本：接受對任何網域的所有要求，並轉送至後端集區。
多網站：根據主機標頭或主機名稱，將要求轉送至不同的後端集區。您必須指定符合傳入要求的主機名稱。這是因為應用程式閘道仰賴 HTTP 1.1 主機標頭，才能在同一個公用 IP 位址和連接埠上裝載多個網站。

處理接聽程式的順序

若為 v1 SKU，則會根據規則順序及接聽程式類型來比對要求。如果基本接聽程式的規則先出現，則會先處理該規則，並接受對該連接埠和 IP 組合的任何要求。若要避免這種情況，請先設定多網站接聽程式的規則，並將基本接聽程式的規則推向清單的最後面。

若為 v2 SKU，則會先處理多網站接聽程式，再處理基本接聽程式。

前端 IP 位址

選擇要與此接聽程式建立關聯的前端 IP 位址。接聽程式會接聽此 IP 上的傳入要求。

前端連接埠

選擇前端連接埠。選取現有連接埠或建立新的連接埠。從允許的連接埠範圍中選擇任何值。您不僅可以使用知名的連接埠，例如 80 和 443，也可以使用合適的任何允許的自訂連接埠。連接埠可用於公開接聽程式或私用接聽程式。

通訊協定

選擇 HTTP 或 HTTPS：

HTTP：用戶端與應用程式閘道之間的流量未加密。
HTTPS：啟用 TLSs 終止或端對端 TLS 加密。 TLS 連接在應用程式閘道上終止。用戶端與應用程式閘道之間的流量會加密。如果您想要端對端 TLS 加密，則必須選擇 HTTPS 並設定後端 HTTP 設定。這可確保流量從應用程式閘道傳輸到後端時重新加密。

若要設定 TLS 終止和端對端 TLS 加密，您必須將憑證新增至接聽程式，才能讓應用程式閘道衍生對稱金鑰。對稱金鑰用來加密和解密傳送至閘道的流量。閘道憑證必須採用「個人資訊交換」(PFX) 格式。此格式可讓您匯出私密金鑰，供閘道用來加密和解密流量。

重新導向概觀

您可以使用應用程式閘道將流量重新導向。這是泛型重新導向機制，可將在一個接聽程式接收的流量重新導向至另一個接聽程式或外部網站。這可簡化應用程式組態、將資源使用量最佳化，並支援新的重新導向案例，包括全域和路徑式重新導向。

許多 Web 應用程式的一個常見重新導向情節是支援 HTTP 至 HTTPS 自動重新導向，以確保應用程式與其使用者之間的所有通訊都在加密的路徑上進行。在過去，客戶會使用一些技巧 (例如建立專屬後端集區)，其唯一目的是要將其在 HTTP 上接收的要求重新導向至 HTTPS。應用程式閘道中的重新導向支援可讓您輕鬆辦到，只要將新的重新導向設定新增至路由規則，並將另一個採用 HTTPS 通訊協定的接聽程式指定為目標接聽程式即可。

支援下列重新導向類型：

301 永久重新導向
302 已找到
303 查看其他
307 暫時重新導向

應用程式閘道重新導向支援提供下列功能：

全域重新導向：從一個接聽程式重新導向閘道上的另一個接聽程式。這允許在網站上進行 HTTP 至 HTTPS 重新導向。
以路徑為基礎的重新導向：只在特定網站區域 (例如，以 /cart/* 表示的購物車區域) 啟用 HTTP 至 HTTPS 重新導向。
重新導向至外部網站：需要新的重新導向設定物件，以指定應該重新導向的目標接聽程式或外部網站。此組態元素也支援能將 URI 路徑和查詢字串附加至重新導向 URL 的選項。重新導向設定會透過新規則而附加至來源接聽程式。

如需有關在應用程式閘道中設定重新導向的詳細資訊，請參閱使用 PowerShell 設定 URL 路徑式重新導向 - Azure 應用程式閘道 | Microsoft Docs。

應用程式閘道要求路由規則

使用 Azure 入口網站建立應用程式閘道時將會建立預設規則 (rule1)。此規則會將預設接聽程式 (appGatewayHttpListener) 繫結至預設後端集區 (appGatewayBackendPool) 和預設後端 HTTP 設定 (appGatewayBackendHttpSettings)。建立閘道之後，您可以編輯預設規則的設定，或建立新的規則。

規則類型：

「基本」將相關聯接聽程式的所有要求 (例如，blog.contoso.com/*) 轉送到單一後端集區。
「路徑式」將來自特定 URL 路徑的要求，路由傳送至特定的後端集區。

處理規則的順序

針對 v1 和 v2 SKU，依照路徑式規則的 URL 路徑對應中列出路徑的順序，處理傳入要求的模式比對。如果要求符合路徑對應中兩個或更多個路徑中的模式，則第一個列出的路徑符合。要求會轉送到該路徑相關聯的後端。

重新導向設定

如果在基本規則中設定重新導向，則會將相關聯接聽程式上的所有要求重新導向目標。這是全域重新導向。如果在路徑式規則中設定重新導向，則會只將特定網站區域中的要求重新導向。例如，以 /cart/* 表示的購物車區域。這是路徑式重新導向。

重新導向類型

選擇所需的重新導向類型：永久 (301)、暫時 (307)、找到 (302)，或查看其他 (303)。

重新導向目標

選擇另一個接聽程式或外部網站做為重新導向目標。

接聽程式

選擇接聽程式做為重新導向目標，以將流量從一個接聽程式重新導向閘道上的另一個接聽程式。

外部站台

當您想要將此規則相關聯的接聽程式上的流量重新導向外部網站時，請選擇外部網站。您可以選擇將原始要求中的查詢字串，加入轉送至重新導向目標的要求中。您無法轉送原始要求中的外部網站路徑。

重寫 HTTP 標頭和 URL

因為要求和回應封包是透過應用程式閘道，在用戶端和後端集區之間移動，您可以使用重寫規則來新增、移除或更新 HTTP(S) 要求和回應標頭，以及 URL 路徑和查詢字串參數。

標頭和 URL 參數可以設定為靜態值或其他標頭和伺服器變數。這在重要使用案例中很有用，例如，將擷取用戶端 IP 位址、移除後端的敏感性資訊、提高安全性等。

設定以 URL 為基礎的路由

URL 路徑型路由可讓您根據要求的 URL 路徑，將流量路由傳送至後端伺服器集區。有一個使用案例是將不同內容類型的要求，路由傳送至不同的後端伺服器集區。

v1 SKU 會依入口網站所列的規則順序處理規則。如果先列出了基本接聽程式，且該接聽程式符合傳入的要求，就會由該接聽程式處理。 v2 SKU 的完全相符項目優先順序則較高。但強烈建議先設定多站台接聽程式，再設定基本接聽程式。這可確保流量路由傳送到右邊後端.

UrlPathMap 組態元素

urlPathMap 元素是用來指定與後端伺服器集區對應的路徑模式。下列程式碼範例是來自範本檔案的 urlPathMap 元素程式碼片段。

"urlPathMaps": [{

 "name": "{urlpathMapName}",

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/urlPathMaps/{urlpathMapName}",

 "properties": {

 "defaultBackendAddressPool": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName1}"

 },

 "defaultBackendHttpSettings": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpSettingsList/{settingname1}"

 },

 "pathRules": [{

 "name": "{pathRuleName}",

 "properties": {

 "paths": [

 "{pathPattern}"

 ],

 "backendAddressPool": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName2}"

 },

 "backendHttpsettings": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpsettingsList/{settingName2}"

 }

 }

 }]

 }

}]

PathPattern

PathPattern 是要比對的路徑模式清單。各路徑開頭皆須為「/」，且「*」只能用於結尾位置並要加上「/」。傳送至路徑比對器的字串不會在第一個「?」或「#」後包含任何文字，且此處不允許使用這些字元。否則，PathPattern 中會允許 URL 中允許的任何字元。支援的模式取決於您是部署應用程式閘道 v1 或 v2。

PathBasedRouting 規則

類型 PathBasedRouting 的 RequestRoutingRule 可用來將接聽程式繫結至 urlPathMap。針對此接聽程式接收到的所有要求都會根據 urlPathMap 中指定的原則進行路由傳送。

在應用程式閘道中設定重寫原則

應用程式閘道可讓您重寫所選的要求和回應內容。您可以使用這項功能來轉譯 URL、查詢字串參數，以及修改要求和回應標頭。您還可以新增條件，以確保僅在符合特定條件時，才重寫 URL 或指定的標頭。這些條件所根據的是要求和回應資訊。

HTTP 標頭和 URL 重寫功能僅適用於應用程式閘道 v2 SKU。

支援的重寫類型

應用程式閘道支援多種重寫類型。

要求和回應標頭

HTTP 標頭可讓用戶端和伺服器透過要求或回應傳遞其他資訊。您可以重寫這些標頭來完成重要的工作，例如新增安全性相關的標頭欄位 (例如 HSTS/ X-XSS-Protection)、移除可能洩露敏感性資訊的回應標頭欄位，以及從 X-Forwarded-For 標頭中移除連接埠資訊。

應用程式閘道可讓您在要求和回應封包於用戶端與後端集區之間移動時，新增、移除或更新 HTTP 要求和回應標頭。

HTTP header rewrite

URL 路徑和查詢字串

應用程式閘道中的 URL 重寫功能可讓您：

重寫要求 URL 的主機名稱、路徑和查詢字串
選擇重寫接聽程式上所有要求的 URL，或只重寫符合您設定的一或多個條件的要求。這些條件以要求和回應屬性為基礎 (要求、標頭、回應標頭和伺服器變數)。
選擇根據原始 URL 或重寫的 URL 來路由傳送要求 (選取後端集區)。

重寫動作

使用重寫動作來指定您要重寫的 URL、要求標頭或回應標頭，以及您想要重寫成什麼新的值。 URL 或新的或現有標頭的值可以設定為這幾種值：

Text
要求標頭。若要指定要求標頭，您必須使用語法 {http_req_headerName}
回應標頭。若要指定回應標頭，您必須使用語法 {http_resp_headerName}
伺服器變數。若要指定伺服器變數，您必須使用 {var_serverVariable} 語法。請參閱支援的伺服器變數清單

文字、要求標頭、回應標頭和伺服器變數的組合。

重寫條件

您可以使用重寫條件 (選用設定) 來評估 HTTP(S) 要求和回應的內容，並只在符合一或多個條件時，才執行重寫。應用程式閘道使用這幾種變數來評估要求和回應的內容：

要求中的 HTTP 標頭
回應中的 HTTP 標頭
應用程式閘道伺服器變數

您可以使用條件來評估指定的變數是否存在、指定的變數是否符合特定的值，或指定的變數是否符合特定模式。

重寫設定

若要設定重寫規則，您必須建立重寫規則集，並在其中新增重寫規則設定。

重寫規則集包含：

要求路由規則關聯：重寫設定會透過路由規則，與來源接聽程式相關聯。使用基本路由規則時，重寫設定會與來源接聽程式相關聯，而且是全域標頭重寫。使用路徑式路由規則時，則是在 URL 路徑對應上定義重寫設定。在此情況下，僅適用於網站的特定路徑區域。您可以建立多個重寫集，並將每個重寫集套用至多個接聽程式。但您只能將一個重寫集套用至一個特定接聽程式。
重寫條件：這是選用設定。重寫條件會評估 HTTP(S) 要求和回應的內容。如果 HTTP(S) 要求或回應符合重寫條件，將會執行重寫動作。如果您將多個條件與某個動作產生關聯，則只有在符合所有條件時，才會執行此動作。換句話說，這是一種邏輯 AND 運算。
重寫類型：有三種類型的重寫可用：
- 重寫要求標頭
- 重寫要求標頭
- 重寫 URL 元件
  - URL 路徑：將路徑重寫為此值。
  - URL 查詢字串：將查詢字串重寫為此值。
  - 重新評估路徑對應：用來決定是否重新評估 URL 路徑對應。如果保持未核取，則會使用原始 URL 路徑來比對 URL 路徑對應中的路徑模式。如果設定為 true，則會重新評估 URL 路徑對應，以檢查是否符合重寫路徑。啟用此參數有助於在重寫後將要求路由傳送至不同的後端集區。

如需有關在應用程式閘道中設定重寫的詳細資訊，請參閱使用 Azure 應用程式閘道重寫 HTTP 標頭和 URL | Microsoft Docs。

檢定您的知識

您在替組織設定 Azure 應用程式閘道，想要確保使用者在尖峰期間不會遇到效能降低的情況。您應該進行哪個設定？

自動調整規模

手動調整

健康探詢

什麼是接聽程式？

接聽程式是一種實體，可檢查傳入連線要求。

接聽程式是一種實體，可根據基本或路徑式規則來路由傳送流量。

接聽程式是一群回應要求的伺服器。

您必須先回答所有問題，才能檢查進度。

繼續