排查应用程序网关中的后端运行状况问题Troubleshoot backend health issues in Application Gateway

概述Overview

默认情况下,Azure 应用程序网关会探测后端服务器,以检查其运行状态,以及它们是否已准备好为请求提供服务。By default, Azure Application Gateway probes backend servers to check their health status and to check whether they're ready to serve requests. 用户还可以创建自定义探测,并指定主机名、要探测的路径,以及表示正常的状态代码。Users can also create custom probes to mention the host name, the path to be probed, and the status codes to be accepted as Healthy. 在每种情况下,如果后端服务器未成功响应,则应用程序网关会将该服务器标记为“不正常”,并停止向其转发请求。In each case, if the backend server doesn't respond successfully, Application Gateway marks the server as Unhealthy and stops forwarding requests to the server. 服务器成功开始响应后,应用程序网关将继续转发请求。After the server starts responding successfully, Application Gateway resumes forwarding the requests.

如何检查后端运行状况How to check backend health

若要检查后端池的运行状况,可以使用 Azure 门户中的“后端运行状况”页。 To check the health of your backend pool, you can use the Backend Health page on the Azure portal. 或者,可以使用 Azure PowerShellCLIREST APIOr, you can use Azure PowerShell, CLI, or REST API.

所述任意方法检索到的状态可能为下列其中一项:The status retrieved by any of these methods can be any one of the following:

  • 正常Healthy

  • 不正常Unhealthy

  • 未知Unknown

如果服务器的后端运行状态为“正常”,则表示应用程序网关会将请求转发到该服务器。If the backend health status for a server is Healthy, it means that Application Gateway will forward the requests to that server. 但是,如果后端池中所有服务器的后端运行状况为“不正常”或未知,则在尝试访问应用程序时,你可能会遇到问题。But if the backend health for all the servers in a backend pool is Unhealthy or unknown, you might encounter problems when you try to access applications. 本文将描述显示的每个错误的症状、原因和解决方法。This article describes the symptoms, cause, and resolution for each of the errors shown.

后端运行状态:不正常Backend health status: Unhealthy

如果后端运行状态为“不正常”,门户视图将如以下屏幕截图所示:If the backend health status is Unhealthy, the portal view will resemble the following screenshot:

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

或者,如果你使用 Azure PowerShell、CLI 或 Azure REST API 查询,则会看到如下所示的响应:Or if you're using an Azure PowerShell, CLI, or Azure REST API query, you'll get a response that resembles the following:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/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 错误的网关”错误。After you receive an Unhealthy backend server status for all the servers in a backend pool, requests aren't forwarded to the servers, and Application Gateway returns a "502 Bad Gateway" error to the requesting client. 若要排查此问题,请检查“后端运行状况”选项卡的“详细信息”列。 To troubleshoot this issue, check the Details column on the Backend Health tab.

“详细信息”列中显示的消息提供有关问题的更详细见解,根据这些信息,可以着手排查问题。 The message displayed in the Details column provides more detailed insights about the issue, and based on those, you can start troubleshooting the issue.

Note

默认探测请求以 <协议>://127.0.0.1:<端口>/ 格式发送。The default probe request is sent in the format of <protocol>://127.0.0.1:<port>/. 例如,对于端口 80 上的 HTTP 探测,格式为 http://127.0.0.1:80For example, http://127.0.0.1:80 for an http probe on port 80. 只将 HTTP 状态代码 200 至 399 视为正常。Only HTTP status codes of 200 through 399 are considered healthy. 协议和目标端口继承自 HTTP 设置。The protocol and destination port are inherited from the HTTP settings. 如果你希望应用程序网关探测不同的协议、主机名或路径,并识别其他状态代码为正常,请配置一个自定义探测,并将其关联到 HTTP 设置。If you want Application Gateway to probe on a different protocol, host name, or path and to recognize a different status code as Healthy, configure a custom probe and associate it with the HTTP settings.

错误消息Error messages

后端服务器超时Backend server timeout

消息: 后端响应应用程序网关运行状况探测所花费的时间超过了探测设置中的超时阈值。Message: Time taken by the backend to respond to application gateway's health probe is more than the timeout threshold in the probe setting.

原因: 应用程序网关将 HTTP(S) 探测请求发送到后端服务器后,它会根据配置的期限等待后端服务器的响应。Cause: After Application Gateway sends an HTTP(S) probe request to the backend server, it waits for a response from the backend server for a configured period. 如果后端服务器在配置的期限(超时值)内未做出响应,则系统会将其标记为“不正常”,直到它再次在超时期限内开始响应。If the backend server doesn't respond within the configured period (the timeout value), it's marked as Unhealthy until it starts responding within the configured timeout period again.

