V2Ray 进阶配置手册

订阅分组与服务器过滤

区分订阅地址、服务器条目与活动配置

订阅分组保存配置来源及更新选项，服务器条目保存实际连接参数，活动配置则是当前启动内核所使用的那一项。三者不是同一个对象。在列表中切换分组通常只改变可见范围，不一定改变正在使用的服务器；选中某一行也不一定已经设为活动服务器。修改后先看客户端的当前服务器提示，再停止并重新建立连接，避免拿旧连接的结果判断新配置。

首次整理时，按来源建立分组，例如“主用订阅”“备用订阅”“手动配置”。在 v2rayN 的订阅分组设置或 v2rayNG 的订阅设置中填写备注与订阅地址，然后执行该分组的更新操作。分享链接只包含一个或一组具体连接参数，不自动提供持续更新能力。导入方式的区别可对照分享链接与订阅地址说明，不要把单节点链接误填进订阅地址字段。

用备注筛选，不修改协议字段

服务器过滤首先作用于列表，不等于网络路由。搜索“备用”只会缩小可见条目，不会自动让某类网站走备用服务器。先用普通关键词确认匹配范围；只有界面明确支持正则表达式时，再使用正则。比如 ^(办公|备用)- 表示备注以指定前缀开头，不能假定所有搜索框都接受它。包含与排除过滤的组合方式也应通过实际列表确认，避免把可用条目全部隐藏。

过滤依据最好选择稳定的备注前缀，而不是临时延迟值或易变的排序位置。订阅更新可能改变备注、顺序和条目数量，同名条目也可能使用不同的地址、端口或传输设置。判断是否重复时，应对照服务器地址、协议、端口和传输参数，不只看名字。用户名、标识和密钥属于敏感连接信息，截图与日志分享前要遮盖，订阅地址中携带的访问令牌也应一并处理。

更新失败时先保留现有条目

更新订阅前，先确认该操作是否会删除旧条目再导入新条目。不同客户端及更新方式的保留策略不同，不应依赖未经验证的行为。重要的手动条目单独导出备份，不直接放进会被重建的分组。如果更新后为空，先看返回内容是否真是客户端支持的订阅格式，再检查地址是否过期、是否返回登录页面，以及获取请求是否经过了可用网络。

遇到“当前代理不可用，所以无法通过当前代理更新订阅”的循环时，区分订阅获取链路与服务器连接链路。只有来源允许且本地网络能够访问时，才改用不经过代理的更新方式；不要反复切换全局设置而丢失原始状态。记录失败发生在域名解析、连接建立还是内容解析阶段，恢复旧配置后再逐项重试。更新成功也只表示取得配置，不表示其中所有条目都能连接。

最后建立一套可重复的检查方法：确认分组名称，清空筛选条件，比较更新前后地址与关键参数，再手动选择活动服务器。先做一次真实网页访问，再决定是否批量测试。测试会产生连接与流量，过密的批量操作可能触发服务端限制。保留少量已验证的备用配置，比依赖列表排序更容易在故障时恢复。

路由规则实战：先匹配，再选择出站

明确规则顺序与默认出站

Xray 的路由规则通常自上而下检查，匹配后交给指定出站。规则的先后顺序比列表是否整齐更重要：精确域名、指定应用入口或特殊目标应放在较宽泛的地区规则之前。编辑前先列出已有出站标签，确认 direct、proxy、block 是否真实存在。标签是区分大小写的引用名称，不是固定保留词；写一个不存在的标签不会自动创建对应连接。

同一条规则中，不同条件字段通常需要同时满足；同一字段的多个值通常表示其中任意一个匹配。例如同时填写 domain 与 port，表示符合域名条件且端口符合要求，不是域名或端口任一命中即可。需要“域名走代理，另有一批端口也走代理”时，拆成两条规则更清晰。规则越长，越应把判断条件写成一句可复述的话，再落到配置中。

从一条精确域名规则开始

