Manifest V3 对代理扩展的影响：Vinea 是如何适配的

2024 年 6 月起，Chrome 强制所有新扩展基于 Manifest V3，2025 年中开始逐步淘汰 MV2 扩展。MV3 不是小版本升级，它改了扩展的运行模型、API 和权限体系。对代理扩展来说，影响尤其深远——很多老牌扩展（如 SwitchyOmega 的某些功能、基于 webRequest 的广告拦截器）在 MV3 下要么不能工作，要么功能缩水。

本文解析 MV3 对代理扩展的具体影响，以及 Vinea 如何在 MV3 下完整保留智能分流能力。

MV3 的关键变化

1. Service Worker 替代 Background Page

MV2 的 background page 是持续运行的页面，扩展可以一直保持状态。MV3 改用 Service Worker，它是事件驱动的——只有在外部事件触发时才唤醒，闲置 30 秒后休眠。

对代理扩展的影响： 不能再依赖持续运行的后台进程做实时监控。Vinea 的设计是"配置者而非中间人"——规则设好后由浏览器内核处理，不需要后台进程持续介入，天然适配 MV3。

2. declarativeNetRequest 替代 webRequest（阻塞式）

MV2 的 webRequest.onBeforeRequest 可以阻塞请求、改写 URL。MV3 改用 declarativeNetRequest，要求规则预先声明，不能动态阻塞。

对代理扩展的影响： 基于阻塞式 webRequest 做流量改写的扩展在 MV3 下失效。但代理扩展用的是 chrome.proxy.settings API，不是 webRequest——这个 API 在 MV3 下完整保留。Vinea 用 chrome.proxy.settings 设置代理服务器和 bypass list，不受影响。

3. 权限模型收紧

MV3 收紧了 <all_urls>、tabs、history 等敏感权限的审批。扩展必须声明具体权限，且最小化申请。

对代理扩展的影响： Vinea 只申请了 proxy、storage、activeTab、webRequest（407 认证）、identity、contextMenus、management 这 7 个权限，没有 <all_urls>、tabs、history、cookies。详见安全与隐私机制。

chrome.proxy.settings API 在 MV3 的状态

chrome.proxy.settings 是 Chrome 长期稳定的 API，在 MV2 和 MV3 都可用。它接受：

• value.mode：direct、auto_detect、pac_script、fixed_servers、system
• value.pacScript.data：PAC 脚本内容
• value.bypassList：不走代理的域名列表

Vinea 用 pac_script 模式，把智能分流规则编译成 PAC 脚本交给浏览器。这样：

• 浏览器内核处理实际路由（快）
• 扩展本身不经手流量（隐私安全）
• Service Worker 休眠后规则仍生效（稳定）

Vinea 的 MV3 适配

Vinea 从设计之初就基于 MV3，没有 MV2 历史包袱。具体适配：

| 维度 | MV2 做法 | Vinea 的 MV3 做法 | |------|---------|------------------| | 后台 | 持续 background page | 事件驱动 Service Worker，只在用户操作时唤醒 | | 规则 | 实时 webRequest 拦截 | chrome.proxy.settings + PAC 脚本，浏览器内核路由 | | 权限 | <all_urls> 常见 | 只申请 7 个具体权限，无全站访问 | | 407 认证 | webRequest 阻塞处理 | webRequest 异步处理（MV3 允许 407 认证的非阻塞用法） | | 域名规则 | 后台进程实时匹配 | PAC 脚本预编译，浏览器内核匹配 |

MV3 下代理扩展的能力边界

MV3 下代理扩展能做：

• ✅ 设置代理服务器（chrome.proxy.settings）
• ✅ 域名级分流（PAC 脚本 bypass list）
• ✅ 407 代理认证（webRequest 异步）
• ✅ 自定义规则管理（storage）

MV3 下代理扩展不能做：

• ❌ 阻塞式拦截请求（declarativeNetRequest 有限支持）
• ❌ 实时改写请求头（需 declarativeNetRequest 规则）
• ❌ 持续后台监控（Service Worker 休眠）

Vinea 的设计刚好在"能做"范围内——它不拦截、不监控、不实时改写，只配置浏览器代理 + 域名规则。这让它在 MV3 下完整保留能力，且隐私边界更清晰。

常见问题

Manifest V3 之后，代理扩展是不是都不能用了？

不是。MV3 限制了 webRequest 阻塞式拦截，但 chrome.proxy.settings API 在 MV3 下仍然可用。Vinea 用这个 API 实现智能分流，完全兼容 MV3。

Vinea 用 Service Worker 会不会导致响应变慢？

不会。Vinea 的代理配置由浏览器内核处理，Service Worker 只在用户主动操作（切换节点、添加规则）时唤醒，平时不运行。日常浏览体验与 MV2 一致。

MV3 下还能做域名级分流吗？

能。chrome.proxy.settings 接受一个 PAC 脚本或 bypass list，Vinea 用 bypass list 实现国内外域名分流。这与 MV3 的 declarativeNetRequest 是不同的 API 路径，不受影响。

---

想了解 Vinea 的智能分流具体如何工作，可以读智能分流原理与工作方式。

Vinea 采用最小权限原则，详见Vinea 安全与隐私机制。