V2Ray 配置进阶手册

先建立可回退的配置模型

区分客户端设置、内核配置与系统网络

进阶配置的第一步不是增加规则，而是明确每项设置由哪一层负责。v2rayN、v2rayNG 与 v2flyNG 都是图形客户端，负责订阅管理、服务器选择、启动内核和写入系统网络设置；Xray 或 V2Fly 内核负责协议连接、DNS 查询、路由匹配与入站出站处理；操作系统则负责默认路由、系统代理、虚拟网卡和应用自身的网络权限。三层同时生效时，界面显示“已连接”只说明客户端与内核进程已经启动，不等于域名解析、路由命中和系统流量接管都正确。

排错时应沿数据流检查：应用先生成域名或目标地址，操作系统决定流量是否交给本地代理或虚拟网卡，内核再执行 DNS 与路由规则，最后选择直连、代理或阻断出站。如果浏览器可用而命令行工具不可用，重点检查系统代理继承方式；如果域名不可用但直接访问地址正常，重点检查 DNS；如果只有个别网站路径异常，重点检查规则顺序、协议能力和目标站点的地址族。按层判断可以避免反复重装客户端这种低信息量操作。

建立基线配置与变更记录

开始调整前，应保留一份已确认可连接的基线。基线只包含一个可用订阅、一个当前服务器、默认 DNS、默认路由和系统代理模式，不启用 TUN、FakeDNS 或复杂自定义出站。随后记录客户端类型、当前配置文件、所选服务器、系统代理状态以及测试应用。v2rayN 桌面端适合将不同用途的设置保存为独立配置；Android 端则应记录当前选中的配置项、分应用代理状态和电池策略，避免系统后台限制被误判为内核故障。

每次变更只处理一个主题。例如先完成订阅过滤并测试，再增加路由规则；路由稳定后再调整 DNS；最后才评估是否需要 TUN 与 FakeDNS。一次同时改动 DNS、路由和虚拟网卡，失败后无法判断是哪一步造成。变更记录不需要复杂工具，一张包含“修改前、修改项、预期结果、实际结果、回退动作”的表格即可。规则越多，回退能力越重要，因为订阅更新、网络切换和系统升级都可能暴露原先未触发的边界情况。

定义可重复的验证动作

验证动作必须固定，否则不同测试结果不可比较。基础检查至少包括：客户端日志没有持续重试；测试域名能够解析；浏览器和一个非浏览器应用都能建立连接；关闭客户端后系统代理或虚拟网卡状态正确恢复。路由验证应选择明确属于直连规则、代理规则和阻断规则的三个目标，不能只测试一个常用网页。DNS 验证则同时观察查询结果与最终连接路径，避免把浏览器缓存当成配置成功。

Windows 可用 Get-NetIPInterface 查看接口优先级，macOS 可用 scutil --dns 查看系统解析器，Linux 可用 ip route 检查路由表。命令输出只用于确认系统状态，不代表客户端内部规则一定命中。Android 端更适合结合客户端日志、网络切换和分应用测试判断。若尚未安装合适客户端，先前往客户端页面按平台选择；桌面配置首推 v2rayN，Android 可按内核需求选择 v2rayNG 或 v2flyNG。

订阅分组与服务器过滤

分组解决管理问题，路由解决流量问题

订阅分组常被误解为路由分流。分组只负责组织服务器、缩小选择范围和指定更新边界，本身不会决定某个网站走哪条出站。真正控制流量路径的是路由规则与出站标签。合理结构是先按来源保存订阅，再按用途或能力建立视图，最后由路由规则引用稳定的出站。不要把订阅名称、服务器名称和出站标签混为一层，否则订阅更新后名称变化，依赖名称的筛选与规则可能同时失效。

建议保留“来源分组”和“工作分组”两个维度。来源分组对应订阅地址，便于独立更新、暂停或删除；工作分组按协议、传输方式、区域文字或人工用途进行筛选。v2rayN 的服务器列表适合利用备注、订阅归属与过滤表达式缩小范围；v2rayNG 和 v2flyNG 的移动界面更适合保持较少分组，避免在小屏幕上维护过度复杂的筛选条件。分组名称应稳定、可读，不要把短期状态写进名称。

