Azure应用运行正常，但通过Azure URL访问报错且日志无异常的问题求助

佐证材料对应内容 #

• 访问报错场景：通过Azure分配的域名访问应用时，前端页面直接返回无详细堆栈的通用“应用错误”提示
• 应用运行状态：应用进程处于“运行中”标识状态，全量应用自有的运行日志未检索到任何异常报错记录

排查核心思路 #

这类问题的核心盲区大多是：之前的排查只覆盖了应用代码层的日志范围，没有覆盖Azure平台侧的请求转发全链路——大部分场景下的报错根本没有抵达应用代码层，自然不会在应用自有的日志里留下记录。 #

分阶段排查步骤 #

第一阶段：验证请求是否真的抵达应用代码层 #

• 不要仅依赖应用自行输出的业务日志判断链路状态，直接开启Azure App Service平台原生的失败请求跟踪和HTTP数据流日志，复现一次访问操作，定位请求在哪个环节被拦截返回错误：是平台路由层拦截、WAF规则拦截，还是应用进程接收到请求后主动返回的错误。
• 在应用实例内置的SSH控制台中，执行curl http://localhost:$PORT做本地环回测试，直接对比实例内部访问、外部公网访问的返回结果：
  • 若本地环回访问正常、外部公网访问报错：问题100%出在Azure平台的流量转发规则、路由配置环节，和应用代码运行状态无关
  • 若本地环回访问也返回错误：说明应用虽然进程启动了，但Web服务本身的监听配置存在问题，之前的“运行正常”判断仅校验了进程存活状态，没有校验Web服务的实际响应能力

第二阶段：匹配高频根因场景 #

• 检查应用端口绑定配置：Azure平台要求所有用户应用必须绑定到系统环境变量PORT指定的端口，如果硬编码监听其他端口（比如固定写死8080、3000），平台反向代理会因为找不到对应端口的监听服务，直接返回通用应用错误页；这类场景下应用进程完全可以正常启动、内部健康检查全部通过，但因为端口不匹配，流量根本不会被转发到应用进程，自然不会产生应用侧的访问日志。
• 检查平台层的兜底配置：在App Service的“路径映射”配置页，查看是否开启了通用自定义错误页、状态码兜底规则；一旦请求触发预设的错误阈值，平台会直接返回配置的通用错误提示，不会把详细错误信息透传到前端，也不会将这部分拦截动作记录到应用的日志中。
• 检查平台的访问规则拦截：核对App Service的IP限制、CORS跨域规则、HTTPS强制跳转配置，若出现规则匹配不通过的情况，平台会直接拦截请求返回提示，不会将流量转发到应用层。
• 检查实例资源配额状态：若应用实例的CPU、内存使用率达到当前服务计划的硬配额上限，平台会临时切断应用的对外监听通道，但短时间内仍会显示应用处于“运行中”状态，这类触发资源限流的报错也不会写入应用自有的日志。

快速修复验证 #

排查定位到根因后，可先临时关闭所有平台侧的拦截规则、修正端口绑定配置、放开错误详情透传开关，重新复现访问流程验证问题是否解决。

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