进阶配置手册

订阅分组与服务器过滤

分组结构：来源、用途与可追溯性

订阅分组：应当回答“这些服务器来自哪里”，而不是替代路由策略。建议先按配置来源建立独立分组，再在备注中标明用途，例如日常连接、临时测试或内核兼容验证。分组名称只影响整理和选择，不会自动决定某个应用的流量去向；需要按域名或地址选择出口时，仍应进入路由设置。

操作入口：在 v2rayN 的订阅分组设置中新增分组，填写容易识别的名称，并将订阅地址放入该分组的地址字段。保存后只更新这个分组，先确认解析成功，再检查服务器列表是否归入预期位置。不同界面的菜单名称可能调整，判断入口时应同时核对“分组名称、订阅地址、更新”这几个字段，而不是照搬截图坐标。

信息保护：订阅地址通常包含可识别账户的路径或参数，应该视为访问凭据。分组备注不要复制完整地址，排错截图也应遮盖敏感部分。将配置导出交给他人之前，还要检查服务器地址、用户标识与认证字段；只删除订阅链接，并不意味着导出的服务器配置已经脱敏。

过滤规则：先理解匹配对象

服务器过滤：先确认当前入口过滤的是订阅返回内容、已导入服务器，还是界面正在显示的列表。搜索框通常只改变可见范围，并不删除配置；订阅过滤则可能影响下一次导入结果。两者混用时容易误以为服务器丢失，实际只是显示条件仍在生效，或更新时被过滤掉了。

匹配语法：过滤字段不一定都支持正则表达式，也不一定采用相同的大小写规则。先用一个明确存在的短词测试，再尝试组合条件。若入口注明支持正则，可以用 办公|测试 表达二选一的备注匹配；如果仅支持普通文字，这段内容就可能被当成一个完整字符串，导致没有结果。

条件收紧：先保留较宽的匹配范围，确认需要的配置出现后，再逐步加入排除条件。不要一开始就写复杂的反向匹配，因为节点备注会被来源方改名，括号、空格和地区缩写也未必稳定。协议是否受支持，应查看配置本身与内核日志，不能仅凭备注里的某个关键词做判断。

更新验证：区分下载失败与解析失败

更新路径：订阅更新是客户端发起的一次网络请求，它与浏览器当前能否访问网页不是同一项测试。直连无法取得内容时，可以评估“更新订阅时使用代理”之类的设置，但前提是已有可用出口。首次导入尚未建立连接时，开启代理更新可能形成依赖循环，应该先解决基础访问路径。

解析结果：更新提示成功后，不要只看总条目变化，还要检查协议类型、地址、端口与分组归属。返回内容可能是过期提示页或认证页面，网络请求成功并不保证它是有效订阅。如果日志显示格式异常，先检查地址是否复制完整、是否到期，再判断订阅格式是否被当前客户端支持。

本地修改：手工调整过的订阅服务器可能在下次更新时被替换。需要长期保留的改动，应使用客户端支持的独立配置或复制到人工维护分组，并记录与来源配置的差异。不要把同一条配置在多个分组反复编辑，否则排错时很难确认实际激活的是哪一份。

恢复顺序：服务器突然减少时，先清空列表搜索，再关闭新增过滤条件，最后仅更新受影响的分组。先比较错误日志与原始配置类型，不要立即删除全部订阅重建。更新失败的更细分支可查阅v2rayN 订阅更新失败与自动更新设置；涉及多个来源的维护节奏，继续阅读多订阅管理。

路由规则实战

请求路径：入站、匹配与出站

路由模型：应用请求先进入某个入站，内核根据目标域名、目标地址、端口等条件查找规则，再把连接交给对应出站。系统代理或 TUN 决定请求能否进入这条路径，路由只处理已经交给内核的流量。因此，应用没有使用本机代理时，反复修改域名规则通常不会改变它的访问结果。

匹配顺序：规则一般按排列顺序检查，先命中的规则决定出站。应将范围明确的例外放在前面，再放较宽的集合规则。一个规则对象内的不同条件通常需要同时满足，同一条件数组内的条目则通常是任选其一；若把域名条件与地址条件写在同一对象里，得到的范围可能比预期更窄。

