v2rayN 配置进阶
订阅、路由与网络模式

订阅分组与服务器过滤

订阅地址是服务器信息的更新入口，订阅分组是客户端保存这些信息的管理容器，服务器条目才是连接时使用的具体参数。先分清这三个对象，再处理列表整理：改分组名称通常不会改变远端订阅内容，切换列表筛选也不会自动切换当前使用的服务器。排查时应分别记录分组来源、列表可见范围和当前活动条目，避免把管理界面的变化当成网络状态的变化。

先建立分组，再更新服务器

在 v2rayN 的订阅分组设置中，为每个来源单独建立分组，填入完整订阅地址并保存，然后执行该分组的更新操作。名称宜体现来源与用途，例如“工作订阅”“备用订阅”，不要依赖来源自动生成的节点名称识别归属。第一次更新先只处理一个分组，确认能取得条目、选择服务器并建立连接，再继续添加其他来源，这样出现错误时能明确定位到哪一次操作。

订阅链接可能携带访问凭据，应按账号信息管理。不要把完整地址放进截图、公开日志或共享笔记；需要描述故障时，只保留请求方式、错误类型和经过遮蔽的主机部分。复制地址后先检查两端空格、换行以及聊天软件附加的标点。若服务方提供了多个面向不同客户端的入口，应选择与当前客户端兼容的格式，而不是靠反复粘贴不同链接碰运气。

更新失败先阅读订阅更新日志。连接超时说明请求未在期限内完成，认证失败通常需要检查地址中的授权信息，响应成功但解析失败则可能拿到了登录页面或不兼容的数据格式。如果已有可用连接，可以尝试客户端提供的经代理更新方式；但首次导入时未必存在可用代理，不能把该选项当成必然可行的修复。原始响应含敏感信息时，不应直接公开上传。

过滤列表，不改写连接参数

服务器过滤适合减少候选范围，例如只查看名称包含某个地区词的条目，或排除不再使用的用途标签。先确认过滤作用于哪个分组、名称字段还是更多字段，再输入条件。普通关键词与正则表达式不是同一种语法：只有界面明确支持正则时才使用正则写法，否则括号、竖线等字符可能仅按字面匹配。过滤完成后，仍需手动确认当前活动服务器。

如果过滤项明确采用正则，可以用下面的表达式匹配两个名称关键词。它只是名称过滤示例，不表示这些名称对应的线路质量，也不决定网络流量的出口。名称由订阅提供方定义，大小写、空格和命名调整都可能影响匹配结果，因此应先观察实际条目，再逐步缩小条件。一次写得过严，容易让整个分组看起来像没有服务器。

(香港|新加坡)

出现空列表时，按“清除搜索词、取消额外过滤、切回全部分组、重新查看更新日志”的顺序处理。不要立刻删除订阅，因为空列表可能只是本地显示条件造成的。服务器过滤也不同于应用分流：它决定列表展示哪些服务器，路由规则才决定某个连接走哪个出站。即使列表只剩一个条目，已经建立的旧连接也可能仍然维持原有出口。

处理更新覆盖与本地修改

订阅更新可能替换来源管理的服务器条目。若直接在条目里改端口、传输参数或备注，应预期下次更新可能覆盖这些修改。需要长期保留的本地调整，宜复制到独立的手动管理分组，并在备注中写清来源与调整原因；这样既能继续接收原始订阅更新，也能识别手动副本何时需要同步。不要把手动副本误当成会持续自动更新的条目。

删除订阅分组前，先确认客户端是否会连带删除该组服务器，以及当前活动服务器是否属于此组。不同界面的删除行为可能不同，操作前应阅读确认提示。需要保留的条目先导出或复制，订阅地址另行安全备份；含地址的导出文件也属于敏感配置。恢复备份后，应重新核对分组启用状态、更新策略与当前服务器，而不只检查名称是否还在。

V2Ray 路由规则实战

