fix: proxy prod api traffic through web entry

memory/2026-05-16.md

@@ -47,3 +47,28 @@
 
 - 风险与关注点：
   - 在线 `api` 仍配置 `REFRESH_COOKIE_SECURE=true`；若继续通过纯 HTTP IP 访问，刷新 token cookie 可能不会被浏览器持久化。短期内不影响本次“登录预检被拦截”的修复，但后续若要稳定保留登录态，建议切到 HTTPS 域名访问，或在明确接受风险的前提下改为 `false`。
+
+## Work Log - 认证刷新超时改为同源反代（2026-05-16）
+
+- 背景：
+  - 浏览器请求 `POST http://223.109.142.84:8000/api/v1/auth/refresh` 超时，控制台报 `Failed to fetch`。
+  - 容器内访问 `http://223.109.142.84:3000/fl` 正常返回 `200`，但访问 `http://223.109.142.84:8000/health` 仍超时；同时 `http://127.0.0.1:8000/health` 在 `api` 容器内正常返回 `200`。
+  - 说明故障不在 `auth/refresh` 业务逻辑，而在“浏览器直连公网 `:8000`”这条访问链路。
+
+- 本次改动：
+  - `web/src/lib/api.ts`
+    - 浏览器端在发现构建注入的 API 基址仍为 loopback 且当前页面不在 loopback 主机时，不再改写到 `当前主机:8000`，而是直接回落到 `window.location.origin`。
+  - `deploy/pro-deploy/compose.yml`
+    - 生产部署新增 `proxy`（nginx）服务，占用宿主机 `3000`。
+    - `web` 改为仅在 Compose 内网暴露 `3000`，不再直接占用宿主机端口。
+  - `deploy/pro-deploy/nginx.conf`
+    - `/api/*` 反代到 `api:8000`。
+    - `/api/v1/ws` 使用 Upgrade 头反代到 `api:8000`。
+    - 其余页面流量反代到 `web:3000`。
+
+- 验证：
+  - 本地 `nft list ruleset` 显示 Docker 已为宿主机 `3000/8000` 建立映射，但容器内访问公网 `:8000` 超时、访问公网 `:3000` 正常，支持“对外入口应统一走 `3000` 反代”的判断。
+  - 待同步部署目录并重建 `web/proxy` 容器后，再做浏览器与 `curl` 复测。
+
+- 风险与关注点：
+  - 当前在线 `REFRESH_COOKIE_SECURE=true`；若继续通过纯 HTTP IP 访问，浏览器可能仍不会持久化 refresh cookie。若部署后出现“登录后刷新即掉线”，需将当前环境的 `REFRESH_COOKIE_SECURE` 调整为 `false` 或切到 HTTPS 入口。