快喵VPN 分流决策台：直连与代理到底按什么判定

结论先行：快喵VPN 的分流判定按「手动锁定 → 黑白名单 → 域名 → 网段 → 应用 → 默认出口」六层顺序执行，命中即停，不再往下匹配。在 2026-11-11 的本地演练环境里，214 条规则的平均匹配耗时低于 0.1 毫秒。

下载客户端对照规则 先看判定依据

一句话结论：分流不是「打开开关就行」，而是给每一条请求找到归属依据。快喵VPN 把归属依据固定为六层顺序、四个判定维度与三种可写规则，掌握这套结构后，规则写错时能直接定位到是哪一层的问题。

判定台怎么用：三步看清一条流量的去向

分流这件事的难点不在于记住某个域名该填代理还是直连，而在于知道「这条请求凭什么被判成这样」。判定台把这个过程拆成三步，每一步都有可观测的输出。

第一步：确认判定走的是哪一层

客户端的状态页会显示当前生效的规则来源，例如「域名规则命中」或「默认出口」。如果显示的是默认出口，说明前面五层都没有匹配上，需要回到规则表补条目，而不是反复重连。

第二步：确认归属方向

归属只有两个方向：直连与代理。本地网段、国内站点、公司内网系统通常判为直连；需要跨境访问的站点与外服游戏判为代理。方向判反的典型表现，是能打开页面但速度没有变化。

第三步：确认优先级是否被更高层覆盖

同一个域名可能同时出现在黑白名单和域名规则里。此时生效的是层级更高、位置更靠前的那一条。演练环境里统计过，62% 的「规则不生效」反馈，实际原因都是被上层条目覆盖。

判定依据：四个维度决定一条流量的归属

规则表里的每一条都属于某个维度。搞清楚维度，才能判断一条规则该不该写、写在哪一层。四个维度分别是域名、网段、应用与用户名单。

维度一：域名，最常用也最易写错

域名维度靠后缀、关键字与完整域名三种匹配方式覆盖站点。写「netflix.com」只覆盖主站，实际播放地址常在另一个后缀下，所以追剧类规则通常要写两到四条。

维度二：网段，覆盖内网与运营商出口

网段维度处理的是 IP 而不是域名。本地局域网、云主机的固定网段、运营商自己的服务地址，都属于这一层。写成 CIDR 形式，一条规则可以覆盖一整段地址。

维度三：应用，按进程区分客户端

应用维度让同一个域名在不同程序里走不同出口。桌面端的游戏客户端与浏览器可以分开判定，移动端则按包名区分，这是移动端规则与桌面端写法不同的根本原因。

维度四：用户名单，手工维护的例外

名单维度是使用者自己维护的一组例外，通常放在最上层，用来压过所有自动规则。练习环境里最常见的用法，是把某个必须直连的内部系统加进直连名单。

决策树：一条请求从进入到出口

下面这棵树是本站所有规则示例的骨架。任何一条分流失败，都可以从树上的某一层找到原因，不必从头排查。

第一层与第二层：为什么它们能压过一切

手动锁定和黑白名单是使用者表达明确意图的入口，客户端把它们放在最前面，就是为了让「我明确指定过」这件事永远不被自动规则推翻。演练环境里，把三条强制直连放进名单层后，同名冲突从每周 6 次降到 0 次。

第三层：域名规则承担大部分判定

在 214 条规则的演练表里，域名层占了 138 条，占比 64%。原因是绝大多数跨境访问的目标都是网站，而网站最容易用域名描述。剩下两层更多是补充与兜底。

第四层与第五层：为什么放得这么靠后

网段与应用层的匹配成本高于域名，且一条网段规则的覆盖面通常大于一条域名规则。把它们放在后面，可以让常见场景尽快结束判定。在实测中，域名层平均命中位置是第 11 条，比网段层靠前得多。

兜底层：默认出口决定兜底方向

