V2Ray 高级配置系统查阅

先区分订阅、配置与分组

订阅链接不是单个服务器，它更接近一份由服务端维护的配置清单。客户端更新订阅时，会读取清单并生成若干服务器条目；分组则是客户端本地用于归类这些条目的管理层。三者的生命周期不同：订阅可能定时更新，服务器名称和参数可能随之变化，而本地分组通常应保持稳定。理解这一点后，配置策略就会清晰：订阅负责接收来源变化，过滤规则负责选出所需条目，分组负责承载固定用途。不要依赖手工拖动几十个条目来维持顺序，因为下一次更新可能重新生成列表，使手工排序失去意义。

在 v2rayN 中，较稳妥的做法是先按来源建立订阅分组，例如“日常主订阅”“备用订阅”“测试订阅”，再为每个来源设置更新、过滤和别名。Android 端的 v2rayNG 更适合保持较少分组：移动屏幕空间有限，分组过细会增加切换成本。v2flyNG 的管理思路与 v2rayNG 接近，但内核体系不同，导入后仍应核对协议和传输参数是否被完整识别。客户端之间迁移时，应迁移订阅地址或标准配置，不要把某一客户端特有的显示顺序当成通用配置。

用正向过滤建立可预测列表

服务器过滤通常包含备注匹配、协议筛选、地址筛选和端口条件。推荐先写正向条件，也就是明确保留哪些条目，再补充少量排除条件。假设订阅备注中包含地区、用途和倍率信息，可以先保留名称中含有“常用”或明确地区标签的条目，再排除“到期”“维护”“测试”等不应参与日常选择的条目。正向条件越清楚，订阅提供方调整命名时越容易发现问题；如果只维护一长串排除词，新的异常标签可能在未被注意时进入可选列表。

过滤表达式应围绕订阅里真实存在的命名规律编写。常见正则表达式如 ^(?!.*(?:维护|到期)).*(?:常用|备用)，表示排除包含“维护”或“到期”的条目，同时只保留含“常用”或“备用”的名称。表达式中的全角标点、空格和大小写都可能影响结果。首次编写时，先复制几个真实备注到本地文本中逐个对照，再放进客户端。不要直接从复杂表达式开始；两段简单规则往往比一段难以维护的组合规则更可靠。

{
  "group": "日常主订阅",
  "include": "(常用|备用)",
  "exclude": "(维护|到期|测试)",
  "updateIntervalHours": 24
}

更新前后分别保留什么

执行订阅更新前，应先确认当前有一条可连接配置，并记下它所属的订阅和备注。更新后先检查条目数量是否出现异常变化，再检查当前选中项是否仍存在。数量突然归零时，优先怀疑订阅访问、过滤条件或分组选择，而不是立即修改协议参数；数量明显减少时，先临时关闭过滤查看原始结果。如果原始条目完整，问题就在本地筛选；如果原始结果也不完整，则需要确认订阅本身返回的内容。

更新动作还涉及覆盖策略。订阅生成的条目原则上由订阅维护，不适合直接在其中长期修改地址、端口、用户标识或传输层参数，因为后续更新可能覆盖这些变更。确实需要实验时，复制一份条目到本地测试分组，并在名称前加“本地测试”以便区分。测试成功后，如果变更属于订阅侧配置，应回到订阅来源修正；如果只是本机路由或 DNS 需求，则应放在客户端的全局设置或路由规则中，而不是逐个修改服务器。

处理空列表与重复条目

订阅导入后没有服务器时，按固定顺序检查：先确认当前查看的是正确分组，再手动更新一次，然后关闭全部包含和排除条件，最后查看客户端日志中是否存在解析错误。若关闭过滤后恢复，逐条启用规则即可找到冲突项。若日志显示内容格式无法识别，应确认订阅返回的是客户端支持的配置格式，而不是登录页面、提示文本或过期响应。相关基础问题可继续查看帮助中心。

重复条目通常来自同一订阅被导入两次、两个订阅包含相同服务器，或更新时选择了追加而非覆盖。处理前不要仅按备注判断，因为同名条目可能拥有不同地址或传输参数。应对照地址、端口、协议、传输方式和安全层配置；完全相同的条目只保留由稳定订阅管理的一份，参数不同的同名条目则重新命名以标注来源。最终目标不是让列表数量最多，而是让每个条目都能追溯来源、明确用途，并在更新后保持可理解。

