Compartir a través de

排查应用程序网关中的后端运行状况问题

  • Artículo

概述

默认情况下，Azure 应用程序网关会探测后端服务器，以检查其运行状态，以及它们是否已准备好为请求提供服务。 用户还可以创建自定义探测，并指定主机名、要探测的路径，以及表示正常的状态代码。 在每种情况下，如果后端服务器未成功响应，则应用程序网关会将该服务器标记为“不正常”，并停止向其转发请求。 服务器成功开始响应后，应用程序网关将继续转发请求。

如何检查后端运行状况

若要检查后端池的运行状况，可以使用 Azure 门户中的“后端运行状况”页。 或者，可以使用 Azure PowerShell、CLI 或 REST API。

所述任意方法检索到的状态可能为以下任一状态：

  • 正常
  • 不正常
  • 未知

如果服务器状态正常，应用程序网关会将请求从后端池转发到服务器。 如果后端池中的所有服务器都运行不正常或未知，则客户端在访问后端应用程序时可能会遇到问题。 继续阅读本文，了解后端运行状况报告的不同消息、原因及其解决方法。

注意

如果用户无权查看后端运行状况，则会显示输出 No results.。

后端运行状态：不正常

如果后端运行状况为“不正常”，门户视图将类似于以下屏幕截图：

应用程序网关后端运行状况 - 不正常

如果你使用的是 Azure PowerShell、CLI 或 Azure REST API 查询，你将收到类似于如下所示的响应：

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

在收到后端池中所有服务器的后端服务器状态都为“不正常”后，请求将不会转发到这些服务器，并且应用程序网关会向请求客户端返回“502 错误的网关”错误。 若要排查此问题，请检查“后端运行状况”选项卡的“详细信息”列。

“详细信息”列中显示的消息提供了有关问题更加详细的见解，根据这些详细信息，可以着手排查问题。

注意

默认探测请求以 <协议>://127.0.0.1:<端口> 的格式发送。 例如，http://127.0.0.1:80 表示端口 80 上的 HTTP 探测。 只将 HTTP 状态代码 200 至 399 视为正常。 协议和目标端口继承自 HTTP 设置。 如果你希望应用程序网关探测不同的协议、主机名或路径，并识别其他状态代码为正常，请配置一个自定义探测，并将其关联到 HTTP 设置。

Error messages

后端服务器超时

消息：后端响应应用程序网关运行状况探测所需的时间超过探测设置中的超时阈值。

原因： 应用程序网关将 HTTP(S) 探测请求发送到后端服务器后，它会根据配置的期限等待后端服务器的响应。 如果后端服务器未在该时间段（超时值）内响应，则将其标记为“运行不正常”，直到它再次在配置的超时时间段内响应为止。

解决方法： 检查后端服务器或应用程序为何无法在配置的超时期限内做出响应，并检查应用程序依赖项。 例如，检查数据库是否存在可能触发响应延迟的任何问题。 如果你了解应用程序的行为，并且它应该只在超时值之后做出响应，请增大自定义探测设置中的超时值。 必须使用一个自定义探测来更改超时值。 有关如何配置自定义探测的信息，请参阅文档页。

若要增大超时值，请执行以下步骤：

  1. 直接访问后端服务器，并在该页面上查看服务器响应所需时间。 可以使用任何工具来访问后端服务器，包括使用开发人员工具的浏览器。
  2. 确定应用程序响应所需的时间后，选择“运行状况探测”选项卡，然后选择与 HTTP 设置关联的探测。
  3. 输入大于应用程序响应时间的任何超时值（以秒为单位）。
  4. 保存自定义探测设置，检查后端运行状况现在是否显示为“正常”。

DNS 解析错误

消息： 应用程序网关无法为此后端创建探测。 未正确输入后端的 FQDN 时，通常会发生这种情况。 

原因：如果后端池的类型为 IP 地址、FQDN（完全限定的域名）或应用服务，应用程序网关将解析为通过 DNS 输入的 FQDN 的 IP 地址（自定义或 Azure 默认）。 然后，应用程序网关尝试连接到 HTTP 设置中所提及的 TCP 端口上的服务器。 但如果显示此消息，则表示应用程序网关无法成功解析输入的 FQDN 的 IP 地址。

