V2Ray 配置进阶手册

订阅分组与服务器过滤

把订阅来源、显示列表和活动节点分开

订阅分组是客户端管理服务器条目的容器，不等于路由分组，也不会自动让某类应用使用某个节点。订阅地址负责提供条目，分组负责组织条目，当前活动服务器才决定普通代理出站的连接目标。先分清这三层，才能避免“已经换了分组，出口却没变”的误判。切换列表之后，还要明确选择服务器，并确认客户端已经应用新的活动配置。

在 v2rayN 中打开订阅分组设置，为不同来源建立独立分组。名称建议写用途与来源简称，例如“日常访问”“备用连接”，不要直接粘贴完整订阅地址。添加地址后先保存，再对目标分组执行更新。首次更新完成时，检查服务器名称、协议类型和传输参数是否被识别。如果列表为空，先核对更新日志，不要连续重复添加同一地址制造多个空组。

过滤只控制条目范围，不证明连接质量

服务器过滤用于缩小可见或导入的条目范围，具体作用点取决于客户端提供的过滤选项。有的作用于当前显示列表，有的在订阅更新时筛选条目。修改之前先看字段说明，并保留未过滤的原始分组作为对照。地区、线路用途和倍率通常来自提供方命名，不是客户端独立测量的事实。名字带某个地区，也不能单凭名称确认最终出口所在地。

先使用普通关键词搜索，确认预期条目能被找到，再考虑正则表达式。只有明确标注支持正则的字段，才适合使用下面的表达式。它匹配名称包含“香港”或“新加坡”的条目；如果提供方使用其他名称，就需要调整文本。不要把这段直接填入仅支持普通文本的搜索框，否则竖线和括号可能被当成字面字符，结果反而为空。

(香港|新加坡)

判断过滤是否正确，应先取消过滤查看全部条目，再应用筛选，比较列表是否符合预期。空结果可能来自大小写、全角字符、隐藏空格或命名变化，而不是订阅失效。排除关键词与包含关键词同时使用时，检查两者是否互相抵消。需要复杂条件时，把条件逐个增加；一次写完长表达式，会使出错位置难以定位，也不利于后续维护。

更新订阅时保留可恢复的信息

远程更新可能替换分组内的服务器条目，本地手工修改的备注或参数不一定被保留。需要长期保留的自定义服务器，宜放在单独的手动分组中。更新前记录活动服务器所属分组与可识别名称，但不要假设更新后条目顺序保持不变。提供方可能调整名称、删除线路或改变排序，依赖列表位置选择服务器，很容易在更新后切到不符合预期的目标。

订阅更新失败时，先区分“地址取回失败”和“内容解析失败”。前者检查地址有效性、当前网络与更新时是否使用代理；后者检查返回的是否是订阅内容，而不是登录页面、到期提示或错误页面。若选择通过代理更新，必须先有一个仍可连接的活动节点。所有节点都已不可用时，这种更新路径可能形成依赖闭环，需要尝试当前网络允许的其他更新方式。

导入到 v2rayNG 或 v2flyNG 时，也要重新检查分组与活动节点。不同客户端对备注、排序和过滤条件的保存方式可能不同，不能把桌面端列表状态当成手机端已同步的证据。订阅链接本身通常带有访问凭据，复制到剪贴板后避免发送到公开群聊。排查时只提供经过处理的错误摘要，不要把完整链接贴进文章评论或截图。

路由规则实战与优先级

先确定默认出口，再写例外规则

路由分流的任务，是把已经进入内核的连接交给某个出站。它不负责让应用流量自动进入客户端，也不等同于系统代理开关。规则通常按顺序匹配，先命中的有效规则决定路径；未命中时再使用配置的默认出站行为。修改之前先明确默认走代理还是直连，再把少量例外写在前面。否则一条范围很大的规则，会让后面的细分规则没有机会生效。

v2rayN 的预设路由模式适合作为起点，不宜把几个预设的规则直接叠加。先选择与用途接近的一组，再通过路由设置查看实际条目。内网地址、指定域名、地区集合和兜底规则应有清晰层次。用于代理服务器自身连接的绕行处理尤其重要，启用 TUN 后还要防止代理连接再次被捕获。客户端可能自动处理部分例外，修改前应确认现有行为。

