装通 dsh-bridge 只要半小时，把它当长期可用的远程通道却要靠后面几个月。远程访问的本质是给外部世界开了一扇门，门开得再方便，也要有门禁、备份与轮换节奏。本文不重复安装流程，只讲怎么把它放进日常运维习惯。背景：dsh-bridge（wenbin-wb/dsh-bridge）站内分类 token 为 platform，星标 185，实装验证为 L4 · 真实安装（dsh 0.2.0-rc.2）。
一、门禁分层：先决定谁能进，再决定怎么证明身份
设置页「远程访问」→「安全认证」Tab 里是两套正交开关：按通道分流、按验证方式分级，选错组合等于白开。
三档分流
- 全部通道开启防护：局域网与所有公网隧道都要认证，适合人员复杂的场景。
- 仅公网隧道开启防护（推荐）：同 Wi-Fi 内免密，暴露到公网的隧道强制认证，多数场景从这档起步。
- 仅局域网开启防护：只拦局域网，仅当公网入口另有网关兜底时才考虑。
三档验证模式
- 🟢 扫码免密 + 密码认证（默认推荐）：二维码内已注入 256-bit 专属 Token，扫码免密；手动输入 IP 或域名者需输密码。
- 🔑 仅密码 / PIN：所有外部设备均需密码，最直白也最易因密码共享失控。
- 🎫 仅专属 Token 免密：只认控制台生成的二维码或带 Token 的链接。
底线：用了自建 WebSocket 隧道一定要配访问密码。隧道服务端只对控制通道校验 TOKEN，公网访客对隧道域名的转发不做独立认证，x-dsh-internal-tunnel 又让这部分流量无法享受本机回环保留——不设密码时，任何知道地址的人都能进，这正是坑二的裸奔状态。
把「🔄 重置安全 Token」当成例行轮换
Token 一旦共享就不可控。人员变动、手机丢失、二维码被截图，都该触发一次「🔄 重置安全 Token」，让旧二维码与链接立即全部失效，再分发给确实需要的人。把这件事写进季度清单。
二、第二道防线：独立管理员密码与三档后台策略
第一道防线管「谁能进界面」，第二道管「谁能改设置」，必须分开——把访问密码给了同事，不该等于他也能改你的隧道 Token 与机器人凭证。核心是独立管理员密码（与访客密码分离）；后台策略三档：需密码解锁（默认推荐）、仅限电脑本机管理（最高安全，远程一律禁止查看与修改网络、机器人配置与 Token）、宽松模式。长期运维里 仅限电脑本机管理 常是最终形态，代价是远程应急改配置不便，要配合下面的备份与巡检一起用。
三、配置备份与跨机迁移
坑九说的就是这件事：配置写在 ~/.dsh-bridge/，与 DSH profile 不是同一层，不随插件包迁移。换机器、重装、把服务从一台 ECS 迁到另一台，只搬插件包的话，IM 凭证、白名单、隧道参数全都没了。做法是在「运维监控」Tab 导出全局配置 .json 并在异地留一份，迁机后导入还原。节奏建议每次改动门禁或机器人配置后导出一份——配置变更才是漂移真正发生的时刻。导出文件含 Token 与白名单，等同密钥材料，存放位置要控权。
四、临时域名到期治理
模式 1 的临时隧道是免登录的随机 trycloudflare.com 域名，不固定、会被「重置链接」换新、也会随时间失效（坑十）。把域名抄下来贴工位，过几天必然打不开。判断标准很直接：这个入口若会被第二个人或第二台设备长期使用，就转模式 2——Cloudflare Zero Trust 建 Named Tunnel、绑固定子域名、填 Tunnel Token，勾选「随 DSH 启动自动开启」，ECS 重启后隧道自动恢复、URL 永久不变。
五、桌面端配置清单显示异常，先用 Web 端
DSH 若跑在桌面版内置宿主（profile desktop）上，可能遇到 IM 平台清单在桌面设置页显示异常，这是坑五描述的已知问题（#55），桌面版宿主仍在验证中。处理方式：改用 Web 端配置（README 明确「Web 端正常」），或等上游修复。把「配置入口统一在 Web 端」当约定，能少很多「明明配了却没生效」的排查。
六、阿里云侧的最小授权与出网收口
门禁再好，安全组对公网大开也是白搭。定期回看：
- 安全组入方向只留必要端口：
22限可信来源，临时 SSH 隧道端口用完即关；不要把3082对0.0.0.0/0开放。 - 弹性公网 IP 的绑定关系记录在案，避免「谁都能绑走」的模糊状态。
- VPC 与实例规格单一职责：这台 ECS 只跑 DSH 与隧道，规格留足内存，别让隧道进程被 OOM 打断。
- 出网策略确认放行 Cloudflare 边缘、npm 源与实际使用的 IM 服务域名。
七、定期巡检项清单
频率按团队定，但门禁与备份每次都看：
- 门禁分流档位与验证模式是否仍为预期值，有没有被改成宽松档；
- 「🔄 重置安全 Token」上次轮换时间，白名单里是否还留着已离职 / 已停用的人员 ID；
- 全局配置
.json是否有最近一次变更后的导出版本，异地存放是否可读； - 临时隧道域名是否还有人在用，需长期入口的是否都已转 Named Tunnel；
- 安全组入方向是否新增了公网放行，
3082是否仍然收敛； - 隧道进程与 DSH 的 Uptime、内存占用是否正常，有没有被 OOM 打断后自动重启的痕迹。
总结
远程连通真正难的不是装通，而是把门禁分层、Token 轮换、配置备份与域名治理变成有触发条件的例行动作，再用阿里云安全组的最小授权兜住底座。想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：需要长期在手机 / IM 里调度本机 DSH 的个人开发者；有固定域名入口诉求、又不愿自建公网服务的小团队；把 DSH 跑在 ECS 上、需要可交接远程访问配置的运维者。不适合：没有远程刚需、只在本地用 DSH 的人——把 DSH 暴露到公网本身就是风险面的扩大；对独立认证有硬性合规要求的团队，自建隧道的公网转发默认没有独立认证，安全完全依赖自己开；连季度轮换 Token 都不愿排进日程的团队，白名单与旧二维码会持续累积风险。此外插件本身也要自评：静态扫描显示它会读写删本地文件并发起外部网络请求，站点尚未对其做风险分级。
标签：dsh-bridge、DeepSeek Harness、远程运维、安全门禁
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
