Clash 系统代理到底代理了谁?端口与绕过规则

「代理明明开着,为什么这个软件还是连不上」是 Clash 相关问题里出现频率最高的一句。它之所以难解释,是因为大多数人默认「打开系统代理」等于「所有流量都走代理了」。这个前提本身就不成立。

系统代理的真实作用范围比想象中小得多。打开开关时,客户端做的事只有一件:把自己监听的那个本地端口地址写进操作系统的网络代理设置里。这项设置的性质接近一张公告——系统把它挂在那儿,程序看不看、遵不遵守,完全由程序自己决定。浏览器一般会主动去读并遵守,而游戏客户端、不少命令行工具和一部分桌面软件从来不查这项设置,它们照旧直连出去。

于是就出现了那个看似矛盾的场面:浏览器一切正常,某个软件死活不通,客户端的日志和延迟测试却全都是绿的。问题不在节点,不在订阅,而在这个软件根本没有把请求交给 Clash。

系统代理开关按下去,系统里发生了什么#

三件事,顺序如下:

1. 客户端在本机监听一个端口,等待接收请求。这个端口只对本机开放,外部访问不到(除非你打开了允许局域网连接)。
2. 客户端把「代理服务器地址 = 本机回环地址 + 该端口」写进操作系统的代理配置。Windows 写的是系统的 Internet 设置,macOS 写的是各网络接口的代理项。
3. 遵守这项配置的程序在发起网络请求前先读一次,读到之后把请求发给那个本地端口,而不是直接发往目标服务器。

遵守系统代理的程序 → 本机端口 → Clash 内核 → 按规则决定直连或走节点
不遵守的程序 ─────────────────────────────→ 直接连目标服务器

上面这张示意说明了全部要害:第二条路径完全绕开了客户端,所以你在客户端里做什么设置都影响不到它。想让第二条路径也被接管,只能换一种接管方式,也就是 TUN 模式。

哪些程序会遵守系统代理,哪些天然不会#

不存在一份绝对准确的名单,但有相当稳定的规律:

判断某个程序属于哪一类,不用查资料,看客户端的连接页最快:让它发起一次网络请求,连接页里出现对应记录就说明走了代理,一片空白就说明没走。这是唯一不依赖经验的判定方法。

对于「不会遵守但自带代理设置」的程序,还有中间路线:在它自己的设置里手动填上本机地址和 Clash 的端口。命令行工具则通常靠环境变量:

# 结构示例,端口号请换成你客户端里实际显示的数值
export http_proxy=http://127.0.0.1:7897
export https_proxy=http://127.0.0.1:7897

混合端口、HTTP 端口、SOCKS 端口该用哪个#

混合端口的存在意义就是让你只记一个数字。除非遇到某个程序明确要求填 SOCKS5 类型的代理并且填混合端口不工作,否则没有必要把它们分开。

填错类型的典型症状是:程序报「代理服务器拒绝连接」或者干脆卡住不动,但客户端日志里没有任何对应记录。这说明请求根本没被正确解析,换成混合端口再试一次通常就好了。

绕过局域网这一项要不要勾#

要勾,而且理由很硬:局域网地址在节点那一端并不存在。

不勾的后果是这些地址会被一并送进代理:路由器管理页面、家里的 NAS、局域网打印机、公司内网系统、以及本机自己开的开发服务。这些请求发到境外落地服务器上,对方只会返回「找不到」。表现出来就是「开了代理之后进不去路由器后台」,很多人会误以为是客户端和路由器冲突。

绕过范围通常包含本机回环地址、私有网段和本地主机名。默认配置已经覆盖了常见情况,需要额外加的一般只有公司内网的特定域名。

# 结构示例:内网域名可以单独加进绕过列表
bypass:
  - '127.0.0.1'
  - 'localhost'
  - '192.168.0.0/16'
  - '*.corp.example.invalid'

公司电脑上使用时要格外注意这一项。内网系统被误送进代理,轻则打不开,重则触发企业安全策略的告警,后者带来的麻烦远大于访问失败本身。

端口被别的软件占用了该怎么改#

先确认真的是冲突,而不是别的问题。冲突有两个明确特征:客户端日志里出现端口绑定失败之类的字样,或者启动之后系统代理设置里那个端口的请求被另一个程序接走了(表现为网页打开了完全不相干的内容)。

确认之后按顺序处理:

1. 把混合端口改成一个不常用的高位数值,避开常见服务占用的区间。
2. 重新打开一次系统代理开关,让新端口写进系统设置。这一步经常被忘记,结果是端口改了但系统还指向旧的。
3. 如果之前手动给某些软件填过代理端口,逐个改成新值。
4. 用浏览器做一次验证,确认链路恢复。

不要用「随便换个端口试试」的方式排查问题。端口一旦和系统设置、软件内的手工配置对不上,会制造出更难定位的假象。没有冲突证据时,保持默认值是最省事的选择。

退出客户端后上不了网,是怎么回事#

这是系统代理机制最经典的一个副作用。正常退出时客户端会把系统代理设置还原回去,但异常退出——被任务管理器结束、系统强制关机、更新时崩溃——就来不及做这一步。结果是系统里那条「所有请求都发给本机某端口」的配置留了下来,而那个端口后面已经没有程序在监听了。

现象很好认:整机所有浏览器都打不开网页,提示无法连接到代理服务器,而网络本身其实是通的。

处理方法有两个,都不需要重装:

• 重新打开客户端,让它把代理接管回去,然后正常退出一次。
• 或者直接去操作系统的网络代理设置里,手动关掉那个开关。

知道这个机制之后,还能反过来用它做判断:遇到整机断网时,先去系统代理设置里看一眼那项是开是关,能立刻区分是代理配置残留还是网络本身出了问题。更完整的分层排查思路在 Clash 教程总览里有说明。

什么时候必须从系统代理换成 TUN#

当目标程序属于「天然不遵守」那一类,并且它自己也没有代理设置项时,系统代理这条路就走到头了。常见的三种情况:

需要强调的是,换成 TUN 不是升级,而是换了一种代价不同的方案:它接管的范围更大,冲突面也更大。什么时候值得开、开之前要满足什么条件,在 TUN 模式什么时候必须开里有完整的判断清单。至于被接管的流量最终走节点还是直连,那是另一层的决定,由分流模式负责。

小结#

系统代理是一项写在操作系统里的建议,不是强制拦截,只有主动读取它的程序才会走 Clash。浏览器基本遵守,游戏、命令行工具和虚拟机里的程序基本不遵守,这是「开了代理某软件仍不通」的唯一根因。混合端口默认就够用,绕过局域网必须勾上,端口只在有冲突证据时才改,并且改完要重开一次系统代理让新值生效。退出后上不了网是设置残留,手动关掉系统代理即可恢复。需要覆盖那些天然不遵守的程序时,才轮到 TUN 出场。