V2Ray 进阶配置手册

建立可以单独更新的订阅分组

订阅链接是一份配置清单的入口，不是客户端自身提供的连接服务。导入之前先确认链接来源可信、仍在有效期内，并且没有把账户管理页面的地址误当作订阅地址。在 v2rayN 中打开“订阅分组”，进入“订阅分组设置”，新建分组，填写容易辨认的备注与订阅地址，再保存。菜单的具体排列可能随界面调整，但“分组设置”与“更新订阅”是两项不同操作：保存地址只建立来源记录，执行更新才会获取并解析服务器配置。

分组备注宜体现来源或用途，例如“主要订阅”“备用订阅”“手工配置”。不要只写日期，也不要把账户密码写进备注。建立分组后，回到主窗口，选中需要更新的分组，再从“订阅分组”菜单执行相应的更新操作。第一次导入建议只更新一个分组，观察是否出现新的服务器条目，确认协议、地址和传输配置能够被识别，再添加第二个来源。这样出错时可以明确是哪次导入带来了变化。

把显示过滤与配置修改分开

主窗口中的分组切换、搜索框和过滤功能通常影响当前列表显示，不会自动给流量添加分流规则。按备注搜索时，先输入稳定的短词，再检查是否同时启用了分组限制。列表突然为空，可能只是“当前分组”和“搜索条件”共同缩小了范围，不代表订阅内容已经被删除。先清空搜索、切回全部分组，再判断是否需要重新导入。不要在尚未确认筛选状态时反复新增相同订阅，否则很容易制造重复条目。

如果客户端提供订阅级过滤表达式，应先确认该字段是包含条件、排除条件还是备注改写规则，不能把三种用途混在一起。只有明确标注支持正则表达式的字段，才使用正则语法。例如 ^(工作|备用)- 匹配以指定前缀开头的备注；它不会检查服务器是否可用，也不会理解地区名称。先用普通搜索验证目标范围，再把条件移入订阅设置。表达式保存后通常需要重新更新订阅，才能观察导入结果的变化。

更新失败时检查获取路径

订阅地址能在浏览器打开，不代表客户端使用相同的网络路径。先检查链接是否完整，尤其是复制时带入的换行、空格与末尾标点。再区分普通更新和通过代理更新：后者依赖一个已经可用的代理出站，如果当前没有可用服务器，就可能形成“必须先更新才能连接、必须先连接才能更新”的循环。遇到这种情况，优先使用可直连的订阅入口，或恢复此前已经验证可用的配置，而不是连续切换多个网络开关。

返回内容也需要判断。登录页面、错误提示和空白响应都不是有效的订阅清单；分享链接与订阅地址也不属于同一种入口。单条分享链接应使用客户端相应的剪贴板导入功能，不能仅因它能被复制就填入订阅地址栏。导入过程的入口区别可参阅订阅链接导入教程。排查时只记录错误类型、分组名称与操作顺序，不要把完整订阅地址贴进公开截图，因为其中可能包含账户凭据。

整理结束后应有一个明确结果：每个订阅来源都有独立分组，手工服务器与订阅服务器分开保存，关闭过滤后能看到完整列表。此时再选择一个已知可用的服务器进行连接验证。服务器是否显示、是否被选中、是否实际用于出站，是三个不同状态；后续路由配置只应建立在这些状态已经确认的基础上。

先理解规则顺序和默认出站

路由处理的是已经进入内核的连接。应用没有使用系统代理，也没有被 TUN 接管时，调整路由不会改变它的访问路径。进入 v2rayN 的“路由”或相关路由设置界面后，先确认当前使用哪个规则集，再检查规则顺序。对 Xray 常见的字段路由而言，规则通常从上到下匹配，首次命中后选择对应出站。因此，具体域名的例外应放在宽泛的域名集合之前，宽泛的最终规则应放在末尾，不能靠备注名称推断优先级。