路由是把已经进入内核的连接交给某个出站处理的过程，不负责让原本绕过客户端的应用自动进入代理。配置规则前，先确认目标应用确实使用了客户端的本地入口，或已被 TUN 接管。否则，即使规则语法完全正确，内核也看不到连接，日志里自然不会出现预期命中记录。先确认入口，再观察规则，最后检查出站，是比反复调整规则顺序更可靠的排查路径。

从上到下安排匹配顺序

Xray 与 V2Fly 的常见字段路由按顺序匹配，先命中的规则决定出站。通常把明确拒绝的目标、私有网络直连以及精确业务例外放在宽泛规则之前，再安排较大的域名集合，最后检查未命中时的默认行为。这里没有适合所有人的固定排序：若某个内部域名必须走专用代理，就应把该域名的精确规则放在可能覆盖它的直连集合前面。

下面是用于解释顺序的 Xray 路由片段，需要合并到完整配置中。它假定已经存在名称为 proxy、direct 和 block 的出站，并且可用的规则数据包含所引用的集合。标签是本地标识，不会因为写下这个名字就自动创建出站；如果客户端生成的标签不同，应以实际配置为准修改引用。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

这个片段没有写入通配兜底规则。对这里讨论的常见内核配置，未匹配连接通常交给出站列表中的第一个出站；客户端也可能通过生成额外规则实现自己的默认策略。因此“final → proxy”是策略示意，不是可以原样放进上述 JSON 的字段。验证默认行为时，应查看实际生成配置与运行日志，不应只凭界面的模式名称推断。

区分域名匹配与地址匹配

域名规则需要连接具备可用的域名信息。如果应用直接访问地址，或入口只提供目标地址，单独添加域名规则未必能命中。协议嗅探可以在部分连接中补充域名，但不是对所有加密流量都有效，也不应当作稳定恢复全部域名的保证。先看日志中目标表现为域名还是地址，再决定使用域名集合、地址范围，还是进一步检查 DNS 与入口传递的信息。

domainStrategy 控制路由匹配阶段何时尝试解析域名，不等于所有应用的 DNS 都被接管。AsIs 不为地址规则主动解析；IPIfNonMatch 可在域名规则未匹配时尝试解析，再进行地址匹配；IPOnDemand 会在规则需要地址时尝试解析。切换策略会改变查询次数与命中结果，应结合 DNS 配置测试，不能简单认为解析越积极越准确。

用单一目标验证规则

每次增加规则，选一个能够明确复现的目标，关闭旧连接后重新访问，再查看访问日志中的目标与出站标签。浏览器长连接、连接复用和应用缓存可能让旧连接继续使用修改前的路径。只刷新页面未必创建新连接；必要时退出对应应用再测试，同时保持其他设置不变。日志中应能把测试时间、目标以及出站对应起来，而不是只看到客户端处于运行状态。

若规则没有生效，依次检查是否有更早规则抢先命中、标签是否存在、数据集合是否加载、连接是否携带域名。若规则已经命中但访问失败，则转向出站和 DNS 排查，不要继续在同一层添加重复规则。规则数据更新也可能改变集合范围，更新后应抽查常用业务。维护时保留简短的规则用途说明，比堆积大量重叠例外更容易定位冲突。

DNS 配置与解析路径

DNS 排查首先要回答三个问题：谁发起查询、查询怎样到达解析器、解析结果由谁使用。应用可能自行查询，系统可能缓存结果，内核也可能为了路由或连接单独查询。这些路径可以同时存在，因此修改客户端中的 DNS 服务器，不一定会改变浏览器自己的加密解析，也不一定会刷新系统已有缓存。先绘出实际路径，再调整服务器，比只替换解析器地址更有意义。

区分系统解析与内核解析

系统代理模式主要改变遵循代理设置的应用连接路径，并不天然截获所有系统 DNS 请求。使用 SOCKS 时，目标域名由本地解析还是交给代理，也取决于应用实现与调用方式。TUN 配合 DNS 接管可以覆盖更多请求，但仍需检查路由、接管端口和应用独立解析设置。不能仅因 TUN 开关已打开，就断言系统中所有查询都采用同一条解析链路。