默认出口有三种可选值：全部代理、全部直连或按地区均衡。对以海外服务为主的用户，全部代理最省心；对以本地服务为主的用户，全部直连能减少无谓的绕路。多数场景建议保持全部代理兜底。

三分流并排：追剧、游戏、办公的归属差异

三类流量的共同点是都跨境，差别在于判定依据不同。追剧看域名集合，游戏看应用与地址段，办公看内网与服务域名。把三类并排放在一起，差异会显得很清楚。

为什么三类流量不能套同一套规则

三类流量的判定对象不同。追剧的对象是网页地址，游戏的地址分散在域名与进程两处，办公还多出一层必须直连的内网。把同一份规则表复制给三类场景，结果通常是两类好用、一类出问题。

追剧流量的判定特征

追剧的特征是域名多、流量大、持续时间长。判定重点是覆盖完整，而不是速度优先。演练环境里，用 6 条规则覆盖一个追剧服务的全部播放分片后，起播失败次数从每百次 4 次降到每百次 1 次。

外服游戏的判定特征

游戏的特征是应用与域名混合，且伴随独立的匹配与更新服务。判定重点是把这几类服务一次写全。漏掉更新服务时，客户端会停在更新界面，表现为「游戏打不开」而不是「连不上」。

跨国办公的判定特征

办公的特征是双向需求，而且直连侧的失败往往更严重。内网系统走代理时，轻则登录变慢，重则被安全策略判定为异常登录。所以办公规则应当从名单层开始写。

判定 chip 的六种状态与含义

客户端会用状态标记表达一条请求的判定结果。看懂这六种标记，就能从现象反推规则层的问题。下面是各状态与对应动作的对照。

两种容易混淆的状态

「代理」与「域名命中」经常被当成一回事。前者只说明方向是代理，后者才说明判定依据来自域名层。如果状态显示「代理」而不是「域名命中」，说明规则来自应用层或默认出口，此时改域名规则不会有任何效果。

状态标记的采样时机

状态页显示的是最近一次请求的判定结果，不是全量统计。演练环境里打开状态页连续访问 10 个站点，会看到状态在几个标记之间跳动，这是正常现象。要判断规则覆盖是否完整，需要看本地日志里的统计口径。

规则优先级：谁先生效

优先级不是模糊的「大概按顺序」，而是可以精确到条目的顺序。演练环境里做过一次对照实验：把同一域名分别放在不同层，观察判定结果变化，规律完全稳定。

同层规则为什么要往前写

同层条目互不覆盖，位置靠前的先被采用。日常维护中，例外条目应该写在同层开头，否则每次新增规则都要重新计算位置。演练环境里把例外统一放在每层首行后，新增规则的误判次数从每月 11 次降到 2 次。

跨层冲突怎么排

跨层冲突由层级决定，与书写顺序无关。遇到「明明写了代理却不生效」的情况，先确认那条规则所在层级是否低于另一条命中规则。跨层冲突占全部反馈的 38%，是排查时最值得先看的一项。

# 注释行：以井号开头，不参与匹配
DOMAIN,direct.internal.example,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
DOMAIN-SUFFIX,example-video.com,PROXY
DOMAIN-SUFFIX,example-cdn.net,PROXY
DOMAIN-KEYWORD,gameupdate,PROXY
PROCESS-NAME,ExampleGame.exe,PROXY
FINAL,PROXY

直连与代理的收益区间

分流的意义在于把流量放到更合适的通道上。下面是本地演练环境下两类通道的实测对照，用于判断某条流量是否值得改写，而不是描述理论上限。

什么时候改写方向才有意义

只有当当前通道明显不合适时，改写方向才有意义。演练对照显示，把境外站点从直连改为代理，首屏时间从 6.8 秒降到 1.2 秒；而把本地站点从直连改成代理，首屏时间反而从 0.4 秒升到 1.9 秒。

大文件与长连接的特殊性

大文件下载与长连接服务不适合用首屏时间衡量。下载看的是持续吞吐，长连接看的是稳定性。这两类流量的方向判断，应以「是否需要跨境」为准，而不是以当前速度为准。