路由判断发生在连接建立之前

路由规则的任务不是改变服务器参数，而是为每一条目标连接选择出站。应用发起访问后，内核会读取可用信息，包括目标域名、目标地址、端口、网络类型和进程来源，再按规则顺序寻找匹配项。匹配成功后，连接被交给指定出站，例如代理、直连或阻断。没有任何规则命中时，则进入最终默认出站。因此，排查路由问题时应先问“这条连接被哪条规则接住”，而不是只看当前选中了哪个服务器。

域名和地址并非总能同时获得。某些连接在进入内核时携带域名，规则可以直接按域名匹配；另一些连接只提供已经解析出的地址，此时域名规则可能无法生效。开启域名嗅探后，内核可从部分协议流量中恢复目标域名，但嗅探不是所有场景都可靠，也不应替代正确的 DNS 设计。稳定的路由配置应同时考虑域名规则和地址规则，并明确哪些规则依赖嗅探。

规则顺序决定最终结果

大多数客户端采用从上到下匹配，第一条命中规则立即决定出站。应把范围最窄、优先级最高的规则放在前面，把范围宽的兜底规则放在后面。例如，某个内部域名必须直连，就应放在宽泛的代理域名规则之前；局域网地址直连规则应放在默认代理之前；最终才是覆盖其余连接的兜底。若顺序相反，宽泛规则会提前命中，后续精确规则即使写得正确也不会执行。

一份便于维护的规则集通常按“特殊阻断、指定直连、指定代理、地址范围、默认行为”排列。阻断规则要保持克制，只写明确不需要连接的目标；直连规则包含局域网、客户端更新所需目标和确定应由本地网络访问的服务；指定代理规则用于确有要求的域名或应用；地址范围规则处理只携带地址的连接；默认行为则负责未分类流量。规则层次清楚后，日志中的出站标签也更容易解释。

Xray 路由结构示例

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

理解 domainStrategy，而不是机械套值

domainStrategy 决定域名在路由阶段何时解析为地址。使用 AsIs 时，路由优先按原始域名判断，不主动为了地址规则执行解析；IPIfNonMatch 会先尝试域名规则，在没有匹配时解析地址并继续匹配地址规则；IPOnDemand 则可能在遇到需要地址信息的规则时更早触发解析。没有统一适合所有网络的值。域名规则占主导、希望减少额外解析时，可以从 AsIs 开始；需要依赖地址库完成分流时，IPIfNonMatch 通常更容易理解。

路由阶段的解析还会受到 DNS 模块影响。如果 DNS 查询本身走错出站，路由就可能得到不符合预期的地址，继而匹配到另一条规则。修改 domainStrategy 后出现“同一域名偶尔走不同出口”，应同时检查 DNS 服务器选择、缓存和域名规则命中情况。路由与 DNS 是前后相接的两个系统，不适合分开盲调。

按端口、网络和应用缩小范围

端口条件适合处理明确服务，例如只让某个出站承担特定 TCP 端口，但不应把常见端口当作域名分类的替代品。大量服务共享 443 端口，仅按端口无法区分目标。网络条件可用来区分 TCP 与 UDP，适合在某条出站不支持 UDP 或需要单独处理实时通信时使用。应用条件则依赖客户端能力：v2rayNG 的分应用代理从 Android 应用维度决定哪些程序进入 VPN；进入内核后的连接仍可继续使用域名、地址和端口路由。

分应用代理的包含模式与排除模式只能围绕一个清晰目标选择。设备上只有少数应用需要进入客户端时，使用包含模式更便于控制；大部分应用都需要进入、仅少量本地应用例外时，排除模式更省维护。应用更新或更换包名后，旧规则可能不再匹配，因此系统升级后若某个应用突然改变路径，应先核对应用选择列表，而不是直接重写域名规则。

用日志验证命中，而不是只看网页结果

验证路由时，先清空容易混淆的后台连接，再打开客户端日志，随后只访问一个测试目标。重点观察目标域名或地址、匹配规则和最终出站标签。如果日志只显示地址，可检查 DNS 和嗅探设置；如果出站标签正确但访问失败，则问题更可能位于目标服务器、选中节点、传输参数或本地网络。若标签错误，将对应规则临时移动到最前方测试，确认规则内容本身能否匹配，再恢复合理顺序。

