V2Ray 从零到精通：客户端、分流与 TUN

01 / concepts

核心概念：先画清一条流量链路

客户端、内核与配置文件分别负责什么

V2Ray 使用中最容易混淆的三个对象是图形客户端、代理内核和配置数据。v2rayN、v2rayNG、v2flyNG 属于图形客户端，负责提供订阅导入、节点选择、系统代理、路由规则和运行日志等操作界面。Xray、V2Fly 等内核负责真正处理连接、协议、传输与路由。配置文件则把监听端口、出站参数、域名规则和 DNS 策略交给内核。界面上的一次切换，最终通常会转换成一组配置字段，再由内核重新加载。

因此，排查问题时不要只看“客户端是否启动”。更准确的顺序是：配置是否存在，当前配置是否被选中，内核是否成功加载，本地入站端口是否开始监听，应用流量是否进入该端口，路由规则是否选中正确出站，远端连接是否完成。任意一环中断，浏览器里都会表现为无法访问，但对应的修复方式完全不同。建立这条链路，是后续所有章节的判断基础。

inbounds、outbounds 与 routing 的关系

inbounds 定义流量怎样进入内核。桌面客户端常见的是本机 SOCKS 与 HTTP 监听端口；启用 TUN 后，还会增加负责接收系统网络层流量的虚拟入口。outbounds 定义流量从哪里离开，既可以是某个远端配置，也可以是直接连接或阻断出站。routing 位于两者之间，按照域名、IP、端口、协议或入站标签判断应当使用哪条出站。

可以把一次请求理解为“应用 → 本地入站 → 路由判断 → 目标出站”。例如浏览器设置 SOCKS 端口后，请求先进入本机监听；路由规则发现目标属于直连集合，就交给 direct 出站；其他请求则交给当前远端出站。规则中使用的 tag 是各段之间的连接标识，名称可以自定义，但引用必须一致。若规则写了 outboundTag: "direct"，配置中就必须存在标签为 direct 的出站。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

配置、节点与订阅不是同一个对象

单个节点是一组连接参数，通常包含服务器地址、端口、用户标识、协议和传输设置。订阅是一项可更新的数据来源，可能返回多个节点，也可能附带分组信息。客户端配置则范围更大：除节点之外，还包含本地端口、代理模式、DNS、路由、日志和界面偏好。删除订阅不一定立即删除已经生成的本地配置，切换节点也不会自动改变系统代理模式。操作前先确认正在处理的是订阅来源、配置列表还是当前运行实例。

需要逐字段理解配置结构时，可继续阅读config.json 结构逐段解析。该文将入站、出站和路由标签放在一份最小配置中对照说明。

02 / client and install

选择客户端与安装：先匹配平台，再确认运行条件

三款客户端怎样分工

桌面平台首选 v2rayN。它覆盖 Windows、macOS 与 Linux，统一提供配置列表、订阅管理、系统代理、路由与 TUN 等常用入口。Windows 下载页同时提供桌面版与经典 WPF 版：桌面版采用跨平台界面，适合希望在不同桌面系统间保持相近操作路径的用户；WPF 版面向 Windows 经典使用习惯，界面和系统集成路径更集中。两者的重点差异在界面框架和系统适配，不是节点协议能力的简单高低关系。

Android 平台优先选择 v2rayNG，使用 Xray 内核，常见订阅、分应用代理、路由和连接测试都可在图形界面完成。v2flyNG 使用 V2Fly 内核，可作为需要该内核实现时的备选。两款 Android 客户端的配置列表并不共享，切换客户端时需要重新导入订阅或配置。不要把某个客户端生成的内部数据库文件直接复制到另一款客户端；通用的订阅链接、分享链接或标准配置更适合迁移。

安装前检查系统架构与旧实例

下载之前先确认处理器架构和系统类型。macOS 可在“关于本机”查看芯片名称；Linux 可执行 uname -m，输出 x86_64 对应 x64，输出 aarch64 对应 arm64；Android 近年的主流设备通常采用 arm64，但设备信息不明确时可选择通用包。安装包架构不匹配时，常见表现是无法启动、安装器拒绝运行或启动后立即退出，这类问题不应通过修改节点参数处理。

升级或更换界面版本前，先退出正在运行的旧实例。桌面客户端可能保留托盘进程，关闭主窗口不一定等于结束进程；应在托盘菜单执行退出，或通过系统任务管理工具确认进程已停止。若旧实例仍占用本地端口，新实例会在日志中报告监听失败。保留现有订阅地址、路由规则和自定义端口记录，再进行迁移，可避免安装完成后无法判断哪些设置来自旧环境。

