快喵VPN 直连与代理判定：六层顺序与四个维度

一句话结论：判定这件事没有玄学，只有顺序。一条流量从进入客户端到选定出口，最多经过 6 次比对，每一次的依据都能在规则表里指出来源。

判定从哪一层开始

六层顺序是客户端 v4.2.0 的固定行为，使用者无法调整。这个设计牺牲了一部分灵活性，换来的是任何判定结果都能被解释。下面逐层说明。

第 1 层：手动锁定只有一条

手动锁定是全局唯一的开关，锁定后所有流量走同一方向，不再逐条比对。它的作用是临时把所有流量压到一条通道上，用来验证链路本身是否正常，而不是长期使用。

第 2 层：名单层是使用者的例外集

名单层由使用者自己维护，条目数量通常在 10 条以内。它的价值在于压过所有自动规则，让「必须直连的内网系统」这类要求不受后续改动影响。

第 3 层：域名层承担大部分判定

域名层在演练规则表里占 138 条，占全部条目的 64%。绝大多数跨境访问的目标都是网站，而网站最容易用域名描述，所以这一层承担了主力工作。

第 4 层与第 5 层：补充与兜底

网段层负责本地网段与固定地址段，应用层负责按程序区分。两层的条目数合计占 32%，作用是覆盖域名层表达不了的场景。

第 6 层：默认出口承接全部未命中

前五层都没有命中时，请求走默认出口。新装客户端的默认出口是全部代理，所以刚开始使用时所有流量都经过隧道，直到使用者补齐直连条目。

直连判定的四种依据

判定为直连，意味着请求由本地网络直接发出，不经过隧道。支撑这个方向的依据主要有四类。

依据一：目标落在本地网段

最常见的直连依据。家庭局域网的 192.168.0.0 段、云主机的 10.0.0.0 段都在这一类。写法上应使用 CIDR 段并附加解析选项，避免为 IP 触发额外的解析请求。

依据二：域名指向内部系统

公司后台、内网协作工具、打印与存储服务，通常用内网域名访问。这类域名的特点是解析结果落在私有地址段上，因此也可以由网段层兜住。

依据三：使用者手动列入直连名单

名单层的直连条目优先级最高，适合放置「必须以本地出口访问」的系统。这类需求常见于需要固定出口地址校验的内部平台。

依据四：本地化服务与运营商自有地址

运营商的服务地址、更新服务器、本地应用商店都属于这一类。它们不需要跨境，绕路只会增加延迟，通常写在名单层。

代理判定的四种依据

判定为代理，意味着请求经隧道转发后发出，出口地址随之改变。与直连一样，支撑这个方向的依据也可以分成四类。

依据一：目标域名在境外服务清单里

这是最常见的代理依据。写法上用后缀匹配覆盖主站与子域，用关键字匹配补上分片域名。三种写法的取舍见 规则写法与示例。

依据二：目标地址落在境外地址段

部分服务直接以地址段暴露，用域名写不出来。这类目标必须走网段层，但要注意段宽不能过大，否则会连带影响同段的本地服务。

依据三：应用本体需要跨境

外服游戏的本体、启动器与更新服务是典型对象。桌面端按进程名写，移动端按包名写，两套写法不能直接互换。

依据四：默认出口兜底

没有命中任何规则的请求，在默认出口为全部代理时也会走代理。这不是缺陷，而是新装客户端的预期行为：先保证能访问，再逐步补直连规则。

代理依据的书写纪律

代理类条目数量最多，也最容易写错。下面四条是演练环境里总结出的书写纪律，遵守后误判率明显下降。

一个容易搞反的地方

默认出口为全部代理时，「代理」这个结果并不说明规则写对了。判断规则是否生效，要看判定标记是「代理」还是「域名命中」。前者只说明方向，后者才说明依据来自域名层。

代理类规则的覆盖代价

把大量目标判成代理，代价体现在本地流量上。下面这组数据取自演练环境同一批目标的对照测试，可以看出代价落在哪里。

覆盖比例的平衡点