解决方法: 检查后端服务器或应用程序为何无法在配置的超时期限内做出响应,并检查应用程序依赖项。Resolution: Check why the backend server or application isn't responding within the configured timeout period, and also check the application dependencies. 例如,检查数据库是否存在可能触发响应延迟的任何问题。For example, check whether the database has any issues that might trigger a delay in response. 如果你了解应用程序的行为,并且它应该只在超时值之后做出响应,请增大自定义探测设置中的超时值。If you're aware of the application's behavior and it should respond only after the timeout value, increase the timeout value from the custom probe settings. 必须使用一个自定义探测来更改超时值。You must have a custom probe to change the timeout value. 有关如何配置自定义探测的信息,请参阅文档页For information about how to configure a custom probe, see the documentation page.

若要增大超时值,请执行以下步骤:To increase the timeout value, follow these steps:

  1. 直接访问后端服务器,并在该页上检查服务器做出响应所花费的时间。Access the backend server directly and check the time taken for the server to respond on that page. 可以使用任何工具来访问后端服务器,包括使用开发人员工具的浏览器。You can use any tool to access the backend server, including a browser using developer tools.

  2. 确定应用程序做出响应所需的时间后,选择“运行状况探测”选项卡,然后选择与 HTTP 设置关联的探测。 After you've figured out the time taken for the application to respond, select the Health Probes tab and then select the probe that's associated with your HTTP settings.

  3. 输入大于应用程序响应时间的任何超时值(以秒为单位)。Enter any timeout value that's greater than the application response time, in seconds.

  4. 保存自定义探测设置,检查后端运行状况现在是否显示为“正常”。Save the custom probe settings and check whether the backend health shows as Healthy now.

DNS 解析错误DNS resolution error

消息: 应用程序网关无法为此后端创建探测。Message: Application Gateway could not create a probe for this backend. 如果未正确输入后端的 FQDN,则往往会发生这种情况。This usually happens when the FQDN of the backend has not been entered correctly. 

原因: 如果后端池的类型为“IP 地址/FQDN”或“应用服务”,则应用程序网关将解析为通过域名系统 (DNS)(自定义或 Azure 默认)输入的 FQDN 的 IP 地址,并尝试连接到 HTTP 设置中指定的 TCP 端口上的服务器。Cause: If the backend pool is of type IP Address/FQDN or App Service, Application Gateway resolves to the IP address of the FQDN entered through Domain Name System (DNS) (custom or Azure default) and tries to connect to the server on the TCP port mentioned in the HTTP Settings. 但如果显示此消息,则表示应用程序网关无法成功解析输入的 FQDN 的 IP 地址。But if this message is displayed, it suggests that Application Gateway couldn't successfully resolve the IP address of the FQDN entered.

解决方法:Resolution:

  1. 验证后端池中输入的 FQDN 是否正确以及它是否为公共域,并尝试从本地计算机解析它。Verify that the FQDN entered in the backend pool is correct and that it's a public domain, and then try to resolve it from your local machine.

  2. 如果可以解析 IP 地址,则表示虚拟网络中的 DNS 配置可能有错误。If you can resolve the IP address, there might be something wrong with the DNS configuration in the virtual network.

  3. 检查是否在虚拟网络中配置了自定义 DNS 服务器。Check whether the virtual network is configured with a custom DNS server. 如果是,请检查 DNS 服务器,确定它为何无法解析为指定的 FQDN 的 IP 地址。If it is, check the DNS server about why it can't resolve to the IP address of the specified FQDN.

  4. 如果使用 Azure 默认 DNS,请与域名注册机构确认是否完成了正确的 A 记录或 CNAME 记录映射。If you're using Azure default DNS, check with your domain name registrar about whether proper A record or CNAME record mapping has been completed.

  5. 如果域是专用或内部域,请尝试从同一虚拟网络中的 VM 解析它。If the domain is private or internal, try to resolve it from a VM in the same virtual network. 如果能够解析,请重启应用程序网关,然后再次检查。If you can resolve it, restart Application Gateway and check again. 若要重启应用程序网关,需要使用相关链接资源中所述的 PowerShell 命令停止启动它。To restart Application Gateway, you need to stop and start by using the PowerShell commands described in these linked resources.

TCP 连接错误TCP connect error

消息: 应用程序网关无法连接到后端。Message: Application Gateway could not connect to the backend. 请检查后端是否在用于探测的端口上做出响应。Please check that the backend responds on the port used for the probe. 同时,请检查是否有任何 NSG/UDR/防火墙正在阻止访问此后端的 IP 和端口Also check whether any NSG/UDR/Firewall is blocking access to the Ip and port of this backend

原因: DNS 解析阶段完成后,应用程序网关会尝试连接到 HTTP 设置中配置的 TCP 端口上的后端服务器。Cause: After the DNS resolution phase, Application Gateway tries to connect to the backend server on the TCP port that's configured in the HTTP settings. 如果应用程序网关无法在指定的端口上建立 TCP 会话,则会将探测标记为不正常并显示此消息。If Application Gateway can't establish a TCP session on the port specified, the probe is marked as Unhealthy with this message.

