V2RayN的路由规则功能如何实现国内外流量分流？

路由规则在 V2RayN 里到底扮演什么角色

V2RayN 的路由规则（Routing）本质上是一张按顺序求值的判定表。每一条出站连接在建立之前，都要先回答同一个问题——这次请求应该交给代理、直连，还是直接阻断；答案确定之后，才有后续动作。所谓国内外流量分流，就是让「访问国内站点与内网地址」走直连，让「需要跨越网络边界的请求」走代理，从而在不切换全局模式的前提下，把代理层的开销压到最低。理解这一点很关键：路由规则不是一个开关，而是一段有先后顺序、有命中优先级、也有回退路径的程序逻辑。

很多人第一次注意到它，是在发现「开着代理访问国内网站反而变慢」之后。这并不奇怪——一旦所有流量都塞进代理通道，国内站点的响应就要多绕一跳，而路由规则的作用正是把这一跳省掉。反过来，如果规则写得过宽，本该走代理的域名被误判为国内，就会出现「某些站点打不开、一直转圈、验证码反复弹」的现象。这两种方向相反的失败模式，几乎覆盖了新手遇到的大部分问题。

与全局模式、系统代理的边界

V2RayN 主界面上的「系统代理」相关选项，决定着操作系统的流量是否被接管；路由规则则决定被接管之后如何分流。两者是上下层关系，不能互相替代。你把系统代理设成全局，再配一套精细的路由规则，规则依然生效——因为规则是在核心内部执行的，早于「是否全局」这一层判断。反过来，如果系统代理没开、应用也没有手动指向本地监听端口，规则再怎么完美也不会被触发。

这也是为什么排错时应该先确认「流量有没有进到核心」，再去查规则。顺序颠倒，往往会在规则表里反复折腾，最后却发现问题根本不在那里。

与 PAC、与 DNS 设置的分工

PAC 是浏览器或系统层面的分流方案，靠一段脚本告诉客户端「这个地址用不用代理」，它工作在代理之前；路由规则工作在代理之后，由核心自己决定出站。两者可以共存，但同时开启容易让判断逻辑互相打架——比如 PAC 已经把某域名排除在外，核心里的规则又把它指向代理，最终结果取决于谁先拦截。经验性观察是：明确只保留一层分流逻辑，出问题时的定位成本会低很多。

至于 DNS 设置，它和路由规则属于强耦合关系，但不是同一个东西。路由规则里的域名条件需要先拿到域名才能匹配；如果域名在早期就被解析成了 IP，后续的域名规则可能根本没机会参与判断。这个细节会在后面单独展开。

两条主线：黑名单式与白名单式分流

讨论国内外分流，绕不开一个前置选择：你是想「默认走代理，把国内的挑出来直连」，还是想「默认直连，只把需要的挑出来走代理」。前者通常叫黑名单模式（或反向名单），后者叫白名单模式。二者在 V2RayN 里都能实现，差别不在功能，而在维护成本与失败时的表现。

• 黑名单式：规则里列出国内域名与国内 IP 段，命中即直连，其余全部交给代理。配置量小，覆盖面取决于数据集完整度。
• 白名单式：规则里只列出需要走代理的域名，命中即代理，其余直连。可控性最强，但需要你清楚自己到底要访问什么。

举个具体场景。假设你日常只用两三个境外站点查资料，其余时间都在国内站点之间流转，这时白名单式的实际体验往往更好：默认直连意味着绝大多数请求根本不进代理通道，延迟最低；那几个站点单独列进规则，出问题时也能一眼看出是哪一条在起作用。相反，如果你需要访问的境外站点数量多且经常变化，白名单的维护成本会迅速上升，此时用「国内直连 + 其余代理」的黑名单式更划算。

需要提醒的是，黑名单式的失败模式是「漏网」，白名单式的失败模式是「误伤」：前者表现为该走代理的走了直连、访问不通，后者表现为本可直连的走了代理、速度变慢。知道自己更怕哪一种，比纠结哪种「更先进」有用得多。

动手之前先回答三个问题

路由配置最容易犯的错误，是还没想清楚目标就开始往规则列表里加条目。建议先花两分钟回答三个问题，答案会直接决定规则怎么写。

第一个问题：你的默认出站应该是什么？如果把「最后一条兜底规则」设成代理，那就是黑名单思路；设成直连，就是白名单思路。这条兜底规则是整个规则表的地基，后面所有条目都是在它之上做例外。

第二个问题：你更在意命中准确率还是配置简洁度？追求准确率意味着要维护更细的域名清单，甚至给单个站点写 full: 精确匹配；追求简洁则意味着依赖 geosite、geoip 这类聚合数据集，接受一定比例的误判。

