V2Ray 客户端完整配置手册

核心概念与客户端选择

先区分客户端、内核、节点与订阅

V2Ray 使用过程可以拆成四层。客户端提供窗口、菜单、订阅管理和系统接管能力；内核负责解析协议、建立出站连接并执行路由规则；节点是一组可用的服务器连接参数；订阅则是批量分发节点与更新变更的地址。v2rayN、v2rayNG 和 v2flyNG 都属于客户端，不是协议本身。Xray 与 V2Fly 属于常见内核家族，客户端会根据配置调用对应内核完成实际连接。

理解分层后，很多故障会更容易定位。客户端窗口能够打开，只能说明界面层正常；订阅列表出现节点，只能说明订阅内容已经被解析；节点被设为活动服务器，也不代表应用流量已经交给客户端。还需要确认内核成功启动、本地监听端口没有冲突、系统代理或 TUN 已经接管目标应用。任何一步中断，最终表现都可能是“网页打不开”，但处理方法完全不同。

三款客户端如何选择

Windows、macOS 和 Linux 桌面环境首选 v2rayN。它统一管理订阅、服务器、路由规则、系统代理和 TUN，适合从首次使用逐步过渡到复杂分流。Windows 可在桌面版与经典 WPF 版之间选择：桌面版采用跨平台界面，便于不同桌面系统保持近似操作路径；WPF 版面向 Windows，界面和依赖体系更传统。具体安装包应从Windows 下载区按当前环境选择。

Android 设备优先使用 v2rayNG，它以 Xray 内核为主要执行层，常见协议和路由设置集中在一个界面内。需要使用 V2Fly 内核体系时，可选择 v2flyNG。两者的订阅导入、选择节点和启动连接流程相近，但内核能力与部分配置字段并不完全相同。不要把一个客户端导出的全部高级配置直接假定为另一个客户端可以无差别读取，迁移时应先确认协议字段和路由规则。

协议名称不等于客户端名称

VMess、VLESS、Trojan 等名称描述连接协议或认证方式，REALITY、TLS 等字段描述传输安全和握手特征，TCP、WebSocket、gRPC 则属于传输层设置。客户端负责把这些字段整理成内核可以执行的配置。导入节点时必须保持地址、端口、用户标识、传输方式、加密或安全选项彼此匹配，不能只看到协议名称相同就认为两个节点配置等价。

新手阶段不需要逐项手写所有字段。可靠做法是先通过订阅导入，由提供方维护完整参数，再学习查看节点信息与日志。手动修改前先复制一份节点，避免覆盖原始配置。想进一步理解各字段含义，可以配合术语表查阅协议、内核、订阅与路由概念。建立“界面管理、内核执行、节点提供参数、订阅负责分发”的模型，是后续安装和排错的基础。

安装与首次启动

下载前确认系统与处理器架构

安装包必须同时匹配操作系统、处理器架构和客户端界面分支。Windows 常见设备使用 x64 包；macOS 需要先判断 Apple Silicon 与 Intel；Linux 除发行版包格式外，还要区分 x64 与 arm64；Android 主流设备通常优先选择 arm64，只有架构不明确或安装被系统拒绝时再使用通用包。所有入口集中在下载页面，不要把其他平台的文件改名后尝试安装。

Windows 用户还需要决定桌面版或 WPF 版。若希望与 macOS、Linux 使用接近的界面路径，可先选桌面版；若现有操作习惯和配置流程基于经典 Windows 界面，可选 WPF 版。两者都是 v2rayN，但运行环境、界面组件和部分菜单位置不同。遇到教程截图与当前界面不一致时，先核对所用分支，而不是直接判断功能缺失。

Windows、macOS 与 Linux 的启动要点

Windows 安装后应从正常用户目录启动，配置目录需要具备写入权限。若双击后窗口没有出现，先检查系统所需运行环境是否完整，再检查安装路径是否过深、目录是否只读，以及防护策略是否阻止程序创建配置和日志。不要在压缩包预览窗口中直接运行程序，应先完整解压或完成安装。启动闪退的分层检查可参考运行库与权限排查。