同一条字段规则中，不同条件字段通常需要同时成立；同一字段中的多个值通常表示任意一个匹配即可。例如同时填写域名与端口，意味着目标既符合域名条件，又符合端口条件。若原意是“这些域名或这些端口”，应拆成独立规则。没有命中规则时，原生 Xray 配置通常使用首个出站作为默认出站；图形客户端还可能自动生成兜底规则，所以必须检查实际生成结果，不能只看自定义部分。

域名集合、地址集合与解析策略

geosite:cn 是域名集合引用，geoip:private 是私有地址集合引用。前者依赖域名规则数据，后者依赖地址规则数据；它们不是在线服务名称，也不会自动补齐缺少的数据文件。域名规则只有在内核知道目标域名时才能匹配。如果入口只提交 IP，且没有可靠的域名恢复或嗅探信息，就不能假定域名规则一定生效。反过来，IP 规则对域名目标是否有效，还与路由的域名解析策略有关。

下面的 JSON 是 Xray 顶层配置合并片段，用于演示私有地址直连、指定域名直连与广告域名阻断。示例将直连放在首个出站，因此未命中的连接也会直连；它不是完整的代理配置。已有配置包含同名出站时应复用，而不是重复定义。图形客户端用户优先在规则编辑器中建立等价规则，并核对客户端生成的标签，不要把整段 JSON 填进只接收规则数组的文本框。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:example.com", "geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  },
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

按一个目标验证，而不是一次导入大量规则

验证路由时，先选一个容易复现的目标，写下预期出站，再观察日志中的实际出站标签。新规则保存后，按客户端要求重载配置或重启核心，并关闭应用已有连接再重试。长连接可能继续复用旧路径，浏览器缓存也可能让页面看似没有变化；仅刷新页面不一定能证明新规则已经被使用。若规则未命中，依次检查当前规则集、规则位置、目标域名格式、数据文件可用性与入口提供的信息。

局域网设备、共享打印机与内部服务应优先按具体地址范围检查，不要为了修复一个局域网访问问题直接把所有流量改为直连。某些内部域名只在单位网络的 DNS 中存在，需要同时安排解析和路由。直连规则命中并不意味着 DNS 一定正确，域名解析成功也不意味着实际连接走对了出站。把日志中的目标、命中条件与出站标签一起记录，才能区分规则问题和解析问题。

最后保留一份小而明确的规则集作为回退基线。每次新增一类规则后检查普通网页、局域网资源和需要特殊分流的目标。若仅某个域名异常，应添加局部例外或修正规则顺序，不要通过清空整个规则集处理。规则数量越多，越需要写清用途；一个无法说明匹配范围的宽泛规则，往往比缺少规则更难排查。

先画清一次域名查询经过哪里

DNS 把域名转换为地址，但一台设备上可能同时存在多条解析路径。系统解析器服务普通应用；浏览器可能启用自己的安全 DNS；代理内核也可能为路由判断、直连出站或上游连接发起解析。客户端中填写“远程 DNS”，不代表所有应用都已使用它。开始调整前，先判断目标应用把域名交给代理，还是先在本地解析成 IP，再把地址交给代理。两种入口提供给路由的信息不同，排查方式也不同。

在系统代理模式下，支持代理的应用往往能把域名一并交给本地代理，但具体行为仍由应用和协议决定。TUN 接管后，系统的 DNS 请求是否进入客户端，还取决于虚拟网卡、DNS 接管和排除设置。浏览器内置的加密解析则可能绕开系统 DNS 入口。为了建立可比较的测试环境，可以暂时让浏览器使用系统解析，确认基础路径后再单独评估其安全 DNS 设置，避免同时改动两层解析器。

服务器地址、查询类型与路由不是同一个参数

选择 DNS 服务器时，应考虑当前网络能否访问、内部域名能否解析，以及查询流量应该走哪条路径。填写 1.1.1.1 只是指定一个公共解析器地址，不会自动要求查询通过代理。加密 DNS 可以保护设备到解析器之间的查询传输，但它也需要建立网络连接；若解析器使用域名地址，还可能先遇到引导解析问题。遇到启动阶段就无法解析的情况，应先验证解析器自身的可达性，而不是继续叠加更多备用地址。

