V2Ray 进阶配置手册

先建立可回退的配置工作模型

把问题拆成入口、决策和出口

进阶配置容易混乱，通常不是因为某个参数太难，而是多个层级同时发生变化。一次完整连接至少经过三段：应用流量先进入系统代理或虚拟网卡，内核再根据域名、IP、端口和进程信息匹配路由，最后由代理、直连、阻断或自定义出站处理。订阅负责提供远端服务器，路由负责决定流量交给谁，DNS 负责把域名转换成地址，TUN 则改变流量进入内核的方式。先把这四层分开，排错时就不必反复重装客户端。

例如，浏览器可以连接而命令行工具不能连接，优先检查入口层：浏览器可能读取了系统代理，终端程序却直接建立连接。普通代理可用而 TUN 开启后异常，优先检查虚拟网卡、路由表和 DNS 接管。某个域名始终走错线路，则检查路由规则的匹配顺序，而不是立刻更换订阅。能解析域名却无法建立连接，还要区分解析结果错误、出站不可达和协议参数不一致。把现象映射到层级，是整本手册最重要的工作方法。

每次只改一个变量

开始实验前，保留当前可工作的基线。记录已选服务器、系统代理状态、路由模式、DNS 模式和 TUN 开关；如果客户端支持配置导出或备份，保存一份副本。随后一次只修改一组相关设置，并立即验证。不要在同一次操作里同时启用 TUN、切换 DNS、导入新路由和更换服务器。四项一起变化后，即使连接恢复，也很难知道真正起作用的是哪一项；一旦连接中断，定位成本会成倍增加。

验证也要分层。先检查客户端日志中内核是否正常启动，再检查本地监听端口或虚拟网卡是否建立，然后测试域名解析，最后测试目标应用。日志中的第一条错误往往比后续连锁报错更有价值。若内核因配置格式失败，后面的连接超时只是结果。可以配合系统命令观察基础状态，但命令输出只说明当前操作系统看到的结果，不能替代客户端日志。

Windows:
ipconfig /flushdns
ipconfig /all

macOS:
scutil --dns
route -n get default

Linux:
resolvectl status
ip route

准备一组稳定的验证样本

验证样本应覆盖三类请求：一个预期直连的站点、一个预期代理的站点、一个仅用于检查 DNS 的域名。不要频繁更换测试对象，否则目标服务自身的波动会干扰判断。浏览器测试时先关闭可能单独接管代理或 DNS 的扩展，并留意浏览器自己的安全 DNS设置；终端测试时明确指定是否读取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 环境变量。不同程序进入代理链路的方法并不相同。

修改前后都记录时间点。v2rayN 日志会持续滚动，准确的操作时间可以帮助定位对应请求。若日志里只有 IP 而没有域名，说明域名可能在进入内核前已经由应用解析；此时仅写域名路由规则未必能命中，需要调整嗅探、DNS 或 IP 规则。若日志显示域名与预期一致，但最终使用的出站不对，再检查规则优先级和标签。完成这一套基线后，后续每章都可以沿用相同的回退和验证方法。

订阅分组与服务器过滤

分组的目标是隔离来源，不是堆叠标签

v2rayN 可以同时保存手动服务器和多个订阅源。服务器数量增加后，最先需要解决的不是“如何显示更多”，而是“如何保持来源可追踪”。建议一个订阅地址对应一个订阅分组，分组名称写清用途或来源，不要只写“订阅一”“备用二”。当某批服务器参数异常、名称重复或更新后消失时，来源清晰能直接缩小排查范围。手动添加的测试服务器也应放进独立分组，避免订阅更新时误判其归属。

分组名称应保持稳定，服务器备注可以变化。把地区、用途、协议等信息全部塞进分组名，会使菜单和筛选条件越来越长；更合适的做法是用分组表示来源，用服务器备注表示节点特征。例如分组记录服务来源，备注保留“地区｜线路｜协议”这样的固定顺序。统一的备注格式能让关键词过滤真正发挥作用，也方便在更新前后识别同一批服务器。

先做包含过滤，再补排除条件