v2rayN 的内核 DNS、TUN 相关 DNS 与桌面系统 DNS 可能属于不同配置入口。操作前记录当前启用的运行模式和辅助组件，再确认所改字段由哪个组件读取。Android 的 v2rayNG 与 v2flyNG 还会受到 VPN 服务及应用选择设置影响。平台之间应迁移策略意图，而不是把桌面配置文本原样复制到移动端的任意输入框。

下面是 V2Fly 风格的内置 DNS 片段，Xray 的具体支持情况应按所用内核核对。它展示普通 UDP 解析器与查询策略的结构，不代表自动获得加密查询，也没有配置查询流量的出站路径。地址应根据当前网络可达性和管理要求选择，实际合并后仍须检查生成配置、路由与日志。

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53
      }
    ],
    "queryStrategy": "UseIP"
  }
}

按用途选择解析策略

对直连业务，解析结果应在本地出口可达；对代理业务，应考虑解析位置是否与出口网络一致。某些服务按解析器位置返回接入地址，解析成功仍可能产生连接不稳定。若使用按域名选择解析器的方案，应先写精确、可理解的范围，再扩展到规则集合。不要把“解析失败时回退”与“按路由分流”混为一谈，两者的触发条件和查询路径并不相同。

使用域名形式的加密 DNS 地址时，还要考虑解析器自身域名如何获得地址，这一步常称为引导解析。若它必须先经过尚未建立的代理，而代理服务器地址又依赖同一个解析器，就会形成启动依赖环。处理方法是明确引导解析路径，或使用客户端提供的独立启动解析设置。不要通过无限增加备用服务器来解决循环，新增服务器也可能被同样的依赖困住。

IPv4 与 IPv6 应分别验证。查询能返回两类地址，不表示两个地址族都具备可用出口；系统优先尝试的地址也可能与客户端预期不同。出现部分网站等待较久再打开、只有某些网络失败时，应检查 IPv6 路由与代理服务器的地址族支持。只返回 IPv4 可作为对照实验，但长期策略应结合网络能力确定，并记录调整是否影响其他应用。

用查询结果与连接结果交叉检查

下面的命令用于查看操作系统默认查询路径的返回结果，并不能单独证明代理内核用了哪个解析器。运行时记录响应服务器、地址族以及错误信息，再与客户端日志中的域名解析事件对照。如果内核没有发起对应查询，可能是命中了缓存，也可能应用已经提供了地址，应先确认原因再改配置。

nslookup example.com

缓存清理应分层进行：先重启目标应用，再按系统提供的方式清理系统解析缓存，最后重启相关内核。不要在同一轮测试中同时切换网络、改解析器、重启设备，否则难以知道是哪一项改变了结果。域名能解析但连接失败时，继续检查出站可达性、证书时间和目标端口；解析超时则检查查询路径与解析器可达性，两类故障不应使用同一套修复动作。

企业网络或局域网内的专用域名，通常需要内部解析器或搜索域支持。把全部查询统一送到公共解析器，可能使内部服务失去解析结果。应为内部域名保留明确路径，并测试短名称与完整域名的区别。公网连接正常而内部服务打不开时，也要检查是否仅仅丢失了搜索域，而不是急着修改代理服务器或全局路由策略。

TUN 模式与接管边界

TUN 通过虚拟网络接口把选定的网络流量交给用户态组件处理，适合不遵循系统代理设置的应用。它改变的是流量入口和路由范围，并不自动保证每个协议、每个目标都可达。进入 TUN 的连接仍需要经过解析、规则匹配和出站处理。判断是否应该启用 TUN，应从目标应用的代理能力出发，而不是把它当作所有连接问题的通用修复开关。

建立可恢复的启用顺序

