Azure App Service显示HTTP 400但日志返回200 OK如何排查

这类无应用日志、后端返回200、改custom error拿不到详情的400，本质是错误根本没走到业务逻辑层，基本都出在IIS前端、AspNetCoreModule反向代理、认证前置校验这几个环节，按以下顺序定位：

• 先拿完整的详细错误文件定位子状态
  别只看KUDU里Detailed Errors模块的页面提示，直接进D:\home\LogFiles\DetailedErrors\路径，下载对应报错时间戳生成的原始错误文件，找里面的HttpSubStatus（400子状态码）和Module（触发错误的模块）字段。常见的比如400.1是无效请求头、400.5是URL序列校验被拦截、400.0是ANCM模块转发失败，不同子状态根因差得很远，跳过这一步瞎试效率极低。
• 优先查认证Cookie问题（登录后报错的最高频原因）
  报错刚好卡在登录完成、写认证Cookie后的第一次跳转，这类问题90%是Cookie被前端层拦了：
  • 开浏览器F12抓登录后跳错的请求，算下所有请求头的总长度，重点看Cookie头的大小。Azure App Service前端IIS默认单请求头总长度限制是16KB，要是认证Cookie里塞了太多claims，很容易超这个阈值，请求直接被IIS打回400，根本不会转发到.NET 6的Kestrel进程，自然啥应用日志都没有，改custom error也没用。
  • 看Cookie值里有没有没编码的中文、换行符、非法控制字符，要是自定义过认证Cookie序列化逻辑，这类非法字符一抓一个准，直接触发IIS请求校验拦截。
  • 临时改Cookie策略做对照：在Program.cs里把认证Cookie的SecurePolicy设为CookieSecurePolicy.SameAsRequest，SameSite设为Lax，排除Cookie策略不匹配的问题。
• 查AspNetCoreModuleV2代理层配置
  .NET 6在Azure App Service上是靠AspNetCoreModuleV2反向代理转发到Kestrel的，这一层抛的错不会进业务日志：
  • 改站点根目录的web.config，把stdout日志开了：把stdoutLogEnabled设为true，日志输出路径配成.\logs\stdout（提前建目录给应用写权限），重启站点复现问题，直接看stdout里的ANCM报错，之前没开这个日志的话这部分错误完全看不到。
  • 临时放宽请求限制做对照：在web.config的<httpRuntime>节点加maxRequestLength="2097152"，在<security><requestFiltering>节点下加<requestLimits maxAllowedContentLength="2147483647" maxUrl="32768" maxQueryString="32768"/>，排除URL、查询字符串、请求体长度超默认限制的问题。
  • 查ForwardedHeaders中间件配置：要是开了反向代理头校验，确认配置和Azure App Service的转发规则匹配，部分版本的这个中间件校验不通过时直接返400，还不往常规日志里写。
• 分层测试卡错误发生的层级
  别只从公网访问测，直接进KUDU的Debug Console用curl，带上和浏览器里失败请求完全一样的Cookie、请求头，直接打本地应用的监听端口（端口从环境变量WEBSITE_PORT拿，地址格式http://localhost:{端口}）：
  • 本地请求返200、公网访问返400，问题100%在App Service前端的IIS/ARR层，和应用代码、后端Container App半毛钱关系没有，直接查ARR和前端配置就行。
  • 本地请求也返400，问题在应用的前置中间件，逐段注释中间件二分定位就行。
  • 测的时候可以临时加两个应用设置：WEBSITE_DISABLE_HTTP2 = true、ARR_ONLY_USE_SSL = false，关了HTTP2和ARR的强制SSL校验，排除HTTP2头压缩、SSL策略不匹配导致的误拦截。
• 开失败请求跟踪（FREB）抓全链路
  前面几步都没找到问题的话，直接开IIS失败请求跟踪，配置捕获400状态码的请求，复现后下载跟踪日志。这个日志是IIS层ETW采集的，会记下来请求从进来到出去每一步每个模块的处理动作，能精准看到是哪个模块把响应改成了400，完全不受应用custom error配置影响，是定位IIS层无日志报错的最靠谱手段。

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