很多人在配置代理时，总觉得分组策略是门玄学，习惯去各大论坛找一份现成的“完美配置”。现在很多人在用 smart 内核确实越来越智能，自带了很多强大的功能，但客观来说，这种内核很重，而且再聪明的智能内核，也很难做到完全了解每个人的具体网络环境和使用习惯。
分流这东西其实并不复杂。授人以鱼不如授人以渔，今天就简单梳理一下分流的底层逻辑，分享一下怎么根据自己的实际痛点，写出一套真正“一劳永逸”的规则。
一、 核心痛点拆解
首先，大前提很明确：墙内默认直连（ DIRECT ）。
对于墙外的普通网站，我们的核心诉求无非两个：既要 IP 稳定不乱跳，又要低延迟。 理清了这点，节点分组的思路就出来了：所有节点直接按地区分（比如香港、日本、韩国、新加坡、美国、英国等），然后按需分配策略。
二、 策略组怎么选？看你重“求稳”还是重“速度”
1. 忌讳 IP 乱跳的用户
如果你对 IP 稳定性要求很高（比如容易被风控的网站），每个地区分组可以使用 load-balance （负载均衡），并配合以下两个参数：
consistent-hashing：将相同“目标地址”的请求，分配给策略组内的同一个节点。
sticky-sessions：将相同“来源地址+目标地址”的请求分配给同一个节点，并设置个 10 分钟缓存过期。
这样一来，就能有效避免访问同一个网站时 IP 反复切换的问题。
2. 追求极致速度的用户
如果你无所谓 IP 乱跳，只要快就行，那直接设置成 url-test （自动测速选择）。
建议把测速间隔 interval 设为 300 秒。如果你的节点太多，怕测速太频繁导致连接数爆炸，记得加上 lazy: true （懒惰状态）。默认为 true 时，只要没选中当前策略组，它就不进行测试，非常节省资源。
三、 默认 Proxy 组的兜底逻辑
各地区分好了，默认的 Proxy 分组怎么设置？推荐用 fallback （可用性测试）。
按节点的物理延迟，把地区组从低到高排个序。比如：香港节点延迟 30ms 排第一，新加坡 60ms 排第二，美国 160ms 排第三。
划重点： 排序的最后一个，一定要加一个 DIRECT 兜底！万一哪天节点失效了，那些墙外但其实能直连的“漏网之鱼”也不至于跟着彻底断网。
其实，一般人折腾到这一步就已经完全够用了。在你的 rules: 底下，只需要保留这两条极简的兜底规则：
- GEOIP,CN,DIRECT
- MATCH,Proxy
就能舒舒服服地实现国内外最快速的自动分流，日常上网毫无压力。
四、 进阶定制：AI 、流媒体与特殊 App
如果有更高阶的需求，可以在基础架构上继续添加特定分组：
AI 专属组： 比如某些 AI 服务不能用香港节点，那就新建个“AI 分组”，把不可用的地区剔除。剩下的节点依然用 fallback ，按延迟从低到高排序。
流媒体分组： 奈飞不想看日区，只想看美区？同理，建个分组，把不能用的地区全剔除，剩下的按喜好或者按延迟排序。
特殊应用专治： 比如 The Weather Channel 的 App ，一检测到非美国 IP 就直接闪退。这种完全不需要搞复杂的分组，直接在 rules: 下方单独写死一条规则，分配给美国组就行。
:warning: 防翻车提示： 配置文件里的规则是自上而下匹配的，匹配到了就不再往下看。所以你自定义的 App 规则一定要写在最前面。而列表的最底下，永远是刚刚提到的那两个雷打不动的兜底规则（ GEOIP 和 MATCH ）。
五、 测速专属分组 (Speedtest)
最后单独说下测速。你可以把所有国内外测速网站的规则集，全指定到一个名为 Speedtest 的特殊分组里。
这个组不需要 url-test ，也不要 fallback ，直接用 select （手动选择）。
选项列表里依次放入：第一条 DIRECT ，然后 Proxy ，接着是各个地区分组，或者你想单独测速的特定节点名称。平时不用管，想测谁的速度就手动选谁，干脆利落。
按照这套逻辑去设置，只要你的节点没有全部失效，平时基本是不需要去手动切节点的，真正做到一劳永逸。
分流这东西其实并不复杂。授人以鱼不如授人以渔，今天就简单梳理一下分流的底层逻辑，分享一下怎么根据自己的实际痛点，写出一套真正“一劳永逸”的规则。
一、 核心痛点拆解
首先，大前提很明确：墙内默认直连（ DIRECT ）。
对于墙外的普通网站，我们的核心诉求无非两个：既要 IP 稳定不乱跳，又要低延迟。 理清了这点，节点分组的思路就出来了：所有节点直接按地区分（比如香港、日本、韩国、新加坡、美国、英国等），然后按需分配策略。
二、 策略组怎么选？看你重“求稳”还是重“速度”
1. 忌讳 IP 乱跳的用户
如果你对 IP 稳定性要求很高（比如容易被风控的网站），每个地区分组可以使用 load-balance （负载均衡），并配合以下两个参数：
consistent-hashing：将相同“目标地址”的请求，分配给策略组内的同一个节点。
sticky-sessions：将相同“来源地址+目标地址”的请求分配给同一个节点，并设置个 10 分钟缓存过期。
这样一来，就能有效避免访问同一个网站时 IP 反复切换的问题。
2. 追求极致速度的用户
如果你无所谓 IP 乱跳，只要快就行，那直接设置成 url-test （自动测速选择）。
建议把测速间隔 interval 设为 300 秒。如果你的节点太多，怕测速太频繁导致连接数爆炸，记得加上 lazy: true （懒惰状态）。默认为 true 时，只要没选中当前策略组，它就不进行测试，非常节省资源。
三、 默认 Proxy 组的兜底逻辑
各地区分好了，默认的 Proxy 分组怎么设置？推荐用 fallback （可用性测试）。
按节点的物理延迟，把地区组从低到高排个序。比如：香港节点延迟 30ms 排第一，新加坡 60ms 排第二，美国 160ms 排第三。
划重点： 排序的最后一个，一定要加一个 DIRECT 兜底！万一哪天节点失效了，那些墙外但其实能直连的“漏网之鱼”也不至于跟着彻底断网。
其实，一般人折腾到这一步就已经完全够用了。在你的 rules: 底下，只需要保留这两条极简的兜底规则：
- GEOIP,CN,DIRECT
- MATCH,Proxy
就能舒舒服服地实现国内外最快速的自动分流，日常上网毫无压力。
四、 进阶定制：AI 、流媒体与特殊 App
如果有更高阶的需求，可以在基础架构上继续添加特定分组：
AI 专属组： 比如某些 AI 服务不能用香港节点，那就新建个“AI 分组”，把不可用的地区剔除。剩下的节点依然用 fallback ，按延迟从低到高排序。
流媒体分组： 奈飞不想看日区，只想看美区？同理，建个分组，把不能用的地区全剔除，剩下的按喜好或者按延迟排序。
特殊应用专治： 比如 The Weather Channel 的 App ，一检测到非美国 IP 就直接闪退。这种完全不需要搞复杂的分组，直接在 rules: 下方单独写死一条规则，分配给美国组就行。
:warning: 防翻车提示： 配置文件里的规则是自上而下匹配的，匹配到了就不再往下看。所以你自定义的 App 规则一定要写在最前面。而列表的最底下，永远是刚刚提到的那两个雷打不动的兜底规则（ GEOIP 和 MATCH ）。
五、 测速专属分组 (Speedtest)
最后单独说下测速。你可以把所有国内外测速网站的规则集，全指定到一个名为 Speedtest 的特殊分组里。
这个组不需要 url-test ，也不要 fallback ，直接用 select （手动选择）。
选项列表里依次放入：第一条 DIRECT ，然后 Proxy ，接着是各个地区分组，或者你想单独测速的特定节点名称。平时不用管，想测谁的速度就手动选谁，干脆利落。
按照这套逻辑去设置，只要你的节点没有全部失效，平时基本是不需要去手动切节点的，真正做到一劳永逸。
Select Language