Azure上.NET 4.8版ASP.NET应用闲置20分钟后触发403错误求助

部署在Azure上的.NET 4.8 ASP.NET应用，闲置20分钟后会触发403访问被禁止的问题，目前只有通过修改web.config里<system.web>节点下<compilation>标签的debug="true"属性（添加或删除均可），才能让应用恢复正常访问。

已尝试但无效的操作 #

• 确认未配置应用级别的访问限制；
• 受服务计划限制，无法开启Always On配置；
• 在网络访问限制中设置了允许0.0.0.0/0（优先级300）；
• 将Session state timeout设为6000。

可尝试的排查与解决方向 #

1. 针对应用池回收的处理 #

Azure App Service默认的应用池闲置超时就是20分钟，和你的问题时间点完全吻合。虽然开不了Always On，但可以试试这些：

• 登录Azure门户，进入目标App Service的配置 > 常规设置，确认「闲置超时」是否为20分钟；
• 若无法修改超时时间，可借助Azure Functions编写简单定时任务，每隔15分钟向应用首页发起一次GET请求，强制维持应用池活跃状态，避免被回收。

2. 排查web.config的权限与模块配置 #

修改debug属性会触发应用重启，说明问题和应用启动状态绑定，重点检查以下内容：

• 查看<system.webServer>下的<modules>节点，确认是否存在自定义模块在应用闲置后出现权限异常；
• 检查<authorization>节点的配置，是否有依赖会话或缓存的动态权限规则，应用池回收后缓存失效导致403；
• 确认应用依赖的Azure临时目录权限，闲置回收后该目录权限可能重置，若应用依赖此处的读写权限，易引发异常。

3. 深挖Azure诊断日志 #

开启详细错误日志和失败请求跟踪，抓取具体错误原因：

• 进入App Service的监测 > 日志流，实时查看403错误发生时的日志细节，重点关注请求被哪个模块拦截、是否有具体错误代码；
• 下载失败请求跟踪日志，逐步分析请求处理流程，定位被拒绝的具体环节。

4. 检查依赖服务的连接状态 #

应用闲置后，数据库、缓存等依赖服务的连接可能断开，若应用未妥善处理此类异常，可能被IIS转换为403响应：

• 排查应用的异常处理逻辑，确认是否将数据库连接失败等错误转换为了403响应；
• 确认依赖服务的超时配置，比如SQL Server的连接超时是否合理，避免闲置后连接失效导致权限校验出错。

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