解决方案: 如果收到此错误,请执行以下步骤:Solution: If you receive this error, follow these steps:

  1. 检查是否可以使用浏览器或 PowerShell 连接到 HTTP 设置中所述端口上的后端服务器。Check whether you can connect to the backend server on the port mentioned in the HTTP settings by using a browser or PowerShell. 例如,运行以下命令:Test-NetConnection -ComputerName www.bing.com -Port 443For example, run the following command: Test-NetConnection -ComputerName www.bing.com -Port 443

  2. 如果指定的端口不是所需的端口,请输入应用程序网关的正确端口号,以连接到后端服务器If the port mentioned is not the desired port, enter the correct port number for Application Gateway to connect to the backend server

  3. 如果在本地计算机的端口上也无法进行连接,请进行以下检查:If you can't connect on the port from your local machine as well, then:

    a.a. 检查后端服务器的网络适配器和子网的网络安全组 (NSG) 设置,并检查是否允许与配置的端口建立入站连接。Check the network security group (NSG) settings of the backend server's network adapter and subnet and whether inbound connections to the configured port are allowed. 如果不允许,请创建新规则来允许连接。If they aren't, create a new rule to allow the connections. 若要了解如何创建 NSG 规则,请参阅文档页To learn how to create NSG rules, see the documentation page.

    b.b. 检查应用程序网关子网的 NSG 设置是否允许出站公共和专用流量,以便可以建立连接。Check whether the NSG settings of the Application Gateway subnet allow outbound public and private traffic, so that a connection can be made. 查看步骤 3a 中提供的文档页来详细了解如何创建 NSG 规则。Check the document page that's provided in step 3a to learn more about how to create NSG rules.

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

    c.c. 检查应用程序网关和后端服务器子网的用户定义的路由 (UDR) 设置中是否存在任何路由异常。Check the user-defined routes (UDR) settings of Application Gateway and the backend server's subnet for any routing anomalies. 确保 UDR 未将流量引离后端子网。Make sure the UDR isn't directing the traffic away from the backend subnet. 例如,检查到网络虚拟设备的路由或通过 Azure ExpressRoute 和/或 VPN 播发到应用程序网关子网的默认路由。For example, check for routes to network virtual appliances or default routes being advertised to the Application Gateway subnet via Azure ExpressRoute and/or VPN.

    d.d. 若要检查网络适配器的有效路由和规则,可使用以下 PowerShell 命令。To check the effective routes and rules for a network adapter, you can use the following PowerShell commands:

            Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
            Get-AzEffectiveRouteTable -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
    
  4. 如果找不到 NSG 或 UDR 的任何问题,请检查后端服务器上是否存在应用程序相关的问题,从而导致客户端无法在配置的端口上建立 TCP 会话。If you don't find any issues with NSG or UDR, check your backend server for application-related issues that are preventing clients from establishing a TCP session on the ports configured. 要检查的几个方面:A few things to check:

    a.a. 打开命令提示符 (Win+R -> cmd),输入 netstat 并按 Enter。Open a command prompt (Win+R -> cmd), enter netstat, and select Enter.

    b.b. 检查服务器是否正在侦听配置的端口。Check whether the server is listening on the port that's configured. 例如:For example:

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

    c.c. 如果服务器未侦听配置的端口,请检查 Web 服务器设置。If it's not listening on the configured port, check your web server settings. 例如:IIS 中的站点绑定、NGINX 中的服务器块,以及 Apache 中的虚拟主机。For example: site bindings in IIS, server block in NGINX and virtual host in Apache.

    d.d. 检查 OS 防火墙设置,确保允许传入的流量进入端口。Check your OS firewall settings to make sure that incoming traffic to the port is allowed.

HTTP 状态代码不匹配HTTP status code mismatch

消息: 后端 HTTP 响应的状态代码与探测设置不匹配。Message: Status code of the backend's HTTP response did not match the probe setting. 预期值: {HTTPStatusCode0},收到的值: {HTTPStatusCode1}.Expected:{HTTPStatusCode0} Received:{HTTPStatusCode1}.

原因: 建立 TCP 连接并完成 TLS 握手(如果启用了 TLS)后,应用程序网关会将探测作为 HTTP GET 请求发送到后端服务器。Cause: After the TCP connection has been established and a TLS handshake is done (if TLS is enabled), Application Gateway will send the probe as an HTTP GET request to the backend server. 如上所述,默认探测针对 <协议>://127.0.0.1:<端口>/,并将 200 至 399 范围内的响应状态代码视为“正常”。As described earlier, the default probe will be to <protocol>://127.0.0.1:<port>/, and it considers response status codes in the rage 200 through 399 as Healthy. 如果服务器返回任何其他状态代码,则将服务器标记为“不正常”并显示此消息。If the server returns any other status code, it will be marked as Unhealthy with this message.

解决方案: 根据后端服务器的响应代码,可以执行以下步骤。Solution: Depending on the backend server's response code, you can take the following steps. 下面列出了一些常见的状态代码:A few of the common status codes are listed here:

错误Error 操作Actions
探测状态代码不匹配:收到 401Probe status code mismatch: Received 401 检查后端服务器是否要求身份验证。Check whether the backend server requires authentication. 应用程序网关探测此时无法传递用于身份验证的凭据。Application Gateway probes can't pass credentials for authentication at this point. 允许探测状态代码匹配中出现 "HTTP 401",或探测其中的服务器不需要身份验证的路径。Either allow "HTTP 401" in a probe status code match or probe to a path where the server doesn't require authentication.
探测状态代码不匹配:收到 403Probe status code mismatch: Received 403 禁止访问。Access forbidden. 检查后端服务器上是否允许访问该路径。Check whether access to the path is allowed on the backend server.
探测状态代码不匹配:收到 404Probe status code mismatch: Received 404 找不到页面。Page not found. 检查是否可在后端服务器上访问主机名路径。Check whether the host name path is accessible on the backend server. 将主机名或路径参数更改为可访问的值。Change the host name or path parameter to an accessible value.
探测状态代码不匹配:收到 405Probe status code mismatch: Received 405 应用程序网关的探测请求使用 HTTP GET 方法。The probe requests for Application Gateway use the HTTP GET method. 检查服务器是否允许此方法。Check whether your server allows this method.
探测状态代码不匹配:收到 500Probe status code mismatch: Received 500 内部服务器错误。Internal server error. 检查后端服务器的运行状况,以及服务是否正在运行。Check the backend server's health and whether the services are running.
探测状态代码不匹配:收到 503Probe status code mismatch: Received 503 服务不可用。Service unavailable. 检查后端服务器的运行状况,以及服务是否正在运行。Check the backend server's health and whether the services are running.

或者,如果你认为响应合法,并且你希望应用程序网关接受其他状态代码为“正常”,可以创建自定义探测。Or, if you think the response is legitimate and you want Application Gateway to accept other status codes as Healthy, you can create a custom probe. 如果后端网站需要身份验证,则此方法很有作用。This approach is useful in situations where the backend website needs authentication. 由于探测请求不携带任何用户凭据,因此它们将会失败,并且后端服务器将返回 HTTP 401 状态代码。Because the probe requests don't carry any user credentials, they will fail, and an HTTP 401 status code will be returned by the backend server.

若要创建自定义探测,请遵循这些步骤To create a custom probe, follow these steps.

HTTP 响应正文不匹配HTTP response body mismatch

消息: 后端 HTTP 响应的正文与探测设置不匹配。Message: Body of the backend's HTTP response did not match the probe setting. 收到的响应正文不包含 {string}。Received response body does not contain {string}.

原因: 创建自定义探测时,可以选择通过匹配响应正文中的字符串将后端服务器标记为正常。Cause: When you create a custom probe, you have an option to mark a backend server as Healthy by matching a string from the response body. 例如,可将应用程序网关配置为接受“unauthorized”作为要匹配的字符串。For example, you can configure Application Gateway to accept "unauthorized" as a string to match. 如果探测请求的后端服务器响应包含字符串 unauthorized,则会将该服务器标记为“正常”。If the backend server response for the probe request contains the string unauthorized, it will be marked as Healthy. 否则,会将其标记为“不正常”并显示此消息。Otherwise, it will be marked as Unhealthy with this message.

解决方案: 若要解决此问题,请执行以下步骤:Solution: To resolve this issue, follow these steps:

  1. 在本地或者通过探测路径上的某台客户端计算机访问后端服务器,并检查响应正文。Access the backend server locally or from a client machine on the probe path, and check the response body.

  2. 验证应用程序网关自定义探测配置中的响应正文是否与配置的内容相匹配。Verify that the response body in the Application Gateway custom probe configuration matches what's configured.

  3. 如果不匹配,请更改探测配置,使其包含可接受的正确字符串值。If they don't match, change the probe configuration so that is has the correct string value to accept.

详细了解应用程序网关探测匹配Learn more about Application Gateway probe matching.

后端服务器证书的 CA 无效Backend server certificate invalid CA

消息: 后端使用的服务器证书未由已知的证书颁发机构 (CA) 签名。Message: The server certificate used by the backend is not signed by a well-known Certificate Authority (CA). 请上传后端使用的服务器证书的根证书,将应用程序网关上的后端列入允许列表。Whitelist the backend on the Application Gateway by uploading the root certificate of the server certificate used by the backend.

原因: 在将服务器视为正常之前,应用程序网关 v2 的端到端 SSL 要求验证后端服务器的证书。Cause: End-to-end SSL with Application Gateway v2 requires the backend server's certificate to be verified in order to deem the server Healthy. 要信任某个 TLS/SSL 证书,后端服务器的证书必须由应用程序网关受信任存储中包含的 CA 颁发。For a TLS/SSL certificate to be trusted, that certificate of the backend server must be issued by a CA that's included in the trusted store of Application Gateway. 如果该证书不是由受信任的 CA 颁发(例如,使用了自签名证书),则用户应将颁发者的证书上传到应用程序网关。If the certificate wasn't issued by a trusted CA (for example, if a self-signed certificate was used), users should upload the issuer's certificate to Application Gateway.