服务器过滤通常包含两类逻辑：只保留命中关键词的项目，或者排除命中关键词的项目。开始时建议使用一个明确的包含词，例如地区名或用途标记，确认结果正确后再增加排除词。复杂正则表达式虽然紧凑，但维护成本高，订阅方只要调整命名方式，原有表达式就可能把全部服务器过滤掉。过滤结果为空时，先暂时清空条件并更新分组，确认原始数据存在，再逐项恢复条件。

如果使用正则表达式，需要注意大小写、空格、全角符号和括号。订阅备注里看起来相同的横线，可能分别是连字符、短横线或其他字符。更稳妥的表达式应抓住稳定文字，不依赖装饰符号。下面示例表示保留名称中包含“东京”或“首尔”的项目，同时排除含“测试”或“过期”标记的项目。具体输入框是否分为包含和排除两项，取决于客户端界面；应分别填写，不要把两段逻辑拼成一段难以阅读的表达式。

包含条件：
东京|首尔

排除条件：
测试|过期

理解更新、覆盖与删除之间的区别

更新订阅时，客户端会重新读取订阅内容并刷新所属服务器。某个服务器消失，可能是上游删除、过滤条件改变、分组选择错误，或订阅解析失败。不要马上手动补回同名服务器；先打开更新日志，确认订阅请求是否成功，再查看未过滤的原始结果。如果手动服务器与订阅服务器使用相同备注，也不要仅凭名称判断它们是同一项，应检查地址、端口、协议和分组归属。

修改订阅地址前先确认是在编辑现有分组还是新建分组。直接用新地址覆盖旧分组，可能让历史来源和新来源混在同一个名称下。来源发生实质变化时，创建新分组、完成测试后再停用旧分组，通常比原地覆盖更容易回退。清理旧分组之前，还要检查当前活动服务器是否属于该组，以及路由规则或自定义配置中是否引用了相关标签。

多来源整理的完整实践可继续阅读多机场订阅分组管理：v2rayN 服务器过滤与备注实践。当过滤已稳定工作，再进入下一章配置路由；不要用过滤功能代替路由功能。过滤决定列表里看见哪些服务器，路由决定一次请求使用哪个出站，两者处在完全不同的层级。

路由规则实战：从命中顺序到出站标签

规则是有顺序的决策链

路由系统会根据请求携带的信息选择出站。常用条件包括域名、目标 IP、目标端口、网络类型和进程名。关键点不是规则数量，而是命中顺序：更具体的规则应放在更通用的规则之前，最终再用兜底规则处理剩余流量。若“全部域名走代理”的规则排在“内部域名直连”之前，后者通常没有机会执行。调整规则时应从日志中选一个真实请求，沿规则列表逐条判断，而不是凭视觉猜测。

域名规则适合表达站点归属，IP 规则适合处理明确网段，端口规则适合限制特定服务。进程规则依赖客户端和操作系统是否能取得进程信息，跨平台迁移时需要重新验证。一个请求也可能先以域名形式进入内核，随后解析为 IP；是否保留域名取决于入口、嗅探和 DNS 设置。因此，同一条域名规则在普通系统代理和 TUN 模式下可能表现不同。

先定义出站，再让路由引用标签

底层配置通常使用标签连接路由和出站。例如 proxy 表示当前代理出站，direct 表示直连，block 表示阻断。标签只是内部引用名，并不会自动创建对应能力。路由规则引用了不存在的标签时，内核可能拒绝启动，也可能在生成配置阶段报错。使用 v2rayN 图形路由编辑器时，界面会处理一部分关联；导入自定义 JSON 时，则需要自行保证标签一致。

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:intranet.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

上面的结构展示了规则关系，但 proxy 出站需要由客户端根据当前服务器生成，不能把片段单独保存成完整运行配置。私有地址规则放在前面，可以避免局域网设备被交给远端处理；明确域名规则随后匹配；最后一条捕获剩余 TCP 与 UDP。若只想让部分流量代理，则不要添加全捕获规则，而应为目标域名建立代理规则，并让默认出站保持直连。

选择合适的域名策略

