V2Ray 高级配置手册

为什么需要配置基线

v2rayN 的实际连接结果由多层设置共同决定：订阅提供服务器信息，客户端负责选择活动服务器，路由决定流量送往哪个出站，DNS 决定域名如何解析，系统代理或 TUN 则决定哪些应用流量能够进入内核。任何一层发生变化，都可能表现为“网页打不开”“只有部分程序生效”或“切换服务器后结果不同”。如果一次同时修改路由、DNS 和接管方式，出现问题后很难判断是哪一层引起。

建议先建立一份最小可用基线：只保留一个确认能连接的订阅分组，选中一台配置完整的服务器，路由使用客户端内置的基础模式，DNS 保持默认，接管方式先用系统代理。随后访问日常使用的普通网站，并观察 v2rayN 日志是否出现连接建立、域名解析和出站选择记录。这里不需要追求复杂效果，只要确认客户端、内核、服务器与本机网络能够形成完整链路。

基线应记录的是配置关系，而不是某次测试得到的瞬时数值。可以记下当前活动分组、服务器别名、系统代理状态、路由模式名称、DNS 是否由客户端处理、TUN 是否关闭，以及日志中最后一次正常连接的大致时间。服务器地址、认证信息等敏感内容不应抄入公开笔记；需要迁移时，使用客户端提供的配置导出功能，并将文件保存在受控位置。

采用单变量修改法

从基线开始，每轮只改变一个配置主题。例如先完成订阅分组与过滤，确认更新和选择都正常，再进入路由规则；路由稳定后再调整 DNS；最后才启用 TUN 或 FakeDNS。每完成一轮，至少验证三个方面：客户端日志没有持续错误、预期应用能够联网、不应被接管的流量仍按原路径工作。这样即使设置失败，也能直接撤销最近一次改动，而不必把整套配置恢复出厂。

日志等级在排错期间可临时提高到 info，需要观察路由匹配细节时再使用更详细等级。长期保持过细日志会增加阅读负担，也可能让真正有用的错误行被大量连接记录淹没。检查完成后恢复常用等级，并清理只为测试建立的临时规则。日志中的第一条错误通常比后续重复错误更有价值，因为后面的失败往往只是上游问题的连锁结果。

建立可回退的工作副本

开始大幅修改前，可在 v2rayN 中导出当前配置或复制现有路由配置集，再为副本取一个能说明用途的名称，例如“办公基础路由”或“测试-TUN-DNS”。名称应体现使用场景，不要只写“新配置”“配置二”。如果客户端支持多个路由配置集，应保留一个未经实验性修改的基础集。更新订阅不会替代这种备份，因为订阅主要保存服务器条目，并不一定包含本地路由、DNS、系统代理和自定义出站设置。

验证配置时要区分“客户端没有接管流量”和“流量进入客户端后出站失败”。前者通常检查系统代理、TUN、应用自身代理设置；后者则检查服务器、路由、DNS 和出站链。最直接的方法是先查看日志中是否出现目标域名或目标连接。如果完全没有相关记录，应从接管层向前排查；如果已经出现但随后报解析或连接错误，再从 DNS 与出站层继续。更多基础错误现象可对照帮助中心，避免把应用自身问题误判为内核问题。

分组按来源建立，不按临时状态堆叠

v2rayN 可以同时保存手动添加的服务器和多个订阅。较稳妥的组织方式是“一条订阅对应一个分组”，手动配置则单独放入“自建节点”之类的分组。这样更新某个来源时，不会误删另一个来源的条目，也能快速判断服务器字段来自订阅还是本地录入。若同一提供方给出不同用途的订阅地址，也应分别命名，并在名称中加入用途，而不是更新后再靠服务器别名猜测来源。

分组名称宜保持短而明确，例如“工作订阅”“移动备用”“自建节点”。不要把到期时间、某次测速结果或当前活动服务器写入分组名，这些信息变化频繁，会让名称很快失真。订阅备注应说明来源和使用范围；更新时间由客户端记录即可。多设备间需要保持相同服务器来源时，可参考电脑手机多设备同步 V2Ray 配置的三种方案，其中订阅同步与单节点传递的边界不同。