解决方案: 遵循以下步骤导出受信任的根证书并将其上传到应用程序网关。Solution: Follow these steps to export and upload the trusted root certificate to Application Gateway. (这些步骤适用于 Windows 客户端。)(These steps are for Windows clients.)

  1. 登录到托管应用程序的计算机。Sign in to the machine where your application is hosted.

  2. 按 Win+R,或右键单击“开始”按钮并选择“运行”。 Select Win+R or right-click the Start button, and then select Run.

  3. 输入 certmgr.msc 并按 Enter。Enter certmgr.msc and select Enter. 也可以在“开始”菜单中搜索“证书管理器”。 You can also search for Certificate Manager on the Start menu.

  4. 找到该证书(通常位于 \Certificates - Current User\\Personal\\Certificates\ 中)并将其打开。Locate the certificate, typically in \Certificates - Current User\\Personal\\Certificates\, and open it.

  5. 选择根证书,然后选择“查看证书”。 Select the root certificate and then select View Certificate.

  6. 在“证书属性”中,选择“详细信息”选项卡。 In the Certificate properties, select the Details tab.

  7. 在“详细信息”选项卡中,选择“复制到文件”选项,并以 Base-64 编码的 X.509 (.CER) 格式保存文件。 On the Details tab, select the Copy to File option and save the file in the Base-64 encoded X.509 (.CER) format.

  8. 在 Azure 门户中打开“应用程序网关 HTTP 设置”页。 Open the Application Gateway HTTP Settings page in the Azure portal.

  9. 打开“HTTP 设置”,选择“添加证书”并找到刚刚保存的证书文件。 Open the HTTP settings, select Add Certificate, and locate the certificate file that you just saved.

  10. 选择“保存”以保存 HTTP 设置。 Select Save to save the HTTP settings.

或者,可以从客户端计算机导出根证书,方法是通过浏览器直接访问服务器(绕过应用程序网关),然后从浏览器导出根证书。Alternatively, you can export the root certificate from a client machine by directly accessing the server (bypassing Application Gateway) through browser and exporting the root certificate from the browser.

有关在应用程序网关中提取和上传受信任的根证书的详细信息,请参阅导出受信任的根证书(适用于 v2 SKU)For more information about how to extract and upload Trusted Root Certificates in Application Gateway, see Export trusted root certificate (for v2 SKU).

受信任的根证书不匹配Trusted root certificate mismatch

消息: 后端使用的服务器证书的根证书与添加到应用程序网关的受信任根证书不匹配。Message: The root certificate of the server certificate used by the backend does not match the trusted root certificate added to the application gateway. 请确保添加正确的根证书,以将后端列入允许列表Ensure that you add the correct root certificate to whitelist the backend

原因: 在将服务器视为正常之前,应用程序网关 v2 的端到端 SSL 要求验证后端服务器的证书。Cause: End-to-end SSL with Application Gateway v2 requires the backend server's certificate to be verified in order to deem the server Healthy. 要信任某个 TLS/SSL 证书,后端服务器证书必须由应用程序网关受信任存储中包含的 CA 颁发。For a TLS/SSL certificate to be trusted, the backend server certificate must be issued by a CA that's included in the trusted store of Application Gateway. 如果该证书不是由受信任的 CA 颁发(例如,使用了自签名证书),则用户应将颁发者的证书上传到应用程序网关。If the certificate wasn't issued by a trusted CA (for example, a self-signed certificate was used), users should upload the issuer's certificate to Application Gateway.

已上传到应用程序网关 HTTP 设置的证书必须与后端服务器证书的根证书相匹配。The certificate that has been uploaded to Application Gateway HTTP settings must match the root certificate of the backend server certificate.

解决方案: 如果收到此错误消息,则表示已上传到应用程序网关的证书与上传到后端服务器的证书不匹配。Solution: If you receive this error message, there's a mismatch between the certificate that has been uploaded to Application Gateway and the one that was uploaded to the backend server.

遵循上述方法中的步骤 1-11 将正确的受信任根证书上传到应用程序网关。Follow steps 1-11 in the preceding method to upload the correct trusted root certificate to Application Gateway.

有关在应用程序网关中提取和上传受信任的根证书的详细信息,请参阅导出受信任的根证书(适用于 v2 SKU)For more information about how to extract and upload Trusted Root Certificates in Application Gateway, see Export trusted root certificate (for v2 SKU).

Note

如果后端服务器在 TLS 握手期间未交换完整的证书链(包括“根”->“中间”(如果适用)->“叶”),则也可能会出现此错误。This error can also occur if the backend server doesn't exchange the complete chain of the cert, including the Root > Intermediate (if applicable) > Leaf during the TLS handshake. 若要验证,可在任何客户端中使用 OpenSSL 命令,并使用应用程序网关探测中配置的设置连接到后端服务器。To verify, you can use OpenSSL commands from any client and connect to the backend server by using the configured settings in the Application Gateway probe.

例如:For example:

OpenSSL> s_client -connect 10.0.0.4:443 -servername www.example.com -showcerts