规则写法：域名、网段、应用三种

三种写法的差别在于匹配对象不同。域名写法面向网站，网段写法面向地址段，应用写法面向程序。下面每种给出可直接对照的示例。

域名写法：后缀、关键字与完整域名

后缀写法覆盖主域与全部子域，是追剧类规则的默认选择。关键字写法用于分片域名多的站点。完整域名写法只覆盖一个地址，适合公司后台这种确定地址。

DOMAIN-SUFFIX,example-video.com,PROXY
DOMAIN-SUFFIX,example-cdn.net,PROXY
DOMAIN-KEYWORD,streamsegment,PROXY
DOMAIN,portal.example-corp.com,PROXY
DOMAIN,update.example-game.com,PROXY
DOMAIN-SUFFIX,example-intranet.local,DIRECT

网段写法：CIDR 段与解析选项

网段写法用一段地址范围代替单个地址。是否附加解析选项，取决于这条规则是否需要触发域名解析，演练环境里的建议是本地网段一律附加该选项。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
IP-CIDR,169.254.0.0/16,DIRECT,no-resolve

应用写法：桌面端与移动端

桌面端按可执行文件名填写，移动端按应用包名填写。同一款应用在两端的名字并不相同，这是跨端迁移规则时最常出问题的一步。

PROCESS-NAME,ExampleGame.exe,PROXY
PROCESS-NAME,ExamplePlayer.exe,PROXY
PROCESS-NAME,ChatClient.exe,DIRECT
ANDROID,com.example.game,PROXY
ANDROID,com.example.player,PROXY
ANDROID,com.example.office,DIRECT

三类流量的完整规则示例

下面三段是按上一节的三类场景拼出的完整片段。每段都能直接放进客户端的分流设置里试用，先在小范围里验证再扩大。

追剧片段：覆盖主站与全部播放分片

这一段共 6 条，包含主站后缀、两个播放分片后缀与一个关键字写法。用关键字兜住未列出的分片域名，是追剧类规则最省事的一种做法。

# 海外追剧：主站与播放分片全部走代理
DOMAIN-SUFFIX,example-video.com,PROXY
DOMAIN-SUFFIX,example-video.net,PROXY
DOMAIN-SUFFIX,example-cdn.net,PROXY
DOMAIN-SUFFIX,example-media.org,PROXY
DOMAIN-KEYWORD,streamsegment,PROXY
DOMAIN-SUFFIX,example-pay.com,DIRECT

游戏片段：匹配、更新与本体分开写

这一段共 7 条，把本体进程、更新域名与匹配服务写在一起。更新与匹配服务漏写时，现象是停在更新界面或匹配不到对局，而不是直接报连接错误。

# 外服游戏：本体、更新、匹配三组分别写全
PROCESS-NAME,ExampleGame.exe,PROXY
DOMAIN-SUFFIX,example-game.com,PROXY
DOMAIN-SUFFIX,example-game.net,PROXY
DOMAIN-KEYWORD,gameupdate,PROXY
DOMAIN-KEYWORD,matchmaker,PROXY
DOMAIN-SUFFIX,example-anticheat.com,PROXY
PROCESS-NAME,Launcher.exe,DIRECT

办公片段：内网直连与境外后台并行

这一段共 8 条，前 4 条保证内网与协作系统直连，后 4 条让境外后台走代理。两条方向相反的规则同时存在时，必须确认它们不在同一层互相覆盖。

# 跨国办公：内网直连，境外后台走代理
DOMAIN-SUFFIX,example-corp.com,DIRECT
DOMAIN-SUFFIX,example-intranet.local,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
DOMAIN,portal.example-corp.com,PROXY
DOMAIN-SUFFIX,example-saas.com,PROXY
DOMAIN-SUFFIX,example-docs.com,PROXY
DOMAIN-KEYWORD,officecdn,PROXY

什么时候不该分流

分流不是所有场景都需要。全量代理、全量直连与不分流，各自对应不同的处境。下面列出可以停止折腾的几种情况。

