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

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

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

不少运用者会把下面这种状态描述成「Clash 全局模式坏了」：Chrome、Edge、Safari 连通外站都正常，游戏拉起器、Steam/Epic 下载、独立聊天软件、IDE 插件市场或某些微软商店应用，却仍然提示超时、无法连接、或显著走国内直连。

你明明在客户端里选了 Global（全局），也开启了系统代理，甚至试过勾选 TUN，但桌面上一半软件仿佛活在另一个网络宇宙。

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

但大批原生程序运用普通套接字 API，不读取 WinHTTP/系统代理表，便会按系统内置路由直连。于是出现「浏览器通、游戏 / CLI / 拉起器不通」的经典组合——这不是玄学，而是路径不同。

先看这一点：在 Mihomo / Clash 系内核里，Global一般指「全部命中规则的请求内置进你选定的策略组 / 出口」，这是在内核做完解析之后的分流语义；它并不等价于「操作系统里每一个 TCP/UDP 包都必然经过 Clash」。

若入口流量压根没到内核（比如某程序直连原始 IP、运用自带证书钉扎、或完全忽略 HTTP 代理 API），你再怎么切 Global，也只会看到浏览器这类「自愿走系统代理或运用本地 Mixed 端口」的应用表现正常。

反过来，只开系统代理而不开 TUN 时，高频客户端会把 Windows/macOS 的系统 HTTP/HTTPS（及某些状态下的 SOCKS）指到本机某个端口。浏览器、Electron 应用、部分尊重系统设置的跑起来时，会跟随这一路径；

系统代理能做什么？边界在哪里？ 逐条拆解

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

补充说明：能够把系统代理理解成「给遵守规矩的应用发通行证」。它核心影响：遵循系统代理变量或 WinINet/CFNetwork 代理链的软件；对纯 TCP 的 HTTP(S) 请求尤其高频。边界也很明白：不认代理的程序不受管理；

UDP、QUIC、部分游戏流量即便理论可走 SOCKS5，还要程序本身兼容、且内核与规则未在别处短路。仅浏览器能上网时，首位怀疑：「非浏览器流量是否从未进入 Clash 监听的本地端口？」而不是先怀疑节点质量。

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

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

在 Windows 上，即使系统代理已指向 127.0.0.1 的 Mixed 端口，UWP（微软商店应用）仍也许连通不了本机代理，这是历史久远的 UWP 回环（loopback） 限制：沙盒应用内置不能随意连接本机服务，除非为具体包名开启回环豁免。

换个角度：症状通常是：浏览器（Win32）畅通，而 Xbox App、部分预装组件或商店版软件异常。处理方式一般涵盖运用官方提供的回环管理工具或对应客户端内置的一键修复，而不是反复引入订阅。

另外，启用 TUN 通常得安装服务并以管理员权限初始化虚拟网卡。若你看到 TUN 反复不成功、或仅有浏览器可用，请核对：UAC 是否放行、是否有安全软件拦截驱动、是否与其他 VPN 抢占路由。

与「只有浏览器通」同时出现时，还能够对照 《Windows 11 上 Clash 与 WSL2 路由》 一文区分：那是子系统网卡与度量难点；而这篇文章聚焦「同一系统上 Win32 应用与浏览器表现不一致」时的代理层级判断。

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

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

具体来说：在 macOS 上，浏览器与部分 App 会读取「系统设置 → 网络 → 代理」中的 HTTP/HTTPS/SOCKS；但与 Windows 类似，命令行工具与众多桌面应用内置仍直连，除非你显式设置 HTTP(S)_PROXY 环境变量或让两者走本地端口。

若你已勾选系统代理但仍「仅浏览器通」，请先确认：终端里 curl、Git、包管理器是否得单独配置代理，而不是期待两者无人值守继承浏览器行为。

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

什么时候能够确定「必须上 TUN」？ 核心要点

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

顺带一提：若你已确认：节点与规则在浏览器下健康；系统代理已无误写入；仍有一批非浏览器应用持续直连或仅在关掉某类防火墙后短暂恢复——这一般表明仅靠本地端口与系统代理不够承载你的目标流量。

此时应在客户端中启用 TUN（并满足驱动/扩展权限要求），让符合条件的 IP 层流量进入 Mihomo 再匹配规则。具体机制与注意事项详见前述 TUN 完全指南，这篇文章不再重复底层容易忽略的地方。

分步排查清单（推荐按顺序执行） 逐条拆解

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

图形操作操作界面操作与模式切换容易忽略的地方，可配合 《Clash Verge Rev 运用指引》 中的代理模式章节一并查看；若尚未安装客户端，可先从本站 下载页 获取适合亲手系统的构建版本。

小结 底层逻辑

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

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

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