路由规则修改后应重启连接，使新配置完整加载。浏览器可能复用既有连接，也可能保留 DNS 缓存，因此仅刷新页面并不足以验证变化。更稳妥的流程是断开客户端、关闭测试应用的后台进程、重新连接，再发起一次新访问。需要系统化排查“显示已连接但无法访问”的情况，可参考代理端口、路由模式与 DNS 逐项排查清单。

先画清解析链路

DNS 故障之所以难排查，通常是因为系统 DNS、客户端 DNS、浏览器加密 DNS和远程解析同时存在。应用提交域名后，查询可能先被操作系统处理，也可能被 TUN 接管；浏览器若启用独立的加密 DNS，又可能绕过客户端设定。内核得到查询后，还要按域名规则选择 DNS 服务器，并决定查询请求走直连还是代理。最终返回的地址可能进入缓存，并交给路由模块继续匹配。任何一层改变，都可能表现为“域名打不开但地址能通”或“同一域名结果不稳定”。

优化的第一步不是堆叠更多 DNS 地址，而是确定唯一主路径。普通系统代理模式下，可让客户端负责需要代理的域名解析，同时保留系统解析处理本地资源；TUN 模式下，则应让进入虚拟网卡的查询尽量由内核统一接管。测试期间可以暂时关闭浏览器独立 DNS，避免它形成平行路径。等客户端链路确认正常后，再决定是否恢复浏览器设置，并验证其流量是否按预期进入路由。

本地 DNS 与远程 DNS 的职责

本地 DNS 适合解析局域网名称、企业内部域名以及明确应由当前网络回答的目标。远程 DNS 适合由代理出站承载的域名查询，使解析位置与访问出口保持一致。两者不等于“一快一慢”的简单选择，而是管辖范围不同。将内部域名交给远程服务器，通常得不到正确地址；将需要与代理出口一致的域名始终交给本地服务器，也可能得到不适合当前出站的结果。

配置时可按域名集合指定服务器，并保留一个清晰的默认解析器。若客户端支持 DoH，可以使用类似 https://1.1.1.1/dns-query 的 HTTPS 端点；若使用普通 UDP DNS，应明确请求是否经过代理出站。DoH 只是传输形式，不自动保证路由正确。端点域名本身也需要首次解析，因此在严格环境中可以配合明确的服务器地址或引导解析策略，避免形成“解析 DNS 服务器域名还要先访问同一个 DNS 服务器”的循环依赖。

按域名范围选择 DNS 服务器

