V2Ray 进阶配置手册

订阅分组与服务器过滤

订阅分组首先解决配置来源的归属问题，而不是直接决定流量走向。一个分组通常保存订阅地址、显示名称、更新选项和过滤条件，服务器列表则是订阅更新后生成的结果。把某台服务器移到另一个显示分组，并不等于给某类应用建立代理规则。配置之前，应先区分来源管理、当前服务器选择和路由分流三个层次，避免在错误的位置寻找开关。

按来源建立可追溯的分组

在 v2rayN 的订阅分组设置中，为每个来源单独建立记录，名称可以采用“用途－来源”的形式，例如“日常－主订阅”和“测试－备用订阅”。订阅地址应完整粘贴，检查首尾空格和换行；保存后执行对应分组的更新，而不是立刻批量更新所有来源。首次更新只观察这个分组的结果，确认能生成服务器，再继续增加其他订阅。

服务器名称只是远端提供的备注，不是可信的能力证明。备注中的地区、线路或倍率文字不能替代协议字段检查，也不能保证实际出口位置。挑选服务器时，还应查看协议、传输方式、加密与安全设置是否符合内核支持范围。涉及内核选型时，可先阅读Xray 与 V2Fly 内核差异，再决定保留哪些配置。

把临时搜索与持久过滤分开

列表搜索通常只改变当前视图，清除搜索词后服务器仍然存在；订阅过滤则可能影响下一次更新时实际导入的条目。两者最明显的区别，是清空搜索后能否重新看到原来的服务器。启用持久过滤之前，先记录未过滤时的列表情况，并保留至少一台已验证可用的服务器。否则，过滤表达式写错后，容易把空列表误判成订阅失效。

部分客户端的过滤框接收普通关键词，另一些位置支持正则表达式，不能只凭输入框名称推断。若界面明确说明使用正则，测试|备用表示匹配任一词；但“匹配后保留”还是“匹配后排除”，仍由该选项的语义决定。先用一个确定存在的服务器名称试验，再扩大范围。不要一开始使用复杂的前后向断言，以免不同实现的正则支持不一致。

更新后处理重名、消失与选中状态

订阅更新可能重建条目，也可能按客户端策略合并已有记录，所以不能假定当前选中的服务器一定保持不变。更新后先检查当前服务器标记，再看协议参数和可用性。对需要长期保留的手工条目，应放入独立的本地分组，或在更新前导出备份；不要依赖修改远端服务器备注来保存个人设置，因为下一次更新可能覆盖这些改动。

如果更新成功却看不到服务器，依次清空列表搜索、检查当前分组、暂时取消订阅过滤，再确认响应内容能否被客户端识别。如果更新失败，不要立即删除原分组，原列表仍可能可用。安卓端同样应先区分订阅组与当前视图；v2rayNG 和 v2flyNG 的界面入口不同，但都应遵循“单组更新、检查结果、再选择服务器”的顺序。来源归属清楚之后，后续排错才能知道是哪一次更新改变了配置。

路由规则实战

路由是在连接进入内核后，为它选择出站的过程。判断依据可以是目标域名、目标地址、端口、网络类型或入站标签。客户端中的“规则模式”通常是选择一套预置路由，而不是让内核自动理解所有应用用途。建立自己的规则前，先确认当前启用的是哪套配置，再备份已有规则；仅在编辑器中保存一条规则，不一定代表运行中的内核已经加载。

理解匹配顺序与规则内部关系

常规路由规则从上到下检查，首先匹配的规则决定出站，因此具体规则应放在宽泛规则前。例如，先放需要代理的完整域名，再放局域网地址直连，最后才考虑兜底行为。同一条规则中的不同条件通常需要同时满足，同一个条件字段里的多个值则通常表示任选其一。把域名、端口和网络类型全填进同一行，会缩小匹配范围，而不是增加三种独立命中机会。

域名匹配也有粒度差异。完整域名匹配适合单个主机，域名及子域名匹配适合整个服务范围，关键词匹配则可能意外覆盖名称相似的其他站点。先用最小范围验证，再逐步扩大。不要为修复一个下载域名的问题，直接把所有流量都改成代理；这样虽然可能暂时恢复访问，却掩盖了规则过宽、依赖域名遗漏或 DNS 路径错误。

从一条明确规则开始验证

下面是 Xray 常见 JSON 路由字段的局部示例，展示完整域名、私有地址和出站标签的对应关系。它不是完整客户端配置，必须合并到已存在的运行配置中，并确保已经定义 proxy 与 direct 出站。示例域名仅用于说明匹配语法；实际验证时，应在自己的配置中改成需要处理的真实目标。

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