AsIs 倾向于直接使用进入路由器的域名信息，不为了 IP 规则主动解析；IPIfNonMatch 会在域名规则未命中时解析 IP，再尝试 IP 规则；IPOnDemand 更积极地为可能需要 IP 判断的请求执行解析。策略越积极，DNS 对路由结果的影响越大。若规则主要基于域名，通常先从保留域名信息的方案开始；若依赖地理 IP 数据，再考虑未命中时解析。

不要为了“提高命中率”同时堆叠大量域名和 IP 规则。域名的解析结果会变化，内容分发服务也可能共享地址。过宽的 IP 范围会误伤不相关站点。对固定内网网段使用 IP 规则很合适，对公共站点则优先使用域名分类，并通过日志确认。规则未命中时，检查日志里看到的是完整域名、子域名还是纯 IP；若只有 IP，需要回到 DNS 和嗅探层处理，而不是继续增加域名条目。

验证路由结果而不是只验证“能打开”

网页能打开不代表路由正确，它可能通过错误的出站碰巧成功。验证时查看连接日志里的目标、匹配规则和最终出站标签。分别请求预期直连与预期代理的样本，确认两者走向不同。局域网服务还应测试主机名与 IP 两种访问方式，因为主机名可能被 DNS 解析到私有地址，而直接输入 IP 会跳过域名阶段。

遇到规则失效，按“规则顺序、条件格式、请求可见信息、出站标签”四项检查。先暂时把目标规则移到顶部；仍不命中时缩小条件，只保留一个域名或 IP；再观察入口是否携带所需信息；最后确认标签存在。这样可以把复杂规则还原成可验证的最小样本。需要了解 VLESS、VMess、REALITY 等术语与路由的关系，可查阅术语表，但协议名称本身不应被当作路由结果的替代指标。

DNS 配置优化：明确谁解析、在哪里解析

先画清解析路径

DNS 问题最常见的根源是“同时有多个解析者”。应用可以自行解析，操作系统有系统解析器，浏览器可能启用独立的安全 DNS，v2rayN 内核也能处理 DNS，TUN 模式还可能接管系统查询。配置前要先回答三个问题：域名由谁发起查询，查询交给哪个服务器，查询本身走直连还是代理。只修改 DNS 地址而不确认路径，往往会出现日志看似正常、实际请求仍使用旧缓存的情况。

普通系统代理下，很多应用会先在本机解析域名，再把 IP 交给代理；也有应用通过 SOCKS 的远程解析语义把域名交给内核。TUN 模式下，系统流量更容易被统一接管，但浏览器内部解析仍可能绕开预期路径。排查时先关闭应用层独立 DNS 做对照，清理系统缓存，重新发起一个此前未访问过的子域名请求，再观察客户端日志是否出现对应查询。

本地 DNS 与远端 DNS 分工

稳定的策略通常不是把所有域名交给同一个解析器，而是按用途分工。局域网主机名和内部域名应交给能识别它们的本地解析器；需要由代理侧视角解析的公共域名，可以交给经代理访问的 DNS；普通直连域名则使用系统或指定的本地 DNS。分流前必须保留私有地址和内部后缀的直连路径，否则打印机、路由器管理页、开发环境服务可能解析失败。

DNS 服务器的地址形式也会影响引导过程。使用域名形式的加密 DNS 端点时，客户端首先需要解析这个端点自身，形成“解析解析器”的引导问题。应提供可用的引导 DNS，或者使用明确的 IP 端点并正确处理服务器名称。不要把互相依赖的两个解析器配置成环：A 的域名交给 B，B 的域名又交给 A，这类配置通常表现为启动后长时间等待或周期性超时。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal"
        ],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

这个示例演示静态主机映射、内部域名专用解析器和一个后备解析器。实际使用时应把 192.168.1.1 替换为本地网络真实可用的 DNS 地址，并确认该地址能够响应查询。skipFallback 表示匹配到指定域名后不再落到其他服务器，适合内部域名；如果专用解析器不稳定，这一设置也会直接暴露故障，因此必须先单独测试。

理解查询策略和地址族

