v2rayN 进阶配置手册：订阅、路由、DNS 与 TUN

配置模型与可回退的变更方法

先区分四个配置层级

v2rayN 的界面设置最终会组合成内核运行配置。排查问题前，应先区分服务器、订阅、客户端行为和内核配置四个层级。服务器记录包含地址、端口、用户标识、传输方式与安全参数；订阅负责批量提供和更新服务器记录；客户端行为包括系统代理、托盘操作、自动更新和界面过滤；内核配置则处理入站监听、DNS、路由与出站。一个节点可以通过延迟测试，并不代表系统代理、DNS 或路由一定正确，因为这些环节位于节点连接之外。

图形界面中的“当前服务器”通常只是默认代理出站的来源。路由规则可能把一部分请求交给直连或阻断出站，TUN 也可能接管原本不读取系统代理的程序。因此，判断某项设置是否生效时，不能只观察节点是否变色或托盘图标是否变化。应同时确认客户端运行状态、代理模式、目标程序的连接方式以及规则命中结果。

建立最小可用基线

进行进阶调整前，先建立一套可重复验证的基线：保留一个已知能够连接的服务器，将路由恢复到简单规则，暂时关闭 TUN 与 FakeDNS，只启用系统代理，然后用浏览器访问普通 HTTPS 页面。该状态能够工作后，再按“订阅过滤、路由、DNS、TUN、FakeDNS”的顺序逐层增加配置。一次只改变一个层级，变更后立即复测，能够显著缩短定位范围。

建议为每次试验记录四项信息：修改了什么、修改前的值、预期结果、实际结果。记录不需要复杂工具，一段本地文本即可。遇到无法连接时，先撤销最后一次变更，而不是同时切换节点、修改 DNS、重装客户端和清理系统网络。多项动作一起执行会破坏可复现性，也无法确认真正原因。

理解生成配置与手写配置的边界

v2rayN 适合通过界面维护常见参数，界面生成的配置也更容易随服务器切换自动更新。手写 JSON 适用于需要额外出站、特殊 DNS 策略或细粒度路由的场景，但必须考虑客户端重新生成配置时是否会覆盖修改。若某项能力能够通过路由设置、DNS 设置或自定义配置入口完成，应优先使用对应入口，不要直接改动临时运行文件。

配置片段必须保持 JSON 语法完整：属性名与字符串使用半角双引号，数组项目之间需要逗号，最后一项不能多写逗号。域名、路径和正则表达式还可能涉及反斜杠转义。保存后若内核立即退出，优先查看日志中最早出现的解析错误；后续连接失败往往只是前一项解析错误的连锁结果。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

按现象确定检查入口

浏览器可用而其他程序不可用，先检查程序是否读取系统代理，再考虑 TUN；域名打不开但直接访问目标地址有响应，先检查 DNS；只有部分网站异常，检查路由顺序和域名规则；订阅更新后节点消失，检查过滤表达式与分组；启用 FakeDNS 后局域网名称异常，检查排除范围与 DNS 接管边界。按照现象选择入口，比从头重置所有设置更可靠。

完成一组稳定配置后，应保留配置导出或界面截图，并记录使用的模式。配置备份只保存本地设置，不等同于订阅服务本身；订阅地址失效时，备份无法生成新的服务器记录。对订阅地址、服务器凭据和自定义配置文件应按敏感信息处理，不放入公开文档，也不要把运行日志原样发送到公开区域。

订阅分组与服务器过滤

分组解决的是管理问题

订阅分组用于区分服务器来源、用途和更新节奏，而不是改变协议本身。导入多条订阅后，如果全部服务器混在一个列表中，节点名称重复、地区标记不一致和倍率说明会使筛选结果难以判断。较稳妥的做法是按来源建立分组，每条订阅设置明确备注，再通过过滤条件形成临时视图。分组名称应描述来源或用途，不要依赖容易变化的节点数量。

订阅地址应通过客户端的订阅分组设置保存。新增后先手动执行一次更新，确认服务器记录能够解析，再设置自动更新间隔。若首次更新失败，应先检查地址是否完整、复制时是否带入空格、网络是否能够访问订阅端点。不要在首次失败后连续创建多条相同分组，否则后续更新会产生重复服务器，增加清理成本。

备注、分组名与服务器名各有用途