协议边界：VMess、VLESS 与 Trojan 描述连接协议，REALITY 属于传输安全相关配置，不能替代路由。节点能导入只说明客户端识别了配置格式，不意味着每个运行内核都支持全部字段。选择协议时应以服务端参数为依据，再确认实际启动的内核，而不是为了命中某条分流规则去改节点协议。

规则片段：局部合并与标签核对

示例用途：下面是 Xray 路由局部片段，将私有地址与中国大陆域名集合交给名为 direct 的出站。使用前需要确认对应出站已经存在，且本地有可读取的规则数据文件。片段未定义代理出口，也没有指定所有未匹配请求的去向；不能据此推断剩余流量必然经过代理。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

标签对应：outboundTag 是对出站标识的引用，不是任意显示名称。客户端可能生成其他标签，必须查看实际生效配置后再引用。若保存时检查通过，但运行时报找不到出站，应先核对标签大小写和拼写；若客户端重新生成配置后标签改变，则应回到受支持的路由编辑入口处理。

域名策略：AsIs 优先用已有域名信息匹配，不为了地址规则主动执行这一步解析；IPIfNonMatch 在域名未匹配时尝试解析后继续匹配地址；IPOnDemand 则在规则需要地址信息时触发解析。后两者可能增加解析依赖，不能简单理解为越积极解析就越准确。

命中验证：用日志区分规则与连接问题

信息来源：应用通过 SOCKS 传入域名时，内核可以直接进行域名匹配；应用先自行解析、只传入地址时，可用信息就不同。流量嗅探可能从部分协议中补回域名，但并非每种连接都能识别。日志只有地址时，先确认请求携带的信息，再决定是否需要嗅探、DNS 调整或 TUN 配合。

验证方法：选一个目标明确的访问操作，暂时减少后台应用干扰，查看连接使用的入站、目标与出站标签。若命中正确出站但连接仍失败，应转查该出口的连通性与服务端配置；若命中错误，才继续检查规则顺序、域名是否可见以及地址集合是否覆盖目标。不要用网页打开速度代替路由命中证据。

兜底行为：自定义配置中，未匹配流量通常会交给默认出站，而默认出站与出站列表顺序有关；图形客户端还可能生成自己的兜底规则。新增或重排出站前应明确记录这项行为。把直连出站挪到前面，可能让原本通过代理的未匹配请求改走直连，影响范围远大于新增的一条规则。

回退方法：一次只增加一类条件，保留修改前的规则顺序与当前出口记录。出现异常时先禁用新规则，再重启内核或重新建立测试连接，因为已有连接未必重新匹配。需要理解规则集合名称时可查阅名词解释；若正确命中后仍无法连接，再按节点超时排查顺序向下定位。

DNS 配置优化

解析分层：先确定谁在查询

解析链路：系统解析器、浏览器自带的安全解析、客户端内置 DNS 与服务端解析可能同时存在。修改客户端 DNS，不一定改变浏览器自己发出的解析请求；启用系统代理，也不代表系统所有查询都进入内核。优化之前先画出实际路径，确认应用提交的是域名还是地址，以及最终由哪一层选择解析服务器。

问题分类：域名无法解析、解析结果不可达、解析速度较慢和路由目标错误，是不同的问题。若地址已经返回但连接超时，继续更换解析服务器未必有效；若同一域名在不同网络得到不同地址，也不必立即判断异常，分布式服务本就可能按来源位置返回不同结果。应结合连接日志和目标网络判断。

目标约束：DNS 优化不是堆叠更多公共服务器，而是减少不必要的交叉依赖。内核启动需要解析节点服务器域名，解析请求又配置为必须经过尚未连接的节点，就会形成启动循环。应保留能够在当前网络中完成基础解析的路径，再逐步调整业务域名的查询方式。

字段对照：地址族与按域名查询

基础示例：下面是 Xray 内置 DNS 的局部写法，用于说明查询服务器与地址族选择。地址仅作配置结构示例，使用前需要确认当前网络可达、符合自己的解析需求。该片段不会自动把系统 DNS 重定向到内核，也没有定义查询流量通过哪个出站发送，不能单独实现整个设备的解析接管。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ]
  }
}

查询范围：服务器对象中的 domains 用于指定优先交给该服务器的域名集合，但不能仅据此断言其他服务器永远不会接到相关查询。回退机制、预期地址条件以及内核实现都会影响后续尝试。需要严格限制查询去向时，应进一步查阅当前内核的回退字段，并通过日志或本机网络观察验证。

