DNS切换至Application Gateway后部分客户端POST请求返回Status Code 0问题排查

核心判断：大概率为客户端/中间网络层面问题，需同步验证Application Gateway配置 #

一、状态码0、无响应头的本质原因 #

状态码0且返回0字节的情况，通常意味着请求在传输层就被中断，根本没有到达Application Gateway的业务处理环节。如果是Application Gateway本身的问题（比如路由匹配失败），即使找不到后端路由，也会返回标准的HTTP状态码（如404 Not Found），而非无状态码的空响应。

二、客户端/中间网络侧的可能原因 #

• 客户端防火墙/端点安全工具拦截：多数企业级防火墙或本地安全软件对POST请求的检测逻辑更严格（比如检查请求体内容、新接入IP的信任状态）。当DNS切换到Application Gateway后，客户端请求的目标IP发生变化，若该IP未被加入安全工具的信任列表，可能会被静默阻断请求，且不返回任何响应。
• MTU分片失败：POST请求通常携带更大的请求体，若客户端与Application Gateway之间的网络MTU值不匹配，大请求体触发分片时可能导致连接中断；而GET/OPTIONS请求体极小，不会触发该问题。
• DNS缓存未更新：部分客户端可能仍缓存着旧的Azure Frontdoor地址，而Frontdoor侧可能存在针对POST请求的限制（比如WAF规则、速率限制），但这种情况会返回Frontdoor的标准响应码，而非状态码0，优先级较低。

三、Application Gateway侧的排查验证点 #

虽然日志显示“未解析到后端服务器路由”，但需同步确认以下配置，排除潜在问题：

• 路由规则的方法匹配：检查路由规则是否仅允许GET/OPTIONS方法，未包含POST。若路由规则的方法限制未覆盖POST，会导致请求无法匹配到后端路由，此时Application Gateway应返回405 Method Not Allowed，而非状态码0，但需确认日志是否完整记录了请求阶段。
• 后端池健康状态：若后端App Service的健康检查失败，Application Gateway会标记实例为不健康，但此时会返回502 Bad Gateway等状态码，与当前现象不符，可快速排除。
• WAF检测模式的异常行为：虽然检测模式仅记录规则命中、不阻断请求，但需检查WAF日志是否存在POST请求被规则标记的情况（比如误判为恶意请求），极端情况下可能出现请求被截断的边缘案例，但概率极低。

排查建议 #

1. 让异常客户端尝试使用移动网络（避开企业防火墙）发起POST请求，验证是否恢复正常；
2. 在异常客户端抓包，确认请求是否成功发送到Application Gateway的IP；
3. 检查Application Gateway的路由规则，确保POST方法被包含在允许的HTTP方法列表中；
4. 对比正常客户端与异常客户端的DNS解析结果，确认是否都指向了Application Gateway的IP。

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