现象：任务栏里 Clash 正常，Chrome / Edge 却「像没走代理」

不少读者描述过同一种挫败感：Windows「设置」里已经打开手动代理，或 Clash / Verge 一类客户端也提示已写入系统代理，其它软件似乎能翻，唯独 Chrome 与 Microsoft Edge 打开某些境外站点时依然慢、超时，甚至和你期望的分流规则完全对不上。也有人反过来：只想让浏览器走隧道，却不想动整机路由，却发现怎么改系统设置都「隔了一层雾」。这类问题在 2026 年的桌面环境仍然非常常见，根源往往不在于节点本身，而在于Chromium 系浏览器究竟听哪一张「代理配置表」——它并不总与你在「终端里 export 的变量」或「UWP 应用的 loopback 例外」共享同一套语义。

本文专门补齐这一环：用成熟扩展 SwitchyOmega（及同类思路）把浏览器的出口显式钉在本机 127.0.0.1 上由 Clash 监听的 mixed-port（常见为 7890，请以你当前配置为准）。你可以选全局走代理，也可以用自动切换按域名决定直连或进隧道，最终仍由 Clash 的规则与策略组决定「这一跳之后走哪条线路」。这与本站 终端 http_proxy 与 Git 代理、UWP 与商店应用 形成并列阅读：同一台电脑里，不同运行时各吃各的配置，不要混作一条命令解决。

为什么「系统代理开着」浏览器仍可能不吃

Windows 的「代理」设置主要影响的是遵循系统代理栈的应用。Chromium 大体上会尊重系统代理，但在实际排障中你会遇到大量例外：企业策略、组策略、安全软件注入、旧版 PAC 缓存、以及用户曾经安装过的扩展把代理决策「截胡」。更细一点说，有些场景下浏览器读到的并不是你以为的那份 PAC，或者某些请求因「直连例外」「本地主机绕过」被提前放行。再加上 Clash 侧若未正确打开系统代理或端口与设置页不一致，表面「开了」其实只是客户端按钮亮着——类似情况在 7890 / mixed-port 占用与改写 一文里也常与「系统设置仍指向旧端口」同时出现。

因此更稳妥的工程化做法是：在浏览器内部再放一层你完全可控的代理开关。扩展工作在标签页请求的决策链上，和「系统全局」解耦——你要全局就全局，要按需就按需；而出口的物理位置仍然是本机环路地址 127.0.0.1，由 Clash 的 mixed-port 统一承接 HTTP CONNECT 与 SOCKS5。这既解决「看起来像没翻」，也避免为了浏览器单独去改整机 TUN——当然，若你希望游戏、Electron 桌面应用与脚本全部一致走内核，仍可并行阅读 TUN 模式详解，本文不展开路由层细节。

准备：对齐 Clash 的 mixed-port 与监听

在碰扩展之前，请先在图形客户端或正在加载的 YAML 中确认三个事实。第一，mixed-port（或等价的混合入站端口）是否为预期数字，例如 7890。第二，监听是否包含 127.0.0.1 或等价的全局监听（仅以局域网 IP 收听时，本机环路仍通常可用，但请以你防火墙与客户端文案为准）。第三，没有其他进程霸占该端口；若启动报错，请先按前文端口篇用 netstat 找 PID。只要本机telnet 语义上「能连到 127.0.0.1:端口」，浏览器侧配置才有意义。

若你连订阅导入、内核启动都不够稳定，请先回到 Windows 图形客户端安装与最小闭环，再继续本文——否则容易出现「扩展填的全对，但 Clash 根本没在听」的假阴性。

SwitchyOmega：在 Chrome / Edge 中安装与固定工具栏

Chrome 通常直接从 Chrome Web Store 安装 SwitchyOmega 或其活跃维护分支（名称可能随商店政策微调，请以可验证的开发者页为准）。Edge 基于 Chromium，一般允许加载相同的扩展——可在 Edge 自带的扩展商店搜索同名扩展，或通过「允许来自其它商城」类开关从 Chrome Web Store 安装；不同组织策略下入口可能被封，需在「扩展管理」里确认未被管理员禁用开发者侧载。

安装后务必把扩展.pin 到工具栏，并把默认情景先设为「直连」以避免一开始误把所有流量送进隧道。随后再按下一节新建名为「Clash」或「Mixed」的情景模式，调试完成后再切换到自动切换。

新建情景模式：指向 127.0.0.1 与 mixed-port

打开 SwitchyOmega 选项页，新建情景模式类型选「代理服务器」。绝大多数 Clash Meta 系的 mixed-port 同时兼容 HTTP 与 SOCKS；为减少兼容性问题，可优先尝试下列写法之一。

