Linux 服务器没有桌面怎么用 DeepSeek Harness：dsh web、端口转发与桌面端边界

那台服务器没有桌面，我拿到 SSH 账号时，第一反应不是装包，而是确认 DeepSeek Harness 能不能在这台机器上活下来。 图形界面在这里帮不上忙，真正要跑的是 Node、端口和浏览器这几件事。下面是我从第一次登录到把 DSH插件 装上的顺序，中间也踩了白屏和端口两个坑。

拿到那台机器，我先判断 DeepSeek Harness 能不能跑

没有桌面不等于不能跑，缺的只是一个把页面送出来的通道。

登录之后我先看系统版本和 Node。node -v 和 npm -v 各跑一次，版本太旧就先升级 Node，再谈安装；很多「装上了但起不来」的问题，最后都追到 Node 版本上。服务器的包管理器能装 Node 最好，不能就按官方文档的步骤来，别混用两套来源。

接着确认命令本身能不能取到。执行 npx @deepseek-ai/dsh --version，能输出结果说明包能下载、PATH 也没问题。如果卡在下载，多半是网络或镜像源，不是 dsh 本身坏了。这一步失败时就别继续往下折腾端口，先把取包的问题解决掉。

然后看端口和资源。ss -ltnp | grep 3080 或 lsof -i :3080 确认默认端口没被别的服务占着，free -h 与 df -h 看内存和磁盘够不够。内存紧张时界面能打开，但会话跑一会儿就失败，看起来像插件问题，实际是机器扛不住。

我一开始也找过「Linux 版安装包」，后来才明白这台机器不需要那个东西。桌面窗口、托盘、系统通知在这里本来就不存在，能用的只有 Web UI、命令行和插件管理。接受这个边界，后面的步骤就顺了。

第一条隧道：把 dsh plugin 的页面接到本地

先用 SSH 本地转发，把服务锁在回环地址上，再谈别的访问方式。

我没有一上来就把服务绑到 0.0.0.0。先在服务器上启动 Web UI，让它只监听本机；确认服务活着之后，再从我的电脑建立隧道。这样即使配置出错，暴露面也只是一台机器的回环地址。

npx @deepseek-ai/dsh web
#本地另开一个终端
ssh -L 3080:127.0.0.1:3080 用户名@服务器地址

隧道建好后，浏览器访问 http://127.0.0.1:3080，不要换成服务器的公网 IP。前者走的是加密通道，后者要么被防火墙挡住，要么需要你额外开放端口，风险和配置量都更大。第一次成功时，我先确认页面能开，再新建一个会话，最后看插件列表能不能加载。

需要长期挂着时，我会用 tmux 或 autossh 维持会话。SSH 一断，隧道和页面会同时失效，这不是 dsh 崩了，而是链路没了。如果服务器不能接收入站连接，可以改用远程转发，原理相同、方向相反，先把最小链路跑通再说。

白屏的那几分钟，我按顺序拆 DeepSeek Harness 的链路

白屏不是一种病，它至少有服务、隧道、前端三种来源。

看到白屏就重装，是最费时间的做法。我按下面的顺序查，每次只改一个变量，确认这一层从「不通」变成「通」再动下一层。顺序本身不神秘，关键是别跳步。

1. 在服务器上执行 curl -I http://127.0.0.1:3080，没有响应头就查进程、端口和 Node 版本。
2. 在本地终端执行同一条命令，服务器能通而本地不通，就是端口写错或转发没建立。
3. 打开浏览器开发者工具的 Network 面板，看静态资源是不是 404，WebSocket 是不是停在 101 之前。
4. 只有走了反向代理才查代理层，重点看 Upgrade、Connection 头和超时设置。
5. 每修完一层就重跑对应的 curl，别一次改三处，否则不知道是哪一处生效。

curl -I http://127.0.0.1:3080   #先在服务器上跑
curl -I http://127.0.0.1:3080   #隧道建立后，在本地再跑一次

最常见的误判，是把浏览器代理当成服务器故障。公司网络里浏览器走了 HTTP 代理时，127.0.0.1 也可能被接管，表现就是隧道明明通了、页面却一直转圈。遇到这种情况，先把浏览器代理关掉或给回环地址加例外，再重新加载。

还有一次是端口对不上：dsh web 实际监听的端口和我转发的不一致，服务器上 curl 通，本地却什么都没有。把两边端口对齐后页面立刻出来。所以每层都要留下可复现的命令和输出，别只凭记忆判断。

第二个人要用时，DeepSeek Harness 才轮到反向代理

第二个人能用隧道就别上域名；要域名时，认证和 TLS 必须一起补。

先问一句：第二个人能不能也用隧道？能，就继续用隧道，成本最低。给每人一个 SSH 账号，比临时搭一套公网入口省事得多，也更容易收回权限。小团队阶段，这一步往往就够了。

确实需要域名、HTTPS 或外部成员接入时，再上反向代理。服务仍然只监听本机，Nginx 或 Caddy 与它在同一台机器上，别把 3080 直接暴露到公网。配置里要显式处理 WebSocket 升级，并把读超时调长，否则长输出会在中途断开。

认证不能省。Basic Auth、OAuth 网关、IP 白名单，选一种补上，别让页面裸奔在公网上。改完之后从外部机器 curl 一次看状态码，再在浏览器里跑一次长输出，确认流式响应没有被截断。域名和证书只是门面，认证才是门锁。

容器我只拿来试 DSH插件

容器适合复现问题，不适合保存状态。

试新版本、试插件冲突时，我会开一个临时容器，验证完直接删，不留残留。它最大的好处是干净：依赖、Node 版本、数据目录都可以从零开始，不会污染宿主机上那套已经调好的环境。用完就删，宿主机上不会留下半截依赖。

用容器有两件事必须显式处理。端口要映射，容器内监听不等于宿主机能访问；数据目录要挂载，把 DSH_HOME 指到卷上，否则容器一删，会话和插件一起没。很多人第一次用容器，就是在这两点上丢数据。

长期使用我还是建议直接装在宿主机上。容器负责「不确定的时候试一下」，宿主机负责日常使用，两者的职责别混。真要把容器当长期住处，就得把备份、升级和日志都重新设计一遍，成本不比直接安装低。

装 DeepSeek插件 时，命令行负责收尾

无桌面环境里，浏览器负责看，命令行负责留痕。

浏览器路线很直接：打开 DSH Plugin Hub，搜包名，确认版本后安装。它的好处是能看到详情和更新时间，适合第一次挑插件。缺点是操作过程留在界面里，换台机器就复现不了。

命令行更适合可复现与批量。dsh plugin add <包名>@<版本> 可以写进脚本，离线机器则用 tarball 或本地目录安装。搜不到时，把 DSH插件、DeepSeek插件 和包名三种写法各试一次，通常总有一种能命中。

不管走哪条路，最后都用 dsh plugin list 核对包名与版本。重启后插件应该进入 ACTIVE，而不是停在 PENDING；停在 PENDING 时先看依赖和版本要求，别反复点安装。最后我把 Node 版本、dsh 版本、隧道端口和 DSH_HOME 路径记在一个文件里，下次换机器照着走就行。

来源：DeepSeek Harness 快速开始、deepseek-harness 仓库、npm @deepseek-ai/dsh。