域名、地址与集合各有匹配条件

full: 适合只匹配一个完整域名；domain: 适合同时覆盖指定域名及其子域名；regexp: 提供正则匹配；geosite: 引用域名集合。地址规则中的 ip 可以使用单个地址、网段或受支持的地址集合。集合名称不是固定内置的业务承诺，是否可用取决于当前数据文件。使用前先确认对应文件存在、条目名称正确。

下面的片段将保留示例域名及其子域名交给名为 direct 的出站。它只演示路由结构，合并到配置时必须确认已有相同标签的出站。示例域名应替换为实际需要直连的目标，但不要填入完整网页地址。协议前缀、端口和路径不属于这个域名匹配字段。使用图形界面添加同类规则时，也应分别选择域名条件与目标出站。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

多个条件如何组合

同一规则中，不同条件字段通常需要同时满足；同一个列表中的候选项通常用于择一匹配。因此，把域名、端口和网络类型塞在同一条规则里，会缩小匹配范围，而不是分别为三类流量添加规则。需要表达不同场景时，拆成独立规则更容易验证。遇到“域名明明正确却不命中”，除了顺序，还要检查是否附带了不符合实际请求的端口或入站条件。

域名规则能否使用，还取决于内核是否拿到了域名。显式代理请求可能自带域名；某些透明接管流量只有目标地址，需要依靠嗅探或 FakeDNS 映射补充信息。domainStrategy 又影响何时为地址规则解析域名。不要把它与 DNS 模块的查询策略混为一谈。解析发生得更早，不代表分流一定更准确，也可能增加等待并改变地址规则的命中结果。

规则验证应围绕具体目标展开：记下预期出站，发起一次新连接，观察日志中的目标与出站标签。浏览器可能复用旧连接，因此修改规则后仅刷新页面不一定触发新路由。必要时关闭相关应用再重试。若结果不符，暂时把目标规则移到前部测试；确认能命中后，再调整回合理位置，而不是永久依靠置顶掩盖其他规则范围过大的问题。

DNS 配置优化与解析路径

先画清谁在解析、请求从哪里发出

一次访问可能涉及应用自身解析、系统解析、客户端内置 DNS，以及代理服务器端解析。客户端里填写了远程 DNS，不代表所有应用的查询都会自动进入它。浏览器的安全 DNS、应用内置解析器和系统缓存，都可能绕开预期路径。排查前先写清测试应用、接管方式与目标域名，避免把不同层的查询混在一起解释。网页出口地址也不能单独证明解析路径正确。

直连 DNS 与远程 DNS 是用途划分，不是单纯的地理位置划分。直连目标需要能够返回适合本地访问的地址；代理目标则需要与代理访问路径相容。若解析结果带有明显地域差异，错误的解析路径可能让内容分发选择偏离实际出口。先用客户端默认配置建立可用基线，再按目标范围拆分解析。不要一开始同时启用多个解析器、复杂回退与特殊查询策略。

查询策略与路由策略分别检查

下面是核心 DNS 配置片段，使用公共解析地址并优先限定为 IPv4 查询结果。它用于说明 servers 与 queryStrategy 的位置，不是针对所有网络的推荐方案。公共解析地址是否可达，需要在实际环境测试。该片段本身也不会接管系统 DNS，不会自动保证查询通过代理，更不会代替客户端对 DNS 出站路径的配置。

{
  "dns": {
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIPv4"
  }
}

UseIPv4 影响该 DNS 模块的查询结果选择，不会关闭操作系统的 IPv6，也不会阻止应用通过其他解析器获得 IPv6 地址。若网络具备完整双栈能力，可以在理解行为后选择相应策略。若只是某类 IPv6 连接失败，先判断是系统路由、代理出站还是服务器链路的问题。全局关闭一个地址族可能暂时避开现象，却会隐藏真正的配置缺口。

