手机端连不上电脑里的 DeepSeek Harness，报错往往只有一两行，原因却可能散在 Cookie、网关、网卡和信任校验四个层面。如果不想靠反复重装试错，可以先看 DeepSeek Harness Hub 的 DSH Mobile 条目，里面把版本、通道和已知问题都列了出来。这篇按「先看到什么、再查什么」的顺序，把最常见的四种情况摊开讲。
先按症状分流，再谈参数
排错最容易犯的错，是一上来就去翻配置。更省时间的做法是先给症状分类：是认证过不去（401、反复要求配对），还是功能不生效（某个社区插件在手机上点不动），还是整条链路断了（换网后局域网失联），还是写入被拒（设置保存报错）。四类问题的判据和处置完全不同，下面逐个拆。
有一点值得先记住：这四种情况都发生在「电脑端 DSH 本身还在正常运行」的前提下。如果电脑上的 DSH 已经起不来，那不是移动访问的问题，应该先回到电脑本地排查 DSH。反过来，只要电脑端正常，手机侧的绝大多数报错都能在这四类里找到归属，不需要重装插件或 App 来「碰运气」。
坑一 · 配对成功后仍反复提示重新配对或续期 401
现象。 配对流程已经走完，进入 App 仍然被要求重新配对，或者请求直接返回 401；有时刷新一下又能用，过一会儿再掉。
原因。 同一域名上跑着别的服务、或者浏览器里残留的旧 Cookie，会干扰本插件的认证 Cookie；此外，其他认证错误或代理层的错误同样可能以 401 的形式返回，所以 401 并不等于「密钥错了」。
解决。 先把插件与 Android App 都更新到 0.5.4，再从当前的移动访问入口重试。浏览器端重新扫描当前二维码即可更新本插件的认证 Cookie，不需要清除所有网站数据------这一步很多人做过头，反而把其他站点的登录态一起清了。如果仍然失败，去看那条失败请求和脱敏日志，确认 401 到底来自插件网关还是上游代理。
坑二 · 社区侧边栏插件的 WebSocket 被默认拦截
现象。 页面能打开、主界面正常，但某个社区侧边栏插件在手机上功能不可用；电脑端诊断页里会多出一批「待处理」项。
原因。 网关默认只放行 DSH 内置的第一方 WebSocket 路径，包含 /sidebar/ws/terminal；社区插件用的其他路径默认被拦，例如 /sidebar/ws/agent-opens、/sidebar/ws/agent-terminals 这类，需要人工确认后才会通过。
解决。 打开 连接诊断 → 第三方 WebSocket 路径，只对确认过的精确路径点「允许」。系统不接受带查询字符串或模糊前缀的写法，也不建议直接「全部允许」------那等于把没核对过的路径一起放进来。放行只代表该路径能通过已认证、同源的 DSH Mobile 网关，既不会开放任意 TCP/UDP 端口，也不会绕过设备配对。
坑三 · 切换网络后局域网访问休眠
现象。 换了 Wi-Fi 或热点之后手机连不上，但电脑上的 DSH 本身一切正常，会话也没丢。
原因。 日志里会出现 saved LAN interface "XXX" is not connected，说明当初保存的那块网卡当前不在线。这不是崩溃，而是移动访问进入了休眠。
解决。 原网卡恢复连接后会自动重试，通常不用管；如果确实已经改用新网卡，就重新完成局域网配置，或者重跑一次 setup。临时不用移动访问时，也可以在 cordis.patch.yml 里禁用 mobile-access，避免它反复探测。
坑四 · 设置请求返回 HTTP 403
现象。 在手机端修改设置，保存时报 403，而同样的设置在电脑本地却能改。
原因。 这是 DSH 的 Host/Origin 信任校验在起作用。iframe、反向代理或浏览器扩展都可能改写请求来源，让校验判定来源不可信；公网 IP 和任意域名本来也会返回 403。
解决。 先用本机直接访问 DSH 验证一遍，确认设置本身没问题；然后逐项排查 iframe、代理和浏览器扩展。关键是保持信任检查启用，不要为了绕过 403 把它关掉------那会把真正的防护一起关掉。
两个最容易被误判的现象
除了上述四个坑，还有两个提示语非常容易被读反，单独拎出来说。
一是页面能打开但一直显示「重连中」。 这并不总是网络断了。要先区分三种情况：WebSocket 升级失败、慢速数据同步、心跳超时。它们外观相似，处理方式不同，按慢链路与反复重连指南逐项对照即可。0.5.4 另外提供了按确切路径启用的 WebSocket 压缩，默认关闭，长会话或按流量计费时可以在指南里对比实际传输量后再决定是否打开。
二是远程诊断显示「电脑经代理可访问」。 诊断逻辑是先直连，直连失败后才尝试 DSH 进程环境变量里的 HTTP 代理（NO_PROXY 可以排除目标）。因此这句话只说明电脑经代理完成了一次 HTTPS 探测，不代表手机或实际隧道可用。正确的验证方式是用手机流量实际连一次；如果直连和代理都失败，诊断仍会报不可达，不会把离线误报成就绪。
总结
排错的顺序其实是固定的：先看症状属于认证、功能、链路还是写入，再按对应判据查最小范围，大多数问题不用重装就能定位；本文涉及的版本与通道细节，都可以在 DeepSeek Harness Hub 插件清单 里对照确认。
适合与不适合
适合：家里或办公室有稳定局域网、想在手机上继续同一份 DSH 会话的人；经常在电脑旁边用手机看任务进度的人；需要检查社区插件 WebSocket 是否被拦的排错者；愿意按通道矩阵取舍远程方案的进阶用户。
不适合：把手机当成长期在弱网下交互的第二终端的人------cpolar 免费线路只有 1 Mbps，卡顿是带宽现实而非配置问题；只使用 iOS 设备的人------原生 App 只支持 Android；以及不愿意承担「配对设备等价于电脑完全受信」这一前提的人，手机丢失必须立刻从电脑端撤销设备。
标签：DSH Mobile、DeepSeek Harness、手机远程访问、故障排查
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。