如果输出未显示要返回的完整证书链,请使用完整链(包括根证书)再次导出证书。If the output doesn't show the complete chain of the certificate being returned, export the certificate again with the complete chain, including the root certificate. 在后端服务器中配置该证书。Configure that certificate on your backend server.

  CONNECTED(00000188)\
  depth=0 OU = Domain Control Validated, CN = \*.example.com\
  verify error:num=20:unable to get local issuer certificate\
  verify return:1\
  depth=0 OU = Domain Control Validated, CN = \*.example.com\
  verify error:num=21:unable to verify the first certificate\
  verify return:1\
  \-\-\-\
  Certificate chain\
   0 s:/OU=Domain Control Validated/CN=*.example.com\
     i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2\
  \-----BEGIN CERTIFICATE-----\
  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\
  \-----END CERTIFICATE-----

后端证书的公用名 (CN) 无效Backend certificate invalid common name (CN)

消息: 后端证书的公用名 (CN) 与探测的主机标头不匹配。Message: The Common Name (CN) of the backend certificate does not match the host header of the probe.

原因: 应用程序网关会检查后端 HTTP 设置中指定的主机名是否与后端服务器 TLS/SSL 证书提供的 CN 的主机名相匹配。Cause: Application Gateway checks whether the host name specified in the backend HTTP settings matches that of the CN presented by the backend server’s TLS/SSL certificate. 这是 Standard_v2 和 WAF_v2 SKU 的行为。This is Standard_v2 and WAF_v2 SKU behavior. Standard 和 WAF SKU 的服务器名称指示 (SNI) 设置为后端池地址中的 FQDN。The Standard and WAF SKU’s Server Name Indication (SNI) is set as the FQDN in the backend pool address.

在 v2 SKU 中,如果存在默认探测(未配置并关联自定义探测),则会根据 HTTP 设置中指定的主机名设置 SNI。In the v2 SKU, if there's a default probe (no custom probe has been configured and associated), SNI will be set from the host name mentioned in the HTTP settings. 或者,如果 HTTP 设置中指定了“从后端地址中选取主机名”,并且后端地址池包含有效的 FQDN,则会应用此设置。Or, if “Pick host name from backend address” is mentioned in the HTTP settings, where the backend address pool contains a valid FQDN, this setting will be applied.

如果某个自定义探测已关联到 HTTP 设置,则会根据自定义探测配置中指定的主机名设置 SNI。If there's a custom probe associated with the HTTP settings, SNI will be set from the host name mentioned in the custom probe configuration. 或者,如果在自定义探测中选择了“从后端 HTTP 设置中选取主机名”,则会根据 HTTP 设置中指定的主机名设置 SNI。 Or, if Pick hostname from backend HTTP settings is selected in the custom probe, SNI will be set from the host name mentioned in the HTTP settings.

如果在 HTTP 设置中设置了“从后端地址中选取主机名”,则后端地址池必须包含有效的 FQDN。 If Pick hostname from backend address is set in the HTTP settings, the backend address pool must contain a valid FQDN.

如果收到此错误消息,表示后端证书的 CN 与自定义探测或 HTTP 设置中配置的主机名不匹配(如果选择了“从后端 HTTP 设置中选取主机名”)。 If you receive this error message, the CN of the backend certificate doesn't match the host name configured in the custom probe or the HTTP settings (if Pick hostname from backend HTTP settings is selected). 如果使用默认探测,主机名将设置为 127.0.0.1If you're using a default probe, the host name will be set as 127.0.0.1. 如果这不是所需的值,应创建一个自定义探测,并将其关联到 HTTP 设置。If that’s not a desired value, you should create a custom probe and associate it with the HTTP settings.

解决方案:Solution:

若要解决该问题,请执行以下步骤。To resolve the issue, follow these steps.

对于 Windows:For Windows:

  1. 登录到托管应用程序的计算机。Sign in to the machine where your application is hosted.

  2. 按 Win+R,或右键单击“开始”按钮并选择“运行”。 Select Win+R or right-click the Start button and select Run.

  3. 输入 certmgr.msc 并按 Enter。Enter certmgr.msc and select Enter. 也可以在“开始”菜单中搜索“证书管理器”。 You can also search for Certificate Manager on the Start menu.

  4. 找到该证书(通常位于 \Certificates - Current User\\Personal\\Certificates 中)并将其打开。Locate the certificate (typically in \Certificates - Current User\\Personal\\Certificates), and open the certificate.

  5. 在“详细信息”选项卡中检查证书的“使用者”。 On the Details tab, check the certificate Subject.

  6. 验证详细信息中的证书的 CN,并在自定义探测或 HTTP 设置的主机名字段中输入相同的 CN(如果选择了“从后端 HTTP 设置中选取主机名”)。 Verify the CN of the certificate from the details and enter the same in the host name field of the custom probe or in the HTTP settings (if Pick hostname from backend HTTP settings is selected). 如果这不是网站所需的主机名,则必须获取该域的证书,或者在自定义探测或 HTTP 设置配置中输入正确的主机名。If that's not the desired host name for your website, you must get a certificate for that domain or enter the correct host name in the custom probe or HTTP setting configuration.