需要固定出口的场景

部分业务系统会把登录态与出口地址绑定。一旦某个域名被判为代理，登录后跳转到另一地址时就会切到另一个出口，表现为刚登录就被登出。这类系统要放进名单层的直连集合。

公司网络与受管终端

受管终端的网络策略通常禁止修改路由表。这类环境下分流规则可以保存，但不会生效，表现为规则状态一直显示未命中。遇到这种情况应先确认制度，而不是反复重写规则。

刚上手时先跑默认配置

默认出口下所有请求走同一通道，行为最容易预测。演练环境里，先用默认出口观察一周，把真正需要分流的流量记下来，再针对这几类写规则，比一次性写 200 条规则更省事也更可控。

分流失败的四种典型表现

分流失败的表现并不直观，同一个现象可能来自不同的层。下面按现象分组，每组给出对应的第一排查动作。

表现一：规则写了却完全不生效

先确认规则的层级。写在低层、而高层已有匹配条目时，低层规则永远不会被读到。演练环境里这一类占失败反馈的 38%，把规则提到名单层后立刻恢复。

表现二：目标站点仍然打不开

先看该次请求的判定状态。如果显示未命中，说明规则表缺少这个域名或进程；如果显示代理却打不开，问题多半在链路上，而不是规则上。此时应转到 分流失败排查 逐项确认。

表现三：速度没有变化

速度没有变化通常意味着判定方向与预期相反，或者流量本来就不大。用同一个站点在直连与代理两种设置下各测一次首屏时间，两次差异小于 0.3 秒时，判定是否生效都难以确认。

表现四：改了规则之后别的站点坏了

这是覆盖面过宽的典型表现，例如用关键字写法时选中了过于通用的词。演练环境里把关键字从 example 改成 exampleupdate 后，受影响的目标从 31 个降到 2 个。修改关键字后应重新验证一遍原有目标。

判定自查清单

下面这份清单按排查顺序排列，每一项都给出可观测的判断依据。逐项确认后，多数分流问题能定位到具体一层。

清单为什么按这个顺序

前五项都是规则表本身的问题，占失败反馈的大多数。后五项涉及客户端行为与环境，逐项确认能避免在规则上反复改。后两项需要打开本地日志，属于最终确认手段。

多久做一次完整自查

规则表改动之后做一次完整自查，平时不必天天做。演练环境的建议节奏是：改动当天查一次，两周后再查一次，确认没有新增的未命中目标。

常见误判的一句话修正

分流反馈里最常见的就是下面这九种。下面把它们并排放在一起，每种给出现象、原因与一句话修正。

九种误判的分布

前三种占全部误判的 46%，它们都发生在规则表里，而且都不需要重写条目内容，只需要调整位置或补一条。其余六种分布在场景细节与环境上。

为什么误判总集中在前三类

因为判定顺序是固定的，规则的生效位置也就固定。多数问题不是写得不对，而是写在了会被压住的位置。把例外前置，是性价比最高的一次整理。

三类场景的最小规则集

如果只想先跑起来，下面三段是最小可用集合。每段都能独立生效，补齐之后再按场景页扩展。

最小集一：追剧四条

四条覆盖主站、播放分片与关键字。覆盖不全时表现为播放缓冲，补齐分片后缀即可解决。

DOMAIN-SUFFIX,example-video.com,PROXY
DOMAIN-SUFFIX,example-cdn.net,PROXY
DOMAIN-SUFFIX,example-media.org,PROXY
DOMAIN-KEYWORD,streamsegment,PROXY

最小集二：游戏五条

五条覆盖本体、更新与匹配。最容易漏的是更新服务，漏写时现象是停在更新界面而不是连不上。

PROCESS-NAME,ExampleGame.exe,PROXY
DOMAIN-KEYWORD,gameupdate,PROXY
DOMAIN-KEYWORD,matchmaker,PROXY
DOMAIN-SUFFIX,example-game.com,PROXY
DOMAIN-SUFFIX,example-anticheat.com,PROXY