AsIs不会为了 IP 规则主动解析域名，但连接原本携带目标 IP 时仍可匹配 IP 规则。域名连接若没有命中域名规则，也不会因为写了私有地址规则，就必然先解析并识别其局域网属性。要处理内网域名，应补充明确的域名规则，或在了解解析影响后选择其他域名策略。使用 geoip:private还要求对应数据资源可读取，资源缺失时应先修复加载错误。

兜底、嗅探与既有连接

没有规则命中时，内核通常采用出站列表中的首个出站，客户端也可能生成额外的最终规则。应查看实际生成配置，而不是只看界面中最后一行。若希望统一由某个出站兜底，可使用客户端提供的最终出站设置；手工配置则要明确覆盖哪些入站或网络类型，避免把规则写成语义不明的空条件。默认出站顺序一旦改变，原来未命中的连接也可能随之改道。

嗅探能够在部分连接中恢复 HTTP 主机名或 TLS 服务器名称，但不能保证识别所有加密协议，也不一定能看到启用加密握手信息的域名。它是补充信息来源，不是 DNS 的替代品。规则修改后应新建连接再测，已经建立的长连接通常不会自动切换出口；必要时关闭测试应用后重新打开，而不是只反复刷新同一个页面。

若规则没有生效，先确认流量是否进入客户端，再检查规则是否启用、目标是否确实匹配、前面是否存在更宽的规则，以及目标出站标签是否拼写一致。系统代理模式下，不遵循系统代理的应用根本不会进入这条路由链。排查到这一步仍有疑问，可对照帮助中心中的代理模式说明，先解决流量入口，再调整路由内容。

DNS 配置优化

DNS 配置需要回答两个不同问题：由谁解析域名，以及解析请求经哪条网络路径发出。浏览器、操作系统、客户端内核和远端服务器都可能参与解析。访问网站成功，不代表所有应用采用同一解析路径；修改系统 DNS 后某个应用仍无变化，也不一定是修改失败，因为应用可能使用自己的加密解析服务或保留了独立缓存。

先画清解析链路

系统代理下，应用可能先把域名交给本地代理，再由出站或远端处理；也可能先在本机解析出 IP，再把 IP 交给代理。TUN 模式下，客户端是否接管 DNS，取决于虚拟接口、DNS 劫持和应用请求方式。开始优化之前，记录当前系统解析器、客户端 DNS 选项以及浏览器安全 DNS 设置。一次只调整其中一处，才能确认是哪一层改变了结果。

用于连接代理服务器的域名尤其重要：客户端必须先找到服务器，才能通过它发送后续流量。如果把该服务器域名的解析强制送进尚未建立的代理，就可能形成启动依赖环。较稳妥的做法，是为服务器地址保留可达的引导解析路径，并明确其直连条件。代理一旦断开，仍应能完成必要的服务器解析，否则重连阶段会持续失败。

区分域名策略与地址族策略

路由里的 domainStrategy影响是否为匹配 IP 规则而解析域名；DNS 的 queryStrategy影响查询使用的地址族；直连出站中的域名策略又影响实际拨号前如何处理域名。这些字段位于不同位置，不能因为名称相似就互相替代。下面是内置 DNS 的最小局部示例，借用系统解析器作为基线，便于先确定问题是否来自复杂的分流解析设置。

{
  "dns": {
    "servers": ["localhost"],
    "queryStrategy": "UseIP"
  }
}

该片段不会自动接管系统中的所有 DNS 请求，也不能保证每个出站都会调用内置解析器。具体调用仍由路由策略、出站设置和客户端集成决定。若原配置使用带域名筛选的解析器条目，直接替换整个 DNS 对象会移除这些规则，应先导出原配置再试验。恢复基线后若问题消失，再逐项添加原来的服务器与筛选条件。

处理 IPv6、缓存与内网域名

双栈网络应先确认 IPv6 是否真正可达，包括本地网络、代理服务器和目标服务三个环节。仅收到 IPv6 地址并不能证明连接可用。若日志持续出现地址族相关连接失败，可临时限定 IPv4 作为对照，但不应把永久关闭 IPv6 当成所有 DNS 问题的通用解法。对照测试结束后，再决定是否保留限制，并检查是否影响原本可用的内网服务。