地址族选择：网络具备可用的双栈连接时，不应仅为减少日志就永久限制地址族。暂时使用 UseIPv4 可以帮助判断故障是否与另一地址族有关，但测试成功后仍应检查系统路由、出口能力与服务端监听。内置 DNS 的选择只约束相关解析动作，应用直接提供地址时不会因此被转换。

缓存与回退：让测试结果可解释

缓存干扰：调整解析服务器后，系统、浏览器和客户端都可能继续使用缓存。先关闭旧连接，再根据实际涉及的组件刷新缓存或重启应用，而不是每次都重启整台设备。记录修改前后的返回地址与出口标签，才能区分配置确实生效和刚好使用了仍可连接的旧地址。

回退取舍：设置备用服务器可以改善单一路径失效时的可用性，但也会让解析行为更复杂。若每个服务器都超时，问题可能在查询出站或当前网络，而不在域名本身。若只有特定域名异常，应先核对域名集合匹配和返回地址，避免扩大为全局 DNS 更换，连带改变其他正常应用。

本地网络：打印设备、局域网主机与内部服务可能依赖路由器解析或本地搜索域。把全部查询发送到公共服务器后，这些名称可能失效。应为明确的内部域名保留本地解析路径，并核对访问地址的路由是否仍为直连；只补一条解析记录，却让对应私有地址进入远端出口，同样不能正常访问。

验证闭环：先在系统代理模式确认一个普通域名能解析并连接，再启用 TUN，最后评估 FakeDNS。每一步都保留可恢复的设置，不同时修改地址族、查询服务器和路由策略。若涉及证书名称不匹配，应转查TLS 握手与 SNI 定位方法，不要用关闭证书验证来掩盖解析或配置错误。

TUN 模式

接管范围：虚拟网卡不等于出口

TUN 定位：虚拟网卡将符合系统路由的网络流量交给用户态处理，适用于不遵循系统代理的应用。它解决的是流量进入客户端的方式，不会自动修复节点认证、服务端不可达或错误的路由规则。启用后仍然需要可用出口、正确的 DNS 路径以及不会把自身连接反复接管的系统路由。

模式区别：系统代理依赖应用读取系统代理设置，TUN 则在更接近网络层的位置接收数据包。两者可以在某些环境中并存，但初次排错时建议先只验证一种接管方式。浏览器正常而其他应用异常，可能只是后者没有使用系统代理；不能据此推断所有节点或内核都需要更换。

内核分工：桌面客户端的 TUN 功能可能由独立组件与代理内核协作实现，配置字段和权限要求由实际组合决定。不能把网上某份包含 tun 字段的配置直接塞进任意 Xray 配置中。应优先通过 v2rayN 提供的 TUN 设置入口操作，并查看启动日志确认相关组件真正运行。

启用流程：从基线到系统路由

连接基线：开启前先在系统代理模式验证一个已知可用的服务器，记录选中项、路由模式和 DNS 设置。然后退出其他可能修改路由或创建虚拟网卡的网络工具，避免多个组件争夺默认路由。不要同时启用 FakeDNS，先让普通解析和 TUN 接管形成独立、可解释的测试结果。

权限准备：Windows 上创建网卡或写入路由可能需要提升权限；macOS 与 Linux 也可能要求系统授权或相应服务权限。具体要求以客户端提示为准。若开关立即回落，应检查权限拒绝、组件启动失败和网卡创建错误，而不是反复点击开关。授权成功后还要确认路由确实建立。

移动端行为：v2rayNG 与 v2flyNG 在 Android 上通常通过系统 VPN 接口接管流量，首次启动时需要确认系统授权。这个入口与桌面 TUN 的实现细节不同，不能逐项照抄桌面设置。系统中其他占用同类接口的应用可能与其互斥，切换前应确认当前负责接管流量的是哪一个客户端。

接管验证：先测试之前不遵循系统代理的应用，再观察客户端连接记录是否出现对应目标。随后检查普通网页、局域网服务和订阅更新是否仍可用。单看网卡存在或图标显示已连接不够，因为网卡创建成功后，DNS 路由、出口路由与应用访问仍可能分别失败。

