配置进阶手册

订阅分组与服务器过滤

订阅分组首先是管理边界，不是网络出口。分组保存订阅地址、更新选项及相关筛选条件，服务器记录才包含协议、地址与端口。把一条记录移动到另一个分组，不代表连接会自动改走不同线路；同样，点击分组标签通常只改变列表展示范围，不等于切换当前活动服务器。调整前应分清“正在查看哪个组”和“正在使用哪条服务器”，避免更新后误判连接状态。

建立可追溯的分组

在 v2rayN 的“订阅分组”相关管理入口新增分组，先填写能表达来源与用途的备注，再粘贴完整订阅地址。不同界面布局可能把入口放在菜单或工具栏中。订阅地址经常包含个人授权信息，不应贴入公开截图、问题讨论或共享文档。首次添加时只建立一个组，更新成功后检查列表的协议类型与地址是否完整，再继续添加其他来源，便于把错误定位到具体订阅。

更新方式需要结合现有连接判断。“不通过代理更新”适合当前网络能直接访问订阅地址的情况；“通过代理更新”依赖已经可用的代理连接。若尚未导入任何可用服务器，却要求更新请求经过代理，就可能形成启动依赖。此时先确认订阅地址能否直接打开，或使用来源提供的单条分享链接完成初始连接，再尝试代理更新。不要把更新失败直接解释为全部服务器失效。

过滤列表与改变数据的区别

服务器过滤至少有两类：列表搜索只隐藏不匹配的行，订阅导入过滤则可能决定哪些记录进入本地数据库。两者作用时机不同。先用列表搜索确认关键词确实匹配目标记录，再在分组设置中使用导入过滤。若界面明确支持正则表达式，可按别名筛选；若只支持普通文本，则不能把正则语法当作通用输入。字段名称与匹配范围应以当前界面说明为准。

研究|办公
^(研究|办公)-

上面两行分别演示“包含任一关键词”和“以指定前缀开头”的正则写法，不是需要同时填入的配置。前者范围较宽，后者要求别名具有固定命名结构。先在少量记录上测试，确认是否区分大小写、是否匹配整段文本，再决定用于整个订阅。空结果应先取消过滤并重新更新；反复改订阅地址通常不能修复由筛选条件造成的空列表。

更新后的检查顺序

订阅更新可能重建服务器记录，手动修改的别名、传输参数或备注未必能保留。需要长期维护的自定义记录，应放入单独的手工分组，并记录修改原因。不要直接在自动更新组里修补服务端参数后长期使用，否则下一次更新可能覆盖修补结果。确实存在来源配置错误时，优先向来源核实，而不是把未知参数逐项试开。

v2rayNG 中可通过“订阅分组设置”管理来源，再执行订阅更新；具体菜单名称以安装的界面为准。Android 的剪贴板权限、网络访问环境与桌面不同，同一地址在桌面更新成功，不保证手机当前网络也能访问。v2flyNG 作为 V2Fly 内核备选，应另外核对订阅中协议与扩展字段的支持情况，不能仅凭列表成功出现就认定连接参数全部兼容。

更新后先核对组内是否仍有预期记录，再确认活动服务器是否需要重新选择，最后进行真连接测试。真连接测试会实际建立连接，与仅探测主机响应不是同一件事；批量测试还可能消耗流量。记录较多时先选小范围验证，结果异常再看日志。关于延迟与倍率的取舍，可继续阅读节点选择说明，不要只按列表排序决定全部业务的出口。

路由规则实战

路由规则回答的是“进入内核的连接送往哪个出站”，并不决定所有应用是否进入内核。系统代理没有覆盖的应用，通常不会因为新增路由规则就自动被接管。先用一个已遵循系统代理的浏览器验证规则，再考虑 TUN。v2rayN 的“路由”入口可选择预置方案或编辑规则；“绕过大陆”等名称代表一组具体策略，使用前应查看规则内容，而不是仅根据名称推断所有域名的处理结果。

先确定匹配顺序与出站标记

Xray 与 V2Fly 的常见路由规则按顺序寻找匹配项，先匹配的规则决定去向。宽泛规则放在前面，会遮住后面的精确规则。一个规则对象同时写入域名、端口和网络类型时，通常要求这些条件共同成立；同一域名数组里的多个条目则表达候选匹配。设计时先用一条明确的域名规则验证，再逐步增加端口或地址约束，避免把“并且”和“或者”的关系混在一起。

