web: frontend data layer never starts when served under a non-loopback origin (LAN IP / domain)

[lusir01]

问题描述

DeepSeek Harness Web GUI 通过反向代理以非 localhost 地址（如局域网 IP http://192.168.31.234:4096 或公网域名）访问时，前端数据层静默不启动：

• 侧边栏显示「暂无会话」，卡在「选择工作区」引导界面；
• host.describe 从未发出（connection.start() 就绪握手缺失）；
• /api/events.mux、/api/events.host WebSocket 从未建立；
• session.list / workspace.list 等业务 API 全部未发出；
• 无任何 console 错误、主线程空闲（异步等待挂起，非死循环）；
• cordis 插件 client.js 全部加载完成，dynamicCordisRunner/inventory 正常返回，但激活在 runtime 服务（connection.start）之前中止。

以 http://localhost:4096 或 http://127.0.0.1:4096（loopback）访问同一代理、同一 DSH 服务、同一浏览器时完全正常：自动选择工作区、会话列表加载、会话恢复。

复现步骤

1. 让 DSH web（dsh web，默认 127.0.0.1:3080）通过任意反向代理暴露为：
   • 正常：http://127.0.0.1:4096/
   • 异常：http://<本机局域网IP>:4096/（如 http://192.168.31.234:4096/）
2. 用 Chrome 打开异常地址（全新 profile 亦可复现），打开 DevTools → Network：
   • 观察：插件 JS 全部加载，但 host.describe 与 events.mux/events.host WebSocket 不出现；
   • 页面停留在「选择工作区 / 暂无会话」。
3. 对比打开正常地址：host.describe 与两条 WebSocket 正常建立，应用完整启动。

期望行为

• 非 localhost 地址访问时，前端应完整启动（与 loopback 一致）；若为有意限制，应给出明确降级提示，而非静默空转。
• DSH CLI 已提供 --trusted-host（声明远程 authority），浏览器端应相应放行该 authority 的前端数据层。

排查补充（供参考）

• 代理侧已改写请求 Host 与 Origin 至 loopback 目标，/api Host fence、特权方法（settings.describe 等）、SSE（/plugins/events）、WebSocket 全部手动验证可达且通过；
• 差异仅在浏览器 location.hostname（loopback vs 非 loopback）；
• 尝试在页面早期覆盖 location.hostname 无效（属性不可重定义）；
• connection.isLoopback（isLoopbackHostname(location.hostname)）在非 loopback 下为 false，其使用方（settings 存 memory、文件打开、deliverables）均为功能降级，未见阻止启动的分支；
• 建议在 dsh-cordis-client-runner 的激活流程（dynamicCordisRunner/inventory 之后）增加错误日志，定位非 loopback 下中断的异步步骤。

环境

• DSH 版本：dsh web（rev 见页面 __DSH_BOOT__）
• 浏览器：Chrome 151（主实例与独立 profile 均复现）
• 系统：macOS

---

目的是通过代理服务支持手机访问DSH

[lusir01]

补充证据：WebSocket 层（已深入验证）

在代理层做了底层验证，确认网络/代理/DSH 服务端全部正常，问题定位在前端 boot 时的 WebSocket 连接：

验证结果

测试	结果
原始 TCP 模拟浏览器 WS 握手（带 Origin/Cookie/Extensions，经代理）	✅ 返回 HTTP/1.1 101，Sec-WebSocket-Accept 正确
Node WebSocket 客户端（经代理）	✅ OPEN
页面加载后手动 new WebSocket('/api/events.mux')（同页面）	✅ OPEN
前端 boot 自动创建的 WS（connection.start → events.mux/host）	❌ WebSocket is closed before the connection is established.，无握手请求发出（CDP 无 webSocketHandshakeResponseReceived），connection lost, retry #1..#7 重试全部失败

关键现象

• 同一页面里手动 WS 成功、前端 boot WS 失败——排除网络/代理/认证（/api 路由日志显示请求到达且 authed=true）；
• 代理已尝试：精简握手头、代理自回 101（WS 中继模式）——均无效；
• CDP Network.webSocketCreated 显示 URL 正确（ws://<LAN-IP>:4096/api/events.mux），但握手请求从未发出——浏览器层在 CONNECTING 状态关闭了连接；
• 疑似与前端 boot 时序相关（runPluginBoot 中 connection.start 在页面加载早期触发 WS）。