常见冲突：绕行、回环与数据包尺寸

自身绕行：代理组件连接服务器的流量必须有正确的绕行方式，否则可能再次进入虚拟网卡形成循环。客户端通常会生成相关路由，但手动改默认路由、接口绑定或自定义出站后可能破坏它。若日志持续重复建立同类连接且访问全面异常，应先停用新增配置，恢复客户端默认接管策略。

局域网访问：远程桌面、打印设备或内部地址失效时，先确认私有网段是否被接管，再检查路由是否将其送往直连出站。某些网络中的内部资源使用的并非标准私有地址，因此仅添加私有网段规则未必足够。应依据实际网段添加最小范围的例外，避免为了一个资源绕过整段不相关流量。

数据包尺寸：部分站点能打开但大文件或长连接卡住时，可以把 MTU 作为后续排查方向，而不是第一步就随意修改。先排除 DNS、协议和服务器问题，再按客户端可用入口做单变量测试，并保存原值。不同网络封装开销不同，没有适用于所有设备与链路的固定最优数值。

稳定性判断：休眠唤醒、切换无线网络和更换默认网卡后都应重新验证，因为旧接口与旧路由可能已失效。确认基础接管稳定后，再加入域名分流或 FakeDNS。常见概念差异可查阅FAQ；首次连接尚未完成时，应回到教程主线，避免在多个未验证层次之间来回修改。

FakeDNS

映射原理：用虚假地址保留域名

工作机制：FakeDNS 不直接返回目标服务器的真实地址，而是为域名分配一个映射地址。应用随后连接该地址时，配套处理组件根据映射表找回原域名，再交给路由或出站处理。它的价值是让只提交地址的流量仍能保留域名关联，而不是让远端网络出现一台拥有该地址的真实服务器。

适用条件：应用的查询必须进入指定的 FakeDNS 解析路径，后续连接也必须由认识这份映射的组件接收。只完成其中一半就会失败：系统得到虚假地址后若直接发到普通网络，该地址通常无法抵达真正目标；反过来，连接被接管但查询绕开映射服务，也无法凭空恢复关联。

路由收益：域名规则比较完整、应用又倾向于先解析再连接时，映射有助于维持域名级分流的一致性。它不能修补错误的规则顺序，也不能替代真实 DNS 的所有用途。应用如果直接访问固定地址，或者使用自己的加密解析通道，仍可能不经过这套映射流程。

配置关系：地址池、解析入口与嗅探

结构示例：下面片段展示 Xray 中地址池与 DNS 服务的关联写法。198.18.0.0/15 属于基准测试用途的地址空间，不是某个远端服务的真实地址。配置前应核对它是否与现有网络规划、其他虚拟网卡或测试环境冲突；若存在重叠，应先处理地址规划，而不是直接启用。

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

入站配合：负责接收这些连接的入站还需要能够恢复映射。下面仅展示可合并到相应入站对象中的嗅探字段，并没有定义入站协议、监听地址或端口。图形客户端可能已经生成了等价设置，应先查看实际配置，避免重复添加。不同接管组件管理的映射不能仅靠复制字段互相共享。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns", "http", "tls"]
  }
}

内核差异：上述写法用于解释 Xray 的相关配置关系，不能不经确认就迁移到 v2flyNG 或其他 TUN 组件。客户端若提供 FakeDNS 开关，应优先使用该入口，并核对其运行内核。没有明确支持信息时，保留普通 DNS 路径比强行拼接不同实现的字段更容易维护。

兼容性与退回普通解析

应用兼容：需要展示真实解析地址、执行地址归属检查、发现局域网设备或直接把解析结果交给另一进程的应用，可能不适合全局使用映射。部分程序还会缓存虚假地址，在客户端停止后继续尝试连接。遇到单个应用异常时，先确认它的查询与连接是否经过同一处理路径，再决定排除范围。

缓存寿命：映射表与应用缓存的生命周期不一致，是重启后间歇失败的常见来源。内核重启后旧映射可能不再存在，而应用仍持有先前返回的地址。此时只更换节点不一定有效，应关闭旧连接、刷新相关应用解析缓存，再重新发起查询，以建立新的映射关系。

