【网络优化】减少B站直播卡顿的上行占用：AdGuard nowebrtc规则 / WebRTC Control 实测

前言

最近在看 B 站直播时，我发现电脑的网络占用有时比较高，打游戏时也会遇到延迟升高的情况。即使没有主动上传文件，电脑仍然可能存在较明显的上行流量。

查找原因时，我开始关注 B 站网页端直播是否使用了 P2P（点对点）技术。部分 P2P 内容分发方案会让用户设备参与数据传输，因此可能产生额外的上行流量。不过，网络发送速率偏高也可能来自其他软件或后台任务，不能仅凭这一现象就确定流量来源。

为了验证这个问题，我尝试使用 AdGuard 的 nowebrtc 规则和 WebRTC Control 浏览器扩展，限制网页使用 WebRTC 相关接口，再对比拦截前后的控制台表现与网络占用变化。

本文主要记录这两种方法的配置过程、控制台验证方式，以及我在实际测试中观察到的结果。

技术原理

WebRTC 是一套支持浏览器实时通信的技术，其中的 RTCPeerConnection 接口用于建立和管理点对点连接。

如果网页中的 P2P 组件依赖 WebRTC 建立连接，那么限制相关接口就可能导致该组件无法正常工作，进而影响它产生的网络流量。

简单来说，部分网页应用可以通过 WebRTC 建立点对点连接。在内容分发场景中，如果采用这种机制，用户设备可能参与数据传输，而不只是接收服务器发送的内容。

不过，WebRTC 不等于 P2P，P2P 也不一定依赖 WebRTC。目前不能仅凭网络占用变化就认定 B 站所有直播间都使用同一种传输机制，也不能断言禁用 WebRTC 后所有 P2P 流量都会被阻断。

因此，这次测试的思路是：限制网页使用 WebRTC 相关接口，再观察接口状态和网络占用是否发生变化。

方法一：AdGuard 用户过滤器

打开 AdGuard 设置，进入支持自定义规则的过滤器区域，添加以下规则：

live.bilibili.com##+js(nowebrtc)

这条规则使用 AdGuard 原生 scriptlet 语法，针对 B 站直播域名注入 nowebrtc 脚本，以限制网页使用相关 WebRTC 功能。

如果希望同时覆盖 B 站主站及其子域名，可以尝试：

bilibili.com##+js(nowebrtc)

具体匹配范围和生效情况取决于规则引擎及 AdGuard 版本。添加规则后，建议刷新直播页面，再进行验证。

另外，以下是AdGuard原生 scriptlet 语法：

live.bilibili.com#%#//scriptlet('nowebrtc')
bilibili.com#%#//scriptlet('nowebrtc')

规则语法说明：

本文实际使用的是 bilibili.com##+js(nowebrtc)，属于 uBlock Origin 风格的 scriptlet 语法。部分 AdGuard 产品和版本支持该写法，具体取决于过滤规则引擎。

由于本文已通过控制台对比观察到 RTCPeerConnection 返回结果发生变化，因此保留实际测试成功的配置，不再额外更换规则语法。

方法二：WebRTC Control 插件

在 Chrome、Edge 或 Firefox 的扩展商店中搜索 WebRTC Control，确认扩展来源及实际支持的浏览器后安装。

基本使用方法：

• 点击浏览器工具栏中的扩展图标。

• 根据扩展当前的图标状态及说明，确认 WebRTC 控制功能是否启用。

• 打开或刷新 B 站直播页面，再检查效果。

WebRTC Control 会限制部分 WebRTC 相关 API。项目说明中涉及的接口包括：

• navigator.getUserMedia

• window.MediaStreamTrack

• window.RTCPeerConnection

• window.RTCSessionDescription

具体实现和不同版本的行为可能存在差异。限制这些接口后，依赖它们的网页功能可能受到影响，但不能据此断言所有 P2P 连接都会被阻断。

需要注意，全局禁用 WebRTC 可能影响其他网站的视频会议、网页通话或屏幕共享等功能。如果这些功能无法正常使用，可以关闭扩展或调整相关设置。

验证效果

控制台验证

在 B 站直播页面按 F12 打开开发者工具，切换到 Console（控制台），输入：

new window.RTCPeerConnection()

对比拦截前后的返回结果：

拦截前： 返回正常的 RTCPeerConnection 对象，可以看到 localDescription、remoteDescription 等相关属性。

拦截后： 返回 rtcReplacement {}，表明相关接口很可能已被脚本替换。

