局域网访问 dsh web：DeepSeek Harness 的绑定地址、防火墙与自签证书

让局域网里的手机或另一台电脑访问 DeepSeek Harness 的 dsh web，要同时解决三件事：绑定地址、端口放行、设备信任。 只改绑定或只放行端口都会失败，正确顺序是先监听对外地址、再放行端口、最后处理证书。另外注意：绑到全部网卡等于把本地工具变成局域网服务，不受信任的网络里要谨慎。

局域网访问 DeepSeek Harness 要解决的三件事

一句话结论：绑定地址决定「谁连得上」、防火墙决定「能不能过」、证书决定「浏览器信不信」——三件事必须同时成立。

DSH plugin 局域网访问的三种方案对比

一句话结论：只在受信任网段临时共享选方案 A；想最小暴露面选方案 B；完全不想开端口选方案 C。

方案 A：直接绑对外网卡（最快）

一句话结论：把监听地址改成全部网卡、放行端口，两步走通；这是「只在受信任局域网里用」的最短路径。

1. 起服务时指定监听地址与端口（参数名以 dsh web --help 为准）：

dsh web --host 0.0.0.0 --port 3080
# 预期：启动输出显示监听 0.0.0.0:3080

2. 本机自测（排除服务问题）：

curl -I http://127.0.0.1:3080      # 预期：返回 HTTP 响应头

3. 查本机在局域网中的地址：

# macOS / Linux
ipconfig getifaddr en0 2>/dev/null || hostname -I
# Windows（PowerShell）
# (Get-NetIPAddress -AddressFamily IPv4).IPAddress

4. 在另一台设备上访问 http://<你的局域网IP>:3080。
5. 不确定时用诊断命令三步走（见第 6 节）。

方案 B：只绑回环 + 反代（暴露面最小）

一句话结论：dsh web 只监听本机、由反代对外提供访问——可以集中加 HTTPS 与访问认证，适合「要给几个人用」的场景。

1. 服务端保持默认（只绑回环），反代层对外监听。
2. 反代配置要满足三条硬要求（WebSocket 升级、不缓冲、长超时），写法见 给 dsh web 配反向代理与 HTTPS。
3. 在反代层加来源限制：只允许内网网段访问，或叠加基础认证。
4. 证书用可信来源：内网有 CA 就签内网证书，设备一次信任、长期有效。
5. 故障定位上一节的三步同样适用。

方案 C：SSH 隧道（不开端口）

一句话结论：服务只监听本机、客户端通过 SSH 把端口转发到自己这边——不开任何对外端口，适合临时、单人使用。

1. 在电脑上按默认方式起服务（只绑回环即可）。
2. 在手机或另一台设备上做本地端口转发（示意，具体命令取决于你用的 SSH 客户端）：

ssh -N -L 3080:127.0.0.1:3080 你的用户名@你的电脑IP
# 预期：本机 3080 端口被转发到远端 dsh web

3. 在本机浏览器访问 http://127.0.0.1:3080。
4. 取舍：每次使用要建隧道；多人共享不方便；好处是不改变服务暴露面，也不需要动防火墙。

DeepSeek Harness 绑定地址的三种取值与后果

一句话结论：回环=只有本机、指定网卡 IP=只有该网段、全部网卡=所有网卡都对外——选哪个取决于「谁能连」，不取决于「能不能连」。

1. 127.0.0.1（回环）：默认值，只本机可达——最安全，也最常被误当成「服务坏了」。
2. 指定网卡 IP（例如 192.168.1.20）：只监听该网卡，适合机器同时接多个网络（内网 + 其它）时限定范围。
3. 0.0.0.0（全部网卡）：所有网卡都监听——风险等同于「该机器可达的所有网络都能访问」，务必配合防火墙来源限制。
4. 切换时机：临时需要共享时改、用完改回；把「长期绑全部网卡」当默认是不必要的暴露。

DSH plugin 的防火墙与端口选择（含证书信任）

一句话结论：放行要精确到「端口 + 来源网段」；证书信任是一次性动作，用自签就要接受每台设备手动信任一遍。

1. 选高位端口（避免落在系统保留区间被拒，也避开常见服务端口冲突）。
2. 放行精确到网段（示意）：

# Linux（ufw 示例）
sudo ufw allow from 192.168.1.0/24 to any port 3080 proto tcp
# 预期：同一网段可访问，其它来源仍被拦

3. 自签证书信任三步：生成证书 → 在服务端启用 HTTPS → 在每台设备上安装并信任（iOS 需在证书信任设置里启用；Android 装为用户证书）。细节各设备不同，装完记得验证一次。
4. 更省事的替代：内网 CA 或公网域名签发的证书，省掉逐设备信任的麻烦。
5. 信任之后仍要收敛来源：加密不等于授权。

DeepSeek Harness 局域网访问的验证与排查三步

一句话结论：本机 curl → 另一设备 ping → 端口探测，三步分别定位服务、网络、防火墙，不要一上来就改绑定。

1. 第一步（服务）：在本机 curl -I http://127.0.0.1:<端口>。不通 → 问题在服务本身（端口被占/权限），与局域网无关。
2. 第二步（网络）：在另一设备 ping <你的局域网IP>。不通 → 两台设备其实不在同一网段（访客网络、AP 隔离是常见原因）。
3. 第三步（端口）：能 ping 通但端口不通 → 防火墙拦了；用端口探测工具确认，再按上一节放行。
4. 还不行再看绑定：确认启动输出里真的是对外地址，而不是仍绑在回环上。
5. 顺手看一眼服务日志：有请求到达与否，是区分「没连上」与「连上但报错」的最快判据。

DSH plugin 排查注意事项

一句话结论：局域网共享时，先确认「能访问」再谈「插件能不能用」——两个问题分属网络层与应用层。

1. 网络层先通：按第 6 节三步验证。
2. 应用层再看：能打开页面但插件功能异常时，属于插件侧问题（如容器/权限前提），见 DeepSeek Harness 容器化安装 与 DeepSeek Harness 端口冲突排查。
3. 共享时把插件清单写清：谁在什么设备上要用哪个插件，用 DSH Plugin Hub 的已安装列表对齐，避免「我这边有、你那边没有」。
4. 用完记得收：把绑定改回回环、关掉临时放行的规则。
5. 移动端与局域网是两件事：移动网络/外网访问另有方案（见 apps/cli/README.md 与反代一文），别把内网方案直接搬到公网。
6. 修复状态如实：本文绑定参数与命令基于官方 CLI 说明；防火墙、证书与 SSH 隧道的具体做法因操作系统与设备而异，dsh web 的准确参数名以你机器上的 --help 输出为准。

局域网共享时建议先把「谁在什么设备上用哪些插件」写清——用 DSH Plugin Hub 的已安装列表对着刷一遍，就不会出现「你那边有、我这边没有」。

来源：apps/cli/README.md、Microsoft Learn · WSL networking、nginx Docs · WebSocket proxying。