三层代理栈：扩展、系统代理与 TUN 各管什么

把网络想成一条流水线：浏览器扩展（如 SwitchyOmega）只影响该浏览器里发出的请求怎么找「上游 HTTP/SOCKS 代理」；系统代理是操作系统告诉多数图形程序「默认代理在哪」；TUN 则在更底层把符合策略的流量抓进虚拟网卡，往往不再依赖应用是否认系统代理。当你同时打开 Clash 的系统代理/TUN，又让扩展把流量指向本机 Clash 端口，就等于在流水线里连续塞了两个闸口——只要端口、协议或 PAC 有一处对不齐，就会表现为随机超时。

这与「扩展只做分流、内核只做隧道」的理想分工不同：理想情况下，要么让浏览器完全信任系统/TUN（扩展关掉或切「直连」），要么在仅系统代理、未开 TUN的前提下，用扩展精细控制哪些站点走代理——但后一种也要保证扩展指向的地址与 Clash 的 mixed-port 实时一致，并在改端口后同步修改，相关联动可参考 端口占用与 mixed-port 一文中的「系统代理与工具链对齐」段落。

典型症状：什么时候该怀疑「双代理」

若出现下面任意组合，优先怀疑重复代理或环路，而不是先换节点：

若关闭扩展后仍异常，再分层查 DNS、TLS 与节点，可走 连接日志与 TLS 的读法；若退出 Clash 后整台机断网，则多半是系统代理残留而非扩展问题，按 退出后清理系统代理与 TUN 处理。

ℹ 一句话原则：Clash 已经以系统代理或 TUN 统一接管时，浏览器扩展再指向 127.0.0.1 往往是多余的；先关扩展验证，比先改规则集更能节省时间。

SwitchyOmega 常见模式与踩坑点

固定代理到本机端口

场景 profile 里若写死 HTTP 127.0.0.1:7890 一类地址，而 Clash 实际监听在别的 mixed-port，浏览器会一直连空端口。更隐蔽的是：Clash 已开系统代理，扩展仍把「全部网址」送到本机端口——形成双代理。

「系统代理」模式

若扩展切到「跟随系统」，而系统代理正是 Clash 写入的地址，通常只有一层，相对安全。但若你同时在 Clash 里开了 TUN，又保留扩展的自动切换规则，仍可能因规则顺序导致部分域名被扩展提前改写，建议实测时先切到直连或暂时禁用扩展做对照。

PAC 与旁路列表

自定义 PAC 若把过宽的通配符送进代理，可能把局域网段也兜进 Clash；这与 Fake-IP 下访问路由器异常有相似之处，可对照 Fake-IP 与局域网绕过 中的思路，区分「DNS/规则」与「扩展误伤本地」。

loopback 环路是怎么形成的

简化描述一种典型环路：扩展把请求发给 127.0.0.1:PORT_A（Clash 入站），Clash 处理时发现该连接仍应「再转发到 HTTP 代理」，目标又是 127.0.0.1:PORT_A 或同一上游，连接在本机回环上反复握手，表现为 CPU 占用升高、日志刷屏、页面永不结束加载。此类问题与节点质量无关，换机场解决不了。

另一种「伪环路」来自环境变量与浏览器叠加：终端里设置了 ALL_PROXY 指向本机 Clash，同时又在 IDE 内置浏览器里开扩展，多层指向不一致时，现象与环路类似。终端与 Docker 侧的统一写法见 Docker 与终端代理环境变量 ；WSL2 与 Windows 宿主机之间则要避免「WSL 指错宿主 IP、宿主再被扩展二次代理」，可参考 WSL2 与宿主机 Clash。

实测步骤：只保留一层代理

按顺序做，便于你写进自己的排障笔记或给他人远程协助。

  1. 记下当前模式：Clash 是「仅系统代理」「TUN」还是两者兼有；客户端显示的 mixed-port、external-controller 端口。
  2. 禁用或卸载冲突扩展：在 Chrome/Edge 的扩展页关闭 SwitchyOmega，或用无痕窗口（默认无扩展）打开同一网址对照。
  3. 扩展必须保留时：新建一个「全直连」情景，或把默认情景改为直连，确认只有 Clash 在系统层工作。
  4. 核对系统代理：操作系统「代理」设置里的主机与端口，应与 Clash 当前监听一致；macOS 用户若曾遇到「系统扩展与代理」双重提示，可对照 macOS TUN 与系统代理冲突排查。
  5. 看连接日志：复现问题时，观察新建连接的目标是否为预期站点，而不是长时间停留在 127.0.0.1 上的异常重复。
  6. 本地与面板验证：浏览器访问 Clash 面板（若开启）时，尽量用扩展的绕过列表排除 127.0.0.1 与内网段，或直接关扩展访问；面板安全与绑定见 external-controller 与本机绑定。
  7. 恢复扩展精细分流（可选）：仅在「未开系统代理、只用扩展指 Clash」或「明确需要按域名拆场景」时，再逐步打开扩展，并每次只改一处配置。

若你的目标是「整台设备统一规则」，长期更省心的是：让 Clash 负责分流，浏览器侧保持干净；客户端选型与平台差异可参考 如何选择适合自己的 Clash 客户端。 浏览器专属问题（例如测速站仍像泄露本地 IP）则与扩展代理不同路，需要单独看 WebRTC 与浏览器验证。

Windows / macOS / Linux 的额外注意

Windows 上部分「网络修复」或安全软件会改写系统代理；Clash 退出后若残留，症状像断网而非环路，需与本文场景区分。macOS 多网络位置（Wi‑Fi、USB 网卡）可能各自保存代理设置，切换接口后记得复查。Linux 桌面环境对系统代理的支持不一，若仅部分应用读 gsettings 而浏览器扩展仍指向旧端口，也会出现「只有浏览器坏」的假象。

⚠ 合规与安全：请在你有权使用的网络环境中操作；勿利用多层代理规避单位或学校的信息安全策略。扩展与第三方 PAC 来源需可信，避免在排障过程中引入新的供应链风险。

结语

Clash 与 SwitchyOmega 并不是天然互斥，但同时各管一层「把流量送去本机端口」时，极容易产生双代理与 loopback 环路。实务上最稳的路径是：系统或 TUN 已接管时，把扩展关掉或切直连；必须保留扩展时，确保全站只有一条指向 Clash 的链路，并在改端口、切模式后立刻复查系统代理与绕过列表。

相比盲目加规则，先做一次「关扩展对照」往往更快定位问题；这与我们在 规则分流最佳实践 里强调的「先分层、再归因」是同一套方法。

相比其它工具栈，Clash 系列在连接可视性与模式切换上通常更利于你做这类对照实验；当你把扩展与系统层对齐后，无限转圈类问题大多会收敛为可验证的配置事实，而不是玄学。

→ 立即免费下载 Clash，开启流畅上网新体验，在客户端里用连接日志完成「关扩展前后」的同场景复现。