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

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

應用程式閘道支援自動調整、TLS 卸載、端對端 TLS、Web 應用程式防火牆 (WAF)、以 Cookie 為基礎的工作階段親和性、以 URL 路徑為基礎的路由、多網站裝載，以及其他功能。 如需完整的支援功能清單，請參閱應用程式閘道簡介。

應用程式閘道是第 7 層負載平衡器，這表示只處理 web 流量 (HTTP、HTTPS、WebSocket 和 HTTP/2)。 支援 TLS 終止、以 Cookie 為基礎的工作階段親和性，以及循環配置資源等功能，以平衡流量負載。 Load Balancer 平衡第 4 層 (TCP 或 UDP) 的流量負載。

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

請參閱 HTTP/2 支援。

請參閱支援的後端資源 (部分機器翻譯)。

應用程式閘道 v1 (標準和 WAF) 適用於全域 Azure 的所有區域。 21Vianet 所營運的 Microsoft Azure 和 Azure Government 中也提供該功能。

針對應用程式閘道 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 逾時控制應用程式閘道在重複使用或關閉持續連線之前，應等待多少時間讓用戶端傳送另一個 HTTP 要求。 TCP 閒置逾時控制 TCP 連線在沒有活動時保持開啟的時間長度。

針對 HTTP/1.1 連線，Keep-Alive應用程式閘道 v1 和 v2 SKU 中的逾時為 120 秒。 針對私人 IP 位址，此值不可設定，且 TCP 閒置逾時為 5 分鐘。 在應用程式閘道 v1 和 v2 SKU 的前端虛擬 IP (VIP) 上，TCP 閒置逾時預設皆為 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 閑置逾時設定為與保持運作逾時相同或更長的時間。

是。 應用程式閘道會重複使用具有後端伺服器的現有 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 分鐘，以協助在更新開始之前，建立與不同更新網域中各執行個體的連線。 在更新期間，應用程式閘道會暫時以降低的容量上限執行，而這是由所設定的執行個體數目所決定。 只有在已成功升級目前的執行個體集時，更新程序才會繼續進行下一組執行個體。

¹ 我們建議針對應用程式閘道 v1 SKU 部署設定至少 2 個執行個體計數，以確保在套用更新時至少會有一個執行個體可以提供流量。

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

應用程式閘道的具有 HTTP (s) 通訊協定的第 7 層 Proxy 將不支援 SMTP、IMAP 和 POP3 等電子郵件通訊協定。 但是，對於一些支援的電子郵件服務，如 Outlook Web Access (OWA)、ActiveSync 和使用 HTTP(S) 通訊協定的 AutoDiscovery 流量，您可以使用第 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 更新 強制規定不含 SameSite 屬性的 HTTP Cookie 視同 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。 此值與虛擬機器主機名稱不同。 格式為 通訊協定<://>主機<:>連接埠<><路徑>。

是。 請參閱限制特定來源 IP 的存取 (部分機器翻譯)。

是，您可以搭配相同的連接埠號碼，使用公開和私人接聽程式來同時支援公用和私人用戶端。 如果網路安全性群組 (NSG) 與您應用程式閘道的子網路建立關聯，視其設定而定，可能需要特定的輸入規則。 深入了解。

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

應用程式閘道 v1 SKU 可以在通過 FIPS 140-2 核准的作業模式中執行，其通常稱為「FIPS 模式」。FIPS 模式會呼叫通過 FIPS 140-2 驗證的密碼編譯模組，其能確保針對加密、雜湊及簽署時使用符合 FIPS 規範的演算法。 若要確保已啟用 FIPS 模式，必須在註冊訂用帳戶後透過 PowerShell、Azure Resource Manager 範本或 REST API 設定 FIPSMode 設定，以啟用 FIPSmode 的設定。

注意：作為 FedRAMP 合規性的一部分，美國政府要求系統在 2024 年 8 月後以 FIPS 核准的模式執行。

在 V1 SKU 中啟用 FIPS 模式的步驟：

步驟 1：註冊 ‘AllowApplicationGatewayEnableFIPS’ 功能，以註冊 FIPS 模式設定的訂用帳戶。

若要使用 Azure PowerShell 進行註冊，請開啟 Cloud Shell 提示，然後輸入下列命令：

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

若要使用 Azure 入口網站進行註冊：

• 登入 Azure 入口網站並搜尋預覽功能。
• 在篩選方塊中輸入 AllowApplicationGatewayEnableFIPS。 選取 [應用程式閘道 V1 允許 FIPS 模式]，然後選取 [註冊]。

步驟 2：使用 PowerShell、Azure Resource Manager 範本或 REST API，將 enableFips 屬性設為 True。

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

變更 FIPS 模式不會影響 V1 閘道上加密套件的整體可用性。 但是，當使用橢圓曲線密碼編譯進行加密時，在停用 FIPS 模式的情况下，您可以使用 curve25519、NistP256 和 NistP384，而在啟用 FIPS 模式時，僅允許使用 NistP256 和 NistP384，並且停用 curve25519。 由於 curve25519 在 FIPS 模式下不可用，在啟用 FIPS 之前，請確保您的用戶端支援 NistP256 或 NistP384 進行安全通訊。

應用程式閘道 v2 目前透過公開預覽版僅支援私人 IP 前端設定 (無公用 IP)。 如需詳細資訊，請參閱私人應用程式閘道部署 (預覽) (部分機器翻譯)。

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

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

若要使用目前的功能將流量僅限於私人 IP 位址，請遵循此流程：

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

2. 請不要為公用前端 IP 位址建立任何接聽程式。 如果未針對公用 IP 位址建立接聽程式，則應用程式閘道不會在此位址上接聽任何流量。

