v2rayN 路由设置：国内直连、国外走代理

路由设置回答的是一个很具体的问题：这条请求应该从哪个出站口出去。v2rayN 把这个决策交给一张有序的规则表，请求进来后从第一行往下比对，命中哪一条就按那一条指定的出站执行，后面的规则不再参与。

这个"命中即停止"的机制是绝大多数分流问题的根源。规则写得对不对是一回事，放在第几行是另一回事，而后者造成的困惑更多——明明加了一条让某站走代理的规则，效果却完全没变，原因往往只是它排在了一条更宽泛的规则后面。

还有一层容易被忽略：路由规则只能作用于"已经被送进 v2rayN 的流量"。没有被接管的程序，它的请求压根不会经过这张表，再怎么改规则也管不到。这一点和路由本身是两个独立问题，本文只处理前者。

路由规则和代理模式是同一回事吗#

不是，但它们叠在一起生效，所以经常被混淆。

代理模式是主界面上那个全局、规则、直连的三选一开关，它决定的是"要不要让路由表参与决策"。选全局代理时，几乎所有流量被直接推给代理出站，你写的分流规则基本失去意义；选直连模式则相反；只有在按规则分流的模式下，路由表才真正开始逐条匹配。

排查时可以利用这个关系：把模式临时切到全局，如果原本打不开的网站立刻好了，说明问题出在某条规则把它判成了直连或拦截，范围一下子缩到规则表内部。

预定义规则集选哪一套最省心#

v2rayN 内置了几套现成方案，覆盖了从"什么都走代理"到"尽量少走代理"的不同取向。

日常选第二套即可。它把国内站点留在本地出口，既避免绕一圈增加延迟，也省下套餐流量——国内视频、网盘、游戏更新这类大流量走代理是纯粹的浪费，而且有些服务还会因为出口在境外而限速或触发风控。

proxy、direct、block 分别什么时候用#

三种出站对应三种完全不同的处理方式，用错的后果差别很大。

block 是最容易出事的一个。它不是"不走代理"，是"不发出去"，被它命中的请求会彻底失败。用通配符批量拦截时务必先确认范围，否则会连带打掉正常服务。

geosite 和 geoip 的判定依据差在哪#

两者是路由规则里最常见的两类内置列表，判定时机完全不同。

geosite 按域名匹配，在 DNS 解析之前就能得出结论。它的优势是不受解析结果影响，也能覆盖同一个 IP 上托管多个站点的情况；劣势是遇到程序直接用 IP 地址访问时完全失效——请求里根本没有域名可供匹配。

geoip 按目标 IP 所属地区匹配，必须等到域名解析完成才知道该走哪条。它能兜住纯 IP 访问的场景，但如果本机的 DNS 被污染，解析出来的 IP 本身就是错的，判定自然也跟着错。

所以标准做法是两条都写，各补对方的短板。下面是一段结构示例，展示规则条目的组织方式，实际界面里是表格化填写的：

{
  "rules": [
    {
      "type": "field",
      "domain": ["domain:example.invalid"],
      "outboundTag": "proxy"
    },
    { "type": "field", "ip": ["geoip:private"], "outboundTag": "direct" },
    { "type": "field", "domain": ["geosite:cn"], "outboundTag": "direct" },
    { "type": "field", "ip": ["geoip:cn"], "outboundTag": "direct" },
    { "type": "field", "network": "tcp,udp", "outboundTag": "proxy" }
  ]
}

注意最后一行的兜底规则，它保证没被任何前置规则命中的流量有明确去向。少了这一行，未匹配流量的行为取决于默认出站设置，容易出现难以复现的时好时坏。

想让某个网站强制走代理，规则该写在第几行#

最上面。这是本文最需要记住的一条。

规则表是有序的，请求从第一行开始逐条比对，命中即停止。如果你把 domain:example.invalid 走 proxy 这条写在 geosite:cn 走 direct 的下面，而这个域名恰好被收录在 cn 列表里，那么它在上一行就被判成直连了，你写的那条永远没有被读到的机会。

判断原则是：越具体的规则越靠前，越宽泛的规则越靠后。单个域名 > 域名后缀 > 内置列表 > 兜底规则，按这个梯度从上往下排，基本不会出错。

内置的地区列表会随着规则文件更新而变化，某个域名今天不在 cn 列表里，下次更新后可能就进去了。如果一条一直好用的规则突然失效，检查一下是不是列表更新导致的匹配顺序变化，比重写规则更快。

局域网地址与内网服务怎么保证不被代理#

靠 geoip:private 这条规则，它覆盖了 RFC 定义的私有地址段。路由器管理页、局域网里的 NAS、家庭打印机、本机监听的开发服务，这些目标的 IP 都落在私有段内，一旦被送进代理就必然失败——代理节点在境外，它当然找不到你家的路由器。

这条规则要放得足够靠前，至少要在所有 proxy 规则之前。预定义规则集通常已经包含它，但如果你从空白开始手写规则，非常容易漏掉，表现就是代理一开局域网设备全部访问不了。

除此之外还有两类地址值得单独排除：本机回环地址，以及公司或学校内部的专用域名。后者往往不在私有 IP 段里，需要按域名后缀单独加一条 direct。

规则改完不生效，通常漏了哪一步#

按下面的顺序核对，四步之内基本能定位。

1. 确认代理模式。当前是不是处于按规则分流的模式。如果停在全局代理上，任何自定义规则都不会被执行。
2. 确认配置已下发。保存路由设置不等于内核已经重载。回到主界面重新选中当前节点，或重启内核服务，让新配置真正生效。
3. 确认顺序。把新规则挪到列表最顶部再测一次。如果挪上去就生效了，说明原来是被前面的规则截胡，属于顺序问题而不是写法问题。
4. 确认浏览器没有自己的代理设置。浏览器扩展里的代理规则优先级高于系统层，它会绕过 v2rayN 的整套判断，让你误以为路由规则失灵。

如果四步都过了仍然不对，那多半不是路由的问题，而是流量根本没进到 v2rayN。这属于接管范围的问题，需要换一个方向查，系统代理和 TUN 模式的覆盖差别那篇讲的就是这一层。至于规则配得没错、现象却仍是网页打不开的情况，可以按能测速却打不开网页的排查顺序从故障现象倒推。

小结#

路由表是一张有序清单，命中即停止，因此规则的位置和规则的内容同样重要。日常配置用绕过大陆的预定义规则集就够，它已经把 geosite:cn、geoip:cn 和私有地址段安排妥当。自定义规则遵循具体在前、宽泛在后的梯度，末尾留一条兜底。block 意味着彻底丢弃而不是不走代理，范围要收紧。改完不生效时先查模式、再查配置是否重载、然后查顺序，最后才怀疑写法。