分组备注由用户维护，适合标记来源；分组名用于列表归类；服务器名通常由订阅提供方生成，更新时可能发生变化。需要长期稳定筛选时，不应只依赖完整服务器名，而应选择相对稳定的关键词组合，例如地区缩写、协议名或用途标签。若订阅方改变命名规则，过滤结果也会改变，因此每次大规模更新后都应确认筛选视图仍包含预期服务器。

服务器过滤通常分为包含与排除两类。包含条件缩小显示范围，例如只显示名称中带有某个地区标记的记录；排除条件用于移除维护、剩余流量、到期提示等非服务器条目。过滤只影响视图时，不会删除原始记录；删除操作则会直接移除本地服务器。执行批量删除前，要先确认当前操作对象是过滤结果还是整个分组。

过滤表达式从简单条件开始

如果客户端入口支持正则表达式，应先使用普通关键词验证范围，再逐步增加组合条件。正则中的圆括号、方括号、点号和加号都有特殊含义，直接复制服务器名称可能改变匹配结果。需要匹配多个普通关键词时，可以使用竖线表达“任意一个”，例如 HK|SG|JP。需要排除“剩余流量”“套餐到期”等提示项时，先单独测试每个关键词，再合并条件。

包含示例：
HK|SG|JP

排除示例：
剩余流量|套餐到期|官网|维护

协议筛选示例：
VMess|VLESS|Trojan

过滤条件不应承担自动选路职责。它适合缩小可见列表，但不会持续判断节点质量，也不会替代真连接延迟测试。筛选后应在目标集合内执行真连接延迟测试，排除握手失败的记录，再结合实际下载或网页访问选择服务器。ICMP Ping、真连接延迟和下载测速的差异可参考延迟测试说明。

更新、覆盖和移除策略

订阅更新通常按分组刷新记录。若更新后出现大量重复项，先确认是否导入了相同地址的多个分组，再检查客户端的更新行为是覆盖旧记录还是保留手工修改。对订阅生成的服务器直接改名或改参数，可能在下次更新时被覆盖。需要长期保留的手工服务器应放在独立分组，不与自动更新订阅混合。

移除订阅时，需要区分“删除订阅配置”和“删除该订阅已生成的服务器”。只删除订阅地址可能留下旧服务器，这些记录不会继续获得参数更新；只删除服务器而保留订阅，下次更新又会重新生成。停用某个来源时，先停止自动更新，再删除对应服务器，最后移除订阅分组。操作完成后检查当前活动服务器，避免它仍指向已经删除的记录。

在 v2rayNG 或 v2flyNG 中，订阅管理入口与桌面端布局不同，但处理顺序相同：为来源设置备注，单独更新，确认解析结果，再选择活动配置。移动网络切换频繁时，不宜设置过短的自动更新周期；更新失败时保留已有服务器，先判断是网络临时不可达还是订阅地址本身发生变化。

路由规则实战：匹配条件、顺序与出站

规则按照顺序决定出站

路由的核心任务是把连接交给指定出站。常见出站包括代理、直连和阻断，自定义配置还可以增加其他代理链路。规则由匹配条件和目标出站组成：当域名、地址、端口、网络类型或入站标签满足条件时，将连接交给对应的 outboundTag。多数实现按规则从上到下匹配，较具体的规则应放在较通用的规则之前，否则前面的宽泛条件会提前接管请求。

一套容易维护的基础顺序是：先处理明确需要阻断的目标，再处理局域网与私有地址直连，然后放置业务上明确的域名或地址规则，最后设置兜底行为。兜底可以由默认出站承担，不一定需要写成覆盖全部目标的规则。若在规则顶部使用过宽的域名匹配，后续分流条目将没有机会生效。

域名匹配与地址匹配不是同一步

域名规则在连接仍保留域名信息时最清晰，例如 domain:example.com 可匹配该域名及其子域范围，full:example.com 用于精确主机名，regexp: 则适合确实需要模式匹配的场景。正则规则解析成本和维护成本更高，普通域名能够表达时不应优先使用正则。站点依赖多个静态资源域名时，应逐项确认，不要根据主页域名推断所有请求都会命中同一规则。

