V2Ray 系统教程：从核心概念到进阶配置

// FOUNDATION

核心概念：客户端、内核、节点与订阅

先分清界面层与执行层

日常所说的“V2Ray 客户端”通常不是单一程序，而是图形界面、代理内核、配置文件和系统网络设置的组合。v2rayN、v2rayNG、v2flyNG 负责展示服务器列表、保存订阅、切换代理模式和读取日志；真正建立连接、解析协议并处理流量的是内核。v2rayN 可管理桌面系统上的相关内核，v2rayNG 以 Xray 内核为主要执行层，v2flyNG 则面向 V2Fly 内核。理解这一层关系后，排错时就不会把“界面按钮没有变化”“内核启动失败”和“远端服务器不可达”混成同一个问题。

图形客户端会根据界面中的选择生成运行配置，然后启动本地代理端口。浏览器或操作系统把请求交给这个本地端口，内核再依据协议、传输、安全参数和路由规则决定请求如何发出。因此，一个节点能否使用至少涉及四组条件：服务器地址能否解析，端口能否建立连接，认证参数是否一致，传输与安全设置是否相互匹配。任何一组不匹配，都可能表现为连接超时、握手失败或启动后无法访问目标站点。

节点不是订阅，订阅也不是代理开关

节点是一组具体连接参数，通常包含地址、端口、用户标识、协议类型、传输方式和安全设置。订阅则是一个可更新的数据入口，它能够一次返回多个节点及分组信息。把订阅添加到客户端，只代表客户端知道去哪里读取配置；还需要执行更新、选择一个活动服务器，并启用合适的代理模式，应用流量才会进入内核。导入成功后服务器列表为空，往往是尚未更新、订阅内容格式不被当前客户端识别，或者更新请求本身未完成。

分享链接与订阅链接也应分开理解。分享链接通常只描述单个节点，适合临时导入或迁移一条配置；订阅链接用于持续维护一组服务器，更新后可能增加、删除或调整节点。详细格式可以参阅订阅链接格式详解。长期使用时，应保留订阅分组，不要把全部节点复制为互不关联的本地条目，否则后续更新无法准确覆盖旧配置。

协议、传输与安全参数是三层设置

VMess、VLESS 等名称主要描述连接协议及认证字段；TCP、WebSocket、gRPC 等属于传输层选择；TLS、REALITY 等则处理安全握手或身份验证。客户端界面常把这些字段放在同一编辑窗口中，但它们不能随意互换。服务端给出的协议是 VLESS 时，客户端不能仅把下拉框改成 VMess；传输设为 WebSocket 时，还需保持路径、主机字段等参数一致。协议基础差异可继续阅读VMess 与 VLESS 的区别。

// CLIENT AND INSTALL

选择客户端并完成可维护的安装

按平台选择，不按名称猜测

桌面平台首推 v2rayN。它覆盖 Windows、macOS 与 Linux，适合需要管理多个订阅、编辑路由规则、查看详细日志和使用 TUN 的用户。Android 平台优先选择 v2rayNG；如果订阅或既有配置明确围绕 V2Fly 内核运行，也可以选择 v2flyNG。三款客户端的职责并不完全相同，不建议为了让多台设备界面看起来一致而强行使用不匹配的平台方案。具体安装包入口集中在下载页，其中会按照处理器架构和安装格式分别列出。

选择安装包前先确认两个信息：操作系统类型与处理器架构。Windows 常见桌面设备选择 x64；macOS 需要区分 Apple Silicon 与 Intel；Android 近年的主流设备通常使用 arm64，无法确认时可选择通用包；Linux 除了 x64 与 arm64，还需根据发行版使用 deb 或 rpm。架构不匹配时，程序可能无法启动，而安装格式不匹配通常会被系统包管理器直接拒绝。

安装位置决定后续维护成本

Windows 的桌面版与经典 WPF 版采用不同界面技术。桌面版适合希望在多种桌面系统上保持相近操作方式的用户；经典 WPF 版适合已经熟悉传统 v2rayN 工作流的 Windows 用户。若下载的是压缩形式，应解压到固定、具有写入权限的位置，不要直接在压缩预览窗口中启动。配置、日志或临时文件需要正常写入，路径频繁变化也会让快捷方式和自启动设置失效。

macOS 首次打开时，应通过系统允许的应用启动流程完成确认，并注意所选安装包是否对应处理器。Linux 用户安装 deb 或 rpm 后，应从桌面菜单启动并确认托盘或主窗口可见。Android 安装完成后，首次启用连接会出现系统网络连接确认，这是建立本地虚拟网络所需的权限步骤。权限被拒绝时，节点本身即使正确，也无法接管设备流量。