验证方法：开启后，系统或应用查询目标域名时应出现映射池中的地址，同时客户端应能将连接关联回原域名并选择预期出站。只看到保留地址并不能证明配置完整；还需要确认业务连接成功，局域网访问正常，而且未使用映射的真实地址流量仍按原有规则处理。

停用顺序：先关闭相关 FakeDNS 配置并恢复普通解析服务器，再刷新系统与应用缓存，关闭仍使用旧映射的连接。若只是关闭虚拟网卡，却保留应用缓存中的映射地址，访问可能继续失败。恢复后应重新检查 DNS 返回值，确认不再把地址池中的结果当作真实远端地址使用。

选型判断：只有普通 DNS 与 TUN 已经稳定、且确实存在域名信息丢失问题时，才值得增加这一层。若主要故障是订阅失效、服务器超时或认证失败，FakeDNS 不会改善对应环节。关于映射与使用场景的展开说明，可继续阅读FakeDNS 原理与 v2rayN 开启时机，并保留未启用时的配置作为对照。

多订阅管理

维护模型：来源隔离与统一命名

来源隔离：多个订阅首先应保持更新边界清晰，每个来源使用独立分组，人工维护的配置再单独存放。不要为了让列表看起来整齐，就把所有服务器复制到一个无法追溯来源的大分组。出现失效、格式变化或更新覆盖时，明确来源可以缩小问题范围，也方便只停用受影响部分。

命名约定：建议将来源简称、用途和维护方式写进分组名称或备注，但不要包含账户信息与完整订阅地址。节点备注可以保留来源提供的文本，必要时另设本地识别标记。手工重命名是否会被更新保留取决于客户端实现，长期依赖备注的过滤规则应定期复查，不能视为永久不变的标识。

选择边界：订阅增加并不会自动形成负载均衡、故障切换或应用分流。普通服务器列表仍通常只有一个当前激活项，多个来源只是提供更多配置候选。若需要不同流量使用不同出站，应明确配置路由与出口关系；不要把分组顺序、列表排序误解为内核选择出口的优先级。

更新节奏：降低联动故障

手动验证：新增来源时先单独导入和更新，检查协议类型与内核支持，再建立一次实际连接。确认可用后才纳入定期更新。若立即与所有旧来源同时更新，一旦当前连接失效，就很难区分是新增内容改变了配置，还是原有来源也发生了变化，排查成本会明显增加。

自动间隔：更新频率应参考来源的配置变化节奏与服务要求，不是越频繁越可靠。过密请求可能增加无效更新，也可能触发来源端限制。客户端支持分组独立更新时，可按实际需要分别安排；只支持统一间隔时，应优先选择能够稳定维护的节奏，并保留手动更新入口处理临时变化。

代理依赖：使用代理更新能解决部分来源直连不可达的问题，但不要让所有来源都依赖同一个尚未验证的出口。当前节点失效时，代理更新也可能同步失败，看起来像全部订阅失效。应先检查更新请求使用的网络路径，再判断链接状态，必要时切到已知可用的配置后单独重试。

去重、迁移与备份边界

去重原则：名称相同不代表配置相同，地址相同也不代表认证与传输参数一致。删除重复项前，应比较协议、端口、用户标识、传输方式与安全字段。自动去重若只依据部分字段，可能误删本来用于不同接入方式的配置；不清楚判定条件时，先在副本中测试，再处理主要分组。

跨端迁移：v2rayN、v2rayNG 与 v2flyNG 的订阅解析、界面存储和自定义配置支持范围并不完全相同。迁移时应分别验证订阅能否解析、节点能否运行、路由与 DNS 是否重建。成功导入服务器列表，并不意味着桌面端的 TUN、系统代理或所有自定义规则也已同步到移动端。

备份内容：至少保存分组结构、必要的订阅信息、本地独立配置和规则设置，并放在受控位置。不要只备份临时生成的内核文件，因为它可能缺少界面侧的来源信息与更新设置。恢复前先确认备份对应哪个客户端及配置入口，避免把旧字段覆盖到结构不同的新环境。

变更记录：每次较大调整只记录必要的行为变化，例如某分组改为代理更新、某过滤条件放宽、某规则移到前面。无需保存敏感地址，也不应把含凭据的配置粘贴到公开笔记。故障出现时，能知道最后改了哪一层，通常比保存大量没有说明的配置副本更有帮助。