地址规则在目标已经解析为 IP 时使用，可匹配单个地址、CIDR 网段或内置分类。geoip:private 常用于私有地址直连，避免局域网打印机、存储设备和路由管理页面被送入代理。域名解析结果可能随时间与地区变化，把动态站点的当前地址写成永久规则通常不稳定；能用域名表达的业务条件，应优先使用域名规则。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:telemetry.example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:docs.example.com",
          "full:api.example.net"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategy 如何改变匹配过程

AsIs 表示优先按请求中的原始域名处理，不主动为路由匹配解析地址；IPIfNonMatch 表示域名规则未匹配时，再解析地址并尝试地址规则；IPOnDemand 会在规则判断需要地址时更早触发解析。选择策略时要结合 DNS 配置。若路由依赖地址分类，而策略始终不解析地址，对应规则可能不会命中；若过早解析，又可能增加 DNS 查询或改变域名分流链路。

一般场景可以从 AsIs 开始，只有明确需要基于解析地址继续判断时再使用 IPIfNonMatch。修改后重点观察同一域名是否产生不同 DNS 请求、是否命中预期出站。不要把策略名称理解为“速度档位”，它改变的是匹配阶段和解析时机，不保证某个值在所有网络环境中更快。

规则验证应观察完整请求

验证路由不能只测试首页是否打开。一个页面可能同时请求主站、图片、接口和身份认证域名，不同请求可能走不同出站。先用一个具体目标建立单条规则，重启内核后查看日志中的目标、命中结果与出站标签。确认单条规则有效后再扩展域名范围。若日志中只有地址没有域名，应回到 DNS 与嗅探设置检查域名信息是否仍可获得。

规则不生效时依次检查四项：规则是否位于正确顺序，匹配语法是否符合内核格式，目标出站标签是否存在，实际连接是否由当前内核接管。浏览器自带的安全 DNS、应用内置代理或已建立的长连接都可能绕开刚刚修改的链路。测试前关闭并重新打开目标程序，必要时清理其连接缓存，而不是只刷新页面。

路由规则应保持可读。几十条零散域名比少量按业务归类的规则更难审查，也更容易发生前后覆盖。完成配置后，从顶部逐条回答“匹配什么、交给哪个出站、为什么必须位于这里”。无法明确回答的条目通常需要拆分、改名或移除。

DNS 配置优化与解析链路排查

先画清楚谁在发起查询

DNS 异常经常被误判为节点失效。实际链路可能包含系统解析器、浏览器安全 DNS、v2rayN 内核 DNS、TUN DNS 接管以及远端解析。不同程序若走不同解析入口，同一域名可能获得不同结果。优化前先确定目标程序是否由系统解析、查询是否进入内核、内核向哪台服务器发送请求，以及解析结果如何参与路由。

仅启用系统代理时，浏览器可能自行解析域名，也可能把域名交给代理入口，具体取决于代理类型和程序实现。启用 TUN 后，系统 DNS 请求通常更容易被统一接管，但仍需正确设置 DNS 地址、路由与排除项。浏览器单独启用安全 DNS 时，其查询可能作为普通 HTTPS 流量发送，表面上看不到传统的 53 端口请求。

内核 DNS 的服务器与查询规则

内核 DNS 配置可以定义多个服务器，并按域名范围选择。普通 UDP DNS 配置简单，但请求路径取决于网络与路由；基于 HTTPS 的 DNS 通过 HTTPS 连接查询，需要先解决服务器域名的初始解析问题；使用固定地址可以减少启动依赖，但地址变化时需要维护。选择方式时应考虑可达性和依赖链，不应只按名称判断优劣。

DNS 服务器也可以带有域名过滤条件。这样做的目的通常是让特定域名走指定解析器，而不是把所有查询随机分配给多个服务器。若多个服务器的域名范围互相重叠，应明确优先关系。默认服务器负责处理没有特殊要求的域名，专用服务器只覆盖必要范围，配置会更容易验证。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": ["domain:service.example"]
      },
      "1.1.1.1",
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

示例中的域名仅用于展示结构，实际配置必须换成可访问的解析服务。hosts 用于少量固定映射，适合本地设备或测试环境，不适合维护大量公网域名。错误的固定映射会绕过正常更新，因此设置后要记录用途。localhost 会回到系统解析器，若系统解析器又把请求交回内核，可能形成循环，使用前必须确认链路方向。

查询策略与地址族