以下是 Xray 的 routing 局部片段，假定配置中已存在 proxy 与 direct 出站。示例先将文档测试域名交给代理，再处理境内域名与私有地址。full: 只匹配完整域名，domain: 匹配该域名及其子域名。示例域名用于说明语法，正式配置时应填写实际目标，不要用它验证服务可用性。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

geosite 与 geoip 是规则数据引用，不是在线实时查询。对应文件缺失、分类名称不受支持或数据过旧，都可能导致加载失败或匹配不符合预期。更新客户端与规则数据是两个层面的操作。出现错误时，先用一条 full: 规则验证路由骨架，再恢复集合引用，不要同时更换内核、数据文件和全部规则。

理解 domainStrategy 的解析时机

AsIs 不为了路由判断额外解析目标域名，适合以域名规则为主的场景。IPIfNonMatch 在域名形式未能匹配规则时尝试解析，并用所得地址重新判断。IPOnDemand 在匹配过程中遇到需要 IP 的规则时就可能解析。它们控制路由阶段的行为，不直接决定最终使用哪台 DNS 服务器，也不能等同于出站连接阶段的地址选择策略。

当应用直接交给客户端一个 IP 地址时，域名规则可能没有输入可匹配。流量嗅探可以在部分 HTTP 或 TLS 请求中识别域名线索，但不能恢复所有协议的原始域名。加密握手、应用缓存以及纯 IP 请求都会影响结果。排错时先确认入口收到的是域名还是 IP，再决定使用域名规则、地址规则或按入口分流，不要仅因规则名字正确就认定它一定命中。

验证时清理应用旧连接，使用一个明确目标发起新请求，再查看访问日志中的目标与出站标签。浏览器连接复用会让修改后的规则看起来没有生效；重启内核也不一定清空浏览器自己的缓存。如果启用日志后出现大量记录，缩小测试范围并及时关闭详细输出。一次只验证一条新增规则，确认命中后再扩展到域名集合，这样才能定位到底是顺序、解析还是标签引用出了问题。

DNS 配置优化：把解析与连接路径分开检查

识别不同层次的解析请求

一个请求可能涉及系统 DNS、应用自带解析器、内核内置 DNS 和代理服务端解析。设置内核的 dns.servers，并不意味着所有应用都会使用它。系统代理主要影响遵循代理设置的请求；浏览器启用自有加密 DNS 后，还可能沿独立路径解析。先确认域名在哪里变成 IP，再讨论应该使用哪台解析器，否则很容易只修改了没有参与当前请求的那一层。

还要区分目标网站域名与代理服务器域名。代理连接建立前，服务器自身的域名通常需要先得到可用地址，这一步不能依赖尚未建立的同一条连接。若服务器地址是域名，先确保启动解析链路可用，再设置目标域名的分流解析。把所有 DNS 请求一律强制交给代理，有时会形成启动依赖循环，表现为内核启动正常但第一条连接始终无法建立。

使用限定域名的解析器配置

下面的 Xray 局部片段把 geosite:cn 对应域名优先交给境内解析器，并保留一个通用解析器。expectIPs 检查返回地址是否符合预期范围，不能验证网站身份，也不能保证地址具有最佳线路。该配置依赖相应规则数据；只有确认本地网络可以访问这些 DNS 地址时，示例才有测试意义。解析请求本身走哪条出站，还需要结合实际内核和路由设置检查。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      "1.1.1.1"
    ]
  }
}

域名优先匹配、预期地址过滤与后备查询会共同影响结果，不能把服务器数组简单理解为“第一台失败后才用第二台”。增加解析器前先检查当前内核对后备策略字段的支持，并用日志确认实际查询行为。若一台解析器已经稳定返回结果，多加几台可能只增加等待和不确定性。对明确要求单一路径的域名，应单独设置匹配范围与后备行为，而不是依赖数组位置猜测。

选择明文 DNS、DoH 与地址族策略

