OpenClash规则和直连模式TCP连接慢，全局模式正常OpenClash开启后网页转圈怎么查
路由器系统是 iStoreOS 22.03.7，具体版本号是 Powered by LuCI istoreos-22.03 branch (git-24.339.46321-5f9267c) / ArgonTheme v2.2.10.10 / iStoreOS 22.03.7 2024120615，OpenClash 版本是 0.46.075。网络这边是三条宽带先进 iKuai 做负载均衡，比例 1:1:1，然后 iStoreOS 直连 iKuai，局域网设备要么走交换机，要么直接接在 iStoreOS 下面[reference:0]。
一开始其实没那么慢。刚开始用的时候一切正常，是后来局域网设备数慢慢加上去之后，问题才冒出来的。iStoreOS 里显示的连接数大概在一万三千左右，也不知道这个数字算不算夸张，反正就在这个量级下，OpenClash 的毛病开始露头了[reference:1]。
先确认是不是上级网络的锅
遇到网络慢，第一反应肯定是先甩锅给上游。于是我做了个很简单的对照：把电脑用网线直接插到上级 iKuai 路由上，OpenClash 该开还开着，规则模式也没动，然后快速连续打开一堆网页——百度、知乎，随便点。结果是快的。网页一个接一个弹出来，没有那种卡在半路的感觉。行，至少说明 iKuai 那边的出口和负载均衡本身没什么大问题，锅不在上级[reference:2]。
把电脑插回 OpenClash 所在的 iStoreOS，问题复现了
然后我把网线拔下来，插到跑 OpenClash 的那台 iStoreOS 路由上。还是规则模式，还是快速打开多个百度网页。这次不一样了，网页一直转圈，圈儿转得人心烦，甚至有的页面直接打不开。这就很难受了——同一个网络出口，只是中间隔了一台跑 OpenClash 的路由器，表现差这么多。问题基本上就锁定在 OpenClash 这台设备身上了[reference:3]。
直连模式也慢，这就有点反直觉
按理说，规则模式慢可能是因为规则匹配、分流判断这些环节拖了后腿。那我把模式切成“直连”试试呢？直连模式在逻辑上应该尽量少碰流量，让数据包直接出去。结果一测，和规则模式一模一样，还是慢，还是转圈，还是打不开[reference:4]。
这就有点意思了。规则慢还能理解成规则集太重、DNS 分流在折腾；直连也慢，说明问题不在“规则匹配”这个层面，更像是 OpenClash 在更底层的地方把什么东西给绊住了。
全局模式反而不慢
接着试全局模式。线路选了日本、韩国、美国这些，流量全部往代理走。按理说绕了一圈国外，访问百度应该更慢才对。但实际表现是：虽然速度确实算不上飞快，毕竟数据绕了远路，但浏览器转圈并不明显，页面很快就加载完了[reference:5]。
测试做到这里，结论开始变得有点“歪”了：规则模式慢，直连模式也慢，偏偏全局模式不慢。 这跟通常“代理拖慢网速”的直觉是反着来的。如果代理本身是瓶颈，那全局模式应该最慢才对。可现实是全局模式反而是三个里面最能让人正常打开网页的那个。关掉 OpenClash 当然最快，这个不用多说，但也等于把问题绕过去了，不算解决[reference:6]。
翻到一个老 issue，但没有完全对上
碰到这种怪现象，肯定会去翻 issue。我在 OpenClash 仓库里搜了一轮，找到一个比较相关的：#300。那个 issue 说的是“路由器开启 OpenClash 国内访问变慢”，听起来很像，但仔细一看不完全是一回事。我这边的问题不是“国内慢、国外快”，而是规则和直连模式下整体都慢，全局模式反而没这个毛病[reference:7]。
不过 #300 里给了一个挺有用的思路：用 httpstat 去拆解一次 HTTP 请求的各个阶段，看时间到底耗在哪一段。DNS Lookup、TCP Connection、Server Processing，一段一段看，比单纯“体感慢”要靠谱得多。我在 Mac 上用 brew install httpstat 装了一个，然后开始对着测[reference:8]。
httpstat 把问题指到了 TCP Connection
测试结果整理出来是这样的：
测试1：OpenClash 开启，规则模式或直连模式。 DNS Lookup 很快，Server Processing 也不慢，唯独 TCP Connection 很慢。也就是说，域名解析没问题，目标服务器处理请求也没问题，卡就卡在“TCP 连接建立”这一步。握手阶段被什么东西拖住了[reference:9]。
测试2：OpenClash 开启，全局模式。 DNS Lookup 快，TCP Connection 不慢，Server Processing 也不慢。三段都正常，和体感上“全局模式虽然绕路但能打开”是对得上的[reference:10]。
测试3：关闭 OpenClash。 三段全部正常，TCP Connection 也很快，网页加载干脆利落[reference:11]。
把这三个结果摆在一起，问题就集中到一句话上了：OpenClash 在规则模式和直连模式下，把 TCP 连接的建立过程拖慢了；全局模式反而没有触发这个拖慢机制。 DNS 层面看起来是干净的，fake-ip 那套配置也在跑，但至少从 httpstat 的观测来看，耗时不在 DNS Lookup 上[reference:12][reference:13]。
所以现在能确定什么，不能确定什么
能确定的是：问题确实由 OpenClash 开启引起，不是上级 iKuai 的负载均衡，也不是单纯的宽带出口问题。触发条件跟“规则模式 / 直连模式”有关，跟“全局模式”无关，而且似乎和局域网设备数量、连接数上来了才有关系，一开始设备少的时候并不会这样[reference:14]。
不能确定的是根因。TCP Connection 慢可以有很多种可能：TUN 模式的处理路径、防火墙规则对新建连接的影响、某种内核模块或者依赖在特定模式下的行为，甚至和 iStoreOS 那个版本的 Firewall3 / Firewall4 环境都有关系。issue 里 OpenClash Log 是空的，没有直接报错，配置那边 port 是 7890，socks-port 是 7891，mode 是 rule，dns 的 enhanced-mode 是 fake-ip，看起来不是那种一眼就能看出毛病的配置[reference:15]。
接下来准备往哪儿查
既然 httpstat 已经指向了 TCP 握手阶段，下一步就不太适合继续在“规则写没写对”上面打转了。更值得看的方向大概是这几个：OpenClash 依赖包是否完整，尤其是 iptables / ip-full / kmod-tun 这一类跟流量接管直接相关的东西；TUN 模式或者流量接管方式在规则/直连下和全局下是不是走了不同的路径；以及当前固件环境的防火墙后端跟 OpenClash 的规则链到底对不对得上[reference:16][reference:17]。另外，连接数一万三这个量级本身也值得留意——是不是在某个连接数阈值之后，新建连接的处理开销突然上来了，而不是 OpenClash 从第一秒开始就慢。
这篇就先记到这儿。问题还没收口，但至少方向从“网络整体慢”缩到了“规则和直连模式下 TCP 新建连接被拖住，全局模式绕开了”。后面如果有进展，再接着写。
点击链接加入群聊四群：722808830
点击链接加入群聊三群：751529538（已满）
点击链接加入群聊二群：376877156（已满）
点击链接加入群聊一群：622891808（已满）
饿了么红包
本站附件分享，如果附件失效，可以去找找看
