系统代理是什么？原理、设置与局限
在 Clash Verge Rev 里点一下「系统代理」开关，浏览器就能正常访问外网了——很多人以为这个开关做了什么复杂的事。其实它只做了一件极简单的事：往操作系统的网络设置里写下一行声明，告诉所有程序「有需要的话，请把 HTTP/SOCKS 请求发到 127.0.0.1 的某个端口」。
关键词是自愿。系统代理没有任何强制力，它是一份公告而不是关卡。愿意读这份公告的程序会照做，不读的程序照样直连——理解了这一点，「明明开了代理却还是打不开」这类问题就有了排查方向。
系统代理的本质：一条声明，不是一道关卡
操作系统提供了一个标准位置存放代理配置：Windows 在「设置 → 网络和 Internet → 代理」，macOS 在网络设置的代理选项卡里，Linux 桌面则各有各的位置（GNOME 在网络设置中，命令行环境靠环境变量）。代理客户端启动时把 127.0.0.1 和自己监听的端口写进去，关闭时再清掉，就这么简单。
流量的实际路径是：应用读到系统代理设置 → 把请求发给本地端口 → mihomo 内核收到后按分流规则判断走哪个节点或直连 → 拿到响应再回给应用。所以内核必须在跑、端口必须对得上，缺一不可。端口以客户端设置里的混合端口为准，常见为 7890 或 7897。
哪些流量会走系统代理，哪些不会
| 程序类型 | 是否遵守系统代理 | 说明 |
|---|---|---|
| 主流浏览器 | 会 | Chrome、Edge 等默认跟随系统设置 |
| 多数桌面应用 | 通常会 | 使用系统网络组件的应用会自动继承 |
| 命令行工具 | 多数不会 | curl、git、包管理器一般只认环境变量 |
| 部分游戏与专用客户端 | 常常不会 | 自行发起连接，尤其是 UDP 流量 |
| 系统级服务与更新组件 | 不确定 | 行为因系统和版本而异 |
Firefox 是个典型例外：它有自己的一套网络设置，默认虽然跟随系统，但一旦你手动改过就以自身设置为准。遇到「别的浏览器能上、这个不能」，先去它自己的代理设置里看一眼。
给命令行工具补上代理：环境变量
终端里的程序基本不读系统代理，但绝大多数认 http_proxy 这类环境变量。临时生效的写法（把端口换成你自己的）：
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890
curl -I https://www.example.comWindows 的 PowerShell 里对应这样写：
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"这两种设置都只对当前终端会话有效，关掉窗口就失效；要长期生效需要写进 shell 配置文件或系统环境变量。也有不少客户端提供「复制环境变量」之类的快捷入口，直接粘贴即可。
技巧：验证代理是否真的生效，最简单的办法是让 curl 带上 -x 参数强制走代理并对比结果。若不带参数能通、带上不通，问题在内核或端口；反过来则说明环境变量没读到。
PAC 模式是怎么回事
除了「全局指定一个代理服务器」，系统代理还支持另一种形式：给出一个 PAC 脚本地址。PAC 是一段 JavaScript，浏览器在发起每个请求前调用它，由脚本返回「这个域名该直连还是走代理」。它的优点是分流判断发生在应用侧，代理客户端不必接管全部请求；缺点是只作用于支持 PAC 的程序、规则更新不如内核灵活，而且排错时更难看清到底走了哪条路。mihomo 系客户端把分流交给内核规则处理，能力比 PAC 强得多，所以日常没有必要专门去用 PAC 模式。
系统代理的局限，以及什么时候换 TUN
系统代理胜在轻量：不需要管理员权限、不动网络栈、出问题关掉开关就恢复原状，日常浏览网页足够用。它的短板同样明确——覆盖范围取决于应用是否配合，UDP 流量、不读系统设置的程序、某些游戏和专用客户端都可能漏在外面。
当你遇到「浏览器正常但某个软件死活连不上」，多半就撞上了这条边界。这时候的解法是改用工作在网络层的 TUN 模式：它创建一块虚拟网卡接管全部 IP 流量，不依赖应用自愿配合，代价是需要更高的系统权限。原理与开启方法见 TUN 模式详解，两种模式的完整取舍见 TUN 模式与系统代理怎么选。如果你现在的状态是「开了代理还是上不了网」，那份 分步排查指南 会更对症。