下面是 Xray / V2Fly 路由字段的结构示例，只展示私有地址直连、保留示例域名直连与其余流量代理的顺序。它依赖现有配置已经定义名为 direct 和 proxy 的出站。客户端生成的标记可能不同，必须对照实际配置调整；示例中的保留域名仅用于教学，不能替代需要分流的真实业务域名。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

域名匹配与地址匹配分开验证

full: 用于精确域名，domain: 用于该域名及其子域名，regexp: 使用正则表达式。没有前缀的文本可能按子串规则解释，范围容易超出预期。只需要处理一个固定站点时，优先采用可读的精确或后缀匹配。业务页面可能同时请求登录、静态资源和接口域名，首页打开并不代表整个业务已沿同一路径完成，需要在日志中核对相关请求。

AsIs 倾向于直接按已有目标信息匹配；IPIfNonMatch 会在域名规则未命中时尝试解析以继续地址匹配；IPOnDemand 则可能在规则需要地址信息时触发解析。这些策略改变路由阶段的解析时机，不等于替浏览器统一指定 DNS。若规则依赖地理地址分类，应同时确认域名如何解析、地理数据是否可用，以及当前连接是否带有域名信息。

预置规则与自定义规则的边界

地理域名分类依赖相应数据文件，分类内容并非实时网络探测结果。数据缺失可能导致启动报错，数据过旧则可能导致分类与预期不同。先确认客户端当前使用哪套规则资源，再通过客户端提供的更新入口处理。不要把另一种规则引擎的语法直接粘贴进来，即使都出现域名和地区名称，其字段、匹配机制与数据格式也可能完全不同。

修改路由后，应关闭测试应用的旧连接再重试。浏览器复用连接、应用连接池与缓存会让新规则看起来没有生效。验证时只改一条规则，打开对应日志，确认新请求的目标与出站标记，再恢复其他业务。若需要代理全部已接管流量，应调整路由的兜底行为；若需要接管原本不经过代理的应用，则应查阅下文 TUN 章节。二者是不同维度，不能用一个“全局”称呼替代排查。

规则中还应保留局域网访问需求。打印机、家庭存储与企业内网站点可能使用私有地址，也可能使用内部域名。仅放行私有地址，未必能解决内部域名无法解析的问题；仅放行域名，也未必覆盖应用直接访问的地址。先确定业务实际访问形式，再把 DNS 与路由成对处理。常见模式差异可结合入门指南中的连接验证重新建立基线。

DNS 配置优化

DNS 故障经常表现为“代理已经连接，网页仍打不开”，但并非所有域名请求都由同一处解析。操作系统、浏览器、应用内置解析器与代理内核可能分别维护缓存和解析通道。配置前先画清请求路径：应用把域名交给本地代理，还是先解析成地址再连接；内核按域名匹配路由，还是需要解析后匹配地址。只有知道域名在哪一层变成地址，才知道应该修改哪处设置。

区分三类解析任务

第一类是代理服务器自身域名的解析，它发生在建立代理连接之前，需要一个当时就能访问的解析路径。第二类是业务目标域名的解析，可能在本地完成，也可能由远端处理。第三类是路由辅助解析，用于地址规则匹配。把三者都指向必须经代理访问的解析服务，可能让客户端在启动时就陷入依赖循环：代理尚未建立，却需要代理才能解析服务器地址。

在 v2rayN 中调整“DNS 设置”前，应先核对当前内核与配置模式。有些选项用于生成 Xray 配置，有些作用于 TUN 所用的网络组件；界面里名称相近，不代表写入同一个字段。v2rayNG 的“启用本地 DNS”涉及本地解析处理，仍需结合远程 DNS、直连 DNS 等实际选项理解。不要在不知道作用范围时同时启用多个 DNS 接管功能。

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["domain:example.com"],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

这段 Xray / V2Fly 风格的 DNS 片段演示按域名选择解析器，并为其他查询设置普通解析地址；能否访问该解析地址取决于实际网络。localhost 表示使用系统解析器，不是要求本机一定运行一个独立 DNS 服务。skipFallback 用于限制该服务器参与非指定域名的回退查询，不表示所有解析失败都会被禁止重试。片段仅作用于内核 DNS，不能直接控制所有应用。

加密解析仍然依赖正确路由

