点开一篇 TechCrunch 的文章，读到一半总会跳出一个自动播放的视频框。很多人习惯用去广告扩展的元素选择器把它点掉，但怪事马上就来了：画面虽然消失，音频还在后台继续响，流量也在偷偷跑。针对这个痛点，技术博客 cornfieldlabs 在 2026 年 11 月 3 日公布了一套包含 5 条自定义规则 的 uBlock Origin 方案，试图从根源上按死这些播放器。这套规则切中了前端拦截的要害，但也暴露了靠手写规则对抗现代网页的局限。

视觉眼不见心不烦，后台流量照跑不误

新闻网站为了拉高视频广告展示率和页面停留时长，极其偏爱在正文里塞入内嵌播放器和浮动广告窗。TechCrunch 采用的是双层结构，正文中部嵌入 JW Player 视频，页面同时加载 Connatix 的浮动广告播放器。

蒙布仍发声的电视机与被剪断网线的电视机(示意图)
蒙布仍发声的电视机与被剪断网线的电视机(示意图)

普通读者用去广告插件把视频框点掉，触发的只是 外观过滤（Cosmetic filtering）。这种做法相当于用 CSS 选择器（比如直接写 ##video 或隐藏容器）给页面元素盖上一块遮羞布。浏览器的 DOM 树里依然挂着播放器节点，它本身不能保证媒体停止下载、后台停止运行或音频彻底切断。

网页视频拦截的两条底层路径对比 仅用外观过滤（## 规则） 作用阶段：DOM 渲染层 核心动作：CSS 隐藏页面容器 播放器脚本：照常加载执行 后果：后台继续偷跑流量与发声 网络过滤 + 外观清理（原文方案） 作用阶段：网络请求发出阶段 核心动作：阻断 JW 与 Connatix 脚本 善后处理：配合 ## 规则抹平空白框 代价：主动想看的正常视频也彻底瘫痪

要想真正掐断声音，必须在请求发出阶段动用 网络过滤（Network filtering）。cornfieldlabs 给出的前三条规则，正是直接阻断 content.jwplatform.com/libraries/ 和 ssl.p.jwpcdn.com 的脚本请求，并拦截 connatix.com 的第三方请求。脚本一旦断供，播放器就根本无法初始化。最后再补上针对 .wp-block-techcrunch-jw-player-embed 和 .jw-player-inline-promo 的两条外观规则，把留在正文里的空白占位框抹平。

Code
! TechCrunch: stop the autoplaying JW Player video
||content.jwplatform.com/libraries/$script,domain=techcrunch.com
||ssl.p.jwpcdn.com^$script,domain=techcrunch.com
||connatix.com^$third-party,domain=techcrunch.com
techcrunch.com##.wp-block-techcrunch-jw-player-embed
techcrunch.com##.jw-player-inline-promo

这套组合拳确实干净，但它属于典型的焦土政策。

杀敌一千自损八百，不如启用底层通用阀门

我不完全买账这种手写域名封杀的思路，原因在于它的脆弱与一刀切。一旦读者遇到某篇报道里确实有值得看的产品演示视频，被掐死脚本的页面根本无法点播；而且只要 TechCrunch 哪天更换了视频技术供应商，外观规则或许还能继续藏住空白框，但网络拦截规则瞬间就会失效，后台声音照样卷土重来。

调高媒体阈值并开启胶片开关，放行高清大图的同时卡住自动播放流媒体(剖面示意)
调高媒体阈值并开启胶片开关，放行高清大图的同时卡住自动播放流媒体(剖面示意)

古人讲，扬汤止沸，不如釜底抽薪。与其跟各个网站的第三方脚本打游击，不如直接收回浏览器的播放控制权。

很多人纳闷，明明在浏览器里开了自动播放拦截，为什么新闻网站的视频还在画面里跳动？症结在于 静音自动播放 机制。以 Firefox 为例，它原生的默认设置是仅阻止音频（Block Audio），对静音状态下的视频自动播放完全放行。用户只需要去 Firefox 设置里把选项改成 阻止音频和视频（Block Audio and Video），就能在不破坏页面组件的前提下按住静音视频。