路由中的域名策略与 DNS 查询策略处于不同层。前者决定为路由判断何时解析目标，后者决定 DNS 模块怎样查询。使用域名集合分流时，尽量先让域名规则完成判断，再对确实需要地址条件的连接解析。若每个请求都提前解析，地址规则可能影响原本只想按域名处理的目标。调整后应同时观察域名命中与最终连接地址，而不只看网页能否打开。

加密 DNS 仍需要可到达的网络路径

加密解析可以保护查询传输，但解析服务本身也必须建立连接。若解析服务使用域名地址，就需要先解决它自己的地址解析；若该连接被安排走代理，则代理服务器的域名又可能依赖尚未工作的 DNS。这类循环依赖会表现为客户端启动正常、所有新域名访问却持续超时。解决时应建立清晰的引导解析路径，并确认代理服务器地址能够独立解析或被正确处理。

客户端中的“通过代理查询”“远程 DNS”或类似选项，含义应结合当前内核与生成配置判断。不要只凭选项名称推断所有查询都走某个出口。若启用了按域名选择解析器，还要检查未命中时使用哪一个默认服务器、失败时是否回退，以及回退是否改变了原先的路径要求。增加解析器并不必然提高可靠性，也可能让同一域名出现不一致的答案。

验证时先选定一个普通域名，记录系统查询结果，再通过目标应用发起新连接。终端查询只代表终端工具使用的解析路径，浏览器可能另走安全 DNS。切换配置后等待缓存过期，或在明确影响范围的情况下刷新相关缓存。不要在每次测试之间反复更换服务器节点，否则出口变化与 DNS 变化同时发生，无法确定究竟是哪项调整带来了结果。

还要检查局域网设备名称、公司内部域名与本地服务。它们可能只能由局域网解析器回答，全部交给公共解析器会导致打印机、内部页面或开发环境不可达。应为确实属于内部网络的名称保留合适的解析路径，同时避免把所有未知域名都当成本地名称。使用搜索后缀的环境，需要分别测试短名称与完整域名，确认客户端没有改变原有解析习惯。

TUN 模式与系统接管边界

系统代理与虚拟网卡解决不同问题

系统代理主要向遵循系统设置的应用提供代理入口，应用是否使用它由自身实现决定。TUN 则通过虚拟网络接口和系统路由接管流量，让更多不读取系统代理的应用进入处理链。两者不是“普通模式”和“加速模式”的关系。网页已经可以正常访问时，只有在确实需要接管其他应用或协议流量的情况下，才需要进一步评估 TUN 的权限与兼容性。

v2rayN 中的 TUN 功能可能依赖配套的网络栈组件，具体实现以客户端界面与实际生成配置为准。不能因为当前代理出站使用 Xray，就把任意 TUN 入站字段直接写进 Xray 配置。内核、接管组件和图形客户端各有职责。启用前先阅读当前客户端的选项说明，确认所需组件已经就绪，再检查权限、虚拟网卡创建与系统路由安装是否成功。

先单独启用，再处理冲突

操作顺序建议是先确认普通代理可用，再关闭其他可能接管系统网络的工具，保存工作后启用 TUN。首次测试不要同时修改 DNS、路由与节点。若客户端提示需要提升权限，按照系统提示授予必要权限，而不是反复点击开关。启用后观察日志，区分“接口创建失败”“路由添加失败”和“代理连接失败”，因为这些问题发生在不同层，处理方法也不同。

Android 客户端通过系统 VPN 服务接管流量，不能直接照搬桌面端虚拟网卡的排错步骤。同一用户环境下，其他使用 VPN 服务的应用可能产生占用冲突。若设置了按应用代理，还要确认目标应用在接管范围内。系统后台限制可能让连接在熄屏后中断，应先观察断开时机，再调整必要的后台运行设置，不要把所有间歇性断流都归因于节点质量。

路由环路与局域网访问

TUN 接管后，代理服务器自身连接必须有正确的绕行路径。如果这条连接再次被送回虚拟接口，就可能形成环路，表现为持续重连、资源占用升高或完全无法联网。客户端通常会处理必要的绕行，但自定义路由、额外网络工具与手动系统路由可能破坏它。出现此类症状时，先停用 TUN 恢复基线，再检查代理目标与系统路由，不要继续叠加例外规则碰运气。

