外观
浏览器代理插件与系统代理的关系
浏览器代理插件和系统代理会冲突，但冲突的形式不是"两个都坏"，而是"浏览器只听其中一个"。插件通常优先于系统设置，一旦它指向了已经关闭或改过的端口，浏览器就会绕开你正在运行的客户端。理清优先级与接管层，是排错的关键。
核心结论与适用条件
下面几条是条件化的判断，不构成对任何插件或品牌的推荐。
- 只用一个浏览器、希望所有程序遵循同一套分流：不装插件，让浏览器跟随系统代理，规则放在客户端里。变量最少。
- 需要某个浏览器配置文件单独走另一个出口，或按站点切换：用插件，同时明确它是浏览器内的唯一分流位置。
- 同时开启系统代理、插件、TUN：可以工作，但要知道每一层谁在做规则判断，否则命中的策略很难解释。
- 浏览器打不开而其他程序正常：先怀疑插件或浏览器自身的代理设置，再怀疑节点。
- 插件的权限很高：只从官方渠道安装，定期清理不再使用的扩展。
一句话概括：浏览器是桌面上唯一拥有"自己的代理设置"的主力应用，所以它最容易与系统代理出现分歧。本文不比较具体插件，也不涉及任何版本的功能确认，只讲所有插件共通的原理。桌面客户端的整体选择见桌面代理客户端专题。
三个设置层：谁在告诉浏览器该走哪里
浏览器决定一个请求走代理还是直连，依据的是三个可能同时存在的设置层。
第一层是系统代理设置。客户端开启"系统代理"后，会把本地端口写入操作系统的网络代理配置。浏览器在默认状态下会读取这份配置，所以不装任何插件也能走代理。
第二层是浏览器自身的代理设置。多数浏览器允许选择"使用系统设置""直连"或"手动指定代理"。选择手动指定后，浏览器不再读取系统设置。
第三层是浏览器扩展。代理插件通过浏览器提供的代理接口，为请求指定出口，或根据规则在不同出口之间选择。扩展设置的优先级通常高于浏览器的默认设置，所以一旦扩展接管，前两层就被覆盖。
三层并存时的实际行为，可以用一个简单的口诀记：越靠近浏览器的设置，优先级越高。插件覆盖浏览器自身设置，浏览器自身设置覆盖系统设置。所以当你"明明开了系统代理却没效果"，答案往往藏在更上层。
不同系统和浏览器的具体行为有细微差别，本文不展开到版本和菜单路径，只讲通用关系。在设置中找到与代理或网络相关的选项，确认当前是"跟随系统"还是"手动"，这是第一步。
冲突的五种典型形态
把冲突场景分类，比记住一堆现象更有用。
形态一：端口残留
客户端退出或重启后，本地端口无人监听，而插件或浏览器设置仍指向它。浏览器表现为"代理服务器拒绝连接"。这是最常见的一种，也是最容易修复的：把插件切换到直连或跟随系统即可。
形态二：端口不一致
客户端换了监听端口，或同一台机器上运行了两个客户端，插件还指着旧端口。表现与形态一相似，但检查端口时会发现另一个端口上确有进程。修复是让插件与客户端的端口一致，或统一让两者都跟随系统设置。
形态三：规则分歧
插件里有一套按站点分流的规则，客户端里又有一套。浏览器请求先被插件判断，命中"走代理"后交给本地端口，客户端再用自己的规则判断一次，可能决定直连。结果是"插件说走代理，客户端说直连"，最终出口不是你想的那个。修复是只保留一处作为主要分流位置。关于客户端规则、全局与直连的使用时机，见规则、全局与直连三种出站模式。
形态四：TUN 叠加
开启 TUN 后，系统层面的流量被虚拟网卡接管；此时浏览器如果还通过插件把请求交给本地端口，同一批流量会经历插件规则、本地端口规则、TUN 层判断多层关系。它不会简单变成"双倍代理"，但命中的策略难以追溯。TUN 的原理与适用场景见TUN 模式与系统代理的区别。
形态五：配置文件各自为政
浏览器可以有多个用户配置文件，每个配置文件的扩展与设置通常独立保存。你在一个配置文件里修好了，另一个配置文件仍然是旧设置。表现为"同一台电脑上，这个浏览器窗口能用，那个不能"。修复是逐个配置文件检查，而不是假定同步。
插件到底做了什么：从请求到出口的路径
理解插件的工作方式，有助于判断问题出在哪里。一个典型的流程是：浏览器发起请求，插件根据当前模式和规则判断这个地址应该直连还是走代理，如果走代理，则把请求交给设定的代理地址，通常是本机内核监听的本地端口，内核再按自己的规则与策略组转发到节点。
所以插件并不是一个"代理"，而是一个浏览器内的"路由选择器"。真正做加密转发的是内核和节点。这也解释了为什么插件无法单独让你上网：它需要一个后端。后端是你本机运行的客户端，客户端没有运行，插件再怎么配置也没有用。
插件常见的几种模式：直连（不代理）、全部走代理、按规则自动切换、跟随系统。按规则自动切换往往基于一个规则列表，决定哪些域名走代理；列表的来源可以是插件自带、手动维护或订阅的在线列表。在线列表需要更新，更新失败时规则可能过期，这与客户端的订阅更新失败是两件事。后者见订阅更新失败的排查。
PAC 与规则列表：同一思想的两种形态
PAC 是一种由脚本决定每个地址使用哪个代理或直连的配置方式。许多插件的规则列表，本质上做的是类似的判断：给定地址，返回"代理""直连"或"另一个代理"。系统代理设置里也可以指定 PAC 地址，让所有读取该设置的程序使用同一套判断。
PAC 与客户端规则的区别在于判断发生的位置。PAC 发生在请求发出之前，决定请求交给谁；客户端规则发生在请求到达内核之后，决定请求从哪个节点出去。两处都做分流，并不一定冲突，但你需要清楚它们是"先后两道关"，不是"一道关的两把钥匙"。
对一般用户，我们的建议是：分流规则只放在一处。放在客户端更通用，覆盖所有程序；放在插件更灵活，只影响浏览器。放在两处的唯一好处，是应对非常特殊的需求，但代价是排错时你必须同时读两套规则。客户端规则的具体写法见Clash 配置文件的结构。
技术参数对比大表
下表对比三类接管方式在浏览器场景下的特征。内容来自通用技术资料，不涉及具体版本，也不给出速度、延迟数值；实测状态统一为 Not Tested。
| 指标 | 系统代理 | 浏览器插件 | TUN 模式 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| 生效范围 | 读取系统设置的程序 | 仅安装它的浏览器配置文件 | 系统层面大部分流量 | 程序范围 | 通用机制 | 通用技术资料 | 2026-10-18 |
| 在浏览器内的优先级 | 最低 | 最高 | 在网络层之下，不经过浏览器设置 | 优先顺序 | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 是否需要额外权限 | 否 | 需要扩展权限授权 | 是（管理员 / root / 系统授权） | — | 系统机制 | 通用技术资料 | 2026-10-18 |
| 分流粒度 | 由客户端规则决定 | 可按站点、按浏览器配置文件 | 由客户端规则决定 | — | 功能形态 | 通用技术资料 | 2026-10-18 |
| 典型冲突来源 | 残留设置、其他 VPN | 端口残留、规则分歧 | 与插件和系统代理叠加 | — | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 排错入口 | 系统网络设置 | 扩展管理与扩展选项 | 路由与虚拟网卡 | — | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 对客户端运行的依赖 | 是，端口需有进程监听 | 是，同左 | 是 | — | 方案形态 | 通用技术资料 | 2026-10-18 |
| 对订阅更新的影响 | 间接 | 间接 | 间接 | — | 方案形态 | 通用技术资料 | 2026-10-18 |
| 实测稳定性 | Not Tested | Not Tested | Not Tested | — | 本站测试状态 | 本站 | 2026-10-18 |
使用这张表时的要点：第一，三种接管方式并不互斥，真正的风险是叠加后无法说清谁在生效；第二，"对客户端运行的依赖"是所有方案的共同事实——插件不是客户端的替代品。
排错顺序：从最外层开始，一次只动一个变量
遇到"浏览器打不开但别的程序正常"时，建议按下面的顺序走，每一步只做一件事。
- 确认客户端正在运行，且监听端口与预期一致。端口信息可以在客户端的设置或日志中找到。
- 暂时把浏览器插件切换为直连，或直接禁用。观察浏览器是否恢复。如果恢复，问题在插件设置；如果没有，继续。
- 检查浏览器自身的代理设置是否为"跟随系统"。如果被改成手动，确认端口是否正确。
- 检查系统代理开关是否开启，端口是否与客户端一致。残留的旧端口是常见原因。
- 如果开启了 TUN，暂时关闭 TUN，只保留系统代理，再测试。反之亦然。目标是把接管层降到只有一层。
- 在只有一层接管的情况下确认浏览器恢复正常，再依次加回其他层，每加一层测一次。
- 最后检查客户端侧：订阅是否更新成功、策略组是否指向有效节点、出站模式是否为规则模式。
这个顺序的逻辑，是从"离浏览器最近、最容易改"的一层开始，逐步向客户端和节点推进。很多用户习惯直接换节点，结果换了十几个节点问题依然存在，因为问题根本不在节点。
对 Linux 用户，浏览器设置还可能与桌面环境的代理入口、环境变量产生额外交互，见Linux 桌面代理方案。macOS 用户则需要额外留意系统代理按网络服务分别保存的特点，以及授权弹窗，见macOS 权限与授权说明。
决策树：我该不该装浏览器代理插件
Decision Path
是否需要浏览器代理插件
text
你使用几个浏览器或浏览器配置文件？
├─ 一个，且所有程序用同一套分流
│ └─ 不装插件：浏览器跟随系统代理，规则放客户端
└─ 多个，或需要不同出口
├─ 是否需要按站点、按配置文件单独分流？
│ ├─ 是 → 安装插件，并明确它是浏览器内的唯一分流位置
│ └─ 否 → 仍然不装插件
└─ 已经装了插件
├─ 插件指向本地端口？
│ ├─ 与客户端端口一致 → 继续检查客户端规则是否重复分流
│ └─ 不一致 → 改为一致，或切换为"跟随系统"
└─ 同时开启了 TUN？
├─ 是 → 先关一层，逐层加回，避免叠加
└─ 否 → 保持系统代理 + 插件
浏览器打不开而其他程序正常？
└─ 先把插件切到直连，再看浏览器自身设置，再看系统代理浏览器代理插件的安全面
插件的权限范围是被低估最严重的一块。一个能改写代理设置的扩展，通常也有能力读取或修改你访问的页面请求。因此安全方面有几条朴素的原则。
只从浏览器官方扩展商店或项目官方渠道安装，不要安装来源不明的离线包。安装前查看权限说明，对申请范围明显超出代理功能的扩展保持警惕。定期打开已安装扩展列表，卸载不再使用的。不要把含有订阅链接的配置导出文件随意上传或分享——订阅链接等同于账号凭据。
此外，一些插件支持"在线规则列表"。规则列表来自第三方，意味着有人能决定你的哪些请求走哪个出口。对来源不明的在线列表，应当谨慎。品牌层面的运营风险识别见风险识别与规避方法。
最后要强调：本文只讨论技术关系与使用风险，不涉及任何绕过监管或违法用途的内容。请在遵守所在地法律法规和平台条款的前提下使用任何网络工具。
与其他桌面方案的关系
浏览器插件处在桌面方案的"最上层"，它依赖下面的客户端。不同客户端方案对插件的适配程度不同：Clash 系客户端通常提供混合端口，插件可以直接指向它；v2ray 系客户端同样提供本地端口，见v2rayN 的订阅导入与内核切换；机场自研客户端可能只提供"系统代理"开关而不开放端口信息，这时插件的使用空间有限，取舍见自研客户端与第三方客户端的取舍。
想知道各款桌面客户端在内核、协议、规则可编辑程度上的差异，可以看桌面客户端横向对照。手机浏览器没有桌面意义上的插件体系，手机端的方案在移动与路由器专题中说明。
知识图谱：浏览器代理插件
实体定义
浏览器代理插件，是运行在浏览器内、通过浏览器的代理接口为请求选择出口的扩展，本身不做加密转发，需要依赖本机代理内核或远端代理服务作为后端。
相关概念
上位概念是桌面代理客户端与机场客户端总览；平行概念是系统代理、TUN 模式、环境变量；依赖概念是代理协议；内部概念包括代理模式、规则列表、PAC、浏览器配置文件、扩展权限。协议相关的背景见代理协议的分类与安全机制。
技术参数
可观察的参数包括：插件当前模式、插件指向的地址与端口、系统代理开关与端口、客户端监听端口、规则列表的更新状态。这些都能在本机自行查看。品牌节点的延迟与速度，本站为 Not Tested，测量方法见测试方法与数据口径。
适用场景
单浏览器日常使用：不装插件。多浏览器配置文件分别使用不同出口：装插件。按站点分流且只影响浏览器：装插件。需要接管非浏览器程序：用系统代理或 TUN，而不是插件。
对比依据
比较接管方式时看四项：生效范围、优先级、权限要求、排错透明度。比较品牌时的维度框架见横向对比方法。
常见问题指向
"哪一个生效"指向三个设置层；"关了客户端还打不开"指向冲突形态一；"规则怎么放"指向 PAC 与规则列表；"安全吗"指向安全面章节。
方案关联：插件使用依赖客户端提供的端口
插件本身与品牌无关，但它能否使用，取决于你的客户端是否提供可指向的本地端口。品牌资料中的客户端字段可以帮助判断。下表只引用 brands.json 的字段，状态均为 Vendor Data。
| 客户端支持类别 | 品牌数 | 对插件使用的含义 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| 标注自研客户端 | 10 | 是否开放端口信息待核实，需看具体客户端 | Vendor Data | 2026-10-18 |
| 仅第三方订阅导入 | 6 | 使用第三方客户端，通常可自行查看监听端口 | Vendor Data | 2026-10-18 |
| 按官方订阅格式选择客户端 | 1 | 取决于所选客户端 | Vendor Data | 2026-10-18 |
下面的快照是一个"自研客户端+第三方订阅导入"的样本，用来对照上表字段的含义。它说明的是客户端支持方式，不代表该品牌的客户端是否开放本地端口，也不构成推荐。
Infrastructure Service Snapshot
U1S1 /u1s1
- 入门价格
- 20 元/月
- 价格类型
- 月付 月付价
- 入门流量
- 120GB
- 线路
- IEPL专线
- 协议
- VLESS
- 运营年份
- 2023
- 客户端
- 自研客户端+第三方订阅导入
- 支付方式
- 支付宝 / 微信 / USDT
如果你想按客户端支持方式筛选品牌，可以进入品牌库查看各品牌的客户端字段，再用机场选型方法里的清单核对其他维度。
优点、限制与风险提示
优点
- 可以让某个浏览器或配置文件单独使用不同出口，不影响其他程序
- 按站点分流的设置直观，改动只影响浏览器，回退简单
- 不需要管理员权限，门槛低于 TUN
- 与系统代理配合时，可以把浏览器的行为与系统其余部分区分开
限制
- 只覆盖安装它的浏览器配置文件，不覆盖其他程序
- 优先级高于系统代理，容易造成"客户端明明开了浏览器却不生效"的错觉
- 需要后端客户端提供本地端口，不是客户端的替代品
- 规则与客户端规则重复时，排错需要同时读两套规则
- 不同浏览器的扩展接口存在差异，行为不能完全类比
风险提示
- 代理插件能影响浏览器的网络请求，权限很高，应只从官方渠道安装
- 在线规则列表来自第三方，来源不明的列表可能改变请求的出口
- 订阅链接和含有链接的配置文件等同于账号凭据，不要随意分享
- 插件与 TUN、系统代理叠加时，命中的策略难以追溯，应保持接管层最少
- 品牌的客户端支持方式随时可能调整，本文品牌信息以 2026-10-18 的资料为准
常见问题
浏览器代理插件和系统代理同时开启，哪一个生效？
通常是浏览器插件生效。插件通过浏览器的代理接口为该浏览器指定出口，优先级高于读取操作系统设置的默认行为。如果插件设置为跟随系统，则退回系统代理；如果插件指向某个具体端口，就会绕过系统设置。
插件指向的端口和客户端不一致会出现什么现象？
浏览器会表现为无法连接、一直转圈或提示代理服务器拒绝连接，而系统里其他程序可能完全正常。这是因为只有浏览器在使用插件设置的端口，该端口上没有进程监听，连接请求被直接拒绝。
为什么关闭了代理客户端，浏览器仍然打不开网页？
最常见原因是浏览器插件或系统代理设置还指向已经关闭的本地端口。客户端退出后端口无人监听，浏览器仍在向它发送请求。应在插件中切换为直连或跟随系统，并检查系统代理开关是否残留。
浏览器代理插件和 TUN 模式一起用会不会重复代理？
不会简单叠成两层代理，但会让排错变复杂。插件把请求交给本地端口，该端口的内核再按规则转发，TUN 则在更底层接管同一批流量。两者可能对同一连接各自做一次规则判断，导致命中的策略与你预期不一致。
只想让部分网站走代理，用插件规则还是用客户端规则？
取决于范围。只希望某个浏览器、某类网站走代理，插件规则更轻；希望所有程序遵循同一套分流，应放在客户端的规则里。两处都配置分流容易互相打架，建议只选一处作为分流的主要位置。
PAC 脚本是什么，它和插件规则有什么关系？
PAC 是一种由脚本决定每个地址使用哪个代理或直连的配置方式。许多插件的规则列表本质上就是在生成或执行类似的判断，系统代理设置里也可以指定 PAC 地址。区别在于生效范围：插件只管浏览器，系统设置里的 PAC 则覆盖读取它的程序。
多个浏览器账户或多个浏览器怎样使用不同的代理出口？
可以为不同浏览器配置文件分别安装插件并设置不同出口，或让一个浏览器跟随系统、另一个使用插件。注意每个配置文件的扩展设置通常是独立保存的，切换账户后要单独检查，不要假定设置会同步。
订阅更新失败时，浏览器插件会受影响吗？
插件本身不管理订阅，订阅由客户端更新。但订阅更新失败会导致客户端节点列表过期，进而让插件指向的本地端口背后的节点失效，浏览器表现为间歇性打不开。应先在客户端侧排查订阅，再检查插件。
安装浏览器代理插件有哪些安全注意点？
代理插件能看到并改写浏览器的网络请求，权限很高。应只从浏览器官方扩展商店或项目官方渠道安装，查看权限说明，避免安装来源不明的版本，并定期核对已安装扩展列表，卸载不再使用的插件。
什么情况下可以完全不装浏览器代理插件？
如果你只用一个浏览器，系统代理或 TUN 已经满足需求，并且分流规则都放在客户端里，就没有必要再装插件。多装一层只会增加排错变量。需要按浏览器或按站点单独分流时，再考虑引入插件。
一个最小化的配置原则
最后给出一个可以直接采用的原则：把"谁负责分流"和"谁负责接管"拆开。接管层只保留一个，要么系统代理，要么 TUN；分流层只保留一处，要么客户端规则，要么插件规则。当你能用一句话回答"我的浏览器流量现在由谁接管、由谁分流"时，配置就是清晰的；当你说不清时，就是该精简的时候。
开发场景下，终端、集成开发环境与浏览器经常需要不同处理，可参考终端代理的设置与排查了解命令行侧的做法，把浏览器与终端分开管理，会比一个全局开关更容易维护。
三个假设化的场景示例
以下场景为说明原理而假设，不对应任何真实用户经历，也不含速度数值。
场景甲：用户只用一个浏览器，装了插件后又开启了系统代理，某天客户端升级后换了监听端口，浏览器全部打不开。原因是插件仍指向旧端口。处理方式是把插件改为跟随系统，之后不再手动维护端口，以后客户端改端口也不受影响。这个例子说明，"跟随系统"是维护成本最低的状态。
场景乙：用户有工作和个人两个浏览器配置文件，希望工作配置文件直连、个人配置文件走代理。做法是只在个人配置文件里安装并启用插件，工作配置文件保持直连或跟随系统且系统代理关闭。这类需求正是插件的合理用途，因为系统代理无法按配置文件区分。
场景丙：用户同时开启 TUN 和插件，发现某个站点的访问行为与客户端规则不符。排查时把插件切到直连后行为恢复一致，说明之前是插件规则先做了一次判断。处理方式是删除插件里重复的站点规则，只保留客户端规则。三个场景的共同点是：先把接管层与分流位置各缩减为一个，再判断问题。
下一步
浏览器侧的接管关系理顺后，体验仍取决于节点与线路。若还没有确定品牌，建议回到机场选型方法按清单核对，再到品牌库查看协议与客户端字段。下方卡片指向品牌库，品牌详情页中的注册链接为各品牌官方注册或推广链接；本页资料部分只整理公开资料，不构成推荐；星岛梦第一、光速云第二为本站推荐排名，非测试结果。