建议排查点（前端）

1. web-api-client.ts 的 readWebSocket：new WebSocket(url) 后是否有路径在握手完成前 close()（如 signal.abort 处理）；
2. connection.ts 的 pumpStream：为何迭代在握手前结束（触发 settle → abort），且重试持续失败；
3. 页面加载早期（document.readyState 非 complete）创建 WS 是否有浏览器层差异。

完整证据链与复现步骤见 dsh-remote 仓库 docs/troubleshooting/2026-08-17-non-loopback-frontend.md。

[lusir01]

已找到解决方案（供参考）

问题已通过网络层方案解决，前端无需改动：

1. 让局域网 IP 进入 DSH 的 trustedHosts（--trusted-host 或 profile patch 的 web-runtime.trustedHosts）——此前经代理时 DSH 只信任 loopback，前端在非 loopback origin 下 boot 挂起；
2. 让 DSH 监听所有网卡（cordis.patch.yml 覆盖 webserver.host: 0.0.0.0）——社区插件 dsh-LAN 正是这么做的（另附口令登录门 + 移动端适配）；
3. 浏览器直连 http://<LAN-IP>:3080 后：host.describe / session.list / 全部 15 个业务 API 正常、WebSocket 事件流建立、多设备会话实时同步（单服务进程，服务端共享）。

供排查参考：非 loopback 下前端 boot 的 WebSocket（connection.start）在握手前被关闭（无握手请求发出、connection lost 重试循环），而同一页面手动 new WebSocket 成功——疑似与 boot 时序相关；trustedHosts 白名单化后即恢复正常，说明前端 origin 信任判定参与了该路径。

完整方案与验证脚本见 dsh-remote 仓库（docs/troubleshooting/、scripts/multi-device.mjs）。

[lusir01]

补充：DSH 开发版（源码 checkout）insert 插件 inject 丢失

在源码 checkout（node --import tsx/esm apps/cli/src/bin.ts web）下，通过 profile cordis.patch.yml 的 - insert: 安装的插件（社区插件 dsh-LAN、以及自研插件均复现）apply 时 ctx.webServer 报 cannot get property "webServer" without inject：

• loader.unwrapExports 输入/输出正常（模块 keys 含 apply/inject/name，inject: ["webServer"] 存在）；
• registry.plugin 的 Inject.resolve(plugin.inject) 环节 inject 丢失（fiber.inject 为空）；
• 栈：include (cordis:include) → dshr-lan；
• 现象与模块格式无关（ESM named export / CJS module.exports 均复现）。

环境：macOS、Node 22.22.1、tsx 运行源码。dsh-LAN 作者环境（发布版 DSH）正常——疑为 checkout 开发版 cordis/loader 的差异或 bug。请确认 insert 插件的 inject 传递路径。

[HenryZ838978]

Reproduced end-to-end on rc.6. Every observation in the OP checks out.

Why (mechanism, not just symptom). The static frontend loads unconditionally (GET / returns 200 under any Host). Every data-layer call then hits api-request-trust.ts, which compares new URL(origin).host === hostUrl.host — a literal string match with no loopback-alias equivalence. From a non-loopback hostname: GET / → 200, /api/events.mux → 403. The frontend has already loaded, so it tries to start; the 403 kills the connection layer before an application-level error can surface. Hence the silent "Select a workspace" hang with no console output. The fence is doing its job correctly — the bug is the failure mode, not the fence.

Fix today. Reach the server at 127.0.0.1 / localhost / [::1]. To detect it: pip install deepseek-harness-cli && dsh doctor --node --only P3-serve --url http://your-dsh-web:3080 — sends natural + evil-Origin requests, reports the fence outcome.

Fix upstream (small). Either (a) inject a warning banner into the served HTML when the request Host is non-loopback, or (b) accept loopback-alias equivalence at the Origin check. (a) is safer.