macOS 首次打开时，系统可能要求确认应用来源和网络相关权限。应在系统设置的隐私与安全性页面完成明确授权，再重新启动客户端。开启系统代理或 TUN 时，系统还可能要求管理员确认，这是修改网络配置所需的操作。完整路径见macOS 安装与网络权限步骤。如果程序可以打开但不能修改网络设置，应优先检查权限，而不是重复导入订阅。

Linux 用户先根据发行版选择 deb 或 rpm 包，再确认当前桌面会话是否提供系统代理接口。安装成功只表示程序文件已就位；托盘图标、自动启动和系统代理写入还依赖桌面环境。若使用最小化窗口管理环境，可能需要在浏览器或终端内单独指定本地代理。客户端日志目录和配置目录应由当前用户持有，避免每次启动都依赖提升权限。

Android 的安装与系统连接确认

Android 安装 v2rayNG 或 v2flyNG 后，首次启动连接会出现系统级连接确认。确认后，状态栏通常会显示系统提供的连接状态标识。这个确认只表示系统允许客户端创建本地网络接口，不代表所选节点一定可用。若点下启动按钮后立即停止，应打开应用日志，检查节点字段、域名解析、端口连通性和内核启动结果。

系统的省电策略可能在屏幕关闭后限制后台运行。需要长期保持连接时，应在系统应用管理中允许客户端按实际需求后台运行，并观察网络切换后的恢复情况。不同设备的电量管理名称不同，判断依据是客户端进程是否被系统暂停，而不是机械地开启所有权限。若只在前台使用，保持默认电量策略通常更节省资源。

首次启动后的基线检查

进入主界面后先不要立即开启多个高级功能。依次确认客户端能够保存设置、内核文件可被调用、本地端口没有被其他程序占用、日志窗口能够产生启动记录。桌面端可先保留默认本地监听地址，避免直接暴露到局域网。然后导入一条配置或订阅，选中活动节点，最后再开启系统代理。每次只改变一个变量，出现异常时才能知道是哪一步引入问题。

Windows:
netstat -ano | findstr LISTENING

macOS / Linux:
lsof -nP -iTCP -sTCP:LISTEN

以上命令用于查看本机监听端口。若客户端报告端口已占用，先在设置中确认 HTTP、SOCKS 和 API 等本地端口，再利用进程列表定位冲突程序。不要随意结束不认识的系统进程；更稳妥的做法是为客户端换用未占用端口，并同步修改浏览器、终端或其他手动代理应用中的端口。

订阅导入与节点管理

订阅的作用与导入顺序

订阅地址用于批量获取节点配置，通常还承担名称调整、参数更新和失效节点移除。它不是客户端安装包，也不是一个固定节点。导入时应复制完整地址，在客户端的订阅分组或订阅设置中新增条目，填写便于识别的备注，然后执行一次手动更新。更新完成后回到服务器列表，确认新增节点位于预期分组，并查看更新日志是否包含解析错误。

v2rayN 中通常先建立订阅条目，再执行更新；v2rayNG 与 v2flyNG 的入口名称可能略有差异，但逻辑相同。地址中若包含查询参数或较长的编码内容，复制时不能缺少末尾字符，也不要在聊天软件转发后继续使用被截断的显示文本。订阅属于敏感配置，应只保存在需要使用的客户端中，不要放入截图、公开日志或共享文档。

更新成功、解析成功与节点可用是三件事

客户端提示获取完成，只能说明订阅内容已被下载；列表出现节点，说明内容已被识别；某个节点能够建立连接，才说明当前网络、节点参数和内核能力共同满足要求。排查时应查看三个结果：网络请求是否返回有效内容、解析后是否产生节点、活动节点启动后是否有明确的成功或错误日志。把三者混在一起，容易在节点故障时反复修改订阅地址。

