Azure Web Application Firewall无响应：App Service配置WAF后访问超时求助

我来帮你一步步拆解这个问题——这类WAF转发超时的情况我碰到过不少，大多是配置细节或者网络权限的疏漏导致的，咱们从最基础的点开始排查：

1. 先确认App Service的访问限制是不是"拦"了WAF #

这是最常见的坑！登录Azure门户进你的App Service，找网络->访问限制：

• 如果这里设置了IP白名单，一定要把应用网关的公网IP（或者如果用了VNet集成，就加应用网关子网的IP范围）加到允许列表里。很多人部署完WAF就忘了这一步，导致WAF的请求直接被App Service拒绝，最终超时。
• 要是开了"拒绝未经允许的流量"，必须确保WAF的IP在允许范围内，不然请求根本到不了你的App Service。

2. 校验WAF（应用网关）的后端配置细节 #

WAF是依附在应用网关上面的，后端配置错了肯定转发失败：

• Backend Pool：确认你加的是App Service的FQDN，不是固定IP！App Service的IP是动态变化的，填IP的话过段时间就会失效，必须用FQDN。
• Backend Http Settings：
  • 除了端口80，重点看主机名设置：要么选"从后端目标获取主机名"，要么手动填App Service的FQDN。如果这里主机名填错，App Service接收请求后不知道怎么路由，就会卡在那里超时。
  • 检查健康探针：默认探针是访问/，如果你的App Service根路径有重定向（比如跳HTTPS）或者加载很慢，探针会失败，后端池会被标记为"不健康"，请求就发不出去。可以把探针改成访问一个简单的健康检查端点（比如/health），或者把探针超时时间调长一点。
  • 确保协议是HTTP，和你监听器的配置一致，别不小心开了HTTPS强制。

3. 检查WAF和App Service的网络连通性 #

• 先确认应用网关和App Service是不是在同一个区域？跨区域不是不行，但延迟和跨区域网络策略容易出问题，优先确保同区域部署，排除地域因素。
• 可以在应用网关的子网里临时部署一个VM，用curl http://<你的App Service FQDN>测一下连通性。如果VM访问都超时，那肯定是网络层面的问题，比如子网的NSG规则限制了出站流量，或者App Service的网络配置有问题。

4. 扒日志找线索 #

启用应用网关的诊断日志，重点看这两个日志：

• ApplicationGatewayAccessLog：这里能看到每个请求的状态码、后端响应时间。如果看到504 Gateway Timeout或者502 Bad Gateway，说明后端根本没响应；如果是403 Forbidden，那大概率是访问限制的问题。
• ApplicationGatewayPerformanceLog：看后端池的健康状态，如果大部分探针都失败，那就是后端连通性出了问题。
  另外也可以看应用网关的指标，比如BackendResponseTime、FailedRequests，这些能直观看到是后端响应慢还是请求直接失败。

5. 临时禁用WAF规则测一测 #

有时候WAF的托管规则或者自定义规则会误拦截请求，导致超时。你可以把WAF模式改成检测模式（Detection），或者临时禁用所有规则，再试访问。如果这时候能正常打开，说明是某个规则搞的鬼，再逐个排查调整规则。

6. 确认WAF端点的DNS解析 #

用nslookup <你的WAF域名>或者ping <WAF公网IP>测一下，确保解析到的是应用网关的正确IP。也可以用curl -v http://<WAF端点>看详细请求过程，看是卡在TCP握手阶段（网络问题）还是等待后端响应（后端配置问题），能帮你快速定位方向。

我之前碰到过一个几乎一模一样的案例：用户的App Service设了IP白名单，只允许公司内网访问，部署WAF后完全忘了把应用网关的IP加进去，结果WAF的请求全被拒了，超时3分钟报错。把WAF IP加到白名单后，立刻就正常了。

内容的提问来源于stack exchange，提问作者webber