使用加密 DNS 时，要同时考虑解析服务域名的初始解析、连接端口与请求出站。选择加密传输并不能自动修复网络不可达，也不能替代业务流量的路由规则。若解析服务只能通过代理访问，应确认代理服务器自身不依赖这个尚未建立的通道。对已有可用配置，先单独替换业务解析器并验证，再考虑接管系统 DNS，避免一次引入多个依赖。

IPv4 与 IPv6 也需要成对检查。返回 IPv6 地址不意味着当前网络与所选出站具备可用的 IPv6 路径；只请求 IPv4 可能暂时绕开问题，却不等于修好了 IPv6。遇到部分网站超时，应分别观察返回地址族、实际连接地址与路由出口。UseIP、UseIPv4 或 UseIPv6 的支持范围和作用字段，应以正在使用的内核说明为准，不能跨组件照抄。

按缓存层次验证修改

改完 DNS 后，先重启客户端相关网络组件，再关闭测试应用的旧连接；必要时清理系统与浏览器缓存。浏览器若启用独立的安全 DNS，测试请求可能绕开系统解析器，因此需要在测试记录中注明其状态。使用命令行查询得到的结果，只代表该命令采用的解析路径，不能自动代表浏览器、聊天应用或代理内核获得了相同结果。

企业内网域名尤其需要保留原有解析路径。公共解析器通常不知道内部名称，统一替换后可能出现外网页面恢复、办公系统反而失效的情况。应为内部域名保留系统或内网解析器，并为对应地址设置直连规则。若内部域名由网络动态下发，不应把某次观察到的服务器地址永久写死；切换办公网络后要重新验证，避免把局部配置带到其他环境。

排错顺序建议固定为：先看代理服务器域名能否解析，再看业务域名是否返回预期地址族，随后确认请求走向哪个出站，最后检查连接错误。只有在解析确实不符合预期时才调整 DNS。若出现证书名称不匹配、握手失败或账户授权错误，应回到对应连接参数处理，反复更换解析器通常不会解决这些问题。涉及虚拟地址映射时，再查阅 FakeDNS 章节。

TUN 模式

TUN 模式通过虚拟网卡接收 IP 数据包，常用于覆盖不遵循系统代理设置的应用。它与“自动配置系统代理”不是同一个开关，也不等于把所有流量都送往代理服务器。是否接管某条连接由网卡与路由决定，接管之后走直连还是代理又由规则决定。因此，排查 TUN 时要分成两步：数据包有没有进入接管路径，以及进入后选择了哪个出站。

启用前建立系统代理基线

先关闭 TUN，使用系统代理完成一次网页访问与真连接验证，确认服务器参数本身可用。记录当前活动服务器、路由方案和 DNS 设置，再启用 TUN。若系统代理阶段已经无法连接，不宜用 TUN 继续叠加变量。v2rayN 的具体 TUN 实现取决于平台与发行包，相关组件可能不是主代理内核；Xray 路由片段不能未经转换就当作另一组件的配置。

虚拟网卡与系统路由通常需要相应权限。Windows 可能需要提升权限，macOS 可能需要网络相关授权，Linux 则涉及设备访问与路由管理权限。遇到启用失败，应先看日志是否已经创建网卡、是否成功添加路由，再判断是权限问题还是网络参数问题。不要把所有客户端长期以最高权限运行当作默认修复；先确认当前包提供的权限申请方式与具体错误。

避免出口回环与双重接管

接管系统流量后，代理程序自身访问服务器的连接必须能正常离开接管路径，否则可能再次被送回自身。成熟的客户端通常会处理接口绑定、路由排除或进程保护，但多网卡、其他 VPN、手工路由和防火墙规则可能破坏这些条件。出现一启用就断网时，先暂停其他网络接管工具，只保留一个客户端，再比较启用前后的路由与日志。

系统代理与 TUN 同时开启并不必然出错，但会增加理解路径的难度：部分应用先连接本地代理端口，其他应用直接进入虚拟网卡。排错时先采用单一接管方式，确认稳定后再决定是否需要同时使用。Android 的 v2rayNG 与 v2flyNG 通常通过系统 VPN 接口接管流量；同一用户空间的另一个 VPN 应用可能与之竞争授权，连接按钮显示启动并不能替代实际网络验证。

应用范围、局域网与 UDP

