决定一个第三方 YouTube 客户端生死的，不再是它内置了多少花哨的功能，而是它能不能在一场毫秒级的服务器对话中证明自己不是脚本。2026 年 9 月 26 日，NewPipe 的硬分叉项目 PipePipe 发布了 v5.4.0 版本。社区起初还在争论它为什么要分家，但 PipePipe 维护者公开的 SABR 与 BotGuard 协议文档揭示了一个更冰冷的现实：YouTube 已经重写了数据投递规则。
绕过广告引发硬分叉
PipePipe 作者在 2022 年选择硬分叉 NewPipe，主要原因是开发理念的差异。主项目 NewPipe 拒绝集成 SponsorBlock，认为屏蔽赞助商片段会让自己从隐私友好工具变成广告守门人。而 PipePipe 不仅加入了 SponsorBlock，还增加了 ReturnYouTubeDislike、弹幕聊天和全列表下载等功能。
图：PipePipe 应用主界面与浏览视图。来源：PipePipe 仓库 fastlane 元数据
社区在这个问题上分化成了两派。一派认为 NewPipe 既然已经绕过了原生广告，对赞助片段设底线存在立场不一致；另一派则指出，既要屏蔽赞助又不想监视用户，技术上存在两难。**功能层面的路线之争虽然激烈，但最终卡住所有客户端的是底层协议的变更。**就在社区争论哪个客户端更好用时，PipePipe 仓库里堆积了大量「视频随机无法播放」的工单。
解析一条 URL 播不了视频
这些播放失败源自 YouTube 切断了旧的投递通道。以前的播放过程是无状态的：客户端向服务器发送请求，解析出一个包含真实媒体流的 URL，然后直接拉取数据。现在，YouTube 把越来越多的视频迁移到了 SABR（Server Adaptive BitRate）协议。
图：SABR 投递流程，客户端与服务器通过 UMP 块持续交互。来源：PipePipe Wiki
在 SABR 机制下，播放变成了一场持续对话。客户端开启会话并上报播放状态，服务器以 UMP（Universal Media Packet）格式返回小片段。这些片段里既有音视频数据，也有给下一次请求的指令。没有了明文 URL，旧的提取模型在 SABR 面前唯一诚实的回答只能是「不支持」。
虚拟机把防线埋进运行时
想要开启 SABR 会话并获取受保护的流，客户端必须出示有效的 Proof of Origin 令牌。这是整个取证链条里最坚固的一环。YouTube 部署了四重防御的 BotGuard 系统：浏览器加载的是一个小巧的解释器。
图：BotGuard 的分层结构：解释器、加密字节码与自建虚拟机。来源：PipePipe Wiki
程序本体以加密形式携带，边运行边解密成自有虚拟机的字节码。每次运行都会重新生成内部名称，上一轮找到的断点到了下一轮就对不上位置。快照中还混入了对运行时代码的度量，打补丁或挂钩子会导致快照改变并被服务器拒收。静态分析在这里失去作用，这套防伪系统直接和动态运行时以及浏览器环境细节绑在了一起。
签名密钥永远留在了服务器
整个认证流程是串联的。客户端先获取 attestation challenge，在 BotGuard 虚拟机里跑出快照。快照发给谷歌的 GenerateIT 端点验证，换取有效期约 12 小时的 integrity token。最后，客户端用它为具体视频签发 Proof of Origin 令牌。
图：从 challenge 到 Proof of Origin 令牌的完整认证链路。来源：PipePipe Wiki
无论第三方开发者把协议解析得多么透彻，签发令牌的密钥按设计永远只存在于谷歌的服务器上。集成方唯一的出路是在真实的 WebView 或 JavaScript 运行时中执行挑战代码，然后向官方服务器请求一个令牌。YouTube 把播放改造成了持续自证身份的会话，把竞争焦点从功能堆叠拉回了协议生存战。
PipePipe 的硬分叉确实给了用户绕开 SponsorBlock 争议的选项。但在服务器端掌控着密钥与虚拟机的现实面前，第三方客户端的生存方式已经被重写。只要签发令牌的权力还在对方手里，这场协议级追赶的终点就永远由官方画定。
参考链接：
- PipePipe GitHub 仓库
- PipePipe 开发者文档：Introduction / SABR Origins / BotGuard / Attestation
- NewPipe 官方博客：NewPipe’s position on advertising
- Hacker News 讨论
