共用方式為


針對應用程式閘道中閘道不正確的錯誤進行疑難排解

了解使用 Azure 應用程式閘道時如何針對收到的閘道不正確 (502) 錯誤進行疑難排解。

注意

建議您使用 Azure Az PowerShell 模組來與 Azure 互動。 若要開始使用,請參閱安裝 Azure PowerShell (部分機器翻譯)。 若要了解如何移轉至 Az PowerShell 模組,請參閱將 Azure PowerShell 從 AzureRM 移轉至 Az

概觀

設定應用程式閘道之後,使用者可能會看到的其中一個錯誤是伺服器錯誤:502 - 網頁伺服器作為閘道器或 Proxy 伺服器時收到無效的回應。 此錯誤可能是由於下列主要原因所導致:

網路安全性群組、使用者定義的路由或自訂 DNS 問題

原因

如果因為 NSG、UDR 或自訂 DNS 而封鎖對後端的存取,應用程式閘道執行個體就無法連線到後端集區。 此問題會造成探查失敗,導致 502 錯誤。

NSG/UDR 可能出現在應用程式閘道子網路,或部署應用程式虛擬機器的子網路中。

同樣地,VNet 中有自訂 DNS 也可能造成問題。 用於後端集區成員的 FQDN 可能無法由為 VNet 設定 DNS 成員的使用者正確解析。

解決方案

透過下列步驟來驗證 NSG、UDR 和 DNS 設定:

  1. 檢查與應用程式閘道子網路相關聯的 NSG。 確定未封鎖對後端的通訊。 如需詳細資訊,請參閱網路安全性群組

  2. 檢查與應用程式閘道子網路相關聯的 UDR。 確定 UDR 不會從後端子網路將流量引導走。 例如,檢查網路虛擬設備的路由,或透過 ExpressRoute/VPN 向應用程式閘道子網路公告的預設路由。

    $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
    Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
    
  3. 檢查有效的 NSG 和後端虛擬機器的路由

    Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
    Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
    
  4. 檢查 VNet 中存在自訂 DNS。 您可以在輸出中查看 VNet 屬性的詳細資料來檢查 DNS。

    Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
    DhcpOptions            : {
                               "DnsServers": [
                                 "x.x.x.x"
                               ]
                             }
    
  5. 如果 DNS 伺服器存在,請確定 DNS 伺服器能夠正確解析後端集區成員的 FQDN。

預設健全狀況探查的問題

原因

502 錯誤也可以是預設健全狀態探查無法連線到後端 VM 的常用指標。

佈建應用程式閘道執行個體時,會使用 BackendHttpSetting 的屬性,自動將預設的健全狀況探查設定到每個 BackendAddressPool 。 設定此探查時不需任何使用者輸入。 具體而言,設定負載平衡規則時,會在 BackendHttpSetting 和 BackendAddressPool 之間建立關聯。 預設探查是針對這其中的每一個關聯所設定,而應用程式閘道會在 BackendHttpSetting 項目中指定的連接埠上,將定期的健全狀況檢查連線啟動到 BackendAddressPool 中的每一個執行個體。

下表列出與預設健全狀況探查相關聯的值:

探查屬性 Description
探查 URL http://127.0.0.1/ URL 路徑
間隔 30 探查間隔 (秒)
逾時 30 探查逾時 (秒)
狀況不良臨界值 3 探查重試計數。 連續探查失敗計數到達狀況不良臨界值後,就會將後端伺服器標示為故障。