理解更新、清理和合并的区别

更新订阅时，客户端会根据订阅返回内容刷新对应分组。是否保留旧条目取决于客户端设置与更新方式，因此操作前应先确认当前选中的分组。若订阅源删除了某台服务器，而本地仍保留旧记录，可能是更新时启用了保留策略，也可能是同名条目来自另一个分组。此时不要直接全局删除同名服务器，应先显示分组列或切换分组视图，确认条目的真实来源。

“清理旧服务器”适合订阅内容已经发生较大变化的情况，但会影响该分组中手动修改过的备注。若确实需要保留本地调整，可以先复制必要条目到手动分组，再刷新原订阅。合并多个订阅看似能减少分组数量，却会失去来源边界：更新失败时难以判断是哪一条订阅有问题，重名服务器也更容易覆盖。除非上游已经提供统一订阅，否则更建议在客户端层保持多个独立分组。

使用过滤表达式缩小列表

服务器过滤主要解决“条目很多但常用范围很小”的问题。常见策略包括按别名关键词保留、按协议名称筛选、按关键词排除，以及同时使用多个条件。过滤仅改变列表展示或候选范围，不会修复服务器配置，也不会改变订阅原始内容。设置过滤前，应先检查服务器命名是否稳定；如果订阅每次更新都会更换别名格式，依赖名称的规则也要随之调整。

过滤表达式通常支持普通关键词或正则表达式。普通关键词更容易维护，适合名称结构简单的订阅；正则适合同时匹配多个固定词，但需要注意转义和大小写。下面的表达式表示保留名称中含“办公”或“备用”的条目，并排除名称中含“测试”的条目。具体输入位置以客户端的服务器过滤设置为准。

保留表达式：
办公|备用

排除表达式：
测试

如果使用正则，建议先从简单组合开始，不要一开始写过长的单行表达式。以名称为“办公-上海-VLESS”“备用-东京-Trojan”为例，可以使用 ^(办公|备用)- 匹配固定前缀。若名称中包含括号、加号或点号等正则特殊字符，需要进行转义。过滤结果为空时，第一步应临时清空排除条件，而不是重新导入订阅；确认条目恢复后，再逐段添加条件找出过度匹配的位置。

先理解规则从上到下匹配

一条连接进入 Xray 或 V2Fly 内核后，路由模块会根据域名、目标 IP、端口、网络类型、入站标签和进程信息等条件寻找匹配规则。通常首条命中的规则会决定出站，后续规则不再参与。因此，越具体的例外规则越应放在前面，范围较大的兜底规则放在后面。例如某个域名必须走代理，而它所属的整个域名分类默认直连，那么具体域名规则应排在分类规则之前。

常见出站标签包括 proxy、direct 与 block，实际名称取决于客户端生成的配置。自定义规则时必须使用当前配置中真实存在的出站标签，标签拼写不一致会导致规则无法指向预期出站。图形界面中的“代理”“直连”“阻断”通常会转换成这些标签；如果导入完整 JSON，则需要自行保持路由规则与 outbounds 数组中的 tag 对应。

域名规则与 IP 规则的职责

域名规则在连接仍保留域名信息时工作，适合按完整域名、子域名后缀或内置域名分类进行分流。IP 规则适合目标已经解析为地址，或需要处理局域网、保留地址段等情况。启用域名嗅探后，一部分最初只带 IP 的连接可能重新获得域名信息，再参与域名路由；但嗅探并不保证所有协议和应用都能恢复域名，因此关键规则不应只依赖单一路径。

domain:example.com 通常匹配该域名及其子域名，full:api.example.com 只匹配完整名称，regexp: 用于正则条件。能用完整域名或后缀表达的规则，不必使用正则。IP 规则可使用 CIDR，例如 192.168.0.0/16 表示一段局域网地址。规则中出现的示例域名仅用于说明语法，实际使用时应替换为需要控制的业务域名。

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

domainStrategy 决定路由阶段何时把域名解析成 IP。AsIs 优先保留域名，不主动为 IP 规则解析；IPIfNonMatch 在域名规则没有匹配时解析，再尝试 IP 规则；IPOnDemand 则在遇到可能需要 IP 的规则时更早解析。一般先使用客户端预设，不要仅为了“看起来更完整”改成更积极的解析策略，因为这会改变 DNS 请求出现的时机，并可能让排错链条变复杂。