设计可维护的过滤条件

服务器过滤通常基于备注文本，因此准确性取决于命名质量。推荐采用“包含条件优先、排除条件补充”的策略：先限定明确协议或用途，再排除测试项、过期项与不需要的传输类型。过滤表达式应尽量短，并在订阅更新后抽查结果。若上游更改命名格式，应更新过滤条件，而不是手工逐个改名，因为下次更新可能覆盖本地修改。对重要服务器可以增加本地备注，但要确认客户端是否在更新时保留该字段。

正则表达式适合处理稳定命名，不适合猜测含糊文本。下面的示例匹配名称中含“VLESS”或“REALITY”，同时排除“测试”和“过期”。不同客户端的过滤输入框对正则支持可能不同，应先用少量条目确认结果，再用于完整列表。若界面只提供普通文本搜索，应拆成多个简单视图，不要试图在单个关键词中表达全部逻辑。

^(?=.*(?:VLESS|REALITY))(?!.*(?:测试|过期)).*$

筛选结果为空时，先去掉排除条件，再逐段增加表达式。结果过多时，检查大小写、全角符号和上游命名是否一致。过滤不会验证服务器是否可连接，也不能替代实际连接测试。延迟只能反映某一时刻的网络往返情况，不能完整代表吞吐、稳定性与协议适配。选择服务器时应结合日志中的握手结果、连续访问表现和网络切换后的恢复情况，而不是只按一次排序作决定。

更新、删除与重复项处理

订阅更新应按来源逐个执行。先更新一个订阅，确认服务器数量、命名与当前选中项是否变化，再处理下一个来源。若所有订阅同时更新，重复项或异常命名会迅速扩散，难以定位来源。删除订阅前，应确认当前使用的服务器和自定义路由没有依赖该来源。部分客户端会保留由订阅生成的历史服务器，部分客户端会在更新时覆盖；操作前查看界面的更新策略，必要时先导出客户端配置。

重复服务器不能只看显示名称。两个条目可能名称相同但地址、端口、协议参数不同，也可能参数相同却来自不同订阅。安全的处理方式是比较协议类型、服务器地址、端口、传输层和安全参数，再决定是否保留。若多个来源长期提供相同条目，可以保留来源更稳定、命名更规范的一份，其余放入停用分组，而不是立即删除。这样在更新异常时仍有回退路径。

自动选择功能也需要明确边界。它可以在候选集合内减少人工切换，但候选集合必须先经过筛选，且测试方法应与实际使用场景接近。把协议能力不同、网络路径不同的全部服务器放进同一自动组，可能导致连接行为频繁变化，给 DNS 缓存、长连接与排错带来干扰。稳定优先的场景应固定服务器一段时间，观察日志与应用行为；只有确认候选项兼容后，再启用自动策略。

路由规则的匹配顺序与实战结构

理解从上到下的首次命中

V2Ray 路由的核心不是规则数量，而是匹配顺序。多数配置按列表从上到下判断，一条连接命中首个符合条件的规则后，就不会继续检查后面的规则。具体规则应放在通用规则之前，阻断规则应覆盖明确且稳定的目标，最终再设置兜底路径。若把范围很大的域名、地址或端口规则放在顶部，后面的细分规则即使语法正确也不会生效。

一套可维护的顺序通常是：先处理内网地址与本机服务，再处理明确阻断项，然后处理需要指定路径的域名或地址集合，接着处理常用直连集合，最后放默认出站。规则条件之间要区分“同一规则内的组合关系”和“多条规则之间的先后关系”。同一条规则同时写入多个字段时，内核通常要求相应条件共同满足；同一字段中的多个值则表示任一值匹配。配置前应先用自然语言写出意图，再翻译为规则。

域名、地址与进程条件的边界

域名规则只在内核能够获得目标域名时生效。如果应用先自行解析并直接连接地址，内核看到的可能只有目标地址，此时需要地址规则、DNS 嗅探或 TUN 配合。地址规则较稳定，但大型服务的地址范围会变化，手工维护成本高。GeoSite 适合按域名类别匹配，GeoIP 适合按地址归属匹配；两类数据需要保持更新，具体更新思路可参考GeoIP 与 GeoSite 数据库更新指南。

