關於 應用程式閘道的常見問題

Azure 應用程式閘道 提供應用程式傳遞控制器即服務。 提供各種第 7 層負載平衡功能，供您的應用程式使用。 這項服務具有高可用性、可調整，而且完全由 Azure 管理。

應用程式閘道 支援自動調整、TLS 卸除和端對端 TLS、Web 應用程式防火牆 （WAF）、Cookie 型會話親和性、URL 路徑型路由、多月臺裝載和其他功能。 如需支援功能的完整清單，請參閱 應用程式閘道 簡介。

應用程式閘道 是第 7 層負載平衡器，這表示它只適用於 Web 流量（HTTP、HTTPS、WebSocket 和 HTTP/2）。 它支援 TLS 終止、Cookie 型會話親和性，以及負載平衡流量的迴圈配置資源等功能。 負載平衡器會平衡第 4 層 （TCP 或 UDP） 的流量。

應用程式閘道 支援 HTTP、HTTPS、HTTP/2 和 WebSocket。

請參閱 HTTP/2 支援。

請參閱 支援的後端資源。

應用程式閘道 v1（標準和 WAF）適用於所有全球 Azure 區域。 它也可在由 21Vianet 和 Azure Government 運作的 Microsoft Azure 中取得。

如需 應用程式閘道 v2 （Standard_v2 和 WAF_v2） 可用性，請參閱 應用程式閘道 v2 的支持區域。

應用程式閘道 是虛擬網路中的專用部署。

支援重新導向。 請參閱 應用程式閘道 重新導向概觀。

請參閱接聽程式處理的順序。