解决方法：

  1. 验证后端池中输入的 FQDN 是否正确以及它是否为公共域，然后尝试从本地计算机对它进行解析。
  2. 如果可以解析 IP 地址，则表示虚拟网络中的 DNS 配置可能有错误。
  3. 检查是否在虚拟网络中配置了自定义 DNS 服务器。 如果是，请检查 DNS 服务器，确定它为何无法解析为指定的 FQDN 的 IP 地址。
  4. 如果使用的是 Azure 默认 DNS，请向域名注册机构验证是否完成了正确的 A 记录或 CNAME 记录映射。
  5. 如果域是专用或内部域，请尝试从同一虚拟网络中的 VM 解析它。 如果能够解析，请重启应用程序网关，然后再次检查。 若要重启应用程序网关，需要使用相关链接资源中所述的 PowerShell 命令停止再启动它。

TCP 连接错误

消息： 应用程序网关无法连接到后端。 检查后端是否在用于探测的端口上做出响应。 同时，请检查是否有任何 NSG/UDR/防火墙正在阻止访问此后端的 IP 和端口。

原因：DNS 解析阶段结束后，应用程序网关会尝试连接到 HTTP 设置中配置的 TCP 端口上的后端服务器。 如果应用程序网关无法在指定的端口上建立 TCP 会话，则会将探测标记为不正常并显示此消息。

解决方案： 如果收到此错误，请执行以下步骤：

  1. 检查是否可以使用浏览器或 PowerShell 连接到 HTTP 设置中所述端口上的后端服务器。 例如，请运行以下命令：Test-NetConnection -ComputerName www.bing.com -Port 443。

  2. 如果所述端口不是所需端口，请输入正确端口号，以便应用程序网关连接到后端服务器。

  3. 如果在本地计算机的端口上也无法进行连接，请进行以下检查：

    a. 检查后端服务器的网络适配器和子网的网络安全组 (NSG) 设置，并检查是否允许与配置的端口建立入站连接。 如果不允许，请创建新规则来允许连接。 若要了解如何创建 NSG 规则，请参阅文档页。

    b. 检查应用程序网关子网的 NSG 设置是否允许出站公共和专用流量，以便可以建立连接。 查看步骤 3a 中提供的文档页来详细了解如何创建 NSG 规则。

            $vnet = Get-AzVirtualNetwork -Name "vnetName" -ResourceGroupName "rgName"
        Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet

    c. 检查应用程序网关和后端服务器子网的用户定义的路由 (UDR) 设置中是否存在任何路由异常。 确保 UDR 未将流量引离后端子网。 例如，检查到网络虚拟设备的路由或通过 Azure ExpressRoute 和/或 VPN 播发到应用程序网关子网的默认路由。

    d. 若要检查网络适配器的有效路由和规则，可使用以下 PowerShell 命令。

            Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
        Get-AzEffectiveRouteTable -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"

  4. 如果找不到 NSG 或 UDR 的任何问题，请检查后端服务器上是否存在应用程序相关的问题，从而导致客户端无法在配置的端口上建立 TCP 会话。 需要检查的若干事项：

    a. 打开命令提示符 (Win+R -> cmd)，输入 netstat，然后选择 Enter。

    b. 检查服务器是否正在配置的端口上侦听。 例如：

            Proto Local Address Foreign Address State PID
        TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4

    c. 如果服务器未侦听配置的端口，请检查 Web 服务器设置。 例如：IIS 中的站点绑定、NGINX 中的服务器块，以及 Apache 中的虚拟主机。

    d. 检查 OS 防火墙设置，确保允许传入的流量进入端口。

HTTP 状态代码不匹配

消息：后端 HTTP 响应的状态代码与探测设置不匹配。 预期值: {HTTPStatusCode0}，收到的值: {HTTPStatusCode1}.