queryStrategy 控制返回地址类型。UseIP 允许按环境获取可用地址，UseIPv4 只请求 IPv4，UseIPv6 只请求 IPv6。只有在网络确实具备对应连接能力时，返回的地址才有意义。系统获得 IPv6 地址并不自动说明出站链路能够稳定访问所有 IPv6 目标；若表现为部分站点等待后回退，可以临时限制到 IPv4 验证是否与地址族有关。

地址族问题应通过对照测试确认，而不是永久关闭某一类地址作为通用做法。分别记录解析结果、连接目标和失败阶段。如果 DNS 能返回地址但 TCP 或 UDP 建连失败，问题位于解析之后；如果只有某个解析器超时，则检查该解析器的访问路径。日志中的“解析失败”和“连接拒绝”代表不同阶段，应分开处理。

缓存清理只用于验证

修改 DNS 后，系统、浏览器和内核都可能保留旧结果。Windows 可在终端执行 ipconfig /flushdns 清理系统缓存，但该命令不会清除浏览器自身缓存，也不会终止已有连接。更可靠的测试流程是保存配置、重启内核、关闭目标程序、清理必要缓存，再重新发起请求。频繁清理缓存不能修复错误配置，只适合确认旧结果是否仍在影响测试。

ipconfig /flushdns

nslookup example.com

nslookup example.com 1.1.1.1

nslookup 适合比较系统默认解析器与指定解析器返回结果，但它不一定经过应用实际使用的内核 DNS 链路。因此命令结果正常而浏览器仍失败时，应继续检查浏览器和代理入口。若启用了 TUN 或 FakeDNS，普通查询工具看到的结果还可能是接管后的映射地址，需要结合对应章节理解，不能按传统 DNS 结果单独判断。

v2rayN TUN 模式：接管范围与系统差异

TUN 解决哪些程序不读取代理的问题

系统代理依赖应用主动读取代理设置。浏览器和部分桌面程序通常支持这种方式，但一些游戏启动器、命令行工具、后台服务或使用自定义网络栈的程序可能直接连接。TUN 模式通过虚拟网络接口接管系统流量，使这些程序的连接也能进入内核。它改变的是流量入口，不是服务器协议，也不会让原本失效的节点恢复连接。

是否启用 TUN 应由应用需求决定。仅使用能够正确读取系统代理的程序时，系统代理配置更简单，排错范围也更小。只有明确发现某个程序不经过代理入口，或需要统一处理 TCP、UDP 与 DNS 时，再启用 TUN。将 TUN 作为默认排错动作，容易把路由、权限、虚拟接口和 DNS 问题同时引入。

启用前确认权限与冲突项

TUN 需要创建或控制虚拟网络接口，并调整路由。Windows 环境中可能需要提升权限；macOS 与 Linux 也需要系统允许相应网络操作。若客户端提示接口创建失败，先查看权限和驱动状态，不要反复切换节点。企业网络管理软件、其他虚拟网络工具和已运行的同类代理程序可能同时修改路由，测试时应只保留一个接管者。

启用前记录系统默认网关和 DNS，关闭其他网络接管工具，然后启动 v2rayN 的 TUN 模式。成功后先测试一个普通网页，再测试原先不读取系统代理的程序。若所有网络立即中断，应先关闭 TUN 恢复基础连接，再检查虚拟接口是否创建、默认路由是否改变、DNS 是否指向预期入口。不要在断网状态下继续叠加 FakeDNS 和复杂路由。

严格路由、自动路由与 MTU

自动路由用于把需要接管的流量导向 TUN 接口；严格路由通常会进一步限制可能绕过该接口的路径。具体选项名称可能随构建变化，但判断原则相同：先使用默认自动路由验证基本接管，再根据泄漏路径或局域网需求调整严格程度。严格路由启用后，如果局域网资源不可访问，应检查私有网段是否保留直连，而不是直接增加全局代理规则。

MTU 决定虚拟接口可承载的数据包大小。值过大时，某些链路可能出现网页部分加载、上传卡住或特定连接超时；值过小则增加分片和额外开销。遇到“能连接但大请求失败”时，可以在记录原值后分档降低 MTU 做对照。不要仅凭单次测速判断，至少测试小网页、较大文件传输和需要持续连接的应用。

排除局域网与客户端自身流量

