Clash 开全局后只有浏览器通？Windows 与 macOS 上系统代理和 TUN 逐步排查

典型现象：像开了全局，却只有浏览器「听话」

很多用户会把下面这种情况描述成「Clash 全局模式坏了」：Chrome、Edge、Safari 访问外站都正常，游戏启动器、Steam/Epic 下载、独立聊天软件、IDE 插件市场或某些微软商店应用，却仍然提示超时、无法连接、或明显走国内直连。你明明在客户端里选了 Global（全局），也打开了系统代理，甚至试过勾选 TUN，但桌面上一半软件仿佛活在另一个网络宇宙。

这类问题与「Allow LAN」「WSL2 路由」或「Docker 守护进程代理」不尽相同：核心矛盾是——你以为已经在系统层面「一锅端」了，实际上有大量进程根本不会去读系统代理设置。因此排查的第一步，是先把「Clash 界面上的全局」与「操作系统里真正生效的接管方式」分开理解，避免在错误层级上调规则。

先澄清：Clash 里的「全局」主要管哪一层？

在 Mihomo / Clash 系内核里，Global通常指「所有命中规则的请求默认进你选定的策略组 / 出口」，这是在内核做完解析之后的分流语义；它并不等价于「操作系统里每一个 TCP/UDP 包都必然经过 Clash」。若入口流量压根没到内核（例如某程序直连原始 IP、使用自带证书钉扎、或完全忽略 HTTP 代理 API），你再怎么切 Global，也只会看到浏览器这类「自愿走系统代理或使用本地 Mixed 端口」的应用表现正常。

反过来，只开系统代理而不开 TUN 时，常见客户端会把 Windows/macOS 的系统 HTTP/HTTPS（及某些场景下的 SOCKS）指到本机某个端口。浏览器、Electron 应用、部分尊重系统设置的运行时，会跟随这一路径；但大量原生程序使用普通套接字 API，不读取 WinHTTP/系统代理表，便会按系统默认路由直连。于是出现「浏览器通、游戏 / CLI / 启动器不通」的经典组合——这不是玄学，而是路径不同。

系统代理能做什么？边界在哪里？

可以把系统代理理解成「给遵守规矩的应用发通行证」。它主要影响：遵循系统代理变量或 WinINet/CFNetwork 代理链的软件；对纯 TCP 的 HTTP(S) 请求尤其常见。边界也很清晰：不认代理的程序不受管理；UDP、QUIC、部分游戏流量即便理论可走 SOCKS5，还要程序本身支持、且内核与规则未在别处短路。仅浏览器能上网时，优先怀疑：「非浏览器流量是否从未进入 Clash 监听的本地端口？」而不是先怀疑节点质量。

另一个常见误判是把「开了增强模式 / 端口混合」当成已接管全机。若你没有启用 TUN（虚拟网卡）或等效透明入口，只是 Local Mixed + 系统代理，那么未指向本地的连接仍会按操作系统路由表出去。此时对比本站 《Clash TUN 模式完全指南》 中的「系统代理 vs TUN」一节，可以快速对齐预期：前者靠应用自觉，后者更接近路由层兜底。

Windows：UWP 回环、服务权限与「看起来开了代理」

在 Windows 上，即使系统代理已指向 127.0.0.1 的 Mixed 端口，UWP（微软商店应用）仍可能访问不了本机代理，这是历史久远的 UWP 回环（loopback） 限制：沙盒应用默认不能随意连接本机服务，除非为具体包名开启回环豁免。症状往往是：浏览器（Win32）畅通，而 Xbox App、部分预装组件或商店版软件异常。处理方式通常包括使用官方提供的回环管理工具或对应客户端内置的一键修复，而不是反复导入订阅。

此外，启用 TUN 往往需要安装服务并以管理员权限初始化虚拟网卡。若你看到 TUN 反复失败、或仅有浏览器可用，请检查：UAC 是否放行、是否有安全软件拦截驱动、是否与其他 VPN 抢占路由。与「只有浏览器通」同时出现时，还可以对照 《Windows 11 上 Clash 与 WSL2 路由》 一文区分：那是子系统网卡与度量问题；而本文聚焦「同一系统上 Win32 应用与浏览器表现不一致」时的代理层级判断。