首次启动后的最小检查

首次打开客户端时，先不要同时启用系统代理和 TUN。正确顺序是：确认客户端界面可用，导入一项配置，选中该配置，启动内核，查看日志中是否出现本地监听成功，再开启系统代理测试。分阶段操作可以把“程序启动问题”和“网络接管问题”分开。Windows 若遇到运行环境提示，应按客户端页面给出的组件要求补齐系统运行库；Linux 安装后若菜单入口未出现，可从终端启动一次并读取错误信息；macOS 首次启动应在系统安全设置中确认应用打开状态。

安装完成不代表代理已经生效。客户端启动、内核运行、系统代理开启是三种不同状态。只打开界面但没有启动配置，本地端口不会监听；内核运行但系统代理关闭时，只有手动指定代理的应用会进入客户端；系统代理已经设置但内核停止时，应用会把请求送到一个没有服务的端口。理解这三种状态，可以避免将安装问题误判为远端连接问题。

Windows 平台需要更完整的安装路径与常见运行环境处理，可参阅Windows 安装 v2rayN 全流程；两种界面版本的选型差异见v2rayN 桌面版与经典 WPF 版差异对比。

03 / subscription

订阅与配置管理：分清导入、更新、选择和运行

订阅导入后的四个动作

添加订阅通常只是在客户端中保存一个数据来源。完整流程包含四个独立动作：保存订阅信息、更新订阅、从结果中选择配置、启动所选配置。部分客户端会在保存后立即更新，部分客户端需要手动执行“更新订阅”；因此，添加成功但配置列表为空时，先检查是否已经执行更新，而不是立即删除重加。更新后还要确认当前分组和筛选条件，避免配置已经存在却被列表筛选隐藏。

订阅名称只用于本地识别，不参与连接。建议使用能够区分用途和来源的短名称，不要把日期写进名称后频繁修改。多个订阅同时存在时，名称应帮助判断更新范围。更新操作可能替换该订阅生成的旧配置，手工改过的节点参数也可能被下一次更新覆盖。需要长期保留的本地改动，应放在客户端提供的路由、DNS 或全局设置中；若确实要修改单个配置，应先复制为本地独立项并标明用途。

更新订阅时怎样保护当前可用状态

更新前先观察当前配置名称和运行状态。更新完成后，客户端可能根据唯一标识保留选择，也可能因为配置被替换而回到其他条目。最稳妥的做法是更新后重新确认当前配置，再执行一次连接测试。若订阅返回空内容，不要连续覆盖和清理全部配置；先检查客户端日志中的 HTTP 状态、响应格式与解析提示，并保留上一次可用配置用于对照。

更新失败可以分成“地址无法请求”“请求成功但内容无法解析”“解析成功但没有可用配置”三类。第一类重点检查网络路径、系统时间和订阅地址是否完整；第二类检查返回内容是否属于客户端支持的订阅格式，是否把网页地址误当成订阅地址；第三类检查订阅分组、过滤规则和客户端内核兼容性。日志中若能看到请求成功但解析数量为零，反复更换代理模式通常没有帮助，应回到订阅内容与格式这一层。

分享链接、JSON 配置与订阅的适用边界

单条分享链接适合导入一个明确配置，便于逐项核对地址、端口和传输设置；JSON 配置适合需要完整控制入站、出站、路由与 DNS 的场景；订阅适合由同一来源维护多项配置并周期更新。三者可以同时存在，但应避免让多个来源生成名称相同的配置，否则切换时很难判断正在运行哪一项。

手工导入 JSON 前，应先确认它是完整内核配置还是客户端可识别的配置片段。完整配置通常包含 inbounds、outbounds 等顶层字段，而分享链接只描述一条出站连接。图形客户端可能会根据自身设置重新生成入站和路由，因此直接编辑客户端运行时生成的临时文件，下一次启动时往往会被覆盖。需要持久化的设置应通过客户端界面、自定义配置入口或明确的配置文件管理功能完成。

订阅数据的基本管理边界

订阅地址本身可能包含访问标识，应只保存在需要使用的客户端中，不应发布到公开页面、日志截图或共享文档。诊断时若需要展示日志，应遮去完整订阅地址、服务器地址和用户标识，只保留错误类型、状态码和时间顺序。客户端的导出功能也可能包含连接参数，发送前应确认导出范围。