TUN 路由通常需要让私有网段保持直连，否则打印机、网关管理页面和局域网服务可能被错误送入代理。常见私有地址范围可通过 geoip:private 规则统一处理。若本地网络使用了非典型地址范围，还需按实际网段补充。域名形式的局域网服务同时依赖本地 DNS，只有地址直连而 DNS 被远端解析时，名称仍可能无法使用。

客户端自身到代理服务器的连接也必须避免再次进入同一代理出站，否则会产生流量回环。成熟的默认配置通常会处理这一点，自定义路由或自定义出站时仍要确认服务器地址采用直连路径。表现为内核启动后不断重连、日志重复出现同一服务器目标时，应检查是否发生自代理循环。

关闭 TUN 后的恢复检查

正常关闭客户端时，虚拟接口与临时路由应随之撤销。若异常退出后网络仍不可用，先重新打开客户端并正常关闭 TUN，再检查系统默认路由和 DNS 是否恢复。重启系统可以清理部分临时状态，但不应替代原因定位。反复出现残留时，应检查多个网络工具是否同时管理接口，并从日志中确认退出阶段是否报错。

移动端的 v2rayNG 与 v2flyNG 通过系统提供的网络接管接口工作，应用排除、后台限制和省电策略会直接影响持续连接。桌面端的 TUN 设置不能原样套用到 Android，但路由和 DNS 的分析方法一致：先确认流量是否进入客户端，再确认规则命中与出站，最后检查系统是否在后台终止连接。

FakeDNS 的工作方式、适用场景与边界

FakeDNS 保存域名与连接的对应关系

FakeDNS 在接管 DNS 查询后，为域名返回一个保留地址池中的临时地址，并记录该地址与原始域名的映射。当应用连接这个临时地址时，内核根据映射恢复域名，再执行域名路由和远端连接。它的主要价值是为那些先在本地解析、随后只携带地址发起连接的程序保留域名信息，使域名规则仍有机会生效。

FakeDNS 返回的地址不是目标服务器的真实公网地址，因此不能脱离内核单独使用。查询与后续连接必须进入同一个接管链路，映射才成立。如果 DNS 查询经过 FakeDNS，但连接绕过 TUN，应用会尝试直接访问临时地址并失败；反过来，连接进入 TUN而查询由其他解析器完成，也无法利用映射恢复域名。

适合启用的场景

当 TUN 已稳定工作，但日志中大量连接只显示地址、域名路由难以命中时，可以考虑 FakeDNS。它也适用于希望减少本地真实解析、让域名在代理链路中继续处理的场景。启用前必须先确认普通 TUN、DNS 接管和基础路由可用，否则新增的地址池与映射机制会让故障现象更难解释。

普通系统代理场景通常不必为了“更快”单独启用 FakeDNS。很多代理入口本身可以接收域名，域名信息没有丢失。FakeDNS 也不是缓存加速器，其核心作用是映射和还原。是否改善连接取决于原来的域名处理问题，不能把它视为所有环境都应启用的性能选项。

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ]
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

示例展示常见结构，实际支持方式取决于客户端所用内核与配置入口。198.18.0.0/15 是常用于基准测试的保留网段，可作为映射池，但仍应确认本地网络、其他虚拟网络或企业路由没有占用相同范围。地址池发生冲突时，可能表现为特定内网服务无法连接或路由把真实目标误当成 FakeDNS 地址。

局域网、分流与排除

局域网名称、打印机发现和路由器内部域名通常依赖本地 DNS，不适合统一交给 FakeDNS。应让私有域名和本地域名后缀走本地解析，并让私有地址直连。若局域网使用自定义后缀，需要显式加入排除范围。只排除私有地址不一定足够，因为名称解析发生在获得地址之前。

FakeDNS 与域名分流配合时，规则应在域名被恢复后判断。若连接日志始终只显示映射地址，说明还原链路没有完成，应检查 DNS 查询和连接是否由同一实例处理、地址池是否一致、TUN 是否接管目标应用。不要通过添加映射地址段的代理规则掩盖问题，这会让所有临时地址进入代理，却仍然失去原始域名的规则价值。

缓存生命周期与测试方法

FakeDNS 映射有容量和生命周期。应用长期保持旧映射地址，而内核已经重启或映射记录被替换时，旧连接可能失败。测试配置变更时应重启目标程序，必要时清理其 DNS 缓存，让查询和连接在同一轮运行中重新建立。只重启内核而保留应用的旧连接，容易得到不一致结果。

