云上没有声卡，朗读桥在 ECS 上该改哪三件事
先说结论：朗读桥不是「装到服务器上就能念」的插件。它分两半——DSH 插件盯会话、把说完一整轮的话排进队列；浏览器扩展取队列、交给 DeepSeek 网页端点「朗读」。真正出声的是浏览器里的页面，声音从本机声卡出来。
所以一台默认配置的 ECS 上，三样东西同时缺席：声卡、带登录态的浏览器、常驻打开的页面。这不是配置问题，是形态问题。你要么改架构，要么改预期。
先看清它到底在哪一步出声
插件侧每 1.5 秒读一次会话新增事件，把文本按回合攒起来，turn/end 时才拼成一句话排队。从 v1.3.1 起，跨扫描的正文会保留，所以「正文和结束落在两次轮询之间」不再丢朗读。
扩展侧要做的事更朴素：从队列取话，发到 chat.deepseek.com，触发它自己的朗读。它不碰接口、不提取音频、不存凭证——本质是在你自己登录的页面里替你点一下按钮，和你手动点是一样的动作。
这解释了为什么 ECS 上「装好了但一句话都不念」是常态：队列在云端排得好好的，取队列的人和出声的页面都不在。
第一件事：把「出声」从云上摘掉
三种处置，各有代价。
一是只做链路验证。在 ECS 上跑 DSH 与插件，用扩展或脚本确认队列能通、/state 与 /next 返回正常，但不指望听见声音。代价是这套验证只覆盖前半段，真正的出声路径仍然没有测过。
二是 ECS 跑 DSH，本机浏览器扩展经隧道回连。这是唯一能真的出声的形态，但要求扩展能访问到云端的插件路由，而 v1.3.2 之后这道门只 listen 127.0.0.1，公网直连是拿不到的，必须走 SSH 隧道或反向代理。
三是放弃云上出声，改在本地跑。如果你的目的只是「让会话被念出来」，这其实是成本最低的选择——省掉隧道、省掉安全组、省掉浏览器登录态的搬运。
第二件事：把网络暴露面收回去
安全组只放 SSH（22）和真正要用的自定义端口，DSH 的 Web 端口不要对公网开。那道「本机小门」的假设就是「外面进不来」：只监听 127.0.0.1，只认 chrome-extension:// 来源，除 /where 外都要带每次启动新发的内存令牌，令牌不落盘。
要访问就开隧道，把远端回环映射到本地回环：
ssh -N -L <本地端口>:127.0.0.1:<DSH_WEB_PORT> <用户>@<ECS_IP>
隧道建好后，本机浏览器打开 127.0.0.1:<本地端口>，流量走 SSH，安全组里不需要多开任何端口。这也是唯一和「只 listen 127.0.0.1」兼容的访问方式。
第三件事：把运行环境补齐
出网只需要三个地方：chat.deepseek.com（扩展真正要访问的），以及 registry.npmjs.org、codeload.github.com（安装与更新用）。如果 VPC 没有公网出口，就得配 NAT 网关或代理，否则插件装到一半会卡在拉包。
存储放在云盘上，把 DSH 的 home 目录挂过去，「听谁」与「收藏」这类配置才不会随实例重建消失。规格走最小可行就行——瓶颈不在 CPU，在浏览器那一侧；堆核数不会让朗读更快。
四个真会挡路的坑
坑一 · 安装命令抄错，包名找不到
dsh plugin --profile web add dsh-tts-bridge 报找不到包，是第一道坎。README 写着「这个插件没有发到 npm 上」，要写 github: 形式或走插件市场；但站点安装检查显示 npm 源「发布者账号已校验与本仓库一致」、周下载 4,098——两处口径不一致。别纠结：优先在插件市场搜「朗读桥」，命令行失败就退回 tarball 直链。装完重启 DSH，右下角应出现 🐳 卡片。
坑二 · 只装了插件，没装浏览器扩展
有卡片但一句话都不念：插件只排队，出声靠扩展驱动页面。打开 chrome://extensions（Edge 用 edge://extensions），开开发者模式，「加载已解压的扩展程序」指向安装目录里的 extension/，再登录 chat.deepseek.com。用时页面要一直开着。
坑三 · 桌面宿主 403，扩展取不到队列
/state、/next 全 403，卡片能开但不朗读。DSH NEXT（2.0.19-next 起）给插件路由套了「浏览器访问」闸，普通浏览器客户端拿不到渲染进程令牌，一律 403 Browser access is disabled；插件改由宿主在问路端口 19387 / 39871 / 39872 另开本机小门。解法：升到 1.3.2+，重启 DSH，扩展点 ⟳ 重载，再刷新页面——两半都得更新。
坑四 · 被自己的「检查更新」劝去降级
一分钟内提示好几个「最新版本」，甚至比本机还旧。v1.3.3 之前是「哪个地址先返回用哪个」，GitHub 一超时就落到带 CDN 缓存的 jsDelivr，会滞后好几天。升到 1.3.3+ 后三源全查、取最大者；仍倒挂就以 npm view dsh-tts-bridge version 为准，别按提示降级。
总结
朗读桥在 ECS 上真正要改的不是参数，而是预期——云上负责排队，出声留在本机；想对照同类插件的中文清单与安装形态，可以看 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：想验证队列与扩展通信链路、不指望云端出声的联调；DSH 跑在 ECS、浏览器留在家用机、愿意用 SSH 隧道回连的人；需要把 DSH 常驻在云端、只在需要时接上本机浏览器的场景；给团队做「云端排队 + 本地播放」方案的可行性验证。
不适合：根本不在本机用 DSH 的人，这套两半结构对你没有意义；只用 Firefox 的人，扩展机制不同，得另写一版；不想一直开着 DeepSeek 页面、或者指望「服务器装完就自动念」的人，页面一关就不出声。
标签：朗读桥、DeepSeek Harness、TTS、阿里云 ECS
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