游戏与对战平台还要考虑反作弊与自定义协议：部分进程会明确禁止使用代理或仅走指定网卡；即使你开了 TUN，也可能需要规则层面的细化（例如区分进程、或接受某些场景无法代理的事实）。但至少先完成「系统代理 → TUN → 日志命中」三层验证，再下结论。

macOS：系统代理、沙盒与网络扩展批准

在 macOS 上，浏览器与部分 App 会读取「系统设置 → 网络 → 代理」中的 HTTP/HTTPS/SOCKS；但与 Windows 类似，命令行工具与许多桌面应用默认仍直连，除非你显式设置 HTTP(S)_PROXY 环境变量或让它们走本地端口。若你已勾选系统代理但仍「仅浏览器通」，请先确认：终端里 curl、Git、包管理器是否需要单独配置代理，而不是期待它们自动继承浏览器行为。

开启 TUN 或系统级捕获时，新版本 macOS 常要求用户在「隐私与安全性」中批准网络扩展（Network Extension）或相关系统扩展。若扩展未获批、或被公司 MDM 配置阻断，表现可能是：浏览器因自身实现仍可走代理，而需要扩展参与的透明路径未建立。请在客户端提示下完成授权与重启，再复测同一款非浏览器应用。

若同时使用 iCloud 专用代理、企业 VPN 或其它过滤描述文件，可能出现路由与 DNS 被多次改写的竞态——这与单纯「全局模式不生效」不同，需要逐项关闭冲突组件后用网络诊断工具观察默认路由变化。

什么时候可以确定「必须上 TUN」？

若你已确认：节点与规则在浏览器下健康；系统代理已正确写入；仍有一批非浏览器应用持续直连或仅在关掉某类防火墙后短暂恢复——这通常表明仅靠本地端口与系统代理不够承载你的目标流量。此时应在客户端中启用 TUN（并满足驱动/扩展权限要求），让符合条件的 IP 层流量进入 Mihomo 再匹配规则。具体原理与注意事项详见前述 TUN 完全指南，本文不再重复底层细节。

需要强调的是：TUN 也不是魔法开关。若 fake-ip、DNS、IPv6 与规则顺序存在问题，仍会出现「看起来像没走代理」的现象。把 TUN 当作扩大流量入口的手段，而不是替代正确的规则与解析配置，会少走很多弯路。

分步排查清单（建议按顺序执行）

1. 确认现象粒度：只有浏览器通，还是「浏览器 + 少数 App 通」？是否包含 UWP / 商店版？记下具体包名或进程，方便检索回环与权限资料。
2. 核对入口：仅系统代理、还是系统代理 + TUN 同时开？若未开 TUN，先承认「大量进程可能永远不经过 Clash」，再决定是否启用虚拟网卡。
3. 看日志命中：在出现问题时发起连接，观察 Mihomo 日志是否出现该连接的域名或 IP。若完全无记录，流量多半未进内核；若有记录但策略不对，再调规则与策略组。
4. 平台专项：Windows 侧排查 UWP 回环与 TUN 服务安装；macOS 侧检查网络扩展是否放行、终端环境变量是否独立配置。
5. 最后才动节点：在确认流量已进入内核且策略为 Global / 预期组之后，再讨论延迟、UDP 与节点地区，避免把「路径没到」误判成「节点挂了」。

图形界面操作与模式切换细节，可配合 《Clash Verge Rev 使用教程》 中的代理模式章节一并查看；若尚未安装客户端，可先从本站 下载页 获取适合自己系统的构建版本。

小结

Clash 全局模式解决的是内核收到请求之后往哪走的问题；系统代理解决的是「哪些应用愿意把请求交给本机端口」的问题；TUN 模式则是在更广范围内把流量兜进内核。所谓「开全局后只有浏览器通」，多数是前两层语义混用所致，而不是单一开关失效。

按 Windows 与 macOS 分平台看清 UWP 回环与网络扩展等特有条件，再配合日志确认流量是否真正进入 Mihomo，你可以系统性区分「代理未接管」「权限不足」与「规则 / DNS 仍需微调」。相比在社交平台上搜一句报错，这套顺序能更快定位根因。

持续维护的 Clash 系客户端在系统代理、Mixed 入站与 TUN 的组合上已经相当成熟；若你希望从安装、订阅到分流规则逐步上手，不妨通过本站渠道获取客户端，用同一套配置在浏览器与更多桌面应用之间验证效果。→ 立即免费下载 Clash，开启流畅上网新体验