第三个问题：你是否需要按应用或按端口区分？如果你的机器上同时跑着下载工具和浏览器，也许希望下载工具永远直连、浏览器走代理。这需要用到入站标签或进程维度的条件，属于进阶用法，配置复杂度会明显上一个台阶。

三个问题回答完，规则表的骨架基本就有了。接下来才是具体的填写动作。

规则是怎么被匹配的：顺序、命中与回退

理解匹配机制，比记住任何一条具体规则都重要。核心在处理一条连接时，会从上到下遍历规则列表，遇到第一条所有条件都满足的规则就立即采用它的出站，不再往下看。这个「命中即停」的行为意味着：规则列表的顺序本身就是逻辑的一部分，把一条宽泛的规则放在前面，会让它后面所有更精确的规则全部失效。

一个真实感很强的例子：某人在列表顶部加了一条「所有 TCP 流量走代理」，本意是兜底，结果下面精心写好的「国内域名直连」全部成了摆设，因为请求在第一条就被截走了。这类问题不会报错，只会表现为「配置看起来没问题但分流没生效」，非常难自查。判断方法很简单：把兜底规则临时挪到最底部，再看行为是否改变。

域名条件与 IP 条件的差异

规则条件大致可以分成两类：基于域名的（domain 系列）和基于 IP 的（ip 系列）。前者匹配的是请求里的目标域名，后者匹配的是解析后或直接给出的目标地址。两者的可靠性和适用范围并不相同。

域名条件的好处是不受 IP 变动影响，一个域名换多少个 CDN 节点都能匹配上；短板是遇到直接以 IP 形式发起的连接时完全失效。IP 条件则相反，它对目标是否带域名不敏感，但依赖 IP 归属判断的准确性，遇到 CDN 场景容易误判。实践中常见的做法是两条腿走路：域名条件负责主要分流，IP 条件作为补充，覆盖那些直接连 IP 的场景，以及内网、回环这类必须直连的地址段。

再补充一点容易被忽略的：域名条件的书写有几种形式，语义各不相同。完整匹配要求域名完全一致；后缀匹配覆盖子域名；关键词匹配只要域名里包含该串就算命中，范围最宽也最容易误伤；正则匹配最灵活，但性能开销更大，也最容易写出意料之外的结果。不确定用哪种时，优先从后缀匹配开始，它通常能在准确度和维护成本之间取得平衡。

桌面端最短可达路径

在 Windows、Linux 与 macOS 上，V2RayN 的配置入口基本一致：打开主窗口，进入「设置」菜单，选择「路由设置」（Routing），即可看到规则集区域与规则列表。列表右侧一般提供添加、编辑、删除与上下移动的操作，调整顺序就在这个界面完成。不同版本之间菜单位置和字段命名可能有细微差异，如果你手上的版本对不上，先看「参数设置」里显示的核心类型，再按实际界面寻找同名或近义入口，不要凭记忆硬套。

新建或编辑一条规则时，对话框会要求你填出站（代理 / 直连 / 阻断）以及触发条件。建议的顺序是：先确定出站，再决定用域名条件还是 IP 条件，最后才填写具体内容。之所以强调顺序，是因为很多人在填写内容时被界面上的示例带偏，先选了一堆条件，回头发现出站选错了，只能整条重来。

移动端与其他平台的差异

V2RayN 本身是桌面端客户端，移动端与它并非同一套界面，规则的组织方式也不完全相同。在移动端上，你大概率面对的是「按应用分流」加上「按规则集分流」的组合，配置粒度与桌面端存在差异。跨平台迁移配置时不要直接复制粘贴，先确认目标客户端支持哪些条件类型、是否支持同样的数据集标签，否则会出现「规则导入成功但不生效」的情况。

另外，桌面端运行的进程与移动端的应用沙箱机制不同，基于进程或入站标签的条件在移动端往往没有对等物。如果你的分流方案重度依赖这类条件，迁移时需要重新设计，简单平移过去的方案很难成立。

一个可复现的最小示例

下面这段结构对应的是核心侧的路由配置形态，用于说明顺序与条件的关系。V2RayN 的图形界面在保存时会生成类似的配置，你不需要手写，但读懂它有助于判断自己到底配了什么。示例假设出站标签为 direct（直连）与 proxy（代理），实际标签名以你本机生成的配置为准。

{
  'routing': {
    'domainStrategy': 'IPIfNonMatch',
    'rules': [
      {
        'type': 'field',
        'domain': ['geosite:cn'],
        'outboundTag': 'direct'
      },
      {
        'type': 'field',
        'ip': ['geoip:cn', 'geoip:private'],
        'outboundTag': 'direct'
      },
      {
        'type': 'field',
        'network': 'tcp,udp',
        'outboundTag': 'proxy'
      }
    ]
  }
}