首次启动只做三项检查

第一项是确认主窗口能够打开且没有持续出现内核启动错误；第二项是找到日志入口、订阅入口和代理模式入口；第三项是确认系统时间与时区正确。部分协议的认证或安全握手依赖时间，设备时间偏差过大时会表现为参数看似一致但始终无法建立连接。首次运行阶段不要同时修改 DNS、路由、TUN、端口和内核选项，否则一旦失败，很难判断是哪一项设置造成影响。

安装完成后可以先保留默认本地监听设置。常见图形客户端会管理 HTTP、SOCKS 或混合代理端口，具体数字以客户端当前设置页为准，不应因为另一台设备使用某个端口就照搬。若端口被其他程序占用，日志通常会出现监听失败或地址已使用的提示。此时应关闭冲突程序或在客户端中更换本地端口，并同步修改依赖该端口的浏览器、终端或开发工具设置。

Windows：打开“任务管理器”确认客户端进程正在运行
macOS：打开“活动监视器”搜索 v2rayN
Linux：使用桌面系统监视器，或执行：
ss -lntp

// SUBSCRIPTION

订阅导入、分组与更新策略

完整导入流程包含四个动作

订阅管理的稳定流程是：新增订阅地址、执行更新、检查服务器列表、选择活动服务器。仅把链接粘贴到编辑框并保存，并不代表节点已经写入列表。v2rayN 中应先建立清晰的订阅分组名称，再执行对应分组的更新；v2rayNG 与 v2flyNG 也应在订阅设置中保存地址后主动刷新。更新结束后观察提示信息，确认获得了可识别的配置，而不是只看到请求完成。

复制链接时要保留完整内容。聊天工具或网页排版可能在链接中插入空格、换行，某些参数也可能因只复制了可见部分而丢失。遇到导入后为空时，先重新复制原始地址，再确认链接开头、查询参数和末尾字符完整。不要通过手工删除看似多余的编码字符来“修复”订阅，因为这些字符可能属于必要的数据内容。

分组用于控制更新范围

订阅分组不只是界面分类。它建立了服务器条目与来源之间的关联，让客户端知道更新时哪些旧条目需要替换。建议每个订阅来源单独建立分组，名称使用可识别的用途或设备范围，不要全部命名为“默认”。多个来源混在同一分组时，更新后较难判断某个节点来自哪里，也容易在清理失效条目时误删仍在使用的配置。

对于手工添加的服务器，应放在本地配置分组或明确标记，避免订阅更新覆盖。需要临时修改订阅节点时，先复制为独立条目，再编辑复制项。直接修改受订阅管理的节点，下一次更新可能恢复远端内容。客户端提供的“更新时删除旧服务器”“保留本地修改”等选项含义不同，启用前应确认分组内是否存在必须保留的手工条目。

更新频率以变化需求为准

订阅不是越频繁更新越好。日常使用可在节点出现变化、当前服务器不可用或来源明确通知配置调整时更新。自动更新间隔过短会产生不必要的请求，也可能在客户端启动时延长准备时间。更稳妥的策略是保留适度的自动更新周期，同时在需要时手工触发。移动网络环境中，还应避免在连接频繁切换时连续刷新多次，以免把网络中断误判为订阅失效。

更新失败要区分请求失败与解析失败。请求失败通常表现为超时、名称解析错误或连接被拒绝，应检查当前网络、系统时间和订阅地址是否可访问；解析失败则说明已经取得内容，但客户端无法识别其格式，可能是返回了登录页面、提示文本或不兼容的数据结构。此时继续点击更新不会改变结果，应查看日志中的响应类型，并核对当前客户端是否支持该订阅格式。

测速结果只用于同条件比较

客户端中的延迟测试、连通性测试和下载测试并不是同一个指标。延迟测试通常只反映特定探测方式的往返时间，无法直接代表网页加载或大文件传输效果；连通性测试关注目标是否可达；真实使用体验还受带宽、丢包、目标站点和当前网络影响。因此，节点排序应在相同网络、相同测试方式和接近时间内进行，不要把不同设备上的数字直接比较。

选择活动服务器后，应通过一到两个稳定目标验证，而不是连续切换大量节点。频繁切换会让 DNS 缓存、已有连接和应用重试相互叠加，日志也更难阅读。如果某个节点只有特定应用失败，应先记录代理模式、目标域名和失败时间，再到日志中定位对应连接。更多界面位置说明可参阅v2rayN 界面功能分区速览。