演练数据里覆盖比例到 70% 时本地目标首屏只增加 0.5 秒，而境外目标从 6.8 秒降到 1.3 秒。这个区间是多数用户比较合适的取值，再往上收益趋缓。

两种判定的差异对照

直连与代理不是对称的两个选项。下面从耗时、丢包、出口地址与适用对象四个维度对照，差异比直觉更明显。

改写方向的两个代价

把境外目标判成直连，代价是打不开或极慢；把本地目标判成代理，代价是变慢但仍可用。两个方向的错误代价不对等，这也是默认出口选全部代理的原因之一。

出口地址改变这一点最容易被忽略

判定为代理之后，出口地址随之改变。部分服务会记录并校验出口，一旦分流规则把某个域名判成代理，用户的登录态就可能失效。这类域名应当写进名单层的直连集合。

命中即停：判定为什么不往下走

客户端在某一层匹配成功后立即停止比对，返回该条目的方向。这个行为叫命中即停，它是判定结果可预测的基础。

为什么必须停

如果继续往下比对，同一目标可能被多条规则反复改写，最终方向取决于遍历顺序而不是规则意图。命中即停让每条规则都有确定含义，也让人能预判结果。

停在哪一层决定了归因

状态标记会显示判定停在哪一层。看到「域名命中」就知道域名层里有对应条目，看到「未命中」就知道前五层都空着。归因清楚，排查才有方向。

同层多条命中的取舍

同层内多条规则都匹配同一目标时，靠前的条目被采用，后面的成为冗余。位置是这个层级里唯一的排序依据。

把最精确的写法放前面

如果同时存在一条后缀规则和一条精确域名规则，精确的那条应该写在前面。这样例外条目优先于宽泛条目，符合直觉，也省去每次新增都要重算位置。

重复条目的识别

导出规则表后按类型分组排序，完全相同的行会挨在一起。演练环境里 214 条规则中检出 7 条完全重复，删除后命中率没有变化，说明它们从未产生实际作用。

手动锁定层的作用与代价

手动锁定是六层里唯一全局性的开关。它用于临时验证，不是日常配置。理解它的代价，才能避免长期误用。

锁定之后发生什么

锁定后所有流量走同一方向，规则表不再参与判定。此时即便规则写对了也不会生效，这是「规则不生效」反馈里最容易漏掉的一种。

什么时候值得用一次

排查链路问题时，把流量锁定到一个方向，可以区分是判定写错还是链路不通。演练环境里，这样的对照测试平均 2 分钟就能给出方向。

名单层：使用者能直接控制的部分

名单层是六层中唯一由使用者完整维护的集合，也是覆盖其他层的最强手段。下面说明它的三个特点。

特点一：条目少而精

演练环境里的名单层只有 8 条，全部是「必须直连」的内部系统。条目少说明它是例外集合，而不是日常分流的主要手段。

特点二：位置决定一切

名单层整体位于域名层之上，所以它内部的先后顺序只影响同类条目。演练环境里，名单层前 3 条承担了 92% 的命中。

特点三：需要定期清理

内部系统换域名或迁移机房后，旧条目会长期留在这里。演练环境建议每季度检查一次，清理已失效的条目，避免占用例外位。

域名层的三种匹配方式

域名层是主力层，它的三种写法各自适合不同的目标。选错写法会导致覆盖不足或覆盖过宽。

后缀匹配的覆盖边界

后缀匹配按域名结构生效，主站与子域共用一条。它不覆盖并列的独立后缀，这是追剧类规则最常漏的地方。

关键字匹配的使用纪律

关键字要选足够独特的一小段。演练环境里用 example 一类的通用词做关键字，会同时命中 31 个无关目标；改成 exampleupdate 后只剩 2 个。

# 后缀匹配：覆盖主站与全部子域
DOMAIN-SUFFIX,example-video.com,PROXY

# 关键字匹配：覆盖分散的分片域名
DOMAIN-KEYWORD,streamsegment,PROXY

# 完整域名匹配：只覆盖这一个地址
DOMAIN,portal.example-corp.com,PROXY

网段层的写法与范围控制