局域网目标需要单独测试。可以先访问路由器管理地址，再测试文件共享、打印服务和内部域名。按地址排除私有网段，只解决了连接路径，不一定解决内部名称解析；反过来，DNS 返回了正确地址，也不代表系统路由会直达它。若设备处于多个网段或使用企业 VPN，还要确认排除范围没有与对方网络重叠。宽泛排除整个地址段可能影响其他用途。

UDP 是否可用，取决于接管组件、核心配置、节点协议、服务器支持与目标网络的完整链路，不能由 TUN 开关单独保证。网页请求成功也不能证明实时通信或其他 UDP 业务正常。测试时使用实际目标应用，并留意失败是否仅出现在某种网络。若 TCP 正常而 UDP 失败，优先检查协议能力与相关日志，而不是不停切换系统代理选项。

网络切换后也要复测。无线网络换到有线网络、休眠恢复或接入企业网络，可能改变默认网关、接口优先级和 DNS。客户端若未正确重建路由，旧状态可能继续影响连接。先停止接管再重新启用，并观察接口状态是否恢复。不要未经确认就删除系统中的所有虚拟网卡，那可能影响其他合法网络工具，也会使回退过程更复杂。

FakeDNS 映射与域名还原

虚拟地址是映射索引，不是目标服务器

FakeDNS 的作用，是给查询域名返回一个受管理的虚拟地址，并保存域名与地址的对应关系。应用连接该地址时，接管链路再依据映射还原域名，让后续分流或代理连接使用域名信息。这个地址不是网站真实地址，也不是公共网络上的实际出口。看到应用获得特殊网段地址，不应立即判定解析错误；应继续检查映射是否被正确还原，以及真实连接是否由预期出站建立。

FakeDNS 适用于能够同时控制解析与后续连接的场景。只有查询进入 FakeDNS，而连接绕过客户端，就会得到无法按预期访问的虚拟地址；只有连接进入客户端，查询却由其他解析器完成，也不会形成相应映射。启用前应先完成 TUN 或其他透明接管的基础验证。显式代理已经能够传递域名时，不一定需要增加这一层，额外组件也意味着更多状态需要维护。

核心地址池、DNS 服务与嗅探要配合

下面展示支持相应字段的核心如何定义地址池，并将 FakeDNS 作为 DNS 服务。它是局部配置示例，只有与支持映射还原的入站、正确路由和对应 DNS 接管一起使用时才有意义。不要把它直接写入不支持这些字段的网络栈配置。客户端若已经生成 FakeDNS 设置，应优先使用界面选项，避免手工配置与自动配置同时生效。

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

示例地址池使用保留用于基准测试的地址范围，并不表示这段地址在所有环境都没有其他用途。某些企业网络、实验环境或其他接管工具也可能使用它。启用前应检查本地路由与已有配置，避免地址重叠。地址池容量用于维护映射资源，不是越大越好，更不是可连接节点数。容量与资源占用、活跃域名规模有关，不应把示例参数当作性能优化结论。

对于支持 FakeDNS 嗅探还原的相关入站，可在已有入站对象中合并如下 sniffing 字段。这里只展示字段结构，不新增监听地址或端口。具体接管组件若使用另一套配置格式，必须按它自己的实现处理。单独打开嗅探并不能替代 DNS 接管，也不会凭空生成已经丢失的映射。验证时需要把查询、虚拟地址和后续连接作为连续过程观察。

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

缓存、重启与混合解析的边界

FakeDNS 映射通常具有运行时状态。核心重启后，应用仍可能缓存之前获得的虚拟地址，而新的进程已经没有对应映射。此时会出现某些应用失败、重新打开后又恢复的现象。排查时先结束受影响应用的新旧连接，必要时处理相关 DNS 缓存，再重新查询与访问。不要立即改动整个地址池，否则旧缓存与新映射并存，反而更难判断问题来源。