DNS 返回 IPv4、IPv6 或两者，应用随后会选择其中一个建立连接。网络只有部分 IPv6 能力时，解析器返回 IPv6 地址并不代表路径可用，常见表现是首次连接等待后才回退到 IPv4。此时应先检查系统是否具备完整 IPv6 路由，再决定查询策略。不要仅因为一次连接变慢就永久关闭某类地址；先用系统网络工具确认默认路由、DNS 返回和目标可达性。

UseIP、UseIPv4、UseIPv6 等策略控制内核接受或偏向哪类结果，具体支持范围取决于当前内核。配置跨设备迁移时，地址族策略不应直接照搬：桌面有线网络、无线网络和移动热点的能力可能不同。适合固定网络的设置，在另一个网络上可能造成解析成功但连接失败。

完成调整后，依次清理客户端缓存、系统缓存和应用缓存，再测试新域名。若只刷新网页，浏览器可能复用已有连接，无法反映 DNS 变化。DNS 优化的目标是路径明确、故障可观察，而不是不断增加解析器数量。两到三个职责清晰的解析入口，通常比一长串自动回退地址更容易维护。

TUN 模式：接管系统流量而不掩盖边界

TUN 与系统代理解决不同问题

系统代理依赖应用主动读取代理设置，浏览器和多数桌面应用通常支持，部分命令行工具、游戏程序或自定义网络组件则可能忽略。TUN 模式通过虚拟网卡和系统路由把更多 IP 流量送入内核，覆盖范围更广，但同时引入路由表、DNS 接管、权限和虚拟网卡驱动等新变量。它不是系统代理的“更强开关”，而是一条不同的入口路径。

启用 TUN 前，应先确认同一服务器在普通代理模式下能够稳定连接。这能把远端协议、订阅参数和服务器可达性从排查范围中暂时移除。随后记录当前系统 DNS、默认网关和客户端路由模式，关闭可能创建其他虚拟网卡的网络工具，再启用 TUN。首次测试只保留基础路由，不要同时打开 FakeDNS 和复杂自定义规则。

权限、虚拟网卡和路由表

创建虚拟网卡和写入系统路由通常需要较高权限。权限不足时，界面开关可能变化，但日志会提示网卡创建或路由写入失败。Windows 侧重点是虚拟网卡状态、防火墙和路由优先级；macOS 侧重点是系统授权、网络扩展状态和 DNS 服务顺序；Linux 侧重点是 TUN 设备权限、策略路由、网络管理服务以及防火墙规则。遇到问题时先看日志中的第一条系统调用错误，不要反复点击开关。

虚拟网卡建立后，检查是否新增预期地址与路由。默认路由未改变不一定表示失败，部分实现会使用更具体的路由或策略路由接管流量。反之，看到新默认路由也不代表所有流量都能正确返回；还要确认私有网段、当前网关和 DNS 服务器没有被错误送入代理形成回环。局域网访问中断时，首先检查私有地址是否直连，以及“允许局域网连接”之类的监听设置是否与本机防火墙一致。

MTU 与 UDP 边界

TUN 连接能建立但部分站点卡住时，需要考虑 MTU。数据包经过额外封装后会变大，底层网络若不能正确分片或反馈路径 MTU，较大的请求可能静默丢失。典型现象是小页面或文本请求正常，上传、图片和长连接异常。调整 MTU 应小步进行，并在每次修改后测试相同请求；不要直接把数值降得很低，过小会增加分片与处理开销。

UDP 也需要单独验证。DNS 常用 UDP，但部分应用还会使用其他 UDP 协议。服务器出站、内核、TUN 栈和路由规则都要允许相应流量。若 TCP 正常而 UDP 异常，先确认路由日志中 UDP 请求是否进入内核，再检查出站能力和本机防火墙。不要把所有 UDP 故障都归因于 DNS，因为 DNS 也可以通过 TCP 或加密传输完成。

退出 TUN 后恢复系统状态

