V2RayN路由规则怎么设置才能实现流量分流？
一、把“全局代理”拆开：路由规则在 V2RayN 里的真实定位
很多人第一次打开 V2RayN，会直接选“全局模式”，把所有流量交给远端节点。这个做法上手最快，却把本来不该外发的连接也一并送了出去：局域网设备、路由器管理页、公司内网系统，以及大量本就在本地访问很快的服务，全都要绕一圈。V2RayN 路由规则的价值，正在于让这些连接先在本地被区分开——该直连的直连，该代理的代理，该阻断的阻断。
需要先明确一点：V2RayN 是图形界面，真正执行判断的是它调用的核心（v2ray-core 或兼容的 Xray-core）。路由模块所处的位置，大致在“连接已经建立、出站还没确定”之间；它拿到的是目标域名、目标 IP、目标端口、入站来源等信息，然后决定这个连接交给哪个出站（outbound）。界面上的勾选、列表与规则集，最终都会被翻译成核心配置文件里的一段 routing 配置。
因此，判断一条规则有没有生效，不应只看界面是否保存成功，而要看核心日志里这条连接最终挂到了哪个出站标签上。这也是本文把“验证与可审计”放在操作步骤之后的原因：分流配置写错通常不会报错，只会安静地走错路。
二、合规视角：分流本质上是数据出境路径的划分
如果把路由规则只当成“提速技巧”，很容易忽视它另一层含义：它决定了哪些目标域名、哪些目标 IP 的信息会被送到远端节点。把不需要外发的流量留在本地直连，等价于减少数据流转环节，也减少了对“这条流量为什么出去”的解释成本。从合规视角看，这不是单纯的性能优化，而是对出境路径的一次主动划分。
从可审计的角度看，一条好用的分流方案应当满足三个条件：出站标签命名可读（例如 proxy、direct、block，而不是默认的 outbound-1）、规则本身有据可查（谁加的、为什么加）、日志能在需要时还原判断过程。工作假设：当规则条目长期无人维护时，它带来的风险会高于它带来的便利，因为没人能说清某条域名为什么被放进代理列表。
需要提醒的是，分流只改变客户端本地的出站选择，并不能替代组织层面的数据合规审查。哪些业务数据允许经由境外节点传输，属于制度问题，应由所在组织的合规负责人判断，而不是由一条路由规则决定。
三、术语先行：入站、出站、域名策略与规则集
在动手之前，把这几个词对齐，后面看界面会顺畅很多。
入站（inbound）指客户端在本机监听的入口，常见的是 SOCKS 与 HTTP 代理入口。V2RayN 生成配置时会给它们打上标签，默认标签通常写作 socks、http 之类（以实际生成的配置文件为准）。浏览器、系统代理、其他软件都是先连到这个入口，再交给路由判断。换句话说，入站解决的是“谁把连接交进来”。
出站（outbound）指连接真正走向哪里。除了你导入的服务器节点，核心通常还会内置几个特殊出站：direct 表示不经过代理直接连出去，block 表示直接中断。V2RayN 的路由设置界面上那几栏“直连”“代理”“阻止”，本质上就是在给这两个特殊出站和你的代理节点分配域名与 IP。你可以把出站理解为连接离开客户端后的下一跳。
域名解析策略（domainStrategy）决定核心在什么时机把域名解析成 IP。常见取值包括 AsIs、IPIfNonMatch、IPOnDemand：AsIs 表示不做额外解析，按原样匹配；IPIfNonMatch 表示域名规则都没命中时再解析成 IP 去匹配 IP 规则；IPOnDemand 表示只要遇到需要 IP 判断的规则就立即解析。这个选项直接影响 DNS 查询次数和匹配行为，是排查“规则看起来对但没生效”时的第一检查点。
规则集（规则列表）指一条条“匹配条件 + 出站标签”的组合。在较新版本的 V2RayN 中，路由设置窗口除基础列表外，还会提供自定义规则页签，可以按域名、IP、端口、协议、入站标签等字段逐条定义。不同版本与汉化包的页签名称存在差异，请以实际界面为准。这些条目并不是无序集合，后文会说明它们按顺序生效。
四、桌面端最短可达路径：在 V2RayN 中配置路由规则
下面给出一条从零开始的最短路径，适用于 Windows 桌面端。若你的界面文字与描述不一致，请优先按关键词搜索，而不是按位置逐级点击。
- 确认已导入至少一个可用节点，并且在不启用路由规则的情况下能够正常连通，这是后续验证的基线。换句话说，先把节点本身跑通，再谈分流。
- 打开主界面，进入“设置”菜单，选择“路由设置”（部分版本显示为“路由”或 Routing）。
- 在基础设置区域，域名解析策略一般可先保持默认；若你准备大量使用 IP 规则，可考虑改为 IPIfNonMatch，再观察效果。
- 在“直连”“代理”“阻止”三类列表中逐行填入域名或 IP。列表里通常支持 domain:、full:、regexp:、keyword:、geosite: 等前缀写法，具体支持范围以官方文档为准。
- 若需要按端口、协议或入站标签做更细的判断，切换到自定义规则页签逐条添加，并为每条规则指定出站标签。
- 保存后让核心重新加载配置。经验性观察：部分版本保存即热加载，部分版本需要重启客户端或切换一次节点才会生效，以日志中是否出现新的路由判断为准。
提示：路由设置窗口的菜单名称、页签数量与顺序会随版本与汉化不同而变化。找不到入口时，先在“设置”菜单里找“路由”二字，再看主界面是否有独立的“路由”页签，这是两个常见入口。
警告：不要在未确认节点可用的前提下先写几十条规则。规则错误不会报错，只会让连接静默走错方向，后续排查成本会成倍上升。
五、移动端与桌面端的差异：同一套思路，不同的入口
分流的概念在各平台是相通的，但入口与表达能力差别不小，跨平台照搬步骤往往会卡住。
Android 上常见的客户端是 v2rayNG 这类基于同一核心的项目，路由入口通常位于“设置”里的“路由设置”，特点是预置规则集（例如绕过局域网与特定地区地址）加自定义规则两层结构，界面以开关和列表为主，适合快速启用，但不便于按端口、协议写复杂条件。iOS 上由于系统限制，通常使用第三方客户端（如 Shadowrocket、Stash 等），它们的路由模型是“规则 + 策略组”，与 v2ray-core 原生的 routing 字段并非一一对应，只能做概念迁移，不能按界面逐项对照。这意味着，你需要先在移动端重新理解一遍“规则如何命中”，而不是复制桌面端的配置。
如果你在多台设备上维护同一套分流意图，经验性做法是：把“要直连什么、要代理什么”整理成一份纯文本清单，各平台再按自己的入口翻译一遍，而不是试图导出一份配置通吃所有客户端。这样做的成本是一次性的，收益是后续任何一台设备出问题都能快速对照。
六、匹配顺序决定结果：为什么第一条命中的规则最关键
路由规则是按顺序自上而下逐条比对的，一旦某条规则命中并且带有出站标签，连接就按这条规则处理。这个特性意味着：规则集合不是“集合”，而是“有序列表”，顺序写错，结果就完全不同。
举个具体的例子。假设你有两个域名：intranet.example.com 属于公司内网，必须直连；example.com 是外部服务，希望走代理。如果你先写“example.com 走代理”，再写“intranet.example.com 直连”，那么访问 intranet.example.com 时很可能先被前一条规则捕获——因为子域名在多数匹配方式下会被父域名规则覆盖——结果就是内网服务打不开或反复超时。把更具体的条件放在前面、更宽泛的条件放在后面，是这类问题的通用解法。
可复现的验证方法：把核心日志等级临时调高，访问该域名，观察日志中这条连接最终落到哪个出站标签。如果标签与预期不符，先检查顺序，再检查匹配写法（例如用了 keyword: 还是 domain:），最后才怀疑缓存或 DNS。
七、三类出站策略的写法：直连、代理与阻断
把域名和 IP 分到三类里，是绝大多数分流方案的骨架。分类本身不难，难的是判断边界。
直连适合三类对象：一是本机与局域网范围，例如 127.0.0.1、10.0.0.0/8、192.168.0.0/16 这些网段以及路由器管理地址；二是内网业务域名，例如公司 OA、代码仓库、内部 API；三是你明确知道不需要绕行、且对延迟敏感的服务。经验性观察：把常用国内服务整体放进直连后，日常浏览的主观流畅度通常会有可见变化，但具体幅度因网络环境而异，不具备通用数值。
代理适合需要跨境的业务域名与 API 域名。建议按业务用途分组书写，并在标签上体现用途，而不是把所有域名堆在一栏里。当规则条目超过几十条时，混在一起的列表几乎无法复核。
阻断适合确定不希望产生任何连接的域名，例如广告域名、已知的遥测域名。这里有一个常见误区：用阻断去“屏蔽”某个国内站点的访问。阻断与直连是两种不同意图，阻断会让依赖该域名的正常业务直接失败，而这类失败往往表现为界面卡住或功能静默失效，排查起来相当费时。
八、一份可参考的 routing 配置片段
理解界面背后的结构，有助于判断某条规则为什么没生效。下面是一段结构示意，字段名称与官方核心文档一致，但具体内容请按你的实际环境替换。注意这只是片段，不是完整配置。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["intranet.example.com"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["192.168.0.0/16", "10.0.0.0/8"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:category-ads-all"],
"outboundTag": "block"
}
]
}
}这段配置里，出站标签 direct 与 block 对应核心内置的特殊出站，其余流量会落到默认出站（通常是你的代理节点）。把这段结构与界面上的三栏列表对照，就能理解界面上填的每一行最终变成了什么。也就是说，界面只是生成这段 routing 的一种前端方式。
需要说明的是，V2RayN 会在保存设置后把界面内容写入它生成的运行配置文件，文件位置与命名因版本和安装方式而异，请以实际安装目录为准，不要直接手工编辑正在被客户端管理的文件，否则下一次保存会被覆盖。
九、Geo 数据与规则集：省事的代价
geosite 与 geoip 是预先整理好的域名与网段分类数据，通过类似 geosite:category-ads-all 的写法引用，能省下大量手工录入。V2RayN 通常提供更新这些数据文件的入口，建议在使用前先更新一次，否则引用的分类可能缺少近期新增的域名。
它的优点和缺点都很明显。优点是维护成本低、覆盖面广；缺点是粒度粗、更新存在滞后，而且不同来源的分类口径可能不一致——同一个域名在不同版本的数据里未必落在同一分类下。经验性观察：依赖 geo 分类做“必须直连的关键业务”判断时，偶尔会出现规则失效导致的绕行或断连，具体是否发生取决于数据版本与目标站点情况。
因此更稳妥的组合是：关键业务域名用显式列表逐条写明，geo 分类只作为兜底或用于非关键场景（例如广告阻断）。这样即便分类数据更新出现偏差，核心业务也不受影响。
十、日志与可审计性：怎样验证分流真的生效
分流配置最麻烦的地方在于“错了也不报错”。所以验证不能靠感觉，要靠日志。
V2RayN 提供日志查看入口，位置通常在主界面的日志页签或菜单中，不同版本位置不同；核心本身也会把日志写入文件，具体路径因版本与安装方式而异。日志的详细程度由 log 字段中的 loglevel 决定：warning 一般只记录告警，info 能看出路由判断与出站选择，debug 最详细但写入量也最大。
一条可复现的验证流程如下：先把 loglevel 临时调整为 info，清空或记录当前日志位置；然后访问一个被规则覆盖的域名；最后在日志中查找该域名对应的出站标签。如果标签是 direct，说明直连规则命中；如果是代理节点的标签，说明走了代理。为了交叉确认，也可以再访问一个显示出口 IP 的页面，对比访问不同域名时看到的出口是否一致。
从留存角度，日志等级越高，记录的内容越多。是否长期保留、保留多久，属于组织策略问题，本文不给出统一建议，只提醒一点：如果日志仅用于排查，问题解决后调回较低等级，可以减少无意义的写入。
十一、例外与副作用：精细分流的隐性成本
规则越细，短期收益越明显，长期成本也越高。常见的副作用有三类。
第一类是维护成本。每新增一条规则都需要有人记住它的理由，否则半年后没人敢删。缓解办法是给规则加上可读的标签和备注，并把清单存在代码仓库或文档里，与配置文件版本对齐。
第二类是解析与延迟变化。把域名解析策略从 AsIs 改为 IPIfNonMatch 后，未命中的域名会额外做一次解析，这会带来少量额外查询；在网络环境不稳定时，主观感受可能反而变差。这是取舍而非缺陷，建议改动后做一次对照观察再决定保留哪个策略。
第三类是失效风险。目标站点可能调整 CDN、更换解析结果、启用新的子域名，导致原本准确的规则逐渐偏离。工作假设：域名类规则比 IP 类规则更耐维护，因为 IP 会随基础设施变更而漂移。所以能用域名表达的，尽量优先用域名。
三种情况建议不要继续加规则：一是规则数量已超出你能记住的范围；二是你无法在日志中解释某条规则为什么存在；三是设备受组织管控，明确不允许自定义出站路径。此时更合理的做法是回到较少但明确的分流集合，而不是继续叠加。
十二、故障排查：现象、原因、验证与处置
下表按“现象 → 可能原因 → 验证方式 → 处置建议”的顺序整理了几类常见问题。所有验证都建议在调高日志等级后进行。
| 现象 | 可能原因 | 验证方式 | 处置建议 |
|---|---|---|---|
| 内网地址打不开 | 内网域名的直连规则排在宽泛的代理规则之后 | 日志中查看该域名的出站标签 | 把具体域名的规则上移到宽泛规则之前 |
| 某个站点速度变慢 | 该站点未命中直连规则，实际走了代理 | 对比访问前后日志中的出站标签变化 | 补一条直连规则，或检查域名写法是否过窄 |
| 应用功能静默失效 | 依赖的域名被放进了阻断列表 | 临时移除阻断规则后重试 | 区分“不想走代理”和“不想连接”，改用直连 |
| 改了规则但行为不变 | 配置未重新加载，或改动的是另一个配置文件 | 重启客户端后再次观察日志 | 确认保存路径，避免手工编辑客户端管理的文件 |
| IP 规则时灵时不灵 | 目标域名解析结果发生变化，与已写 IP 不匹配 | 多次访问并观察日志中的目标地址 | 改用域名规则，或缩小 IP 规则的使用范围 |
十三、适用与不适用场景清单
把判断标准写清楚，比给出一套“万能规则”更有用。以下准入条件与边界，供你在决定是否投入时间配置分流时参考。
适合配置分流的场景包括：同一台设备上既有需要跨境的业务访问，又有大量本地与内网访问；你希望减少不必要的流量绕行；你需要向他人解释“什么流量走了哪里”；你使用的主流客户端支持规则集并且有人能定期复核。
不建议投入精力的场景包括：你的访问目标非常单一，全局模式与分流效果差别不大；没有人力定期复核规则；设备属于受管控资产，不允许自定义出站路径；组织制度要求所有相关流量必须经统一出口，此时正确做法是先与合规负责人确认边界，而不是自行加规则。
还有一类容易被忽略的情况：多人共用同一套规则模板。人越多，规则越容易膨胀，因为每个人都想加自己的例外。此时建议约定“新增规则必须附理由与复核人”，否则模板会在几个月内失去可读性。
十四、最佳实践检查表
下面这份检查表可以在每次改动前后各过一遍，用来降低“改完忘了为什么改”的概率。
- 先建立基线：关闭路由规则，确认节点本身可用，再开启分流。
- 顺序优先于数量：具体规则在上，宽泛规则在下，把这条当成硬性习惯。
- 意图分离：直连用于“不必绕行”，阻断用于“不应连接”，不要混用。
- 关键业务用显式域名，geo 分类只做兜底，避免关键路径依赖分类数据的更新节奏。
- 把规则清单与配置文件一起纳入版本管理，并为每条规则写一句理由。
- 改动后必做一次日志验证，确认出站标签与预期一致再收工。
- 按固定周期复核，重点清理“没人能解释来源”的条目。
- 记录你的解析策略取值，因为它是很多“规则不生效”问题的隐藏变量。
十五、常见问题
V2RayN 路由规则在哪设置？
通常在桌面端主界面的“设置”菜单中进入“路由设置”。部分版本与汉化包会把它显示为“路由”或 Routing，也可能在主界面有独立入口。基础列表可直接填域名与 IP，更细的条件需要到自定义规则页签逐条添加。菜单名称随版本变化，找不到时按“路由”关键词检索即可。
为什么我的直连规则没有生效？
按可能性从高到低排查：一是顺序问题，宽泛的代理规则排在前面把连接先捕获了；二是写法问题，domain: 与 keyword: 等前缀的匹配范围不同，实际没覆盖到目标域名；三是配置未重新加载，界面保存了但核心还在用旧配置；四是解析策略设置导致匹配时机与预期不一致。建议调高日志等级，直接观察该域名最终的出站标签。
直连和阻断有什么区别？
直连是建立连接但不经过代理节点，访问仍然正常；阻断是不建立连接，直接中断。把本该直连的域名放进阻断列表，会导致依赖它的应用功能失败，而且往往表现为静默失效、不容易定位。简单说：不想绕行就用直连，不希望发生任何连接才用阻断。
geosite 和 geoip 规则可以直接依赖吗？
可以用于覆盖面广、容错率高的场景，例如广告域名阻断。但对于关键业务路径，建议改用显式域名列表，因为分类数据的粒度和更新节奏不由你控制，一旦出现偏差，受影响的是业务可用性。更稳妥的做法是显式列表为主、geo 分类兜底。
分流配置会不会影响日志留存？
分流本身不产生额外日志，但验证分流通常需要临时把日志等级调高，这会显著增加写入量。建议把“调高等级—验证—调回”作为一个固定动作，长期保留与否应按所在组织的策略执行，本文不提供统一的留存期限建议。
十六、结语：先写清意图，再写规则
回到最初的问题：V2RayN 路由规则怎么设置才能实现流量分流？答案并不是某一组固定条目，而是一套可以解释、可以验证、可以退回的做法。先用最短路径把基础列表跑通，再用日志确认每条连接的去向，最后按业务用途整理成一份有人维护的清单——顺序、写法、解析策略这三个变量理顺之后，绝大多数“规则不生效”的问题都会自己浮出水面。
下一步建议从两件事做起：一是挑一个你确定必须直连的域名，按本文流程完整走一遍并做日志验证；二是把现有的所有规则导出成一份纯文本清单，逐条写下添加理由。前者让你确认操作路径没问题，后者让你在半年后仍然看得懂这份配置。可以预期的是，界面层仍会随版本与汉化调整，但只要 routing 的判断顺序与出站标签没变，排查思路仍然适用；至于更新更细的界面变化，请以你安装的当前最新版本实际界面与官方文档为准。