原因：建立 TCP 连接并完成 TLS 握手（如果启用了 TLS）后，应用程序网关会将探测作为 HTTP GET 请求发送到后端服务器。 如前所述，默认探测将设置为 <protocol>://127.0.0.1:<port>/，它会将 200 至 399 范围内的响应状态代码视为“正常”。 如果服务器返回其他任何状态代码，则在此消息中其将被标记为“不正常”。

解决方案： 根据后端服务器的响应代码，可以执行以下步骤。 下面列出了一些常见的状态代码：

错误 操作
探测状态代码不匹配：收到 401 检查后端服务器是否要求身份验证。 应用程序网关探测无法传递用于身份验证的凭据。 允许探测状态代码匹配中出现“HTTP 401”，或探测其中的服务器不需要身份验证的路径。
探测状态代码不匹配：收到 403 访问被禁止。 检查后端服务器上是否允许访问该路径。
探测状态代码不匹配：收到 404 找不到页面。 检查是否可在后端服务器上访问主机名路径。 将主机名或路径参数更改为可访问的值。
探测状态代码不匹配：收到 405 应用程序网关的探测请求使用 HTTP GET 方法。 检查服务器是否允许此方法。
探测状态代码不匹配：收到 500 内部服务器错误。 检查后端服务器的运行状况，以及服务是否正在运行。
探测状态代码不匹配：收到 503 服务不可用。 检查后端服务器的运行状况，以及服务是否正在运行。

或者，如果你认为响应合法，并且你希望应用程序网关接受其他状态代码为“正常”，可以创建自定义探测。 如果后端网站需要身份验证，则此方法很有作用。 探测请求将因不包含任何用户凭据而失败，并且后端服务器会返回 HTTP 401 状态代码。

若要创建自定义探测，请遵循这些步骤。

HTTP 响应正文不匹配

消息：后端的 HTTP 响应正文与探测设置不匹配。 收到的响应正文不包含 {string}。

原因：创建自定义探测时，可以通过匹配响应正文中的字符串将后端服务器标记为正常。 例如，可以将应用程序网关配置为接受“unauthorized”作为要匹配的字符串。 如果探测请求的后端服务器响应包含字符串 unauthorized，则它将被标记为“正常”。 否则，给定消息中它会被标记为“不正常”。

解决方案： 若要解决此问题，请执行以下步骤：

  1. 在本地或者通过探测路径上的某台客户端计算机访问后端服务器，并检查响应正文。
  2. 验证应用程序网关自定义探测配置中的响应正文是否与配置的内容相匹配。
  3. 如果两者不匹配，请更改探测配置，以便接收正确的字符串值。

详细了解应用程序网关探测匹配。

注意

对于与 TLS 相关的所有错误消息，若要详细了解 SNI 行为以及 v1 与 v2 SKU 之间的差异，请参阅 TLS 概述页。

公用名 (CN) 不匹配

消息：（适用于 V2）后端服务器提供的叶证书的公用名与应用程序网关的探测或后端设置主机名不匹配。
（适用于 V1）后端证书的公用名 (CN) 不匹配。

原因：（适用于 V2）如果在后端设置中选择 HTTPS 协议，并且自定义探测和后端设置的主机名（按此顺序）与后端服务器证书的公用名 (CN) 都不匹配，就会出现这种情况。
（适用于 V1）后端池目标的 FQDN 与后端服务器证书的公用名 (CN) 不匹配。

解决方案：主机名信息对于后端 HTTPS 连接至关重要，因为此值用于在 TLS 握手期间设置服务器名称指示 (SNI)。 可根据网关配置，通过以下方式解决此问题。

对于 V2，

  • 如果使用的是默认探测器 - 可以在应用程序网关的相关后端设置中指定主机名。 可在后端设置中选择“使用特定主机名替代”或“从后端目标中选取主机名”。
  • 如果使用的是自定义探测 - 对于自定义探测，可以使用“主机”字段来指定后端服务器证书的公用名。 如果后端设置已使用相同的主机名配置，也可在探测设置中选择“从后端设置中选取主机名”。

