Discord用户花3个月自建语音服务器，发现隐私漏洞比想象中狠

全球每月有1.5亿人在Discord上开黑。你的每一次战术沟通、每一次吐槽队友、每一次约饭时间，全部躺在别人的硬盘里。开发者Shynsec用了这个服务五年，某天突然算了一笔账：五年，几千小时语音，零加密掌控权。于是他花了三个月，造了一个叫Squawk的替代品。

核心逻辑粗暴直接：自己的服务器，自己的网络，自己的数据。不需要注册账号，不需要同意隐私条款，连Discord的"我们可能收集"都不用看。

但这篇文章不是安利你卸载Discord。真正有意思的是他踩过的坑——那些你以为"自建=安全"就能自动解决的漏洞，以及WebRTC这个黑箱里藏着的信号劫持风险。

从"能用就行"到"必须自己造"

Shynsec的团队不大，固定开黑的就那么几个人。Discord确实稳定，语音质量过得去，手机电脑无缝切换。问题出在"过得去"这三个字上。

他开始注意到一些细节：语音频道里的闲聊会被推荐算法拿去训练吗？聊天记录的保留期限到底是多久？那些"已删除"的消息真的消失了吗？Discord的隐私政策写得像迷宫，而他已经厌倦了在迷宫里找答案。

Mumble和TeamSpeak确实存在，都是老牌开源方案。但Mumble的界面停留在2010年代，手机端体验堪称灾难；TeamSpeak的授权模式复杂，朋友还得走一遍注册流程。Shynsec想要的是2024年的交互体验，加上1990年代的隐私模型——数据不出家门。

技术选型上，他选了WebRTC做音频传输，Socket.io做信令层，Tailscale解决内网穿透。这套组合不算激进，但每个选择都埋着雷。

WebRTC的"甜蜜陷阱"

浏览器提供的WebRTC API文档齐全，Demo跑通只需要几十行代码。创建点对点连接、交换SDP描述、添加ICE候选——这套"幸福路径"确实顺畅。

但Shynsec很快撞上了信令层的暗礁。WebRTC只负责把音频包送到对端，不管你们是怎么找到彼此的。这个"找人的过程"需要第三方服务器介入，也就是信令服务器。他用Socket.io实现，代码简洁，直到一个安全疑问浮现：

如果客户端A在房间1，客户端B在房间2，什么阻止A把WebRTC信号转发给B？

答案是：默认情况下，什么都没有。

Socket.io的广播机制不验证房间边界。恶意用户（或只是出bug的代码）可以把语音流重定向到任意房间，实现跨房间窃听。Shynsec的修复方案是在中继任何offer、answer或ICE候选之前，强制校验发送方和接收方是否处于同一房间。逻辑简单，但"容易遗漏"——他承认这个漏洞是事后审计才发现的，而非设计之初就规避。

这引出一个反直觉的结论：自建服务器不等于自动安全。Tailscale把攻击面缩小到"只有受邀用户能连接"，但内部威胁依然存在。你可能邀请了朋友的朋友，可能某天想对外开放部分功能，可能只是想养成好习惯。威胁模型会变，代码里的漏洞不会自己消失。

那些"计划外"的安全加固

Squawk的权限系统极简：建频道的人拥有它，能踢人、改名、删除。没有角色体系，没有细粒度权限，没有Discord那种"管理员-版主-普通成员"的层级。Shynsec认为这是功能而非缺陷——小团体不需要官僚结构。

但简单不意味着粗糙。他最终实现的防护清单包括：

• 信令层的房间隔离校验（前面提到的）

• 连接来源验证，防止Tailscale网络外的意外访问

• 频道所有权的不可转让设计，避免权限混乱

• 无账号体系带来的身份伪造风险对冲——通过Tailscale的节点身份绑定

每一项都不复杂，但"想清楚需要覆盖哪些表面"比写代码更耗时间。Shynsec的原话是："我以为是周末项目，结果花了三个月。"

