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

2025-04-12

概述

默认情况下，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 探测。仅 200 到 399 的 HTTP 状态代码被视为正常。协议和目标端口继承自 HTTP 设置。如果希望应用程序网关探测其他协议、主机名或路径，并将其他状态代码识别为“正常”，请配置自定义探测并将其与 HTTP 设置相关联。

Error messages

后端服务器超时

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

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

解决方法：检查后端服务器或应用程序为何无法在配置的超时期限内做出响应，并检查应用程序依赖项。例如，检查数据库是否存在可能导致响应延迟的任何问题。如果知道应用程序的行为，并且应用程序应仅在达到超时值后作出响应，则增加自定义探测设置中的超时值。必须具有自定义探测才能更改超时值。有关如何配置自定义探测的信息，请参阅文档页。

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

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

DNS 解析错误

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

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

解决方法：

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

TCP 连接错误

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

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

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

检查是否可以使用浏览器或 PowerShell 连接到 HTTP 设置中所述端口上的后端服务器。例如，请运行以下命令：Test-NetConnection -ComputerName www.bing.com -Port 443。
如果所述端口不是所需端口，请输入正确端口号，以便应用程序网关连接到后端服务器。
如果也无法从本地计算机上的端口进行连接，请执行以下操作：

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"
```
如果没有发现 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，则它将被标记为“正常”。否则，给定消息中它会被标记为“不正常”。

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

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

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

注意

对于与 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 服务器。

其他原因

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

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

下列一个或多个原因可能导致产生此行为：

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