正常关闭客户端时，虚拟网卡、路由和 DNS 设置应被清理；系统强制关机、客户端崩溃或权限变化时，可能留下旧状态。关闭 TUN 后若网络仍异常，先彻底退出客户端，检查虚拟网卡和路由是否还存在，再重新连接当前网络。必要时重启系统网络服务，而不是直接删除不认识的系统接口。删除错误接口可能影响正常网络。

稳定性测试应覆盖启动、关闭、睡眠恢复、网络切换和系统重启。一次成功连接只能说明当前状态可用，不能证明生命周期处理完整。确认这些场景都能恢复后，再进入 FakeDNS 配置。若只需要让浏览器和常规桌面软件使用代理，系统代理的维护成本更低；只有确实存在不读取代理设置的程序时，TUN 的额外复杂度才有明确收益。

FakeDNS：保留域名信息的地址映射

理解“假地址”的用途

部分应用会先在本机完成 DNS 解析，再只把目标 IP 交给 TUN。内核收到纯 IP 后，域名路由规则难以判断请求原本属于哪个站点。FakeDNS 的思路是为域名分配一个专用地址池中的临时地址，应用连接这个地址时，内核再通过映射找回原始域名。这样既能保持 TUN 对 IP 流量的接管，又能让域名规则继续工作。

专用地址不对应真实远端主机，它只在本机代理链路内部有意义。因此，FakeDNS 必须与能够识别映射的入口、DNS 和路由协同使用。只配置一个地址池，却没有让系统查询进入 FakeDNS，映射不会产生；系统取得了假地址，但流量没有进入对应 TUN，连接也会直接失败。配置时要把“查询返回假地址”和“连接被内核还原”为一个完整闭环。

地址池要避开现有网络

FakeDNS 地址池必须与本机局域网、企业网络、容器网络和其他虚拟网卡网段保持隔离。若地址池与真实路由重叠，操作系统可能把连接送向错误接口，内核甚至看不到请求。选择地址池前检查当前路由表，并考虑设备经常连接的网络环境。笔记本在家庭网络可用，不代表切换到办公网络后仍不冲突。

地址池大小影响可保存的映射数量。普通桌面使用不需要追求极大范围，稳定且不冲突比容量更重要。映射具有生命周期，应用缓存时间、内核缓存和系统 DNS 缓存若不一致，可能出现旧假地址找不到原域名的情况。修改地址池或切换 FakeDNS 模式后，应清理系统和应用 DNS 缓存，并重新建立连接。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "fakedns"
        ]
      }
    }
  ]
}

该片段用于说明 FakeDNS 地址池与入口嗅探的关联，并非可单独运行的完整配置。v2rayN 通常会根据界面选项生成入口和路由，手动合并配置时应检查是否重复定义同名入站。destOverride 允许内核根据可识别信息恢复目标，但嗅探并不等于解密内容，它只使用连接建立阶段可见的协议信息。对无法识别的流量，仍要依赖 FakeDNS 映射或 IP 规则。

哪些请求不适合交给 FakeDNS

局域网主机名、内部服务发现域名和需要返回真实地址给其他设备的查询，通常不应使用 FakeDNS。它们应交给本地 DNS，并通过私有地址规则直连。若将打印机、存储设备或开发环境域名映射成假地址，应用也许能把请求送入内核，但局域网发现、证书校验或旁路设备访问可能失败。应为内部后缀建立明确的 DNS 分流，并设置在公共解析规则之前。

直接把解析结果展示给用户或传递给其他程序的工具，也需要谨慎。命令行查询看到专用地址属于预期行为，但如果后续程序不经过 TUN，就无法使用这个结果。排查脚本、监控程序和容器环境常出现这种“解析在宿主机，连接在另一个网络命名空间”的情况。确认查询与连接是否经过同一代理入口，是判断 FakeDNS 是否适用的关键。

用闭环方法排查映射失败

排查顺序应固定为四步：先确认 DNS 查询进入客户端，再确认返回地址落在设定地址池，然后确认应用对该地址的连接进入 TUN，最后确认日志恢复出原始域名并命中正确路由。第一步失败，检查系统或应用 DNS；第二步失败，检查 FakeDNS 规则和缓存；第三步失败，检查虚拟网卡与路由；第四步失败，检查映射生命周期、嗅探和规则顺序。