{
  "dns": {
    "hosts": {
      "router.internal.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal.example"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

queryStrategy 与地址族选择

queryStrategy 控制查询 IPv4、IPv6 或同时查询。选择 UseIP 时通常允许两类地址，具体返回仍取决于服务器和网络；只用 IPv4 可以减少在 IPv6 路径不可用时的等待；只用 IPv6 则要求本地网络、代理出站和目标服务均具备完整支持。不要仅因为日志出现 IPv6 地址就立刻禁用它，应先判断失败是否真的发生在 IPv6 连接阶段。稳定网络可保留双栈，不完整的网络则应选择与实际连通能力一致的地址族。

地址族问题常表现为首次打开较慢、稍后又恢复，或同一目标在不同应用中表现不同。原因可能是应用采用不同的地址选择算法，也可能是其中一个地址族先失败后回退。检查时应分别观察 A 与 AAAA 结果，并在客户端日志中确认最终尝试的目标地址。只修改 DNS 返回类型而不看出站能力，可能把原本可用的另一类地址一并排除。

缓存、Fallback 与污染式误判

DNS 缓存能减少重复查询，但也会延长错误结果的影响。修改服务器或分流规则后，应断开并重连客户端，必要时重启测试应用，使旧缓存退出。若系统仍保留解析结果，可以等待记录过期或使用系统提供的缓存刷新方式。不要连续更换多个 DNS 后立即比较，因为此时浏览器、系统和客户端可能各自持有不同阶段的结果，观察到的并不是单一配置效果。

Fallback 机制用于首选服务器不适合或结果满足特定条件时转向备用解析器。它需要明确的判断条件，否则多个服务器可能同时返回不同结果，增加理解难度。对于内部域名，可通过 skipFallback 防止查询泄露到不认识内部命名的服务器；对于普通域名，应根据域名集合或地址范围设计回退，而不是简单并列多个服务器后期待客户端自动选择“最好”的答案。配置越复杂，越需要从日志确认实际使用了哪个解析器。

远程 DNS 失败的排查顺序

远程 DNS 无响应时，先直接检查端点能否建立连接，再看其请求走的是代理还是直连出站。若端点使用域名，确认引导解析能够得到地址；若使用 HTTPS，检查设备系统时间是否正确，因为时间偏差会影响 TLS 建连。随后检查路由规则是否把 DNS 端点错误送入阻断或不支持的自定义出站。最后再检查客户端日志中的响应格式和超时信息。按这一顺序可以区分“端点不可达”“路由错误”和“解析结果不适用”。

Android 上启用 VPN 模式后，还要留意系统私人 DNS 设置。系统私人 DNS、浏览器独立 DNS 和 v2rayNG 远程 DNS 若同时运行，查询路径可能与预期不同。排错时先保留 v2rayNG 的单一路径，确认域名解析和访问都稳定，再逐项恢复系统功能。桌面端 v2rayN 则需要区分系统代理与 TUN：系统代理不一定接管所有程序的 DNS，TUN 才更接近全局网络层接管。两种模式不能用完全相同的观察方式判断。

TUN 与系统代理的工作位置不同

系统代理依赖应用主动读取操作系统的代理设置，适合浏览器和遵循系统网络配置的软件。TUN 模式则创建虚拟网络接口，在更低的网络层接收流量，因此能够覆盖不支持 HTTP 或 SOCKS 代理设置的程序。它的覆盖范围更广，也意味着需要处理更多细节：路由表、DNS 接管、UDP、地址族、局域网访问和其他虚拟网络软件都可能参与。把 TUN 理解为“更强的开关”并不准确，它是一套不同的流量入口。

选择模式时应依据应用需求。日常网页和明确支持系统代理的软件可以先使用系统代理，配置简单、故障面较小；当某个程序忽略系统代理、需要处理 UDP，或希望统一接管更多应用时，再启用 TUN。不要在基础连接尚未确认时直接叠加 TUN。先用普通代理模式验证服务器、协议和订阅均正常，再切换入口，才能把新增问题限定在 TUN、DNS 或路由表范围内。

启用前的系统准备

桌面端 v2rayN 启用 TUN 时，通常需要系统允许创建虚拟网卡并修改路由。权限不足可能导致开关看似启用但接口未正确建立。应观察客户端日志是否完成接口创建、地址分配和路由写入，而不是只看按钮状态。安全软件、防火墙以及其他虚拟网卡工具可能拦截驱动或改变路由优先级。首次测试时，关闭不必要的同类网络工具，保留单一变量，确认 v2rayN 能独立运行。

Android 的 v2rayNG 使用系统 VPN 接口实现接管，系统会显示 VPN 状态。此时分应用代理、始终开启的 VPN、系统私人 DNS 和省电策略都可能影响结果。若系统同时指定另一项 VPN 服务，通常无法并行占用同一接口。切换客户端前应先断开当前连接，等待状态完全释放，再启动新的连接。后台受限会导致客户端被系统暂停，因此需要按设备的电池管理规则允许其稳定运行。

栈类型、MTU 与 UDP

TUN 实现可能提供不同网络栈选项。系统栈更贴近操作系统行为，兼容性通常较好；用户态栈把更多网络处理放在客户端内部，便于跨平台保持一致。具体名称会随客户端界面不同，但选择原则相同：先使用客户端推荐的默认栈，只有在日志明确指向兼容问题、UDP 异常或特定应用失败时再切换。切换后重新建立连接，并对同一目标重复测试。

MTU 表示网络接口一次承载的数据大小。值过大时，某些路径上的数据包可能需要分片或被丢弃，表现为小页面能打开、大内容卡住、上传失败或连接建立后无数据；值过小则增加额外开销。排查时可以从系统或客户端默认值开始，遇到疑似分片问题再小幅降低，并记录每次变化。不要直接套用极端数值，因为不同网络、传输方式和封装层的有效上限不同。

UDP 需要出站和服务器配置共同支持。TUN 接收到 UDP 不代表远端一定能够转发。如果网页正常而实时通信、语音或部分域名解析失败，应查看日志中 UDP 是否进入正确出站，以及当前服务器配置是否允许。为了定位，可临时让 DNS 改用基于 HTTPS 的查询，区分普通 UDP DNS 故障与所有 UDP 流量故障；随后仍应回到真实使用场景验证，而不是把临时替代方案当作问题已经消失。

绕过局域网与防止路由回环

TUN 接管后，局域网打印机、路由器管理页和文件共享可能被错误送入代理。应在路由规则前部保留私有地址直连，并按需加入本地域名。常见私有地址集合可由内核的 geoip:private 处理，但企业网络可能使用额外地址段，仍需根据实际网络补充。验证时分别访问网关地址、局域网设备地址和一个内部域名，确认地址直连与内部 DNS 都正常。

路由回环发生在客户端访问代理服务器或 DNS 端点的流量又被 TUN 重新接管，并反复送回自身。客户端通常会自动排除自身进程或服务器地址，但自定义出站、链式代理和特殊网络环境仍可能打破这一保护。典型表现是连接后立即失去网络、日志重复出现同一目标，或服务器连接不断重建。应确保代理服务器地址、必要的引导 DNS 和客户端自身通信有明确可达路径，并避免默认规则把所有流量不加区分地送回同一入口。

TUN 场景中的基础路由框架

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

冲突诊断与恢复路径

启用 TUN 后完全无法访问时，先断开连接，确认系统网络恢复；若未恢复，退出客户端并检查虚拟网卡或系统路由是否仍残留。随后重新打开客户端但不启用 TUN，使用普通代理验证服务器。普通代理正常后，再关闭其他 VPN、虚拟机网络增强工具和可能改写路由的软件，重新启用 TUN。若此时恢复，说明是软件冲突；若仍失败，则查看接口创建、DNS 接管和默认路由写入日志。

只有部分应用失败时，不要重置全部配置。先判断失败应用是否被分应用规则包含，再看它使用 TCP、UDP 还是自带 DNS，然后检查对应连接的路由标签。网页能访问但应用登录失败，也可能是应用使用了不同域名或证书校验链路。通过一次只启动一个应用、过滤日志目标的方式，可以把问题缩小到具体连接。节点超时与连接后立即断开的排查顺序，可继续阅读v2rayNG 节点超时六环节排查。

FakeDNS 解决什么问题

部分应用会先自行完成 DNS 查询，再把目标地址交给系统。连接进入 TUN 时，内核看到的可能只剩地址，原始域名已经丢失，基于域名的路由规则因而无法匹配。FakeDNS 的思路是：客户端对受控查询返回一个虚拟地址，同时记录“域名与虚拟地址”的映射；应用随后连接该虚拟地址时，内核从映射中恢复原始域名，再按域名规则选择真实 DNS 和出站。它主要服务于域名信息保留，不是公共 DNS 的替代品。

这套机制依赖查询和后续连接都经过同一个客户端。如果应用绕过客户端执行独立解析，或连接没有进入 TUN，映射就无法建立或使用。浏览器加密 DNS、应用内置解析器和某些直连网络库都可能形成旁路。因此，启用 FakeDNS 前应先确保 DNS 接管链路清楚，并确认 TUN 基础功能正常。否则出现问题时，很难区分是映射、DNS 旁路还是虚拟网卡本身导致。

虚拟地址池不是可访问服务器

FakeDNS 返回的地址来自专用虚拟池，它只在客户端内部代表某个域名，并不是互联网上真实可访问的服务器。看到测试工具显示虚拟地址不表示解析错误；关键是后续连接是否被客户端接住并恢复域名。如果应用把虚拟地址保存到文件、长期缓存或分享给其他设备，该地址在客户端映射之外没有意义。因此，不适合把 FakeDNS 查询结果用于持久化配置、服务器白名单或局域网设备共享。

地址池需要避免与真实网络、局域网和其他虚拟接口发生冲突。客户端默认值通常已经考虑常见场景，除非日志显示路由冲突，不建议随意修改。若企业网络使用了特殊地址范围，或设备上还有容器、虚拟机与其他隧道，应检查路由表中是否存在重叠。冲突可能表现为某些真实地址被错误认为是虚拟映射，或者虚拟连接被另一张网卡接管。

FakeDNS 与 DNS 服务器组合示例

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

与嗅探和路由的配合

FakeDNS 与域名嗅探都能帮助内核获得域名，但路径不同。FakeDNS 在 DNS 查询阶段建立明确映射，适用于查询被完整接管的 TUN 流量；嗅探则尝试从后续协议内容中识别域名，可能用于没有经过 FakeDNS 的连接。两者可以配合，但不应把所有问题都交给嗅探。对于加密程度更高或协议内容不携带可识别域名的连接，嗅探未必成功，而 FakeDNS 映射更直接。

路由规则仍然按照既定顺序运行。恢复出域名后，精确域名规则、域名集合规则和默认规则依次匹配。若 FakeDNS 已成功恢复域名但流量仍走错出站，应检查规则顺序和出站标签，而不是继续调整地址池。日志中通常可以看到原始目标、恢复后的域名和最终出站；三者连起来看，才能判断问题发生在哪一步。

哪些场景应谨慎启用

局域网内部域名、设备发现、打印服务和依赖真实地址返回的应用需要谨慎处理。内部域名通常应交给本地 DNS 并直连，不应进入 FakeDNS；依赖 DNS 返回地址执行局域网扫描或访问控制的软件，也可能无法理解虚拟地址。可以通过域名规则让内部命名跳过 FakeDNS，直接使用局域网解析器。若应用必须得到真实地址才能工作，应为它设置分应用绕过或使用真实 DNS 结果。

服务器程序、开发调试工具和需要显示真实目标地址的网络分析任务，也不一定适合默认启用 FakeDNS。它们可能把虚拟地址记录到日志，使分析人员误认为目标服务器位于该地址。进行抓包或问题复现时，应在记录中明确 FakeDNS 是否开启，并同时保留域名映射日志。只有这样，虚拟地址才能被正确还原为实际目标。

缓存失配与应用异常

应用在 FakeDNS 关闭后仍持有旧虚拟地址，是常见的切换故障。此时客户端已经不再维护原映射，但应用继续连接旧地址，结果自然失败。切换 FakeDNS 状态后，应重启连接并关闭相关应用后台进程；必要时等待应用 DNS 缓存失效。反向切换也一样：刚启用时，如果应用继续使用之前缓存的真实地址，短时间内可能看不到 FakeDNS 效果。

某个应用启用 FakeDNS 后立即异常，而其他应用正常，优先将该应用临时排除以建立对照。若排除后恢复，查看它是否自带 DNS、是否长期缓存地址、是否依赖局域网发现，或是否在应用层校验实际地址。不要因为一个应用不兼容就删除所有域名路由；更合理的方式是为该应用选择真实解析路径，同时保留其他应用从域名映射中获益。

为每个来源定义角色

多订阅不是把链接全部导入同一列表。每个来源都应有明确角色：主订阅承担日常使用，备用订阅只在主来源异常时启用，测试订阅用于验证新协议或新传输参数。角色决定更新频率、过滤规则和是否参与自动选择。若三个来源的条目全部混合，出现失败时很难判断问题来自哪个订阅，也容易在名称相同的服务器之间误选。

命名建议包含用途而非个人信息，例如“主用｜日常”“备用｜手动更新”“测试｜临时”。在 v2rayN 中，可以利用订阅分组保持来源边界；在 v2rayNG 中，应控制分组数量，并用清晰别名减少移动端切换负担。v2flyNG 作为 Android 备选客户端时，也应使用相同的来源命名原则，但不要假设两个客户端会保留完全一致的本地分组结构。

自动更新需要失败保护

自动更新能及时接收来源变化，但也可能在订阅临时返回空内容或格式异常时影响现有列表。可靠流程应保留最近一次可用结果，并在新结果明显异常时停止覆盖。客户端是否具备这一行为需要以实际界面和日志为准；不能确认时，主订阅可按固定周期更新，备用和测试订阅则采用手动更新。这样既减少无意义请求，也避免所有来源在同一时刻发生变化。

更新计划可错开执行。例如主订阅每日检查，备用订阅在需要切换前手动检查，测试订阅仅在实验期间更新。更新后先观察条目数量和当前选中项，再进行批量测速或连接测试。测速只能说明测试时刻的可达性，不能替代协议参数核对；如果大量条目同时失败，更应先检查订阅格式、系统时间和本地网络，而不是逐个删除。

去重不能只看显示名称

两个订阅可能使用相同备注，但服务器地址、端口、用户标识、传输方式或安全设置不同。真正的重复需要综合比较关键连接参数。反过来，同一配置也可能在不同来源中使用不同名称。去重时应先按来源保留边界，再对确认为完全相同的条目选择一个稳定来源。不要将不同订阅生成的条目合并成无法追踪的本地副本，否则后续参数变化无法自动同步。

如果需要跨设备保持一致，最适合共享的是订阅链接和少量标准化配置，而不是完整客户端状态。桌面端的窗口布局、测速结果、当前选中项和 Android 分应用列表都属于设备本地信息，不应强求同步。可同步层包括订阅来源、标准协议参数和通用路由思路；设备层则分别维护系统代理、TUN、应用选择和本地 DNS。更完整的方式对比见订阅链接、二维码与导出配置对比。

二维码与导出文件的边界

二维码适合在自己的设备之间快速迁移单条配置。扫描后仍应核对协议、地址、端口、传输和安全字段是否完整，不要只看备注名称。二维码不适合承载长期变化的多订阅体系，因为内容一旦生成便不会自动更新。对于长期维护，订阅链接更合适；对于一次性迁移或离线保存少量测试配置，二维码更直接。

导出配置文件能够保存更多字段，但也可能包含当前设备特有路径、端口和本地规则。导入另一平台前应先阅读内容，移除不适用的本机设置，并避免将带有访问凭据的文件放到公开位置。迁移完成后，先在新设备建立单条连接基线，再恢复路由和 DNS。直接把桌面端全部高级设置一次性搬到 Android，会让权限、网络入口和应用选择差异同时进入排错范围。

建立变更记录与回退点

多订阅环境最需要的是简洁变更记录。记录不必复杂，只要包含日期、修改对象、旧状态、新状态和验证结果。例如“主订阅增加排除词”“备用订阅改为手动更新”“Android 仅导入主用来源”。当列表异常时，可以快速判断最近一次变化发生在哪里。配置内容涉及连接凭据时，记录只写变更类型，不复制完整敏感字段。

回退点应建立在“已验证可连接”的状态上。修改过滤规则前保留旧表达式，批量更新前记住当前可用条目，导入新配置前保留原分组。若更新后连接失败，先恢复选中项和过滤条件，再判断新订阅内容。不要一边回退订阅、一边更换 DNS 和 TUN 设置；同时回退多个层次虽然可能偶然恢复，却无法确认真实原因。

主备切换的验证流程

备用订阅只有在被定期验证时才真正具备备用价值。验证不需要长期保持连接，可在网络稳定时手动更新，选择一条配置进行连接测试，并确认基本 DNS 和路由能够工作。测试结束后切回主订阅，避免当前选中项无意留在测试来源。若主备使用不同协议或传输方式，应分别记录各自的必要系统条件，避免故障发生时才发现备用配置依赖尚未启用的功能。

主来源异常时，先判断是订阅更新失败还是现有服务器连接失败。订阅暂时无法更新并不表示已经导入的配置立即失效；可以保留现有列表继续测试。只有服务器连接也失败时，再切换备用来源。相反，如果订阅更新成功但列表为空，应先关闭过滤、查看原始内容，避免把本地筛选错误误判为来源故障。

出站是路由规则的执行目标

路由规则只负责判断，真正建立连接的是出站。最基础的配置通常包含代理出站、直连出站和阻断出站。代理出站承载当前服务器连接，直连出站使用本地网络访问目标，阻断出站拒绝不需要的连接。自定义出站是在此基础上加入额外出口，例如指定 SOCKS 上游、单独的直连策略或特定协议连接。每个出站应有唯一且稳定的 tag，路由通过这个标签引用它。

标签命名应表达功能，例如 proxy、direct、block、upstream-socks。不要用“线路一”“测试二”这类离开当前界面就失去语义的名称。修改标签时必须同步修改所有路由规则、DNS 出站引用和链式代理关系；如果只改一处，配置可能加载失败，也可能在未匹配时落入默认出口。

建立一个可审查的基础结构

自定义配置应先从三类基础出站开始，确认日志能显示各自标签，再加入额外上游。直连使用 freedom 协议，阻断使用 blackhole，代理出站则由当前客户端生成或订阅配置提供。直接编辑完整内核配置时，要注意客户端可能在连接时重新生成配置；如果界面提供自定义配置入口，应使用其支持的覆写或合并机制，避免修改临时文件后在下一次连接时丢失。

基础出站与 SOCKS 上游示例

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    },
    {
      "tag": "upstream-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081,
            "users": [
              {
                "user": "example-user",
                "pass": "your-password"
              }
            ]
          }
        ]
      }
    }
  ]
}

