平时在 DeepSeek Harness 里写代码或者让模型跑复杂任务，最容易遇到一种黑盒式的停顿。

光标停在那里几秒钟没有吐字，心里总会下意识冒出几个疑问。是本地的科学上网网络在抖动，还是中间的反代网关在排队，或者只是大模型本身正在做长思考。

为了让自己心里有个准数，我决定给 DSH 的 Web 界面做个轻量级的网络脉搏感知插件，取名叫 dsh-link-pulse。

想要解决什么

做这个小工具的目标很简单，一眼就能看清当前连接的上游网关到底顺不顺畅。

第一个是动态感知当前模型。每个人在 settings.yaml 里配置的模型供应商各不相同，有人用 CPA 网关，有人用 OpenCode GO，也有人直连 DeepSeek 官方通道。插件启动时会自动读取配置文件，建立模型和 Provider 的对应关系。当我们在会话输入框切换不同模型时，侧边栏左下角的常驻胶囊会自动同步变成对应的供应商名字与实时延迟。

第二个是多通道的并排对比。平时难免同时配置了主力通道和备用通道。点击侧边栏条目或者鼠标悬停上去，会弹出一个小看板，把当前正在使用的通道放在最上方，下方整齐列出其它备用通道的延迟对比。哪条链路连通性更好，一目了然。

第三个是零 Token 消耗与轻量开销。探针发起的只是底层的网络心跳包，不调用大模型推理接口，完全不消耗宝贵的 API 额度。

测速过程中的一个小插曲

在打磨测速算法时，碰到了一个挺有意思的细节。

刚开始探针用的是常规的独立请求。测速跑出来，连国内机房只要一百多毫秒，但连部署在德国法兰克福的自建网关却显示四百多毫秒。当时第一反应是网络哪里绕路了，排查后才意识到，这是把冷启动的建立连接耗时和长连接通信混在了一起。

从国内到欧洲大陆，光缆物理距离超过一万公里。一次完整的从零建立 HTTPS 连接，得走好几个来回，先握手底层连接，再跑两次加密证书协商，最后才发送数据并收回首包。四次跨国物理往返累加起来，自然会有四百多毫秒。

但在实际使用中，客户端和服务器之间常驻着长连接。真正发消息和接收流式字符时，加密通道早就就绪了，数据传输只需要单次网络往返。于是我把探针算法改成了测量加密管道就绪后的纯单次往返延迟。重新测速后，德国源站的读数立刻稳定在了真实的物理单程往返，也就是一百二十多毫秒。

在排版上，我也把侧边栏的展示形式调成了和 OpenCode 状态栏统一的紧凑点号分段，比如 ● CPA · Gemini 3.7 · 126ms，三段信息紧密连在一起，视觉上看着很工整。

怎么安装

插件已经发布到了 npm 官方源，同时也开源在 GitHub。在终端执行 DSH 标准插件命令即可一键安装。

dsh plugin --profile web add dsh-link-pulse

安装完成后重启一次 Web 实例并刷新页面，左下角设置图标上方就会常驻这一行低调的延迟指示灯。

代码开源在 j2st1n/dsh-link-pulse，也重度使用 DSH 的朋友可以装上试试。