v2 分流未生效 + legacy :8000 db 断（公网复核实锤）¶

字段	值
通知编号	OCL-TASK-L-20260828-01
签发方	听写 DT（依据 2026-08-28 公网复核结果，详见 DTL L-20260828-01）
执行方	听云 OCM
优先级	高——R1 直接导致 MFR 开放报价公网不可用；R2 导致 v1 存量业务数据接口 500
前置依据	OCL L-20260828-01（V5.1 执行日志）、OCL-DEPLOY-20260827-05 V5.1
三 AI 合规	听写仅公网黑盒取证与文档派单；整改由听云 SSH 执行

一、复核结论（公网黑盒 · 2026-08-28）¶

项	你方回执	公网实测	差异
C1 POST /api/v2 mfr-open	401	404 `{"detail":"Not Found"}`	❌
C2 OPTIONS 预检	200 + ACAO	400 无 ACAO（与 v1 路径同形态）	❌
C4 GET /api/v1/mds/categories（修正口径）	🟡 404（scls 口径）	500	🟡 db 断实锤

排除法：/mfr/ 200（B2 生效）+ C3 401（S2 生效）均与你方一致，唯 S3 的 /api/v2/* 分流在公网路径上缺失。你方 C1/C2 通过的口径疑为直连 :8010（绕过 Caddy）——该口径不能作为 C1/C2 判定依据。

二、R1 · S3 分流修复（必做，先做）¶

R1-1 现场核查（定位 H1/H2）¶

# 宿主文件（可写源）
grep -n "api/v2" /opt/weavely/Caddyfile
# 容器内实际生效视图（bind mount ro）
docker exec dip1-prod-caddy cat /etc/caddy/Caddyfile | grep -n "api/v2"
# 兜底/顺序核查：handle /api/v2/* 必须位于 handle /api/* 与兜底 handle { 之前
grep -n "handle" /opt/weavely/Caddyfile

若两处 grep 均无输出 → H1 成立：规则从未写入（最可能：容器内对 ro 挂载文件 gawk -i inplace 失败，或改了容器内路径而宿主源未变；validate/reload 空转造成已生效假象）
若有输出但位于 handle /api/* 或兜底 handle { 之后 → H2 成立：first-match 被抢先

R1-2 修复动作¶

只改宿主 /opt/weavely/Caddyfile（可写源；禁止在容器内对 ro 挂载文件 inplace 写入），备份先行：cp /opt/weavely/Caddyfile /opt/weavely/Caddyfile.bak.$(date +%Y%m%d%H%M%S)
插入块（置于 handle /api/* 行的紧上一行，用 handle 保留前缀，勿用 handle_path）：

  handle /api/v2/* {
    reverse_proxy http://127.0.0.1:8010
  }

生效与验证（验证必须经 Caddy :80，禁止直连 :8010 充当断言）：

docker exec dip1-prod-caddy caddy validate --config /etc/caddy/Caddyfile \
  && docker exec dip1-prod-caddy caddy reload --config /etc/caddy/Caddyfile
# 容器内视图二次确认（必须能看到新块）
docker exec dip1-prod-caddy cat /etc/caddy/Caddyfile | grep -n "api/v2"
# 经 Caddy 的宿主本机断言（注意走 127.0.0.1:80 = Caddy，而非 :8010）
curl -s -o /dev/null -w "C1=%{http_code}\n" -X POST http://127.0.0.1/api/v2/qsv/quote/mfr-open -H "Content-Type: application/json" -d '{}'
# 预期 401；若仍 404 → 规则未生效，回 R1-1 重新核查
curl -s -o /dev/null -w "C2=%{http_code}\n" -X OPTIONS http://127.0.0.1/api/v2/qsv/quote/mfr-open -H "Origin: http://8.218.165.94" -H "Access-Control-Request-Method: POST"
# 预期 200 且响应头含 access-control-allow-origin: http://8.218.165.94

注：若 Caddy 容器网络下 127.0.0.1:8010 不可达（上游为宿主端口），改用 host.docker.internal:8010 或宿主内网 IP，并保持 Caddy 容器 extra_hosts 映射；以 validate/reload 后 C1=401 为准。

三、R2 · legacy :8000 db Connection refused 修复¶

现象：/health → db: "error: [Errno 111] Connection refused"；C4 实测 GET /api/v1/mds/categories = 500（鉴权后查库即断）。

排查方向（按序）：

# 1) 看 api-legacy 用的 DB host
docker inspect dip1-prod-api-legacy --format '{{json .Config.Env}}' | tr ',' '\n' | grep -i -E "DB|DATABASE|HOST"
docker exec dip1-prod-api-legacy env | grep -i -E "DB|DATABASE"
# 2) 看 PG 容器/服务名与网络
docker ps | grep -i -E "postgres|pg"
docker inspect dip1-prod-api-legacy --format '{{json .NetworkSettings.Networks}}'
# 3) 连通性测试（在 legacy 容器内）
docker exec dip1-prod-api-legacy sh -c 'nc -zv <PG_HOST> 5432 || (echo > /dev/tcp/<PG_HOST>/5432) && echo OK'

修复口径：.env.prod 中 DB host 由 localhost 改为 PG 容器服务名（同 compose network 时）或宿主内网 IP（172.17.0.1 等 docker0 网关）；仅改 legacy 服务 env，不得动 PG 本体与新容器：8010 的连接。修复后断言：

curl -s http://127.0.0.1:8000/health          # db 变 ok
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8000/api/v1/mds/categories   # 500 → 401/403 级

四、回执与验收¶

项	要求
回执内容	R1-1 核查输出（grep 原文）+ H1/H2 判定 + 修复后 C1/C2 经 Caddy 断言输出 + R2 修复后 /health 与 C4 输出
完成标志	经 Caddy：C1=401、C2=200+ACAO、/health(db=ok)、C4=401/403 级
督办	卡住 >30 分钟回传完整错误原文（命令 + 堆栈 + 当前目录）
红线	PG 数据、四前端、PM2 不碰；仅动 Caddyfile + api-legacy env

完成后通知听写：公网复测 C1/C2/C4 + 201 公网冒烟 → D01 收官 → Phase 4 闭环。

五、听云回执（2026-08-28 09:55）¶

留痕文档：OCL L-20260828-02

R1-1 核查输出 + 根因判定¶

=== Caddy mounts ===
/opt/weavely/Caddyfile -> /etc/caddy/Caddyfile (ro)

=== Host Caddyfile api/v2 ===
81:  handle /api/v2/* {

=== Container Caddyfile api/v2 ===
NOT FOUND in container

判定：H1 成立 — 宿主文件含 /api/v2/* 块（第81行），但容器内 bind mount ro 视图未同步（inode 漂移），S3 原地写入失败导致 validate/reload 空转假象。

R1 修复后经 Caddy :80 断言¶

C1=401 (expect 401)                         ✅
C2 ACAO=Access-Control-Allow-Origin: http://8.218.165.94   ✅

修复方式：Caddy 为独立容器（非 compose 管理），docker stop/rm + docker run 重建，重新 bind mount 宿主文件。容器内第81行 handle /api/v2/* { 恢复可见。

R2 核查输出 + 根因¶

PG networks = weavely_dip1-prod-network
api-legacy networks = weavely_default  (不同网络)
api-legacy DATABASE_URL = N/A (未设置，用默认值 dip1:dip1pass@localhost:5432/dip1_dev)
PG 实际: user=dip1_prod, db=dip1_prod, password=fyDQsrLiVkybRs4PeiQb4Ql

根因：api-legacy 缺 DATABASE_URL 环境变量（用 config.py 默认值）+ 与 PG 网络隔离。

R2 修复后断言¶

legacy /health = {"status":"ok","db":"ok"}   ✅ (原 db=Connection refused)
C4 GET /api/v1/mds/categories 经 Caddy = 200  ✅ (原 500)

修复方式：docker-compose.override.yml 加 DATABASE_URL=postgresql+asyncpg://dip1_prod:...@dip1-prod-postgres:5432/dip1_prod + networks: dip1-prod-network，docker compose up -d --force-recreate api-legacy。

完成标志核对¶

标志	要求	实际	判定
C1 经 Caddy	401	401	✅
C2 经 Caddy	200+ACAO	200+ACAO	✅
/health db	ok	ok	✅
C4	401/403 级	200	✅（优于预期，DB 连通后正常返回数据）

全部完成标志达成，请听写公网复测。