传统 DNS 常使用 UDP 或 TCP 的指定端口；DoH 通过 HTTPS 承载解析请求，能保护到解析器这一段的传输，但不替代代理，也不自动解决错误路由。DoH 地址若使用域名，同样需要考虑其自身的启动解析。只有当前内核支持对应地址格式、网络能够访问端点，并且证书验证正常时才启用。不要为了消除报错而关闭证书验证，那会改变连接的安全边界。

UseIP 允许按配置获取两种地址族，UseIPv4 与 UseIPv6 则限制查询方向。限制为 IPv4 可用于判断故障是否与 IPv6 路径有关，但不是适用于所有网络的永久修复。若系统发布 IPv6 地址、TUN 却只接管 IPv4，应用可能优先尝试未被接管的路径。应把 DNS 返回结果、系统路由和出站能力放在一起检查，而不是只修改解析器地址。

排查“能连接但部分域名打不开”时，先对同一个域名分别记录系统解析与内核日志结果，再检查是否命中了预期的域名规则。系统查询工具只能说明工具所用的解析链路，不能代表代理请求内部的结果。随后重启测试应用、清理其 DNS 缓存或等待记录过期，再发起新连接。只刷新客户端列表不会清除所有层级的缓存，旧地址可能继续被使用一段时间。

保存一份只使用单个可达解析器的基线配置。新增域名分流后，先测试普通域名，再测试指定集合，最后测试重启后的首次连接。如果只有冷启动失败，优先检查启动解析依赖；如果只有长期运行后失败，再检查缓存、网络切换及解析器可达性。这样的分层测试比一次开启 DoH、FakeDNS 与复杂后备规则更容易得到确定结论。

TUN 模式：检查接管范围与系统路由

区分系统代理、虚拟网卡与 Android VPN

系统代理向应用提供代理地址，只有遵循该设置的程序才会使用。TUN 则通过虚拟网络接口接收系统交给它的 IP 流量，再由相应组件转成代理请求。二者工作层级不同，开启 TUN 不等于更换服务器协议，也不保证所有程序都被接管。桌面端优先在 v2rayN 中使用界面提供的 TUN 选项；实际处理组件与配置格式应以当前客户端生成结果为准。

Android 的 v2rayNG 通常借助系统 VPN 服务接收应用流量，其权限提示与桌面虚拟网卡的安装过程不同。不要把桌面 TUN 配置文件直接导入 Android 客户端。v2flyNG 使用另一内核路线，功能也不能根据 v2rayNG 的菜单推断。选择客户端后，先确认普通连接可用，再单独启用系统接管，才能区分故障来自服务器参数还是本机的流量入口。

启用前排除路由冲突

启用前关闭其他正在接管默认路由的网络工具，并记录已有 VPN、虚拟机网卡与企业网络设置。多个组件同时修改默认路由、DNS 或防火墙时，现象可能随启动顺序变化。桌面系统如果要求提升权限，按客户端提示操作，不要通过反复启动多个实例绕过错误。虚拟接口创建失败时，应先看权限与驱动日志，而不是修改订阅或更换协议。

特别检查代理服务器自身的连接是否被再次送回虚拟接口。TUN 接管大部分流量时，需要为底层代理连接建立正确的绕行路径，通常由客户端自动处理。如果手工添加系统路由或改动网卡绑定，可能破坏这种排除关系，形成流量循环。表现往往是开启接管后全部断开，关闭后立即恢复。此时先恢复自动接口与默认路由设置，再逐项恢复自定义项。

分别测试 TCP、UDP 与局域网

网页能打开只证明部分链路正常，不能代表 UDP、实时音视频或局域网访问都正常。TUN 能接收 UDP，也需要后续出站协议、服务器端和目标网络共同支持。测试失败时，先判断请求是否进入客户端，再看出站是否支持对应网络类型。不要通过把所有 UDP 直接丢弃来掩盖问题；这可能让应用退回其他传输，也可能使部分功能完全不可用。