进程条件依赖操作系统和客户端实现，不应作为唯一依据。进程名称可能因安装方式、辅助进程或应用更新而变化，同一应用也可能通过系统服务发起网络请求。桌面端可将进程规则用于补充精细分流，但仍应准备域名或地址规则作为基础。Android 的分应用代理在系统层选择哪些应用进入虚拟网络，它与内核路由是前后两道判断：前者决定是否进入，后者决定进入后走哪个出站。

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

示例中的 IPIfNonMatch 表示先按域名规则判断，域名未匹配时再解析地址用于地址规则。它可以提高地址规则覆盖率，但也会让内核 DNS 参与决策，因此必须与 DNS 章节中的服务器和查询策略一起设计。若设为始终按地址判断，域名请求会产生更多解析；若完全不解析，只有域名信息的连接无法命中地址集合。不存在适用于所有网络的固定值，应根据规则是否依赖 GeoIP、应用是否提供域名以及 DNS 路径来选择。

用日志验证规则，而不是凭页面结果推测

规则验证应检查目标、命中条件和最终出站三个信息。先清理浏览器 DNS 与连接缓存，关闭会复用连接的测试页面，再发起一次新的请求。日志若显示目标已经直接成为地址，应检查应用解析或嗅探；若目标域名正确但命中错误出站，应检查规则顺序和域名写法；若出站正确却连接失败，应转向协议参数、服务器状态与网络路径，不要继续改路由。

域名写法也有明确差异。完整域名只匹配一个主机名，域名后缀会覆盖其子域，关键词匹配范围最宽且最容易误伤。优先使用完整域名或维护良好的域名集合，只有目标命名稳定且无法枚举时才使用关键词。端口规则应注明协议，因为同一端口可能同时存在 TCP 与 UDP 行为。阻断 UDP 时还要考虑应用是否会自动回退到 TCP，表面上“仍能访问”不代表阻断规则没有生效。

修改路由后，应依次测试内网服务、明确直连目标、明确代理目标、被阻断目标和未匹配目标。内网访问异常通常是私有地址规则位置错误；所有目标都走同一路径通常是兜底规则提前；只有域名失败可能是 DNS 与路由形成循环；连接后无法打开网页可继续按十二项排查清单从本地设置、节点、路由和解析四层检查。

DNS 配置优化与解析路径

先画出查询从哪里发出

DNS 问题难以定位，通常是因为系统解析器、浏览器安全 DNS、客户端内核 DNS 和远端解析同时存在。应用可能把域名交给系统，也可能自行发出加密查询；系统代理模式下，部分应用仍直接使用系统 DNS；TUN 模式可以接管更广的查询，但仍可能遇到硬编码解析器或特殊协议。配置前应先确定测试应用使用哪条路径，再决定是否让内核接管，不能只看到客户端里填写了 DNS 地址就假定所有查询都会经过它。

解析路径至少包含三个决策：查询交给哪个服务器、查询流量通过哪个出站、返回结果用于路由还是仅用于连接。若 DNS 服务器地址本身需要经过代理，而建立代理连接又依赖同一个 DNS，就会形成启动循环。解决办法是为基础连接保留一个可直接访问的解析器，或者让服务器地址使用已经可解析的固定域名与独立路径。任何优化都应先保证启动链路闭合，再讨论缓存、并发或地址族偏好。

按域名范围选择解析器

不同域名可以使用不同 DNS 服务器，但分流依据应清晰。内部域名和局域网设备通常交给系统或局域网解析器，因为它们可能依赖搜索域、私有区域和本地地址；公共域名可以交给内核配置的解析器；需要与特定出站保持一致的域名，应让查询沿相同路径发出，减少解析结果与连接出口不一致。不要简单地把所有查询并发发送给多个服务器并接受最先返回者，这会让结果来源不稳定，增加排错难度。