日常使用中，可把订阅更新与客户端升级分开执行。先在现有客户端环境验证订阅更新，再安排客户端升级；或先升级客户端并确认旧配置能运行，再更新订阅。两个变量同时改变时，一旦出现兼容问题，很难判断是解析器变化、内核变化还是订阅内容变化。稳定维护的关键不是频繁操作，而是让每次变更只有一个明确目标。

04 / proxy mode

代理模式与本地端口：决定哪些应用进入客户端

系统代理、手动代理与 TUN 的覆盖范围

系统代理是桌面平台最适合首次验证的模式。v2rayN 将系统代理地址设置为本机监听端口，遵循系统代理设置的浏览器和应用会把请求交给客户端。优点是行为清晰、关闭方便；边界是部分应用不读取系统代理，命令行工具和独立运行环境也可能使用自己的代理设置。遇到“浏览器可用、某个应用不可用”时，先检查该应用是否遵循系统代理，而不是直接判定配置失效。

手动代理适合精确测试。可在浏览器、开发工具或命令行进程中明确填写 127.0.0.1 与 SOCKS/HTTP 端口。它不会自动覆盖其他应用，便于判断本地入站是否工作。TUN 位于更靠近系统网络层的位置，能够接收更多不支持显式代理的流量，但也会引入虚拟网卡、路由表、DNS 接管和权限问题。正确学习顺序应当是先用系统代理跑通，再进入 TUN，而不是把 TUN 当作首次连接的默认开关。

SOCKS 与 HTTP 端口怎样选择

SOCKS 入站能够承载 TCP，并可在配置允许时处理 UDP；HTTP 代理主要面向支持 HTTP CONNECT 的应用。客户端常会同时创建两个本地端口，也可能提供混合入站。设置应用代理时必须让协议类型与端口对应：将 SOCKS 端口填入只接受 HTTP 代理的字段，会出现连接失败或协议错误；反过来同样如此。端口号没有固定必须值，关键是客户端实际监听值、系统代理值和应用设置三者一致。

本地监听地址通常设为 127.0.0.1，表示只接受本机连接。只有明确需要同一局域网其他设备接入时，才考虑允许局域网连接，并同步检查系统防火墙和访问边界。开放局域网监听后，不能只改地址而忽略认证与网络范围。对普通单机使用，保持本机监听更容易管理，也能减少局域网环境变化对故障判断的干扰。

端口冲突与残留系统代理

内核启动时如果提示地址已被使用，说明计划监听的端口已由其他进程占用。先退出旧客户端实例，再查找占用进程。Windows 可执行 netstat -ano | findstr :10808 获取进程标识；macOS 可执行 lsof -nP -iTCP:10808 -sTCP:LISTEN；Linux 可执行 ss -lntp | grep 10808。确认进程用途后再结束进程或修改客户端端口，不应看到占用就直接终止未知系统服务。

netstat -ano | findstr :10808
lsof -nP -iTCP:10808 -sTCP:LISTEN
ss -lntp | grep 10808

修改端口后，要同步修改系统代理或应用中的代理端口。只改客户端监听值而保留旧系统代理，会形成“客户端已运行，但应用仍连接旧端口”的状态。客户端异常退出后，系统代理也可能残留；此时即使内核不再运行，浏览器仍尝试连接本地代理。处理方法是重新打开客户端关闭系统代理，或在系统网络设置中手动恢复。完整的端口定位流程可参考端口被占用的定位与修改方法。

05 / routing

路由分流：用规则决定每类流量的出口

规则匹配顺序比规则数量更重要

路由规则通常自上而下匹配，命中后交给指定出站。规则越多不代表结果越准确；真正重要的是条件是否互斥、优先级是否合理、兜底出口是否明确。具体规则应放在宽泛规则之前。例如，一个域名既属于自定义直连列表，又会被后面的通用代理规则覆盖时，应让自定义规则优先出现。若客户端提供预设路由模式，先选择最接近目标的预设，再增加少量自定义规则，比从空白开始堆叠大量集合更容易维护。

常见条件包括域名、IP、端口、网络类型、协议和入站标签。域名规则适合按完整域名、后缀或 GeoSite 分类；IP 规则适合私有地址与 GeoIP 分类；端口规则适合特定服务；入站标签可让不同本地入口采用不同策略。不要把域名条件与最终解析出的 IP 条件视为完全等价。请求进入路由阶段时是否保留域名，与 DNS 流程和 domainStrategy 设置有关。

