本文适合已经能连接节点、准备细调分流的用户。先区分域名条目与 IP 字段,再用三条规则看清首条命中、字段组合和 DNS 解析的关系,最后在 v2rayN 中保存一份可回退的自定义方案。示例使用保留的示例域名说明语法,不把访问这些域名当成联网测试。
先分清:域名前缀与 IP 字段
Xray 的 routing.rules 是有顺序的规则数组。每条规则描述“哪些连接”交给“哪个出站”,其中 domain、ip、port 是匹配条件,outboundTag 指向已有出站。这里的路由不是订阅节点列表排序,也不会修改 VMess 或 VLESS 节点的认证参数。
| 写法 | 填写位置 | 匹配范围 |
|---|---|---|
full:api.example.com | domain 数组 | 只匹配这个完整域名,不含其下级域名。 |
domain:example.com | domain 数组 | 匹配根域及子域,例如 www.example.com,不匹配 notexample.com。 |
regexp:^api[0-9]+\.example\.com$ | domain 数组 | 匹配符合正则表达式的域名,例如 api12.example.com。 |
geosite:cn | domain 数组 | 引用当前域名数据库中的分类,实际范围以所用文件为准。 |
192.168.0.0/16 | ip 数组 | 匹配这一 IPv4 网段,不应在前面加 ip:。 |
geoip:private | ip 数组 | 引用 IP 数据库中的私有地址集合,需相应数据可用。 |
容易混淆的是“ip 前缀”:在这里,ip 是 JSON 字段名,不是与 domain: 对称的通用域名条目前缀。把 ip:192.168.1.1 填进域名列表,不能表达目标 IP 匹配。没有前缀的域名字符串通常按子串匹配,例如 example.com 的范围会比明确的 domain:example.com 更宽。
按匹配范围选择写法
单个接口改走代理,通常不需要正则;整个站点及其子域统一处理,也不需要逐个列出主机名。先使用边界清晰的写法,可以减少后续排查时的歧义。
明确域名边界
推荐用 full: 指定单一主机,用 domain: 覆盖根域与子域。两者都便于逐条核对,适合作为手写规则的起点。
适合:修正单个网站、为某个接口设置例外。
引用分类集合
用 geosite: 承载一组域名。分类名称不是随意命名的标签,必须存在于当前使用的数据库中,更新数据后成员也可能变化。
适合:维护区域或业务分类,再用少量具体域名补充例外。
正则描述模式
用 regexp: 表达编号主机等规律。Xray 使用的正则语法不等同于所有浏览器正则功能,不应直接照搬带环视或反向引用的表达式。
适合:多个主机名遵循固定命名规律,且可以列出正反测试样本。
正则要分清输入层。在图形界面的纯文本域名框中,通常填写 regexp:^api[0-9]+\.example\.com$;写成 JSON 字符串时,反斜杠需要再转义一层,如下所示。开头的 ^ 与末尾的 $ 限定完整域名,避免把更长字符串误当成目标。
{
"type": "field",
"domain": [
"regexp:^api[0-9]+\\.example\\.com$"
],
"outboundTag": "proxy"
}
匹配顺序:例外在前,集合在后
规则从上到下检查,第一条满足条件的规则决定出站,不会继续寻找“更精确”的后续规则。full: 不会天然压过前面的 domain:,分类条目也没有独立于数组顺序的优先级。
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["full:api.example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["192.168.0.0/16"],
"outboundTag": "direct"
}
]
}
}
这是路由片段,不是完整客户端配置,也不应直接作为整份配置导入。它要求现有配置已定义 proxy 与 direct 出站。对于域名目标,api.example.com 命中第一条,www.example.com 命中第二条;对于直接以 IP 发起的目标,192.168.1.20 命中第三条。
- 交换前两条:API 域名先被整个域名集合接住,后面的精确例外不再有机会命中。
- 同一数组内多个值:
domain中任一条目匹配即可,适合把同出站的几个域名合并。 - 同一规则内多个条件:例如同时填写
domain和port,通常要求两个条件都满足,而不是二选一。 - 所有规则均未命中:通常使用配置中的第一个出站,并不固定等于直连;还要检查客户端生成的兜底规则。
结论:先移动例外,再扩展分类
发现单个域名走错出站时,先把它的精确规则移到宽泛集合之前,再验证日志;不要立即增加一组重复分类,否则只会增加被遮挡的规则。
IP 网段与 DNS 策略怎样配合
IP 规则匹配的是目标地址,不是电脑当前的公网出口地址。客户端拿到域名时,是否先解析并用结果参与路由,与 domainStrategy 有关。它也不等于完整的 DNS 配置:解析器选谁、解析请求怎么发出,仍要看 DNS 与相关路由设置。
| 策略值 | 处理方式 | 检查重点 |
|---|---|---|
AsIs | 路由阶段不主动把域名解析为 IP。 | 域名未命中时,不能指望 IP 规则自动补上;原本就是 IP 的目标仍可匹配。 |
IPIfNonMatch | 域名按现有条件未匹配到规则时,尝试解析后再匹配。 | 前面若已有宽泛域名规则命中,就不会为寻找更优 IP 规则而重新选择。 |
IPOnDemand | 匹配过程中遇到需要 IP 的规则时,触发所需解析。 | IP 规则的位置会影响解析时机,过早放置宽泛 IP 规则可能改变域名例外的结果。 |
例如要让办公设备 192.168.1.20 的管理页面直连,可在 IP 字段填写 192.168.1.20/32,不必把整个私有地址范围都加入。若页面使用域名访问,应同时确认该连接交给核心的是域名还是 IP;应用代理方式、DNS 缓存以及嗅探设置都可能影响可见的目标信息。
在 v2rayN 中建立可回退的规则
下面按中文桌面界面的常见入口操作。不同版本可能将编辑动作放在按钮或右键菜单中,先认准「路由设置」与当前启用的方案;不要把路由片段粘贴到节点的服务器地址、订阅链接或传输参数中。
-
确认核心
打开「设置」→「参数设置」,检查当前节点协议对应的核心类型是否为 Xray。若版本将核心映射单独列在设置页,按该页确认;先保证节点本身可以连接。
-
备份方案
进入「设置」→「路由设置」,记录当前使用的路由方案,并使用界面提供的导出或复制功能保留副本。已有自定义规则时,先保存顺序再修改。
-
添加例外
编辑准备使用的方案,添加一条规则:域名填
full:api.example.com,出站选择代理,其余不需要的条件留空。图形表单只填字段值,不粘贴整段 JSON。 -
调整顺序
再添加域名为
domain:example.com、出站为直连的规则。使用界面移动操作,让精确例外位于整个站点规则之前;检查是否还有更靠前的分类规则覆盖它。 -
启用并验证
保存方案并将它设为当前路由,按界面提示重载或重启服务。把示例域名替换为实际受控目标后,关闭旧连接再发起新请求;若结果异常,切回备份方案定位变化。
验证时一次只改一个条件。选一个应代理的域名、一个应直连的域名,再选一个局域网 IP,分别新建连接,记录时间与目标。规则修改通常不会把已建立的长连接立即迁移到另一个出站,浏览器复用连接会让结果看起来像“保存没有生效”。
- 看核心日志:在主窗口日志区域查看新连接的目标及出站信息;默认日志不一定逐条显示规则编号,必要时临时提高日志详细程度,测试后恢复。
- 确认请求进入核心:使用系统代理时,应用必须实际遵循系统代理。应用完全绕过核心的连接,不会受到这些路由规则控制。
- 对照生成配置:如果版本提供运行配置查看或导出入口,检查
routing.rules顺序和真实出站标签,不以编辑器里的视觉位置代替最终结果。
常见问题:规则写对了为何没生效
已经用了 full,为什么还是走直连?
先检查它前面有没有 domain:、geosite: 或其他宽泛规则已经命中,再确认实际连接的主机名。网页地址与接口、图片、登录服务可能使用不同域名,只为主页面添加例外不会覆盖全部请求。
添加 geosite 分类后核心启动失败怎么办?
查看日志中的文件加载或分类不存在提示,核对当前数据文件是否包含该分类,以及核心实际读取的位置。先撤回新条目恢复连接,再通过客户端的规则数据更新功能处理;不能仅根据分类名字猜测其存在。
域名和 IP 分别能命中,放一起却不行?
同一规则里的不同条件一般是同时成立关系。若目的是“这个域名或者这个网段都直连”,拆成两条规则;若确实要限制到同一组目标,还需核查 DNS 策略与核心实际拿到的地址。
正则测试通过,粘进 JSON 却报错?
先检查反斜杠转义:JSON 中匹配一个字面点通常写成 \\.,纯文本输入框通常写成 \.。再删除当前正则引擎不支持的语法,并用一个应命中和一个不应命中的域名分别验证。
稳定的自定义路由通常由少量精确例外、明确的集合规则和清楚的兜底行为组成。每次修改都记录“目标、规则位置、预期出站、实际出站”四项,比不断堆叠相似条目更容易维护;数据库更新后,也应重新验证曾经需要例外处理的域名。