3. 依優先順序使用下列設定，針對應用程式閘道子網路建立並附加網路安全性群組 (部分機器翻譯)：

   1. 允許 [來源] 為服務標籤 GatewayManager、[目的地] 為 [任何]，且目的地 [連接埠] 為 65200-65535 的流量。 Azure 基礎結構通訊需要此連接埠範圍。 這些連接埠由憑證驗證保護 (鎖定)。 如果沒有適當的憑證，外部實體 (包括閘道使用者管理員) 無法變更那些端點。

   2. 允許 [來源] 為服務標籤 AzureLoadBalancer，且目的地 [連接埠] 為 [任何] 的流量。

   3. 拒絕 [來源] 為服務標籤 Internet，且目的地 [連接埠] 為 [任何] 的流量。 在輸入規則中，將此規則設定為「最低優先順序」。

   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。 如需詳細資訊，請參閱使用 Key Vault 憑證終止 TLS。

針對多個網域型 (主機型) 路由，您可以建立多網站接聽程式、設定以 HTTPS 為通訊協定的接聽程式，以及將接聽程式和路由規則建立關聯。 如需詳細資訊，請參閱使用應用程式閘道來裝載多個網站。

否。 在 .pfx 檔案密碼中只能使用英數字元。

CA/瀏覽器成員最近發行的報表，詳述由我們的客戶、Microsoft 和較大的技術團體所簽發個憑證，而這些憑證不符合公開信任 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. 存取網站，並確認網站是否如預期般運作。 如需詳細資訊，請參閱更新應用程式閘道憑證。

如果您在應用程式閘道接聽程式中參考來自 Key Vault 的憑證，則建議您遵循下列步驟來進行快速變更：

1. 在 Azure 入口網站中，移至與應用程式閘道相關聯的 Key Vault 設定。
2. 在您的存放區中新增或匯入重新簽發的憑證。 如需詳細資訊，請參閱快速入門：使用 Azure 入口網站來建立金鑰保存庫。
3. 匯入憑證後，請移至您的應用程式閘道接聽程式設定，然後在 [從 Key Vault 選擇憑證] 下，選取 [憑證] 下拉式清單，然後選取最近新增的憑證。
4. 選取 [儲存]。 如需使用 Key Vault 憑證之應用程式閘道上 TLS 終止的詳細資訊，請參閱使用 Key Vault 憑證的 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 解決方案能透過重寫、工作階段親和性、重新導向、WebSocket、WAF 等進階功能，提供比 HTTP(S) 通訊協定更好的控制和安全性。

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

• REST API
• CLI

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

您無法針對 L7 (httpListeners) 和 L4 (listeners) 使用相同的名稱。 這也適用於其他 L4 屬性，例如 backendSettingsCollection 和 routingRules。

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

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

後端伺服器會看見應用程式閘道的 IP 位址。 我們目前不支援「用戶端 IP 保留」，其中後端應用程式可透過此功能得知原始用戶端的 IP 位址。

相同的 TLS/SSL 原則設定適用於第 7 層 (HTTPS) 和第 4 層 (TLS)。 現在，您可以為 TLS 接聽程式使用 SSL 設定檔 (用於接聽程式特定的 TLS 原則和相互驗證)。 但是，目前 SSL 設定檔只能透過 CLI、PowerShell 或 REST API 與 TLS 接聽程式關聯。

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

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

Web 應用程式防火牆 (WAF) 功能無法在使用第 4 層的情況下運作。

否。 目前不提供 UDP 支援。

相同的允許連接埠範圍和例外情況清單也適用於第 4 層 Proxy。

目前不支援對 TLS/TCP 接聽程式使用一般埠。

Kubernetes 可讓您建立 deployment 和 service 資源，以在叢集內部公開一組 Pod。 為了對外公開同樣的服務，已定義一項 Ingress (英文) 資源，其可提供負載平衡、TLS 終止和名稱型虛擬裝載。 為了滿足此 Ingress 資源，需要輸入控制器，以接聽 Ingress 資源的任何變更，並設定負載平衡器原則。

應用程式閘道輸入控制器 (AGIC) 允許應用程式閘道作為 Azure Kubernetes Service (亦稱為 AKS 叢集) 的輸入。

不支援應用程式閘道的直接設定。

如果需要變更應用程式閘道上的設定，請在輸入控制器或其他 Kubernetes 物件上使用公開的組態來進行變更，例如使用支援的註釋。 在應用程式閘道連結至應用程式閘道輸入控制器 (AGIC) 之後，幾乎所有該閘道的設定都會由輸入控制器同步控制。 如果您嘗試以命令方式或透過基礎結構即程式代碼直接設定應用程式閘道，則輸入控制器最終會覆寫這些變更。

目前，一個輸入控制器執行個體只能與一個應用程式閘道建立關聯。

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

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

如需透過 Helm 部署的 AGIC 與部署為 AKS 附加元件的 AGIC 之間的差異，請參閱 Helm 部署與 AKS 附加元件之間的差異 (部分機器翻譯)。

如需透過 Helm 部署的 AGIC 與部署為 AKS 附加元件的 AGIC 之間的差異，請參閱 Helm 部署與 AKS 附加元件之間的差異 (部分機器翻譯)，特別是記錄作為 AKS 附加元件與透過 Helm 部署的 AGIC 個別支援哪一些案例的表格。 一般來說，透過 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 上有 NSG (Standard_v2，WAF_v2) 子網路，而且已在其上啟用 NSG 流量記錄，則會看到不具決定性的行為。 目前不支援此案例。

應用程式閘道不會在其部署所在的區域中移動或儲存客戶資料。

下一步

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