示例中的本地 SOCKS 服务必须真实运行在对应地址和端口，否则被路由到该出站的连接会直接失败。若上游不需要认证，应按内核支持格式移除用户字段，而不是保留空字符串。连接远程上游时，应确认其地址不会再次被同一出站接管形成回环。任何访问凭据都只保存在自己的受控配置中，排错截图和日志分享前应先移除相关字段。

链式代理的方向要明确

链式代理表示一个出站的底层连接通过另一个出站建立。它适合有明确网络拓扑需求的场景，但会增加延迟、故障点和日志复杂度。设计前先画出顺序：应用流量进入客户端，路由选择业务出站，业务出站再通过上游出口连接目标。链条中的每一层都必须独立可达，并且上游连接本身不能再次回到业务出站。

验证链式结构时，应先单独测试最外层上游，再加入内层连接。若上游是本机 SOCKS 服务，先用明确支持 SOCKS 的工具确认端口可用；若上游也是客户端内出站，先写一条只针对测试域名的精确路由。确认日志按预期经过两个标签后，再扩大匹配范围。直接把默认流量全部切到未验证链路，一旦失败会同时失去查询、更新和排错所需连接。

DNS 流量也要选择出口

自定义出站加入后，DNS 请求可能仍沿用原有路径。若目标访问走 upstream-socks，而远程 DNS 走直连，解析位置和访问出口可能不一致。是否需要一致取决于场景，但必须是明确设计，而不是偶然结果。可以为 DNS 端点添加精确路由，使其通过指定出站，也可以让内部 DNS 始终直连。修改后观察 DNS 端点连接和目标连接是否分别命中预期标签。