direct、proxy 与 block 三类出口

一套可读的路由通常至少区分三种结果：direct 表示直接连接，proxy 表示交给当前远端出站，block 表示阻断。名称只是标签，实际行为由对应出站协议决定。规则引用标签时必须与出站标签逐字一致。若界面允许选择“直连”“代理”“阻断”，客户端会代为维护标签；手写 JSON 时则需要自行保证引用关系。

私有地址一般应优先直连，以免访问路由器、打印机或局域网服务时绕行远端出站。需要阻断的流量应使用明确条件，避免使用过宽的域名关键字。最后保留一个可理解的兜底策略：没有命中规则的流量是默认走代理还是直接连接，应与客户端当前模式一致。故障排查时临时切换到较简单的全局策略，可以判断问题是否来自路由；验证完成后再恢复分流，不要长期依赖临时模式。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "protocol": ["bittorrent"],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy 与 DNS 的配合

AsIs 倾向于直接使用进入路由的域名进行匹配，不为 IP 规则额外解析；IPIfNonMatch 会在域名规则未命中时尝试解析，再继续匹配 IP 规则；IPOnDemand 会在遇到可能需要 IP 的规则时更积极地解析。选择哪一种取决于规则结构。域名规则为主时，AsIs 路径更直观；同时大量使用 GeoIP 条件时，IPIfNonMatch 更容易让 IP 规则参与判断，但也更依赖 DNS 结果。

DNS 与路由构成闭环：DNS 请求本身也需要选择出口，解析结果又会影响后续路由。若域名解析走了不合适的网络路径，可能得到不可达地址；若规则要求按 IP 判断但没有获得可用解析结果，规则就不会按预期命中。排查时应分别记录“域名由谁解析”“DNS 请求从哪条出站离开”“结果进入哪条路由规则”，不要只更换 DNS 地址而忽略出站路径。

GeoIP 与 GeoSite 的更新边界

GeoIP 根据 IP 地址归类，GeoSite 根据域名集合归类。两类数据库过旧时，新域名和地址段可能无法落入预期分类。更新后如果分流突然改变，应检查数据库版本变化带来的分类调整，而不是立即认定内核异常。自定义高优先级规则应保持数量有限，并记录添加原因；当数据库更新已经覆盖该场景时，可移除重复规则，避免后续出现冲突。

数据库的作用、更新入口与验证方法见GeoIP 与 GeoSite 数据库更新指南。对比多个客户端的路由能力和适用平台时，可查看客户端对比。

06 / tun

TUN 模式：从系统代理扩展到网络层接管

什么时候需要启用 TUN

TUN 模式通过虚拟网络接口接收系统流量，适合不读取系统代理设置的应用、需要 UDP 支持的程序，以及希望减少逐个应用配置工作的桌面环境。它不是连接质量增强开关，也不会自动修复错误的远端参数。若系统代理模式下连基本网页都无法通过，先解决配置、端口、DNS 或远端连接问题，再启用 TUN。否则新增的路由表和虚拟网卡只会增加排查变量。

启用前应完成三个基线测试：当前配置能够启动；系统代理下至少有一个应用能够稳定访问；客户端日志中没有持续的连接或解析错误。随后关闭系统代理或按客户端推荐方式处理两者关系，再开启 TUN。测试时先保留默认栈与默认 MTU，不要同时修改 DNS、严格路由、绕过规则和网卡参数。只有确认默认配置存在具体问题后，才调整对应选项。

虚拟网卡、路由表与权限

TUN 需要创建虚拟网络接口并修改系统路由，因此桌面系统通常要求相应权限。权限不足时，常见表现是虚拟网卡创建失败、路由添加失败或客户端显示已开启但没有流量进入。应从客户端日志确认具体失败步骤，再按系统权限模型处理。重复点击开关可能留下多个短暂接口或残余路由，使现象更复杂。

路由表决定哪些目标进入虚拟网卡，绕过规则则让局域网、特定地址或指定应用保持原路径。启用严格路由后，系统可能阻止未被明确处理的旁路流量，这有助于保持路径一致，但也可能影响本地开发环境、虚拟机或局域网服务。若启用后无法访问局域网设备，应先检查私有地址绕过和 direct 规则，而不是关闭所有分流。

MTU、网络栈与 UDP 问题