验证时可以选择一个具有明确域名规则的测试目标。先在未启用 FakeDNS 时记录日志中的目标形式，再启用后重新发起全新连接，确认 DNS 返回映射地址、内核恢复域名、规则命中预期出站三个阶段都出现。任何一个阶段缺失，都应在该阶段修复，而不是继续增加规则。

关闭 FakeDNS 后，应同时恢复对应 DNS 服务器配置，并让应用重新解析域名。仅移除地址池而保留 fakedns 解析入口会导致配置不完整。若需要长期在启用与关闭之间切换，建议保存两套完整配置，而不是每次手动修改多个分散选项。

多订阅管理、更新节奏与冲突处理

每个来源保持独立生命周期

多订阅管理的目标不是把更多服务器堆入同一列表，而是让不同来源能够独立更新、停用和审查。每条订阅应使用唯一备注与分组，不要把两个地址配置成相同名称。这样在某一来源更新失败、节点命名变化或需要暂停时，可以只处理对应分组，不影响其他已验证的服务器。

建议把手工服务器单独放在“本地维护”分组。订阅更新通常以远端内容为准，直接修改订阅生成的服务器可能在下一次刷新时被覆盖。需要临时调整某个参数时，先复制服务器到手工分组，再进行修改，并在名称中标记用途。原始订阅记录保留不动，便于和远端参数对照。

错开更新而不是频繁轮询

自动更新间隔应根据订阅变化频率设置。过短间隔会增加无效请求，也可能在网络切换时连续产生失败记录。多个订阅不必在同一时刻更新；先手动确认每个来源可独立更新，再启用合理周期。笔记本从休眠恢复、网络刚切换或代理内核尚未连接时，首次自动更新可能失败，应等待网络稳定后手动重试。

更新订阅时，订阅请求本身走直连还是代理取决于客户端设置与当前网络。若一个订阅只能通过当前代理访问，就形成了对现有可用节点的依赖。此时至少保留一个已验证且不会在更新前被清理的服务器。不要在获取新内容之前先删除全部旧记录，否则一次临时更新失败就会失去恢复路径。

处理同名服务器与重复内容

不同来源可能使用相同服务器名称，甚至提供参数相同的记录。名称相同不代表配置相同，不能仅按显示文本批量删除。应结合分组、地址、端口、协议和传输参数判断。若客户端支持按分组查看，先限制在一个来源内执行操作。跨分组去重前，先确认重复记录是否承担备用来源作用。

同一订阅被重复导入时，最明显的现象是每次更新都产生两批相似记录。处理前暂停相关分组的自动更新，确认哪条订阅配置需要保留，然后删除多余分组及其生成的服务器。完成后重新更新保留分组，并检查当前活动服务器是否仍存在。直接在总列表中逐条删除无法解决重复订阅的根因。

服务器选择应与分组管理分离

分组用于来源管理，延迟测试用于判断连接阶段，实际使用还要考虑带宽、稳定性和目标服务。不要因为某个分组最近更新，就默认其中所有服务器都可用。每次更新后先执行真连接延迟测试，排除无法完成代理握手的记录，再对少量候选进行实际访问。具体选择思路可参考节点选择说明。

自动选择功能如果依赖定期测试，应理解测试目标、超时和切换条件。测试地址不可达会让全部服务器被错误判断，超时过短会排除高延迟但可用的线路，切换过于频繁则会中断已有连接。先手动验证测试目标能够通过多个服务器访问，再考虑自动化。需要持续会话的应用通常更看重稳定，而不是每次选择最低的单次延迟。

订阅迁移与本地记录

更换设备时，应分别处理订阅地址、手工服务器、路由规则和 DNS 设置。只迁移订阅可以重新生成远端服务器，但不会自动带回本地自定义规则；只复制运行配置又可能包含临时生成内容，后续难以更新。迁移后按来源逐条更新，确认分组与服务器数量合理，再导入自定义规则。

订阅地址和服务器凭据都属于敏感配置。用于排错的截图应隐藏完整地址、用户标识和令牌。日志提交前也要检查请求参数与服务器信息。公开示例使用 https://example.com/sub?token=xxxx 这类明显假值，不应把真实订阅内容写入脚本、网页或共享笔记。