最小集三：办公六条

六条包含内网直连与境外后台代理两个方向。少了名单层那一条，登录后的跳转会落到默认出口。

DOMAIN,login.example-corp.com,DIRECT
DOMAIN-SUFFIX,example-corp.com,DIRECT
DOMAIN-SUFFIX,example-saas.com,PROXY
DOMAIN-SUFFIX,example-docs.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

最小集与完整表怎么选

最小集适合先跑通，完整表适合长期使用。演练环境里最小集平均 62.5% 的正确率已经能覆盖大部分日常使用，完整表则把正确率推到 90% 以上。

这套判定做不到的五件事

把边界写清楚，比只讲能力更有用。下面五条是分流判定本身无法覆盖的情形。

做不到一：不能替代链路质量判断

规则只决定流量走哪条路，走哪条路之后是否顺畅，取决于链路状况。判定正确但链路拥塞时，用户看到的仍然是慢。这两件事必须分开看。

做不到二：不能覆盖未知的关联域名

写规则只能覆盖已知域名。服务方新增接口域名时，规则表不会自动跟进。演练环境里每季度约有 3 到 5 个新增接口域名需要补写，这部分只能靠观察发现。

做不到三：不能保证出口地址稳定

判定为代理的流量，出口地址取决于当时选中的节点。需要出口稳定的业务必须锁定固定节点，这属于节点层面的事，不是规则层面能解决的。

做不到四：不能识别语义相同的不同域名

规则匹配的是字符串。同一项服务在不同地区使用不同域名时，无法自动归并。这类情况只能在名单层手工列出。

做不到五：不能在受管网络里生效

受管网络禁止修改路由时，规则可以保存但不会生效。这一点在排查早期就要确认，否则容易把时间浪费在改规则上。

快喵VPN 的分流取舍

快喵VPN 在分流上的取舍集中在三点。这些取舍决定了你打开客户端后看到什么，也决定了哪些设置值得手动改。

取舍一：层级固定，不提供自定义排序

客户端固定六层顺序，不允许把域名规则提到名单层之前。好处是行为可预期，坏处是使用者无法表达「这条域名规则比名单更优先」。这一取舍换来了规则表的可解释性。

取舍二：默认出口统一为全部代理

新装客户端的默认出口是全部代理，而不是自动分流。理由是默认行为越简单越好判断。代价是第一次使用时本地流量也会绕路，需要使用者主动加直连条目。

取舍三：规则表本地保存

规则表保存在本地，不随账号同步。这样换设备时需要重新配置，但同一台设备上的规则不会被其他操作覆盖。演练环境里，一台设备上的规则条数在 30 天内被外部改动的情况为 0 次。

采样环境与数据口径

本站所有读数都来自编辑部在固定环境下的演练，记录口径如下，便于你判断这些数字的适用范围。

为什么只记录判定状态

判定状态与耗时足以支撑本页的全部结论，而访问地址属于个人隐私范畴，不应出现在任何公开记录里。演练环境通过本地回环生成流量，因此不产生真实访问痕迹。

两个时段为什么分开测

上午与晚间两段的规则命中分布不同。晚间访问更密集时，未命中条目被触发的次数更多，默认出口层的占比会上升。分开记录能看清这种差异，而不是把两段混成一条曲线。

判定层与规则写法的对应速查

下面这张表把六层判定、各类写法与常见目标一次对齐，排查时可以先在这里定位到层，再去看具体写法。

速查表的使用顺序

先看状态标记确定层，再用这张表找到对应写法与常见问题，最后到规则页看写法细节。三步之间是递进的，不必从头读。

各层修正动作的耗时

不同层的修正动作耗时差别很大。名单层与默认出口属于设置项改动，几分钟就能改完；应用层的核对则要逐条比对，耗时最长。

常见问题

下一步读哪一页

判定台的结论到这里已经说完。下面几页分别对应四个更具体的问题，按需要取用即可。