配置中的 hosts 适合保存少量稳定映射，例如本地测试服务或需要固定别名的内部资源。它不是大规模域名规则数据库，也不应替代正常解析。映射变化频繁时，静态条目容易过期。若一个域名同时存在 IPv4 与 IPv6 记录，应确认系统网络是否具备对应地址族的可用路径；仅禁用某类返回值虽然能绕开表面故障，但可能掩盖系统路由或上游网络配置问题。

{
  "dns": {
    "hosts": {
      "router.home.arpa": "192.168.1.1"
    },
    "servers": [
      {
        "address": "localhost",
        "domains": [
          "domain:router.home.arpa",
          "domain:service.example.invalid"
        ]
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

示例只用于说明字段关系：本地域名优先交给本机解析器，其余查询使用后续服务器。实际部署时，应选择当前网络可达且用途明确的解析器。queryStrategy 控制返回地址族的范围，UseIP 允许查询可用地址；仅查询 IPv4 或 IPv6 应基于实际网络能力决定。客户端生成的配置可能使用不同字段形式，若图形界面已经提供 DNS 模式，应避免同时导入一段重复配置，否则后生成的字段可能覆盖前者。

缓存、浏览器与污染判断

修改 DNS 后立即重复访问同一页面，常常仍在使用旧缓存。缓存可能存在于浏览器、系统服务、内核和目标应用四处。验证时应新建连接、使用此前未查询的测试域名，或按系统方式刷新解析缓存。浏览器若启用了独立安全 DNS，需要暂时关闭或明确配置，使测试路径与客户端设计一致。否则浏览器正常而其他应用失败，只能说明两者使用了不同解析路径。

判断异常结果时，应比较“系统查询结果、内核查询结果、最终连接地址”三项，而不是只看一个命令输出。系统查询正常但内核失败，检查内核 DNS 的出站和路由；内核查询正常但应用仍失败，检查应用是否绕过代理或复用旧连接；结果地址正确但连接超时，问题已经离开 DNS 层，应转查路由、协议和服务器。解析耗时偶尔升高不一定需要更换服务器，先观察是否由网络切换、首次握手或缓存未命中造成。

DNS 与路由必须一起验证。使用 IPIfNonMatch 等策略时，路由判断可能主动触发解析；DNS 查询本身也会进入路由系统。如果 DNS 服务器域名又被一条依赖解析结果的规则匹配，就可能形成递归。为解析器设置明确出站、让基础服务器地址具备直接可达路径，并把相关规则放在通用规则之前，可以降低循环风险。配置稳定后再增加按域名分配解析器的细分规则。

TUN 模式的启用顺序与边界

TUN 与系统代理处理的对象不同

系统代理向遵循操作系统代理设置的应用提供代理地址，配置简单、回退清晰，但无法覆盖忽略系统代理的程序和部分 UDP 流量。TUN 模式创建虚拟网络接口，让更广范围的 IP 流量进入客户端，再由内核执行 DNS、路由和出站选择。它并不是“更强的开关”，而是改变系统数据路径的网络模式，因此需要额外处理路由表、DNS 接管、接口优先级和本地网络访问。

是否启用 TUN 应由应用需求决定。浏览器、常见桌面软件和开发工具若能正确使用系统代理，没有必要仅为配置复杂度而切换。需要处理不读取代理设置的应用、UDP 请求或统一分流时，再评估 TUN。Android 客户端通常通过系统虚拟网络能力接管流量，还可结合分应用选择；桌面端则可能需要系统权限创建接口并写入路由。不同平台的权限表现不同，但验证逻辑相同：确认接口创建、默认路径调整、DNS 进入预期通道，以及停止客户端后网络恢复。

按最小配置启用

启用前先关闭其他会创建虚拟网卡、修改默认路由或接管 DNS 的网络工具，避免两套路由同时竞争。保留一个已验证可用的服务器，暂时使用最小路由集，不启用 FakeDNS，也不要同时调整系统防火墙。启动 TUN 后先检查客户端日志是否成功创建接口，再测试本地网关、普通域名和一个明确走代理的目标。若第一步就无法访问本地网关，优先检查私有地址直连与路由排除，不要继续修改远端协议参数。

Windows 可在 PowerShell 中查看接口和路由优先级；macOS 可检查当前默认路由与 DNS 解析器；Linux 应同时查看路由表、策略路由和 DNS 服务状态。以下命令只读取状态，不修改系统配置。输出中应出现客户端创建的虚拟接口，但接口名称由客户端与系统决定，不应按固定名称编写自动判断。

# Windows PowerShell
Get-NetIPInterface | Sort-Object InterfaceMetric

# macOS
route -n get default
scutil --dns

# Linux
ip address
ip route
ip rule

处理局域网、回环与路由循环

TUN 最常见的故障是把不该接管的流量再次送回虚拟接口。代理服务器自身的连接必须排除在 TUN 路由之外，否则内核建立出站时又被系统送回入站，形成循环。局域网网段、回环地址、本机服务和必要的系统网络探测也应按需求直连。私有地址规则通常是基础，但企业网络可能使用更复杂的内部网段和域名，需要根据实际路由表补充，不能只依赖一份通用列表。

如果启用后客户端显示连接正常但所有应用都超时，先检查服务器地址是否被 TUN 重捕获；若互联网正常但局域网设备不可达，检查私有地址直连与本地接口路由；若只有 UDP 应用异常，检查内核出站是否支持对应流量、路由是否允许 UDP，以及系统防火墙是否拦截虚拟接口。停止 TUN 后仍无法联网时，确认客户端是否正常退出并恢复系统 DNS、默认路由和系统代理。

移动网络与无线网络切换会改变底层接口、地址和 DNS。TUN 客户端需要重新绑定当前网络，短暂中断属于路径重建过程；持续失败则应重启连接并查看是否仍引用旧接口。笔记本从休眠恢复后也可能出现相同情况。排错时记录故障发生在“首次启动、网络切换、休眠恢复还是长时间运行”中的哪一阶段，这比单纯描述“无法连接”更有价值。

性能与 MTU 的判断

TUN 增加了一层用户态处理，但性能问题不能直接归因于虚拟网卡。应先比较同一服务器、同一网络、同一路由规则下系统代理与 TUN 的表现，再观察 CPU、日志重试和特定站点行为。若小请求正常、大页面或文件传输停滞，可能涉及 MTU 或路径分片；若所有请求均匀变慢，更应检查 DNS、服务器路径与协议握手。不要在缺少对照测试时同时修改 MTU、并发和缓冲区。

MTU 应从客户端默认值开始。只有出现稳定可复现的“大包异常、小包正常”现象，且更换服务器与网络后仍存在，才逐步降低并测试。数值调整后要重新建立连接，确保旧连接没有继续复用。更完整的虚拟网卡原理、平台操作和冲突情形可参阅V2Ray TUN 模式详解；本章重点是将 TUN 放入整个配置链中，而不是将其作为独立开关处理。

FakeDNS 的工作方式与适用条件

FakeDNS 解决的是域名信息丢失

部分应用先在本地解析域名，再以目标地址建立连接。内核接收到流量时只看到地址，域名路由规则便无法直接匹配。FakeDNS 通过为域名返回一个专用地址池中的临时地址，记录域名与该地址的映射；连接到达内核后，再从映射中还原原始域名并执行域名路由。它的价值是保留路由所需的域名信息，而不是提供更快的公共解析服务。

FakeDNS 通常与 TUN 或能够接管 DNS 的入站配合。若应用的 DNS 查询没有进入内核，它不会获得专用地址，也就无法建立映射；若查询进入内核但后续连接绕过 TUN，系统会尝试直接访问专用地址并失败。因此，DNS 查询路径和连接路径必须同时被接管。启用前应先确认普通 TUN 与真实 DNS 工作正常，否则叠加 FakeDNS 只会增加变量。

地址池、映射与回退

专用地址池不能与真实局域网、企业网络或其他虚拟网络使用的网段重叠。重叠时，系统可能把真实内部服务误送给 FakeDNS，或把临时地址交给错误接口。地址池容量决定可同时保存的映射数量，但盲目扩大并无必要；容量不足通常表现为旧映射被回收，长期连接与缓存应用可能出现不一致。应优先保持合理缓存周期，并在客户端重启、网络切换后重新建立测试连接。

并非所有流量都适合 FakeDNS。局域网设备发现、内部域名、需要系统搜索域的服务和依赖真实地址判断的应用，应保留真实解析或设置绕过。对无法正确处理专用地址的应用，可以使用分应用排除，或让相应域名走普通 DNS。不要把兼容问题简单归为服务器故障：如果关闭 FakeDNS 后同一服务器立即恢复，而普通 TUN 始终正常，应检查域名映射、嗅探与地址池冲突。

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

该片段展示常见字段关系，具体客户端可能由界面生成对应配置。198.18.0.0/15 常用于基准测试网络，适合作为专用映射池，但仍要确认本地环境没有占用。配置后不应通过外部网络直接访问池中地址；这些地址只在本机的内核映射中有意义。如果日志显示请求到达该地址却没有还原域名，说明 DNS 查询与连接没有使用同一映射上下文，或映射已经失效。

与嗅探、路由和真实 DNS 的协作

嗅探可以从部分 TCP、TLS 或 HTTP 流量中恢复域名，FakeDNS 则从受控 DNS 映射恢复域名，两者解决的问题相近但来源不同。嗅探依赖流量中存在可识别信息，并非所有协议都适用；FakeDNS 依赖查询与连接都经过内核。可以按客户端默认策略协同使用，但要明确路由最终使用哪一个目标。若日志中的目标域名与应用请求不一致，应检查目标覆盖策略，避免嗅探结果错误替换原目标。

FakeDNS 返回临时地址，不意味着真实 DNS 完全不再需要。内核最终连接目标服务器时，仍可能需要获取真实地址；路由规则使用 GeoIP 时也可能需要真实解析结果。因此配置中通常同时存在 FakeDNS 与正常解析器，并按阶段承担不同任务。若正常解析器的出站设置错误，会出现域名已经成功还原、最终连接却仍失败的现象。日志中应分别观察映射命中和真实地址解析。

启用后的验证应分四步：首先确认应用查询得到专用地址；其次确认该连接进入 TUN；然后确认内核日志还原出原始域名；最后确认域名路由命中预期出站并完成真实连接。只看到第一步不能证明配置完成。若浏览器可用但某个应用失败，检查该应用是否缓存地址、使用独立 DNS 或绕过虚拟网络。完全关闭应用并清理其连接状态后再测试，避免旧映射干扰。

回退时应同时关闭 FakeDNS 服务器、地址池与依赖其目标覆盖的设置，并恢复普通 DNS。只关闭其中一个组件可能留下专用地址缓存，使系统短时间仍然尝试访问无效目标。回退后重启客户端和测试应用，确认解析结果恢复为真实地址。FakeDNS 适合有明确域名路由需求且普通嗅探覆盖不足的场景，不应作为所有配置的默认前提。

多订阅管理与更新策略

把订阅视为外部配置来源

多订阅管理的重点不是把更多服务器放进列表，而是控制外部配置变化。每个订阅都可能改变名称、协议参数、条目数量和可用范围，因此应有独立名称、更新节奏和停用状态。订阅地址只保存在客户端的订阅管理中，不要复制到路由备注、脚本输出或共享截图。若需要在多台设备使用，应分别导入，并根据设备用途建立本地分组，而不是假定桌面端与移动端需要完全相同的服务器集合。

建议为每个来源记录用途、客户端范围、上次成功更新时间和异常处理方式。这里的“更新时间”用于本地管理，不需要写进服务器名称。长期不用的订阅先停用自动更新，观察确认无依赖后再删除。直接删除可能同时移除当前服务器或打乱分组。v2rayN 更适合作为桌面多订阅管理中心，利用较大的列表界面检查差异；v2rayNG 与 v2flyNG 应保留移动端真正需要的来源，减少后台更新和手工选择负担。

错峰更新与变更审查

多个订阅不要在同一时刻批量更新。先更新低风险来源，检查新增、删除、重命名和协议变化，再继续下一个。若更新后当前服务器被替换，先选择同来源的确认项测试；若大量条目消失，不要立即重复更新或清空列表，应保留现状并查看客户端日志。重复操作可能覆盖仍可用于回退的信息。自动更新周期也不应过短，过于频繁会在网络切换或来源暂时异常时反复改变列表。

变更审查至少关注四项：条目数量是否出现异常跳变；显示名称是否仍能被过滤规则识别；当前选中服务器是否保留；协议和传输参数是否发生改变。名称变化只影响组织，参数变化则可能影响连接。若某个来源开始使用不同协议能力，应调整工作分组，而不是只修改显示名称。涉及订阅格式识别与转换边界时，可参考V2Ray 订阅格式全解析，避免把分享链接、编码列表和原生配置当作同一种结构处理。

去重、优先级与故障隔离

去重应基于连接身份，而不是单看名称。可比较协议、地址、端口、用户标识、传输方式和安全参数。完全相同但来自不同订阅的条目仍有来源价值：当一个来源更新失败时，另一来源可能继续维护。可以将重复项放入较低优先级分组，避免日常列表拥挤，同时保留回退能力。若客户端不支持复杂视图，至少在订阅名称中清楚区分来源。

优先级应服务于稳定性。固定用途的应用使用经过持续验证的服务器，不与临时测试条目混合；测试来源放入独立分组，并避免自动成为默认选择。多订阅自动选择只能在兼容的候选集合内进行。协议、传输和网络路径差异很大的条目不适合放入同一快速切换组，否则连接变化会被误判为 DNS、路由或应用问题。

故障隔离时，先停用自动更新和自动选择，固定一个已知服务器，再逐个检查来源。若所有来源都失败，问题更可能位于本地网络、系统接管或公共配置；若只有一个来源失败，集中检查该来源的解析、参数变化和条目状态。若同一来源在 v2rayN 正常、Android 客户端异常，应比较内核家族、传输支持、系统网络权限和移动网络限制，不要直接复制桌面端全部设置。

备份范围与恢复顺序

备份应覆盖订阅定义、手工服务器、自定义路由、DNS、出站和客户端偏好，但恢复时不要一次导入全部。先恢复订阅与一个服务器，确认基础连接；再恢复路由和 DNS；最后恢复 TUN、FakeDNS 与自定义出站。跨客户端迁移时，优先迁移通用连接参数和规则意图，不要假定界面导出的所有私有字段都能被另一客户端识别。

备份文件属于敏感配置，应只保存在受控位置，不应公开分享。需要展示问题时，删除订阅地址、服务器地址、用户标识与认证字段，只保留与结构相关的片段。日志同样可能包含目标域名和连接信息，提交排错材料前应先检查。恢复完成后重新建立变更记录，避免旧备份与当前订阅状态混用。

多订阅管理最终应达到三个结果：任一来源异常时不会影响全部配置；更新后能够快速看出变化；删除或停用来源时不会破坏路由与出站。实现这三点依赖稳定命名、分层分组、错峰更新和明确回退，而不是增加更多自动化开关。来源越多，越应减少隐式行为。

自定义出站、链式路径与统一排错

用稳定标签连接路由与出站

自定义出站是路由规则的执行目标。常见基础出站包括代理、直连和阻断，复杂配置还可能增加指定服务器、DNS 专用路径或链式前置路径。每个出站都应使用稳定、语义明确的标签，例如 proxy、direct、block 和 dns-out。路由规则引用的是标签，不是界面中的临时显示名称。修改标签前要检查所有路由、DNS 与链式关系，避免出现配置语法正确但引用对象不存在的情况。

出站数量应保持最小。若两个出站只有名称不同、实际协议和路径完全一致，应合并并由路由规则区分目标。只有当连接参数、前置路径、地址族或网络策略确实不同，才建立独立出站。大量近似出站会增加日志阅读难度，也容易在订阅更新后指向过期服务器。图形客户端自动生成的主代理出站可能随当前服务器变化，自定义规则应确认引用的是稳定入口，而不是某个会被替换的内部标签。

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

示例展示直连与阻断出站的基本结构。实际客户端通常会自动生成代理出站，手工片段不应覆盖客户端维护的服务器配置。freedom 出站的域名策略决定直连时如何解析目标，应与全局 DNS 和系统地址族保持一致。blackhole 用于明确拒绝匹配流量；阻断后应用可能显示超时或连接失败，这是预期结果。判断规则是否生效应查看出站标签，而不是依赖应用提示文字。

链式路径的前置条件

链式出站让一个连接先经过前置出站，再建立后续出站。它适用于路径要求明确的场景，但会增加握手层级、故障点和日志复杂度。配置前应分别确认前置服务器与最终服务器单独可用，并明确哪一段负责 DNS 解析。若前置连接本身依赖最终路径，就会形成循环；若两个阶段都进行不一致的域名解析，最终目标地址可能与预期不同。

链式路径不是提升稳定性的通用办法。每增加一段，就增加一次连接建立、超时和参数匹配。应先用单出站验证应用、路由和 DNS，再加入前置路径。测试时分别记录第一段是否握手成功、第二段是否发起、最终目标是否建立。日志只显示“连接失败”时，从最前一段开始检查，不能直接把错误归因于最终服务器。

避免使用动态自动选择作为链式前置，除非所有候选项都验证过相同协议能力和网络行为。前置路径频繁变化会让长连接中断，也会改变 DNS 与出口关系。更稳妥的做法是固定前置出站，完成一段时间观察后再评估自动策略。链式配置发生问题时，第一回退动作是取消链式关系并恢复单出站，而不是继续增加路由例外。

DNS 专用出站与流量隔离

为 DNS 建立专用出站可以让查询路径更明确，但必须避免自举循环。专用出站所需的服务器地址应能通过基础网络解析或直接访问，路由规则也要保证 DNS 流量不会再次回到需要该 DNS 才能建立的代理。配置完成后，应在日志中区分 DNS 查询和普通连接，确认解析流量使用 dns-out，业务流量仍按原路由选择。

流量隔离还可用于将特定协议或端口送到独立出站，但条件必须能够稳定识别。端口不等于应用，进程名也不等于全部连接；优先使用目标域名、地址集合和明确的网络类型。若需要多条件组合，先在测试规则中只写一个条件，确认命中后再增加限制。一次写入完整复杂条件，未命中时很难判断是哪个字段不符合。

统一排错顺序

复杂配置出现故障时，应执行统一回退：关闭自动服务器选择，固定一个已知服务器；取消链式出站；关闭 FakeDNS；保留普通 DNS；从 TUN 退回系统代理；将路由恢复为私有地址直连加默认代理。若此时仍失败，问题大概率在服务器参数、本地网络或客户端启动层。若基线恢复，再按原顺序逐项重新加入，出现故障的第一步就是重点对象。

日志阅读按时间线进行。先找配置加载与语法错误，再看入站是否接收连接，然后看 DNS 是否返回结果、路由命中哪个标签、对应出站是否开始握手。错误发生在哪一步，就只检查该步及其直接依赖。出站握手已经成功但页面内容异常，应继续检查应用协议、地址族或目标服务，不要返回修改订阅分组。日志级别可以临时提高，但问题确认后应恢复正常级别，避免长期产生大量无关记录。

排错材料应包含客户端名称、操作系统、使用系统代理还是 TUN、问题发生前的单项变更、关键日志阶段和回退结果。不要直接提交完整订阅或完整配置。对照实验比大量截图更有效：同一服务器在基线配置是否正常，同一配置更换网络是否正常，关闭新增模块是否恢复。三个结果通常足以把范围缩小到本地系统、内核配置或服务器路径。

完成配置后，应保存一份结构说明，列出订阅来源、工作分组、路由顺序、DNS 路径、TUN 排除项、FakeDNS 地址池和自定义出站依赖。后续更新客户端、内核数据或订阅时，按说明逐项复核。若需要重新梳理客户端选择，可阅读v2rayN、v2rayNG、v2flyNG 横向对比；基础操作仍以快速上手为准，本页用于长期维护与系统排错。