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

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

这类困扰与「Allow LAN」「WSL2 路由」或「Docker 守护进程代理」不尽相同：核心矛盾是——你以为已经在系统层面「一锅端」了，其实有规模不小进程根本不会去读系统代理设置。

规模不小人会把下面这种现状描述成「Clash 全局模式坏了」：Chrome、Edge、Safari 访问到到到外站都正常，游戏开启器、Steam/Epic 下载、独立聊天软件、IDE 插件市场或某些微软商店应用，却仍然提示超时、无法连接、或清楚可见走国内直连。

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

关键点是：于是排查的第一口气，是先把「Clash UI UI UI 界面上的全局」与「操作系统里真正生效的接管方式」分开理解，避免在疏漏层级上调规则。

先澄清：Clash 里的「全局」关键点管哪一层？ 关键信息

反过来，只开系统代理而不开 TUN 时，普遍客户端会把 Windows/macOS 的系统 HTTP/HTTPS（及某些采用采用使用场景下的 SOCKS）指到本机某个端口。浏览器、Electron 应用、部分尊重系统设置的持续持续持续运行时，会跟随这一路径；

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

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

这里要多说一句：但规模不小原生程序采用普通套接字 API，不读取 WinHTTP/系统代理表，便会按系统出厂路由直连。于是出现「浏览器通、游戏 / CLI / 开启器不通」的经典组合——这不是玄学，而是路径不同。

系统代理能做什么？边界在哪里？ 关键点梳理

另一个普遍误判是把「开了增强模式 / 端口混合」当成已接管全机。若你没有启用 TUN（虚拟网卡）或等效透明入口，只是 Local Mixed + 系统代理，那么未指向本地的连接仍会按操作系统路由表出去。

得以把系统代理理解成「给遵守规矩的应用发通行证」。它关键点影响：遵循系统代理变量或 WinINet/CFNetwork 代理链的软件；对纯 TCP 的 HTTP(S) 请求尤其普遍。边界也很一目了然：不认代理的程序不受管理；

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

换个说法：此时对比本站 《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：系统代理、沙盒与网络扩展批准 要点速览

若扩展未获批、或被公司 MDM 配置阻断，表现或许是：浏览器因自身实现仍可走代理，而要扩展参与的透明路径未建立。请在客户端提示下完成授权与重启，再复测同一款非浏览器应用。

别忽略了：在 macOS 上，浏览器与部分 App 会读取「系统设置 → 网络 → 代理」中的 HTTP/HTTPS/SOCKS；但与 Windows 类似，命令行工具与规模不小桌面应用出厂仍直连，除非你显式设置 HTTP(S)_PROXY 环境变量或让这几个走本地端口。

若你已勾选系统代理但仍「仅浏览器通」，请先确认：终端里 curl、Git、包管理器是否要单独配置代理，而不是期待这几个全全全自动继承浏览器行为。

开启 TUN 或系统级捕获时，新版本 macOS 常要求用户在「隐私与安全性」中批准网络扩展（Network Extension）或相关系统扩展。

关键点是：若同时采用 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 与节点地区，避免把「路径没到」误判成「节点挂了」。

这里要多说一句：图形UI UI 界面操作与模式切换细枝末节，可配合 《Clash Verge Rev 采用指南》 中的代理模式章节一并查看；若尚未安装客户端，可先从本站 下载页 获取适合自行系统的构建版本。

小结 完备说明

持续维护的 Clash 系客户端在系统代理、Mixed 入站与 TUN 的组合上已经相当被验证过；

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

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

若你希望从安装、订阅到分流规则逐步上手，不妨通过本站渠道获取客户端，用同一套配置在浏览器与更多桌面应用之间验证成效。→ 立即免费下载 Clash，开启流畅上网新上手感觉