订阅更新失败时，先确认设备当前网络本身可用，再检查系统日期和时间是否明显偏差，然后核对地址是否完整。若客户端正在使用一个已经失效的代理执行订阅更新，可临时关闭系统代理，或在订阅设置中调整更新时所用的代理策略。更新后节点数量没有变化并不必然表示失败，服务端内容未改变时列表可能保持原样，应以更新时间和日志结论为准。

分组、命名与活动节点

有多个订阅时，应为每个来源设置清晰名称，并避免把所有节点堆在同一未命名列表中。分组有三个作用：更新时识别来源，故障时快速切换，清理时避免误删其他配置。节点备注建议保留服务端提供的地区或用途信息，不要只写“节点一”“备用二”。手动配置应单独放置，防止订阅更新时被覆盖或与远端条目混淆。

活动节点是当前客户端用于建立主要出站连接的条目。选中节点后，还要确认它确实被设为活动服务器，而不是仅在列表中高亮。不同界面可能通过双击、右键菜单或单独命令完成设置。切换后观察状态栏和内核日志，确认出站配置已重新加载。如果只是选中列表行但内核没有重载，实际流量仍可能走上一个节点。

更新策略与配置保留

自动更新适合内容变化较频繁的订阅，但更新间隔不宜过短。频繁刷新不会提升节点质量，反而会增加无意义请求，并让手动排错时难以判断列表何时发生变化。日常可保留合理的周期更新，在准备使用前手动更新一次。出现连接故障时先测试当前配置，再决定是否更新，避免同时改变节点列表和客户端设置。

订阅更新可能替换同名节点或删除远端已移除条目。对某个节点做过本地传输参数修改时，应先复制为独立配置并记录修改原因，否则下次更新可能恢复远端值。客户端整体迁移前，应使用其自带的配置备份或导出能力保存订阅分组、路由设置和偏好选项；单独复制节点分享文本通常不能覆盖全部客户端设置。

如果更新后全部节点同时异常，优先检查订阅内容、客户端内核和本地网络；如果只有单个节点异常，则更可能是该条目参数或服务端状态问题。详细的失败分支可从站内搜索词“v2rayN 订阅更新失败”进入相关说明。完成本章后，应达到订阅可手动更新、节点分组清晰、活动节点可明确切换、日志能够区分获取与连接结果的状态。

系统代理与代理模式

本地监听与系统代理的关系

内核启动后，会在本机创建 HTTP、SOCKS 等监听端口。应用把请求交给这些端口，客户端再依据路由规则选择直连、代理或阻断。系统代理是一种“告诉遵循系统设置的应用去哪里发送请求”的机制，它本身不负责协议连接。客户端关闭后，如果系统仍残留旧代理地址，浏览器可能因为连接不到本地端口而无法访问网络，因此退出时应让客户端正常恢复系统设置。

多数桌面浏览器会读取系统代理，但命令行工具、部分开发环境、游戏和独立网络组件可能忽略它。看到浏览器已经生效，不能推断所有应用都已接管；反过来，终端未生效也不代表节点异常。应根据应用类型选择系统代理、应用内手动代理或 TUN。相关分线检查可参考浏览器与终端代理排查。

全局、规则与直连模式

全局模式通常表示大部分符合接管条件的流量都交给代理出站，适合短时间验证节点和本地监听是否正常。规则模式会按域名、IP、端口、进程或规则集决定出口，是日常使用的主要方式。直连模式让已接管流量直接从本地网络发出，常用于对照测试或临时停用代理路径。不同客户端对模式名称的翻译可能略有不同，应以实际出站行为为准。

首次排错可以先切到全局模式。如果全局模式可用、规则模式不可用，问题多半位于路由匹配或 DNS 判断；如果两者都不可用，应回到节点、内核和本地端口检查；如果直连模式也异常，说明问题可能来自系统代理残留、应用自身设置或本地网络。这个对照方法能快速缩小范围，但不建议长期用全局模式代替规则设计。

手动代理应用如何填写