v2rayNG 的“分应用代理”用于确定哪些应用纳入或排除 VPN 处理，具体选择含义应看当前模式说明。选中应用并不一定总表示“只代理这些应用”，因为包含与排除模式的方向相反。先选一个测试应用，完全退出后重新打开，观察是否进入客户端日志，再扩大范围。系统组件、下载管理器与嵌入式网页可能由不同进程发起请求，要结合实际业务验证。

局域网发现、打印与投屏可能依赖广播或组播，不能只靠一条私有地址直连规则保证恢复。先确认对应流量是否应进入 TUN，再看客户端是否提供局域网绕过设置。实时通信或游戏常使用 UDP，测试网页成功不能证明 UDP 路径也正常；需要同时核对本地接管能力、出站协议与服务端支持。不要把协议支持 UDP 的描述理解为所有网络环境均可传输。

MTU 影响单个数据包的有效负载范围。只有在出现特定大请求卡住、连接建立但传输异常等线索时，才考虑调整，并记录原值逐步验证。盲目把 MTU 调得很小可能降低效率，也可能掩盖其他问题。先排除 DNS、出站不可达与重复接管，再做这类底层调整；同一数值不应作为所有平台和网络的固定答案。

退出时先通过客户端关闭 TUN，再结束程序，随后确认普通网络访问恢复。若异常退出造成网络不可用，重新打开客户端执行正常关闭，检查系统代理与虚拟网卡状态；必要时重连当前网络。不要直接删除不认识的系统网卡或清空全部防火墙规则。macOS 授权问题可参考安装放行与网络权限说明，启动阶段故障则应先处理客户端本身。

FakeDNS

FakeDNS 返回的是供本地映射使用的虚拟地址，而不是业务服务器的真实公网地址。应用拿到虚拟地址后发起连接，接管组件根据映射找回原始域名，再按域名执行路由或交给代理处理。这种机制有助于保留域名信息，但成立条件很明确：DNS 查询与后续连接必须经过能够共享映射关系的路径。只启用一个名为 FakeDNS 的选项，并不能自动补齐整条链路。

先判断是否确实需要虚拟映射

如果应用已经通过本地代理提交完整域名，内核通常可以直接按域名匹配，不必为了“优化”再加一层 FakeDNS。它更适合需要从 IP 层接管连接、又希望恢复域名信息的场景。是否启用应取决于接管方式与客户端支持，而不是看到选项就全部开启。不同组件中的 FakeDNS 与 fake-ip 名称相近，但配置字段、地址池与缓存实现未必相同。

下面展示 Xray / V2Fly 风格配置中的地址池、DNS 与入站嗅探关系。它不是 v2rayN 所有 TUN 实现的通用配置，也不包含完整入站与出站。只有确认当前内核支持这些字段、DNS 查询确实由该内核处理时，才应把对应部分合并到自定义配置。采用客户端图形开关时，应优先让客户端生成配置，避免同时手写另一套相冲突的设置。

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

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"],
    "metadataOnly": false
  }
}

第二段属于需要恢复映射的入站对象内部，不能直接放在完整配置的任意位置。地址池必须与接管路由一致，并避免与当前实际网络冲突；示例使用的是专用测试地址范围，不是可供应用直接访问的公网服务。poolSize 代表映射容量，不是服务器数量或性能承诺。客户端管理映射池时，应优先保留其默认值，再根据明确故障调整。

映射、缓存与流量嗅探的关系

普通流量嗅探尝试从连接初始数据中识别域名，FakeDNS 恢复则依赖之前建立的地址映射。两者不能简单互相替代。部分协议或加密握手无法暴露可识别域名，嗅探不一定成功；映射如果已丢失，只有虚拟地址也不足以推断原域名。v2rayNG 的“启用流量嗅探”应结合实际内核设置理解，不能把它视作恢复任意连接目标的万能开关。

最容易出现的边界是客户端重启后映射消失，而应用仍缓存旧虚拟地址。此时应用继续连接旧地址，当前内核却没有对应关系，表现为部分应用失败、重新打开后恢复。处理时应关闭旧连接，清理相关 DNS 缓存或重启测试应用，再重新查询域名。只重启代理但保留所有应用连接，可能延长这种不一致状态，导致排错结果相互矛盾。

为特殊业务保留真实解析

有些程序会比较解析地址、把地址写入后续协议字段，或者使用独立解析器绕过系统 DNS。内部发现服务与依赖地址语义的应用，也可能不适合虚拟地址响应。遇到兼容性问题，应先为对应域名或应用恢复真实解析路径，再验证业务功能，不宜继续叠加嗅探参数。局域网域名通常应与内网解析器配合处理，而不是统一返回虚拟地址。