若开启后只有少数程序异常，不要立刻扩大地址池。先对比异常程序与正常程序的 DNS 行为，检查它是否使用独立解析、缓存旧地址、绕过系统路由或把解析结果传给其他进程。FakeDNS 适合解决“域名信息在 TUN 前丢失”的问题，不负责修复所有 DNS 故障。只有在普通 DNS 与 TUN 已稳定时启用，才能清楚观察它带来的具体变化。

多订阅管理：更新、迁移与失效隔离

把订阅当作配置来源管理

当订阅数量增加后，管理重点从“挑选最快的服务器”转为“控制配置变更”。每个订阅都是一个会变化的外部来源：服务器可能增加、删除、更名或调整参数。应记录来源用途、更新方式、最近一次成功更新时间和当前是否参与日常选择。客户端分组名负责表达来源，备注前缀负责表达服务器特征，过滤条件负责缩小视图，这三层不要混用。

建议把订阅分为常用、备用和测试三类，但分类不必写成复杂层级。常用来源参与日常更新，备用来源保留少量验证样本，测试来源用于观察新配置。新订阅先进入测试分组，完成解析、连接、DNS 和路由验证后再纳入常用列表。这样即使新来源包含异常参数，也不会立刻替换当前工作链路。

安排可观察的更新流程

同时更新所有订阅很方便，却不利于定位失败。首次整理时应逐组手动更新，记录每组是否成功、服务器数量是否明显变化、过滤后是否仍有结果。确认稳定后再使用批量更新。某一组更新失败时，不要连续高频重试；先查看响应错误、解析错误还是过滤结果为空。网络请求成功只说明取得了内容，不代表内容能被客户端正确解析。

更新前保持一个已验证的活动服务器，更新后不要立刻清理旧项。先从新结果里选取一项测试，确认连接和路由正常，再删除明确失效的数据。如果更新行为会覆盖整个分组，可以在大幅调整前导出客户端配置。备份的价值在于恢复分组、备注和规则关系，而不仅是保存订阅地址。

处理重复服务器与备注漂移

两个来源可能提供参数相同但备注不同的服务器，也可能使用相同备注指向不同参数。去重时不能只看名称。应至少比较协议、地址、端口、传输方式、安全层参数和关键标识。若参数完全一致，可以保留来源更稳定、命名更清晰的一项；若只有部分一致，则视为不同配置，不要合并。

备注漂移会破坏关键词过滤。解决办法不是不断扩展正则，而是为重要服务器建立本地统一备注，或让过滤词只依赖较稳定的地区和用途字段。若客户端在更新时会重置备注，应把过滤逻辑设计得更宽松，再通过分组缩小范围。过滤表达式越依赖上游排版，维护频率越高。

迁移设备时按层恢复

跨设备迁移不要一次复制所有系统相关配置。先安装与平台匹配的客户端：桌面端优先使用 v2rayN，Android 可按内核需求选择 v2rayNG 或 v2flyNG。随后导入订阅和分组，验证普通代理连接，再迁移路由规则和 DNS，最后根据新系统能力重新配置 TUN。虚拟网卡权限、DNS 服务和进程规则具有平台差异，不应从旧设备直接照搬。

迁移后的第一轮验证只选择一个订阅、一个服务器和一套简单路由。稳定后再恢复过滤条件与多来源更新。若旧设备导出的自定义配置包含绝对文件路径、本地端口或局域网 DNS 地址，需要逐项替换。尤其是 127.0.0.1 监听端口：新设备上可能被其他程序占用，导致内核启动失败。

建立失效隔离而不是频繁删除

发现异常服务器时，先移动到停用或测试分组，保留日志和参数用于对照。立即删除会失去比较样本，也可能在下次订阅更新时重新出现。只有确认来源已移除、参数长期失效或重复项已替代后，再清理记录。对于更新后整体异常的订阅，应暂时停用该组，而不是让它继续参与自动选择。