公司内网、路由器管理名和设备发现名称，往往依赖本地解析环境。把所有域名统一发给公共解析器，可能让这些名称失效。应给内网域名保留系统或指定局域网解析器，同时确保相关目标走直连。修改 DNS 后，要考虑系统与应用缓存的不同有效期；重启测试应用通常比不停切换解析器更有意义，已经建立的连接则未必再次查询域名。

排错时把“查询超时”“返回地址不合适”和“地址正确但连接失败”分开记录。查询超时看解析器可达性与请求路由，地址不合适看筛选规则和缓存，连接失败则继续检查出站、目标端口和网络环境。加密 DNS 主要改变查询传输方式，不会自动修复错误的路由选择，也不会让不可达的服务器地址恢复连接。

TUN 模式与系统网络接管

TUN 通过虚拟网络接口把 IP 层流量交给用户态处理，适合无法遵循系统代理、但仍需要统一分流的应用。它并不是“更强的全局代理”开关：流量进入 TUN 后，依然需要路由规则决定直连或代理，也依然受出站协议、UDP 支持和 DNS 处理方式约束。系统代理与 TUN 的入口不同，应先分别验证，再考虑是否需要同时保留。

确认接管组件、权限和工作基线

v2rayN 的 TUN 实现可能由配套组件承担，不应把图形界面的 TUN 开关直接理解成给 Xray 添加某个同名字段。开始前先让普通代理模式稳定工作，确认当前服务器可用，再查看客户端要求的运行权限、组件状态与日志。安卓端的 VPN 授权则是流量接管许可，不表示使用了与桌面端完全相同的虚拟接口实现或配置格式。

首次开启时，保留一个能够恢复设置的本地操作入口。先关闭其他正在接管网络的工具，保存当前 Wi-Fi 或有线网络的 DNS 与代理设置，再开启 TUN。观察虚拟接口是否建立、默认路由是否变化，以及测试流量是否进入日志。若界面显示已开启但没有对应连接记录，应先查接口和路由，不要立即更换服务器。

避免回环，保留局域网访问

代理客户端发往服务器的连接不能再次被自己当成待代理流量，否则会产生回环或反复重试。成熟的接管组件通常提供自动路由或接口绑定机制，但手工修改路由后仍可能破坏这些保护。遇到开启 TUN 后代理立即断开的情况，先检查服务器地址是否被错误接管，再看是否有多个虚拟接口竞争默认路由。

局域网设备、打印服务和路由器管理页面通常需要直连，但仅添加私有地址规则不一定能覆盖设备发现。广播、多播和按名称发现属于另一类问题，是否能够穿过虚拟网络取决于实现与系统环境。若设备 IP 能访问而名称无法解析，应转向 DNS 或发现协议排查，而不是不断扩大代理范围。企业网络中的私有地址也可能与本地网段重叠，需要更具体的路由边界。

按 TCP、UDP 和应用范围逐步验证

先用一个明确的 TCP 请求验证入口和出站，再验证确实需要的 UDP 应用。网页正常但语音或实时通信失败，可能是 UDP 转发、服务端能力或网络策略问题，并不等于整个 TUN 都失效。应用出现 QUIC 相关故障时，也应把 UDP 路径单独记录；临时停用应用中的相关功能只能作为对照，不能替代检查底层转发能力。

系统代理与 TUN 同时开启可能是客户端预期设计，也可能导致应用先连本地代理、本地代理再被 TUN 捕获。排错阶段建议只保留一个已知入口，确认工作后再恢复组合配置。安卓端按应用排除后，被排除应用可能完全绕过客户端路由；因此不能用它的访问结果验证内核规则。后台省电限制也可能使接管会话中断，应区分进程退出与服务器断开。

关闭 TUN 后若网络没有恢复，先检查虚拟接口、默认路由和系统 DNS 是否回到原状态，再检查系统代理是否还指向已经停止的本地监听端口。不要直接删除所有网络适配器或重置全部网络设置，这会扩大影响范围。仅撤回本次新增的接管设置，并重新连接当前网络，通常更容易保留原有企业网络和本地设备配置。

FakeDNS 的工作方式与使用边界

FakeDNS 为域名返回一个用于本地映射的合成地址，随后在连接进入代理处理链时，根据映射恢复原始域名。它解决的是“应用已经把域名解析成 IP，路由却仍希望按域名判断”的信息保留问题，而不是给目标站点分配真实地址。理解这一点很重要：合成地址只能在对应的接管与映射链路里使用，普通网络设备并不知道它代表哪个域名。

查询、映射与连接恢复必须闭环

