[Bug][Desktop] 0.2.1-rc.3 启动即崩「desktop welcome: Web authentication failed」：dsh-auth cookie 按随机端口累积，撑破请求头上限后宿主一律 431

[Gaudi-XIX]

环境

• Windows 10 22H2 x64
• DeepSeek Harness 桌面端 0.2.1-rc.3（由 0.2.0-rc.2 自动升级；Electron 44.7.0）
• 使用场景：重度折腾——一天内多次重启宿主／插件管理器安装卸载操作（每次都会重建 host、换随机 GUI 端口）

现象

应用完全打不开：点击图标后无窗口，主进程启动即退，连续重试 6 次全崩。%APPDATA%\@deepseek-ai\dsh-desktop\logs\ 下的 crash-*-host.log 全部崩在同一处：

phase: startup
app: @deepseek-ai/dsh-desktop 0.2.1-rc.3
--- error ---
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (.../resources/app.asar/lib/main.js:8886:31)
    at async Object.start (.../lib/main.js:12195:22)

重启、重装均无效。唯一恢复手段：完全退出应用后，手工删除 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies（SQLite）里 host_key='127.0.0.1' AND name LIKE 'dsh-auth-%' 的行，再启动即愈（本例一次删除 71 行后完全恢复）。

根因（已定位到包与数据）

1. cookie 名绑定随机端口，只增不减：@deepseek-ai/dsh-client-connection 里 cookieName(authority) = 'dsh-auth-' + base64url(sha256(authority))，而 authority 来自 Host 头＝127.0.0.1:<port>。桌面端 GUI 端口每次启动随机 ⇒ 每次启动铸出的 cookie 名字都不同，旧的永远不会被覆盖、只会累积。单枚约 227 B（名 52＋值 172），属性 Path=/; HttpOnly; SameSite=Strict; Max-Age=3 天。
2. 请求头被累积 cookie 撑爆：Electron 侧（net.fetch + credentials:'include'）对本机宿主的每个请求都携带 cookie 罐里全部 127.0.0.1 的 cookie。累积到 71 枚时 Cookie 头约 16.1 KB，加上请求行与其余头超过 Node HTTP maxHeaderSize（16,384 B） ⇒ 宿主对一切带 cookie 的请求直接回 431。
3. 启动握手一半不走 cookie 罐、一半走：authenticateWebHost（Node 原生 fetch、无 cookie 罐）照常完成 303＋set-cookie；紧接着 connectDesktopWelcome（net.fetch、带罐）第一个请求就吃 431 ⇒ !response.ok ⇒ 抛错 ⇒ 主进程退出。这个「一半通一半死」的不对称在排障时非常有迷惑性。
4. 过线即永久无法启动：失败启动连新 cookie 都铸不出来（第一个请求已是 431），一旦越线没有任何自愈机会——只能手工清库。

边界证据：cookie 罐里最新一枚的时间戳精确停在最后一次成功启动的时刻；此后每次失败启动都没有新增任何 cookie。

复现

正常使用即可：3 天窗口内累计 70+ 次宿主启动/热重载（插件管理器的安装/卸载操作也会触发 host 重建换端口）。本例一天内攒到 71 枚越线。

修复建议（任一即可止血）

1. cookie 名与端口解耦（固定名），让每次启动自然覆盖旧 cookie；
2. 铸新 cookie 时顺带给同 origin 的陈旧 dsh-auth-* 补 Max-Age=0（或启动握手前清一遍）；
3. connectDesktopWelcome 失败不要直接崩主进程——捕获后清 origin cookie 重试，或给用户一个可点的恢复入口；
4. 或为启动握手使用独立 session partition，让业务 cookie 罐的膨胀不影响启动链路。

给同样中招用户的临时解法

完全退出 DSH（运行中的 Electron 会锁住该 SQLite 文件），然后：

