Azure Web App Service 数小时不可用，.NET Core 3.1 Web API 请求失败无日志如何解决？

你附上的响应时间监控显示所有请求无正常返回：

故障时的可用性与性能诊断仅提示存在失败请求，其余资源指标无异常：

核心故障定位逻辑 #

请求处于pending状态后失败、且Application Insights未捕获日志，说明请求未进入应用业务处理逻辑，优先按以下路径排查：

1. 排除外层链路拦截问题 #

• 直接访问App Service默认域名*.azurewebsites.net测试可用性，排除自定义域名、CDN、WAF、云防火墙等上层服务的拦截/限流问题
• 查看Azure门户App Service的「活动日志」，确认故障时段是否存在平台侧区域故障、宿主机维护事件，或是账号侧的配置变更（如VNet集成调整、访问限制规则修改、认证授权配置更新等）

2. 排查应用进程状态 #

重启应用无效的场景，大概率是应用进程启动阻塞或持续崩溃：

• 尝试打开App Service的「高级工具（Kudu）」，如果Kudu无法访问，说明实例层面故障，直接调整App Service计划的实例数，新增1个实例后删除原有故障实例，强制将应用调度到健康宿主机即可快速恢复
• 如果Kudu可以正常访问，进入「进程资源管理器」查看.NET Core应用进程是否正常运行，再查看两类日志定位具体错误：
  • 系统事件日志：路径为D:\home\LogFiles\eventlog.xml，可查看应用崩溃的完整异常栈
  • IIS日志：路径为D:\home\LogFiles\w3svc<对应站点ID>\，查看请求返回的具体状态码与子状态码，例如502.3代表进程响应超时、503代表进程未就绪

3. .NET Core 3.1 应用专项排查 #

.NET Core 3.1已停止官方支持，常见启动阻塞问题可优先核对：

• 检查应用启动逻辑（Program.cs/Startup.cs）是否存在阻塞类调用，若启动时依赖的数据库、缓存、第三方接口不可用，会导致进程一直无法进入就绪状态，所有请求排队超时
• 确认App Service的「Always On」配置处于开启状态，避免应用被自动回收后启动阻塞
• 核对近期是否有代码或依赖包更新，存在兼容性问题导致进程启动失败

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