桌面端反复重启后必定启动失败：dsh-auth cookie 随随机端口无限堆积，撑爆 16KB 请求头上限导致 431

[ziyouzhiyi666888]

---

环境

• DSH Desktop 0.2.1-rc.5（0.2.1-rc.3 同样存在）
• Windows 11 x64 / Electron 44.7.0 / Node 24.21.0
• 崩溃日志：%APPDATA%@deepseek-ai\dsh-desktop\logs\crash-*.log

---

摘要

桌面端每次启动都会写入一个新的 dsh-auth-<44位哈希> 会话 cookie。
哈希值包含当次启动的随机端口，而 cookie 按域名（127.0.0.1）存储、
不区分端口，因此旧 cookie 永远不会被同名覆盖，只会无限累积。

累积到约 70 条时，Cookie 请求头超过 Node 默认的 max-http-header-size
（16384 字节），Host 返回 431，桌面端将其判为认证失败并中止启动。

---

现象

启动即弹窗 "The application could not start or stopped unexpectedly."，详情为：

Error: desktop welcome: Web authentication failed
at connectDesktopWelcome (.../app.asar/lib/main.js)
at async Object.start (.../app.asar/lib/main.js)

日志中 phase: startup。

弹窗建议"重装或禁用第三方插件"，这两条都是死路，与插件无关。

---

复现步骤

1. 正常使用桌面端，反复启动/退出约 70 次（正常使用约 10～14 天）
2. 再次启动，必现上述错误
3. 关闭应用，删除 %APPDATA%@deepseek-ai\dsh-desktop\Network\Cookies
4. 重新启动，恢复正常

---

实测证据

从 cookie 库 Network/Cookies 中统计，故障时 127.0.0.1 下共有
71 条 dsh-auth-* cookie，无其他任何 cookie。

单条 cookie 形态（实测 Set-Cookie）：

dsh-auth-xve1cdvif713tCh-zvXXZ2XqUnAtUVDatWsduYXhYok=v1.eyJ2ZXJzaW9uIjoxLCJhdXRob3JpdHkiOiIxMjcuMC4wLjE6NDk0OTQifQ.rnymiz...
Max-Age=2592000; Path=/; HttpOnly; SameSite=Strict

• name 52 字符、value 173 字符，单条约 228 字节
• value 解码后含 "authority":"127.0.0.1:49494"，确认哈希与端口绑定
• 两次不同端口启动（49448 / 49494）产生两个不同的 cookie 名

针对真实 Host 扫描条数临界点（仅构造 Cookie 头，其余请求头最小化）：

Cookie 条数 Cookie 头字节 响应

---

71 16,194 200
72 16,422 431

实际请求还会带上 Host、User-Agent、Accept、Sec-Fetch-* 等约 300 字节，
因此真实阈值落在 71 条，与用户实际故障点完全吻合。

---

根因分析

app.asar/lib/main.js 中的启动流程：

const ready = await host.start();
hostCookie = await authenticateWebHost(ready.url); // ① 通过
hostUrl = ready.url;
welcomeBackend = await connectDesktopWelcome(
ready.url, (input, init) => net.fetch(input, init), ...
); // ② 失败

① authenticateWebHost() 使用 Node 全局 fetch，请求不带任何 cookie，
因此能正常拿到 303 + Set-Cookie，看起来一切正常。

② connectDesktopWelcome() 使用 Chromium 的 net.fetch 且 credentials: "include"，
会把该域下全部 71 条 cookie 一并发出，请求头超限 → Host 返回 431：

const authenticated = await send(authenticatedUrl, { credentials: "include" });
if (!authenticated.ok) throw new Error("desktop welcome: Web authentication failed");

431 被统一归入 !ok，真实状态码被吞掉，日志中只剩"认证失败"，极难定位。

---

为什么 Web 版不会遇到

三个条件在 Web 版被默认用法消掉了：

1. dsh web 默认使用配置中的固定 host + port，哈希稳定 → 同名覆盖，永远只有 1 条
2. cookie 存在用户自己的浏览器里，可随手清理
3. 万一触发，浏览器直接显示 431 页面，不会变成"应用无法启动"