下面是 Xray 的 DNS 顶层配置片段，只展示单个服务器与 IPv4 查询策略。它不会创建流量入口，也不会自动改变系统 DNS。仅在确认当前内核支持相应字段后合并；由客户端生成配置时，应优先使用客户端提供的 DNS 设置项。使用 UseIPv4 适合隔离 IPv6 路径问题，但它不是所有网络的长期推荐值，依赖 IPv6 的服务可能因此失去可用地址。

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

分流解析与缓存的边界

需要访问内部域名时，应保留能回答该域名的内部解析器，再按内核支持的域名条件安排查询。公共 DNS 通常不知道单位内部的主机名称。分流 DNS 的目标不是让每个域名都询问全部服务器，而是让特定域名交给合适的解析器，并明白首选失败后是否允许回退。不同内核对服务器选择、回退与缓存的字段定义并不相同，不应从其他配置格式复制同名字段后直接使用。

修改解析器之后，旧地址可能仍留在系统缓存、浏览器缓存和应用连接池中。先重启目标应用，再按系统方法清理解析缓存，必要时重载客户端核心。不要把缓存尚未过期误判为设置无效，也不要只凭一次地址变化判断解析质量。验证时同时记录是否解析成功、得到的地址类型、最终连接是否成功。如果域名能解析但目标地址连接失败，应转到路由或网络路径排查，而不是继续替换 DNS。

还应区分 DNS 失败和证书错误。系统时间不正确、目标域名与证书不符，或应用连接到了内部拦截页面，都可能表现为网页打不开，但更换解析器未必有帮助。对于固定域名覆盖，应记录维护原因与恢复条件，避免将临时地址长期写死。完整的 DNS 配置不仅要能返回地址，还要与路由、入口和网络环境相互一致。

先有可用出站，再启用虚拟网卡

TUN 通过虚拟网络接口接收符合系统路由条件的数据包，适合处理不读取系统代理设置的应用。它与 HTTP、SOCKS 本地监听属于不同入口方式，但接管后的流量仍需要由路由规则选择出站。启用之前，先在普通系统代理模式下验证服务器可以建立连接、DNS 能够工作。若最基础的连接尚未成功就开启 TUN，问题会同时涉及虚拟网卡、权限、解析和路由，难以判断最初故障的位置。

在 v2rayN 中找到“启用 TUN”相关开关前，先确认客户端的安装位置稳定，所需核心与辅助组件完整，并按当前平台要求授予必要权限。Windows 可能需要管理员权限以创建接口或调整路由；macOS 与 Linux 的权限方式取决于客户端实现。不要把其他平台的权限命令直接套用。各平台安装入口见客户端下载页，首次运行的基础步骤见入门指南。

建立单一入口的测试条件

第一次测试 TUN 时，可以先清除系统代理，让目标应用只通过 TUN 接管，以减少重复入口带来的干扰。这不是说两种模式永远不能并用，而是排错阶段应使路径尽量单一。启用后检查客户端日志是否显示接口初始化失败、权限不足或路由设置失败。系统中看见虚拟网卡，并不代表 DNS 接管和出站都已经成功；还需要分别验证域名访问、普通连接与局域网资源。

其他 VPN、虚拟网卡工具、容器网络和企业安全软件可能同时修改系统路由。出现全部网络中断时，应先关闭 TUN，观察是否恢复，再逐个检查这些并行组件。不要在多个接管工具同时运行时反复切换默认网关。需要保留单位网络或特定网段直连时，应使用客户端支持的排除路由或规则，并核对这些规则作用于系统接管层还是内核分流层。两者名称相近，发生位置却不相同。

检查 DNS、局域网与 UDP