浏览器或应用内置的加密解析可能绕过 FakeDNS，使不同应用获得不同类型的地址。这不必然表示全部配置失效，但意味着不能用一个应用的结果推断整个系统。若目标是统一按域名分流，应检查应用解析设置与接管范围。若目标应用必须使用自己的解析方式，则需要明确该流量是否还有其他可用的域名识别路径，并接受它可能只能按地址规则处理的边界。

局域网服务也不宜盲目使用虚拟地址回答。内部名称可能依赖局域网 DNS 的搜索后缀与特殊记录，某些应用还会直接比较解析出的地址。应先建立内部域名的真实解析路径，再把适合的外部目标交给 FakeDNS。需要读取真实地址的诊断工具、基于地址的访问控制和部分设备发现机制，都应分别测试，不能只用网页浏览代表全部业务。

关闭 FakeDNS 时，应同步撤销 DNS 服务选择、映射还原设置与相关路由，再让应用重新获取真实解析结果。只关掉地址池但保留返回虚拟地址的解析路径，会留下半套配置。完成回退后，确认普通域名得到符合预期的真实地址，原有分流仍然工作。若问题只在 FakeDNS 开启时出现，保留普通 DNS 基线，逐段检查，而不是把故障归结为节点不可用。

多订阅管理与更新策略

按来源隔离，再按用途整理

多个订阅不应简单合并成一个庞大的服务器列表。来源不同，更新周期、命名规则与可用范围也可能不同。先按来源建立独立分组，再用搜索或过滤满足日常选择需要。这样某个来源更新异常时，可以单独停用或重新导入，不会影响其他分组。用途标签可写在分组备注中，但不要把提供方的宣传标签当作已经验证的能力说明。

订阅地址与服务器分享链接是两类信息。前者用于持续获取一组条目，后者通常描述单个服务器。把单节点链接填入订阅更新入口，可能出现解析失败；把订阅内容当成单节点导入，也可能丢失管理关系。添加新来源前先确认内容类型，再选择对应入口。测试成功后记录来源用途与最近检查结果即可，不要在公开笔记中保存包含访问凭据的完整地址。

自动更新需要可用的获取路径

自动更新的前提，是客户端运行、任务能够执行、订阅服务可达，且请求所用网络路径正确。它并不代表系统休眠或客户端退出时仍会持续更新。选择更新间隔时，应结合提供方允许的请求频率与实际需求，不宜频繁刷新。遇到临时限流，连续手动点击只会增加请求，应该先阅读错误类型，稍后重试，并保留目前仍可用的服务器条目。

当更新需要通过代理时，要确保当前活动节点不依赖此次更新才能恢复。可以保留一个已经验证的备用来源，但备用来源仍需要单独测试，不能仅凭列表存在就认定可用。若更新服务在直连网络能够访问，则先测试直连路径。关键是减少循环依赖：获取节点列表、解析代理服务器与建立代理连接，不应互相等待一个尚未准备好的环节。

更新后要检查实际差异，而不是只看成功提示。确认活动服务器是否仍存在、名称是否变化、协议参数是否被替换，以及过滤条件是否导致列表骤减。若提供方移除了某个条目，客户端未必会自动选择符合原用途的替代目标。需要手动重新选择并建立新连接。对长期运行的应用，还要注意旧连接可能继续使用更新前的路径，直到连接被重建。

相同节点不等于重复数据可以随意删

不同订阅可能出现相同显示名称，也可能名称不同但指向同一服务。判断重复应结合协议、服务器地址、端口与传输设置，而不是只比较备注。即便技术参数一致，条目仍可能属于不同管理来源；删除后是否会在下次更新重新出现，也取决于订阅管理机制。优先通过分组与筛选减少干扰，不要直接在大列表里批量删除尚未确认的条目。

手工调整的服务器应与远程订阅条目隔离。确实需要修改某个传输参数时，可在确认允许的前提下复制为手动条目，并明确标记用途。远程来源之后发生变更，手动副本不会自动跟进，需要自行复核。保留副本不是为了长期绕过正确更新，而是为了让测试变量可控。测试完成后，应清理不再使用的副本，避免后续误选过期配置。