解決方案

  • 要求的主機值將會設定為 127.0.0.1。 確定預設網站已設定且正於 127.0.0.1 上進行接聽。
  • 要求的通訊協定是由 BackendHttpSetting 通訊協定所決定。
  • URI 路徑會設定為 /
  • 如果 BackendHttpSetting 指定了 80 以外的連接埠,則應將預設網站設定為在該連接埠上進行接聽。
  • protocol://127.0.0.1:port 的呼叫應該會傳回 HTTP 結果碼 200。 此程式碼應該會在 30 秒的逾時期間內傳回。
  • 確定設定的連接埠已開啟,而且沒有任何防火牆或 Azure 網路安全性群組會在所設定的連接埠上封鎖連入或連出流量。
  • 如果 Azure 傳統 VM 或雲端服務會與 FQDN 或公用 IP 搭配使用,請確認對應的端點已開啟。
  • 如果 VM 是透過 Azure Resource Manager 所設定且位於應用程式閘道部署所在的 VNet 外部,就必須將網路安全性群組設定為允許在所需的連接埠上進行存取。

如需詳細資訊,請參閱應用程式閘道基礎結構設定

自訂健全狀況探查的問題

原因

自訂的健全狀況探查能夠對於預設探查行為提供更多彈性。 使用自訂探查時,您可以設定探查間隔、要測試的 URL 和路徑,以及在將後端集區執行個體標示為狀況不良前,可接受的失敗回應次數。

已新增下列其他屬性:

探查屬性 描述
Name 探查的名稱。 此名稱用來在後端 HTTP 設定中指出探查。
通訊協定 用來傳送探查的通訊協定。 探查會使用後端 HTTP 設定中定義的通訊協定
Host 用來傳送探查的主機名稱。 只有當應用程式閘道上設定多站台時適用。 這與 VM 主機名稱不同。
路徑 探查的相對路徑。 有效路徑的開頭為 '/'。 探查會傳送到 <通訊協定>://<主機>:<連接埠><路徑>
間隔 探查間隔 (秒)。 這是兩個連續探查之間的時間間隔。
逾時 探查逾時 (秒)。 如果在這個逾時期間內未收到有效的回應,則會將探查標示為失敗。
狀況不良臨界值 探查重試計數。 連續探查失敗計數到達狀況不良臨界值後,就會將後端伺服器標示為故障。

解決方案

確認已按照上述資料表顯示的正確設定 [自訂健全狀態探查]。 除了上述的疑難排解步驟,也請確定下列各項:

  • 確定已根據 指南正確指定探查。
  • 如果已將應用程式閘道設定為單一站台,根據預設,除非已在自訂探查中加以設定,否則應將主機名稱指定為 127.0.0.1
  • 確定對 http://<主機>:<連接埠><路徑>的呼叫會傳回 HTTP 結果碼 200。
  • 確定 Interval、Timeout 和 UnhealthyThreshold 在可接受的範圍內。
  • 若使用 HTTPS 探查,請在後端伺服器本身設定後援憑證,以確定後端伺服器不會要求您提供 SNI。

要求逾時

原因

收到使用者要求時,應用程式閘道會將設定的規則套用到該要求,並將其路由傳送到後端集區執行個體。 其會等候一段可設定的時間間隔以接收來自後端應用程式的回應。 根據預設,這個間隔為 20 秒。 在應用程式閘道 v1 中,如果應用程式閘道在此間隔中未收到來自後端應用程式的回應,則使用者要求會收到 502 錯誤。 在應用程式閘道 v2 中,如果應用程式閘道在此間隔中未收到來自後端應用程式的回應,則要求會針對第二個後端集區成員進行嘗試。 如果第二個要求失敗,使用者要求會收到 504 錯誤。

解決方案

應用程式閘道允許您透過 BackendHttpSetting 設定此組態,接著可將之套用到其他集區。 不同的後端集區可以有不同的 BackendHttpSetting,可設定不同的要求逾時。

    New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60

空白的 BackendAddressPool

原因

如果應用程式閘道在後端位址集區中未設定虛擬機器或虛擬機器擴展集,則無法路由傳送任何客戶要求,還會傳送閘道不正確的錯誤。

解決方案

請確定後端位址集區不是空的。 這可透過 PowerShell、CLI 或入口網站來完成。

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