TUN 的常见边界是 DNS 请求没有进入预期解析路径。若直接访问地址可用而域名失败，先检查虚拟网卡使用的 DNS、客户端的 DNS 接管方式和应用自己的解析设置。不要一开始就打开 FakeDNS；真实地址解析可以作为更容易观察的基线。局域网访问异常时，检查私有地址是否被正确排除或直连，尤其注意单位内部使用的非典型网段，以及只能通过特定接口到达的内部服务。

部分应用使用 UDP，但入口能够接收 UDP，不代表远端服务器、传输配置和整个网络路径都支持相同的流量。网页正常而语音或其他 UDP 功能异常时，应单独核对协议能力、出站配置和防火墙规则，不能仅凭 TUN 开关判断已经覆盖所有应用。MTU 也不宜随意修改；只有出现特定网络下大数据传输停滞、连接建立但持续传输失败等可复现现象时，才在记录原值后按单一变量测试。

保留明确的退出与恢复步骤

关闭 TUN 后，检查普通网络是否恢复，再确认系统代理是否仍指向本地端口。客户端已经退出而系统代理还在使用停止监听的端口，会造成应用继续无法访问。若接口或路由没有恢复，先正常重启客户端并再次关闭接管，必要时按系统网络管理方式检查残留状态。不要批量删除不认识的路由，也不要随意移除系统虚拟适配器，因为其中可能包含其他软件正常使用的接口。

完成配置后，用固定顺序复测：普通网页、需要域名的目标、局域网资源、需要 UDP 的应用，最后再观察休眠唤醒与网络切换。移动办公环境下，网络从有线切到无线会改变接口和路由，原本正常的接管可能需要重新初始化。只有这些场景都能解释清楚，才适合将 TUN 作为日常入口，而不是把它当作遇到任何连接问题时都要打开的总开关。

理解合成地址在连接中的位置

普通 DNS 查询返回目标的真实地址，应用随后向该地址发起连接。FakeDNS 则为域名分配池内的合成地址，并由内核保存域名与合成地址的对应关系。应用连接这个地址时，接管链路需要将请求送回掌握映射的内核，内核才能恢复域名并继续路由或出站。它的主要作用是保留域名信息，而不是让目标服务器变快，也不是把所有 DNS 查询自动转换为远端解析。

这种机制要求解析路径与连接路径闭环。如果系统收到合成地址后，后续连接却绕过客户端，就会尝试访问并不存在于公网的目标；如果地址由一个实例分配，连接却进入另一个没有映射记录的实例，也可能无法恢复域名。因此，不应仅复制一个地址池配置就认定 FakeDNS 已启用成功。必须同时检查 DNS 查询如何进入内核、应用数据包如何接管，以及对应入站是否具备所需的域名恢复能力。

地址池、解析器与嗅探需要配套

下面展示 Xray 顶层配置中的 FakeDNS 地址池和 DNS 服务器片段。示例使用 198.18.0.0/15 内的地址作为合成池；这不是可向目标服务器直接连接的公网地址范围。该片段仍需要与实际入站的 FakeDNS 恢复设置配套，不能独立替代客户端生成的 TUN 配置。如果客户端已有“启用 FakeDNS”设置，优先使用其整合流程，避免在不同配置层重复声明地址池。

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

对于支持相应字段的 Xray 入站，嗅探配置中的 destOverride 可以包含 fakedns。它的用途是从合成地址恢复目标域名，不等于普通 HTTP 或 TLS 嗅探。普通嗅探尝试从连接数据中识别主机名，FakeDNS 恢复依赖此前建立的映射。入站的其他设置仍须保留，不能为了加入嗅探而覆盖协议、监听地址和端口。不同核心与接管实现的写法不同，应以实际生成配置为准。

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

切换前后处理缓存与绕行