这段配置的阅读方式是：先看域名是否属于国内数据集，是则直连；否则看目标 IP 是否落在国内段或私有地址段，是则直连；两条都不命中，才交给最后的兜底规则走代理。国内访问优先直连、其余走代理的分流逻辑，就由这三条完成。注意私有地址段单独列出的意义——内网服务、本机回环如果被塞进代理，往往表现为「本地服务突然连不上」，排查起来很费时间。

要验证这段规则是否按预期工作，可以做一个可复现的对照实验：先访问一个确定属于国内数据集的站点，观察连接是否明显更快、代理端是否没有对应的出站记录；再访问一个确定在境外的站点，确认它走了代理。两次结果与预期一致，说明顺序和条件都写对了。若第一次也走了代理，重点检查是否有更靠前的宽泛规则抢先命中。

域名解析策略：三种取值怎么选

路由配置里有一个不起眼但影响很大的选项，通常译作「域名解析策略」（domainStrategy）。它决定核心在匹配规则时，是否要把域名提前解析成 IP。取值大致有三种，语义差别明显。

怎么选取决于你的规则构成。如果规则几乎全是域名条件，AsIs 就够了，没必要为不存在的 IP 匹配付出解析成本。如果同时用了域名与 IP 两套条件，IPIfNonMatch 是折中选择，它只在必要时才解析，兼顾覆盖面和开销。IPOnDemand 更适合规则高度依赖 IP 判断的场景，普通家用环境很少需要。

这里有一个常被忽略的边界：解析行为本身会引入额外的 DNS 查询，而这些查询走哪条链路、会不会泄漏，取决于你的 DNS 配置。也就是说，把域名策略调得越积极，DNS 侧的问题就越容易被放大。如果你发现调整策略后某些站点开始解析异常，优先回头检查 DNS 设置，而不是继续在规则里加条目。

DNS 与分流为什么会互相拖累

一个典型的现象是：规则写得没错，但访问境外站点时好时坏，或者国内站点偶尔解析到境外地址导致走了代理。这类问题的根子往往不在路由规则，而在 DNS 查询走了哪条路。

原因不难理解。路由规则里大量使用域名条件，而域名条件的匹配前提是请求里还保留着域名。如果 DNS 在很早的阶段就把域名解析成了 IP，后续的域名匹配就失去了依据，规则只能退化成 IP 判断，准确率随之下降。更麻烦的是，如果解析本身被污染或超时，你会得到一个错误的 IP，然后再拿这个错误 IP 去匹配国内段，结果自然是错的。

可行的做法是把两个方向分开处理：国内域名的解析交给响应更快的本地或国内 DNS，境外域名的解析交给可信的境外 DNS，并让这套分工与路由规则的直连/代理走向保持一致。V2RayN 的 DNS 设置里提供了相应的配置项，具体字段名以你当前版本为准。配置完成后，用一个可复现的方法验证：分别对一个国内域名和一个境外域名做解析查询，观察返回的地址是否落在预期网段内。如果境外域名解析出了明显异常的地址，先修 DNS，再谈规则。

需要说明的是，DNS 与分流的耦合程度在不同网络环境下差异很大，上面的描述属于经验性观察，不代表所有环境都会遇到。判断自己是否受影响，最直接的办法是对比「关闭代理时的解析结果」与「开启代理后的解析结果」，两者差异明显就说明值得调整。

规则集：把维护成本转移出去

手工维护几十条域名规则很快就会变成负担，尤其是当某些站点的域名结构发生变化时。V2RayN 提供了规则集相关的管理入口，可以引入预先整理好的规则集合，把「哪些域名算国内、哪些算境外」这类判断交给数据集，自己只关心少数需要特殊处理的例外。这也是社区里最常见的做法。

引入规则集时有三点值得留意。第一是来源可信度，规则集会直接决定你的流量走向，来源不明的集合不应引入。第二是更新频率，数据集过期会导致新站点被误判，建议定期检查更新，而不是一次性配置完就不管。第三是叠加顺序，规则集展开后同样遵循从上到下的匹配逻辑，把它放在兜底规则之前、例外规则之后，通常是最稳的位置。

边界也要说清楚：规则集不是万能药。它擅长覆盖「大众站点」，对内部系统、私有域名、非常规端口这类个性化需求基本无能为力。合理的组合是「规则集打底 + 少量手写例外」，而不是指望一套集合解决全部问题。

故障排查：从现象倒推原因

分流出问题时，最有价值的动作是把现象描述得足够具体。下面按「现象—可能原因—验证方式—处置」的顺序列出几类高频情况，供对照使用。