用小规模规则集验证顺序

建立新路由集时，可以先只写三类规则：必须代理的少量域名、局域网地址直连、最后的默认出站。保存并应用后，用浏览器访问匹配域名，再从日志中确认命中的出站标签。验证完成后再加入域名分类、端口或进程规则。若一开始导入数百条自定义规则，单个例外很容易被前面的宽泛条件截获，也难以判断内置数据是否与当前内核匹配。

端口规则应结合网络类型理解。比如只写 53 可能同时影响 TCP 与 UDP 的 DNS 流量；只需要控制 UDP 时，应同时指定网络条件。进程规则依赖客户端、操作系统权限和接管方式，不同平台能力可能不同。它适合解决少量应用例外，不宜代替域名与 IP 规则成为主要分流手段。应用升级后可执行文件名称变化，也会使旧进程规则失效。

当某个网站包含多个资源域名时，只为主域名配置路由可能造成页面主体能打开、图片或接口失败。此时应在开发者工具或客户端日志中找到失败资源的域名，再把真正相关的后缀加入规则，而不是直接扩大为所有流量代理。对 VMess、VLESS、Trojan 与 Shadowsocks 的选型疑问，可阅读代理协议横向对比；协议决定连接方式，路由则决定连接送往哪个出站，两者不要混为一项设置。

区分系统 DNS 与内核 DNS

系统 DNS 是操作系统和普通应用默认使用的解析路径；内核 DNS 是 Xray 或 V2Fly 配置中的解析模块，主要服务于进入客户端的连接、路由判断和特定域名策略。启用系统代理时，部分应用可能先在系统侧解析，再把目标 IP 交给代理；另一些应用会通过代理请求保留域名。启用 TUN 后，DNS 请求还可能被内核截获。若不先判断查询从哪里发出，仅修改内核 DNS，可能对实际问题没有影响。

排查时可观察日志是否出现目标域名的解析记录。如果浏览器已经把域名解析成 IP 且没有被嗅探恢复，路由只能看到地址，域名规则可能无法命中。反过来，如果内核收到域名并负责解析，就要检查 DNS 服务器选择、查询类型、返回地址和后续路由。不要把所有解析失败都归因于服务器；域名拼写、系统缓存、应用自带安全 DNS、路由阻断和 UDP 接管不完整都可能造成相似现象。

为 DNS 服务器定义清晰职责

一套容易维护的配置通常只包含少量 DNS 服务器，并明确各自处理范围。默认服务器处理普通查询，指定服务器处理特定域名，必要时再配置回退。地址既可以是传统 UDP DNS，也可以是基于 HTTPS 的查询地址，具体支持取决于当前内核与客户端配置方式。选择时应优先考虑与现有路由兼容、能够稳定连接的服务，而不是堆叠多个相同职责的地址。

当 DNS 服务器本身使用域名表示时，会出现“先解析 DNS 服务器域名”的启动依赖。解决方式通常是提供 host 映射、使用可直接连接的地址，或指定用于解析该服务器域名的引导 DNS。若配置中还有自定义出站，应确认 DNS 查询是直连还是经过代理。查询路径与目标域名的流量路径可以不同，但这种差异应是明确设计的结果。

