适合已经导入节点、能够建立连接,但希望本地服务直连、其他流量按规则走代理的 Android 用户。先用“绕过局域网及大陆地址”建立基线,再添加少量域名例外,最后通过日志与对照测试确认出口。本文区分路由分流、分应用代理与 DNS,避免用一个开关解释所有连接问题。
先确认:哪些流量进入路由
v2rayNG 使用 Xray 内核处理代理连接。选中节点决定代理出口连接到哪台服务器,路由规则决定某条请求是否使用这个出口。VMess、VLESS 等节点协议不会自动规定“国内直连、海外代理”;订阅更新成功,也不代表路由策略已经按需要配置。
本文以 Android 的 VPN 模式为前提。应用流量先进入 v2rayNG,再由内核选择直连、代理或阻断。若开启分应用代理,被排除的应用可能直接绕过这条处理链;应用自身的网络设置、其他 VPN 服务也会影响测试结果。
先分清:应用范围与请求去向
分应用代理
- 按 Android 应用决定是否进入 VPN 处理范围。
- 适合明确排除某个应用,而非区分同一应用里的不同网站。
- 测试浏览器必须处于处理范围内。
路由分流
- 对进入内核的请求按域名、IP 等条件匹配。
- 同一个浏览器可以同时访问直连和代理站点。
- 自定义完整配置可能自行定义规则,不一定沿用界面预设。
先保证测试应用进入 VPN,再验证路由;否则“没有代理日志”不能直接证明直连规则命中。
选择预设:先建立可回退基线
打开主界面侧栏,进入「设置」中的路由相关设置,找到「预定义规则」。部分版本把「路由设置」作为侧栏独立入口,或将选项称为「路由模式」。菜单分组有差异时,以“预定义规则”及下列选项文字定位,不要把节点选择菜单当作路由入口。
绕过局域网及大陆地址
推荐让局域网与大陆地址按预设直连,其余流量通常交给代理出口。具体分类依赖当前规则数据及生成配置,需要验证常用站点。
适合:同时使用本地服务、国内站点和海外服务的日常环境。
绕过局域网地址
保留局域网直连,其他流量通常走代理,不再依靠大陆地址分类决定公网请求去向。
适合:需要减少地理分类影响,或临时对照排查的环境。
全局代理
将进入处理范围的流量主要交给代理。它不等同于接管全部应用,也不能排除 DNS、应用排除列表或自定义配置的影响。
适合:短时判断问题是否来自分流规则;测试后恢复日常预设。
-
记录原设置
截存当前「预定义规则」「域名策略」与自定义规则内容,记录分应用代理是否开启。先保留回退点,不同时调整节点、DNS 和路由。
-
选择预设
在「设置」→路由相关设置→「预定义规则」选择「绕过局域网及大陆地址」。若侧栏已有「路由设置」,从该入口查找同名选项。
-
检查域名策略
找到「域名策略」,记录当前值。首次配置可保留默认值;只有明确需要 IP 规则补充匹配时,再对照后文评估
IPIfNonMatch。 -
重启并测试
保存后停止、重新启动连接,让新配置重新加载。依次打开局域网管理页、国内站点与海外站点,记录可达性,再开始添加例外。
局域网直连:地址段比名称可靠
路由器、打印机与 NAS 常用私有地址。若把这些请求发往远端代理服务器,远端通常无法访问手机所在的家庭网络。预设中的私有地址规则用于解决这类问题,但应检查是否覆盖实际地址,而不是只添加一条 192.168.1.1。
支持相应数据文件的配置可以用 geoip:private 引用私有及其他本地用途地址分类,实际范围以所用数据为准。IPv6 局域网也要单独留意,例如唯一本地地址 fc00::/7;只写三段 IPv4 网段,并不能覆盖所有本地通信。
- 先用 IP 测试:在实际网关为该地址时访问
http://192.168.1.1;不要把示例地址当成所有路由器的默认地址。 - 再用设备名测试:IP 可达、设备名不可达时,优先检查局域网 DNS 或名称发现。路由直连不会自动修复名称解析。
- 区分发现与连接:投屏、打印机搜索涉及组播等机制,不能仅凭一个网页能打开,就认定设备发现也正常。
- 检查网络隔离:访客 Wi-Fi、无线客户端隔离也会阻止互访,修改代理规则并不能解除路由器的隔离策略。
域名例外:精确规则放在分类前
Xray 路由规则按配置顺序匹配,第一条符合条件的规则决定去向。因而“某个域名必须代理”应放在宽泛的大陆直连分类之前。界面可能将代理、直连、阻断分别放在不同输入框;输入框的视觉位置不一定就是最终规则顺序,应查看导出配置或日志确认。
| 写法 | 匹配范围 | 适用场景 |
|---|---|---|
full:api.example.com | 只匹配完整域名 | 仅调整一个接口,不扩大到其他子域 |
domain:example.com | 匹配该域名及其子域名 | 整站直连或整站代理 |
geosite:cn | 匹配数据文件中的 cn 域名分类 | 大陆站点的宽泛分类 |
geoip:cn | 匹配数据文件中的中国 IP 分类 | 按目标 IP 补充判断 |
下面仅演示 Xray 的规则片段,不是可以直接导入的完整节点配置。example.com 是语法示例域名,实际使用时需换成目标站点;proxy、direct、block 必须与当前配置真实存在的出站标签一致。
{
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["full:ads.example.com"],
"outboundTag": "block"
},
{
"type": "field",
"domain": ["full:api.example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:cn"],
"outboundTag": "direct"
}
]
}
DNS 与分类:为什么看似海外却直连
“海外站点”不是内核可直接识别的业务属性。域名可能被分类库收录到某个集合,也可能通过 CDN 解析到中国 IP;同一服务的登录、图片与 API 还可能使用不同域名。因此,网页主域名走代理,不代表所有子请求都走同一出口。
AsIs:路由阶段按现有目标信息匹配,不为 IP 规则主动解析域名。它不表示整个连接过程都不会进行 DNS 查询。IPIfNonMatch:域名未命中规则时,尝试解析并用得到的 IP 再匹配。它能补充 IP 分类,也可能把解析到国内 CDN 的域名判为直连。IPOnDemand:遇到需要 IP 信息的规则时即可触发解析,规则位置会影响解析时机,不建议在没有对照记录时随意切换。
如果明确要求某个服务代理,优先补一条准确的域名代理例外,而不是扩大整个地区的代理范围。浏览器若使用自身的加密 DNS,内核可获得的域名信息可能改变;嗅探能够在部分连接中补充域名,但受协议及加密方式限制,不能当作必定成功的识别手段。
广告域名:先小范围阻断
广告阻断适合放在允许规则之前,但应从确认过的独立域名开始。某些规则数据提供 geosite:category-ads-all 分类,使用前必须确认当前文件确实包含该分类;分类缺失可能导致配置加载失败,而不只是“少拦几个广告”。
- 先用
full:阻断一个明确的广告主机,重启连接后检查页面、登录和播放功能。 - 不要把图片 CDN、支付接口或验证服务的整个主域一并阻断,同一域名可能承载必要资源。
- 出现误拦时,先撤销最近新增的规则;确需白名单时,将精确允许规则放到对应宽泛阻断规则之前。
- 广告与正文共用域名时,域名路由不能按网页路径区分内容。不要将域名阻断当作完整的页面过滤工具。
对于“广告消失但页面一直转圈”的情况,保留日志中的失败域名,再逐条恢复。一次导入大批规则后只观察首页,很难定位登录、验证码或视频播放环节的误拦来源。
验证分流:日志、出口与回退
保存规则后,停止并重新启动 v2rayNG,再关闭测试应用的旧连接。已经建立的长连接可能继续沿用原路径;浏览器缓存也可能让页面看似正常,却没有产生新的请求。以下是验证步骤,不是预先宣称的实测结果。
| 测试对象 | 预期观察 | 异常时检查 |
|---|---|---|
| 实际路由器管理 IP | 局域网直连且管理页可访问 | 私有地址规则、Wi-Fi 隔离、实际网关 |
| 常用国内站点 | 按规则使用直连出口 | 域名分类、IP 分类及更靠前的例外 |
| 明确指定代理的域名 | 日志显示代理出站标签 | 规则顺序、子域名是否遗漏 |
| 新增阻断域名 | 请求失败或显示阻断出站 | 缓存、长连接、是否进入 VPN 范围 |
在主界面侧栏「日志」查看新连接;若当前日志级别不显示路由信息,可临时提高到信息级别后重现一次问题,检查目标地址与实际出站标签,结束后恢复原级别。日志若不展示足够信息,不应只凭“连接成功”推断命中了哪条规则。分享日志前应移除节点地址、订阅链接与个人访问记录。
- 固定变量:保持同一节点、同一 Wi-Fi 和同一测试应用,每次只修改一条规则。
- 核对出口:对 IP 查询站点,先把它明确设为直连并记录结果,再改为代理对照;单次查询只证明该站点这一次请求的路径。
- 对照全局:某站点在分流模式失败、全局代理成功,重点排查该站点的规则与 DNS;两种模式都失败,则继续检查节点和服务端连通性。
- 更新后复查:更新 geo 数据或订阅后,重新验证常用站点。分类变化可能影响分流,订阅更新通常不等于更新规则数据库。
- 及时回退:若启动失败或大量站点异常,恢复原预设和自定义规则,再逐条添加,避免叠加多个未知改动。
最终保留的配置应能说明三件事:哪些应用进入 VPN、哪些目标明确直连或代理、未命中时使用哪个出口。先用稳定预设覆盖大多数请求,再用少量精确例外修正误判,比不断堆叠宽泛规则更容易维护。