对于 V1，验证后端池目标的 FQDN 是否与公用名 (CN) 相同。

提示：要确定后端服务器证书的公用名 (CN)，可使用以下任一方法。 另请注意，根据 RFC 6125，如果 SAN 存在，则仅针对该字段执行 SNI 验证。 如果证书中没有 SAN，则匹配公用名字段。

  • 通过浏览器或任何客户端：直接访问后端服务器（不通过应用程序网关），单击地址栏中的证书挂锁以查看证书详细信息。 可以在“颁发对象”部分下找到它。 在浏览器中显示证书详细信息的屏幕截图。

  • 通过登录到后端服务器 (Windows)：

    1. 登录到托管应用程序的计算机。
    2. 按 Win+R，或右键单击“开始”按钮并选择“运行”。
    3. 输入 certlm.msc 并按 Enter。 也可以在“开始”菜单中搜索“证书管理器”。
    4. 找到证书（通常位于证书 - 本地计算机\个人\证书中），然后打开该证书。
    5. 在“详细信息”选项卡中检查证书的“使用者”。

  • 通过登录到后端服务器 (Linux)：通过指定正确的证书文件名 openssl x509 -in certificate.crt -subject -noout 来运行此 OpenSSL 命令

后端证书已过期

消息： 后端证书无效。 当前日期不在证书上的“生效”和“失效”日期范围内。

原因：已过期的证书被认为不安全，因此应用程序网关将具有过期证书的后端服务器标记为运行不正常。

解决方案：解决方案取决于后端服务器上证书链的哪一部分已过期。

对于 V2 SKU，

  • 已过期的叶（也称为域或服务器）证书 - 通过证书提供商续订服务器证书并在后端服务器上安装新证书。 确保已安装包含 Leaf (topmost) > Intermediate(s) > Root 的完整证书链。 根据证书颁发机构 (CA) 的类型，可以在网关上执行以下操作。

    • 公开已知的 CA：如果证书颁发者是已知的 CA，则无需在应用程序网关上执行任何操作。
    • 专用 CA：如果叶证书是由专用 CA 颁发的，则需要检查签名根 CA 证书是否已更改。 在这种情况下，必须将新的根 CA 证书 (.CER) 上传到网关的关联后端设置。

  • 过期的中间证书或根证书 - 通常，这些证书的有效期相对较长（十年或两年）。 如果根/中间证书过期，建议向证书提供商查询续订的证书文件。 确保已在后端服务器上安装包含 Leaf (topmost) > Intermediate(s) > Root 的这个已更新的完整证书链。

    • 如果根证书保持不变或者颁发者是已知的 CA，则无需在应用程序网关上执行任何操作。
    • 使用专用 CA 时，如果根 CA 证书本身或续订的中间证书的根已更改，则必须将新的根证书上传到应用程序网关的后端设置。

对于 V1 SKU，

  • 使用 CA 续订已过期的叶（也称为域或服务器）证书，并将同一叶证书 (.CER) 上传到应用程序网关的关联后端设置。

找不到中间证书

消息：后端服务器提供的证书链中缺少中间证书。 请确保证书链完整且其在后端服务器上的排序正确。

原因：中间证书未安装在后端服务器上的证书链中。

解决方案：中间证书用于对叶证书进行签名，因此需要该证书才能完成链。 请与证书颁发机构 (CA) 核实所需的中间证书，并将其安装在后端服务器上。 此链必须从叶证书开始，然后是中间证书，最后是根 CA 证书。 建议在后端服务器上安装完整的链，包括根 CA 证书。 有关参考，请查看叶必须位于链的最顶层下的证书链示例。

注意

非证书颁发机构的自签名证书也会导致相同的错误。 这是因为应用程序网关将此类自签名证书视为“叶”证书，并查找其签名的中间证书。 可以按照本文正确生成自签名证书。

以下图像显示自签名证书之间的差异。 显示自签名证书之间的差异的屏幕截图。

找不到叶证书或服务器证书

消息：后端服务器提供的证书链中缺少叶证书。 请确保链完整且其在后端服务器上的排序正确。