启用前，先在普通系统代理模式下确认一个服务器能够工作，记录当前系统代理状态、DNS 设置和局域网访问情况。随后关闭可能冲突的其他网络接管软件，再按客户端要求授予管理员权限或网络扩展权限。第一次只开启 TUN 所需的基础选项，暂不叠加复杂 DNS、FakeDNS 与自定义出站。若一开始同时启用多项功能，出现断网时很难拆分依赖关系。

v2rayN 的 TUN 功能可能借助独立组件处理虚拟接口与路由，不能假定核心连接日志就是全部运行日志。应同时查看 TUN 组件是否启动、接口是否创建、默认路由是否按预期变化。v2rayNG 与 v2flyNG 在 Android 使用系统 VPN 授权建立接管入口，首次出现授权提示时应确认请求来自当前客户端；已有其他 VPN 服务运行时，还需先处理其占用关系。

防止回环并保留本地访问

代理服务器本身的连接不能再次被同一条代理路径反复接管，否则可能形成回环。客户端通常会通过路由排除、接口绑定或进程处理避免这一问题，但手动增加路由、自定义上游或套用旧配置后仍需验证。典型表现是启用 TUN 后已有服务器也无法连接、日志反复出现相似连接，或者请求持续超时。此时先关闭 TUN 恢复基线，不要继续添加代理链。

局域网访问还需要同时考虑网络层绕行和内核规则。路由表决定数据是否先进入虚拟接口，内核规则决定进入后使用哪个出站；只配置其中一层未必满足目标。测试路由器管理页、局域网打印设备和内部域名时，应分别记录地址访问与域名访问结果。如果地址正常而名称失败，重点转向内部 DNS；两者都失败，则检查私有网段路由及直连规则。

应用分流与目标分流也应分开理解。Android 的应用选择通常决定哪些应用进入 VPN，进入后的连接再由内核路由处理；桌面端能否按进程分流取决于实际组件能力。不要把域名规则当作进程隔离规则，也不要把某个平台的应用排除方式套用到另一个平台。需要业务隔离时，先确认入口层支持什么，再选择能被验证的实现方法。

覆盖 UDP、休眠与切网场景

网页访问成功只证明相关连接可用，不能代表 UDP 应用也正常。语音、实时通信和部分解析请求可能使用 UDP，支持情况还取决于服务器、传输方式和出站配置。测试时先确认目标协议，再看日志是否出现对应连接。如果只有 UDP 业务异常，应缩小到 UDP 处理与上游能力排查，不要因为浏览器可以打开网页就排除网络路径问题。

休眠恢复、无线网络切换和有线网络重新连接，可能改变默认网关、DNS 与接口优先级。启用 TUN 后应补测这些日常场景：先建立连接，再切换网络，观察组件能否恢复以及局域网是否仍可访问。若切换后失效，先重启 TUN 组件再验证；反复复现时记录接口与路由变化，而不是只记录“客户端掉线”这一宽泛现象。

回退时先关闭 TUN，再退出客户端，检查系统代理是否按预期恢复，最后验证普通网络与本地服务。不要直接删除不明虚拟接口或大范围重置网络，因为这可能影响其他正常软件。若退出后仍异常，按操作系统的网络设置逐项检查遗留 DNS、代理和路由。无法确认的系统项应先记录再修改，保留恢复依据。

FakeDNS 与域名映射

FakeDNS 不把真实目标地址直接返回给应用，而是从指定地址池分配一个合成地址，并在内部保存该地址与域名的对应关系。应用随后连接合成地址时，接管组件再恢复原域名，交给路由与出站处理。这种机制用于保留域名上下文，尤其适合透明接管场景；它不是公共 DNS 服务器，也不是实际业务服务器地址的替代来源。

先确认闭环，再考虑启用