移动端支持是另一个隐形工作量。WebRTC在桌面浏览器里成熟稳定，到了手机端就是另一套故事。iOS的WKWebView（网页视图）对WebRTC的支持滞后数年，Android的碎片化让测试矩阵爆炸。Squawk最终选择了渐进增强策略：核心语音功能优先保证，高级特性桌面先行。

自建的成本真相

开源项目页面上，Squawk的部署说明写着"一行Docker命令"。但Shynsec在文章里坦承了隐性成本：

Tailscale需要每个参与者安装客户端，这对技术圈朋友是小事，对非技术背景的人可能是门槛。服务器需要持续运行，电费、维护、备份都是你的责任。没有Discord的24/7运维团队，凌晨三点语音中断时，排查问题的人是你。

他算过一笔账：五人小团体，年均Discord Nitro订阅费约300美元。自建方案的硬件折旧加电费可能更低，但时间成本无法量化。"如果你享受这个过程，它是爱好；如果你只想要结果，它是负担。"

数据控制权的代价是责任转移。Discord丢失你的聊天记录，你可以发推文骂它；你自己丢失数据，只能对着镜子骂自己。

但Shynsec认为这个交换值得。他的核心论据不是技术性的，而是关系性的：当五个朋友的数据只存在于五个朋友的设备上时，信任链条变得透明可控。没有第三方平台的"我们可能分享数据给合作伙伴"，没有算法推荐可能误读你的玩笑，没有某天突然出现的"更新后的服务条款"。

开源社区的反馈循环

项目发布两周内，GitHub仓库收到47个issue，其中12个是功能请求，8个是安全建议，3个是部署问题。一位用户提交了iOS PWA（渐进式网页应用）的适配补丁，让移动端体验提升了一个档次。

但也有冷遇。Hacker News上的讨论帖最高赞评论是："我为朋友做了类似的东西，六个月后没人用了——维护负担太重，大家回流Discord。"Shynsec的回复很直接："这完全可能发生。Squawk不是Discord杀手，它是一个选项。有人在乎这个选项就够了。"

代码层面，他拒绝了几个PR（Pull Request，代码合并请求）。一个想加入端到端加密，但会显著增加连接延迟；一个想支持公开服务器注册，与"私有"核心理念冲突。开源项目的边界管理，和产品经理砍需求是同一门手艺。

最意外的反馈来自一位企业安全工程师。对方把Squawk的架构文档拿去给内部团队参考，用于评估"零信任语音通信"的可行性。Shynsec的周末项目，意外成了某家公司的技术调研样本。

当"隐私优先"成为小众需求

Discord 2023年的透明度报告显示，平台处理了超过3000万次内容审核操作。这个数字可以解读为"积极治理"，也可以解读为"你的对话正在被扫描"。Shynsec选择后者。

但市场数据站在另一边。Discord月活持续增长，Mumble和TeamSpeak的用户基数停滞不前。隐私工具的历史充满类似的悖论：PGP（Pretty Good Privacy，一种加密软件）发明三十年，主流用户依然用微信发密码；Signal技术口碑极佳，装机量不及WhatsApp的零头。

Squawk的定位因此清晰：不做大众产品，服务"在乎的人"。Shynsec在README里写明了预期用户画像——"有技术背景的小团体，愿意为隐私承担额外操作成本"。这不是傲慢，是诚实。

技术债务方面，他列出了三个已知局限：没有消息持久化（断线即丢失历史），没有视频支持（WebRTC的视频编解码复杂度是音频的十倍以上），没有联邦架构（每个服务器孤岛运行）。这些可能永远不被修复，因为它们与"简单"和"私有"的设计目标存在张力。

最后一个产品细节：Squawk的默认频道名是"Lobby"，但Shynsec自己的实例改成了"Treehouse"。他在文档里没解释原因，但在某个issue回复里提到——"小时候的秘密基地不需要注册账号"。

你会为了这种"秘密基地"的感觉，放弃Discord的一键邀请链接吗？