// node 一行（需 Node ≥22.5 带 node:sqlite）
const {DatabaseSync}=require('node:sqlite');
const db=new DatabaseSync(process.env.APPDATA+'/@deepseek-ai/dsh-desktop/Network/Cookies');
console.log(db.prepare("DELETE FROM cookies WHERE host_key='127.0.0.1' AND name LIKE 'dsh-auth-%'").run().changes);
db.close();

跑完重新启动即可。

[transmerger]

2026-10-27 独立复现，结论与本贴一致。这里补本贴缺的一环：431 的直接抓包证据。

环境：Windows 11 Home 26H2 (build 26300.9711) x64 · DSH 桌面端 0.2.1-rc.3 · Electron 44.7.0 · Node 24.21.0。

一、431 的直接证据（netlog）

桌面壳接受 Chromium 的 --log-net-log 开关，带它启动一次即可拿到完整 HTTP 事务：

DeepSeek​ Harness.exe --log-net-log=<输出路径>

解析 {"constants":{"logEventTypes":{...}},"events":[...]}（注意 events[].type 可能是数字，需用 constants.logEventTypes 反查事件名）。失败请求所在的 source 里只有三条关键事件：

事件	内容
REQUEST_ALIVE	http://127.0.0.1:<port>/?token=<...>
HTTP_TRANSACTION_SEND_REQUEST_HEADERS	Cookie: [16086 bytes were stripped]
HTTP_TRANSACTION_READ_RESPONSE_HEADERS	HTTP/1.1 431 Request Header Fields Too Large

netlog 会把 Cookie 头的内容打码，但保留长度，这正好把「累积到 16 KB」这一步坐实：16,086 B 的 Cookie 头 + 请求行 + 其余头 > Node maxHeaderSize（16,384 B），宿主直接回 431；connectDesktopWelcome 判非 2xx 抛错，主进程退出。

本贴给的边界证据是「cookie 时间戳停在最后一次成功启动」——那是间接推断；上面这条是同一请求的请求头长度与响应码，可以直接定位到 header 上限那一层。

二、一个更容易误导人的细节：认证其实"成功了一半"

同一次启动里，两步走的是两套网络栈：

• authenticateWebHost 用 Node 原生 fetch（不走 Electron cookie 罐）→ 照常拿到 303 + set-cookie，成功；
• 紧接着 connectDesktopWelcome 用 net.fetch（走 cookie 罐、credentials: 'include'）→ 第一个请求就吃 431。

所以 Web authentication failed 这句文案几乎指反了方向：失败的不是认证，是「带罐的第一次请求」。建议把 431 单独映射成一个明确错误（例如 local auth cookie store exceeded header limit），而不是复用通用的 Web 认证失败——否则用户和排查者会一路往代理、账号、时间同步上找。

补充一条自测办法：把这两步分开看即可验证——用不带 cookie 罐的方式请求同一地址仍然 303，而带罐的第一次请求返回 431。

三、修复建议（在原贴四条基础上补两条）

5. 启动握手前自检 cookie 头尺寸，超限就清同 origin 的旧 dsh-auth-* 再重试一次，别直接退出主进程；
6. 让 connectDesktopWelcome 对 431 给出可操作的提示（"本地认证 cookie 过多，请清理"），而不是抛通用认证失败。

四、目前没有已修版本

nightly 通道 feed 上仍是 0.2.1-rc.3（releaseDate: 2026-10-23T08:02:12Z），与出问题的版本相同，升级无法规避。

五、用户侧临时缓解

清 host_key='127.0.0.1' AND name LIKE 'dsh-auth-%' 这个方法是对的。补充两点：

• 一定要在完全退出后做（库被独占），并且先备份 Network/Cookies 与 Cookies-journal；
• 别等到攒满 71 枚再清。按单枚约 227 B 估算，请求头到 9–10 KB（约上限 60%）就该清一次，留出重试余量；我们用一个前置检查脚本按「行数 + name/value 原始字节」双阈值判断，超阈值先备份再清。

[Refeain]

独立复现（Windows 10 x64，DSH 桌面端 0.2.1-rc.3 / Electron 44.7.0 / Node 24.21.0），结论与 OP 及 @transmerger 一致：71 枚越线，Cookie 头 16,186 B（比楼上 netlog 的 16,086 B 略高，差异来自当时 cookie 值长度）。