方式 A — HTTP： 协议选择 HTTP；代理服务器填 127.0.0.1；端口填你的 mixed-port（示例 7890）。HTTPS 一栏在扩展里常与 HTTP 同源，可按扩展说明留空或与 HTTP 同步。

方式 B — SOCKS5： 协议选择 SOCKS5；地址仍为 127.0.0.1；端口同上。个别站点或 HTTP/3 路径在 SOCKS 与 HTTP 上的表现会因扩展与 Chromium 版本略有差异；若某一种方式异常，可平行试另一种作为对照。

保存后在工具栏点击该情景，访问一个纯境外测试页或在 Clash「连接」面板观察是否出现由浏览器进程发起的链路。若没有，请先排除扩展未启用、被策略禁用、或与其它「代理类」扩展冲突——多个扩展同时劫持 PAC 屡见不鲜。

按需分流：自动切换（PAC）与 Clash 规则的关系

如果你希望「国内站直连、名单内走代理」，可以在 SwitchyOmega 新建「自动切换」情景，按域名后缀把请求分发到前述「直连」或「Clash」子情景。但要注意边界：扩展侧的域名列表与 Clash rules: 是两层决策。扩展先决定浏览器是否把手伸到 127.0.0.1；一旦进来了，出站国家、落地节点与策略组仍由 Clash 决定。团队协作时建议把「境内外大方向」仍以 Clash 为主，浏览器扩展只做粗分流或兜底，避免出现两份长长的域名表互相打架。

想深入 YAML 优先级与 GEOIP/CIDR 的阅读顺序，可对照 站内配置文档索引 与分流专文；本篇刻意保持在「浏览器入站对齐」粒度。

Edge 特别说明：配置同步、工作与家庭配置文件

Edge 多配置文件（工作 / 个人）彼此隔离，扩展与情景不会自动串门。若在 A 配置文件装好了 SwitchyOmega，在 B 里仍未生效属于正常行为——请在同一配置文件内重复安装或确认同步策略。政企环境若统一管理扩展白名单，可能看不到商店入口，需要先走 IT 流程。

这与 Edge 系统代理页面里的开关是两套 UI：你看到系统页「开着」，不等于当前配置文件里的扩展没有把请求改道；反过来，扩展走的是 127.0.0.1 时，即使你临时关闭系统代理，只要 Clash 在听，浏览器仍可能继续翻——这是一致性行为，并非 bug。

验证与交叉检查：别让端口写错或与绕过列表相冲

验证建议从弱缓存页面开始：开 Clash 连接列表，再在浏览器开一个少跳转的 HTTPS 站点，观察五条线索：目标主机名是否正确；是否经由 DIRECT 误入；策略组是否与预期一致；TLS 报错是否更像 SNI／证书而非代理链路；IPv6-only 环境下是否有半通。若你只改浏览器而忘了 Clash 里策略把该域名送回直连，会看到「扩展显示代理开、内核仍放行直连」这一现象——此时应回到规则优先级而不是怀疑扩展失灵。

另外请检查操作系统或浏览器自带的「不使用代理服务器的地址」列表：局域网段、*.local、或公司内往往在这里被排除——若你把测试域名写成了落在这些模式里的镜像地址，也会产生「看起来像没代理」的错觉。

常见坑小结

mixed-port 与系统设置页端口不一致

最典型的低级错误是把扩展写成 7890，但 YAML 已改成 7892——症状是立刻连接被拒绝。改端口后要三处一起改：Clash、Windows 代理设置（若仍使用）、浏览器扩展。

代理扩展互相冲突

广告拦截、隐私类扩展有时也带「本地 VPN」或「HTTPS 过滤」子功能，与 SwitchyOmega 叠在一起会导致请求链路过长或证书被中间人。排障时可先临时禁用其它扩展做二分法。

以为浏览器与终端天然共享配置

命令行仍要看 HTTP_PROXY 与 Git 配置，商店应用要看 UWP loopback。浏览器走扩展 ≠ 终端自动跟着走；需要 CLI 的读者请继续用 终端代理专文。

小结与下载入口

把 Chrome 代理与 Edge 系统代理的困惑拆开后，核心只有一句话：先保证本机 Clash mixed-port 在 127.0.0.1 上真实可用，再用 SwitchyOmega 把浏览器决策链透明地接到这个入口，你就同时获得了「可切换、可排障、可与规则文件协同」的桌面浏览体验。相比把希望完全寄托在系统代理层或反复重装浏览器，这种接法更利于长期维护，也与团队里常见的「本机固定 mixed-port 作为语义锚点」实践一致。若你尚未选定长期维护的图形客户端与内核组合，可从本站 Clash 客户端下载页 获取各平台安装指引；需要查阅字段含义时结合 文档中心 即可。→ 立即免费下载 Clash，开启流畅上网新体验