桌面与手机可以导入相同来源，但不意味着过滤规则、活动节点和分流设置会自动一致。v2rayN、v2rayNG、v2flyNG 对订阅格式和参数支持可能存在差异，同一条目在某端可用，也不能证明另一端完全兼容。跨设备排查时，先对齐协议与传输条件，再分别验证。不要通过发送整份含认证信息的配置来比较界面，必要时只比对经过处理的字段名称。

导出备份前要明确包含哪些数据。服务器配置、订阅地址和认证信息都可能是敏感内容，备份文件应保存在访问受控的位置。恢复到另一台设备后，还要重新检查本地监听端口、网卡权限与系统代理状态，因为这些环境信息不能靠复制订阅解决。清理旧设备时也应移除不再需要的配置，避免账户信息长期留存在不使用的客户端目录中。

自定义出站与配置边界

出站标签是路由的连接点

出站描述连接如何离开核心，路由通过标签选择对应出站。标签只是本地引用名称，不具有自动识别协议或地区的能力。名称写成“direct”，不代表它一定直连；真正行为由该对象的协议与设置决定。新增出站前先列出已有标签，确认没有同名对象，也确认路由指向的是预期对象。标签拼写错误可能导致配置检查失败，或使预期路径无法建立。

普通客户端配置通常已经生成代理、直连与阻断等出站。若只是希望某个域名改走直连，优先新增路由规则，不必再创建另一个功能相同的出站。自定义出站适合确实需要不同连接方式的情况，例如将特定流量交给受控的本地代理服务。即便如此，也要先确认客户端是否支持合并自定义字段，以及切换节点时是否会覆盖手动修改。

先用清晰的基础对象理解结构

下面的片段展示直连与阻断出站的基本对象结构，适用于支持这些协议的核心。它不包含代理服务器，也不构成可直接替换的完整客户端配置。若现有配置已经有同名标签，不要再次追加。还要注意，未匹配路由的流量可能使用第一个出站；因此不能把示例数组原样替换进去，否则默认路径可能从代理变为直连。

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

阻断出站通常用于明确拒绝某类连接，而不是修复网络问题。测试期间如果把范围过大的域名或地址集合交给它，会造成看似随机的页面资源缺失。使用时应先对单个目标测试，再扩大匹配范围。直连出站同样不是绕过所有系统设置的保证，它仍受到操作系统路由、防火墙和底层网络条件影响。核心成功选择出站，只说明完成了路径决策。

连接其他本地代理时防止自我引用

如果需要通过另一个本地代理转发，先单独验证那个服务正在监听，并确认协议、地址、端口与认证要求。监听地址是本机环回地址还是局域网地址，决定谁能连接它。不要为了方便就把监听范围扩大到全部网络接口。若确实需要局域网访问，还要同步考虑系统防火墙与访问控制，避免把仅供本机使用的入口暴露给不相关设备。

最常见的错误，是自定义出站又连回当前客户端自己的代理监听入口。连接进入客户端后再次选择同一出站，就形成循环。端口相同不一定代表服务相同，因此应核对监听进程和完整处理路径。采用多级代理时，把每一跳画出来，明确哪一层负责域名解析、哪一层处理 UDP，以及最终连接由谁建立；链路越长，排查时越需要逐跳验证。

不同代理协议对域名、UDP 与认证的处理并不相同。上游支持普通网页代理，并不能推出它支持所有应用流量。若本地上游只接受某类请求，就应将路由范围限制在已经验证的用途。也不要把另一个组件的出站对象直接粘贴到当前核心中，字段名称相似不代表配置格式兼容。先确认核心名称与文档语义，再通过配置检查与启动日志判断是否被正确接受。

客户端切换服务器、更新订阅或修改路由后，可能重新生成运行配置。临时文件中的手工出站因此可能消失。应优先使用客户端明确支持的自定义配置入口，并记录合并方式是追加对象还是替换整个字段。若使用完整自定义配置，活动服务器选择等图形功能也可能不再按普通模式工作。设置前应确认这一边界，避免界面看似切换成功，实际仍运行固定配置。