{
  "dns": {
    "hosts": {
      "router.local": "192.168.1.1"
    },
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": [
          "domain:example.com"
        ],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

示例中的 hosts 用于固定本地域名映射；带 domains 的服务器只处理匹配范围；最后一项作为普通查询路径。skipFallback 表示匹配该服务器的查询不再进入回退判断，适用于希望结果来源确定的域名。示例地址 dns.example 只用于展示结构，实际配置必须换成可用服务。若不需要分域名解析，可以直接使用简单服务器列表，配置越短越容易定位问题。

理解查询类型与缓存

queryStrategy 控制查询 IPv4、IPv6 或两者。网络环境没有可用 IPv6 路径时，如果解析得到 IPv6 地址但连接无法建立，可能出现等待后再回落的现象。此时可以根据实际网络能力选择仅查询 IPv4，而不是通过路由规则到处排除 IPv6。相反，确认系统和出站均有稳定 IPv6 时，保留双栈更符合正常网络行为。修改后应重新建立连接，并清理应用自身缓存，避免旧结果干扰判断。

DNS 缓存能够减少重复查询，但也意味着修改配置后不会立刻看到新结果。v2rayN 重启内核通常会清理内核侧状态，浏览器和操作系统仍可能保留缓存。验证时可以使用一个此前未访问的子域名，或等待缓存过期。不要用同一个长期打开的页面反复刷新判断，因为浏览器可能复用连接、复用解析结果，甚至由后台服务进程处理请求。

系统代理与 TUN 的接管范围

系统代理适合遵循操作系统代理设置的浏览器和桌面应用。它配置简单，停用后恢复也直观，但部分程序会忽略系统代理，UDP 流量的处理能力也取决于应用。TUN 模式通过虚拟网络接口接收更广范围的 IP 流量，因此常用于命令行工具、独立网络栈应用或需要统一处理 TCP 与 UDP 的场景。接管范围扩大后，局域网访问、开发环境、虚拟机和其他网络工具之间的关系也会变得更复杂。

启用 TUN 前，应先确认同一台服务器在系统代理模式下工作正常，并保证路由规则能够正确区分代理、直连和阻断。否则，TUN 只会让原有配置错误影响更多程序。首次测试时关闭其他会创建虚拟网卡或修改默认路由的软件，记录本机局域网网段与默认网关，并在 v2rayN 中启用基础 TUN 配置。成功后再逐个恢复其他网络组件，观察是否产生路由竞争。

理解虚拟接口、路由与严格模式

TUN 启动后，客户端会创建虚拟接口，并通过系统路由把目标流量导入该接口。自动路由负责写入所需路由项，严格路由则尽量减少流量绕过虚拟接口的机会。严格模式有助于保持路径一致，但也可能影响局域网发现、容器网络或特殊虚拟网卡。若启用后无法访问打印机、路由器管理页或开发设备，应先为局域网地址保留直连规则，再判断是否需要降低严格程度。

MTU 表示虚拟接口能够承载的数据包大小。设置过大时，某些路径可能发生分片或丢包；设置过小则增加包数量和额外开销。没有明确证据时应使用客户端默认值。典型的 MTU 问题表现为连接能够建立，但特定页面加载停住、上传失败或部分协议异常。排查时可以逐步降低数值并重复同一测试，但每次只改变一个档位，同时确认问题不是服务器或 DNS 引起。

按现象定位 TUN 启动问题

如果 TUN 无法创建接口，先查看日志中是否提示权限、接口名称冲突或驱动组件问题。Windows 上可能需要以具备相应权限的方式启动；macOS 与 Linux 则要确认系统是否允许客户端建立虚拟接口。不要在日志已经明确提示权限不足时反复切换服务器，因为服务器不会影响接口创建。重新安装客户端前，也应先确认当前使用的是下载页提供的对应平台版本。

如果 TUN 能启动但所有连接都失败，应检查默认路由是否指向虚拟接口、内核是否收到流量、DNS 是否可用，以及代理出站是否意外再次进入 TUN 形成循环。客户端一般会为自身连接设置排除或保护机制；自定义启动方式、外部核心或复杂路由可能破坏这一关系。日志出现大量连接重复、目标指向本机虚拟地址时，要优先考虑回环，而不是继续增加路由规则。

如果只有局域网失败，检查 geoip:private 或明确的私有网段是否直连，并确认局域网共享设置没有改变监听范围。常见私有网段包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。企业或实验室网络可能使用额外地址段，需要根据实际网络补充。域名形式的本地服务还依赖本地 DNS，不能只配置 IP 直连。

停用 TUN 后若网络没有立即恢复，可以先在客户端中正常停止内核，再检查虚拟接口和系统默认路由是否已撤销，最后重新连接当前网络。直接结束进程可能来不及执行清理步骤，因此不应作为日常关闭方式。若问题持续，可在帮助中心按“客户端已退出但网络异常”的思路逐层检查系统代理、虚拟接口与 DNS，而不是只重启浏览器。

FakeDNS 的工作过程

普通 DNS 查询会直接返回目标服务器的真实地址，应用随后连接该地址。若连接进入内核时只剩 IP，域名路由可能需要依赖嗅探才能恢复原始名称。FakeDNS 则从一段专用地址池中返回虚拟地址，并在内核内部保存“域名—虚拟地址”的映射。当应用连接这个虚拟地址时，内核根据映射找回域名，再执行域名路由和实际解析。这种方式的核心价值是保留域名上下文，而不是提高服务器性能。

FakeDNS 通常与 TUN 模式一起使用，因为 TUN 能接收应用发往虚拟地址的连接，并把它交回内核。仅开启 FakeDNS 但没有正确劫持 DNS 请求时，应用仍可能从其他解析路径得到真实地址；只劫持 DNS 却没有让虚拟地址流量进入内核，则会表现为解析成功但连接失败。因此，DNS 查询入口、FakeDNS 地址池、TUN 路由和内核映射必须形成闭环。

地址池与映射容量

FakeDNS 地址池应选择不会与本机局域网、企业网络、容器网络和其他虚拟接口冲突的保留范围。客户端预设通常已经考虑常见情况，除非出现明确冲突，不建议自行更换。冲突的典型表现是启用后某段真实内网地址无法访问，或系统把虚拟地址送往错误接口。排查时应查看系统路由表，比较 FakeDNS 地址池与现有网络的路由范围。

映射容量决定同时保留多少域名记录。容量过小可能让较早映射被频繁替换，复杂网页加载大量域名时更容易出现不一致；容量过大则没有明显必要。保持客户端默认值通常足够。应用长期复用旧 DNS 结果时，即使内核映射已经清理，仍可能继续连接失效的虚拟地址。遇到这种情况，应同时重启应用连接和内核，而不是只反复刷新网页。

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

示例展示 FakeDNS 的常见结构：指定域名分类使用虚拟解析，其他查询交给普通 DNS。198.18.0.0/15 是经常用于此类映射的地址范围，但是否适合仍要以本机网络为准。不同内核配置格式可能把 fakedns 放在不同层级，v2rayN 也可能通过界面自动生成相关字段。不要把片段直接覆盖整个配置，应先与客户端导出的当前结构对照。

哪些场景不适合优先启用

依赖本地 DNS 返回内网地址的办公系统、局域网设备名称和分流解析环境，需要谨慎使用 FakeDNS。这些域名通常应交给本地 DNS 并直连，不应返回虚拟地址。可以通过指定域名规则、域名后缀或本地 hosts 映射让它们绕过 FakeDNS。若企业内部域名没有稳定后缀，建议先收集实际查询记录，再建立明确列表，不要使用过宽的排除条件。

某些应用会验证 DNS 返回地址、直接使用内置 DNS、缓存时间很长，或在连接过程中再次比较目标地址。这类应用与 FakeDNS 的配合可能不稳定。遇到单个应用异常时，优先为其相关域名使用普通解析，而不是关闭整个 TUN 配置。若异常无法通过域名范围定位，再退回不使用 FakeDNS 的基线，确认问题是否确实由虚拟映射引起。

FakeDNS 与域名嗅探可以互补，但不应盲目全部开启。FakeDNS 已经能为受控 DNS 查询保留映射，嗅探则处理未经过映射但可从协议中恢复域名的连接。启用嗅探时要留意目标覆盖设置：如果内核用嗅探域名替换原目标，路由结果可能改变。建议先让 FakeDNS 处理主要 TUN 流量，再根据日志中仍只显示 IP 的连接决定是否启用嗅探。

用日志验证映射链路

验证时选择一个此前没有缓存的域名，观察 DNS 请求是否由 FakeDNS 返回虚拟地址，再观察紧随其后的连接记录是否显示原域名。随后确认路由命中的出站标签，并检查实际连接是否成功。若只看到 DNS 记录，没有后续连接，通常是虚拟地址未被 TUN 接管或应用没有立即发起连接；若有连接但无法恢复域名，则检查映射是否被清理、请求是否来自同一内核实例。

为每条订阅定义用途与优先级

多订阅并不意味着要把所有服务器混在一个候选池中。更可控的做法是先为每条订阅定义用途，例如日常主用、工作备用、特定设备或测试来源，再分别建立分组。日常选择只在当前用途分组内进行，需要切换来源时再切换分组。这样可以避免同名服务器混淆，也能减少自动选择功能跨来源跳转造成的结果变化。

订阅名称应包含稳定信息，不应依赖服务器数量或更新时间。可以采用“用途—来源简称”的格式，并在备注中写明适用设备、是否允许自动更新、是否包含特殊路由参数。若订阅地址带有访问令牌，应只保存在客户端订阅配置中，不要复制到截图、公开日志或共享文档。需要向另一台自己的设备传递时，应使用受控方式，并在不再使用的设备上移除旧配置。

错开更新并保留失败现场

同时更新所有订阅虽然省步骤，但某个来源失败时，日志中容易混杂多组请求。首次配置或正在排错时，建议逐条更新：先选中分组，执行更新，确认返回内容能够解析，再处理下一组。稳定后可以使用定时更新，但更新间隔不宜过短。订阅内容通常不会按分钟变化，过于频繁只会增加请求和列表重建次数。

更新失败时先保留当前分组，不要立即删除并重新添加。查看失败属于网络连接、地址失效、响应格式错误，还是内容为空。若地址能够访问但解析失败，可能是订阅格式与客户端预期不一致；若只有当前活动代理下更新失败，可以临时切换更新订阅所使用的出站路径。订阅更新与普通网页访问可能走不同设置，应在日志中确认请求实际由直连还是代理发出。

当更新返回空内容时，客户端的保留策略很重要。稳妥做法是避免空响应直接覆盖已有服务器，待确认来源恢复后再更新。如果客户端已经清空分组，可从配置备份恢复，而不是凭记忆重建每台服务器。更新成功后，也应抽查协议、地址、端口、传输方式和安全层字段是否完整；只看到服务器名称出现，不代表每个字段都能建立连接。

处理重复条目与名称冲突

不同订阅可能包含相同服务器，别名也可能完全一致。仅按名称去重可能误删配置不同的条目，仅按地址和端口去重又可能忽略协议或用户标识差异。因此，除非明确知道上游内容关系，不建议跨分组自动合并。列表中过多重复项可以通过分组视图隐藏，而不必破坏原始订阅结构。

如果确实需要生成统一候选集合，可先保留原始分组，再建立一个手动精选分组，把少量常用条目复制进去。精选分组不会自动继承订阅更新，因此每次上游调整后都要重新检查。它适合长期稳定的少量服务器，不适合作为所有订阅的镜像。服务器字段发生变化时，旧复制项不会自动修正，这是手动分组最容易被忽略的维护成本。

自动选择与手动选择的边界

自动选择功能应限定在配置一致、用途相同的候选集内。如果把协议、用途和来源完全不同的服务器放入同一自动集合，某次选择变化可能同时改变连接能力与路由表现。进阶配置阶段更建议先手动固定服务器，完成 DNS、路由和 TUN 验证后，再打开自动选择。这样出现故障时，可以排除“活动服务器刚好变化”这一变量。

不要把一次延迟测试当作长期排序依据。网络路径会随时间和连接状态变化，能快速响应测试请求的服务器也不一定适合所有业务。选择时应同时关注连接是否稳定、协议字段是否完整、目标应用是否正常，以及切换后是否需要重建旧连接。需要了解客户端界面中的分组、服务器列表与日志位置，可阅读v2rayN 主界面功能分区速览。

出站对象由协议、设置和标签组成

内核中的每个出站至少包含协议类型、协议设置和用于路由引用的标签。v2rayN 根据选中的服务器生成主要代理出站，同时通常还会生成直连与阻断出站。自定义出站可以连接本机已有的 SOCKS 服务、指定特殊直连行为，或作为链式连接的一环。无论用途如何，标签必须唯一且稳定，因为路由规则、DNS 服务器和其他出站可能通过标签引用它。

添加自定义出站前，先画出流量路径：哪个入站接收流量，哪条路由命中，自定义出站连接到哪里，该出站自身是否还需要经过另一个代理。如果路径无法用一两句话说明，配置通常已经过度复杂。链式出站会增加故障点，任何一段的 DNS、认证、监听地址或网络不可用，都会表现为最终连接失败。应逐段验证，而不是只看链路末端。

{
  "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 服务定义为 local-socks，并保留直连和阻断出站。使用前必须确认该端口确实有服务监听，且不会反向把连接送回 v2rayN 当前入站，否则可能形成循环。示例没有认证字段；如果本地服务要求认证，应按内核支持的 SOCKS 服务器结构添加，并避免在公开文档或截图中展示真实凭据。

用路由把有限目标送入自定义出站

新出站建立后，不要立刻设为全局默认。先创建一条只匹配测试域名的路由规则，并将 outboundTag 指向新标签。确认日志显示规则命中，再检查本地 SOCKS 服务是否收到连接。测试通过后逐步扩大范围。若规则没有命中，问题在路由条件或顺序；若命中但本地服务没有连接，检查出站地址、端口和循环；若本地服务收到连接但最终失败，再排查下一段链路。

{
  "type": "field",
  "domain": [
    "full:test.example.com"
  ],
  "outboundTag": "local-socks"
}

出站标签改名后，所有引用位置都必须同步更新。常见遗漏包括路由规则、DNS 服务器的 outboundTag、代理链中的 proxySettings，以及客户端界面保存的自定义模板。内核启动时报“找不到标签”时，应搜索整个生成配置，而不是只检查 outbounds 数组。若客户端会在每次启动时重新生成配置，直接修改临时 JSON 可能在下次应用设置时丢失，应优先使用客户端提供的自定义配置入口。

配置文件的验证方法

保存前先检查 JSON 语法：对象和数组括号是否成对、最后一个成员后是否多出逗号、字符串是否使用双引号。语法正确只代表文件可解析，还要确认字段被当前内核支持。启动后从日志开头检查配置加载结果；若内核直接退出，第一条错误通常会给出字段路径或标签名称。修复一个错误后重新加载，后续错误可能只是被前一个错误遮挡。

配置能够启动后，再按“入站—路由—出站—目标”的顺序验证。先确认测试连接进入预期入站，再确认路由命中目标标签，随后检查出站建立，最后验证应用行为。对 DNS 相关出站，还要单独确认解析请求是否使用该标签。不要只用浏览器页面是否打开作为唯一判断，因为缓存、连接复用和应用回退可能掩盖配置问题。

控制长期维护成本

一套长期可用的进阶配置，应能回答三个问题：每条自定义规则为什么存在、它依赖哪个分组或出站、失效时如何回退。建议在规则名称或本地说明中记录用途，不记录敏感连接信息。每隔一段时间检查一次不再使用的订阅、重复服务器、失效过滤词、过期的域名例外和无人引用的出站标签。删除前先停用并观察，确认没有隐含依赖后再彻底清理。

客户端和内核更新后，不要立即把所有旧设置重新调整一遍。先使用原配置验证基本连接，再阅读界面中新增或变化的选项，重点检查 TUN、DNS、路由数据和配置生成方式。若出现问题，使用本章开头建立的基线逐层恢复。v2rayN 是桌面平台的首选客户端；Android 可按内核需要选择 v2rayNG 或 v2flyNG，三款客户端的具体入口和平台说明集中在客户端下载页。

当某个问题只在一台设备出现时，应比较接管方式、系统 DNS、局域网网段和应用代理行为，不要先假定订阅内容不同。多设备导入同一订阅，只能保证服务器来源接近，并不能同步本地路由、TUN 权限、系统代理和 DNS 缓存。把这些设备侧变量列出来逐项比较，通常比重复导入订阅更有效。

进阶配置的目标不是让配置文件不断变长，而是让流量路径更符合实际需求。能由客户端预设解决的问题优先使用预设；只有当日志和测试明确指出边界不足时，再增加一条针对性规则。保持变更范围小、标签含义清楚、验证步骤固定，即使订阅、网络环境或使用场景发生变化，也能较快找到需要调整的那一层。