MTU 表示接口能够承载的数据包大小。设置过大时，某些网络路径可能无法正确分片，表现为小页面可打开、大文件或特定站点停滞；设置过小时会增加分包开销。没有明确证据时应保留客户端默认值。若怀疑 MTU，可对比不同网络环境、观察是否只在大响应或特定协议中复现，再逐步降低测试，每次记录修改值和结果。

不同 TUN 网络栈在兼容性、性能和系统集成方式上存在差异。选择时应先使用客户端推荐默认项，只有遇到明确的 UDP、休眠恢复或虚拟化冲突时才切换。切换网络栈后需要重新启动 TUN，并确认旧虚拟接口已经清理。Android 的 VPN 接管由系统提供，v2rayNG 与 v2flyNG 启动连接时会申请相应权限；若系统中已有其他使用同类接管机制的应用，同时运行可能产生互斥。

DNS 泄漏式误判与解析路径

TUN 开启后，DNS 请求可能由客户端接管，也可能仍由系统网络接口发出，取决于客户端配置。常见故障是域名打不开但直接访问已知 IP 有响应，这说明应优先检查 DNS，而不是远端协议。另一种情况是 DNS 能返回结果，但该结果经过路由后走错出口。排查需要同时查看 DNS 日志、路由命中和连接日志，三者时间应能对应起来。

若某些局域网域名依赖本地 DNS，应为这些域名保留本地解析路径，同时让公共域名按既定策略解析。不要用单一 DNS 服务器覆盖所有场景后再靠大量静态地址修补。企业网络、家庭局域网和公共网络切换时，本地 DNS 可达性也会变化，因此移动设备与笔记本应重点验证网络切换后的恢复行为。

TUN 启用后若整个系统立即失去连接，应先关闭 TUN，确认默认路由恢复，再检查日志中的权限、接口和路由添加错误。不要在网络完全中断时继续叠加 DNS 与分流修改，否则恢复路径会变得难以追踪。

07 / maintenance

日常维护与故障定位：按层收集证据

建立可重复的维护节奏

稳定使用依赖可回退的变更流程。客户端升级、内核更新、订阅更新、路由数据库更新和系统网络调整应分开执行。每次变更前记录当前客户端类型、所选配置、本地端口、代理模式、路由预设和 DNS 策略；变更后按相同测试清单验证。这样即使出现异常，也能明确比较前后差异。

订阅可以按实际变化频率更新，不需要在每次启动时反复刷新。GeoIP 与 GeoSite 应在分流规则出现明显分类偏差或按维护计划更新时处理。客户端升级前阅读界面中的迁移提示，确认配置存储位置和权限要求是否变化。更新完成后先使用原有配置验证，再引入新功能。把升级和重构配置放在同一次操作中，会失去清晰的回退点。

从日志判断故障所在层级

日志应按时间顺序阅读。启动阶段重点看配置解析、端口监听、内核进程和 TUN 接口；连接阶段重点看域名解析、路由命中、出站拨号和握手；运行阶段重点看超时、连接重置和网络切换。第一条关键错误通常比后续重复错误更有价值，因为后面的失败可能只是前一环节中断的结果。

配置解析错误常包含字段路径或 JSON 行列位置，应先修复语法和字段类型；监听错误通常指向端口占用或权限；解析错误指向 DNS 路径；连接超时说明请求已经尝试离开本机，但目标路径没有在时限内完成；握手错误则需要核对协议、传输和时间。不要只截取最后一行日志，诊断时至少保留启动前后和一次完整请求对应的连续片段。

最小化复现而不是同时重置所有设置

有效的复现环境应尽量简单：选择一项已知配置，使用默认本地端口，关闭自定义路由，先不开 TUN，只保留系统代理或单应用手动代理。若最小环境可用，再逐项恢复 DNS、路由、TUN 和应用规则；若最小环境仍失败，就集中检查配置参数、系统时间、端口和网络路径。这样可以把复杂问题拆成有限步骤。

“恢复默认”适合确认配置污染，但执行前应记录现有设置。直接清空全部配置会失去对照，也可能删除仍可用的订阅信息。更好的做法是建立独立测试配置或使用客户端提供的备份与复制功能。测试完成后，将确认有效的变更写入维护记录，包括修改项、原因、验证方式和回退方式。记录不需要很长，但必须能在下一次故障时还原判断过程。

网络切换、休眠和系统更新后的检查