启用条件是查询和后续连接必须落在能够共享映射关系的处理链中。若应用取得合成地址后绕过接管组件直连，地址就失去意义；若查询由一个组件生成，连接却交给另一个没有映射记录的组件，也可能失败。因此不能只在 DNS 列表里加入一个名称便认为配置完成，还需要确认地址池路由、入口接收以及域名恢复环节相互对应。

v2rayN 的 TUN 组件与 Xray、V2Fly 的 FakeDNS 不是可以任意混合的同一套设置。不同内核及辅助组件可能使用不同字段、地址池和映射生命周期。先核对当前流量实际由哪个组件处理，再选择对应机制。若客户端已有完整的相关预设，优先使用预设并检查生成结果；不要把另一种内核的字段直接粘贴进当前配置来补齐看似缺少的功能。

下面是 Xray 配置结构中的 FakeDNS 相关片段，只展示地址池和 DNS 选择。它不是独立可运行配置，还需要实际入口的域名恢复设置及合成地址的接管路径配合。示例中的地址段属于用于基准测试的地址空间，并非实际站点地址；如果当前网络已使用同一范围，应先处理冲突，而不是直接套用。

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

理解地址池与映射生命周期

ipPool 决定可分配地址的范围，poolSize 控制池的容量。池容量不是吞吐量指标，也不表示能够同时维持多少业务连接。应用可能长期缓存地址，内核重启则可能丢失映射；当应用继续拿旧合成地址发起连接时，新的处理进程未必知道它对应哪个域名。因此启用、停用或重启相关组件后，应让目标应用重新解析。

DNS 缓存与映射缓存的生命周期不一致，是常见的间歇性故障来源。表现可能是刚启用时可用，重启后少数应用失败，清理应用缓存后又恢复。排查时记录发生前是否切换模式、重启内核或恢复休眠。不要只增加地址池容量，因为容量调整并不能修复旧地址对应关系丢失的问题，反而可能让原有缓存更难直接对应。

某些应用需要真实地址来进行网络探测、区域判断或直接协议交互，也可能自行携带加密 DNS 绕过预期查询入口。出现这类兼容性问题时，应对特定域名或应用采用真实解析路径，并确保其连接也采用相匹配的路由。例外应尽量精确，先对一个目标验证，再扩展到相关域名集合，避免把大范围业务全部排除后失去原先的域名映射效果。

把解析、恢复与出站分段验证

第一步确认目标查询返回的是合成地址，并且地址位于预期池中；第二步确认连接该地址时，日志能够恢复对应域名；第三步才看域名命中了哪个规则与出站。返回合成地址只说明第一步完成，不代表后续链路正常。如果日志仅出现合成地址而没有域名，应检查接管入口与恢复设置，而不是立刻追加真实目标地址规则。

路由中存在地址规则时，要区分合成地址与真实解析地址。把合成地址误当成普通目标做地理或私有地址判断，会得到与业务意图无关的结果。设计规则时应明确哪些判断基于恢复后的域名，哪些需要真实解析。需要地址匹配的连接可能仍需执行真实查询，因此 FakeDNS 并不等于所有场景都可以完全跳过后续 DNS 处理。

停用 FakeDNS 时，先恢复正常解析配置，关闭相关地址池接管，再重启目标应用并处理残留缓存。若停用后应用仍尝试访问合成地址，说明缓存尚未更新；此时反复更换服务器通常没有帮助。恢复完成后，重新检查普通 DNS 与局域网业务。只有能稳定启用、明确验证并完整退出，才适合把该机制纳入日常配置。

多订阅管理与更新策略

多订阅管理解决的是来源隔离、更新节奏和可恢复性，不等于自动负载均衡。把多个来源导入同一个客户端后，默认情况下仍可能只使用一个活动服务器；其他条目只是候选。先明确哪些订阅用于日常业务、哪些用于备用、哪些仅保留历史记录，再安排分组与更新。目标是发生变化时能够说明原因，而不是让列表始终包含尽可能多的服务器。

按来源管理，按用途筛选