需要手动设置代理的应用，应填写客户端实际监听的地址和端口。本机应用通常使用 127.0.0.1，协议类型必须与端口一致，不能把 SOCKS 端口填入只接受 HTTP 代理的栏目。若客户端修改了默认端口，所有手动配置都要同步更新。局域网设备不能使用它们自己的 127.0.0.1 指向桌面客户端，而应使用运行客户端设备的局域网地址，并明确开启局域网共享。

HTTP 代理环境变量示例：
set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

macOS / Linux 当前终端会话：
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

以上变量只影响读取它们的程序和当前作用域。关闭终端后是否保留，取决于是否写入 shell 配置文件。排错时建议先做临时设置，确认有效后再决定是否持久化。清除时使用对应系统的变量删除方式，避免客户端退出后终端继续请求一个已经关闭的本地端口。SOCKS 代理还涉及应用是否通过代理解析域名，需要查看该应用的具体选项。

局域网共享的边界

开启局域网共享会让客户端监听可被同一网络中的其他设备访问。启用前应确认监听地址、系统防火墙和当前网络环境。家庭可信网络与公共网络应采用不同策略，公共网络中不应为了临时测试而扩大监听范围。共享设备需要把代理服务器填写为运行客户端电脑的局域网地址，并使用对应端口；电脑进入休眠、切换网络或地址变化后，共享连接会中断。

局域网共享只提供本地代理入口，不会自动替其他设备修改系统网络设置。每台设备仍需单独配置应用代理或系统代理。若同网设备连接不到端口，先在主机本地确认端口监听，再检查防火墙入站规则和网络是否允许设备互访。若能连接端口但无法访问目标，则继续查看客户端日志和路由结果，不要把端口可达与出站成功混为一谈。

用日志确认流量是否进入客户端

验证代理生效时，最直接的方法不是只看网页结果，而是观察客户端连接日志。打开一个未缓存的请求，日志中应出现对应域名、目标地址、入站类型和最终出站。完全没有记录，说明应用流量未进入客户端；有记录但被直连，说明规则匹配到直连；进入代理后连接失败，则继续检查节点或远端握手。日志把“未接管”和“接管后失败”分成两条不同路径。

路由分流与规则设计

路由规则解决什么问题

路由分流是在流量已经进入客户端之后，根据目标特征决定使用哪个出口。常见出口包括代理、直连和阻断。规则可以匹配域名、IP、端口、网络类型、进程或预定义规则集。设计目标不是把规则写得越多越好，而是让常见流量获得稳定且可解释的结果。规则过度重叠会增加维护成本，也会让命中顺序难以判断。

一套基础规则通常从明确边界开始：本机和局域网地址直连，确实需要代理的域名或规则集走代理，其余流量交给一个可预测的最终规则。最终规则非常重要，没有匹配到前置条件的请求都会落到这里。如果默认出口不明确，同一份规则在不同客户端或不同版本设置中可能表现不一致。

规则顺序与首次命中

多数路由系统按顺序检查规则，并采用首次命中的结果。范围更具体的规则应放在更宽泛规则之前。例如，某个子域名需要代理，而整个主域名通常直连，那么子域名规则必须先出现。端口、进程和域名条件组合时，还要确认它们是同时满足还是任一满足。不能只看规则文本，需要结合客户端对字段关系的实现说明。

修改规则后应重新加载配置，并通过日志查看命中项。若请求走错出口，先记录实际域名和解析地址，再检查它命中了哪条规则。不要立刻添加更多宽泛规则，因为新规则可能遮住原有条件。先用一条精确规则完成验证，确认方向正确后，再判断是否扩展为域名后缀、IP 段或规则集。

域名匹配与 IP 匹配的差异

域名规则依赖客户端在路由阶段能够看到目标域名。如果应用先在本地完成解析并只把 IP 交给代理，域名条件可能无法使用；反之，IP 规则依赖解析结果和地址归属，内容服务使用动态地址时可能频繁变化。路由器中的域名策略、DNS 设置和入站协议会共同影响可见信息，因此域名规则失效时不能只检查拼写。

