[Desktop] Startup fails permanently after ~70 launches: per-port dsh-auth-* cookies overflow Node 16 KB header limit (host returns 431)

[beileibu322]

环境

• @deepseek-ai/dsh-desktop 0.2.2-rc.1（Electron 44.7.0 / Chromium 152 / Node 24.21.0）
• Windows 11 x64，profile desktop，DSH_HOME C:\Users\youyo\.dsh
• 官方安装包（download.deepseek.com/dsh-desk/...，nightly 通道）
• 装机时间 2026-09-25，故障发生于 2026-11-08 01:15（第 71 次启动）

---

现象

启动直接失败，弹出「DeepSeek Harness 无法使用」，logs/crash-*-host.log：

phase: startup
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (.../resources/app.asar/lib/main.js:16856:31)
    at async Object.start (.../lib/main.js:20386:22)

重试无效，永久失败；日志里没有任何指向真实原因的信息（无 401/431/网络错误），
用户从 UI 上无法自救（没有「清除本地会话」入口）。

根因

宿主每次启动绑定随机端口，桌面端签发的认证 cookie 名字绑定 host:port：

// apps/.../cookieName(authority)
COOKIE_PREFIX + base64Url(sha256(authority))   // authority = "127.0.0.1:<port>"

于是 每启动一次就多一条 cookie，且永不清理。单条实测 227 字节（name 52 B + value 173 B，
传输时连分隔符约 229 B）。累积到 约 70 条时，带 Cookie 的请求达到 16.4~16.6 KB，
超过 Node HTTP 服务端默认 maxHeaderSize = 16384，宿主返回：

HTTP/1.1 431 Request Header Fields Too Large

Electron 侧的 net.fetch 拿到非 2xx，就抛出与真实原因无关的
desktop welcome: Web authentication failed。

同一条启动链路里，先在哪个请求上越线，就报哪个错误

authenticateWebHost()（Node fetch，不带 Cookie）先拿到 303 + Set-Cookie，这一步永远成功；
随后 Chromium 带着全部 Cookie 依次请求 token URL、/、/api/*（RPC）。
启动链路上有三处会带 Cookie，越线发生在哪一处，错误文案就不同：

越线位置	表现
第 1 个请求（token）	desktop welcome: Web authentication failed
页面已加载、第 1 个 RPC	desktop welcome: Web request failed

两者根因相同，日志里都不出现 431。

本机 A/B 对照实验（可复现，实测字节数）

用「归一化灌入 N 条同形状 cookie → 启动 → 抓 netlog」的方式做了三组对照
（cookie 形状与真实签发的一致：name 52 B + value 173 B ≈ 227 B/条）：

起始 cookie	token 请求	跟随 303 到 /	首个 /api/* RPC	结果
60 条	14181 B → 303	14359 B → 200	14441 B → 200	正常启动 ✅
69 条	16242 B → 303	16420 B → 200	16502 B → 431	启动失败：Web request failed ❌
70 条	16471 B → 431	—	—	启动失败：Web authentication failed ❌

结论：每多一条 ≈ +229 字节，越过 Node 默认 maxHeaderSize = 16384 后启动必挂；
60 条与 69 条的差异只在于「崩在第几个请求」。

为什么崩了之后永远修不好

越线的请求在签发新 cookie 之前就被 431 拒绝，所以计数不再增长、也永远降不下来 →
之后每次启动都稳定复现，用户没有任何 UI 手段可以清除这些 cookie。

证据

1. Chromium netlog（--log-net-log=... --net-log-capture-mode=IncludeSensitive）

HTTP_TRANSACTION_SEND_REQUEST_HEADERS
  Host: 127.0.0.1:64426
  Cookie: dsh-auth-...; dsh-auth-...; ... (71 条)
SOCKET_BYTES_SENT {"byte_count": 16629}
HTTP/1.1 431 Request Header Fields Too Large

2. Cookie 库统计（Network/Cookies）

行数 71，host_key 全部为 127.0.0.1
sum(length(name)+length(value)) ≈ 16118
创建时间从 2026-10-17 14:28 到 2026-11-08 01:15，跨 18 天、每天 1~9 次启动，无异常峰值

3. 服务端本身完全正常（排除鉴权/令牌问题）

手工拉起宿主后直接 curl：

GET /?token=<launchToken>            → 303 + Set-Cookie
GET /?token=<launchToken>  带 cookie → 200
GET /                     无 cookie  → 401

确定性复现（不需要真启动 70 次）

已在本机验证通过：应用完全退出后，向 cookie 库灌入 N 条形状相同的假 cookie，再启动即复现。
N = 60 正常，N = 69 报 Web request failed，N = 70 报 Web authentication failed。

import sqlite3, secrets, string, time
p = r"...\AppData\Roaming\@deepseek-ai\dsh-desktop\Network\Cookies"
N = 70                                                      # 阈值约 70
c = sqlite3.connect(p)
c.execute("delete from cookies where name like 'dsh-auth-%'")
now = int((time.time() + 11644473600) * 1_000_000)          # Chrome epoch（1601 起，微秒）
for i in range(N):
    name = "dsh-auth-" + "".join(secrets.choice(string.ascii_letters) for _ in range(43))
    c.execute("""insert into cookies
      (creation_utc, host_key, top_frame_site_key, name, value, encrypted_value, path,
       expires_utc, is_secure, is_httponly, last_access_utc, has_expires, is_persistent,
       priority, samesite, source_scheme, source_port, last_update_utc, source_type,
       has_cross_site_ancestor)
      values (?,?,?,?,?,'',?,?,?,?,?,?,?,?,?,?,?,?,?,?)""",
      (now, "127.0.0.1", "", name, "v1." + "A"*169 + ".x", "/", now + 2_592_000*1_000_000,
       0, 1, now, 1, 1, 1, 2, 1, -1, now, 0, 0))
c.commit()

启动即得到同样的 Web authentication failed（N=70）。
（先备份 Network/Cookies；恢复时把 dsh-auth-% 行删掉即可。）

建议的修复（按性价比排序）

1. 启动时清理过期 authority 的 cookie（最省事，且能修复存量坏机器）
   在 apps/desktop 调 connectDesktopWelcome 之前，取出 session.defaultSession.cookies.get({ url })，
   把名字匹配 dsh-auth-* 但不属于当前 authority 的全部 remove()。升级到修复版即可自动解除卡死。

2. cookie 不再绑定端口
   用固定名（如 dsh-auth）作用域到 origin host，authority 放到 cookie 值的 claim 里校验，
   从根上消除「每端口一条」的膨胀。

3. 提高宿主头上限并区分错误
   宿主是以参数启动的（spawn(node, [--expose-internals, entry, ...])），
   加 --max-http-header-size=65536 可立刻止血；
   同时把 431 与 401 区分开，别都落到「authentication failed」。

4. 错误文案带上状态码
   desktop welcome: Web authentication failed → 建议附 HTTP <status>，
   这次排查如果日志里有 431，定位时间可以从两小时缩到两分钟。

用户侧临时绕过（供其他遇到的人参考）

完全退出应用后删除
%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies
（该库只有 127.0.0.1 的这类 cookie；账号登录态在 ~/.dsh/.credentials.yaml，不受影响）。
约 70 次启动后会复发。

影响面

不是个例：凡是长期使用桌面端（累计启动约 6970 次，按每天 34 次约 3 周）的用户都会撞上，
且表现为「昨天还好好的，今天突然打不开」，日志无有效信息，极易被误判为账号/网络/插件问题。
建议按「启动可靠性」优先级处理。