问题概述
线上遇到一个偶发问题：webchat2api 容器仍然处于运行状态，轻量健康接口也正常，但首页和前端静态页面无法打开，直到重启容器后才恢复。
这看起来不像是 Caddy、证书、域名或容器退出导致的问题，更像是应用本身进入了一种“部分存活但前端静态返回链卡死”的状态。
现象表现
问题发生时：
- 容器仍在运行
GET /health 返回 200 {"status":"ok"}GET /version 返回 200GET / 超时GET /index.html 也超时- 容器内
/app/web_dist/index.html 文件实际存在
- 重启容器后，首页立即恢复正常
重启后验证：
/health => 200/version => 200/ => 200- 首页 HTML 正常返回
为什么判断更像项目层面的问题
排查时已确认：
- 反向代理 Caddy 配置正常
- HTTPS 证书正常
- 容器没有退出
- 容器没有 OOMKilled
- 静态文件没有丢失
- API 轻接口仍然能正常响应
也就是说，不是整站都挂了，而是应用进入了这样一种异常状态：
- JSON 健康接口还能回
- 但前端首页和静态文件返回链卡住
这更像是项目内部的应用层问题，而不是纯部署问题。
运行环境
- 镜像：
ghcr.io/zqbxdev/webchat2api:latest
GET /version 返回：0.0.11- 启动方式：
uv run python main.pyuvicorn- entrypoint 中还会启动 Browser Bridge
- 反向代理：Caddy
- 容器端口：
83
- 公网域名：
webchat2api.ai-api.20021108.xyz
相关代码位置
首页和静态前端回退逻辑看起来主要在这里：
api/app.pyapi/support.py
当前逻辑大致是：
/health 直接返回 JSON/{full_path:path} 使用 resolve_web_asset(...)- 找到文件后通过
FileResponse(...) 返回
从现象看，问题更像出在这条静态页面返回链，而不是整体路由不可用。
额外观察
排查过程中还观察到：
/_next/_index.txt 可以快速返回 404/ 和 /index.html 会持续超时- 容器内
/app/web_dist/index.html 文件存在且可读
- 容器资源没有明显异常
- 重启后服务立即恢复
这说明问题并不是静态文件缺失，而更像是运行时某种卡死/阻塞状态。
期望行为
如果服务还能正常返回 {"status":"ok"}，那么首页静态页面也应该保持可访问。
至少不应该出现这种状态：
怀疑方向
目前比较怀疑这些方向之一：
- FastAPI 静态页面回退路由在某些情况下卡住
FileResponse(...) 返回链偶发阻塞- 单进程运行下，某些同步任务/线程池占用影响了静态页面响应
- Browser Bridge 或后台 watcher 对主服务造成副作用
- 应用进入“部分可用但静态页面不可用”的异常状态
影响
这个问题会导致：
- 前端页面、后台界面看起来像“站点挂了”
- 但简单健康检查仍然显示正常
- 运维层面不容易第一时间发现真实故障
临时解决办法
当前临时处理方式是：
重启后可立即恢复，但这只是临时 workaround，并不能解决根因。
问题概述
线上遇到一个偶发问题：
webchat2api容器仍然处于运行状态，轻量健康接口也正常，但首页和前端静态页面无法打开，直到重启容器后才恢复。这看起来不像是 Caddy、证书、域名或容器退出导致的问题，更像是应用本身进入了一种“部分存活但前端静态返回链卡死”的状态。
现象表现
问题发生时：
GET /health返回200 {"status":"ok"}GET /version返回200GET /超时GET /index.html也超时/app/web_dist/index.html文件实际存在重启后验证：
/health=> 200/version=> 200/=> 200为什么判断更像项目层面的问题
排查时已确认：
也就是说，不是整站都挂了，而是应用进入了这样一种异常状态：
这更像是项目内部的应用层问题，而不是纯部署问题。
运行环境
ghcr.io/zqbxdev/webchat2api:latestGET /version返回：0.0.11uv run python main.pyuvicorn83webchat2api.ai-api.20021108.xyz相关代码位置
首页和静态前端回退逻辑看起来主要在这里：
api/app.pyapi/support.py当前逻辑大致是：
/health直接返回 JSON/{full_path:path}使用resolve_web_asset(...)FileResponse(...)返回从现象看，问题更像出在这条静态页面返回链，而不是整体路由不可用。
额外观察
排查过程中还观察到：
/_next/_index.txt可以快速返回 404/和/index.html会持续超时/app/web_dist/index.html文件存在且可读这说明问题并不是静态文件缺失，而更像是运行时某种卡死/阻塞状态。
期望行为
如果服务还能正常返回
{"status":"ok"}，那么首页静态页面也应该保持可访问。至少不应该出现这种状态：
怀疑方向
目前比较怀疑这些方向之一：
FileResponse(...)返回链偶发阻塞影响
这个问题会导致：
临时解决办法
当前临时处理方式是：
webchat2api容器重启后可立即恢复，但这只是临时 workaround，并不能解决根因。