订阅排错记录建议：
1. 分组名称与更新时间
2. 更新提示或错误文本
3. 更新后服务器条目数量是否变化
4. 当前活动服务器名称
5. 使用的代理模式与测试目标

// PROXY MODE

系统代理、应用代理与流量接管范围

本地端口是流量进入内核的入口

客户端启动后，通常会在本机监听一个或多个代理端口。HTTP 代理适合支持标准系统代理的浏览器和桌面应用；SOCKS 代理可供支持该协议的软件单独填写；混合端口则在一个端口上兼容多种入口。端口本身不决定流量最终走哪个节点，它只负责把请求交给内核。节点选择、DNS 处理和路由规则仍由运行配置决定。

检查代理是否生效时，需要同时确认“内核在监听”和“应用确实指向该入口”。客户端显示运行中，但系统代理未启用时，遵循系统设置的应用不会自动进入内核；浏览器设置了独立代理时，即使系统代理关闭，该浏览器仍可能继续使用本地端口。排错前应明确当前使用哪一种接管方式，避免系统设置、浏览器扩展和应用内代理同时存在。

系统代理适合常规桌面应用

启用系统代理后，客户端会修改操作系统的代理设置，支持系统代理的应用会把 HTTP 或 HTTPS 请求交给本地端口。这种方式配置简单，适合浏览器、部分通讯软件和常见桌面工具。它的边界也很明确：不读取系统代理的程序、使用自定义网络栈的应用、部分命令行工具和某些 UDP 流量可能不会经过该入口。

关闭客户端前应正常退出或先清除系统代理。若程序异常结束，系统可能仍保留指向本地端口的设置，而该端口已经没有进程监听，表现就是浏览器突然无法访问网络。此时先检查系统代理是否仍指向回环地址，再关闭该设置或重新启动客户端。反复更换节点无法解决本地端口不存在的问题。

应用内代理用于精确控制

开发工具、终端程序和部分浏览器允许单独指定代理。应用内设置的优点是范围清楚，不会影响其他软件；缺点是每个程序都需要维护地址与端口。代理地址通常填写 127.0.0.1，端口必须与客户端设置页当前值一致。若应用运行在容器、虚拟机或另一台设备中，回环地址指向的是它自己的网络环境，不能直接代表宿主机。

命令行验证时，可以显式指定本地代理，借此区分“代理链路有问题”还是“系统代理没有被程序读取”。下面的命令使用示例站点，只验证 HTTP 请求能否通过指定入口发出。端口数字应替换为客户端实际显示的本地端口，而不是照抄其他设备的设置。

curl --proxy http://127.0.0.1:本地端口 https://example.com/

若不希望在命令中出现说明性文字，可先从客户端设置页读取端口，再使用实际数字执行。返回正常网页响应，说明本地 HTTP 代理和活动节点基本可用；命令提示无法连接本地地址，说明内核未监听该端口或端口填写错误；连接建立后长时间无响应，则需要继续查看节点、路由与 DNS 日志。

// ROUTING

路由分流：匹配条件、顺序与默认出口

路由只决定出口，不负责修复节点

路由分流的任务是依据域名、IP、端口、网络类型等条件，把连接交给代理出口、直连出口或阻断出口。它建立在基础连接已经可用的前提上。如果活动节点本身无法连接，增加更多规则不会让链路恢复；如果 DNS 返回异常结果，域名规则也可能无法按预期命中。因此，配置路由前应先在简单模式下验证节点，然后逐步加入规则。

常见规则集包含 domain、ip、port、network 与 protocol 等字段。域名规则适合按站点分类，IP 规则适合匹配明确地址段，端口规则用于限定服务类型，网络规则可区分 TCP 与 UDP。规则的 outboundTag 指向已有出口标签，标签拼写不一致时，即使匹配条件正确也无法得到预期结果。

规则顺序从具体到一般

路由通常按列表顺序判断，先命中的规则先执行。因此，较具体的例外规则应放在较宽泛的规则之前。例如，一个子域名需要代理，而其所属域名集合整体直连，那么子域名规则应排在集合规则前面。把“所有域名”或“所有 IP”一类兜底条件放在顶部，会使后续规则失去机会。编辑完成后，应从上到下阅读一次，确认每条规则的覆盖范围不会提前吞掉下一条。

