「OpenClash 装了、规则也导入了，但有些应用走代理、有些死活不走」——这是 openwrt vpn 分流场景里最典型的症状。
我先把结论放前面：分流不是一个开关，是三层依次判断的结果。哪一层断了，症状都不一样。搞清症状对应哪一层，比反复改规则有用得多。
三层是这样的：
| 层 | 它管什么 | 断了的症状 |
|---|---|---|
| DNS 层 | 域名解析成哪个 IP | 有的网站能开有的打不开，或者开了是错的节点 |
| 规则层 | 这个 IP/域名该走哪条策略 | 全部流量走同一个出口，规则像没生效 |
| 转发层 | 设备的流量有没有进到 OpenClash | 某个设备或某个应用完全不受影响 |
下面按这个顺序拆。先说清楚一件事：**这篇写的是机制和排查顺序，不是「照抄就能用」的配置模板。**每个人的网络结构不同，我不在你那台设备上，给不出直接可用的配置。但排查的顺序是通用的。
完全不能用很容易发现，你会去修。部分应用不走才是最麻烦的——因为容易误判成「规则写错了」，然后花几个小时在规则集里翻，方向从一开始就错了。
这个症状有三个高度可疑的原因，按出现频率排：
这三个原因的症状都是「部分应用不走」，但修法完全不同。所以别急着改规则，先做定位。
这一层最容易被忽略，但它决定了后面两层的输入。
简单说：
两者最实际的差别在这里：
**fake-ip 下，凡是「不经过 DNS 解析、直接连 IP」的应用，拿不到假 IP，就绕过了整套分流逻辑。**这类应用不少——某些游戏客户端、某些 P2P 工具、部分安卓应用的硬编码 IP 请求，都属于这一类。这就是「部分应用不走」原因之二。
**redir-host 下，如果你另外还跑了 AdGuard Home 或自建 DNS，fake-ip 会抢答，导致上游 DNS 拦截完全失效。**广告过滤规则一条都不生效，就是这个原因。
所以选哪个不是喜好问题，取决于你还有没有别的 DNS 服务在上游：
想确认当前 dnsmasq 的上游有没有被 OpenClash 改写，SSH 进去看这条：
# 查看 dnsmasq 的上游服务器与 noresolv 设置
uci show dhcp.@dnsmasq[0] | grep -E 'server|noresolv'
# 期望在「用 AdGuard 接管」的架构里看到类似：
# dhcp.@dnsmasq[0].server='127.0.0.1#5553' （指向 AdGuard 的端口）
# dhcp.@dnsmasq[0].noresolv='1'
如果 server 指向的不是你期望的那个上游，说明 OpenClash 的「DNS 接管」把你的配置改掉了。关掉 OpenClash 的 DNS 接管，再改回来，然后重启 dnsmasq（来源：OpenWrt 与 OpenClash 项目文档中关于 DNS 劫持行为的说明）：
uci set dhcp.@dnsmasq[0].server='127.0.0.1#5553'
uci set dhcp.@dnsmasq[0].noresolv='1'
uci commit dhcp
/etc/init.d/dnsmasq restart
**这一步是整篇里最值得先做的。**因为它一旦错了，后面改多少规则都没用——流量根本没走到规则判断那一步。
确认 DNS 层没问题之后，才轮到规则。
规则匹配是有严格顺序的。主流内核（Mihomo / Clash Meta 系）的判断顺序大致是：
**只要前面任何一条命中，就立刻按那条走，不再往下看。**所以「规则写了但没生效」最常见的原因是：有一条更靠前的规则先命中了，你写的那条根本没被读到。
判断方法只有一个：看日志。看这条连接到底命中了哪条规则、走了哪个策略。
OpenClash 的日志在面板的「运行日志」页，或者 SSH 里直接跟：
tail -f /tmp/openclash.log
然后在客户端上访问一次那个「不走代理」的应用，回来看日志里对应的那条记录。日志会写清楚命中的规则名和最终走的策略。
如果日志里根本没有这次连接——恭喜，问题不在规则层，在转发层。跳到下一节。
如果日志里有，但策略不对——那就是规则顺序问题，去找那条抢先命中的规则，把它挪到后面，或者给你的规则加更精确的条件。
这一步我不建议「凭感觉调顺序」。日志已经告诉你答案了，照着改就行。
这一层的问题最隐蔽，因为配置界面看起来一切正常。
三种常见断裂：
**一、设备的网关/DNS 没指向旁路由。**旁路由方案下，靠主路由 DHCP 下发或设备手动指定。手动指定的设备，如果只改了网关没改 DNS（或者反过来），会出现「能上网但分流不生效」——因为流量走主路由直出了。
**二、应用绕过了系统代理。**这类应用有自己的网络栈，读自己的配置而不是系统设置。典型表现是：浏览器分流正常，但这个应用永远走本地网络。这种情况在代理层修不了，只能在该应用内部单独配置，或者用 TUN 模式在网络层强制接管。
**三、IPv6 被漏掉了。**这条特别值得说。很多分流配置只处理了 IPv4，局域网里 IPv6 是通的，于是支持 IPv6 的应用和服务会直接走 IPv6 出去，完全绕过你的规则。症状就是「一部分服务分流了，一部分没有」，而且很难联想到 IPv6。
验证方法很直接——从一台局域网设备发起请求，看它的出口到底是哪：
# 看出口 IP（注意：这里只看出口归属，不涉及任何具体服务）
curl -s https://ipinfo.io/ip
# 或者用国内可访问的接口
curl -s https://myip.ipip.net
如果某台设备的出口跟预期不符，就先查它的网关和 DNS 指向，再查 IPv6 有没有开。
上面三层都排完了还不生效，才考虑这一层。
**规则集是会过期的。**GEOIP 数据库、各种 rule-provider 的域名列表，都是定期更新的。一个半年没更新过的 GEOIP 库，判断「这个 IP 属于哪个地区」已经不准了，表现就是某些新服务分流错误（来源：Mihomo 项目对 GEOIP 数据库更新机制的说明）。
**内核版本也会影响行为。**Clash 内核分支很多（原版 Clash、Clash Premium、Mihomo/Clash Meta），同一个配置在不同内核上行为不完全一致。有些新语法只在新内核支持，老内核会静默忽略——配置文件不报错，但那几行等于没写。
这里给个务实建议：改动前先备份配置，改完先只测一条规则。一次性改五处再测，出问题你根本不知道是哪一处引起的。这和排查网络连通性是同一个思路，我在另一篇讲局域网共享排障时写过类似的分层法：Windows 局域网共享连不上：0x80070035 分五层排查——先测端口再谈应用，别一上来就翻应用层。
排查到最后，我发现很多人卡住不是因为技术不够，而是对这套东西的前提理解偏了。把这四个误解说清楚，能省掉不少弯路。
误解一：装了 OpenClash 就会自动分流。
不会。OpenClash 只是执行者，它按你给的规则执行。规则库里没有的域名，最后会落到 MATCH 那条兜底规则上——而兜底规则是你自己定的，可能是直连，也可能是走代理。所以「装了但没效果」往往不是故障，是兜底策略本来就是这样。
误解二：规则越多越全越好。
反过来。规则之间是有先后顺序的，一条规则命中就结束判断。规则集越长，互相抢先命中的概率越高，出问题时越难定位是哪条干的。我见过导入了几万条规则、结果自己新加的那条永远不生效的情况——因为前面有更宽的规则先拦下了。先从五条能说清楚目的的规则开始，跑通了再加。
误解三：旁路由模式下，家里所有设备自动生效。
不自动。旁路由方案里，主路由的 DHCP 还在正常发地址，设备默认拿到的网关是主路由。要让某台设备走旁路由，得让它的网关和 DNS 都指向旁路由——要么主路由 DHCP 里改，要么设备上手动设。只设网关不设 DNS，或者反过来，都会出现「能上网但分流不对」的怪现象。
误解四：TUN 模式和 redir-host 可以随便混用。
不能。TUN 模式是在网络层建一块虚拟网卡接管流量，redir-host / fake-ip 是应用层的透明代理模式，两者的接管范围不一样（来源：OpenClash 与 Mihomo 项目文档对运行模式的说明）。同时开会出现流量被接管两次或者互相绕过的情况，症状很随机——有时候能用，重启一次就不行了。选一种，别贪。
这四条误解有个共同点：都是把「工具」当成了「结果」。工具装上了不等于意图实现了，中间的判断逻辑得自己补上。
| 症状 | 最可能的原因 | 先查什么 |
|---|---|---|
| 全部流量走同一出口，规则像没生效 | 规则没命中，落到 MATCH | 看日志命中哪条规则 |
| 某些应用完全不受影响 | 应用自带代理，或 IPv6 绕过 | 该应用的内部设置、设备 IPv6 |
| 能上网但分流全乱 | 设备 DNS 没指向旁路由 | 设备的 DNS 设置 |
| 广告过滤一条都不生效 | fake-ip 抢答，上游被架空 | 切 redir-host |
| 新服务分流错误，老服务正常 | GEOIP 库过期 | 更新规则集与数据库 |
| 配置改了但没反应 | 内核版本不支持该语法 | 内核版本与语法匹配 |
我写这篇的起因是站里那篇OpenWrt安装OpenVPN和OpenClash实现分流只讲了怎么装起来，没讲装完之后分流不对怎么办。装起来只是开始，真正的成本在后续的排查上——而排查之所以难，是因为大多数人不知道这三层的存在，遇到问题只能一条条试。
所以我的建议是：
推荐的：动手前先把三层结构画出来（DNS → 规则 → 转发），遇到问题时先判断症状属于哪一层，再看那一层的具体配置。这个习惯能省掉大量瞎改。
推荐的：改配置前备份，改完只改一处、只测一处。分流配置的特点是互相影响，一次改多个变量，等于放弃定位能力。
不推荐的：从网上抄一份超长的规则集直接导入，然后指望它一次到位。规则集越长，规则之间的顺序冲突越多，出问题越难定位。先从几条明确的规则开始，跑通了再往上加。
不适合折腾的：如果你的需求只是「家里网络正常上网、不折腾分流」，别装这一套。旁路由方案相对安全（崩了不影响家人），但它的复杂度是真实存在的，装完之后维护它的人还是你。
最后一句：**分流的本质是「让流量按你的意图选择路径」，不是「装一个插件」。**插件只是执行者，判断逻辑要你自己想清楚。想清楚这一点，三层结构就是自然的事情，而不是需要背下来的清单。