局域网设备访问还涉及私有地址路由、防火墙和名称解析。启用绕过局域网规则通常只处理连接流向，不自动解决打印机发现或多播广播。先用设备的实际私有地址验证基础连通性，再判断发现协议是否受到接管影响。允许来自局域网的连接是开放本机代理监听的另一项设置，与本机访问局域网设备不同，不要为了修复后者随意打开前者。

在 Android 上，分应用代理应明确采用“只代理所选应用”还是“绕行所选应用”。名单相同而模式相反，结果会完全不同。应用更新、重新安装或工作资料环境可能改变可见应用范围，修改名单后要重新建立 VPN 连接再测试。部分系统对后台进程有额外限制，若锁屏后断开，应先检查系统电池与后台运行设置，而不是把原因归结为路由规则。

稳定性验证应覆盖开启、关闭、切换网络和休眠恢复。每次观察系统 DNS 与默认路由是否随客户端正确恢复，避免遗留不可达的解析地址。如果关闭客户端后系统仍不能联网，先恢复系统代理和自动 DNS，再检查是否有残留虚拟接口设置。完整记录接管前后的变化，能把本机网络状态问题与远端连接问题分开，也方便回退到已经验证的普通代理模式。

FakeDNS：维护域名映射，而不是连接虚拟地址

理解虚拟地址的用途

FakeDNS 为查询的域名分配一个虚拟 IP，并在内核中保存域名与地址的对应关系。应用随后连接这个地址时，代理组件根据映射找回域名，再执行路由与出站处理。虚拟地址不是目标服务器的真实地址，也不是可以从任意网络直接访问的地址。它的价值在于让只携带 IP 的后续连接仍有机会恢复域名信息，前提是解析与连接都经过相互配合的处理链路。

因此，只在 DNS 设置里填入 fakedns 并不构成完整方案。客户端还需要把相关查询交给它，并确保虚拟地址范围的连接被接管，入口也要能够还原映射。系统代理场景中，应用如果自行解析后绕过代理连接，可能得到一个外部网络无法路由的地址。先明确接管范围，再启用 FakeDNS；不要用它替代尚未配置正确的系统路由。

先确认地址池与嗅探能力

以下为 Xray 的 DNS 与地址池局部示例，展示字段关系，不包含 TUN 接管设置。198.18.0.0/15 是用于基准测试的特殊地址范围，常被用作虚拟地址池，不是真实目标站点网段。已有企业网络或其他接管工具也可能使用该范围，冲突时不能只扩大地址池，而应统一规划。入口片段必须合并到真正接收对应流量的入站中，不能新建一个未被使用的入站来代替。

{
  "dns": {
    "servers": ["fakedns"]
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

对实际承接流量的 Xray 入站，嗅探配置可以采用下面的形式。destOverride 中的 fakedns 用于相关域名还原，routeOnly 约束嗅探结果用于路由的方式。具体选项是否由客户端自动生成，必须查看当前内核和生成文件。若客户端的 TUN 链路由另一组件处理，不能把这段 Xray 入站配置当作通用的 TUN 配置语法。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls", "fakedns"],
    "routeOnly": true
  }
}

处理缓存与映射生命周期

映射的生命周期是排错重点。应用可能缓存虚拟地址，但内核重启后不再保存原映射，于是旧连接只有虚拟 IP，无法还原真实域名。表现可能是刚启用时正常，重启客户端后部分应用失败。先结束应用的旧连接并清理相关 DNS 缓存，再重新查询和连接。不要把虚拟地址保存成长期服务器地址，也不要把它复制到其他设备上测试。

地址池容量控制可维护的映射规模，不是并发连接数，也不是性能评分。长时间访问大量不同域名时，映射替换与应用缓存可能共同造成问题；盲目增加容量不能修复未接管的连接。先在较小范围内验证查询确实进入 FakeDNS、连接确实回到同一处理链路，再观察运行稳定性。确认基础逻辑后，才根据内核说明与设备资源评估是否需要调整容量。