分组首先按来源划分，避免更新时混淆归属；用途通过备注、关键词或本地筛选表达。一个来源内可能同时包含多个用途条目，不宜为了每种用途重复导入同一链接。重复导入会增加更新请求，也会让相同参数出现在多个位置，切换时难以判断哪一份才是当前维护对象。确有独立管理需求时，应写清复制原因和后续同步方式。

不同来源中的相同名称不能作为去重依据。名称相同的条目可能具有不同地址、端口、协议与传输设置；同一连接参数也可能换了名称再次出现。需要整理重复项时，应结合实际参数和来源判断，并先保留备份。对订阅生成的条目直接大量删除，下一次更新又可能重新出现，因此优先使用显示过滤，或者在来源允许的情况下调整服务端订阅偏好。

每个来源至少记录用途、更新方式以及是否依赖现有代理连接即可，不必在普通笔记保存完整授权链接。账户到期、授权更换或套餐调整可能导致列表变化，客户端不能从名称自动判断这些业务状态。出现大量条目消失时，先查看该来源的响应和账号状态，再考虑恢复旧配置；恢复旧列表也不意味着已失效的远端服务会重新可用。

更新频率服从实际变化

自动更新间隔应根据来源变更频率和客户端使用习惯设置，不宜过于密集。远端出现临时错误时，持续重试可能触发请求限制，也会让日志难以阅读。第一次设置自动更新后，观察一轮完整流程，确认它在网络尚未就绪时如何处理失败，以及是否会影响当前服务器选择。客户端未运行或被系统限制后台时，计划任务也未必会按预想执行。

经代理更新和直接更新可作为两条不同的访问路径，但应明确各自依赖。若当前活动服务器来自待更新订阅，且该服务器已经失效，经代理更新也可能失败。可先切到另一个已验证的来源，再更新故障分组；如果直接路径可用，则单独尝试直接更新。不要一次对全部分组切换更新方式，否则无法判断问题属于某个来源还是共同网络路径。

更新前后记录服务器数量的变化可以辅助排查，但数量不是服务质量指标。更重要的是当前活动条目是否仍存在、参数是否改变、手动备注是否保留，以及关键业务能否继续访问。更新成功后先验证当前业务，再做列表清理。若客户端允许更新时保留选中条目，应实际检查保留行为，不能假定名称相同就必然对应同一服务器。

把测速、切换与业务验证分开

延迟测试、连接测试与实际业务访问测量的不是同一件事。一次测试可达，不代表长连接、UDP 或特定域名都可用；测试失败也可能与测试目标和解析路径有关。多订阅环境应按分组逐批测试，减少并发干扰，并用实际业务做最后确认。不要把一次排序结果直接当成长期选择规则，更不要把列表位置当作客户端已经自动切换的证据。

手动切换活动服务器后，旧连接可能继续使用之前的路径。验证备用方案时，应建立新的测试连接，并检查日志中的出站与目标。若配置了自定义路由或固定出站，某些业务可能不跟随主服务器切换，这属于策略设计结果，不一定是切换失效。应维护一份“哪些业务跟随主选择、哪些业务固定出口”的简短说明，避免故障期间误判。

备份应覆盖分组设置、手动条目和本地规则，并妥善限制访问。恢复时先导入基础配置，逐个验证来源，再恢复复杂规则，不要把很久以前的整份状态直接覆盖当前可用环境。需要停用某个来源时，可先关闭更新并移除活动引用，观察没有依赖后再删除。这样即使要回退，也能在明确的边界内恢复，而不是重新整理所有订阅。

自定义出站与配置回退

出站描述内核如何把连接送往下一段网络，路由则选择使用哪个出站。日常切换服务器通常由客户端生成对应出站；自定义出站适合需要固定出口、明确直连或拒绝策略，以及需要对接本地代理服务的场景。开始前先确认普通配置无法表达所需策略，再决定是否手动编辑。能够由界面稳定管理的设置，通常不必重复写入另一份自定义配置。

先确认谁拥有配置

