使用dsh时，无法打开报错问题

[tianjuanquan-prog]

DSH Desktop 启动失败（desktop welcome: Web authentication failed）—— Cookie 累积导致请求头溢出

摘要

DSH Desktop 每次启动在本机 loopback 上使用随机端口（--port 0），会话 cookie 名称由 authority（即 127.0.0.1:<port>）的 SHA-256 派生，因此每次启动都产生一个名称不同、30 天内不过期的 cookie。由于 cookie 未设置 Domain 属性（host-only，绑定 127.0.0.1，不含端口），浏览器会把所有历史端口留下的 cookie 一并放入发往当前端口的 Cookie 请求头。

累积约 70 条后，Cookie 头接近/超过 Node.js 默认的 max-http-header-size（16384 字节），Host 返回 431 Request Header Fields Too Large（HPE_HEADER_OVERFLOW），connectDesktopWelcome() 收到非 2xx 即抛出 desktop welcome: Web authentication failed，应用启动终止。

代码中没有任何回收过期/无用 cookie 的逻辑，因此这是必然而非偶发的问题，只是触发时间取决于启动频次。

---

环境

项目	值
应用	@deepseek-ai/dsh-desktop 0.2.1-rc.2（FileVersion: 0.2.1-rc.2）
平台	win32 x64
Electron	44.7.0
Node	24.21.0
app.asar 时间	2026-10-17 17:20:50
触发日期	2026-10-25，21:25:31 – 21:34:42，连续失败 10 次

---

复现步骤

1. 正常安装并使用 DSH Desktop。
2. 反复启动/关闭应用（本例累计约 71 次，时间跨度 8.1 天，日均 8.8 次）。
3. 某次启动时应用弹出崩溃对话框：

DeepSeek Harness is unavailable
The application could not start or stopped unexpectedly.
desktop welcome: Web authentication failed

4. 此后每次启动必然失败，重启、重装均无效（只要不清空浏览器 cookie 存储）。

修复方式（已验证）：完全退出应用后，删除 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies 与 Cookies-journal，重启即恢复。恢复后从 0 条重新累积，约 8 天后再次触发。

---

崩溃栈