表格之外还有一类容易被误判的情况：问题其实出在代理服务器一侧，与规则无关。判断方法是临时切到全局模式访问同一目标，如果依然异常，就说明不是路由规则的责任，应该去查节点连通性。这个交叉验证能省掉大量无效排查。

副作用与边界：什么时候不该做细粒度分流

分流越细，出错的面积越大，这是一个绕不过去的权衡。当规则条目增加到几十上百条时，任何一次数据集更新、任何一个域名结构调整，都可能让某条规则悄悄失效，而你未必能立刻察觉——因为失效的表现往往只是「某个站点变慢了一点」，不足以引起注意。

所以有几类情况并不适合上复杂的路由：一是临时使用，几天后就不再需要，配置成本高于收益；二是排障期间，此时变量越少越好，全局模式反而更容易定位问题；三是对稳定性要求极高的场景，规则越简单，行为越可预测。经验性结论是：能从三五条规则解决的问题，不要写成三十条。

还有一层边界来自合规与组织要求。如果设备处于受管理的网络中，自行添加分流规则可能与网络使用规定冲突，这种情况下应当先确认允许范围，而不是默认「技术上可行就等于可以这么做」。

适用与不适用场景清单

把前面的判断收敛成一份清单，便于快速对号入座。适合做国内外分流的场景包括：日常在国内外站点之间来回切换、希望国内访问保持本地速度；设备上同时有下载类与浏览类流量，希望区别对待；需要访问的境外站点相对固定，规则可以稳定维护；对 DNS 污染有一定感知，愿意把解析也一并规划。

不太适合的场景则包括：只在极短时间内使用一次，配置与验证的时间成本明显偏高；网络环境本身不稳定，分流带来的变量会让排障更难；设备由他人统一管理，规则改动不在你的权限范围内；以及规则需求高度依赖某个特定数据集，而该数据集的更新节奏你无法掌控。

这份清单不是硬性门槛，而是一个提醒：先判断值不值得，再决定怎么做。很多「配置问题」实际上在动手之前就已经注定了结果。

验证与观测：怎么确认它真的在工作

配置完成不等于配置正确。建议固定一套三步验证流程，每次改动后都跑一遍，形成肌肉记忆。第一步是双向访问测试，选一个确定的国内站点和一个确定的境外站点，分别确认走向；第二步是顺序验证，临时把兜底规则改成相反方向，看行为是否随之改变，以此确认规则表真的在按顺序生效；第三步是稳定性观察，间隔一段时间重复第一步，看结果是否一致，不一致通常指向解析层面的问题。

如果客户端提供了日志或连接记录，也可以借助它做佐证：观察某次连接实际匹配到了哪条规则、走了哪个出站。这类记录的价值在于把「我感觉变快了」变成「这一条确实走了直连」，让判断有据可依。日志的详细程度与具体位置因版本而异，找不到时不必强求，前两步的对照实验已经能覆盖大部分场景。

最佳实践检查表

把上述要点整理成一张可以照着做的检查表，配置前后各过一遍，能规避绝大多数常见坑。

• 先定兜底方向，再补例外；不要在兜底规则之上叠加宽泛条件。
• 私有网段与回环地址单独列为直连，且尽量靠前。
• 域名条件为主、IP 条件为辅，两者都保留但不要互相覆盖。
• 解析策略从 AsIs 或 IPIfNonMatch 起步，确有需要再调积极。
• DNS 分工与分流走向保持一致，避免解析结果与规则判断打架。
• 只保留一层分流逻辑，PAC 与路由规则不要同时承担判断职责。
• 每次改动用固定的三步验证流程复测，并记录改动前后的差异。
• 规则集定期更新，来源与格式都在引入前确认清楚。

这张表不需要一次全部满足，但每多满足一条，后续排错的时间就少一点。尤其是前两条——兜底方向与私有网段——它们决定了你的基础体验是否稳定，优先级高于任何精细化的例外配置。

常见问题解答

下一步可以做什么

回到最初的问题：V2RayN 的路由规则如何实现国内外流量分流？答案可以压缩成一句话——用一张有顺序的判定表，把国内域名与国内地址段指向直连，把其余流量交给代理，并用 DNS 与解析策略保证这张表在判断时拿得到足够的信息。真正决定成败的不是规则条数，而是兜底方向、顺序安排和解析行为三者的配合。

接下来建议按这个顺序推进：先确认当前的兜底方向是否符合你的使用习惯，再为私有网段补上直连规则，然后才考虑引入规则集和细化例外。每完成一步就跑一次三步验证，把改动与结果对应起来记录。等到某天出现异常时，你手上会有一份可回溯的记录，而不是一堆只能推倒重来的猜测。这也是技术文档写作里反复强调的一点：可复现的步骤，比看起来高级的配置更有价值。