门槛我也实测了一次（对运行中的宿主逐字节二分）：

Cookie 头长度	宿主响应
≤ 16,315 B	401（正常走到认证求值）
≥ 16,325 B	431 Request Header Fields Too Large

即失败发生在 Node maxHeaderSize 那一层，请求根本没进业务逻辑——与 @transmerger 的 netlog 结论吻合。

补一条不需要用户手工清库的客户端止血方案（已在 rc.3 实测生效）

在 resources/app.asar 的 lib/main.js 里，start() 内、const ready = await host.start(); 之前插入：

try {
  const stale = (await session.defaultSession.cookies.get({}))
    .filter((cookie) => cookie.name.startsWith("dsh-auth-"));
  for (const cookie of stale) {
    const host = (cookie.domain ?? "127.0.0.1").replace(/^\./, "");
    await session.defaultSession.cookies.remove(
      `${cookie.secure ? "https" : "http"}://${host}${cookie.path || "/"}`,
      cookie.name
    );
  }
  // 自检：删完再读一次，仍有残留就整库兜底，不依赖 remove() 的匹配细节
  const leftBehind = (await session.defaultSession.cookies.get({}))
    .filter((cookie) => cookie.name.startsWith("dsh-auth-"));
  if (leftBehind.length > 0)
    await session.defaultSession.clearStorageData({ storages: ["cookies"] });
} catch {}

几个必须注意的点：

1. 必须用每条 cookie 自己的 domain / path / secure 反推 URL 再 remove()。早期试过固定 http://127.0.0.1/，删不掉带历史端口的条目——cookies.remove(URL, name) 是按 host 匹配的。
2. 删完要二次读取自检，不要假设 remove() 一定干净；有残留再走 clearStorageData。
3. 整段包 try/catch：清理失败绝不能影响启动，最坏退化成现状。
4. 位置必须是 app.whenReady() 之后、主窗口与 connectDesktopWelcome 之前。主窗口 createWindow() 未指定 partition，welcomeBackend 也读 session.defaultSession.cookies，所以清理的就是真正被发出去的那个罐子。

实测结果

时间	事件
22:32:02	补丁写入 app.asar（182,733,033 → 183,250,760 B；lib/main.js 516,716 → 517,727 B）
22:34:10	应用重启
22:34:40	cookie 库被改写：53,248 → 20,480 B（清零后 VACUUM 的最小尺寸）
22:32 之后	新增 crash-*.log 0 条

改 app.asar 前做了静态校验：头部 sha256 与新字节一致、vm.SourceTextModule 可解析、session 来自第 5 行 electron 具名导入；18,188 条目 / 16,605 个 sha256 全部匹配、0 越界。该版本 Electron 的 EnableEmbeddedAsarIntegrityValidation fuse 为 disabled，所以容器完整性校验不会拦截（但官方若将来打开该 fuse，此法即失效）。

这只是止血，不是修复

它每次启动清一次，代价是每次都要重新认证一次（本来也要认证），语义不变，但属于用户侧侵入式改动，且应用更新会覆盖补丁。

根本修法仍是 OP 的第 1 条：让 cookie 名与端口解耦（cookieName() 里把 authority 的端口去掉，或固定 GUI 端口）。这样每次启动自然覆盖旧 cookie，累积从机制上消失。

另外强烈赞同 @transmerger 的第 6 条：connectDesktopWelcome 应当把 431 单独映射成一个可操作的错误（例如「本地认证 cookie 过多，请清理」），而不是复用通用的 Web authentication failed。这句文案把所有人引向了代理、账号、时钟同步的错误方向，我自己也排查了很久才落到 header 上限上。同理，恢复对话框里的「禁用第三方插件」按钮对这个故障完全无效，却会顺带清空用户的 dsh-profile bundle 列表，制造第二个「我的插件全没了」的事故，建议该按钮先判断失败类型再决定是否出现。