要防止 DNS 循环：如果上游出站的服务器地址是域名，而解析该域名的 DNS 又被路由到同一上游，就可能在上游尚未建立时形成依赖。解决方式包括为上游地址提供可靠的引导解析、使用明确可达的地址，或为其 DNS 查询设置独立直连路径。选择哪种方式取决于网络条件，核心是让建立上游所需的基础连接不依赖上游自身。

阻断出站与失败表现

阻断出站用于明确拒绝不需要的连接。它与“连接失败”在表面上可能相似，但日志应能显示流量命中了 block 标签。排查某目标无法访问时，先检查是否被阻断规则捕获，尤其是使用宽泛域名后缀或端口条件时。阻断规则应放在合适优先级，并限制在可解释范围内。范围过宽会使正常资源、登录流程或客户端更新请求一并被拒绝。

阻断方式可能是静默丢弃，也可能主动返回拒绝。不同应用对两者表现不同：静默丢弃常表现为等待超时，主动拒绝通常更快失败。选择方式时以减少无意义等待和保持应用兼容为原则。不要通过阻断大量未知目标来替代清晰的分应用和路由设计；规则越难解释，后续维护成本越高。

客户端生成配置与手工配置的边界

v2rayN、v2rayNG 和 v2flyNG 都会根据界面设置生成内核运行配置。手工示例用于理解字段关系，不代表所有客户端都允许直接粘贴完整 JSON。若客户端提供自定义配置导入，应先确认它要求完整配置、局部覆写还是单个出站片段。格式不匹配时，即使 JSON 语法正确，也可能因为缺少客户端所需结构而无法启动。

升级或切换客户端前，应记录哪些内容来自订阅，哪些内容来自客户端界面，哪些属于手工覆写。订阅服务器参数通常可以重新获取，复杂自定义出站和路由则需要单独备份。备份后可在文本中检查标签引用：每个 outboundTag 都应对应实际出站，每个链式引用都应有目标，每个 DNS 路由都应能在上游建立前完成必要解析。

从最小规则逐步上线

上线自定义出站时，先用一个专用测试域名绑定到新标签，保留其他流量原样。日志确认连接命中新出站、DNS 路径正确且没有回环后，再逐步增加域名集合或应用范围。每次扩大范围都记录修改内容，并保留可以快速删除的新规则。若失败，只回退最近一层，不重置已经验证的订阅、服务器和基础路由。

最终配置应能回答四个问题：每类流量由哪条规则匹配、规则选择哪个出站、该出站如何建立底层连接、建立它所需的 DNS 又走哪里。如果其中任何一步只能靠猜测，配置就还不适合长期运行。遇到复杂故障时，可先恢复 proxy、direct、block 三类基础结构，再逐个加入自定义出口。需要重新选择适合平台的客户端时，可查看选型指南和安装包页面。