完整链路至少包括三步：应用查询域名时得到合成地址，应用向该地址发起连接，接管组件把地址反查成域名并交给后续路由。只启用第一步，可能让应用拿到一个无法直接连接的地址；只开启域名嗅探，也不代表一定能恢复 FakeDNS 映射。应使用客户端提供的一体化选项，并确认 DNS 与流量接管由兼容的组件协同处理。

在 v2rayN 中，应先查看当前 TUN 组件是否提供对应能力，而不是把网上找到的内核片段直接粘贴到所有设置框。v2rayNG、v2flyNG 与桌面端的集成方式也可能不同，支持情况取决于内核与客户端实现。菜单中没有该功能时，不应假定增加一个字段就能补齐接口、DNS 劫持和地址恢复的全部链路。

理解地址池与映射容量

下面展示 Xray 常见的 FakeDNS 对象形式，使用专门的测试地址范围作为合成池。它只是局部语法示例，不是可独立运行的接管配置；还需要内置 DNS 调用 FakeDNS，以及兼容入站恢复映射。若当前客户端使用其他接管组件，必须使用该组件自己的配置语法，不应混用字段。

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

ipPool决定可用于映射的合成地址范围，poolSize决定映射池容量，不代表并发连接数，也不是越大越快。配置前应确认合成网段没有被当前实验网络或特殊路由使用。不要拿常见家庭局域网网段随意充当地址池，否则真实设备地址与合成地址可能发生冲突，表现为某些设备突然不可达。

映射的生命周期同样需要考虑。内核重启后旧映射可能消失，但系统或应用仍缓存着之前的合成地址。此时新的连接进入客户端，却无法找回对应域名，就会出现“刚开启正常，重启后部分应用失败”的现象。应让应用重新发起 DNS 查询，必要时退出应用并清理相关缓存，而不是继续扩大地址池来掩盖生命周期不一致。

判断哪些应用需要真实地址

有些应用会检查 DNS 返回地址、比较地址与证书信息，或把解析结果交给另一个不经过代理的进程。这些场景不一定适合合成地址。局域网管理、设备发现、某些实时通信和依赖真实地址判断的程序，通常需要单独验证。若客户端支持按域名使用真实解析，可为这些目标建立例外，但必须同时检查对应的路由与 DNS 请求路径。

浏览器自己的加密 DNS 可能绕过预期的 FakeDNS 查询入口，使同一设备上一部分应用获得真实地址，另一部分获得合成地址。出现这种混合状态时，应先记录各应用解析方式，不要仅凭网页能打开就认为整个链路正常。测试范围至少包括普通网页、需要域名分流的目标、局域网地址和一个不应进入代理的应用。

关闭功能时同步撤回依赖

停用 FakeDNS 不只是关闭映射池。应同时恢复正常解析路径，确认客户端不再向应用返回合成地址，并让已有缓存失效。若先关闭接管而保留合成 DNS 响应，应用会尝试把流量发往普通网络中的合成地址，故障会继续存在。回退顺序应以客户端集成机制为准，但最终必须让 DNS 返回结果与流量接管方式重新一致。

建议只在常规 DNS、路由和 TUN 都已经稳定后引入 FakeDNS。若目标是修复单个域名分流，先检查是否能通过明确域名规则解决；只有确实存在域名信息丢失、且接管链路支持恢复时，才值得增加这一层映射。功能带来的收益应能通过日志说明，而不是仅凭开启后某一次访问速度的主观变化判断。

多订阅管理与更新策略

多订阅管理的重点是让来源、用途和变更保持可追溯，而不是把所有服务器混成一张更长的列表。建议先明确主订阅、备用订阅和测试订阅的职责：主订阅承载日常使用，备用订阅提供人工切换选择，测试订阅用于检查新协议或新配置。服务器属于不同分组，不表示已经具备自动故障切换，更不表示流量会按分组名称自动分配。

为每个来源保留独立边界

新增来源时使用独立分组，先执行单组更新，再检查协议类型、条目命名和过滤结果。即使两个来源提供相同备注，也应保留来源信息，因为同名不等于相同服务器。对照地址、端口和传输参数时，只在本地进行，分享排错材料时遮蔽凭据。不要为了让列表整洁就直接合并来源，否则后续很难知道某个条目是由哪次更新带来的。

重复条目的判断需要结合实际用途。相同服务器地址与端口，可能因为用户凭据、传输路径或安全参数不同而代表不同配置；不同备注也可能指向同一服务。客户端的去重功能通常按有限字段判断，不能替代人工确认。批量去重前先导出本地备份，并保证至少保留一个可以连接的条目，避免误删后只能等待远端重新下发。

