dsh web 打开后所有 /api/* 请求返回 403（transport failure for /api/host.describe / host.pickDirectory: HTTP 403），curl 直连却是 200

[WAKECai]

环境

• macOS（Darwin 25.x），Node.js v24.18.0
• 通过 npx @deepseek-ai/dsh web 启动，服务监听 http://127.0.0.1:3080
• 系统开启了代理（HTTP/SOCKS 127.0.0.1:7897），ExceptionsList 已包含 127.0.0.1、localhost
• 存在 TUN 模式虚拟网卡（utun0，地址 198.18.0.1，应为 Clash/Surge 类工具创建）
• 浏览器安装了 Immersive Translate 扩展（控制台日志中出现其报错）

问题现象
Web UI 能打开，但所有 /api 调用全部 403：

transport failure for /api/host.pickDirectory: HTTP 403
host.describe: Failed to load resource: the server responded with a status of 403 (Forbidden)
WebSocket connection to 'ws://.../api/events.host' failed: WebSocket is closed before the connection is established.
/api/settings.describe → 403
/api/credentials.describe → 403
/api/agentPreset.list → 403
/api/dynamicCordisRunner/inventory → 403

前端随后进入 [web-runtime] connection lost, retry #N 无限重试。

关键证据（同一台机器、同一个正在运行的服务）
我用 curl 对 127.0.0.1:3080 做对照测试：

场景	Host	Origin	结果
正常 loopback 直连	127.0.0.1:3080	无	200
模拟跨域/代理改写	127.0.0.1:3080	http://evil.example.com	403
模拟页面用 localhost 打开、请求发到 127.0.0.1	127.0.0.1:3080	http://localhost:3080	403
浏览器标记跨站	127.0.0.1:3080	—（sec-fetch-site: cross-site）	403

说明：服务端的信任围栏正常在起作用——它要求 Host 与 Origin 严格一致。curl 直连 200，浏览器却全部 403，说明浏览器发出的请求在到达服务端前，Host/Origin 或 sec-fetch-site 被某层改写了。

已尝试，问题依旧

1. 在代理软件中把 127.0.0.1、localhost 加入直连/绕过列表 —— 无效
2. 关闭 TUN 模式、完全退出代理后重启 dsh web —— 仍然 403（这一步最令我困惑）

怀疑方向

• 浏览器扩展（如 Immersive Translate）改写请求头？
• 系统代理 ExceptionsList 只绕过了 macOS 层，但浏览器/某软件仍把 loopback 请求交给代理，TUN 劫持后 Host/Origin 不一致？
• 我注意到一个与测试 3 吻合的假说：页面若以 http://localhost:3080 打开而请求打向 127.0.0.1:3080，Origin≠Host 即 403。但前端 resolveBase() 用的是 location.origin，理论上应同源……请帮忙确认是否存在此类拼接不一致。

期望

1. 官方确认 403 的全部可能触发路径（不只是 pickDirectory，而是所有 /api 请求）；
2. 给出在开启系统代理/TUN 的情况下，如何让 dsh web 正常工作的标准配置；
3. 如需更多日志/抓包数据，请告知抓取方法。

[DRAG0NM]

感谢这么完整的对照实验。我在 0.1.0-rc.6 上核对了源码并在本机复测了同一矩阵，结论与你一致：服务端信任围栏在按设计工作，你的浏览器请求在到达服务端之前被某层改写了 Host/Origin/sec-fetch-site。下面是权威的触发路径清单与排障顺序。

403 的全部触发路径（源码 + 实测）

围栏位于 @deepseek-ai/dsh-client-connection 的 isTrustedApiRequest，四条拒绝条件，任一命中即 403：

1. Host 头缺失或不可解析
2. Host 不是 loopback（127.0.0.0/8、::1、localhost）且不在 trustedHosts 配置内（DNS-rebinding 防御）
3. sec-fetch-site: cross-site（浏览器把请求标为跨站）
4. Origin 头存在但 new URL(origin).host !== Host —— 包括字面量 Origin: null（解析失败同样拒绝）

应用在三层：/api 前缀路由、每个 RPC 通道路由、以及 WebSocket upgrade（协商前直接 403，所以你看到 "WebSocket is closed before the connection is established"）。另外 agentPreset.* / host.pickDirectory / host.openPath / settings.* / credentials.* / llm.discoverModels 是特权方法，用空信任列表再校验一次，即使配置了 trustedHosts 也永远钉死在 loopback + 同源。

本机实测（POST /api/host.describe，127.0.0.1:3080）：

场景	结果
无 Origin	200
Origin: http://evil.example.com	403
Origin: http://localhost:3080（Host=127.0.0.1:3080）	403
Origin: http://127.0.0.1:3080（匹配）	200
Origin: null（字面量）	403
sec-fetch-site: cross-site	403
Host: evil.example.com	403
Host: localhost:3080	200

关于你 localhost vs 127.0.0.1 的假说

你怀疑的触发条件确实成立（上表第 3 行）。但前端 resolveBase() 取的是 location.origin，请求与页面构造性同源——只要页面 URL 是 http://127.0.0.1:3080，所有请求的 Host/Origin 就都是 127.0.0.1:3080，前端自身不可能产生这种不匹配。因此你的 403 一定来自浏览器与页面之间的一层改写。按下面的顺序排查，通常第一步就能定位：

排障顺序

1. 无扩展窗口重试（chrome 的隐身窗口通常仍加载已启用的扩展，最好用全新 profile 或 --disable-extensions）。你日志里出现了 Immersive Translate 的报错——这类翻译扩展会拦截并改写 fetch，是头号嫌疑。
2. URL 一致性：只用 dsh 打印的确切地址 http://127.0.0.1:3080 打开页面；旧标签页若是以 localhost 打开的，其 origin 会残留在缓存/Service Worker 里。
3. curl 自证服务器侧正常（复刻浏览器的同源头应为 200）：

   curl -X POST http://127.0.0.1:3080/api/host.describe \
     -H "content-type: application/json" -H "Origin: http://127.0.0.1:3080" -d '{}'

4. 代理侧：Clash/Surge 对 loopback 默认直连；确认「系统代理」没有把 127.0.0.1 交给代理、TUN 规则放行 loopback。你"关闭代理后仍 403"的现象与"浏览器请求仍被改写"（第 1、2 步未排除）一致，先排第 1 步再回头验证。
5. 若将来需要 LAN 内访问：配置 trustedHosts（authority 形式，如 harness.internal:3080），但记住特权方法仍然只接受 loopback + 同源。

一个小建议给项目方

403 的响应体目前只有裸的 forbidden，没有任何诊断信息——用户不知道是哪一条条件失败、收到的头是什么。如果 403 时能附上触发的条件名（bad-host / cross-site / origin-mismatch）或至少在服务端日志记录收到的 Host/Origin/sec-fetch-site，这类环境问题就能自助定位，不必逐案排查。

[sailorhero]

逐个禁止插件，折腾下，403就消失了

[RuixiangLiu01]

我也遇到了，改成localhost:3080就好了，无语。。。

[valsun2016]

同问题，重置 chrome 也没用，换成 Microsoft Edge ok了.

[siemensyf]

无痕模式和localhost:3080两种方式试了ok，不知道什么配置导致的

[Cocowwy]

确实，切成 localhost 就可以了

[Tiget-wa]

我的破案了，是ollama的Page Assist这个插件，禁用了就好了

[RaymentLiang]

这个浏览器插件会注入和改写收发地址，之前测试一个服务报错排查了半天

[xiaoxlm]

牛逼！还真是！

[WAKECai]

thanks