域名后缀规则适合覆盖一组结构稳定的子域名，完整域名规则适合精确例外。IP 段规则应使用正确的 CIDR 表示，前缀长度决定范围，写得过宽可能把无关流量一起匹配。局域网保留地址通常应直连，避免内部服务绕到外部路径。端口规则则适合协议边界明确的服务，但现代应用可能混用多个端口，不能仅凭一个端口推断全部流量。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:docs.example.test",
          "domain-suffix:example.test"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

示例展示了常见的字段结构：私有地址走直连，指定测试域名走代理。实际客户端可能通过图形界面生成配置，出站标签也必须与客户端已有出站名称一致。示例中的保留测试域名只用于解释语法。把片段合并到完整配置前，应先导出或备份当前规则，并确认 JSON 逗号、括号与数组层级正确。

DNS 与路由为什么必须一起看

DNS 决定域名如何得到地址，路由决定请求走哪个出口。若 DNS 查询与后续连接使用不同路径，可能出现解析结果适合一个网络、实际连接却从另一个网络发出的情况。规则模式异常而全局模式正常时，应检查域名策略、DNS 服务器选择、缓存结果和请求是否由代理侧解析。切换配置后，旧缓存可能继续影响短时间内的判断。

不要同时大幅修改 DNS、路由规则和代理模式。更稳妥的做法是先保留默认 DNS，用精确域名规则验证分流；确认路由生效后，再根据解析需求调整 DNS。出现问题时记录四项信息：原始域名、解析到的地址、命中的规则、最终出站。四项齐全时，通常可以判断错误位于解析、匹配还是连接阶段。

建立可维护的规则层次

长期规则可分为四层：最前面放必须优先处理的例外；随后放局域网和本机服务；再放主要域名或规则集；最后设置默认出口。每条自定义规则都应有清晰名称和用途说明。短期测试规则在问题解决后及时删除，避免半年后仍影响流量。对于团队或多设备使用，应记录规则变更原因，而不是只保存最终配置文件。

规则数量增长后，可以定期检查重复条件、永远不会命中的后置规则和已经失效的域名。若一个应用表现异常，优先创建针对该应用的最小测试规则，而不是重排整套规则。完整掌握分流的标志不是规则表很长，而是能够从日志解释某个请求为何走直连、代理或阻断，并能在修改后验证预期结果。

TUN 模式与全局流量接管

TUN 与系统代理的根本区别

系统代理依赖应用主动读取操作系统设置，TUN 则通过虚拟网络接口接收更广范围的 IP 流量。对于忽略系统代理的应用、独立网络组件或需要统一处理的桌面流量，TUN 通常覆盖更完整。但覆盖范围扩大也意味着配置复杂度更高，DNS、路由表、虚拟网卡权限和其他网络软件都可能参与结果。能够用系统代理解决的场景，不必默认开启 TUN。

TUN 并不是“更快”的开关，它改变的是流量进入客户端的方式。节点连接质量、协议握手和远端路径不会因为启用 TUN 自动改善。若系统代理模式下节点已经连接失败，直接切换 TUN 往往只会增加新的变量。正确顺序是先用系统代理验证节点和内核，再在确有应用无法接管时启用 TUN。

启用前的准备

启用 TUN 前应关闭其他可能修改路由表或创建虚拟网卡的网络工具，记录当前 DNS 与系统代理状态，并确保客户端具备创建虚拟接口所需权限。Windows 需要关注虚拟网卡驱动与管理员授权；macOS 会要求网络扩展或相关系统确认；Linux 需要具备 TUN 设备访问和路由写入条件。权限不足通常会在启动日志中明确表现为接口创建或路由设置失败。