对于使用 OpenSSL 的 Linux:For Linux using OpenSSL:

  1. 在 OpenSSL 中运行此命令:Run this command in OpenSSL:

    openssl x509 -in certificate.crt -text -noout
    
  2. 在显示的属性中找到证书的 CN,并在 HTTP 设置的主机名字段中输入相同的 CN。From the properties displayed, find the CN of the certificate and enter the same in the host name field of the http settings. 如果这不是网站所需的主机名,则必须获取该域的证书,或者在自定义探测或 HTTP 设置配置中输入正确的主机名。If that's not the desired host name for your website, you must get a certificate for that domain or enter the correct host name in the custom probe or HTTP setting configuration.

后端证书无效Backend certificate is invalid

消息: 后端证书无效。Message: Backend certificate is invalid. 当前日期不在证书上的“生效”和“失效”日期范围内。""""Current date is not within the "Valid from" and "Valid to" date range on the certificate.

原因: 每个证书均附带有效范围,除非服务器的 TLS/SSL 证书有效,否则 HTTPS 连接不安全。Cause: Every certificate comes with a validity range, and the HTTPS connection won't be secure unless the server's TLS/SSL certificate is valid. 当前日期必须在生效失效日期范围内。The current data must be within the valid from and valid to range. 否则,证书将被视为无效,并成为一个安全隐患。在这种情况下,应用程序网关会将后端服务器标记为“不正常”。If it's not, the certificate is considered invalid, and that will create a security issue in which Application Gateway marks the backend server as Unhealthy.

解决方案: 如果 TLS/SSL 证书已过期,请向供应商续订证书,并使用新证书更新服务器设置。Solution: If your TLS/SSL certificate has expired, renew the certificate with your vendor and update the server settings with the new certificate. 如果它是自签名证书,则必须生成有效的证书,并将根证书上传到应用程序网关的 HTTP 设置。If it's a self-signed certificate, you must generate a valid certificate and upload the root certificate to the Application Gateway HTTP settings. 为此,请执行以下步骤:To do that, follow these steps:

  1. 在门户中打开应用程序网关 HTTP 设置。Open your Application Gateway HTTP settings in the portal.

  2. 选择包含已过期证书的设置,选择“添加证书”并打开新证书文件。 Select the setting that has the expired certificate, select Add Certificate, and open the new certificate file.

  3. 使用证书旁边的“删除”图标删除旧证书,然后选择“保存”。 Remove the old certificate by using the Delete icon next to the certificate, and then select Save.

证书验证失败Certificate verification failed

消息: 无法验证后端证书的有效性。Message: The validity of the backend certificate could not be verified. 若要找出原因,请在 OpenSSL 诊断信息中检查与错误代码 {errorCode} 相关的消息To find out the reason, check OpenSSL diagnostics for the message associated with error code {errorCode}

原因: 当应用程序网关无法验证证书的有效性时,将会发生此错误。Cause: This error occurs when Application Gateway can't verify the validity of the certificate.

解决方案: 若要解决此问题,请验证是否正确创建了服务器上的证书。Solution: To resolve this issue, verify that the certificate on your server was created properly. 例如,可以使用 OpenSSL 来验证证书及其属性,并尝试将证书重新上传到应用程序网关的 HTTP 设置。For example, you can use OpenSSL to verify the certificate and its properties and then try reuploading the certificate to the Application Gateway HTTP settings.

后端运行状态:未知Backend health status: unknown

如果后端运行状况显示为“未知”,门户视图将如以下屏幕截图所示:If the backend health is shown as Unknown, the portal view will resemble the following screenshot:

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

以下一种或多种原因可能会导致此行为:This behavior can occur for one or more of the following reasons:

  1. 应用程序网关子网中的 NSG 正在阻止从“Internet”对端口 65503-65534 (v1 SKU) 或 65200-65535 (v2 SKU) 进行入站访问。The NSG on the Application Gateway subnet is blocking inbound access to ports 65503-65534 (v1 SKU) or 65200-65535 (v2 SKU) from “Internet."
  2. 应用程序网关子网中的 UDR 设置为默认路由 (0.0.0.0/0),下一跃点未指定为“Internet”。The UDR on the Application Gateway subnet is set to the default route (0.0.0.0/0) and the next hop is not specified as "Internet."
  3. 默认路由是由通过 BGP 与虚拟网络建立的 ExpressRoute/VPN 连接播发的。The default route is advertised by an ExpressRoute/VPN connection to a virtual network over BGP.
  4. 自定义 DNS 服务器是在无法解析公共域名的虚拟网络中配置的。The custom DNS server is configured on a virtual network that can't resolve public domain names.
  5. 应用程序网关处于“不正常”状态。Application Gateway is in an Unhealthy state.

解决方案:Solution:

  1. 检查 NSG 是否正在阻止从 Internet 对端口 65503-65534 (v1 SKU) 或 65200-65535 (v2 SKU) 进行访问。Check whether your NSG is blocking access to the ports 65503-65534 (v1 SKU) or 65200-65535 (v2 SKU) from Internet:

    a.a. 在应用程序网关“概述”选项卡中,选择“虚拟网络/子网”链接。 On the Application Gateway Overview tab, select the Virtual Network/Subnet link.

    b.b. 在虚拟网络的“子网”选项卡中,选择已将应用程序网关部署到的子网。 On the Subnets tab of your virtual network, select the subnet where Application Gateway has been deployed.

    c.c. 检查是否配置了任何 NSG。Check whether any NSG is configured.

    d.d. 如果配置了 NSG,请在“搜索”选项卡中或者在“所有资源”下搜索该 NSG 资源。 If an NSG is configured, search for that NSG resource on the Search tab or under All resources.

    e.e. 在“入站规则”部分添加一个入站规则,以允许目标端口范围 65503-65534 (v1 SKU) 或 65200-65535 (v2 SKU),并将“源”设置为“任何”或“Internet”。 In the Inbound Rules section, add an inbound rule to allow destination port range 65503-65534 for v1 SKU or 65200-65535 v2 SKU with the Source set as Any or Internet.

    f.f. 选择“保存”,并验证是否可以查看正常的后端。 Select Save and verify that you can view the backend as Healthy. 或者,可以通过 PowerShell/CLI 执行此操作。Alternatively, you can do that through PowerShell/CLI.

  2. 检查 UDR 是否包含下一跃点不是设置为“Internet”的默认路由 (0.0.0.0/0): Check whether your UDR has a default route (0.0.0.0/0) with the next hop not set as Internet:

    a.a. 执行步骤 1a 和 1b 来确定子网。Follow steps 1a and 1b to determine your subnet.

    b.b. 检查是否配置了任何 UDR。Check whether there's any UDR configured. 如果已配置,请在搜索栏中或者在“所有资源”下搜索该资源。 If there is, search for the resource on the search bar or under All resources.

    c.c. 检查是否存在下一跃点未设置为“Internet”的任何默认路由 (0.0.0.0/0)。 Check whether there are any default routes (0.0.0.0/0) with the next hop not set as Internet. 如果设置为“虚拟设备”或“虚拟网络网关”,则必须确保虚拟设备或本地设备能够正确地将数据包路由回到 Internet 目标,且无需修改数据包。 If the setting is either Virtual Appliance or Virtual Network Gateway, you must make sure that your virtual appliance or the on-premises device can properly route the packet back to the internet destination without modifying the packet.

    d.d. 否则,请将下一跃点更改为“Internet”,选择“保存”,并验证后端运行状况。 Otherwise, change the next hop to Internet, select Save, and verify the backend health.

  3. 通过 BGP 与虚拟网络建立的 ExpressRoute/VPN 连接播发的默认路由:Default route advertised by the ExpressRoute/VPN connection to the virtual network over BGP:

    a.a. 如果 ExpressRoute/VPN 通过 BGP 连接到虚拟网络,并且你正在播发默认路由,则必须确保数据包在不修改的情况下可路由回到 Internet 目标。If you have an ExpressRoute/VPN connection to the virtual network over BGP, and if you are advertising a default route, you must make sure that the packet is routed back to the internet destination without modifying it. 可以使用应用程序网关门户中的“连接故障排除”选项进行验证。 You can verify by using the Connection Troubleshoot option in the Application Gateway portal.

    b.b. 手动选择任何可通过 Internet 路由的 IP 地址(例如 1.1.1.1)作为目标。Choose the destination manually as any internet-routable IP address like 1.1.1.1. 将目标端口设置为任意端口,然后验证连接。Set the destination port as anything, and verify the connectivity.

    c.c. 如果下一跃点是虚拟网络网关,则可能存在通过 ExpressRoute 或 VPN 播发的默认路由。If the next hop is virtual network gateway, there might be a default route advertised over ExpressRoute or VPN.

  4. 如果在虚拟网络中配置了自定义 DNS 服务器,请验证服务器是否可以解析公共域。If there's a custom DNS server configured on the virtual network, verify that the server (or servers) can resolve public domains. 在应用程序网关必须连接到外部域(例如 OCSP 服务器)或检查证书的吊销状态的情况下,可能需要进行公共域名解析。Public domain name resolution might be required in scenarios where Application Gateway must reach out to external domains like OCSP servers or to check the certificate’s revocation status.

  5. 若要验证应用程序网关是否正常且正在运行,请在门户中转到“资源运行状况”选项,并验证状态是否为“正常”。 To verify that Application Gateway is healthy and running, go to the Resource Health option in the portal and verify that the state is Healthy. 如果看到“不正常”或“降级”状态,请联系支持人员If you see an Unhealthy or Degraded state, contact support.

后续步骤Next steps

详细了解应用程序网关诊断和日志记录Learn more about Application Gateway diagnostics and logging.