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

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

注意

若要與 Azure 進行互動,建議使用 Azure Az PowerShell 模組。 請參閱安裝 Azure PowerShell 以開始使用。 若要了解如何遷移至 Az PowerShell 模組,請參閱將 Azure PowerShell 從 AzureRM 遷移至 Az。

概觀

設定應用程式閘道之後,您可能會看到其中一個錯誤是 伺服器錯誤:502 - 網頁伺服器在作為閘道或 Proxy 伺服器時收到不正確回應。 此錯誤可能會因為下列主要原因而發生:

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

原因

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

NSG/UDR 可能存在於應用程式閘道子網或部署應用程式 VM 的子網中。

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

解決方法

透過下列步驟來驗證 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 伺服器可以正確解析後端集區成員的 FQDN。

預設健全狀況探查的問題

原因

502 錯誤也可能是預設健康狀態探查無法連線到後端 VM 的頻繁指標。

布建應用程式閘道實例時,它會使用 BackendHttpSetting 的屬性,自動設定每個 BackendAddressPool 的預設健康情況探查。 設定此探查時不需任何使用者輸入。 具體而言,設定負載平衡規則時,會在 BackendHttpSetting 與 BackendAddressPool 之間建立關聯。 系統會針對每個關聯設定預設探查,應用程式閘道會在 BackendHttpSetting 元素中指定的埠上,啟動與 BackendAddressPool 中每個實例的定期健康情況檢查連線。

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

探查屬性 描述
探查 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、要測試的路徑,以及在將後端集區實例標示為狀況不良之前,要接受多少失敗的回應。

已新增下列其他屬性:

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

解決方法

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

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

要求逾時

原因

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

解決方法

應用程式閘道可讓您透過 BackendHttpSetting 設定此設定,然後套用至不同的集區。 不同的後端集區可以有不同的 BackendHttpSetting,並設定不同的要求逾時。

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

空白的 BackendAddressPool

原因

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

解決方法

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

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

前述 Cmdlet 的輸出應包含非空白的後端位址集區。 下列範例顯示傳回的兩個集區,這些集區是使用 FQDN 或後端 VM 的 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 應用程式的瀏覽器要求可供服務。

下一步

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