有些应用会检查解析结果、使用硬编码地址或发起自己的加密 DNS 查询，这类行为可能绕过预期映射流程。对单个不兼容应用，先尝试恢复真实 DNS 并保留其他路由设置，比较结果。如果仅关闭 FakeDNS 就恢复，说明应检查映射链路，而不是立即更换订阅。需要给某些域名使用真实解析时，也要保证后续路由能处理真实地址，避免两套判断互相冲突。

验收时至少覆盖首次查询、应用重新启动、内核重新启动和网络切换四种情况。日志中若持续出现虚拟目标地址而没有还原域名，先查映射是否存在以及入站是否正确，不要给虚拟地址添加直连规则。虚拟地址一旦直接送到外部网络通常无法完成目标访问；正确修复方向是恢复域名映射与接管闭环，而不是扩大直连范围。

多订阅管理：隔离来源与更新策略

建立来源清单，而不是混成一个列表

多订阅的主要难点不是导入数量，而是配置来源、更新结果与活动服务器之间的关系。建议每个来源使用独立分组，并记录用途、获取方式和是否允许自动更新。备注写实际用途，不依赖某个容易改变的节点名称。手工维护的特殊配置单独放组，避免订阅刷新时被替换。需要比较两个来源时，先在各自分组内测试，再决定哪个作为主用。

订阅可能下发地址、端口、协议与传输参数，但不应假定它能够控制客户端全部路由、DNS 或接管设置。不同订阅格式的覆盖范围不同，有的只提供服务器列表。导入后检查实际变化，尤其是内核选择和传输字段。将来源配置转换为另一种格式时，也可能丢失原来格式中的部分能力；遇到解析成功但连接失败，应回看原始参数是否被完整保留。

避免同名、去重与更新覆盖的歧义

两个来源都叫“备用线路”，并不说明它们连接同一服务器；相反，不同名称也可能指向相同地址。去重前先确定去重依据，至少考虑协议、地址、端口、身份字段与传输设置。只根据地址和端口删除条目，可能误删使用不同身份或安全参数的有效配置。去重功能的具体算法若不明确，先导出备份，再在副本中操作，不要直接清理唯一可用的列表。

对订阅条目的手工修改要建立可追踪边界。临时调整服务器备注通常影响较小，但改动 SNI、传输路径或公钥后，下次更新可能恢复来源值。需要长期保留的修改应复制为独立手工条目，并写清原始来源与修改目的。不要用关闭订阅更新来掩盖配置冲突，否则地址或服务参数变化时会继续使用过期内容，增加后续排错难度。

更新、选用与故障切换分别处理

更新订阅、延迟测试、选择活动服务器是三个动作。订阅更新成功不应被理解为已经切换；列表排序也不应被理解为自动选优。即使客户端提供自动选择功能，也要检查触发条件、测试地址和切换范围。测试目标可达不代表所有业务都可达，TCP 建连成功也不代表完整请求成功。不同测试的含义见延迟测试与下载测速区别。

安排自动更新时，避开需要稳定长连接的工作时段，并先确认更新是否会触发内核重载。移动设备切换网络或进入省电状态时，计划任务可能延迟执行，因此不要把自动更新当成严格定时保证。重要使用前主动检查配置与连接状态。若多个订阅都经过同一条失效连接获取，备用来源也可能同时无法刷新，应保留已经验证的离线配置备份。

订阅地址往往具有访问权限，不能当成普通公开网页链接。浏览器历史、截图、剪贴板同步及导出文件都可能包含完整地址。分享配置时只提供排错所需字段，不公开订阅地址和连接身份。怀疑地址泄露时，通过来源提供的管理方式更换访问凭据，再更新客户端；仅改本地分组名称不会使旧地址失效，也不会阻止其他设备继续访问。

故障切换可以采用固定流程：先确认当前分组与活动服务器，检查订阅是否刚发生变化，再切到已验证的备用条目。切换成功后保留故障配置副本，用单独测试还原原因，不立即删除整个来源。如果两个独立来源同时失败，优先检查本机 DNS、系统时间、网络权限与接管状态。多来源能降低部分故障影响，但不能绕过同一设备上的共同网络问题。