启用 FakeDNS 后，应用可能仍缓存此前获得的真实地址；关闭后，也可能继续保留旧的合成地址。测试时先结束目标应用连接，再重启应用，必要时清理系统 DNS 缓存并重载核心。否则同一域名的多次访问可能走不同路径，看起来像规则偶尔生效。尤其不要在客户端重启、映射表丢失之后，继续让应用使用此前缓存的合成地址；这种失败不一定意味着订阅或服务器发生了变化。

需要绕过接管的应用应谨慎处理。如果一个应用取得了 FakeDNS 的合成地址，却被进程排除或系统路由排除，它将无法依靠普通网络访问该地址。内部网络若恰好使用与合成池冲突的地址，也需要调整方案。某些直接检查解析结果、要求真实目标地址或自行实施连接验证的应用，可能不适合使用合成解析；可对这些目标保留真实 DNS 路径，而不是继续叠加更宽泛的接管规则。

验证应从一个普通域名开始。先确认查询确实由 FakeDNS 回答，再检查连接进入预期入站，最后查看日志中是否恢复了域名、是否命中对应路由。若真实 DNS 模式正常、FakeDNS 模式失败，就保留原服务器与路由不动，只检查映射链路。这样能把问题范围限定在解析与入口之间，不必重新导入订阅。确认实际需求只是普通网页访问时，也可以保留真实 DNS，减少需要维护的配置环节。

按来源建组，不按临时显示结果建组

多订阅管理的第一步不是一次导入更多地址，而是让每条配置都能追溯来源。建议每个订阅地址使用独立分组，将手工服务器另放一组，再用备注或过滤条件组织日常显示。不要因为两个订阅包含相似名称就把它们混进同一个来源记录。订阅更新、过滤条件与上游变动都以来源为单位发生，分组混杂后很难判断条目消失是上游删除、过滤条件变化，还是另一个订阅覆盖了显示结果。

建立简单的维护记录即可：分组用途、是否允许自动更新、更新依赖直连还是代理，以及恢复时使用哪个已知可用配置。记录可以保存在本地文档，但订阅地址应作为敏感信息单独保护。若客户端提供配置导出或备份，先确认导出范围是否包含订阅凭据、服务器认证与自定义规则。向别人分享排错材料时，只保留字段名称和错误类型，不要直接发送整个用户数据目录。

更新顺序与当前选中服务器

更新可能增加条目、移除条目，也可能重新生成本地标识。当前选中的服务器如果被上游删除或替换，客户端之后的选择行为取决于实现，不能假定会始终停留在同一个服务器。重要使用时段之前，先更新一个分组，确认当前选择仍存在，再建立一次新连接。服务器备注相同也不能证明配置相同，应检查协议、地址、端口、传输与安全设置是否仍符合预期。

自动更新适合已经验证稳定的来源，但需要考虑设备休眠、网络切换与更新路径。将所有订阅设置为同一时刻通过当前代理更新，可能在该代理不可用时一起失败。排错期间可暂时改为手动更新，一次只处理一个分组；恢复后再按需要启用自动更新。没有明确需求时，不必追求非常频繁的刷新。刷新失败也不意味着已有本地配置立即失效，应先验证现有出站是否仍可使用。

去重、过滤与手工修改

相同服务器可能出现在多个来源里，但“名称相同”不是可靠的去重条件。不同认证、不同传输方式或不同 TLS 参数可能指向同一地址，却具有不同用途。相反，名称不同的条目也可能是同一配置。使用客户端去重功能前，应先查看它比较哪些字段，并保留恢复副本。若只为了简化日常列表，优先通过分组和搜索减少显示，而不是删除自己尚未理解的配置。

订阅内容属于上游维护数据。本地临时调整某个服务器的传输参数，下次更新时可能被覆盖；需要长期使用的派生配置，应复制到手工分组并写明来源与修改原因。不要直接把上游生成的配置文件当作唯一工作文件反复编辑，因为客户端重载时也可能重新生成它。路由与 DNS 尽量放在客户端支持的独立设置层，让订阅只负责服务器参数，以减少更新时互相覆盖的范围。

备用分组不等于自动故障切换