如果觉得浏览器全局设置不够精细，uBlock Origin 官方文档其实早就藏着一把更优雅的手术刀。在扩展面板里有一个按站点设置的 禁大媒体元素（No large media elements，显示为一个胶片图标）开关。这个功能名字起得有些保守，它除了拦截大体积媒体，底层逻辑是直接阻止任何大小（甚至包括通过 XHR 流式传输）的音视频自动播放。

  • 建议.在 uBlock Origin 中开启胶片图标开关，同时在设置里把媒体大小阈值调得非常高；这样既能放行所有正常的大尺寸高清图片，又能精准废掉跨网站的自动播放流媒体，且完全保留用户主动点击播放的权利。

早在 2024 年 10 月 14 日至 15 日，Reddit 的 r/uBlockOrigin 社区讨论如何拦截新闻网站自动播放视频时，资深用户推崇的正是这套胶片开关配高阈值的通用解法，根本不需要针对单个媒体站点去扒前端代码。

MV3 时代的真假边界与三级防御

cornfieldlabs 在文末特意叮嘱，那 5 条规则只适用于 Firefox 上的完整版 MV2 uBlock Origin，不适用于 uBO Lite。这个判断放在两年前或许成立，但放在今天已经过时了。

应对自动播放视频的浏览器设置、扩展媒体开关与手写规则三级防线(示意图)
应对自动播放视频的浏览器设置、扩展媒体开关与手写规则三级防线(示意图)

uBlock Origin Lite 分为 Basic（仅网络过滤）、Optimal（默认模式，增加特定站点外观和 scriptlet 过滤）以及 Complete（启用通用外观过滤）三种模式。更重要的是，uBO Lite 已经在 2026 年 6 月 正式新增了对自定义过滤规则和外部过滤列表订阅的支持。像原文这种基础的特定域名网络阻断加站点 CSS 隐藏，在默认的 Optimal 模式下完全可以跑通，并非与 Lite 绝缘。

真正拉开完整版与 Lite 差距的，是按站点的媒体接管能力。

在浏览器扩展从 Manifest V2 向 Manifest V3 迁移的震荡期，两款工具的真正代差在于底层 API。uBO Lite 依赖浏览器提供的 declarativeNetRequest 引擎来执行声明式规则，受限于这个接口的能力边界，它无法复现完整版 uBO 那个极其好用的胶片图标开关。而 Firefox 之所以依然是高级内容拦截的大本营，是因为 Mozilla 选择继续同时支持 MV2 和 MV3，并且在自家的 MV3 实现里坚持保留了阻塞式的 webRequest API。

反自动播放视频的三级防御阶梯 第一层：浏览器原生拦截（Firefox 改为 Block Audio and Video） 零扩展负担，直接堵死默认放行的静音视频自动播放漏洞 第二层：uBO 胶片开关 + 高体积阈值（最推荐的通用解） 连根拦截 XHR 流媒体自动播放，不伤大图，保留主动点播权（仅限完整版 uBO） 第三层：手写网络阻断 + 外观规则（针对顽固站点的核武器） 直接掐断第三方播放器脚本，uBO Lite（2026 年 6 月后）同样可用，但丧失点播能力

看清了这一层技术底牌，普通读者对付网页流氓视频的防御策略就非常清晰了。首选修改浏览器原生的音视频拦截设置；如果用着完整版 uBO，直接打开胶片开关配高阈值就能一劳永逸；只有当你被困在不支持胶片开关的 MV3 环境里，或者遇到连播放器外框都不想看见的极端场景，才需要掏出那 5 条规则，去跟 JW Player 和 Connatix 的脚本做个了断。

  • 风险.随着第三方广告和视频域名成为拦截规则的公开标靶，主流内容出版商接下来很可能会更多转向第一方域名代理或混淆 XHR 流媒体，届时靠手写第三方域名黑名单的路子只会越走越窄。