桌面端则相反：端口必须每次随机（无法假设某个端口空闲）、cookie 存在
应用内置 profile 里无人清理、失败被包装成误导性的启动崩溃弹窗。

---

建议修复（按优先级）

1. cookie 名去掉端口因素，改为固定名（如 dsh-auth），让新 cookie 覆盖旧 cookie；
   authority 信息已包含在 value 内，无需体现在名字里
2. 或者在写入前，先删除该 host 下所有 dsh-auth-* 旧 cookie
3. 容错：connectDesktopWelcome 收到 431 时，清理陈旧 dsh-auth-* 后重试一次
4. 把状态码写进错误信息，例如
   desktop welcome: Web authentication failed (HTTP 431)，
   并在致命弹窗中区分该场景，提示"清理会话 cookie"而非"重装"

---

临时规避

关闭应用（含托盘）后删除：
%APPDATA%@deepseek-ai\dsh-desktop\Network\Cookies
%APPDATA%@deepseek-ai\dsh-desktop\Network\Cookies-journal

该库仅包含上述 localhost dsh-auth cookie，不影响账号登录态
（凭据存于 ~/.dsh）。

清理后大约可再用 70 次启动，之后复发。

---

补充

如果你也遇到同样的报错，可以核对一下 cookie 库里的条数。
只要 127.0.0.1 下的 dsh-auth-* 接近 70 条，基本就是这个原因，
清掉即可恢复，无需重装。

[PerryLink]

你的推导我逐条核了，都对，只在修法上补一个坑。

代码侧对得上（master ce7073d5）：

• packages/client/connection/src/browser-auth.ts:79-84 的 authority 在 http 下取 url.host，含端口；
• :116-118 名字 = dsh-auth- + base64url(sha256(authority))，端口一变名字就变；
• :138 只写 Max-Age / Expires（cookieMaxAgeDays 默认 30 天），整个文件里没有任何删除旧名字的分支；
• apps/desktop-host/src/index.ts:36 就是 --port 0。

所以"必然而非偶发"这个判断成立，browser-auth.ts 从 rc.2 到 master 是同一个 blob（5c8594df），现在没有哪个版本修了它。

补的坑在修法方向：不要用"名字里去掉端口"来修。packages/client/connection/README.md:43 写明名字和 payload 都绑 hostname+port，是为了同一个 home 能同时跑多个 Web 端口而不互相覆盖。去掉端口后浏览器里同名 cookie 只能留一条，两个端口会互相顶掉，每次切换都得重新认证。

最小修法是写入时清理同族旧名：签发新 cookie 之后，把其它 dsh-auth-* 置为过期（Max-Age=0）。端口照旧进名字，条数压在 1 条附近，多端口也不受影响。

恢复你现在的做法（关掉应用，删 Network/Cookies）是有效的，只是把"攒满"变成"从头攒"。

[ziyouzhiyi666888]

多谢逐条核对，特别是修法方向那段——我之前提的"名字去端口"确实想漏了，
没看到 README:43 里多端口共存是明确的设计目标。这个纠正我接受。

补一条现场验证，正好把你给的算法闭环了。

按 dsh-auth- + base64url(sha256(authority)) 复算，本机两次启动的实际
cookie 名逐字节吻合：

• 127.0.0.1:49494 → dsh-auth-xve1cdvif713tCh-zvXXZ2XqUnAtUVDatWsduYXhYok ✅
• 127.0.0.1:49448 → dsh-auth--PByDpIKJpL9Zp2ULLjdZrdFFVsKhLX4vndfOJwdJhY ✅

所以"端口进名字 → 每次启动必然新增一条 → 永不覆盖 → 累积到 70 条撞 16KB
上限"这条链是确定的，不是推测。

关于你给的最小修法（签发新 cookie 后把其它 dsh-auth-* 置 Max-Age=0）：
我理解它不破坏多端口共存，因为端口仍在名字里，被清掉的只是同一 authority
之外的陈旧条目。如果需要验证，我可以在本地反复启停几十次，把 cookie 条数
曲线跑出来，确认能稳定压在 1 条附近、且多端口同时开时不互相顶掉。

