为何Azure HealthCheck请求结果异常？ASP.NET应用健康检查故障

核心差异定位 #

从日志可以明确看到两个请求的关键区别：

• Azure健康检查请求：目标域名是my-app.azurewebsites.net，UserAgent为HealthCheck/1.0，被转发到TokenService并返回404
• 手动请求：目标域名是my-app.mycompany.net，返回正常200

问题根源大概率是路由/转发规则的差异化处理，而非ASP.NET健康检查本身的配置问题。

排查方向与解决步骤 #

1. 确认健康检查中间件顺序

虽然手动请求正常，但仍需确保UseHealthChecks在认证、授权及自定义路由中间件之前注册，避免健康检查请求被拦截：

var app = builder.Build();

// 优先注册健康检查，确保未授权请求也能访问
app.UseHealthChecks("/hc");

// 后续注册其他中间件
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();

app.Run();

2. 检查域名路由规则

排查应用或前端网关（如Azure Front Door、Application Gateway）是否存在针对azurewebsites.net域名的特殊转发规则：

• 应用内是否有基于Host头的自定义中间件，将my-app.azurewebsites.net的请求导向TokenService？
• 网关层是否配置了域名路由策略，错误地将azurewebsites.net下的/hc请求转发到TokenService？

3. 排查UserAgent相关拦截规则

检查是否有针对HealthCheck/1.0的特殊处理逻辑：

• 应用内的中间件是否根据UserAgent做路由转发？
• 网关或WAF是否配置了UserAgent匹配规则，将该请求导向TokenService？

4. 模拟Azure健康检查请求验证

用curl模拟Azure的请求参数，直接访问azurewebsites.net域名：

curl -A "HealthCheck/1.0" https://my-app.azurewebsites.net/hc

观察返回结果，确认是否是域名/UserAgent触发了错误路由。

5. 检查TokenService路由配置

确认TokenService是否存在错误的路由映射，比如误将/hc路径纳入其路由范围，导致接收到请求后返回404。

结论 #

最可能的根因是针对azurewebsites.net域名或HealthCheck/1.0 UserAgent的错误路由规则，导致Azure的健康检查请求未到达ASP.NET的健康检查端点，而是被转发到了没有该路径的TokenService。

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