在主窗口增加备用订阅，只是增加可选配置来源，并没有自动建立健康检查、负载均衡或故障切换机制。若没有明确配置相关功能，当前服务器失败后通常仍需手动选择。即使某个界面支持测速或自动选择，也应确认测试使用什么目标、是否检查实际连接，以及切换是否影响已经建立的会话。一次测试成功不能证明所有应用都可用，更不能替代协议与网络路径的兼容检查。

维护多来源时，最有价值的是可重复的切换步骤：先记录当前分组与服务器，选择备用配置，重新建立连接，再测试同一个目标。若备用可用，就保留原来源不动，单独排查其更新与服务器参数；若全部来源同时失败，则更应检查本地入口、DNS、权限和系统网络。把来源问题与本机环境问题分开，可以避免通过不断新增订阅来掩盖真正的配置错误。

区分图形客户端、核心与配置格式

v2rayN 是图形客户端，负责管理服务器、生成配置和启动核心；真正处理协议与路由的是所选核心及其配套组件。相似的界面字段不保证底层配置格式相同。编辑之前先在客户端设置或启动日志中确认当前核心类型，再判断某项功能由哪个组件负责。尤其是 TUN 接管与普通代理连接，可能并非由同一个处理环节完成，不能仅凭服务器协议名称推断整条链路的实现。

Android 上，v2rayNG 以 Xray 内核为主要技术路径，v2flyNG 则属于 V2Fly 路径的备选客户端。选型时应先看配置所需协议与功能，而不是仅比较名称。不同内核对协议、安全扩展和配置字段的支持会有差异，不能将一份复杂的 Xray 自定义配置直接交给其他内核运行。生态关系与功能取舍可参阅Xray 与 V2Fly 内核区别。

出站标签是路由引用，不是显示备注

自定义出站至少需要清晰的标签、受支持的协议与对应参数。路由中的 outboundTag 必须与实际出站的 tag 完全一致，大小写也应保持一致。服务器在主窗口中的备注不一定就是生成配置中的标签。保存前检查客户端是否保留该出站、是否已经存在同名标签，以及自定义规则究竟合并到哪里。重复标签或指向不存在标签的规则，应在启动阶段优先处理。

下面的 Xray 出站对象演示将连接转交给本机另一个 SOCKS 服务，监听地址为 127.0.0.1:10810。它只适用于该服务确实已经启动且允许本机连接的环境，不会自动创建第二个代理。应将对象放入受支持的出站数组，再让具体路由引用 local-socks。如果只是使用普通订阅服务器，通常没有必要为了连接而新增这一层。

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

防止转发环路与参数覆盖

本地转发最需要检查的是端口对应关系。若当前核心自己的 SOCKS 入站也监听同一端口，而出站又指向该端口，就可能把连接送回自己，形成环路。另一个服务若也通过当前客户端出站，同样可能构成跨进程循环。配置之前先写下每一段的监听地址、监听端口和下一跳，确保路径最终能到达真实网络出口。不要只检查端口是否有进程监听，还要确认监听进程是谁。

对于由客户端管理的自定义配置，应优先使用其提供的自定义服务器、配置导入或规则编辑入口。直接编辑运行时生成文件，可能在下一次切换服务器或重启核心时被覆盖。若确实需要维护完整配置，应明确哪些设置还受主窗口控制，哪些只能在配置文件中调整；例如主界面路由选择可能不再影响完整自定义配置。不要同时维护两套看似相同、实际却互相覆盖的参数来源。

把兼容性问题限制在最小范围

核心无法启动时，先查看第一条明确错误，区分 JSON 语法、未知字段、缺少文件、标签引用和端口占用。不要在核心尚未启动时更换 DNS 或服务器。若需要切换核心，先保留当前可用配置，再使用最简单且兼容的连接验证基础能力，之后逐项恢复路由、解析与自定义出站。客户端配置导入成功，只表示界面读取了内容，不保证当前核心能够执行所有字段。