自定义出站：管理标签、默认流向与回退

先确认配置由谁生成

出站描述内核如何向目标建立连接，路由则决定哪一条请求使用哪个出站。客户端图形界面通常根据活动服务器、路由模式与参数设置生成运行配置。直接编辑临时生成文件可能在下次启动时被覆盖。长期定制前，先确认客户端是否提供自定义配置或对应模板入口，并导出当前结果作对照。桌面端优先用 v2rayN 的图形选项完成常规设置，只有界面无法表达时才转入完整配置维护。

Xray、V2Fly 与其他网络组件的配置格式不能只凭相似字段互换。本节示例面向 Xray 风格 JSON，不是所有客户端都能直接导入。自定义完整配置还可能绕过客户端的服务器列表生成逻辑，因此切换列表条目后未必改变连接目标。保存后检查实际启动文件、内核类型与日志中的配置加载结果，先排除“修改了没有被使用的文件”这一类问题。

从直连与阻断出站验证骨架

下面是局部出站数组，freedom 表示直连，blackhole 表示丢弃匹配流量。第一项在未被其他规则接管时通常成为默认出站，所以此示例默认直连；它不是完整的代理方案。若要加入实际代理出站，应从已验证的客户端配置中保留正确连接参数，再让路由引用对应标签，不应凭空拼接服务器身份信息。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

标签应短而稳定，并且在同一配置中保持唯一。把出站标签从 proxy 改为 proxy-main 后，所有引用旧标签的路由和其他关联设置都要同步修改。不要用显示备注替代标签，也不要让两条不同出站共用同一个名称。维护时可以先列一张“入站标签、规则条件、目标出站”的对应表，再检查每个引用是否有定义，这比只看 JSON 缩进更可靠。

区别串联、分流与自动回退

配置多个出站只表示存在多种连接方式，不会自动进行故障切换。路由按目标分配到不同出站属于分流，通过一个出站建立另一个连接属于串联，基于观测结果选择出站则需要额外的选择机制。三者不能混为一谈。没有显式配置健康检查和选择逻辑时，第一条代理失败不会因为数组里还有第二条就自动使用它，重复添加出站也不能提高可用性。

串联会增加依赖关系：前一段连接的 DNS、传输能力与稳定性都会影响后一段。若链路里某一段不支持需要的网络类型，最终请求仍然失败。先分别验证每条出站单独可用，再讨论串联，并确认当前内核支持相关字段。不要同时加入多层串联、复杂路由和不同解析策略；一旦出错，难以判断失败发生在哪一段，也难以获得有意义的日志。

用可恢复的变更验证最终配置

自定义配置先做语法与加载验证，再做业务验证。合法 JSON 不代表字段被当前内核支持，字段能加载也不代表路由引用正确。遇到启动错误，按日志指出的对象定位，不要直接删除整个路由段。先恢复最近一次成功版本，然后只加入一个出站或一条规则。客户端若提供配置测试入口，优先使用；没有时也要在重启前保留原文件及能够恢复的图形配置。

业务验证至少选一个应直连目标、一个应代理目标和一个明确阻断的测试目标，分别观察日志与应用结果。阻断规则应限制在清楚的域名或测试范围内，避免误伤更新与解析请求。连接失败时，从入口是否收到请求开始，依次检查匹配规则、目标标签、地址解析及远端握手，而不是只根据最后的超时信息推断服务器故障。需要查看桌面日志入口时，可参考v2rayN 主界面功能说明。

完成后把有效配置、修改目的和验证条件一起保存。记录采用的接管方式、DNS 路径与出站标签，比只记录“能够联网”更有复现价值。导出前移除不必要的敏感信息，对外交流时另做脱敏副本。若后续更换内核或客户端，先用原有基线验证，再迁移自定义字段。日常连接仍按入门指南的连接与验证流程执行，复杂设置只保留确有用途且能够解释的部分。