网段层处理地址而不是域名。写法简单，但范围控制不当会连带影响同段的其它服务。

段宽怎么定

本地网段用标准的三段私有地址即可。境外地址段应精确到需要覆盖的具体范围，演练环境里的 8 条网段规则平均段宽为 21 个地址，没有一条超过 256 个。

解析选项要不要加

本地网段一律附加解析选项。这能避免为网段条目额外发起解析请求，减少判定耗时。演练环境里加上该选项后，单次判定平均耗时从 0.14 毫秒降到 0.09 毫秒。

为什么要把大段拆细

一段覆盖 256 个地址时，只要其中一个地址属于本地服务，整段都会被判成同一方向。拆细之后误伤范围从 256 个降到 128 个，进一步细分还能更小。

应用层的平台差异

应用层让同一个域名在不同程序里走不同出口。四个维度里，只有这一层需要区分平台。

桌面端按进程名

Windows 与 macOS 与 Linux 都支持按可执行文件名匹配。写法上要注意带上扩展名，并注意同名程序可能出现在不同路径下。

移动端按包名

Android 与 iOS 的应用规则按包名填写，包名通常以厂商域名开头。同一款应用在两个系统的包名也可能不同，需要分别写。

跨端迁移时最容易漏的一步

桌面端的进程名不能直接用在移动端。演练环境里的跨端迁移反馈中，有 63% 的失败原因是照搬进程名而没有换成包名。

默认出口的三种取值

默认出口是判定链的终点，决定所有未命中请求的方向。它的取值只有三种，选择依据是主要使用场景。

为什么出厂值是全部代理

因为跨境访问不通的表现远比变慢更严重。默认全部代理保证了第一次使用时主要目标能打开，代价是本地流量多绕一段路，这个代价可以通过补直连规则消除。

按地区均衡的适用限制

均衡策略的判定结果会随出口变化，不适合需要固定出口地址的业务。这类场景应当直接选全部代理并锁定固定节点，而不是依赖均衡。

三种取值怎么改

默认出口的修改不需要重写规则表，改完立即生效。但改动前后的行为差异很大，建议先记录当前取值再修改。

判定结果的可观测性

判定不是黑盒。客户端提供两个观察入口：状态页的即时标记与日志里的累计统计。两者配合，可以确认规则是否真的被覆盖。

状态标记看单次

状态页显示最近一次请求的判定结果，包括方向与生效层。它适合确认某一条规则是否命中，不适合统计覆盖率。

日志看累计

日志记录每个目标的判定层与次数，可以统计出哪些域名始终未命中。演练环境里，214 条规则中有 11 条在 30 天内一次都没有被触发，属于可以清理的条目。

日志不记录访问内容

判定日志只保存目标标识与判定结果，不保存请求内容与响应体。演练环境里通过本地回环生成流量，因此也不产生真实访问痕迹。

判定的六个边界

下面六条是这套判定机制本身做不到的事。遇到时应当换思路，而不是继续改规则。

先排除边界，再改规则

改规则之前，先用下面这份清单确认问题不落在边界范围内。这一步能省掉大量无效的规则调整。

边界一：不能识别语义等价的域名

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

边界二：不能感知服务的新增接口

服务方新增接口域名时，规则表不会自动更新。演练环境里每季度有 3 到 5 个新增接口域名需要补写。

边界三：不能决定链路是否顺畅

判定只回答走哪条路，不回答这条路快不快。两者必须分开评估，否则会把链路问题误判成规则问题。

边界四：不能同时给两个方向的结果

一条规则只能写一个方向。同一域名需要「主站走代理、接口直连」时，得靠同层位置区分，而不能一条写两个方向。

边界五：不能覆盖未在规则表出现的进程

应用层按名称匹配，程序改名或换路径后条目即失效。演练环境里每季度有 1 到 2 条应用规则因此失效。

边界六：不能在受管网络里落地

路由改写被系统策略接管时，规则可以保存却无法生效，状态页始终显示未命中。

常见判定误区

下一步

判定顺序已经讲完。下面两页分别讲三类场景怎么分，以及每种写法怎么落笔。