若测试工具显示目标属于虚拟地址池，不能据此判断业务服务部署在哪个地区，也不能把该地址用于延迟比较或手工固定服务器。要观察真实连接，应看实际出站与远端目标日志。反过来，浏览器显示正常公网地址，也不一定说明 FakeDNS 完全未生效，可能是浏览器使用了独立 DNS，或命中了尚未过期的缓存。验证必须从新查询开始。

停用 FakeDNS 时，同样要处理缓存与路由的顺序。先切回真实解析配置并重新加载客户端，再清理应用持有的虚拟地址，确认新查询不再返回地址池范围，最后检查接管规则是否恢复预期。若修改后只有少数应用失败，先检查缓存；若所有业务立即失败，优先检查配置生成、DNS 可达性与接管链路，而不是更换服务器记录。

多订阅管理

多订阅管理的目标是保留来源边界、减少重复修改，并能在更新失败时明确回退。订阅数量增加并不自动带来故障转移，也不意味着客户端会根据业务选择最合适的服务器。应把“来源管理”“活动服务器选择”和“业务路由”分别设计：来源负责提供记录，活动服务器决定默认代理出口，路由决定哪些连接交给该出口。三者混在一起，更新时最容易失去可追溯性。

按维护方式而不是临时用途分组

建议把自动更新来源与手工维护记录分开。自动组只保存来源返回的参数，手工组保存经过明确验证的本地修改，并在备注中说明用途和修改原因。来源名称应稳定，不必随当前活动服务器变化。业务用途可以通过备注或筛选表达，避免为了“办公”“视频”等标签重复导入同一份订阅，最终形成大量难以判断是否相同的记录。

重复记录不能只按别名判断。两条名称相似的服务器可能使用不同传输层、端口、认证参数或服务名称；名称不同的记录也可能指向相同连接参数。执行去重前，应明确客户端按什么字段识别重复项，先备份再处理。若无法确认规则，宁可保留来源分组，通过显示过滤减少列表干扰，也不要对所有组执行不可追溯的批量删除。

更新计划与失败回退

自动更新适合参数稳定、来源响应可靠的订阅，但更新频率不宜脱离实际需要。过于频繁可能触发来源限流，也可能让临时错误更难复现。调整为定时更新后，应观察一次正常流程，确认失败时原有记录是否保留、成功时活动服务器如何处理。不同客户端与不同更新操作的行为可能不同，不应假设“更新失败一定不会改变本地数据”。

批量更新前，先确保至少一条已验证的连接路径可以恢复。若更新必须通过代理，保留当前可用记录尤其重要；若更新后来源返回空内容，应先看响应错误与过滤条件，不要立刻再次清空全部分组。回退应恢复本地备份或重新导入已确认的来源配置，而不是把旧授权链接公开寻求他人代测。授权信息失效时，应由来源重新签发。

跨设备同步与格式选择

桌面与 Android 之间迁移时，优先传递订阅地址或客户端支持的单条分享链接，而不是直接复制整个客户端数据目录。数据库、界面状态、路径与运行组件存在平台差异，目录复制可能带入不可用路径或旧权限。迁移后先核对协议、传输参数与安全设置，再完成真连接验证。v2rayN 上可用的扩展字段，不代表 v2flyNG 所用内核也具有相同支持。

Base64 订阅通常封装多条分享记录，完整 JSON 则可能包含入站、出站、路由与 DNS。把完整 JSON 当作普通订阅导入，客户端未必能提取服务器列表；把分享链接当成完整配置，也不会自动拥有原来的路由方案。遇到导入错误，应先识别内容类型与客户端入口，具体结构可参考订阅格式与分享链接说明，不要仅靠修改文件扩展名尝试转换。

导出记录同样要注意范围。有的操作只导出选中服务器，有的导出当前组，完整备份则可能包含所有分组与设置。传给另一台自己的设备前，先确认文件中是否包含不需要迁移的来源。清理旧设备时，应同时检查导出文件、剪贴板历史与云盘副本，避免只删除客户端界面里的记录，却保留可继续访问的订阅地址。

用变更记录替代反复试配