验证自定义出站时，先只让一个测试域名命中它，查看日志中的标签与上游连接情况，再逐步扩大范围。若失败，依次判断目标规则是否命中、上游监听是否可达、认证是否正确、域名是否能解析。不要同时调整所有层。恢复时撤销测试路由，再移除不再引用的出站，最后确认默认代理与直连规则仍保持原来的顺序和行为。

配置验证、故障定位与回退

把“能启动”和“符合预期”分开验证

配置检查通过，只能说明结构与部分字段符合核心要求，不代表订阅服务可达、代理节点可用或分流结果正确。完整验证应依次覆盖客户端启动、核心运行、入站接管、路由匹配、解析路径与真实业务。每层都有自己的证据，不能用一个成功的网页请求替代全部检查。尤其是 TUN 与 FakeDNS，同时涉及系统状态和运行时映射，更需要分层确认。

开始修改之前，记录一组基线：使用的客户端与核心、活动服务器、系统代理状态、TUN 状态、路由模式，以及一个已知可访问的测试目标。记录设置名称与行为即可，不必公开服务器地址或认证信息。为本次修改写一句明确目标，例如“让指定域名直连”。目标越具体，验证越容易；“整体优化网络”过于宽泛，难以判断修改是否真正有效。

按症状选择最短排查路径

客户端无法启动时，先解决运行环境、目录权限与配置读取问题，不要继续调整 DNS。客户端启动正常但核心退出时，查看最近修改的字段、标签与端口占用。核心正常运行但应用完全不走代理时，检查系统代理、应用设置或接管范围。只有流量已经进入核心，路由和出站分析才有意义。把问题放到正确层，通常比一次性重装全部组件更有效。

延迟测试与真实连接测试也要分开理解。某项测试可能只探测特定目标、使用特定请求方式，不能代表所有协议与业务。测试成功后，还应访问实际需要的目标，并确认出口和路由符合预期。若单个站点失败，先检查它涉及的附属域名与连接类型，而不是立即判定整个代理链失效。页面主体出现但图片或登录失败，往往需要检查不同资源的分流。

日志阅读从时间与一次请求开始。先清楚记录发起测试的时刻，再查对应目标、入站和出站标签。错误中的解析失败、连接拒绝、连接超时和认证失败分别指向不同方向。连接拒绝通常说明对端明确拒绝或端口没有服务；超时则可能涉及路径、防火墙或远端响应。日志信息不足时可临时提高详细程度，排查结束后恢复，避免长期积累敏感目标信息。

回退也要按依赖顺序执行

若本次同时涉及多层设置，先停止新建业务连接，再撤销最外层接管或新增规则，随后恢复 DNS 与出站基线。关闭 FakeDNS 时按前文同步处理映射相关设置与应用缓存。TUN 异常时先恢复普通系统网络，再验证客户端代理。不要一边保留错误接管状态，一边反复更换服务器，这样既不能恢复可用性，也会增加新的变量。

回退之后必须复测，而不是看到开关关闭就结束。确认客户端已停止相关核心或重新加载正确配置，系统代理指向现存监听入口，普通网页与局域网访问均恢复。若客户端退出后仍残留代理设置，应按系统网络设置检查；不要继续启动第二个客户端去掩盖旧入口。只有基线重新可用，才适合重新引入刚才失败的设置，并将修改范围缩到最小。

需要进一步求助时，提供客户端名称、平台、所用核心、最小复现步骤与经过处理的错误摘要。订阅链接、认证字段、完整服务器配置和含私人域名的日志不宜直接发送。截图前先检查地址栏、二维码和剪贴板提示。客户端启动即退出的专项排查可看v2rayN 打不开与闪退处理，不要把启动问题与连接问题混成同一故障。

稳定配置应当能解释、能验证、能恢复。保留必要的订阅分组、明确的路由顺序与适合当前网络的解析路径，比不断增加开关更容易维护。新设备从快速上手主线重新建立连接，再迁移已经理解的规则；遇到名词疑问可查概念速查。每次只增加一层能力，确认收益与边界后再保留，手册才会真正成为可重复的操作依据。