长期维护可以固定一个简短周期：更新订阅、检查失败日志、验证常用服务器、清理失效过滤词、备份配置。无需每天重做全部步骤，但每次大改前都应执行。客户端本身的更新与订阅内容更新也要分开处理；更换客户端安装包前可先查看下载页的平台说明，确认当前平台与客户端型号，再按基线流程恢复配置。

自定义出站：串联本地服务与明确回退路径

什么时候需要自定义出站

常规使用只需当前服务器生成的代理出站、直连和阻断。自定义出站适合明确的工程需求，例如把特定流量交给本机另一个 SOCKS 服务、为某类目标指定独立出口，或建立可控的回退链。它不适合用来掩盖订阅配置错误。当前服务器本身无法连接时，先修复协议参数和网络可达性，再考虑增加出站。

设计自定义出站时先写清三个信息：入口请求由哪条规则命中，目标出站使用什么协议和地址，出站失败后是否允许回退。每个出站设置唯一、语义清楚的标签，例如 local-socks、direct。不要使用 proxy1、proxy2 这类缺乏含义的名称，配置增长后很难从日志判断实际路径。

连接本机 SOCKS 出站

下面示例把命中 domain:service.example 的流量交给本机 127.0.0.1:1081 上的 SOCKS 服务。该本地服务必须已经启动，并且不能把流量再次送回 v2rayN 当前入口，否则会形成回环。监听地址使用回环接口可以限制访问范围；若确实需要连接局域网服务，应单独评估防火墙和访问控制。

{
  "outbounds": [
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:service.example"
        ],
        "outboundTag": "local-socks"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

保存前检查 JSON 结构、端口类型和标签拼写。端口应为数字，不要写成带引号的文本。若 v2rayN 使用的是配置片段合并功能，还要确认合并位置：把完整 outbounds 数组覆盖到客户端生成配置上，可能删除当前服务器对应的代理出站。更稳妥的方式是使用客户端支持的自定义出站或高级配置入口，并在生成后的运行配置中确认原有出站仍存在。

避免回环与重复代理

回环通常发生在两个本地服务互相把流量交给对方。例如 v2rayN 的入口监听在 127.0.0.1:10808，自定义出站连接另一个本地服务，而该服务的上游又指回 127.0.0.1:10808。日志会快速出现重复连接、端口耗尽或连接超时。绘制一条从应用到最终网络出口的单向链路，确认任何一步都不会返回上游入口。

系统代理与环境变量也可能制造隐蔽回环。本地上游程序如果自动读取系统代理，它建立出站连接时可能再次进入 v2rayN。运行本地上游时，应明确它是否忽略系统代理，或为其进程配置直连规则。进程规则在不同平台支持情况不同，因此还应准备目标地址直连作为补充，但地址变化时需要维护。

回退不是自动“容错”

多个出站并列存在，不代表内核会自动从失败线路切换到下一条。回退、负载均衡或健康检查需要对应的策略对象与可观察条件。若没有明确配置，请把每条路由看作确定选择：命中后就交给指定出站。为了排错清晰，初期只配置一个自定义出站，验证稳定后再增加策略。

回退路径还要区分连接失败与业务响应失败。内核通常能观察网络连接是否建立，却无法把所有应用层状态都判断为“应切换线路”。过于积极的回退可能让同一请求重复发送，对提交类操作并不合适。设计策略时应根据协议和业务性质决定，而不是把所有失败都视为可重试。

从启动日志到单请求验证

自定义配置保存后，先重启内核并查看配置加载阶段。若出现未知字段、标签不存在、端口格式错误或数组覆盖，先修复第一条错误。内核成功启动后，只发送一个目标请求，确认日志里显示目标域名、命中规则和 local-socks 标签。随后停止本地 SOCKS 服务再次请求，观察错误是否明确指向本地端口；这一反向测试可以证明流量确实走了自定义出站。

如果内核点击启动后立即退出，可参考从日志逐行定位配置错误。系统代理开启后，浏览器与终端表现不一致，则阅读浏览器与终端两条线分开排查。完成自定义出站后，再保存一份可工作的配置副本，并记录所依赖的本地端口和服务启动顺序。这样在系统重启、客户端迁移或端口冲突时，可以快速恢复到明确基线。