domain: 前缀用于匹配指定域名及其子域，full: 只匹配完整域名，keyword: 按关键词匹配，regexp: 使用正则表达式。一般配置优先使用明确域名或维护良好的 geosite 分类，只有无法用普通规则表达时才考虑正则。正则范围过宽会产生意外命中，也增加后续维护成本。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:service.example.com",
          "domain:example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "udp",
        "port": "53",
        "outboundTag": "dns-out"
      }
    ]
  }
}

以上片段展示字段结构，不包含服务器认证信息。第一条把两个示例域名交给代理出口；第二条让私有地址走直连，避免访问局域网设备时绕行；第三条把 UDP 的 DNS 请求交给专用出口。实际使用时必须确认运行配置中确实存在 proxy、direct 与 dns-out 标签。若客户端通过界面生成标签，应以生成结果为准。

域名策略影响 IP 规则何时参与

domainStrategy 控制路由在遇到域名请求时是否解析 IP。使用 AsIs 时，路由主要按原始域名匹配，不会仅为了 IP 规则主动解析；IPIfNonMatch 表示域名规则未命中时再解析地址，以便继续匹配 IP 规则；IPOnDemand 会在可能需要 IP 匹配时更早执行解析。选择策略时应结合 DNS 配置，不要把策略名称理解为连接速度档位。

若规则以域名为主，通常先保证域名信息能保留到路由层；若大量依赖 geoip 分类，则应确认 DNS 结果稳定且解析路径符合预期。某些应用直接连接 IP，不会携带可供匹配的域名，这时 geosite 或普通域名规则无法生效，需要 IP 规则或其他识别方式。反过来，内容分发网络的地址可能变化，不适合长期手写单个公网 IP。

用日志验证命中，不靠结果猜测

路由排错应记录目标域名、访问时间、最终出口和匹配规则。客户端日志级别过低时，可能只看到连接成功或失败，看不到路由决策；调试期间可临时提高日志详细程度，完成后再恢复常规级别，避免日志快速增长。若目标没有命中预期规则，依次检查规则顺序、域名写法、出口标签和 DNS 策略。

自定义规则应分批加入。先写一个范围明确的域名规则并验证，再加入分类规则和兜底规则；每次变更后重新加载配置，确认日志中没有解析错误。完整语法与优先级案例可参阅V2Ray 自定义路由规则写法。当配置越来越长时，应保留规则目的注记，并定期删除已经失去用途的例外项。

// TUN MODE

TUN 模式：完整接管、DNS 与排除项

TUN 解决的是接管范围问题

TUN 会创建虚拟网络接口，让更多不读取系统代理设置的应用流量进入客户端。它适合需要处理 UDP、命令行程序、独立网络栈应用或希望统一执行路由规则的场景。TUN 并不是更快的代理模式，也不会自动改善节点质量；它改变的是流量进入内核的路径。基础节点、订阅和路由配置仍然沿用原有逻辑。

启用 TUN 前应先用系统代理验证活动节点可用。若系统代理模式下也无法连接，直接开启 TUN 只会增加虚拟接口、DNS 和路由表三个新变量。正确顺序是：确认客户端与内核正常，确认节点连接正常，确认基本规则正常，最后再启用 TUN。这样出现问题时，可以把范围缩小到权限、虚拟接口或接管规则。

权限与系统网络组件必须就绪

创建虚拟接口、修改路由和处理 DNS 通常需要额外系统权限。Windows 上应按客户端提示完成权限确认，macOS 需要允许对应网络组件，Linux 则要确保当前运行方式具备管理网络接口的能力。Android 客户端通过系统提供的网络连接接口建立本地通道，首次启用时需要用户确认。若权限步骤未完成，界面可能短暂显示正在启动，随后在日志中报告接口创建失败。

与其他虚拟网络软件、企业网络组件或安全工具同时运行时，路由表可能被多方修改。表现包括局域网无法访问、DNS 请求走向异常、网络切换后连接中断。排查时应暂时只保留一个负责接管流量的工具，确认 TUN 单独工作正常后，再逐个恢复其他组件。不要在多个程序中同时启用默认路由接管。

DNS 必须与路由策略一起设计

TUN 模式下，域名解析不仅决定目标 IP，也影响域名规则是否能获得足够信息。客户端可能提供 DNS 劫持、虚拟地址映射、远程 DNS 与本地 DNS 等设置。配置目标不是堆叠最多选项，而是保证查询进入预期路径、结果能回到发起应用，并让路由层保留正确的域名关联。若网页可以通过 IP 访问但域名失败，首先检查 DNS，而不是立即更换协议。