这一变化与 WebRTC 接口被替换或限制的表现相符，可以作为拦截生效的辅助证据。但它不能单独证明所有 WebRTC 功能或 P2P 连接均已停止，具体效果仍需结合实际测试判断。

如果控制台结果与预期不符，可以先确认规则语法、扩展状态以及页面是否已经刷新。

网络占用实测

为了观察限制 WebRTC 相关功能后的网络变化，我在同一直播间【环境：400+人数，1080原画（高帧率）】进行了前后对比。以下为 Windows 任务管理器中 Wi-Fi 网卡的性能截图。

拦截前	拦截后

图注：左图为拦截前，右图为拦截后。截图中的发送速率由约 11.3 Mbps 降至约 88 Kbps。

从本次截图来看，网卡发送速率出现了明显下降，发送速率的虚线几乎消失了，而接收速率仍处于相近的水平。按截图读数计算，发送速率下降约 99.2%。

这说明本次测试中，上行发送活动明显减少。不过，数据反映的是整个 Wi-Fi 网卡的网络活动，并非 B 站直播单独产生的流量。因此，目前还不能将全部变化直接归因于 B 站 P2P，也不能保证其他直播间会出现相同结果。

禁用后对正常观看直播有影响吗？

在本次测试中，禁用相关功能后，直播播放基本正常，且我本人体验明显改善。

一般来说，网页直播的视频播放、弹幕和互动功能可能分别依赖不同的传输机制，并不一定全部依赖 WebRTC。因此，限制 WebRTC 后，部分直播功能仍然可能正常运行。

实际效果仍取决于播放器的实现方式和具体直播间，不能保证所有场景都不受影响。如果遇到视频无法播放、互动异常或其他网页功能故障，可以关闭相关规则或扩展，刷新页面后重新测试。

另外，直播播放仍然正常，并不代表 P2P 功能一定完全停止；同样，网络占用下降也不等于所有下降的流量都来自 P2P。

两种方案对比

对比项	AdGuard nowebrtc	WebRTC Control
实现方式	通过过滤规则注入脚本	通过浏览器扩展限制相关接口
作用范围	可按域名配置	通常影响较广，具体取决于扩展设置
配置难度	需要添加规则	安装后通过扩展界面控制
适合人群	已使用 AdGuard，希望精确控制网站范围的用户	希望通过浏览器扩展快速测试的用户
对其他网站的影响	可通过域名规则缩小影响范围	可能影响其他依赖 WebRTC 的网站
恢复方式	删除或停用规则并刷新页面	关闭扩展或调整设置并刷新页面

如果已经在使用 AdGuard，可以先尝试添加 nowebrtc 规则，不必额外安装扩展。

如果不熟悉过滤规则，也可以使用 WebRTC Control 进行测试，但需要留意其他网站的视频通话、会议和屏幕共享功能是否受到影响。

注意事项

1. 配置完成后刷新页面。 如果直播页面在启用规则或扩展之前就已经加载，已有的连接可能不会立即受到影响。可以使用Ctrl + F5强制刷新后再测试。

2. 区分发送速率与总网络占用。 任务管理器中的 Wi-Fi 性能页面会分别显示发送和接收速率；其他位置显示的网络占用可能是总量，不能直接混用。

3. 确认 AdGuard 规则语法。 本文使用的是 AdGuard 原生 scriptlet 写法。不同产品、版本和规则引擎的兼容情况可能不同，不能认为所有过滤工具都支持同一种语法。

4. 正确理解控制台结果。 new window.RTCPeerConnection() 可以辅助判断接口是否受到限制，但不能单独证明所有 P2P 连接都已停止。

5. 测试结论以实际环境为准。 网络发送速率会随时间波动，其他应用也可能产生上行流量。单次截图只能说明当时观察到的现象，不能保证所有设备和直播间都有相同结果。

总结

这次尝试使用 AdGuard 的 nowebrtc 规则和 WebRTC Control 浏览器扩展，观察限制 WebRTC 相关接口后，B 站直播期间的网络活动是否发生变化。

在本次测试中，网卡发送速率从约 11.3 Mbps 降至约 88 Kbps，下降约 99.2%，而接收速率没有同步下降。这是一个值得进一步验证的现象，但由于数据来自整个 Wi-Fi 网卡，目前还不能将全部变化直接归因于 B 站 P2P。

两种方案都可以作为排查 WebRTC 相关网络活动的尝试。建议优先选择作用范围清晰、便于恢复的配置，并在实际使用中确认直播播放及其他网页功能是否受到影响。

如果你也遇到 B 站直播期间上行发送速率异常偏高的情况，可以尝试上述方法，再结合自己的实际测试结果判断是否有效。