自定义出站投入日常使用前，应测试目标路由命中、下一跳可达、应用重连和关闭恢复。若链路依赖另一个本地服务，还要测试该服务停止后的错误表现，避免把明确的本地依赖失败误判为远端故障。出站设计的重点是可解释和可恢复：每个标签有用途，每个端口有归属，每次切换都能回到已经验证的基础配置。

先确定故障发生在哪个阶段

“无法连接”可能意味着核心没有启动、应用没有使用代理、域名解析失败、规则选错出站，或远端连接无法建立。先记录最小复现过程：当前客户端、核心类型、入口模式、选择的服务器、目标应用和出现错误的操作。再尝试一个不同目标，判断是单个域名异常还是全部连接失败。如果直接网络本身已经不可用，先恢复系统网络，再继续检查代理配置，避免把底层断网误当作订阅问题。

核心启动失败时，首先查看日志开头的错误。端口被占用、配置语法错误和权限不足通常在启动阶段就有线索。端口号应以当前设置为准，不能因为常见 SOCKS 端口是 10808、HTTP 端口是 10809，就认定设备实际使用相同值。若更改端口，要同步更新手工配置了代理的应用；系统代理自动设置与应用内部手动代理也可能是两套独立记录。

先验证入口，再看远端连接

系统代理开启后，只有读取系统设置的应用才会自动使用它。对一个不支持系统代理的程序，网页测试成功并不能证明该程序已经进入客户端。可以先使用明确支持代理的应用验证本地入口，再决定是否需要 TUN。TUN 场景则检查接口、权限与接管范围。若客户端日志完全没有目标连接的记录，优先排查入口，而不是改远端协议参数。入口没有流量时，后续路由自然没有匹配机会。

已经确认流量进入后，再区分解析错误和连接错误。域名失败而已知地址的测试路径正常，可以检查 DNS；但直接用地址访问 HTTPS 可能触发证书与主机名问题，不能把这种错误当作 DNS 结论。更可靠的方法是结合日志查看解析结果和实际连接目标。若解析得到地址但连接超时，继续检查出站与网络；若立即报告规则或标签错误，先修复配置引用。

用症状缩小范围，不靠连续切换开关

如果问题只在启用 FakeDNS 后出现，保持服务器和路由不变，先回到真实 DNS 验证；只在 TUN 下出现，就保留普通代理入口作为对照。若更新订阅后发生，检查当前服务器是否被替换，以及上游参数是否改变。若切换核心后发生，则从字段兼容性和生成配置开始检查。每个分支都应有明确的对照条件，而不是同时换服务器、换 DNS、重设路由后再猜是哪一步有效。

查看日志时关注错误类别与发生顺序。连接被拒绝通常说明目标端口没有接受连接或被明确拒绝，超时则可能涉及路径、过滤或远端未响应；两者都不能单独证明服务器配置的所有字段正确。TLS 错误还应检查系统时间、服务器名称和证书验证设置。不要为了消除错误提示随意放宽安全验证；应先让域名、传输和服务端配置保持一致，再重新连接。

建立可以复用的回退基线

一份可恢复基线应包括：能启动的核心、已验证的服务器、明确的本地入口、简单路由和可达 DNS。每次修改前，记录原值与预期结果；失败后恢复原值，而不是在错误状态上继续叠加调整。涉及 TUN 与 FakeDNS 时，恢复还包括应用缓存和系统接管状态。恢复完成后重新建立连接，不能仅凭开关已经关闭就认定旧路径已经清理。

完成排错后，把最终有效的改动缩减到必要范围，并删除临时测试规则。快速恢复基础连接可回到入门指南重新核对主线；需要更换安装平台或客户端时，使用下载页对应入口。日常维护应沿用同一套验证顺序：先看核心是否运行，再看流量是否进入，接着检查解析、路由和出站。这样新问题出现时，仍能沿着清晰的配置层次定位，而不必从头重建全部设置。