局域网名称、打印设备和路由器管理域名通常依赖本地 DNS。若全部查询都交给远端解析，这些名称可能无法识别。可以为私有地址、局域网域名和系统需要的解析保留直连路径，再将其他查询按规则处理。启用虚拟地址机制时，还应确保对应地址段只由当前客户端管理，避免与公司网络、容器网络或已有虚拟网段重叠。

排除项用于保护本地资源

常见排除范围包括回环地址、私有网络地址、局域网设备以及不应进入代理链路的系统服务。排除规则要尽量精确。排除整个应用虽然简单，但该应用的全部连接都会绕过路由；排除过大的地址段则可能让本应匹配的目标直接连接。调整前先明确保护对象，再选择按应用、地址或域名排除。

移动设备还需关注按应用代理。只选择指定应用时，未勾选的软件不会进入通道；选择排除模式时，列表中的应用会直连。两种语义相反，迁移配置后应重新检查。桌面端若需要让虚拟机或容器访问宿主机代理，还涉及网络边界与转发设置，不应简单把监听地址开放到所有接口。

Windows DNS 缓存刷新：
ipconfig /flushdns

Linux 查看路由：
ip route

macOS 查看默认路由：
route -n get default

// MAINTENANCE

日常维护、日志阅读与故障隔离

维护对象分为程序、配置和运行状态

客户端维护不应只关注安装包更新。程序文件决定界面和功能，配置数据保存订阅、服务器、路由及偏好，运行状态则包括当前节点、系统代理、TUN、日志和网络接口。升级程序不会自动修复错误订阅，重新导入订阅也不会解决端口冲突。每次处理问题前先判断属于哪一层，可以减少无关操作。

配置备份至少应覆盖订阅地址、自定义路由、DNS 设置和手工节点。备份文件要与程序安装包分开保存，并记录适用客户端。v2rayN、v2rayNG 与 v2flyNG 的配置组织方式不同，不应直接把整个数据目录相互覆盖。恢复时先安装匹配平台的客户端，再通过其提供的导入方式恢复可识别内容，最后检查本地路径、端口和权限。

日志按时间与层级阅读

有效的日志分析从复现时间开始。先清理或标记旧日志，执行一次明确操作，例如更新订阅、启动内核或访问一个目标，然后立即查看新增记录。不要从数千行历史内容中随机搜索“error”，因为早期错误可能已经解决。记录操作发生的准确时间，可以把界面行为与内核输出对应起来。

启动阶段重点看配置解析、端口监听和内核进程；连接阶段重点看 DNS、路由出口、握手与超时；运行阶段重点看网络切换、接口关闭和重复重试。连接被拒绝通常说明目标端口明确拒绝或本地端口不存在；超时表示在限定时间内未得到响应；名称解析失败指向 DNS；配置解析失败则意味着内核尚未进入连接阶段。这些错误不能用同一种方式处理。

一次有效故障记录应包含：
- 操作系统与客户端名称
- 当前接管方式：系统代理、应用代理或 TUN
- 问题发生时间
- 活动服务器与订阅分组
- 能复现问题的目标
- 对应时段的日志文本
- 最近一次设置变更

使用最小化配置隔离变量

当复杂配置出现异常时，先建立最小路径：保留一个已知可用的服务器，关闭 TUN，使用系统代理，停用自定义路由和额外 DNS 规则。若最小路径恢复，再按 DNS、路由、TUN、应用排除项的顺序逐项加回，每次只改变一类设置。这样可以明确是哪一层引入故障。

如果最小路径仍失败，继续检查本地端口、系统时间、当前网络和服务器参数。换到另一条网络只是一种隔离手段，用于判断问题是否与当前接入环境有关；它不能替代日志分析。若同一配置在不同网络均失败，应回到节点参数和内核输出；若只有某一网络失败，则检查 DNS、路由、网络认证页面及该网络对长连接的处理。

更新与回退都要可验证

更新客户端前记录当前可用状态，包括所用模式、活动分组和关键自定义设置。更新后先验证程序能启动、订阅能读取、节点能连接，再恢复高级功能。若升级后出现问题，应区分配置迁移失败与运行行为变化。直接覆盖旧目录可能保留不再适用的文件，完全清空又可能丢失订阅与规则，因此更稳妥的方法是保留原目录副本，在独立位置完成验证。