退役处理：来源不再使用时，先确认它没有被当前服务器、自动更新任务或自定义出口引用，再停用分组。观察其他来源独立工作正常后再删除，避免删除后留下无法解析的标签引用。若只是临时网络故障，应优先暂停更新并保留现有配置；关于订阅失效与解析问题，可结合常见问题和订阅分组章节逐项核对。

自定义出站

内核与生态：先确定配置归属

内核关系：Project V 是理解这类代理工具的生态背景，V2Fly 与 Xray 是需要区分的内核家族。图形客户端负责订阅、界面和配置生成，内核负责执行具体连接。两款客户端界面相似，不代表它们能接受同一份配置；同一客户端选择不同运行内核时，也应重新确认协议与字段支持。

Xray 配置：v2rayNG 采用 Xray 内核，v2flyNG 作为 V2Fly 内核备选；v2rayN 的实际行为应以当前运行组件为准。自定义出站之前，先查看日志中的启动信息与客户端设置，确认正在使用哪一套配置。开源属性说明代码可以被研究和维护，不代表配置可以脱离实现差异任意互换。

REALITY 边界：它涉及连接安全相关参数，需要与服务端提供的设置一致，不是一种本地分流开关。改出口标签、调整直连规则或增加本机 SOCKS 出站，都不能补齐错误的服务端名称、公钥等连接参数。涉及这类节点时，应保留原始配置，先确认基础连接再增加自定义链路。

出站定义：直连与阻断的最小结构

定义方式：出站对象用 tag 提供可被路由引用的标识，用 protocol 指定行为。下面展示 Xray 中直连与阻断出站的局部列表，其中标签只是示例，需要与前文路由片段对应。将它合并到已有配置时，不要覆盖原来的代理出站，更不要在尚未确认默认行为时改变整个列表顺序。

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

默认行为：这份片段没有远端代理出口，也没有完整路由。如果把它当成完整出站列表使用，未匹配请求可能默认走第一个直连出站。阻断出站也只有在被规则选中时才发挥作用。新增对象后应先核对生成配置与默认出口，再用一条明确、范围较小的规则测试标签引用是否正确。

本地上游：避免把连接送回自身

链式转发：有时需要把某类请求交给本机另一个受控的 SOCKS 服务。下面片段定义名为 local-upstream 的出站，连接回环地址的指定端口。使用条件是该端口确有兼容服务监听，而且不是当前客户端接收同一批流量的入站；没有上游服务时，这段定义本身不会产生可用出口。

{
  "tag": "local-upstream",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 10810
      }
    ]
  }
}

循环检查：本机入站如果也监听该地址与端口，转发可能重新进入自身，造成连接递归或快速失败。TUN 模式下还需确认上游进程的外连不会被重新接管形成另一种循环。应先独立验证上游，再让一条测试规则指向它，最后才扩大使用范围，不要一开始就接管所有流量。

能力核对：SOCKS 上游是否支持认证、域名传递和 UDP，需要分别确认。网页访问成功只能说明相关连接路径可用，不能证明所有类型的数据都能转发。遇到只有部分应用失败时，应检查请求类型与上游能力，而不是立刻复制更多代理字段，增加难以观察的嵌套层次。

生效检查：入口、语法与持久化

编辑入口：完整自定义配置模式与界面生成配置模式通常有不同的维护责任。前者可能需要自行定义入站、路由、DNS 和出站，后者则由客户端保留部分控制权。保存前先确认哪些字段会被覆盖，以及切换节点后自定义内容是否仍存在；不能以临时文件里出现过字段作为持久生效的依据。

错误分类：启动即失败时先检查 JSON 逗号、括号、字段类型与协议名称；成功启动但没有命中时检查路由标签；命中后连接失败再检查监听、认证与网络可达性。日志级别可在受控测试期间临时提高，完成定位后恢复常用级别，并避免把包含目标地址和认证信息的完整日志公开分享。

维护收口：每新增一层出站，都应写清输入来自哪里、输出交给谁、失败时如何回退。无法解释这三个问题时，优先保留客户端默认配置。安装与组件选择回到安装包页面核对，基础连接验证回到配置教程；稳定之后再按本手册逐层加入路由、解析和接管设置，避免把多个独立故障合并成一个不可复现的问题。