原因：后端服务器上的证书链中缺少叶（也称为域或服务器）证书。

解决方案：可以从证书颁发机构 (CA) 获取叶证书。 在后端服务器上安装此叶证书及其所有签名证书（中间证书和根 CA 证书）。 此链必须从叶证书开始，然后是中间证书，最后是根 CA 证书。 建议在后端服务器上安装完整的链，包括根 CA 证书。 有关参考，请查看叶必须位于链的最顶层下的证书链示例。

服务器证书不是由公开已知的 CA 颁发的

消息：后端服务器证书未由已知的证书颁发机构 (CA) 签名。 若要使用未知的 CA 证书，必须将其根证书上传到应用程序网关的后端设置。

原因：在后端设置中选择了“已知的 CA 证书”，但后端服务器提供的根证书并非公开已知。

解决方案：如果叶证书是由专用证书颁发机构 (CA) 颁发的，则必须将签名根 CA 的证书上传到应用程序网关的关联后端设置。 这样，应用程序网关就能够与该后端服务器建立信任连接。 要解决此问题，请转到关联的后端设置，选择“不是已知的 CA”并上传根 CA 证书 (.CER)。 要标识并下载根证书，可以按照受信任的根证书不匹配中所述的相同步骤进行操作。

中间证书不是由公开已知的 CA 签名的。

消息：中间证书未由已知的证书颁发机构 (CA) 签名。 请确保证书链完整且其在后端服务器上的排序正确。

原因：在后端设置中选择了“已知的 CA 证书”，但后端服务器提供的中间证书未由任何公开已知的 CA 签名。

解决方案：如果证书是由专用证书颁发机构 (CA) 颁发的，则必须将签名根 CA 的证书上传到应用程序网关的关联后端设置。 这样，应用程序网关就能够与该后端服务器建立信任连接。 要解决此问题，请联系专用 CA 以获取相应的根 CA 证书 (.CER)，并通过选择“非已知的 CA”将该 CER 文件上传到应用程序网关的后端设置。 还建议在后端服务器上安装完整的链（包括根 CA 证书），以便于验证。

受信任的根证书不匹配（后端服务器上没有根证书）

消息：中间证书未由上传到应用程序网关的任何根证书签名。 请确保证书链完整且其在后端服务器上的排序正确。

原因：上传到关联后端设置的根 CA 证书均未对后端服务器上安装的中间证书进行签名。 后端服务器仅安装了叶证书和中间证书。

解决方案：叶证书由中间证书签名，而中间证书又由根 CA 证书签名。 使用专用证书颁发机构 (CA) 的证书时，必须将相应的根 CA 证书上传到应用程序网关。 请联系专用 CA 以获取相应的根 CA 证书 (.CER)，并将该 CER 文件上传到应用程序网关的后端设置。

受信任的根证书不匹配（后端服务器上提供根证书）

消息：后端使用的服务器证书的根证书与添加到应用程序网关的受信任根证书不匹配。 请确保添加正确的根证书，以将后端列入允许列表。

原因：如果上传到应用程序网关后端设置的根证书与后端服务器上提供的根证书都不匹配，就会发生此错误。

解决方案：这适用于由专用证书颁发机构 (CA) 颁发的后端服务器证书或者是自签名证书。 标识正确的根 CA 证书并将其上传到关联的后端设置。