回退时不要同时回退订阅内容和客户端程序，否则无法判断是哪一项恢复了功能。先恢复程序并使用同一份配置测试；仍有问题再检查配置变化。日常还应清理过期服务器、重复分组和已经不用的路由例外。配置越精简，升级后的行为越容易验证。

// ADVANCED PATH

进阶路线：从可用配置到可解释配置

进阶的标准不是选项数量

稳定配置的核心是每一项都有明确目的，并能说明它影响哪一层。能够导入订阅和启用代理只是起点；能够解释某条流量为何走代理、为何直连、DNS 在哪里解析、TUN 接管了哪些应用，才算建立可维护的系统。进阶过程不应一次打开所有高级开关，而应围绕一个实际需求增加一项能力，并留下验证方法。

建议把学习路径拆成四层。第一层是客户端操作，掌握订阅、活动服务器、日志和系统代理；第二层是连接结构，理解协议、传输、安全参数及内核关系；第三层是流量控制，掌握域名策略、出口标签、DNS 与 TUN；第四层是维护工程，能备份配置、隔离故障、评估变更和安全回退。前一层不稳定时，不急于进入下一层。

建立自己的配置基线

配置基线是一份已经验证可用、内容尽量少的设置。它应包含一个订阅分组、一个活动服务器、默认本地端口、基础系统代理和少量必要规则。每次新增配置前复制基线，记录变更目的和验证结果。出现问题时可立即回到基线，判断故障来自新增设置还是外部网络变化。

基线还应记录平台差异。同一订阅在 v2rayN、v2rayNG 与 v2flyNG 中的界面位置、DNS 实现和路由生成方式可能不同，不要要求三台设备的每个开关完全一致。需要保持一致的是目标行为，例如“局域网直连”“指定业务走代理”“未命中规则使用默认出口”，而不是界面截图中的选项顺序。

把规则写成可检查的决策表

规则数量增加后，可以先在文本中写出决策表，再转换为客户端配置。每一行至少包含匹配对象、匹配条件、预期出口和验证目标。例如“私有地址—geoip:private—direct—访问路由器管理页”“指定域名—domain 规则—proxy—观察路由日志”。这种写法能够发现规则重叠，也方便在客户端更换后重新实现。

默认出口必须明确。所有具体规则都未命中时，流量最终去哪里，是路由设计中最重要的边界。采用代理作为默认出口时，应明确哪些本地资源需要提前直连；采用直连作为默认出口时，应明确哪些目标必须进入代理。不要依赖自己记得规则顺序，应让配置结构本身表达优先级。

配置变更记录示例：

目标：让局域网资源保持直连
匹配：geoip:private
出口：direct
位置：精确业务规则之后，公网兜底规则之前
验证：访问本地网关与局域网设备
回退：停用该规则并重新加载配置

逐步学习 DNS 与网络观察工具

进入进阶阶段后，建议掌握基本的名称解析与端口观察方法。nslookup 或 dig 可以确认域名由哪个解析器返回结果；ipconfig、ip route、route 等工具可以查看接口和路由；ss 能确认本地监听端口。使用这些工具的目的不是替代客户端日志，而是从操作系统一侧验证客户端声称建立的状态是否真实存在。

观察结果必须结合上下文。域名能够解析不代表代理连接一定成功，端口正在监听也不代表远端节点可用，TUN 接口存在也不代表所有应用都被接管。每个工具只回答一个问题。将多个问题拆开验证，可以避免看到一条正常结果就过早结束排查。

形成长期维护闭环

完整闭环由“记录当前状态—提出单一变更—执行验证—保留或回退”组成。更新订阅、切换内核设置、增加路由和启用 TUN 都应遵循这一流程。变更成功后记录最终结果，失败则恢复基线并保留错误日志。随着记录积累，常见问题会从反复试错转变为可复用的判断路径。

客户端选择也可以定期复核。桌面端以 v2rayN 为主要管理工具，Android 根据内核与配置需求在 v2rayNG 和 v2flyNG 之间选择。三者横向差异可阅读v2rayN、v2rayNG、v2flyNG 客户端对照。选择依据应是平台、配置兼容性和维护需求，而不是界面选项数量。

完成本手册后，可以回到快速上手教程重新走一遍主线，检查每一步是否都能解释其作用；需要更换或补装客户端时前往下载页按平台选择安装包；遇到具体错误时使用疑难解答按现象检索。最终目标不是保存一份永远不变的配置，而是掌握能够验证、调整和恢复的工作方法。