首次测试时保持规则简单，优先使用已经验证可用的活动节点。启动后检查三个结果：虚拟接口是否创建、默认或策略路由是否按预期写入、DNS 查询是否进入设定路径。若客户端开关显示已启用但接口不存在，应看权限和驱动；接口存在但没有流量，检查路由表；流量进入后域名失败，则转向 DNS 设置。

严格路由、自动路由与绕过范围

自动路由通常由客户端生成需要接管的系统路由，减少手工设置。严格路由用于降低流量绕过虚拟接口的可能性，但也可能与局域网服务、虚拟机、容器或企业网络策略冲突。启用严格策略前，应先确认打印机、文件共享、开发服务和本地管理页面是否需要保留直连，并为私有地址设置明确的绕过或直连规则。

局域网访问异常时，不要立刻停用全部 TUN 设置。先检查私有地址是否被错误送入代理、局域网域名是否由不合适的 DNS 解析、系统防火墙是否把虚拟接口视为不同网络。对于虚拟机和容器，还要确认它们使用的是宿主机 NAT、桥接网络还是独立接口。不同网络拓扑下，流量是否经过宿主机 TUN 并不相同。

常见冲突的定位方法

TUN 启用后完全断网，先停止 TUN 并确认基础网络恢复，再查看启动日志中最后一个成功步骤。若停止后仍异常，检查客户端是否恢复了系统 DNS、默认路由和系统代理。能访问 IP 但不能访问域名时，重点检查 DNS；只有局域网不可用时，检查私有地址路由；只有特定应用失败时，检查进程自身网络栈、IPv4 与 IPv6 选择以及应用是否绑定了特定接口。

系统休眠、网络切换和客户端异常退出都可能让虚拟接口状态与实际连接不同步。恢复后可先停止连接，等待接口和路由清理完成，再重新启动。不要连续快速切换开关，因为系统网络服务需要时间应用变更。若每次重启都复现，应保留一份启动前后路由表与日志，寻找固定失败步骤，而不是依赖多次随机重试。

Windows 查看路由：
route print

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

Linux 查看路由：
ip route

这些命令用于观察系统路由，不会修改网络。对比 TUN 启用前后，应关注默认路由、虚拟接口对应路由和私有网段路径。只记录必要的接口与网段信息，分享日志前移除订阅地址、节点凭据和本地设备标识。完成本章后，应能够判断一个问题属于接口未创建、路由未接管、DNS 不一致还是规则出口错误。

日常维护、备份与故障排查

建立稳定的更新节奏

客户端、内核与订阅是三条不同的更新线。客户端更新可能改变界面、配置迁移和系统集成；内核更新可能影响协议实现与路由行为；订阅更新主要改变节点内容。日常维护应分别记录，不要在出现故障时一次性更新全部组件。一次只改变一层，完成启动、连接和分流验证后再继续，出现回归时才能定位来源。

更新客户端前先阅读界面中的变更说明，确认当前操作系统和安装分支仍匹配。更新后不要立即删除旧配置备份，应先验证订阅列表、活动节点、路由规则、本地端口、系统代理和 TUN。若新界面重新生成了默认设置，重点检查端口和出站标签，因为手动代理应用与自定义规则可能仍引用旧值。

备份什么，而不只是复制节点

完整备份至少应覆盖订阅分组、手动节点、自定义路由、DNS 设置、端口偏好和客户端通用选项。单个节点分享文本通常不包含系统代理模式、窗口设置、自动更新计划和全部路由规则。优先使用客户端提供的备份或导出功能，并把备份放在受控位置。恢复时先关闭正在运行的内核，避免配置文件被同时写入。

备份应按“可恢复”而不是“文件存在”判断。完成一次备份后，可以在不影响主配置的环境中查看其内容结构，确认订阅和路由文件确实包含在内。跨平台迁移时，不要直接覆盖与系统路径、权限或界面分支相关的全部文件；更稳妥的做法是导入通用配置，再单独重建系统代理、开机启动和 TUN 权限。

日志的阅读顺序