安排可观察的更新过程

订阅更新会改变服务器集合，应尽量避开长时间下载、远程管理或重要会话期间。先更新备用或测试分组，确认没有异常，再更新主分组。自动更新若可设置周期，应根据实际变更频率选择，而不是越频繁越好；过于密集的请求可能触发来源限流，也会让本地列表不断变化，增加排错难度。

更新订阅是否经过代理，需要单独验证。有些来源通过当前网络直连可用，有些需要已有代理路径。如果更新依赖当前服务器，而该服务器已经失效，就会出现“需要更新才能恢复，但更新又依赖失效连接”的循环。客户端若提供不同更新方式，可在确认来源安全的前提下切换请求路径；不要把订阅地址复制到未知在线转换服务中尝试修复。

把个人设置与远端内容分离

订阅提供的服务器信息与个人路由应分别维护。个人添加的局域网直连规则、应用范围和 DNS 例外，最好保存为客户端支持的独立设置，而不是直接改订阅生成的临时配置。生成文件可能在切换服务器、更新订阅或重启时重建；如果修改只存在于临时文件中，下一次重建就会消失，容易被误认为客户端没有保存。

远端订阅也可能包含复杂配置内容，应先弄清客户端究竟导入的是服务器列表还是完整配置。两者权限边界不同：服务器列表通常只补充连接参数，完整配置则可能改变路由、DNS 和监听行为。导入前应看清格式提示，导入后检查实际运行设置，尤其是局域网监听和默认出站，不要仅根据文件扩展名判断其内容。

更新失败后的保留与恢复

一次更新失败不应立即触发删除旧列表。先观察是连接超时、响应状态异常、返回空内容，还是格式解析失败；这些情况对应不同处理方式。若旧服务器仍可连接，暂时保留它并停止反复刷新。若订阅地址已变更，应通过可信来源获取新地址，再在原分组中替换，避免建立多个含义相同却状态不同的记录。

备用订阅的价值在于可以独立验证。平时应偶尔检查其是否仍能更新、是否存在可用服务器以及内核是否支持，而不是等主订阅故障后才首次尝试。相关客户端的功能边界见三款客户端平台与功能对比。完成来源分离后，再考虑自动选择或负载策略，才能避免把订阅管理问题误当成出站调度问题。

自定义出站与配置组合

出站定义连接如何离开内核，路由则引用出站标签决定使用哪一种方式。常见出站包括代理协议、直连和阻断。增加一个出站对象并不会自动让流量使用它；必须有路由规则命中它，或让它成为默认出站。反过来，路由引用不存在的标签也不会凭空生成对应连接方式，所以标签一致性是自定义配置的首要检查项。

先确定配置由谁生成

v2rayN 的普通服务器模式通常根据当前选择与界面设置生成运行配置。直接编辑生成结果，可能在下一次切换服务器时丢失。需要自定义出站时，应优先使用客户端明确提供的高级配置入口；如果选择完整自定义配置，就要确认哪些界面开关仍然生效，哪些字段已经由自定义文件接管。两套管理方式混用，最容易出现“界面已修改、运行结果没变化”。

安卓客户端同样需要区分普通配置编辑与完整配置导入。v2rayNG 主要依托 Xray，v2flyNG 使用 V2Fly，不能因为两者都能处理某种服务器列表，就认为所有出站字段完全兼容。遇到特定协议或安全层参数，应先核对目标内核的支持范围。社区生态关系可参阅Project V 开源生态梳理，不要按客户端名称猜测内部能力。

用直连与阻断验证标签链路

下面是一份可供 Xray 使用的最小本地 SOCKS 配置，用于验证入站、路由和出站标签之间的关系。它只提供直连与示例域名阻断，不包含代理服务器。监听限定在本机回环地址，且关闭 UDP，适合作为独立实验配置；不要覆盖正在使用的主配置，测试前还应确认本地端口未被占用。

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

测试应用应把域名交给 SOCKS 代理，而不是先在本机解析成 IP，否则示例中的完整域名规则可能无法命中。这份配置没有启用嗅探来补回域名信息，目的是让验证条件保持清楚。未命中的连接使用首个出站，即 direct；更改出站顺序后，默认行为也会改变，因此维护时不应只关注标签而忽略排列顺序。

添加代理出站与理解链式连接