v2rayN 可能在启动或切换服务器时重新生成运行配置，直接修改临时生成文件不一定能够保存。应通过客户端支持的自定义配置入口管理，并区分“完整配置”与“追加片段”的导入方式。完整配置需要提供全部必要入口和出站，片段则依赖合并规则；选错入口可能覆盖既有结构。编辑前保存当前可用设置，并确认恢复时需要导入哪一份文件。

Xray 与 V2Fly 都采用入口、路由、出站等概念，但协议支持和字段细节会有差异；TUN 辅助组件也可能使用另一种配置结构。文件同为 JSON，不代表可以跨组件互换。应先查看实际启动的内核，再核对字段归属。需要了解客户端与内核分工时，可阅读Project V、V2Fly 与 Xray 生态关系，避免按客户端名称猜测所有内部能力。

下面是 Xray 中两个常见出站的片段。freedom 用于直接连接目标，blackhole 用于丢弃连接；标签可供路由引用。它没有包含代理服务器出站，也不应替换完整出站列表。如果把直连放到列表首位而没有相应兜底策略，未命中规则的连接就可能采用直连，因此追加与排序必须一起检查。

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

通过标签连接规则与出站

标签应短小、唯一且能够解释用途。修改标签时，要同步查找路由、链式转发及其他引用位置；只改出站名称而未改引用，可能导致启动失败或运行时路由异常。新增一个出站后，先写一条精确域名规则进行测试，不要立即把宽泛集合交给它。这样可以确认标签引用、连接路径和日志表现都符合预期，再逐步扩大使用范围。

对接本地 SOCKS 服务时，先确认该服务确实监听在指定地址和端口，再添加对应出站。监听本机回环地址适用于同机调用，不应为了方便直接改为对所有网卡开放。若使用容器或不同网络命名空间，本机回环地址的含义也会变化。出现连接被拒绝时，优先检查监听进程与地址范围，而不是修改路由集合；超时则还要检查防火墙和路径可达性。

链式代理会引入额外依赖：前一跳不可达，后续出口就无法建立；某一跳不支持目标协议，整体也可能只在部分业务上失败。不要把多个订阅条目简单排列成数组便认为形成链路，数组顺序本身不是链式关系。具体转发机制要按内核支持配置，并检查是否产生自引用。需要认证的示例应在本地安全填写，不应把真实凭据放进公开配置说明。

按语法、引用和连接三层验收

第一层检查 JSON 语法，包括逗号、引号、括号与字段类型。第二层检查语义引用，包括标签是否存在、协议字段是否受支持、规则数据是否可加载。第三层才检查实际连接。语法通过只证明文件能够解析，不证明服务器可达或路由符合意图。客户端如果提供配置测试功能，应先执行测试再启动；失败时保留首条关键错误，避免被后续重复日志淹没。

日志级别应按排查需要临时调整。更详细的日志有助于定位连接路径，也可能记录访问目标和网络信息，应限制留存范围，完成后恢复日常级别。共享日志前去除订阅地址、用户标识和认证信息。若内核无法启动，先检查配置测试输出；若启动成功但局部连接失败，则用精确目标复现，不要在未定位前重装客户端或重写全部配置。

回退方案应在修改前准备：保存可用基线，记录本次新增字段和预期结果，明确如何恢复客户端自动生成模式。每完成一项变更，分别验证默认访问、精确规则、局域网和退出后的系统网络。若只有新规则失败，先撤销该规则；若内核整体无法启动，恢复整份基线。小范围回退能够保留已确认有效的配置，比一次性清空更容易继续排查。

系统升级、内核调整或客户端迁移后，应重新执行同样的验收流程。旧字段可能不再适用，默认值也可能发生变化；不要只因为文件还能加载就认定行为完全一致。保留简明的配置说明，写清每个自定义项解决的问题、依赖的组件及验证目标。当用途已经消失时，删除对应定制并重新测试，让长期维护的配置保持可解释、可恢复。