日志应从首次出现的明确错误开始看，而不是只看最后一行。内核启动失败时，后续通常会连续产生端口不可用、连接被拒绝或状态停止等派生信息。先找到配置加载、监听端口、DNS 初始化、出站建立中的第一个失败点，再判断属于语法、端口、权限还是网络。站内文章看日志定位配置错误给出了常见错误入口与处理方式。

配置语法错误常带有字段名或行列位置；端口占用会指出监听地址；权限问题通常发生在写入目录、创建接口或修改系统网络设置时；节点握手失败则多出现在出站连接阶段。日志中出现域名解析失败时，还要区分客户端自身解析、代理侧解析和系统解析。不要只截取一句错误，应保留它前后的初始化上下文。

按症状建立排查树

客户端无法启动：检查运行环境、安装路径、目录权限和配置损坏。客户端能启动但内核失败：检查端口占用、配置字段和内核日志。内核启动但网页无记录：检查系统代理、应用设置或 TUN 接管。日志有请求但走错出口：检查路由命中和 DNS。请求进入代理但连接失败：换同组节点对照，并检查节点参数与当前网络。

只有一个应用异常时，不要重置整个客户端。先判断该应用是否遵循系统代理、是否缓存 DNS、是否使用独立网络组件，以及是否设置了自己的代理。只有一个节点异常时，不要删除全部订阅。换同组节点可以区分单节点问题与客户端问题。所有节点同时异常时，再检查订阅变化、内核状态、本地网络和系统时间。

退出、休眠与网络切换

退出客户端前应让它正常停止内核并恢复系统网络设置。直接结束进程可能留下系统代理地址、虚拟接口或临时路由。出现退出后无法联网时，先检查系统代理是否仍指向本地端口，再检查 TUN 接口和 DNS。不要在未确认状态前同时重置多个网络组件，否则难以判断是哪项恢复了连接。

设备从休眠恢复或在有线、无线网络之间切换后，原节点连接、DNS 缓存和局域网地址可能失效。可先观察客户端是否自动重连，再发起一个新请求验证日志。若状态停留在旧连接，应停止并重新启动内核。长期出现恢复失败时，记录网络切换前后的接口与路由差异，并减少同时启用的自动网络功能。

良好的维护基线包括：配置有可恢复备份，订阅来源和分组清晰，客户端与内核更新分开进行，日志入口随时可找到，系统代理和 TUN 的恢复方法明确。满足这些条件后，大多数问题都可以在现有安装上定位，不需要把重装作为第一选择。

进阶配置与长期学习路线

从能用走向可解释

进阶阶段的目标不是打开更多开关，而是能够解释一条请求从应用到出站的完整路径：应用通过系统代理、手动代理或 TUN 进入客户端；入站保留域名或得到目标 IP；DNS 按设定路径解析；路由规则选择直连、代理或阻断；内核根据节点协议建立出站连接；日志记录每一阶段的结果。只要这条路径清楚，复杂问题也能拆成有限步骤。

建议先选一个日常应用作为观察对象，在系统代理模式下记录其入站类型、域名、命中规则和出站。随后切换为 TUN，再比较路径变化。实验期间保持节点不变，避免把网络波动误判为模式差异。完成一次完整对照，比一次性导入大量规则更能建立可靠理解。

理解入站、出站与标签

入站定义客户端如何接收流量，例如本地 HTTP、SOCKS 或 TUN；出站定义流量最终如何离开，例如代理节点、直连或阻断；标签用于让路由规则引用这些对象。自定义配置常见错误是规则中的出站标签与实际配置不一致，或者多个入站监听同一端口。阅读生成配置时，应先找到入站列表、出站列表，再看路由如何连接两者。

图形客户端会自动维护部分标签和端口。手工修改完整配置后，界面再次保存可能重新生成相关字段，因此应分清“客户端托管设置”和“用户自定义片段”。能通过图形界面完成的常规设置优先使用界面；只有需要表达更精细条件时才编辑自定义配置，并保留修改前版本。若内核启动失败，可参考配置错误日志定位方法。