前述 Cmdlet 的輸出應包含非空白的後端位址集區。 下列範例會顯示傳回的兩個集區,針對後端 VM 使用 FQDN 或 IP 位址進行設定。 BackendAddressPool 的佈建狀態必須是 'Succeeded'。

BackendAddressPoolsText:

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

BackendAddressPool 中狀況不良的執行個體

原因

如果 BackendAddressPool 的所有執行個體都狀況不良,則應用程式閘道不會包含任何要將使用者要求路由傳送到其中的後端。 當後端執行個體的狀況良好,但尚未部署必要的應用程式時,也可能發生此情況。

解決方案

確定執行個體的狀況良好且已正確設定應用程式。 檢查後端執行個體是否能夠從同一個 VNet 中的其他 VM 回應 Ping。 如果是使用公用端點所設定,請確定對 Web 應用程式的瀏覽器要求能夠提供服務。

上游 SSL 憑證不符合

原因

安裝在後端伺服器上的 TLS 憑證不符合主機要求標頭中收到的主機名。

在啟用端對端 TLS 的案例中,編輯適當的「後端 HTTP 設定」來達成設定,並將 後端通訊協定」設定的設定變更為 HTTPS,請務必確保後端伺服器上安裝的 TLS 憑證 CNAME 符合 HTTP 主機標頭要求中後端的主機名。

提醒您,在「後端 HTTP 設定」上啟用通訊協定 HTTPS 而非 HTTP 選項的結果,就是應用程式閘道執行個體與後端伺服器之間發生的通訊的第二個部分將會使用 TLS 加密。

由於應用程式閘道預設會將相同的 HTTP 主機標頭傳送至從用戶端接收的後端,因此您必須確定安裝在後端伺服器上的 TLS 憑證是以符合 HTTP 主機標頭中該後端伺服器所接收之主機名的 CNAME 發出。 請記住,除非另有指定,否則此主機名會與從用戶端接收的主機名相同。

例如:

假設您有應用程式閘道來提供網域的 HTTPs 要求 www.contoso.com。 您可以將網域 contoso.com 委派給 Azure DNS 公用區域,以及該區域中的 A DNS 記錄,指向要處理要求的特定應用程式應用程式閘道的公用 IP www.contoso.com

在該應用程式閘道上,您應該有主機的接聽程式 www.contoso.com,其規則具有強制使用通訊協定 HTTPS 的規則 (確保端對端 TLS)。 相同的規則可能已設定後端集區,其中兩部 VM 以 Web 伺服器身分執行 IIS。

如我們所知,在規則的「支援 HTTP 設定」中啟用 HTTPS,將會讓應用程式閘道執行個體與後端中的伺服器之間發生的通訊的第二個部分使用 TLS。

如果後端伺服器沒有針對 CNAME www.contoso.com 或 *.contoso.com 發出的 TLS 憑證,要求將會失敗,並出現 伺服器錯誤:502 - 網頁伺服器在作為閘道或 Proxy 伺服器時收到無效的回應, 因為上游 SSL 憑證 (安裝在後端伺服器上的憑證) 不符合主機標頭中的主機名, 因此 TLS 交涉將會失敗。

www.contoso.com --> APP GW 前端 IP --> 接聽程式,其規則會設定為使用通訊協定 HTTPS 而不是 HTTP --> 後端集區 --> Web 伺服器 (必須安裝適用於 www.contoso.com的 TLS 憑證)

解決方案

必須安裝於後端伺服器上的 TLS 憑證 CNAME,符合 HTTP 後端設定中所設定的主機名,否則應用程式閘道執行個體與後端之間發生的端對端通訊的第二個部分將會失敗,並出現「上游 SSL 憑證不相符」,並會擲回伺服器錯誤:502 - 網頁伺服器在作為閘道或 Proxy 伺服器時收到無效的回應

下一步

若上述步驟未解決問題,請開啟支援票證