每次较大调整，记录原路由方案、当前内核、接管方式和修改原因。记录不需要保存凭据，只需能回答“哪一步开始异常”。多来源同时出问题时，先检查共同依赖：当前网络、DNS、系统时间、客户端权限与更新代理路径；只有单个来源失败时，再检查地址有效性、响应格式与来源授权。这个顺序比轮流重装三款客户端更容易保留有效线索。

最后，把备份恢复也作为一次实际操作验证。确认备份能够重新导入、手工记录仍可识别、路由与 DNS 没有遗漏，再依赖自动更新长期运行。恢复测试应在可控时段进行，避免办公连接正在使用时切换整个配置。桌面客户端无法启动时，可先按启动闪退排查确认运行环境；配置损坏与来源失效是两类问题，应分别处理。

自定义出站

出站是内核实际建立目标连接的执行对象，路由通过标记把连接交给它。v2rayN 日常使用通常由客户端根据当前服务器生成代理出站，再配合直连和阻断出站。只有需要明确的多出口、特殊链路或完整自定义配置时，才有必要直接管理出站结构。先确认需求能否通过图形界面的服务器选择与路由规则完成，再进入手写配置，能减少客户端生成逻辑与本地修改互相覆盖的风险。

从可验证的最小结构开始

下面是一份只包含本地 SOCKS 入站、直连出站与阻断出站的 Xray / V2Fly 风格教学配置。它不会连接任何远程代理服务器。监听地址限定为本机回环，避免意外把本地代理服务开放给局域网。使用它的目的，是理解入站、路由与出站标记的引用关系；要连接订阅提供的远程服务，应使用经过验证的服务器参数，而不是自行猜测认证字段。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

示例的未匹配连接交给首个出站，也就是直连；保留示例域名用于演示阻断规则。测试前要确认监听端口没有被现有客户端占用，不要在同一端口启动第二个实例。客户端使用完整自定义配置时，界面中的活动服务器、DNS 或路由开关是否继续生效，取决于具体导入方式。必须通过实际生成配置或日志确认，不能默认所有图形设置都会叠加进去。

标记命名与默认行为

tag 是本地引用名称，不是协议名称，也不是服务端自动识别的参数。路由中的 outboundTag 必须准确引用已经定义的出站，拼写不一致会产生启动或运行问题。建议使用含义明确且互不重复的短名称，并把默认出站放置顺序记录清楚。不能依赖服务器别名自动变成出站标记；客户端列表中的显示名称与内核配置字段属于不同层。

修改前先保存一份能工作的完整配置，再进行语法与启动验证。JSON 不允许普通注释与末尾多余逗号，界面编辑器接受内容也不代表内核接受字段。若日志报告未知协议或未知字段，先核对实际启动的是 Xray 还是 V2Fly，以及字段所在层级。另一网络组件的配置即使同样使用 JSON，也不能直接导入。错误定位应从首个有效错误开始，避免被后续连锁报错干扰。

链式连接与多出口边界

链式连接要求明确每一段的职责：前一段负责到达后一段，后一段负责访问最终目标。配置中引用另一个出站的方式、可用传输能力与字段支持取决于内核实现；不能仅按想象把两个服务器对象并列放置就形成链路。每一段都应先单独验证，再测试组合后的 DNS、UDP 与连接复用。组合路径增加依赖，任何一段失效都可能影响最终连接。

多个出站同时存在，也不代表自动测速、负载均衡或故障转移已经启用。若需要选择器或均衡策略，应另外配置其候选集合、选择逻辑与健康判断，并确认当前内核确实支持。桌面用户只有切换默认服务器的需求时，优先使用 v2rayN 的现有服务器选择方式。把复杂配置引入日常环境前，应能说明它比简单配置多解决了哪个具体问题。

回到业务请求验证

完成配置后，按入站监听、路由命中、出站连接、业务响应四层验证。端口成功监听只证明程序启动到一定阶段；真连接成功也不代表目标业务的所有域名与 UDP 都可用。选择一个可重复的业务操作，关闭旧连接后执行，并记录错误发生在哪一层。临时提高日志详细程度后，应注意其中可能包含目标域名与地址，排错结束再恢复常用日志级别。

如果自定义配置失败而图形生成配置正常，先回退到正常方案，再比较两者的入站、默认出站、DNS 与路由差异，不要继续修改订阅中的认证参数。长期保留自定义方案时，应把适用内核、依赖资源和恢复步骤写入本地说明。基础概念可查术语表，三款客户端的适用范围见选型指南；初始连接尚未建立时，仍应回到入门主线，先完成最小可用配置。