笔记本从一个网络切换到另一个网络后，旧 DNS、虚拟网卡状态和路由缓存可能暂时保留。若切换后连接异常，先停止并重新启动当前配置；TUN 用户还应重新建立虚拟接口。系统从休眠恢复时，客户端界面可能仍显示运行，但底层网络接口已经变化，应以新请求日志而不是界面状态判断。

系统更新后出现问题，应检查防火墙权限、虚拟网卡驱动状态、系统代理是否被重置，以及客户端是否仍有创建网络接口的权限。Android 设备切换网络后，可停止并重新启动连接，让系统重新授予当前网络路径。任何平台都应避免在问题尚未复现稳定时连续更换多个配置，因为这会把系统状态变化与配置差异混在一起。

08 / advanced route

进阶路线：从界面配置过渡到可维护规则

第一阶段：能够解释当前配置

进阶不是先增加字段，而是能够解释现有配置。应当明确当前有哪些入站、每个入站监听哪个地址和端口、默认出站是哪一条、direct 与 block 如何定义、路由规则按什么顺序匹配、DNS 请求从哪里发出。可以从客户端导出的配置或运行日志中逐项核对，但不要直接修改临时生成文件。先把界面选项与最终字段建立对应关系，后续才能判断客户端升级后某项行为为何变化。

建议画一张自己的流量路径表：应用名称、进入方式、入站标签、匹配规则、目标出站、DNS 路径。表中每一列都应能从配置或日志找到依据。若某列只能凭感觉填写，说明该环节仍需要验证。完成这一步后，再处理复杂分应用、多入口或多出站场景，避免规则数量增加后失去可解释性。

第二阶段：用标签组织多入口与多出口

多入口适合把不同应用或用途隔离。例如一个 SOCKS 入站用于浏览器，另一个入站用于开发工具，再通过 inboundTag 指向不同出站。多出口则可把 direct、block 和多个远端连接组合起来。标签命名应表达职责，如 socks-browser、direct、block，不要使用难以回忆的临时编号。规则引用标签时，修改名称要同步更新全部引用。

多出口并不意味着需要复杂自动选择。先建立明确的静态规则，确认每类流量稳定进入预期出口，再考虑故障转移或负载策略。自动策略依赖健康检查、连接状态和内核能力，故障时也需要更多日志。若基础路由尚未稳定，增加自动策略只会让实际出口更难预测。

第三阶段：把 DNS 作为独立子系统维护

复杂配置中的 DNS 不应只是一个服务器地址。需要明确查询类型、域名分类、解析出口、缓存行为和回退条件。局域网域名可能需要本地 DNS，公共域名可以按路由策略选择解析路径，特定域名还可使用独立规则。任何拆分都应有实际需求，不要因为选项存在就全部启用。

验证 DNS 时，先确认请求由哪一层发起，再确认返回地址是否符合预期，最后确认该地址经过哪条路由。若只看解析结果，不看查询出口，可能忽略网络路径差异；若只看路由，不看结果，可能把错误地址造成的连接失败误判为分流问题。DNS 调整应与 GeoIP、GeoSite 更新分开进行，保证一次只改变一个判断来源。

第四阶段：建立配置变更与回退规范

长期维护的配置应保留可读注释记录，但标准 JSON 本身不接受注释，因此注释可以放在独立说明文档、客户端备注或变更记录中。每次修改记录目标、原值、新值、验证结果和回退步骤。对路由规则尤其要记录“为什么存在”，否则几个月后很容易把过期规则当成必要条件。

配置备份应包含订阅名称、自定义路由、DNS、监听端口和 TUN 选项，但保存位置要控制访问范围。恢复时不要一次导入所有旧状态；先恢复订阅与基本设置，确认可运行，再恢复路由和 TUN。跨平台迁移时只迁移通用逻辑，不要假定系统代理、虚拟网卡和权限设置能够直接复制。

第五阶段：形成固定验证清单

一份完整验证清单可以包含：客户端正常启动；内核配置加载成功；本地端口正在监听；系统代理或 TUN 状态符合预期；域名解析可用；私有地址保持直连；指定域名命中预期规则；网络切换后能够恢复；关闭客户端后系统代理与虚拟接口正确清理。清单中的每一项都应有具体观察方法，而不是只写“网络正常”。

遇到新问题时，先把现象归入配置、入站、DNS、路由、出站或系统接管中的一层，再使用本手册对应章节。快速上手操作可回到入门指南，重新选择安装包可进入客户端下载页，客户端能力差异可查看客户端对比。如果问题涉及配置结构、端口冲突或路由数据库，则分别使用本文链接的专题文章继续定位。