已启用Always On的Azure App Service闲置后需重启问题求助

生效前提排查 #

• Always On仅在基本、标准、高级、孤立定价层可用，如果你使用免费/共享定价层，即便配置页开启开关也不会实际生效，先确认定价层匹配要求。

探活逻辑配置修复 #

• Always On默认每5分钟向应用根路径/发送GET请求判定应用存活，如果根路径配置了鉴权、HTTPS强制跳转、登录页重定向，或者返回4xx/5xx状态码，探活会判定失败，平台仍会回收应用进程。
• 可通过以下方式修复：
  1. 在.NET Core应用中添加独立的健康检查端点，示例代码如下：

  // Program.cs 服务注册部分添加
  builder.Services.AddHealthChecks();
  // 中间件管道配置部分添加
  app.MapHealthChecks("/health");
  

  注意该/health端点不要配置任何鉴权、跳转逻辑，确保访问直接返回200状态码
  2. 进入Azure Portal对应App Service的【配置】-【健康检查】页面，开启健康检查并将路径设置为/health，配置合理的探测间隔。

应用异常崩溃修复 #

• 若应用存在未捕获的代码异常、依赖资源不可用导致进程意外退出，不属于常规闲置回收场景，Always On不会主动拉起进程。可进入App Service的【诊断和解决问题】面板，搜索「应用崩溃」「可用性报告」查看对应的崩溃日志，定位异常代码修复。
• 可启用平台自动修复能力：进入【配置】-【常规设置】找到「自动修复」模块，配置触发规则（如HTTP 5xx错误超过阈值、内存占用过高、请求超时次数达标）后自动重启进程，无需人工干预。

冷启动优化 #

• 若应用初始化逻辑复杂、依赖外部资源加载耗时过长，会导致探活请求超时被平台判定为应用未响应。可将非核心启动逻辑迁移到后台异步任务执行，不要阻塞主启动流程。
• 开启.NET Core编译优化：发布时启用ReadyToRun、分层编译配置，大幅减少冷启动耗时。

部署槽位适配 #

• 如果你使用了部署槽位做蓝绿/灰度发布，需确认所有启用的槽位的Always On、健康检查配置完全一致，避免流量切换后槽位配置不匹配导致的进程回收。

内容的提问来源于stack exchange，提问作者Furaha Damién