提示：若要标识并下载根证书，可使用以下任一方法。

  • 使用浏览器：直接访问后端服务器（不通过应用程序网关），单击地址栏中的证书挂锁以查看证书详细信息。

    1. 选择链中的根证书，然后单击“导出”。 默认情况下，这是一个 .CRT 文件。
    2. 打开该 .CRT 文件。
    3. 转到“详细信息”选项卡，然后单击“复制到文件”,
    4. 在“证书导出向导”页上，单击“下一步”，
    5. 选择“Base-64 编码的 X.509(.CER)”，然后单击“下一步”，
    6. 提供新的文件名，然后单击“下一步”，
    7. 单击“完成”以获取 .CER 文件。
    8. 将专用 CA 的此根证书 (.CER) 上传到应用程序网关的后端设置。

  • 通过登录到后端服务器 (Windows)

    1. 登录到托管应用程序的计算机。
    2. 按 Win+R，或右键单击“开始”按钮并选择“运行”。
    3. 输入 certlm.msc 并按 Enter。 也可以在“开始”菜单中搜索“证书管理器”。
    4. 找到证书（通常位于证书 - 本地计算机\个人\证书中），然后将其打开。
    5. 选择根证书，然后选择“查看证书”。
    6. 在“证书”属性中，选择“详细信息”选项卡，然后单击“复制到文件”，
    7. 在“证书导出向导”页上，单击“下一步”，
    8. 选择“Base-64 编码的 X.509(.CER)”，然后单击“下一步”，
    9. 提供新的文件名，然后单击“下一步”，
    10. 单击“完成”以获取 .CER 文件。
    11. 将专用 CA 的此根证书 (.CER) 上传到应用程序网关的后端设置。

叶必须位于链的最顶层。

消息：叶证书不是后端服务器提供的链中最顶层的证书。 请确保证书链在后端服务器上的排序正确。

原因：未按正确顺序在后端服务器上安装叶（也称为域或服务器）证书。

解决方案：后端服务器上的证书安装必须包含已排序的证书列表，其中包含叶证书及其所有签名证书（中间证书和根 CA 证书）。 此链必须从叶证书开始，然后是中间证书，最后是根 CA 证书。 建议在后端服务器上安装完整的链，包括根 CA 证书。

给定的示例为服务器证书安装及其中间证书和根 CA 证书，它们在 OpenSSL 中表示为深度（0、1、2 等）。 可使用以下 OpenSSL 命令验证后端服务器的证书是否相同。
s_client -connect <FQDN>:443 -showcerts
或
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

显示典型证书链的屏幕截图。

证书验证失败

消息： 无法验证后端证书的有效性。 若要找出原因，请在 OpenSSL 诊断信息中检查与错误代码 {errorCode} 相关的消息

原因： 当应用程序网关无法验证证书的有效性时，将会发生此错误。

解决方案： 若要解决此问题，请验证是否正确创建了服务器上的证书。 例如，可以使用 OpenSSL 来验证证书及其属性，并尝试将证书重新上传到应用程序网关的 HTTP 设置。

后端运行状态：未知

后端池的 DNS 条目更新

消息：无法检索后端运行状况状态。 如果应用程序网关子网上的 NSG/UDR/防火墙阻止端口 65503-65534（对于 v1 SKU）和端口 65200-65535（对于 v2 SKU）上的流量，或后端池中配置的 FQDN 无法解析为 IP 地址时，将发生这种情况。 若要了解详细信息，请访问 - https://aka.ms/UnknownBackendHealth。

原因：对于金鱼 FQDN（完全限定域名）的后端目标，应用程序网关会缓存并使用最后一个已知良好的 IP 地址（如果无法获取后续 DNS 查找的响应）。 处于此状态的网关上的 PUT 操作将完全清除其 DNS 缓存。 因此，网关将无法访问任何目标地址。

解决：检查并修复 DNS 服务器，确保它为给定 FDQN 的 DNS 查找提供响应。 还必须检查是否可通过应用程序网关的虚拟网络访问 DNS 服务器。

其他原因

如果后端运行状况显示为未知，门户视图将类似于以下屏幕截图：

应用程序网关后端运行状况 - 未知

以下一种或多种原因可能会导致此行为：

  1. 应用程序网关子网中的 NSG 正在阻止从“Internet”对端口 65503-65534 (v1 SKU) 或 65200-65535 (v2 SKU) 进行入站访问。
  2. 应用程序网关子网上的 UDR 设置为默认路由 (0.0.0.0/0)，且下一个跃点未指定为“Internet”。
  3. 默认路由是由通过 BGP 与虚拟网络建立的 ExpressRoute/VPN 连接播发的。
  4. 自定义 DNS 服务器是在无法解析公共域名的虚拟网络中配置的。
  5. 应用程序网关处于“不正常”状态。