另外这个 workaround 我已经做成脚本常备了（关应用 → 删 Network/Cookies），
修好之前就用它顶着。

[LewisYa]

补充另一个失效面：这台机器上除了 431，还有一条 bad port 的死法，两者都源自 --port 0。

环境：DSH Desktop 0.2.1-rc.2（Windows 11 x64 / Electron 44.7.0 / Node 24.21.0），
Windows 动态端口范围被设为 1024 起 13977 个（1024–15000）。

crash-2026-10-30T14-25-40-548Z-host.log：

app: @deepseek-ai/dsh-desktop 0.2.1-rc.2
--- error ---
[TypeError: fetch failed] {
  [cause]: Error: bad port
      at makeNetworkError (node:internal/deps/undici/undici:11841:35)
      at mainFetch (node:internal/deps/undici/undici:13224:22)
      at fetch (node:internal/deps/undici/undici:13075:20)
      at authenticateWebHost (.../app.asar/lib/main.js:8230:25)
      at Object.start (.../app.asar/lib/main.js:12191:24)
}

同目录另有 5 份是主帖那种 desktop welcome: Web authentication failed（cookie 累积 431）。
即同一台机器上两种症状交替出现，机制不同：

1. 随机端口落进 fetch 规范的 blocked port 表 → bad port，authenticateWebHost() 首
   次 fetch 就抛，启动当场终止（不需要累积 cookie，首次启动即可中）；
2. 端口每次都不同 → cookie 名随之不同 → 累积到 ~71 条撑爆 16KB → 431（主帖）。

第 1 条依赖机器配置：undici badPorts 里 ≥1024 的条目为
1719, 1720, 1723, 2049, 3659, 4045, 4190, 5060, 5061, 6000, 6566,
6665, 6666, 6667, 6668, 6669, 6679, 6697, 10080
本机 dynamicport = 1024–15000，刚好全部覆盖；Windows 默认 49152–65535 时它们都不可达。

用户侧规避（两条都能治）：把 Host 监听端口钉死，桌面端可在 profile 的
cordis.patch.yml 覆盖 webserver 插件：

- id: webserver
  name: '@deepseek-ai/dsh-host-webserver'
  config:
    host: 127.0.0.1
    port: 38780

端口固定后 cookie 名稳定（同名覆盖、不再累积），也不会再落进 badPorts。
0.2.1-rc.2 与 rc.5 的 dsh-host-webserver/lib/index.js 字节相同
（sha256 前缀 08907285802F0EDD），该覆盖在 rc.5 上同样有效。

建议修复：--port 0 拿到端口后若命中 blocked 表，重新 bind 或给出可读错误，
不要把它包装成 "Web authentication failed"。

[PerryLink]

@LewisYa 这条是新信息，而且和 431 是两回事 —— 我在本地确认了机制。

Node 的 fetch（undici）会拒绝 WHATWG 的 blocked port 列表，对 127.0.0.1 也一样。刚跑的两条：

fetch('http://127.0.0.1:6000/')  → TypeError: fetch failed, cause: bad port
fetch('http://127.0.0.1:49494/') → cause: connect ECONNREFUSED

同一条命令、同样没人监听，只有名单里的端口会得到 bad port，其它端口才走到连接阶段。所以你的判断对：--port 0 让 OS 从动态端口段里挑，段一旦覆盖了 6000 / 6665–6669 / 10080 这些，那一次启动在 authenticateWebHost() 的第一次 fetch 就抛，和 cookie 条数完全无关 —— 这也解释了为什么有的机器第一次启动就中。

两个失败共享同一个起点（--port 0），但修法不同：

• bad port：拿到端口后校验一次，落在 blocked 集合里就重新绑；或者由 Host 自己挑端口再报给壳。
• 431：写入时清理同族 dsh-auth-*。

用户侧能做的：把动态端口段改回 Windows 默认的 49152 起（netsh int ipv4 set dynamicport tcp start=49152 num=16384），名单里 ≥1024 的那些端口就都不在段内了。这是改系统全局设置，动之前自己评估影响。