crash-2026-10-25T13-33-59-326Z-host.log（10 份日志内容一致）：

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (file:///D:/Program%20Files/DeepSeekHarness/resources/app.asar/lib/main.js:8886:31)
    at async Object.start (file:///D:/Program%20Files/DeepSeekHarness/resources/app.asar/lib/main.js:12195:22)
    at async file:///D:/Program%20Files/DeepSeekHarness/resources/app.asar/lib/main.js:7162:5
    at async file:///D:/Program%20Files/DeepSeekHarness/resources/app.asar/lib/main.js:12313:4

对应的 main.js:8882-8886：

async function connectDesktopWelcome(authenticatedUrl, send, cookies = () => Promise.resolve("")) {
  const origin = new URL(authenticatedUrl).origin;
  const authenticated = await send(authenticatedUrl, { credentials: "include" });
  await authenticated.body?.cancel();
  if (!authenticated.ok) throw new Error("desktop welcome: Web authentication failed");

此处 send 为 Electron 的 net.fetch（main.js:12195 传入），即携带 Chromium cookie jar。431 属于 4xx，authenticated.ok === false，直接抛错。

---

根因分析（四处代码）

1. 每次启动使用随机端口

dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js:234-240

args: [
  "--no-open",
  "--host", "127.0.0.1",
  "--port", "0"        // ← 0 = OS 随机分配
],

实测备份中 71 条 cookie 对应 71 个互不相同的端口，一一吻合。

2. cookie 名称绑定 authority（含端口）

dsh/node_modules/@deepseek-ai/dsh-client-connection/lib/index.js:335-337

const COOKIE_PREFIX = "dsh-auth-";
function cookieName(authority) {
  return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
}

端口不同 → 名称不同 → 旧 cookie 永远不会被同名覆盖。

3. cookie 未设 Domain，浏览器跨端口全量发送

index.js:347-350

function sessionCookie(name, value, expiresAt, maxAgeSeconds, secure) {
  const attributes = `${name}=${value}; Max-Age=${String(maxAgeSeconds)}; Path=/; Expires=${new Date(expiresAt).toUTCString()}; HttpOnly; SameSite=Strict`;
  return secure ? `${attributes}; Secure` : `${attributes}`;
}

无 Domain → host-only cookie，绑定 127.0.0.1（不含端口）。Chromium 会把该 host 上、Path=/ 的全部 cookie 放入任何端口的请求。

4. 有效期 30 天，且无任何清理逻辑

index.js:1017

cookieMaxAgeDays: z.natural().min(1).default(30),

在 dsh-client-connection 全包内检索以下 API，命中数全部为 0：

API	命中
clearStorageData	0
cookies.remove	0
removeAll	0
flushStore	0

主进程中存在两处 clearStorageData（main.js:6960、main.js:10242），但均作用于平台账号登录窗口的独立 partition，与本地 Host 的 cookie 无关，不会清理这里。

---

量化数据（实测）

从用户备份的 Cookies（SQLite，53,248 字节）中解出全部 71 条 dsh-auth-* cookie，逐条解析其 payload：

指标	数值
cookie 条数	71
对应不同 authority	71（一一对应）
已过期条数	0（30 天有效期，全部仍在有效期内）
时间跨度	2026-10-17 18:49 → 2026-10-25 21:24（8.1 天）
日均启动	8.8 次
单条 cookie 占名	53 字节
单条 cookie 占值	171 字节
单条在 Cookie 头中总计	53 + 1 + 171 + 2 = 227 字节
71 条合计 Cookie 头	16,117 字节
Node.js 默认 max-http-header-size	16,384 字节
差额	仅剩 267 字节

关键说明（如实标注）：单独 71 条 cookie 为 16,117 字节，尚未超过 16,384。但该预算是整个请求头共享的，还需容纳 Host、User-Agent、Accept、Accept-Encoding、Accept-Language、Referer、Sec-Fetch-*（4 项以上）、sec-ch-ua* 等，实测同类 Chromium 请求这些字段合计约 600–900 字节。因此总请求头稳定超过上限。

阈值估算：16384 ÷ 227 ≈ 72 条（未计其他头部）；扣除其他头部后约 68–70 条。

已验证 Node 行为：以 17,000 字节 Cookie 头请求本地 http.createServer()，服务端 clientError 返回 HPE_HEADER_OVERFLOW，响应 431。

---

为什么现有测试没有覆盖到

packages/client/connection/tests/browser-auth.host.spec.ts 共 11 条用例，覆盖篡改、过期、未来签发、超长有效期、HTTPS/HTTP 区分、密钥轮换等。检索结果：

关键词	命中
multiple	0
accumul	0
431	0
overflow	0
maxHeader	0
old cookie	0

其中第 185 行：

expect(first.isAuthenticated(request('/', '127.0.0.1:3081', { cookie: login.cookie }))).toBe(false)

该断言验证的是服务端：携带 A 端口 cookie 访问 B 端口必须被拒。逻辑正确。

但真实故障发生在服务端之前：请求头在 Node HTTP 解析层即被拒绝，不会进入 isAuthenticated()。纯服务端单元测试无法观测到这一层，因此 11 条用例全绿而线上失败。

---

建议修复方向

1. 固定端口：--port 0 改为固定端口，使 cookie 名稳定、可被同名覆盖（最直接）。
2. cookie 名不绑定端口：cookieName() 去掉 authority 中的端口，或直接使用固定名称 + 内容中校验 authority。
3. 启动时主动清理：启动阶段对本 host 的 dsh-auth-* 执行 cookies.remove，或在 clearStorageData({ storages: ['cookies'] }) 中以 host 为作用域清理。
4. 失败自愈：connectDesktopWelcome 遇 401/431 时，回退到用 launch token 重新换取 cookie 再重试一次，而非直接终止启动。

---

影响面评估

条件	是否必然触发
30 天内启动次数 ≥ 约 70 次	是
日均启动 ≥ 2.3 次（30 天 × 2.3 ≈ 69）	是
日均启动 8.8 次（本例）	约 8 天触发

结论：任何在 30 天内累计启动约 70 次及以上的正常用户都会遇到。这不是个别环境问题——不涉及网络、代理、防火墙、系统时钟或第三方插件（鉴权全程在 127.0.0.1 本地回环完成）。触发时间仅取决于使用频率。

---

附：用户侧自助修复步骤

1. 从系统托盘完全退出 DeepSeek Harness。
2. 删除：
   • %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies
   • %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies-journal
3. 重新启动，需重新登录账户一次。

注意：不要删除同级 Local Storage 目录——其中含插件开关与配置状态。删除后会导致所有第三方插件被重置为关闭。

[PerryLink]

你的分析对，我只补一条和修法有关的。

先说结论一致：cookie 名含随机端口（browser-auth.ts:79-84 + :116-118）、只写不删（:138）、Host 每次 --port 0（apps/desktop-host/src/index.ts:36），所以条数只增不减，攒到 16 KiB 请求头就 431 —— 你说的"必然而非偶发"成立。master ce7073d5 上这几处仍然一样，browser-auth.ts 从 rc.2 到现在是同一个 blob。

补的是另一面："去掉端口"不是安全的修法。packages/client/connection/README.md:43 写明 cookie 的名字和签名 payload 都绑 hostname + port，理由是同一个 Harness home 要能同时跑多个 Web 端口而不互相覆盖。名字里去掉端口之后，浏览器里同名 cookie 只能留一条，两个端口会互相顶掉。

所以修复应该是"写入时清理同族旧名"（签发新 cookie 后把其它 dsh-auth-* 置为过期），端口保留。这样条数压在 1 条附近，多端口能力也不动。

另外 cookieMaxAgeDays 调小只是压缩累积窗口：每天启动两次、保留 7 天，也还是 14 条。它不改变"只增不删"，所以只能延后、不能避免。