解决方案：

  1. 检查 NSG 是否正在阻止从 Internet 对端口 65503-65534 (v1 SKU) 或 65200-65535 (v2 SKU) 进行访问。

    a. 在应用程序网关“概述”选项卡中，选择“虚拟网络/子网”链接。 b. 在虚拟网络的“子网”选项卡上，选择部署应用程序网关的子网。 c. 检查是否配置了任何 NSG。 d. 如果配置了 NSG，请在“搜索”选项卡中或者在“所有资源”下搜索该 NSG 资源。 e. 在“入站规则”部分，添加一个入站规则，以允许 v1 SKU 的目标端口范围为 65503-65534，v2 SKU 的目标端口范围为 65200-65535，同时将“源”设置为“GatewayManager”服务标记。 f. 选择“保存”，并验证是否可以查看正常的后端。 或者，可以通过 PowerShell/CLI 执行此操作。

  2. 检查 UDR 是否包含下一跃点不是设置为“Internet”的默认路由 (0.0.0.0/0)：

    a. 执行步骤 1a 和 1b 来确定子网。 b. 检查是否配置了 UDR。 如果已配置，请在搜索栏中或者在“所有资源”下搜索该资源。 c. 检查是否存在下一个跃点未设置为“Internet”的任何默认路由 (0.0.0.0/0)。 如果设置为“虚拟设备”或“虚拟网络网关”，必须确保虚拟设备或本地设备能够正确地将数据包路由回 Internet 目标，而无需修改数据包。 如果探测通过虚拟设备路由并已经过修改，则后端资源会显示 200 状态代码，应用程序网关运行状况状态可能显示为“未知”。 这并不表示出现错误。 流量仍可正常地通过应用程序网关路由。 d. 否则，请将下一跃点更改为“Internet”，选择“保存”，并验证后端运行状况。

  3. 由通过 BGP（边界网关协议）连接到虚拟网络的 ExpressRoute/VPN 播发的默认路由：

    a. 如果拥有通过 BGP 连接到虚拟网络的 ExpressRoute/VPN，并且打算播发默认路由，则必须确保在不修改数据包的情况下可以将其路由回 Internet 目标。 可以使用应用程序网关门户中的“连接故障排除”选项进行验证。 b. 手动选择任何可通过 Internet 路由的 IP 地址（例如 1.1.1.1）作为目标。 将目标端口设置为任意端口，然后验证连接。 c. 如果下一跃点是虚拟网络网关，则可能存在通过 ExpressRoute 或 VPN 播发的默认路由。

  4. 如果虚拟网络中配置了自定义 DNS 服务器，请验证服务器是否可以解析公共域。 在应用程序网关必须连接到 OCSP（联机证书状态协议）服务器等外部域或检查证书的吊销状态等情况下，可能需要进行公共域名解析。

  5. 若要验证应用程序网关是否正常运行，请转到门户中的“资源运行状况”选项，并验证状态是否为“正常”。 如果看到“不正常”或“降级”状态，请联系支持人员。

  6. 如果 Internet 和专用流量要通过托管在安全虚拟中心中的 Azure 防火墙（使用 Azure 虚拟 WAN 中心）：

    a. 若要确保应用程序网关可以直接将流量发送到 Internet，请配置以下用户定义路由：

    地址前缀：0.0.0.0/0
    下一跃点：Internet

    b. 若要确保应用程序网关能够通过虚拟 WAN 中心的 Azure 防火墙将流量发送到后端池，请配置以下用户定义路由：

    地址前缀：后端池子网
    下一个跃点：Azure 防火墙专用 IP 地址

注意

如果应用程序网关无法访问 CRL 终结点，它可能会将后端运行状况标记为“未知”。 为了防止这些问题，请检查应用程序网关子网是否能够访问 crl.microsoft.com 和 crl3.digicert.com。 这可以通过配置网络安全组以将流量发送到 CRL 终结点来实现。

后续步骤

详细了解应用程序网关诊断和日志记录。