最小化实验配置

测试新规则时建立最小条件：一个已验证节点、一种接管方式、一条精确规则和一个明确目标。先确认请求按预期命中，再逐步扩展为域名后缀、规则集或进程条件。如果最小配置都不能工作，增加更多 DNS 和路由选项只会扩大排查范围。每次实验记录修改项、预期结果、实际日志和回退方式。

{
  "type": "field",
  "domain": [
    "full:api.example.test"
  ],
  "network": "tcp",
  "outboundTag": "proxy"
}

这段规则表示仅匹配指定测试域名的 TCP 流量，并交给名为 proxy 的出站。实际使用前必须确认出站标签存在，客户端内核支持对应字段，并把规则放在更宽泛规则之前。验证成功后，如果需要覆盖子域名，再明确改为后缀规则；不要一开始就使用范围过大的条件。

性能判断应基于可重复对照

连接体验受本地网络、节点路径、协议设置、DNS、并发连接和应用行为共同影响。判断某项设置是否改善性能，应固定节点与目标，分别测试修改前后，并多次观察连接建立和持续传输。单次页面打开速度容易受缓存影响，不能作为稳定结论。客户端界面中的即时状态也只反映当时条件，不适合形成长期评分。

若连接建立慢，先区分 DNS 等待、TCP 建连、TLS 或协议握手；若建立后传输不稳定，观察丢包、网络切换和节点路径；若只有规则模式慢，检查 DNS 与规则集；若只有 TUN 慢，检查虚拟接口、MTU 和是否出现重复接管。不同症状对应不同层，统一归因于客户端通常会错过真正原因。

多设备配置如何保持一致

桌面与 Android 可以使用同一订阅来源，但不应假定全部客户端偏好自动同步。订阅解决节点分发，路由规则、DNS、系统代理和 TUN 仍可能需要分别配置。维护多设备时，先定义共同策略，例如私有地址直连、指定域名代理、其余使用默认出口，再根据各客户端能力实现。不要复制依赖某个平台路径或进程名称的规则到另一平台。

v2rayN、v2rayNG 和 v2flyNG 的菜单结构与内核体系存在差异。迁移时先比较协议字段是否完整，再重建路由和 DNS。桌面端的局域网共享、终端环境变量和开机启动设置不属于 Android 配置；Android 的系统连接授权和后台电量策略也不能由桌面配置替代。保持策略一致，比强求配置文件逐字相同更实际。

推荐的学习顺序

第一阶段掌握订阅、活动节点、系统代理和日志；第二阶段掌握全局与规则模式的对照方法；第三阶段能够编写精确域名规则并解释首次命中；第四阶段理解 DNS 与路由的关系；第五阶段再启用 TUN，分析虚拟接口和系统路由；最后学习完整配置结构、标签引用和跨设备策略。每阶段都应保留一个可工作的基线配置。

遇到新术语时查阅术语表，需要重新走首次连接流程时回到快速上手教程，比较三款客户端定位时查看客户端对比。系统问题优先阅读对应平台文章，启动闪退、系统代理不生效和内核配置错误都有独立排查路径。把知识按层整理，能避免每次故障都从头搜索零散答案。

完成手册后的能力清单

完成全部章节后，应能够根据平台选择正确客户端和安装包，独立导入与更新订阅，明确设置活动节点，区分系统代理与 TUN，使用日志判断流量是否进入客户端，设计包含例外、私有地址、主要规则和默认出口的路由层次，并在更新前完成配置备份。更重要的是，能够把异常归入运行环境、内核、节点、接管、DNS、路由或系统网络中的某一层。

下一次遇到连接异常时，先保留现场并回答五个问题：客户端是否稳定运行，内核是否成功监听，应用流量是否进入，路由选择了哪个出口，出站连接在哪一步失败。五个答案通常足以确定后续动作。需要重新安装客户端时前往下载页选择当前平台；已经完成安装但操作路径不熟悉，则从快速教程重新建立一份最小可用配置。