如果您使用公用IP位址作為端點，您可以在公用IP位址資源上找到IP和 DNS 資訊。 或者，您可以在應用程式閘道的概觀頁面上的 [Azure 入口網站 中找到它。 如果您使用內部 IP 位址，請在 [概觀] 頁面上尋找資訊。 針對 v1 SKU，在 2023 年 5 月 1 日之後建立的閘道不會自動擁有與公用 IP 資源相關聯的預設 DNS 名稱。 針對 v2 SKU，開啟公用 IP 資源，然後選取 [ 設定]。 DNS 名稱標籤 （選擇性） 字段可用來設定 DNS 名稱。

Keep-Alive timeout 會控管應用程式閘道等候用戶端在持續連線上傳送另一個 HTTP 要求的時間，然後再重複使用或關閉它。 TCP 閑置逾時會控管沒有活動時，TCP 連線保持開啟的時間長度。

Keep-Alive應用程式閘道 v1 SKU 中的逾時為 120 秒，而 v2 SKU 則為 75 秒。 針對私人IP位址，此值不可設定，且TCP閑置逾時為5分鐘。 TCP 閑置逾時是 v1 和 v2 SKU 應用程式閘道 前端虛擬 IP （VIP） 的 4 分鐘預設值。 您可以將 v1 和 v2 應用程式閘道 上的 TCP 閑置逾時值設定為介於 4 分鐘到 30 分鐘之間的任何位置。 針對 v1 和 v2 應用程式閘道 實例，您必須移至應用程式閘道的公用 IP，並在入口網站中公用 IP 的 [組態] 窗格下變更 TCP 閑置逾時。 您可以執行下列命令，透過 PowerShell 設定公用 IP 的 TCP 閒置逾時值：

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

針對 應用程式閘道 v2 SKU 上前端IP位址的 HTTP/2 連線，閒置逾時會設定為180秒，且無法設定。

是。 應用程式閘道 使用後端伺服器重複使用現有的 TCP 連線。

否。 無法重新命名 應用程式閘道 資源。 您必須使用不同的名稱來建立新的資源。

否。 刪除之後，無法還原 應用程式閘道 資源或其公用IP。 您必須建立新的資源。

應用程式閘道 v1 SKU 中，如果您停止並啟動應用程式閘道，VIP 可能會變更。 但是與應用程式閘道相關聯的 DNS 名稱不會在閘道的存留期內變更。 因為 DNS 名稱不會變更，所以您應該使用 CNAME 別名，並將它指向應用程式閘道的 DNS 位址。 在 應用程式閘道 v2 SKU 中，IP 位址是靜態的，因此 IP 位址和 DNS 名稱不會在應用程式閘道的存留期內變更。

是。 應用程式閘道 v2 SKU 支援靜態公用IP位址和靜態內部IP。 v1 SKU 支援靜態內部IP。

應用程式閘道僅支援每個IP通訊協定的一個公用IP位址。 如果應用程式閘道設定為 DualStack，它可以支援兩個公用 IP，一個用於 IPv4，一個用於 IPv6。

請參閱 應用程式閘道 子網大小考慮。

是。 除了指定 應用程式閘道 部署的多個實例之外，您還可以將另一個唯一 應用程式閘道 資源布建至包含不同 應用程式閘道 資源的現有子網。

單一子網不支援 v2 和 v1 應用程式閘道 SKU。

是，但僅限特定案例。 如需詳細資訊，請參閱應用程式閘道基礎結構設定。

是。 請參閱 對要求的修改。

新的應用程式閘道 v1 SKU 部署最多可能需要 20 分鐘才能佈建。 執行個體大小或計數的變更不會造成干擾，且閘道在此期間會保持作用中。

大部分使用 v2 SKU 的部署大約需要 6 分鐘才能佈建。 不過，程式可能需要較長的時間，視部署類型而定。 例如，跨多個可用性區域部署有許多實例可能需要超過 6 分鐘的時間。

更新 起始至 應用程式閘道 會一次套用一個更新網域。 隨著每個更新網域的實例正在更新，其他更新網域中的其餘實例會繼續提供流量¹。 作用中聯機會從更新的實例正常清空長達 5 分鐘，以協助在更新開始之前，在不同的更新網域中建立實例的連線。 在更新期間，應用程式閘道 會暫時以降低的最大容量執行，這是由設定的實例數目所決定。 只有在目前的實例集成功升級時，更新程式才會繼續進行下一組實例。

¹ 建議至少設定 2 個實例計數，以用於 應用程式閘道 v1 SKU 部署，以確保至少一個實例可在套用更新時提供流量。

應用程式閘道支援TLS/TCP 通訊協定 Proxy 透過第 4 層 Proxy 預覽版。

使用 HTTP（S） 通訊協定的應用程式閘道第 7 層 Proxy 不支援電子郵件通訊協定，例如 SMTP、IMAP 和 POP3。 不過，對於某些支持的電子郵件服務，例如 Outlook Web Access （OWA）、ActiveSync 和使用 HTTP（S） 通訊協議的自動探索流量，您可以使用第 7 層 Proxy，其流量應該會流經。 （注意：使用 WAF SKU 時，可能需要 WAF 規則中的排除專案。

是。 如需詳細資訊，請參閱將 Azure 應用程式閘道 和 Web 應用程式防火牆 從 v1 移轉至 v2。

是。 應用程式閘道 v1 SKU 會繼續受到支援。 我們強烈建議移至 v2，以利用該 SKU 中的功能更新。 如需 v1 與 v2 功能差異的詳細資訊，請參閱自動調整和區域備援 應用程式閘道 v2。 您可以遵循 v1-v2 移轉檔，手動將 應用程式閘道 v1 SKU 部署移轉至 v2。

否。 應用程式閘道 v2 不支援使用NTLM或 Kerberos 驗證來 Proxy 處理要求。

要求標頭名稱可以包含英數位元和連字元。 當要求傳送至後端目標時，會捨棄包含其他字元的要求標頭名稱。 響應標頭名稱可以包含任何英數位元和特定符號，如 RFC 7230 中所定義。

是。 Chromium 瀏覽器v80 更新在 HTTP Cookie 上引進了授權，而不需要將 SameSite 屬性視為 SameSite=Lax。 這表示第三方內容中的瀏覽器不會傳送 應用程式閘道 親和性 Cookie。

為了支援此案例，應用程式閘道 除了現有的 ApplicationGatewayAffinity Cookie之外，還插入另一個稱為 ApplicationGatewayAffinityCORS 的Cookie。 這些 Cookie 很類似，但 ApplicationGatewayAffinityCORS Cookie 又新增了兩個屬性： SameSite=None 和 Secure。 即使跨原始來源要求，這些屬性仍會維護黏性會話。 如需詳細資訊，請參閱 以 Cookie 為基礎的親和性一節。

作用中的接聽程式是與規則 相關聯的接聽程式，並將 流量傳送至後端集區。 任何只重新導向流量的接聽程式都不是作用中的接聽程式。 與重新導向規則相關聯的接聽程式不會被視為作用中。 如果重新導向規則是以路徑為基礎的規則，該重新導向規則中的所有路徑都必須重新導向流量，否則接聽程式會被視為作用中。 如需個別元件限制詳細數據，請參閱 Azure 訂用帳戶和服務限制、配額和條件約束。

當您部署兩個或多個實例時，應用程式閘道 v1 SKU 支援高可用性案例。 Azure 會將這些執行個體分散到更新和容錯網域，以確保執行個體不會全部同時失敗。 v1 SKU 支援延展性，方法是新增相同閘道的多個實例來共用負載。

v2 SKU 會自動確保將新執行個體分散在各個容錯網域和更新網域。 如果您選擇區域備援，則最新的執行個體也會分散到各個可用性區域，以支援區域失敗復原能力。

使用 Azure 流量管理員 將流量分散到不同數據中心的多個應用程式閘道。

是。 您可以設定連線清空，以在後端集區內變更成員，而不會中斷。 如需詳細資訊，請參閱 應用程式閘道 的 連線 清空一節。

是，應用程式閘道 v2 SKU 支援自動調整。 如需詳細資訊，請參閱自動調整和區域備援 應用程式閘道。

否。 實例會分散到升級網域和容錯網域。

是。

是。

是。 應用程式閘道 一律部署在虛擬網路子網中。 此子網只能包含應用程式閘道。 如需詳細資訊，請參閱 虛擬網路和子網需求。

如果您有IP連線能力，應用程式閘道 可以與其位於虛擬網路外部的實例通訊。 應用程式閘道 也可以與其位於訂用帳戶外部的實例通訊。 如果您打算使用內部 IP 作為後端集區成員，請使用虛擬網路對等互連或 Azure VPN 閘道。

如同任何 DNS 解析程式，應用程式閘道 資源會接受後端伺服器 DNS 記錄的存留時間 （TTL） 值。 TTL 到期之後，閘道會執行查閱來更新該 DNS 資訊。 在此查閱期間，如果您的應用程式閘道遇到收到回應的問題（或找不到 DNS 記錄），閘道會繼續使用最後一個已知良好的 DNS 值來提供流量。 如需詳細資訊，請參閱 應用程式閘道的運作方式。

應用程式閘道的實例會使用虛擬網路的 DNS 組態進行名稱解析。 變更任何 DNS 伺服器組態之後，您必須重新啟動應用程式閘道，以指派新的 DNS 伺服器。 在此之前，輸出連線的 FQDN 型名稱解析可能會失敗。

否。 但您可以在子網中部署其他應用程式閘道。

您只能在相同虛擬網路內的子網之間移動應用程式閘道。 v1 具有公用和私人前端（動態配置）和 v2 僅支援公用前端。 如果以靜態方式配置私人前端IP組態，我們就無法將應用程式閘道移至另一個子網。 應用程式閘道應處於 [ 已停止] 狀態，才能執行此動作。 停止或啟動 v1 會變更公用IP。 此作業只能藉由執行下列命令來使用 Azure PowerShell 和 Azure CLI 來完成：

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

如需詳細資訊，請參閱 Set-AzApplicationGatewayIPConfiguration。

Azure CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

請參閱 應用程式閘道 子網中的網路安全組。

請參閱 應用程式閘道 子網中支援的使用者定義路由。

否。 應用程式閘道 子網不支援記憶體帳戶的服務端點原則，並設定它會封鎖 Azure 基礎結構流量。

請參閱 應用程式閘道 限制。

是。 應用程式閘道 支援每個應用程式閘道一個內部IP和一個外部IP。

是。 虛擬網路對等互連可協助平衡其他虛擬網路中的流量負載。

是，只要允許流量。

支援微服務架構。 若要在不同的埠上探查，您必須設定多個後端設定。

否。

請參閱 處理規則的順序。

[主機] 字段會指定要在 應用程式閘道 上設定多月臺時傳送探查的名稱。 否則，請使用 127.0.0.1。 此值與虛擬機主機名不同。 其格式為 protocol>：//<host>：<port><路徑>。<

是。 請參閱 限制特定來源IP的存取。

是，您可以使用具有相同埠號碼的公開和私人面向接聽程式，同時支援公用和私人用戶端。 如果網路安全組 （NSG） 與應用程式閘道的子網相關聯，視其組態而定，可能需要特定的輸入規則。 深入了解。

應用程式閘道 v2 支援 IPv4 和 IPv6 前端。 目前，IPv6 支援僅適用於新的應用程式閘道。 若要支援 IPv6，虛擬網路應該是雙重堆疊。 應用程式閘道 v1 不支援雙堆疊虛擬網路。

應用程式閘道 v1 SKU 可以在 FIPS 140-2 核准的作業模式中執行，這通常稱為「FIPS 模式」。FIPS 模式會呼叫 FIPS 140-2 驗證的密碼編譯模組，以確保啟用時符合 FIPS 規範的加密、哈希和簽署演算法。 為了確保已啟用 FIPS 模式， FIPSMode 設定必須透過 PowerShell、Azure Resource Manager 範本或 REST API 進行設定，才能啟用 的 FIPSmode設定。

應用程式閘道 v2 目前僅透過公開預覽支援私人IP前端設定（沒有公用IP）。 如需詳細資訊，請參閱私人 應用程式閘道 部署（預覽版）。

針對目前的正式運作支援，應用程式閘道 v2 支援下列組合：

• 私人IP和公用IP
• 僅限公用IP

若要將流量限制為具有目前功能的私人IP位址，請遵循此程式：

1. 建立同時具有公用和私人前端IP位址的應用程式閘道。

2. 請勿為公用前端IP位址建立任何接聽程式。 如果沒有為其建立任何接聽程式，應用程式閘道 將不會接聽公用IP位址上的任何流量。

3. 依照優先順序，為具有下列組態的 應用程式閘道 子網建立並附加網路安全組：

   1. 允許來源作為服務標籤 GatewayManager、Destination as Any 和目的地埠作為 65200-65535 的流量。 Azure 基礎結構通訊需要此連接埠範圍。 這些埠會受到憑證驗證的保護（鎖定）。 外部實體，包括閘道用戶系統管理員，無法在這些端點上起始變更，而不需要適當的憑證。

   2. 允許來源作為服務標籤 AzureLoadBalancer 和目的地埠作為 Any 的流量。

   3. 拒絕來源作為服務標籤因特網和目的地埠為 Any 的所有輸入流量。 將此規則 指定為輸入規則中的優先順序 最低。

   4. 保留 AllowVNetInBound 之類的默認規則，以免封鎖私人 IP 位址上的存取。

   5. 無法封鎖輸出因特網連線。 否則，您會遇到記錄和計量的問題。

私人IP專用存取的NSG組態範例：

您可以使用 Azure PowerShell 或 Azure CLI 來停止並啟動 應用程式閘道。 當您停止並啟動 應用程式閘道 時，計費也會停止並啟動。 在已停止的應用程式閘道上完成的任何 PUT 作業（例如新增標籤、健康情況探查或接聽程式）會觸發啟動。 建議您在更新組態之後停止應用程式閘道。

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

應用程式閘道 支援自我簽署憑證、證書頒發機構單位 （CA） 憑證、擴充驗證 （EV） 憑證、多網域 （SAN） 憑證和通配符憑證。

應用程式閘道 支援下列加密套件：

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

如需如何自定義 TLS 選項的資訊，請參閱在 應用程式閘道 上設定 TLS 原則版本和加密套件。

是。 應用程式閘道 支援 TLS 卸除和端對端 TLS，以重新加密對後端的流量。

是。 您可以將 應用程式閘道 設定為拒絕 TLS1.0、TLS1.1 和 TLS1.2。 根據預設，SSL 2.0 和 3.0 已停用且無法設定。

是。 在 應用程式閘道 中，您可以設定加密套件。 若要定義自定義原則，請至少啟用下列其中一個加密套件：

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

應用程式閘道 使用SHA256進行後端管理。

應用程式閘道 最多支援 100 個 TLS/SSL 憑證。

是，應用程式閘道 支援具有 OCSP 延伸模組的憑證，以及伺服器證書的 OCSP 裝訂。

應用程式閘道 最多支援 100 個驗證憑證。

是，應用程式閘道 v2 SKU 支援 金鑰保存庫。 如需詳細資訊，請參閱使用 Key Vault 憑證終止 TLS。

針對多個網域型（主機型）路由，您可以建立多月臺接聽程式、設定使用 HTTPS 作為通訊協定的接聽程式，並將接聽程式與路由規則產生關聯。 如需詳細資訊，請參閱使用 應用程式閘道 裝載多個網站。

否。 在您的 .pfx 檔案密碼中只使用英數位元。

CA/Browser 成員最近發佈報告，詳細說明客戶、Microsoft 所使用 CA 廠商所發行的多個憑證，以及不符合公開信任 CA 業界標準的更大技術社群。 您可以在這裡找到有關不符合規範 CA 的報告：

• Bug 1649951
• Bug 1650910

根據業界的合規性需求，CA 廠商開始撤銷不符合規範的 CA，並發行符合規範的 CA，要求客戶重新發出其憑證。 Microsoft 與這些廠商密切合作，將 Azure 服務的潛在影響降到最低。 不過，攜帶您自己的憑證 （BYOC） 案例中使用的自我發行憑證或憑證仍面臨意外撤銷的風險。

若要檢查您的應用程式所使用的憑證是否已撤銷，請參閱 DigiCert 的公告 和 證書吊銷追蹤器。 如果您的憑證已撤銷，或將會撤銷，您必須向應用程式中使用的 CA 廠商要求新的憑證。 若要避免應用程式因憑證意外撤銷而中斷可用性，或更新已撤銷的憑證，請參閱 撤銷不符合規範的證書頒發機構單位可能會影響客戶的 Azure 服務。

如需 應用程式閘道 的特定資訊：

如果您使用其中一個撤銷的 ICA 所簽發的憑證，應用程式的可用性可能會中斷。 視您的應用程式而定，您可能會收到各種錯誤訊息，包括但不限於：

• 不正確憑證/憑證已撤銷
• 連線逾時
• HTTP 502

若要避免因此問題而中斷應用程式，或重新發出已撤銷的 CA，您必須採取下列動作：

1. 請連絡您的憑證提供者，瞭解如何重新發出您的憑證。
2. 重新發出之後，請使用完整的信任鏈結更新 應用程式閘道/WAF 上的憑證（分葉、中繼和跟證書）。 根據您使用憑證的位置，在應用程式閘道的接聽程式或 HTTP 設定上，遵循這裡的步驟來更新憑證。 如需詳細資訊，請檢查所述的文件連結。
3. 更新後端應用程式伺服器以使用重新簽發的憑證。 視您使用的後端伺服器而定，憑證更新步驟可能會有所不同。 檢查廠商的檔。

若要更新接聽程式中的憑證：

1. 在 Azure 入口網站 中，開啟您的 應用程式閘道 資源。
2. 開啟與您的憑證相關聯的接聽程序設定。
3. 選取 [ 更新或編輯選取的憑證]。
4. 使用密碼上傳新的 PFX 憑證，然後選取 [ 儲存]。
5. 存取網站，並確認網站是否如預期般運作。 如需詳細資訊，請參閱更新 應用程式閘道 憑證。

如果您要在 應用程式閘道 接聽程式中參考來自 金鑰保存庫 的憑證，建議您執行下列步驟來快速變更：

1. 在 Azure 入口網站 中，移至與應用程式閘道相關聯的 金鑰保存庫 設定。
2. 在存放區中新增或匯入重新簽發的憑證。 如需詳細資訊，請參閱快速入門：使用 Azure 入口網站 建立密鑰保存庫。
3. 匯入憑證之後，請移至您的 應用程式閘道 接聽程式設定，然後在 [從 金鑰保存庫 選擇憑證] 底下，選取 [憑證] 下拉式清單，然後選取最近新增的憑證。
4. 選取 [儲存]。 如需使用 金鑰保存庫 憑證 應用程式閘道 終止 TLS 的詳細資訊，請參閱使用 金鑰保存庫 憑證終止 TLS。

若要在 HTTP 設定中更新憑證：

如果您使用 應用程式閘道/WAF 服務的 v1 SKU，則必須上傳新的憑證作為後端驗證憑證。

1. 在 Azure 入口網站 中，開啟您的 應用程式閘道 資源。
2. 開啟與您憑證相關聯的 HTTP 設定。
3. 選取 [新增憑證]、上傳重新簽發的憑證，然後選取 [ 儲存]。
4. 您稍後可以選取舊憑證旁的 [...] 選項按鈕來移除舊憑證。 選取 [ 刪除] ，然後選取 [ 儲存]。 如需詳細資訊，請參閱搭配入口網站使用 應用程式閘道 設定端對端 TLS。

如果您使用 應用程式閘道/WAF 服務的 V2 SKU，則不需要在 HTTP 設定中上傳新憑證，因為 V2 SKU 使用「受信任的跟證書」，因此不需要在這裡採取任何動作。

是。 透過應用程式閘道的第7層和第4層路由都使用相同的前端IP組態。 如此一來，您可以將所有客戶端導向單一IP位址（公用或私人），而相同的網關資源會根據已設定的接聽程式通訊協定和埠來路由。

雖然 HTTP（S） 流量也可以透過 L4 Proxy 通訊協定提供，但我們不建議這麼做。 應用程式閘道 的 L7 Proxy 解決方案透過重寫、會話親和性、重新導向、WebSockets、WAF 等進階功能，透過 HTTP（S） 通訊協定提供更高的控制和安全性。

第 4 層功能的資源屬性與第 7 層不同。 因此，使用 REST API 或 CLI 時，您必須使用下列屬性。

• REST API
• CLI

否。 您無法跨連結第 4 層和第 7 層屬性。 因此，路由規則只允許您將第 4 層型接聽程式連結到第 4 層類型的後端設定。

您無法對 L7 （httpListeners） 和 L4 （接聽程式） 使用相同的名稱。 這也適用於其他 L4 屬性，例如 backend 設定 Collection 和 routingRules。

當然 類似於第 7 層 Proxy，您可以將私人端點新增至應用程式閘道的後端集區。 此私人端點必須部署在應用程式閘道相同虛擬網路的相鄰子網中。

它不會針對後端連線使用 Keepalive。 針對前端接聽程式連線上的每個傳入要求，應用程式閘道 起始新的後端連線以滿足該要求。

後端伺服器會看到應用程式閘道的IP位址。 目前，我們不支援「用戶端IP保留」，後端應用程式可以透過此「用戶端IP保留」來瞭解原始用戶端的IP位址。

相同的 SSL 原則設定適用於第 7 層 （HTTPS） 和第 4 層 （TLS）。 目前，我們不支援 TLS 接聽程式的 SSL 配置檔（接聽程式特定 SSL 原則或相互驗證）。

否。 目前不支援將用戶端路由傳送至相同的後端伺服器。 聯機會以迴圈配置資源的方式散發至後端集區中的伺服器。

是，自動調整功能也會針對TLS或 TCP 通訊協定的流量增加和減少運作。

Web 應用程式防火牆 （WAF） 功能不適用於第 4 層使用。

否。 目前無法使用UDP支援。

Kubernetes 允許建立 deployment 和 service 資源，以在叢集中內部公開一組 Pod。 為了在外部公開相同的服務， Ingress 會定義資源，以提供負載平衡、TLS 終止和以名稱為基礎的虛擬裝載。 若要滿足此 Ingress 資源，需要輸入控制器，它會接聽資源的任何變更 Ingress ，並設定負載平衡器原則。

應用程式閘道 輸入控制器 （AGIC） 允許 應用程式閘道 作為 Azure Kubernetes Service 的輸入，也稱為 AKS 叢集。

目前，輸入控制器的一個實例只能與一個應用程式網關相關聯。

AGIC 嘗試自動將路由表資源與 應用程式閘道 子網產生關聯，但由於 AGIC 的許可權不足，因此可能無法這麼做。 如果 AGIC 無法將路由表與 應用程式閘道 子網產生關聯，AGIC 記錄中會出現錯誤。 在此情況下，您必須手動將 AKS 叢集所建立的路由表與 應用程式閘道 的子網產生關聯。 如需詳細資訊，請參閱 支援的使用者定義的路由。

是，只要虛擬網路已對等互連，而且沒有重疊的位址空間。 如果您使用 kubenet 執行 AKS，請務必將 AKS 所產生的路由表與 應用程式閘道 子網產生關聯。

如需透過 Helm 部署的 AGIC 與部署為 AKS 附加元件之間的差異，請參閱 Helm 部署與 AKS 附加元件之間的差異。

如需透過 Helm 部署的 AGIC 與部署為 AKS 附加元件之間的差異，請參閱 Helm 部署與 AKS 附加元件之間的差異，特別是記載透過 Helm 部署 AGIC 所支援案例的數據表，而不是 AKS 附加元件。 一般而言，透過 Helm 部署可讓您在正式發行之前測試 Beta 功能和發行候選專案。

否。 AGIC 附加元件是受控服務，這表示 Microsoft 會自動將附加元件更新為最新的穩定版本。

相互驗證是客戶端與伺服器之間的雙向驗證。 與 應用程式閘道的相互驗證目前可讓閘道驗證傳送要求，也就是客戶端驗證。 一般而言，用戶端是唯一驗證應用程式閘道的用戶端。 由於 應用程式閘道 現在也可以驗證用戶端，因此會變成相互驗證，其中 應用程式閘道 和用戶端彼此相互驗證。

否，相互驗證目前只在前端用戶端與應用程式閘道之間。 目前不支援後端相互驗證。

應用程式閘道 提供三個記錄：

• ApplicationGatewayAccessLog：存取記錄包含提交至應用程式閘道前端的每個要求。 數據報含呼叫端的IP、要求的URL、回應延遲、傳回碼，以及進出的位元組。它包含每個應用程式閘道的一筆記錄。
• ApplicationGatewayPerformanceLog：效能記錄會擷取每個應用程式閘道的效能資訊。 資訊包括位元組的輸送量、提供的要求總數、失敗的要求計數，以及狀況良好且狀況不良的後端實例計數。
• ApplicationGatewayFirewallLog：針對您使用 WAF 設定的應用程式網關，防火牆記錄包含透過偵測模式或預防模式記錄的要求。

所有記錄都會每隔 60 秒收集一次。 如需詳細資訊，請參閱適用於 應用程式閘道的後端健康情況、診斷記錄和計量。

使用PowerShell Cmdlet Get-AzApplicationGatewayBackendHealth 或入口網站來確認健康情況。 如需詳細資訊，請參閱應用程式閘道診斷。

診斷記錄會流向客戶的記憶體帳戶。 客戶可以根據他們的喜好設定來設定保留原則。 診斷記錄也可以傳送至事件中樞或 Azure 監視器記錄。 如需詳細資訊，請參閱應用程式閘道診斷。

在入口網站的應用程式閘道選單窗格中，選取 [ 活動記錄 ] 以存取稽核記錄。

是。 在 應用程式閘道 中，系統會在計量上設定警示。 如需詳細資訊，請參閱 應用程式閘道 計量和接收警示通知。

您可以透過數種方式來檢視和分析存取記錄。 使用 Azure 監視器記錄、Excel、Power BI 等等。

您也可以使用 Resource Manager 範本來安裝和執行熱門的 GoAccess 記錄分析器，以進行 應用程式閘道 存取記錄。 GoAccess 提供寶貴的 HTTP 流量統計數據，例如唯一訪客、要求檔案、主機、作業系統、瀏覽器和 HTTP 狀態代碼。 如需詳細資訊，請在 GitHub 中，請參閱 Resource Manager 範本資料夾中的自述檔。

通常，當對後端的存取遭到 NSG、自定義 DNS 或 應用程式閘道 子網上的使用者定義路由封鎖時，您會看到未知的狀態。 如需詳細資訊，請參閱適用於 應用程式閘道的後端健康情況、診斷記錄和計量。

由於目前的平臺限制，如果您在 應用程式閘道 v2 （Standard_v2，WAF_v2） 子網上有 NSG，而且如果您已啟用 NSG 流量記錄，您會看到非決定性的行為。 目前不支援此案例。

應用程式閘道 不會將客戶數據移出部署所在的區域。

下一步

• 若要深入瞭解 應用程式閘道，請參閱什麼是 Azure 應用程式閘道。
• 若要瞭解使用 應用程式閘道 的 TLS 終止和端對端 TLS，請參閱在 Azure 應用程式閘道 上啟用端對端 TLS。