dsh-bridge 的文档写得很直白局域网扫码、Cloudflare 隧道、自建 WebSocket 中转、四家 IM 机器人一装全有。但把这几条通道摆在一起之后真正需要读懂的其实是两件事——不同隧道模式各自的适用边界以及门禁在这几条通道上分别生效到什么程度。这篇从实现角度把这两件事捋一遍。三条隧道的取舍插件提供三种公网接入方式定位差别明显。模式 1极速免登录临时隧道默认。点「开启」后系统全自动准备cloudflared二进制macOS 上会自动剥离 Gatekeeper 隔离属性并做自愈校验几秒生成一个https://*.trycloudflare.com随机 URL 和二维码点「重置链接」可以随时换新。适合外出临时连一次、用完即走的场景。模式 2Cloudflare Token 固定域名免费。在 Cloudflare Zero Trust 控制台建好 Named Tunnel、绑定域名例如dsh.yourdomain.com把自定义域名与 Tunnel Token 填进面板再勾选「随 DSH 启动自动开启」。之后不管重启电脑还是重启服务URL 永久固定不变。这是需要长期稳定入口时该选的模式。模式 3自建 WebSocket 隧道。连接你自己的 VPS 中转服务器脚本是scripts/install-tunnel-server.sh带数据端到端 gzip 压缩与 SSE 响应优化。它把链路完全握在自己手里代价是安全责任也一并转移给你。自建隧道控制通道之外没有第二道门模式 3 是三者里需要更认真读文档的一个因为它有一段明确的安全须知。自建隧道上线后任何人知道地址就能进现象。自建隧道跑通、域名可访问但任何拿到地址的人都能直接打开你的 DSH。原因。隧道服务端只对「隧道客户端控制通道」校验TOKEN公网访客对隧道域名的 HTTP / WebSocket 转发不再做独立认证安全完全依赖插件本地的「访问认证」。更关键的是一个标识x-dsh-internal-tunnel使隧道流量无法享受本机回环保留——也就是说走隧道的请求不会被当作「本机」放行必须真正过门禁。而如果你连密码都没设这道门就是敞开的。解决。开启「安全认证」并设置访问密码或二维码 Token尤其在scopeall或公网使用场景下。文档的措辞很重未设置任何密码时任何知道隧道地址的访客都能直接访问你的 DSH。这段须知解释了插件门禁设计的前提——它默认「本机回环」可信所以物理机127.0.0.1/localhost享有免密直通特权设置面板也不会被锁。自建隧道的流量正因为带了x-dsh-internal-tunnel标识被排除在这份信任之外属于强制降级。理解了这一点就明白为什么「开了隧道但没设密码」是最需要避免的配置状态。桌面版宿主还在验证中插件的 DSH 版本兼容表是分段给出的0.1.0~0.1.1支持回环专用 RPC 通道加固0.1.2~0.1.4支持0.1.5-alpha.1~0.1.5-rc.2自 v2.10.9 起支持。最后一行是另一回事。桌面版里 IM 平台清单显示异常现象。在桌面版 DSH 里打开插件设置「IM 机器人」的平台清单显示不正常。原因。桌面版内置宿主是0.2.0-rc.2profiledesktop这一档目前仍在验证中已知问题编号 #55。解决。改用 Web 端配置README 明确写了「Web 端正常」或者等上游修复。站点这侧的实装验证同样是基于 dsh0.2.0-rc.2完成的等级为L4 · 真实安装。但请注意验证覆盖的是安装环节不等于桌面端每个界面都已完备。Telegram 通道的网络前提四家 IM 通道里Telegram 是唯一对国内网络有额外前提的一个。Telegram 机器人连不上现象。填好 Bot Token 之后机器人没有反应长轮询一直取不到更新。原因。Telegram Bot API 在国内网络不可直连。解决。在配置里填代理README 给的示例是http://127.0.0.1:7890。插件内置了零依赖的 HTTP/HTTPS CONNECT 代理隧道不需要额外装依赖。作为对照另外三条通道的网络形态完全不同微信走 ClawBot / iLink扫码登录个人号、全程走腾讯官方服务器不需要公网与隧道飞书用官方 WebSocket 2.0 长连接免公网 IP、免域名、免配置 WebhookQQ 走 OpenAPI v2群聊需要 机器人。它们共用同一套白名单与指令表但网络前提各不相同配之前值得先分清。门禁怎么组合把通道和门禁放在一起看比较清楚的做法是分层理解。第一道防线管「谁能进 Web 界面」门禁分流有三档全部通道开启防护、仅公网隧道开启防护推荐、仅局域网开启防护。验证模式也有三档扫码免密 密码认证二维码自动注入 256-bit 专属 Token、仅密码 / PIN、仅专属 Token 免密。第二道防线管「谁能改插件设置」用独立的管理员密码与访客密码分离。合理的做法是让门禁强度跟着通道的暴露面走局域网同 Wi-Fi 场景可以宽松公网隧道必须收紧自建隧道则没有余地——它的转发层本身不再做认证。三重容灾物理机免密直通、touch ~/.dsh/dsh-bridge/reset-auth救急标记、忘记密码指引是兜底不是可以省掉密码的理由。想对照同类插件的中文清单与安装形态见 完整插件清单与汉化避坑指南。环境侧的门槛不变Node 要求^22.19.0 || 24.0.0安装命令为dsh plugin --profile web add wenbin_wb/dsh-bridge局域网代理监听的端口是3082。插件在站点上的分类 token 为 platformGitHub Star 185许可 MIT最近提交在 0 天前。总结dsh-bridge 的三种隧道对应三种不同的信任假设而x-dsh-internal-tunnel这个标识是理解门禁边界的钥匙隧道流量不享受回环保留安全必须自己开。更多同类插件的中文说明与安装形态见 完整插件清单与汉化避坑指南。适合与不适合适合需要在多种网络环境间切换访问方式的开发者愿意自建 VPS 中转、并接受自己承担安全配置责任的人需要长期固定入口来远程使用 DSH 的团队主要用 IM 机器人在手机上推进任务的用户。不适合只想在局域网内用、不打算把服务暴露到公网的人没有能力或不愿意管理访问密码与 Token 的人期待「开箱即安全」、不想读自建隧道安全须知的人。标签dsh-bridge、DeepSeek Harness、远程访问、隧道本文由 DeepSeek Harness Hub 自动整理数据来源于插件详情页。
读 dsh-bridge 的远程访问实现
dsh-bridge 的文档写得很直白局域网扫码、Cloudflare 隧道、自建 WebSocket 中转、四家 IM 机器人一装全有。但把这几条通道摆在一起之后真正需要读懂的其实是两件事——不同隧道模式各自的适用边界以及门禁在这几条通道上分别生效到什么程度。这篇从实现角度把这两件事捋一遍。三条隧道的取舍插件提供三种公网接入方式定位差别明显。模式 1极速免登录临时隧道默认。点「开启」后系统全自动准备cloudflared二进制macOS 上会自动剥离 Gatekeeper 隔离属性并做自愈校验几秒生成一个https://*.trycloudflare.com随机 URL 和二维码点「重置链接」可以随时换新。适合外出临时连一次、用完即走的场景。模式 2Cloudflare Token 固定域名免费。在 Cloudflare Zero Trust 控制台建好 Named Tunnel、绑定域名例如dsh.yourdomain.com把自定义域名与 Tunnel Token 填进面板再勾选「随 DSH 启动自动开启」。之后不管重启电脑还是重启服务URL 永久固定不变。这是需要长期稳定入口时该选的模式。模式 3自建 WebSocket 隧道。连接你自己的 VPS 中转服务器脚本是scripts/install-tunnel-server.sh带数据端到端 gzip 压缩与 SSE 响应优化。它把链路完全握在自己手里代价是安全责任也一并转移给你。自建隧道控制通道之外没有第二道门模式 3 是三者里需要更认真读文档的一个因为它有一段明确的安全须知。自建隧道上线后任何人知道地址就能进现象。自建隧道跑通、域名可访问但任何拿到地址的人都能直接打开你的 DSH。原因。隧道服务端只对「隧道客户端控制通道」校验TOKEN公网访客对隧道域名的 HTTP / WebSocket 转发不再做独立认证安全完全依赖插件本地的「访问认证」。更关键的是一个标识x-dsh-internal-tunnel使隧道流量无法享受本机回环保留——也就是说走隧道的请求不会被当作「本机」放行必须真正过门禁。而如果你连密码都没设这道门就是敞开的。解决。开启「安全认证」并设置访问密码或二维码 Token尤其在scopeall或公网使用场景下。文档的措辞很重未设置任何密码时任何知道隧道地址的访客都能直接访问你的 DSH。这段须知解释了插件门禁设计的前提——它默认「本机回环」可信所以物理机127.0.0.1/localhost享有免密直通特权设置面板也不会被锁。自建隧道的流量正因为带了x-dsh-internal-tunnel标识被排除在这份信任之外属于强制降级。理解了这一点就明白为什么「开了隧道但没设密码」是最需要避免的配置状态。桌面版宿主还在验证中插件的 DSH 版本兼容表是分段给出的0.1.0~0.1.1支持回环专用 RPC 通道加固0.1.2~0.1.4支持0.1.5-alpha.1~0.1.5-rc.2自 v2.10.9 起支持。最后一行是另一回事。桌面版里 IM 平台清单显示异常现象。在桌面版 DSH 里打开插件设置「IM 机器人」的平台清单显示不正常。原因。桌面版内置宿主是0.2.0-rc.2profiledesktop这一档目前仍在验证中已知问题编号 #55。解决。改用 Web 端配置README 明确写了「Web 端正常」或者等上游修复。站点这侧的实装验证同样是基于 dsh0.2.0-rc.2完成的等级为L4 · 真实安装。但请注意验证覆盖的是安装环节不等于桌面端每个界面都已完备。Telegram 通道的网络前提四家 IM 通道里Telegram 是唯一对国内网络有额外前提的一个。Telegram 机器人连不上现象。填好 Bot Token 之后机器人没有反应长轮询一直取不到更新。原因。Telegram Bot API 在国内网络不可直连。解决。在配置里填代理README 给的示例是http://127.0.0.1:7890。插件内置了零依赖的 HTTP/HTTPS CONNECT 代理隧道不需要额外装依赖。作为对照另外三条通道的网络形态完全不同微信走 ClawBot / iLink扫码登录个人号、全程走腾讯官方服务器不需要公网与隧道飞书用官方 WebSocket 2.0 长连接免公网 IP、免域名、免配置 WebhookQQ 走 OpenAPI v2群聊需要 机器人。它们共用同一套白名单与指令表但网络前提各不相同配之前值得先分清。门禁怎么组合把通道和门禁放在一起看比较清楚的做法是分层理解。第一道防线管「谁能进 Web 界面」门禁分流有三档全部通道开启防护、仅公网隧道开启防护推荐、仅局域网开启防护。验证模式也有三档扫码免密 密码认证二维码自动注入 256-bit 专属 Token、仅密码 / PIN、仅专属 Token 免密。第二道防线管「谁能改插件设置」用独立的管理员密码与访客密码分离。合理的做法是让门禁强度跟着通道的暴露面走局域网同 Wi-Fi 场景可以宽松公网隧道必须收紧自建隧道则没有余地——它的转发层本身不再做认证。三重容灾物理机免密直通、touch ~/.dsh/dsh-bridge/reset-auth救急标记、忘记密码指引是兜底不是可以省掉密码的理由。想对照同类插件的中文清单与安装形态见 完整插件清单与汉化避坑指南。环境侧的门槛不变Node 要求^22.19.0 || 24.0.0安装命令为dsh plugin --profile web add wenbin_wb/dsh-bridge局域网代理监听的端口是3082。插件在站点上的分类 token 为 platformGitHub Star 185许可 MIT最近提交在 0 天前。总结dsh-bridge 的三种隧道对应三种不同的信任假设而x-dsh-internal-tunnel这个标识是理解门禁边界的钥匙隧道流量不享受回环保留安全必须自己开。更多同类插件的中文说明与安装形态见 完整插件清单与汉化避坑指南。适合与不适合适合需要在多种网络环境间切换访问方式的开发者愿意自建 VPS 中转、并接受自己承担安全配置责任的人需要长期固定入口来远程使用 DSH 的团队主要用 IM 机器人在手机上推进任务的用户。不适合只想在局域网内用、不打算把服务暴露到公网的人没有能力或不愿意管理访问密码与 Token 的人期待「开箱即安全」、不想读自建隧道安全须知的人。标签dsh-bridge、DeepSeek Harness、远程访问、隧道本文由 DeepSeek Harness Hub 自动整理数据来源于插件详情页。