Azure免费试用Bot框架Web应用服务超时问题求助

我之前在Azure免费环境部署Bot时也碰到过一模一样的问题，折腾了好一阵子才理清根源。结合你的情况，我整理了几个针对性的排查和解决方向：

1. 先确认Always On的实际生效情况 #

你提到已经启用了“Always On”，但要注意：Azure App Service的免费层（F1）其实不支持Always On功能——这个选项看起来能勾选，但免费计划的资源限制会直接导致它无法生效。如果你的Bot部署在免费App Service计划上，这大概率是问题的核心原因。

• 临时解决办法：如果条件允许，可以升级到基础层（B1），这个层级完全支持Always On，能有效避免服务因闲置被自动回收。

2. 调整应用服务的闲置超时设置 #

即使在支持Always On的层级，也建议检查闲置超时配置：

• 进入Azure门户的App Service资源，找到「配置」>「常规设置」
• 把“闲置超时”从默认的20分钟调至最长的120分钟，减少服务被自动回收的触发频率

3. 设置自动重启的监控警报 #

为了避免手动重启的麻烦，可以用Azure Monitor配置自动化的恢复机制：

• 进入App Service的「监控」>「警报」，创建新的警报规则
• 选择信号为「应用服务计划CPU百分比」或「HTTP 5xx错误率」，当触发阈值时（比如CPU持续为0超过10分钟，或者出现大量5xx错误），添加「重启App Service」的自动化操作

4. 排查Web Chat连接的会话问题 #

有时候不是Bot服务真的停了，而是Web Chat的iframe会话过期导致无法重新连接：

• 检查你的Web Chat嵌入代码，确保用户重新打开聊天时，会重新初始化Bot连接（而非复用旧的会话ID）
• 可以在iframe的加载逻辑里添加心跳检测，定期向Bot发送一条轻量消息，保持连接活跃

5. 查看日志定位具体故障 #

如果以上方法都没解决，建议通过日志找根因：

• 在App Service的「日志」>「应用服务日志」里，启用「文件系统日志」，查看日志文件中是否有进程崩溃、内存不足或未处理的异常信息
• 同时在Bot Framework门户的「分析」>「日志」里，检查通道连接的错误记录，看是否有会话中断的具体触发点

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