当多订阅体系已经稳定，日常维护只需要检查失败更新、异常重复和长期不可用记录。不要为了列表整齐频繁重建全部分组。保留清晰的来源边界、可回退的活动服务器和少量说明，比追求完全自动化更容易长期维护。

自定义出站、链式连接与完整诊断

出站标签是路由与连接方式的接口

内核通过出站定义连接如何离开本机。常见的 proxy、direct 和 block 分别表示使用当前代理服务器、直接连接和阻断。自定义出站可以增加本地 SOCKS 服务、特定直连参数或其他受支持协议，再由路由规则通过标签选择。标签必须唯一，规则中的 outboundTag 必须与出站的 tag 完全一致。

增加出站前先明确用途：是让某类请求交给本机另一项服务，还是为特定目标设置独立连接路径。没有对应路由规则的自定义出站不会自动接管流量；标签拼写错误时，内核可能拒绝加载配置或在请求阶段报错。名称应使用稳定、可读的英文短词，避免用服务器名称作为标签，因为服务器名称可能随订阅更新变化。

{
  "outbounds": [
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

示例把特定流量交给本机 127.0.0.1:1081 的 SOCKS 服务。使用前必须确认该端口确实有服务监听，并且不会再把流量转回当前 v2rayN 入站。两个本地服务互相指向会形成循环，表现为连接不断建立又立即失败。自定义端口也不要与 v2rayN 已使用的本地 HTTP、SOCKS 或 API 端口冲突。

链式连接需要明确每一跳

链式连接会增加故障点和握手成本，只应在明确需要时配置。每一跳都应能够单独验证：第一跳从本机到中间出站可达，中间出站能够访问下一目标，DNS 解析发生在预期位置。若链路中的任意一跳依赖前一跳提供的 DNS 或路由，应记录依赖关系，避免启动阶段互相等待。

测试链式连接时先用简单目标，不要同时启用复杂域名规则。日志应能显示请求进入哪个入站、匹配哪条规则、选择哪个出站以及在哪一阶段失败。连接超时表示的范围较广，可能是端口未监听、路由不可达或后续目标无响应；认证失败则优先检查对应出站的凭据和协议参数。不要通过延长所有超时来掩盖确定性的配置错误。

按层次读取日志

完整诊断可以分为六层：客户端进程是否启动，内核配置是否解析，入站端口或 TUN 是否接管请求，DNS 是否得到可用结果，路由是否选择预期出站，出站是否完成连接。日志中最早出现的错误通常最接近根因。内核配置解析失败时，后面的“代理不可用”没有独立诊断价值；DNS 已失败时，也不应先调整服务器测速参数。

日志级别应在排错期间临时提高，问题确认后恢复常规级别。详细日志可能包含目标域名、服务器地址和本地路径，分享前需要清理敏感内容。截取日志时保留错误前后的时间段和操作步骤，不要只复制最后一行。一次明确的复现过程比大量无关日志更容易定位。

建立可复现的诊断流程

遇到“V2Ray 无法连接”时，先记录发生时间、当前服务器、代理模式、是否启用 TUN、是否启用 FakeDNS以及受影响程序。然后选一个最小测试目标，关闭与问题无关的自定义规则，重新发起连接。若基础连接恢复，再按原顺序逐项启用设置，直到错误再次出现。该方法能够把复杂问题收敛到单个变更。

如果所有服务器同时失败，应优先检查本机网络、订阅是否刚更新、系统时间、DNS 与客户端运行状态，而不是逐个修改服务器参数。只有某个服务器失败时，再比较同分组其他记录和该服务器的协议参数。只有某个应用失败时，先确认应用是否进入当前代理入口。更多短问题可转到常见问题页逐项核对。

长期维护与升级检查

客户端和内核更新后，先用原有基础配置启动，再检查自定义字段是否仍被支持。不要在更新客户端的同时重构全部路由与 DNS。若配置无法加载，查看字段弃用或格式变化相关日志，把问题缩小到具体片段。下载与客户端选择统一从本站下载页进入，桌面平台优先使用 v2rayN，Android 可根据内核需求选择 v2rayNG 或 v2flyNG。

每隔一段时间审查订阅分组、过滤条件、路由条目、DNS 专用规则和自定义出站。删除已经无法说明用途的临时规则，确认局域网排除仍与当前网络一致，并检查自动更新是否持续成功。进阶配置的目标不是增加选项数量，而是让每一层行为都可解释、可验证、可回退。