真正增加代理出站时，应从已验证可用的服务器配置出发，保留协议、服务器地址、端口、用户参数和传输安全设置，再给它分配唯一标签。不要只复制地址和端口，因为握手失败往往来自传输路径、服务器名称或安全参数不匹配。一个标签对应一个明确职责，例如主代理与备用代理，便于在日志里识别实际使用的出口。

链式连接表示一个出站通过另一个出站建立底层连接，不等于把两条路由规则依次执行。第一条路由命中后，通常不会继续把同一连接交给下一条规则。不同内核对出站转接字段与传输支持存在差异，应按目标内核语法配置；避免让甲依赖乙、乙又依赖甲，或让链路中的域名解析依赖尚未建立的链路本身。

负载均衡则属于候选出站选择，还涉及可用性观察、选择策略和会话持续性。把多个出站放进数组不会自动轮换，也不会自动检测故障。若需求只是偶尔切换备用服务器，人工选择更容易验证；只有明确需要自动调度，并且能解释每个候选出站的健康状态时，才适合引入更复杂的组合。

配置验证、日志定位与回退

一份配置能被保存，不代表能够启动；内核能启动，也不代表目标流量按预期出站。进阶配置应采用分层验收：先确认语法与资源加载，再确认本地入口，随后检查路由、解析和远端连接。每次修改前写清预期结果，例如“只有指定完整域名改走代理，局域网保持直连”，这样测试失败时才能知道是哪一层没有满足条件。

建立可复现的变更记录

备份至少覆盖订阅分组、手工服务器、路由规则、DNS 与接管设置，而不是只保存服务器列表。导出文件可能包含凭据，应存放在受控位置。修改时记录具体字段、原值与新值，并保留客户端生成配置和完整自定义配置的区别。若改动由多个界面开关共同产生，最好先逐项保存截图，避免回退时只记得其中一个选项。

一次只改一个主题：先验证订阅更新，再调整路由，之后处理 DNS，最后才引入 TUN 与 FakeDNS。修改后重启内核或使用客户端明确提供的重新加载功能，确认启动成功再进行业务测试。不要在同一轮操作里同时更新订阅、切换内核和修改 DNS，否则即使连接恢复，也很难知道真正起作用的是哪项变化。

按流量链路读取日志

首先看本地入口是否收到连接。没有入口记录时，应检查应用代理设置、端口、TUN 范围和按应用排除，而不是分析远端握手。入口存在后，再看路由目标与出站标签；标签不符就检查规则顺序与目标信息。只有标签正确后，才继续检查解析、拨号、握手和服务端响应。这个顺序能减少在错误层次反复更换参数的情况。

临时提高日志详细程度时，应控制测试时间，并在完成后恢复日常级别。日志可能记录访问域名、服务器地址和连接细节，分享前应脱敏。连接超时通常需要结合发生阶段判断：解析超时看 DNS，拨号超时看网络与端口，握手阶段异常看协议、安全设置及系统时间。单独截取最后一行，往往不足以说明真正原因。

使用对照测试而不是单次测速

测试集合应覆盖需要代理的目标、应当直连的目标、局域网地址以及实际使用的应用。每个目标都建立新连接，避免旧会话复用掩盖规则变化。可用性测试、连接延迟和实际传输速度反映不同事情，不能因为一次延迟测试成功，就认定 DNS、UDP 和大文件传输都正常。也不要把目标服务自身的错误响应直接归因于代理配置。

若只有一个应用失败，先与同设备上的另一个应用对照，检查独立 DNS、代理遵循方式和缓存。如果所有应用都失败，再缩小到系统网络与客户端入口。若普通代理正常而 TUN 失败，保留同一服务器，只改变入口方式进行比较；若切换服务器后仍然失败，则应优先检查共同的本地配置，而不是继续批量更换服务器。

按相反顺序撤回修改

回退时先撤回最后引入的复杂层，再恢复原来的路由与 DNS。停用 FakeDNS 后处理合成地址缓存，停用 TUN 后确认系统路由与解析器恢复，停止客户端前确认系统代理不再指向停止的端口。订阅更新导致的问题则恢复对应分组备份，不必连同无关的本地规则一起删除。回退范围越精确，越容易保存已经验证正确的部分。

当问题仍无法定位时，整理客户端名称、操作系统、入口模式、内核类型、复现步骤和脱敏后的日志片段，再对照运行日志报错定位方法逐项检查。若回退到最初基线仍不能连接，先回到快速上手教程重新验证基础链路。配置维护的终点不是启用更多选项，而是每个选项都有明确用途、可观察结果和可靠的撤回方法。