V2Ray 从零到精通完整手册

核心概念：先看清客户端、内核与配置的关系

图形客户端不是协议本身

开始操作前，最重要的一步是把几个经常混用的名称分开。V2Ray 通常指 Project V 形成的技术生态，也常被用户用来概括一组代理协议、内核与图形客户端。v2rayN、v2rayNG 和 v2flyNG 是面向不同平台的图形客户端，它们负责保存配置、切换服务器、控制系统代理、展示日志，并把整理后的参数交给内核运行。Xray 与 V2Fly 则属于内核家族，真正处理连接建立、协议编解码、传输层和路由匹配。理解这层关系后，遇到问题时就能判断是界面操作、配置数据、系统接管还是内核运行出了偏差。

协议描述客户端与服务器如何交换必要信息，例如 VMess、VLESS 或 Trojan；传输方式描述数据如何承载，例如 TCP、WebSocket、gRPC；TLS、REALITY 等安全层又位于不同位置。一个可用节点不是只靠协议名称决定，而是由地址、端口、用户标识、传输方式、安全层、域名等参数共同组成。任意一项与服务端不一致，都可能表现为连接失败。不要根据名称猜参数，也不要把某个节点的字段机械复制到另一个节点。

配置从哪里来，又流向哪里

常见配置入口有两类。单节点分享链接适合临时添加一个配置，订阅地址则用于管理一组由服务提供方维护的节点。客户端读取订阅后，会把其中的条目转换成内部配置并归入订阅分组；连接时，当前选中的节点、代理模式、路由规则和本地端口会共同生成运行配置。由此可以看出，订阅更新不是“启动连接”的同义词：更新只负责刷新列表，仍需选择节点并启动连接，新的配置才会进入当前会话。

系统代理与 TUN 也不是同一个层级。系统代理通常修改操作系统提供的代理设置，只有遵循该设置的应用会把请求送到客户端；TUN 会建立虚拟网络接口，在更低层接收流量，因此覆盖范围更广，但对权限、路由和 DNS 的要求也更高。刚开始使用时应先掌握系统代理，确认节点和订阅本身正常，再考虑是否需要 TUN。这样能把问题范围控制在较小的层面。

用分层思路处理故障

系统化排查应从最短链路开始。先确认客户端能正常启动，再确认订阅能够读取，然后选择一个节点查看内核是否成功运行，最后检查应用流量是否进入代理。若客户端启动即退出，优先检查运行环境、目录权限与残留进程；若订阅更新失败，检查地址格式、网络可达性和系统时间；若内核已经运行但浏览器没有变化，检查系统代理与浏览器自身设置；若只有个别应用不工作，再考虑该应用是否忽略系统代理，以及是否需要 TUN。

延迟测试只能作为筛选线索，不能单独证明节点具备完整可用性。不同测试方式可能只检测 TCP 建连、握手或特定目标，结果还会受到本地网络、测试目标和瞬时负载影响。更可靠的判断是：先确认配置握手成功，再使用实际需要的应用进行访问测试，同时查看日志中是否存在重复重试、DNS 失败或路由拒绝。建立“客户端—配置—内核—系统—应用”的分层模型，是后续每一章的基础。

选择客户端：按平台、内核与使用场景取舍

桌面平台优先选择 v2rayN

Windows、macOS 与 Linux 桌面环境优先选择 v2rayN。它把订阅分组、服务器列表、系统代理、路由规则、TUN 和日志集中在同一套界面中，适合作为长期维护的主客户端。桌面端经常需要同时处理浏览器、开发工具、办公应用和命令行程序，v2rayN 的分组与路由能力更容易形成稳定工作流。Windows 用户还会在下载页看到桌面版与经典 WPF 版：桌面版采用新一代跨平台界面，经典 WPF 版适合习惯传统 Windows 界面的用户。两者选择一个长期使用即可，不需要同时运行。

macOS 下载时要按处理器架构选择 Apple Silicon 或 Intel 安装包；Linux 则依据发行版的软件包体系选择 deb 或 rpm，并继续区分 x64 与 arm64。架构选错通常会表现为无法安装或无法启动，而不是网络连接问题。因此，安装前先查看系统信息，比安装后反复调整节点更有效。所有安装入口都集中在安装包页面，该页按照四个平台列出对应选择方法。

Android 上的 v2rayNG 与 v2flyNG

Android 首选 v2rayNG。它以 Xray 内核为基础，适合需要常见协议、订阅管理、分应用代理和系统 VPN 接管的用户。安装包通常分为 arm64 与通用版，近年的主流设备一般使用 arm64；如果无法确认设备架构，通用版覆盖面更广，但体积通常也会更大。首次连接时，系统会要求授权建立 VPN 连接，这是 Android 把应用流量交给客户端处理的必要步骤。授权只代表允许建立本地虚拟接口，并不等于订阅已经导入或节点已经可用。

v2flyNG 是 Android 上以 V2Fly 内核为主的备选客户端。它适合配置明确依赖 V2Fly 行为，或希望在同一平台对照不同内核实现的用户。不要仅凭名称判断哪款客户端“更快”，实际体验取决于配置协议、本地网络、远端状态和内核兼容性。对大多数首次配置的 Android 用户，先用 v2rayNG 完成稳定连接更容易；只有在明确知道配置来源、协议支持与内核要求时，再切换到 v2flyNG。

不要用客户端切换代替问题定位

遇到连接失败时，连续安装多个客户端通常不能缩小问题范围。更有效的方法是先固定一个客户端，记录订阅是否成功、内核是否启动、日志在哪一步停止。如果同一订阅中的所有节点都失败，优先检查订阅状态、系统时间、网络与配置兼容性；如果只有一个节点失败，优先比较该节点与正常节点的协议和传输字段；如果系统代理可用而 TUN 不可用，说明节点链路大概率正常，应转向权限、DNS 与路由检查。

迁移客户端时也要避免直接覆盖原有配置目录。先导出或记录订阅分组、路由规则和本地端口，再关闭旧客户端及其内核进程，确认系统代理已经恢复，然后启动新客户端。两个客户端同时接管系统代理或监听相同端口，会产生看似随机的连接故障。Android 上切换 v2rayNG 与 v2flyNG 时，也应先停止当前 VPN 连接，再启动另一款客户端，避免系统仍保留前一个会话。

建立清晰的选型边界

客户端选择可以归纳为三个问题：当前操作系统是什么、订阅要求哪类内核、是否需要高级路由或 TUN。桌面平台直接从 v2rayN 开始；Android 从 v2rayNG 开始；配置方明确指定 V2Fly 行为时再考虑 v2flyNG。界面偏好可以影响最终选择，但不应覆盖协议兼容性与系统架构。更详细的三款客户端差异可查看横向评测，安装包类型则以下载页的实时清单为准。

选定客户端后，建议至少连续使用一段时间再调整工具。稳定的配置习惯比频繁更换界面更有价值：统一订阅备注、固定路由规则命名、明确系统代理开关、保留必要日志，就能让后续维护形成可重复的流程。下一章将以这种思路处理安装与首次启动。

安装与首次启动：先建立可恢复的基础环境

安装前确认系统与处理器架构

安装的第一步不是双击文件，而是确认操作系统版本、处理器架构与可写目录。Windows 常见为 x64；macOS 需要区分 Apple Silicon 和 Intel；Linux 除 x64、arm64 外，还要根据发行版选择 deb 或 rpm；Android 则在 arm64 与通用包之间选择。系统信息中的“系统类型”“芯片”或“处理器”字段比设备营销名称更可靠。若架构不匹配，应重新选择安装包，不要尝试通过修改扩展名或复制可执行文件绕过限制。

桌面端建议把客户端放在路径清晰、当前账户有读写权限的位置。客户端需要保存订阅、日志、路由规则和界面设置，只读目录可能导致设置无法保存、升级后配置回退或内核无法释放文件。路径尽量避免过长，也不要把正在运行的目录交给会自动按需释放文件的同步工具。需要迁移时，先退出客户端，再复制完整配置目录；仅复制主程序通常无法保留订阅分组与自定义规则。

首次启动只完成必要设置

首次启动后，先确认界面能够正常打开、内核组件可以被调用、日志窗口没有持续报错。此时不要急着启用 TUN、自定义 DNS 和复杂路由。保持默认本地端口与基础代理模式，导入一个来源明确的订阅或单节点，再进行第一次连接。这样可以建立最短验证路径：客户端启动、配置读取、内核运行、系统代理生效、应用访问。任何一步失败，都有清晰的前后边界。

Windows 若出现启动后立即退出，可检查系统运行环境、程序目录权限、旧进程与配置文件是否损坏。macOS 若系统阻止首次打开，应通过系统设置确认该应用的打开操作，而不是反复复制应用文件。Linux 安装后无法启动时，先从终端运行一次以查看缺少的依赖或权限提示。Android 安装完成后先允许必要的通知显示，便于观察连接状态；首次建立连接时再处理系统 VPN 授权。

Windows：设置 → 系统 → 系统信息 → 系统类型
macOS：苹果菜单 → 关于本机 → 芯片
Linux：uname -m
Android：在系统信息工具中查看 ABI，优先识别 arm64-v8a

退出、重启与系统代理恢复

桌面客户端关闭窗口后不一定立即退出，部分设置会让程序继续驻留。更新、迁移或排查端口占用前，应使用客户端的退出命令，并确认内核进程也已经结束。若直接终止进程，系统代理可能保留上一次指向本地端口的设置，之后浏览器会表现为全部请求失败。此时即使节点本身正常，也需要先恢复系统代理，再重新启动客户端。

一个稳妥的退出顺序是：停止当前连接，关闭系统代理或 TUN，退出客户端，确认进程结束。重新启动时则反过来：先打开客户端，确认配置加载完成，选择节点并启动内核，最后开启系统代理或 TUN。这个顺序能避免流量被送到尚未监听的本地端口。Android 上直接从最近任务划走应用，也可能被厂商后台策略终止；需要持续连接时，应结合后续维护章节设置省电白名单和后台运行权限。

为后续排查保留基线

首次成功连接后，先不要立即叠加设置。记录当前客户端、订阅分组、节点类型、代理模式和是否启用 TUN，并确认一个浏览器与一个日常应用能够稳定访问。这个状态就是后续调整的基线。修改路由或 DNS 后若出现问题，可以回到基线判断是哪项变化带来影响，而不是重新安装全部组件。

建议同时熟悉日志入口和配置备份位置。日志中最有价值的是错误发生的阶段、目标地址、协议握手结果和 DNS 提示，不需要长期保留冗长的调试级输出。备份则应在客户端完全退出后进行，至少包含订阅信息、路由规则与主要偏好设置。关于运行库与权限导致的启动问题，可继续阅读客户端启动闪退修复指南。

订阅与节点：把配置来源整理成可维护的分组

订阅地址、分享链接与手动配置

订阅地址用于一次获取并持续更新一组节点，适合长期维护；分享链接通常只描述单个节点，适合临时导入或精确测试；手动配置则要求逐项填写地址、端口、用户标识、传输与安全参数，适用于无法使用导入格式或需要核对细节的场景。三种入口最终都会形成客户端可选择的服务器条目，但更新方式不同。订阅中的节点应由订阅更新维护，手动修改后可能在下次刷新时被覆盖。

添加订阅时，先新建有辨识度的分组备注，再粘贴完整地址。备注可以使用服务名称、用途或环境，不建议只写“订阅一”“备用二”，因为多个来源并存后很难判断更新对象。保存后主动执行一次更新，观察客户端是否返回条目以及是否出现格式错误。订阅地址含有访问凭据，应只保存在受控设备和客户端配置中，不要放入公开文档、截图或共享日志。

更新并不等于立即切换

订阅更新通常会新增、删除或修改当前分组中的节点，但不会自动替代正在使用的连接。更新完成后，应查看当前选中的条目是否仍存在，必要时重新选择节点并重连。若列表没有变化，先确认执行更新的是目标分组，再检查是否启用了关键词过滤、去重或排序规则。部分名称相同的节点可能因筛选结果看起来没有变化，实际上内部参数已经更新。

更新失败时，按地址格式、网络可达性、系统时间和客户端日志依次检查。复制地址时不要带入首尾空格或换行；浏览器能打开某个页面不代表订阅接口一定可达；系统时间偏差可能影响安全连接；日志中的状态码或解析提示则能区分是请求失败还是内容格式不受支持。不要在同一时刻反复点击更新，连续请求既不能修复格式问题，也会让日志难以阅读。

订阅分组命名示例：
工作环境｜主订阅
移动设备｜常用
协议测试｜临时

筛选规则示例：
保留关键字：VLESS|Trojan
排除关键字：维护|到期|剩余

节点选择要结合协议、位置与实际任务

节点列表中的名称通常只是配置方提供的备注，不代表稳定性结论。延迟测试适合快速排除无法建连或响应明显缓慢的条目，但测试结果受线路、测试方法和瞬时状态影响。选择节点时，应结合协议是否被当前内核支持、传输参数是否完整、实际应用能否稳定工作，以及连续使用时是否频繁重连。一次很低的数值不能替代持续访问测试。

当某个节点不可用时，先在同一订阅分组选择另一个节点。如果其他节点正常，问题范围通常在单条配置或远端状态；如果整个分组都失败，检查订阅是否过期、更新内容是否异常；如果多个来源同时失败，则进一步检查本地网络、系统代理与客户端内核。这样的对照比无顺序地修改 DNS、路由和端口更有效。

多订阅分组与过滤策略

同时维护多个订阅时，应把来源分开，而不是导入后混在一个平面列表。分组能明确更新边界，也便于为不同来源设置独立过滤规则。节点名称可使用统一排序方式，例如先按协议或地区，再按原始备注。过滤关键词应保持简单，每次只解决一个目标：隐藏维护提示、保留特定协议或排除不需要的用途。规则过长时，很容易把新节点意外隐藏。

修改过滤规则后，先查看未过滤的原始数量与名称，再逐步增加条件。正则表达式中的竖线表示“或”，括号用于组合，点号与星号具有特殊含义；如果只是匹配普通词语，直接使用明确关键词更安全。关于多个订阅源的分组、备注和筛选实践，可参考多机场订阅分组管理实践。完成订阅整理后，再进入代理模式设置，避免把列表问题误判为系统接管问题。

代理模式：理解系统代理、规则模式与全局处理

系统代理负责把支持它的应用引向客户端

桌面环境中的系统代理，本质上是把操作系统代理地址设置为客户端监听的本地端口。浏览器和许多桌面应用会读取这项设置，再把 HTTP 或 SOCKS 请求交给客户端。客户端随后根据当前节点和路由规则决定如何处理。系统代理覆盖范围清晰、权限要求较低，适合作为首次连接和日常使用的默认入口，但某些应用会使用自己的网络栈或独立代理设置，因此不会自动跟随。

开启系统代理前，客户端内核必须已经运行并监听对应端口。若系统代理指向的端口没有程序监听，所有遵循系统设置的应用都会连接失败。检查时可以先关闭系统代理，确认本地网络恢复，再启动客户端并重新开启。不要随意修改本地端口；如果确实需要调整，应同时确认客户端入站端口、系统代理地址和手动配置过代理的应用保持一致。

规则、全局与直连分别解决什么问题

规则模式会根据域名、IP、端口、进程或协议等条件决定流量走代理、直连或阻断，是日常使用中最平衡的方式。全局模式通常让可接管的流量统一经过当前代理，适合短时验证节点是否能处理目标请求，也适合排除路由规则误判；它不应被理解为连接质量更高。直连模式则绕过远端代理，可用于临时恢复普通网络或验证问题是否来自代理链路。

排查时可以利用三种模式形成对照。如果全局模式可用而规则模式不可用，优先检查路由规则命中；如果全局模式也不可用，问题更可能在节点、内核或系统接管；如果关闭系统代理后应用仍然走代理，说明应用可能配置了独立代理，或仍有其他网络工具在运行。每次切换模式后重新连接，并观察日志中的出站标签，才能确认新设置已经进入当前会话。

浏览器、命令行与独立代理应用

浏览器通常会跟随系统代理，但也可能通过扩展或企业策略使用独立设置。排查浏览器时，先关闭额外的代理扩展，使用新建窗口访问目标，再与系统中的其他应用对照。命令行工具不一定读取桌面系统代理，可能需要在当前终端会话设置 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。设置只应指向客户端实际监听的本地地址和端口，测试结束后及时清除，避免后续命令在客户端关闭时失败。

# 临时为当前终端会话指定本地代理，端口需与客户端设置一致
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# 结束测试后清除
unset HTTP_PROXY
unset HTTPS_PROXY

部分开发工具、下载工具或游戏平台拥有独立网络设置，应优先查看应用自身文档。不要为了覆盖一个不遵循系统代理的应用，立即切换到 TUN；先判断它是否支持手动 HTTP 或 SOCKS 代理，往往更容易控制。若应用确实无法设置代理，且需要连同 UDP 或子进程一起接管，再评估 TUN 的必要性。

连接状态与实际访问要分开判断

客户端显示“已连接”通常表示内核已经启动或本地 VPN 接口已经建立，不代表每个远端请求都成功。实际访问还要经过 DNS 解析、路由匹配、协议握手与目标响应。遇到“显示连接但无法访问”时，查看日志是否出现 DNS 失败、连接超时、路由到直连或远端拒绝。通过日志中的目标与出站标签，可以判断流量是否进入预期路径。

建立稳定习惯后，日常使用可以固定为规则模式，并保留全局模式作为诊断工具。每次修改订阅、节点或模式，只改一项并重连，再用同一测试目标验证。这样积累的结果具有可比性，也为下一章编写路由规则打下基础。

路由分流：用明确规则控制每类流量的出口

规则由匹配条件、目标与顺序组成

路由分流的核心不是堆积规则，而是回答两个问题：哪些流量需要特殊处理，它们应当走哪个出口。常见匹配条件包括完整域名、域名后缀、IP 网段、端口、网络类型和进程名；目标通常是代理、直连或阻断。客户端会把界面中的规则转换为内核配置，并按既定顺序匹配。一般情况下，越具体的规则越应靠前，范围较大的兜底规则放在后面。

域名规则在 DNS 解析前后可能有不同表现。若应用直接访问 IP，单纯的域名后缀规则不会命中；若客户端没有获得原始域名，只能按解析后的 IP 判断。进程规则依赖系统权限和进程识别能力，在不同桌面平台上的支持也可能不同。因此，编写规则前先确认客户端界面提供哪些条件，不要把其他工具的语法直接粘贴进来。

从最小规则集开始

一个易维护的规则集通常包含明确直连项、明确代理项和最终兜底。先写最确定的条件，例如局域网地址直连、特定工作域名使用指定出口，再决定其余流量的默认路径。不要一开始导入大量来源不明的规则，因为规则之间可能重叠，更新后也难以追踪变化。每新增一条规则，都应知道它匹配什么、为什么需要以及放在当前位置的原因。

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

上面的结构展示了常见内核路由逻辑：私有地址先直连，指定域名走代理，其余 TCP 与 UDP 使用代理出口。实际在 v2rayN 或移动客户端中，出站标签可能由界面生成，不应自行假设名称。复制配置片段前，先确认客户端是否支持直接编辑完整配置；若使用图形规则编辑器，应把条件逐项填入对应字段，而不是把整段 JSON 放进单个输入框。

理解域名策略与 DNS 的配合

AsIs 表示优先按原始域名匹配，不为路由判断额外解析 IP；其他策略可能在域名规则未命中时继续解析并尝试 IP 规则。策略越积极，越可能增加 DNS 查询，也更依赖 DNS 配置正确。若需求主要是按域名后缀分流，保持域名逻辑简单更容易排查；若必须根据 IP 网段处理，则需要确认解析结果、DNS 出口和 IP 规则保持一致。

DNS 与路由会相互影响。DNS 查询本身也属于流量，需要决定由哪个服务器解析、通过哪个出口发送；解析结果又会参与后续 IP 规则。常见异常包括域名被解析到不适合当前线路的地址、查询经错误出口发送、缓存仍保留旧结果。排查时先观察具体域名的解析结果，再检查该查询和业务连接分别命中了什么规则。不要同时更换多个 DNS、域名策略和路由集，否则很难确认是哪项修改生效。

规则命中测试与冲突定位

验证规则时，应选择特征明确的目标，并查看日志中的域名、目标 IP 与出站标签。若具体规则没有命中，检查它是否排在更宽泛的规则之后、域名格式是否正确、应用是否直接使用 IP、旧连接是否仍在复用。浏览器可能保持长连接，修改规则后仅刷新页面不一定重建全部请求，必要时关闭相关标签页或重启应用再测试。

进程分流还要考虑子进程。例如浏览器主程序与网络服务进程可能名称不同，启动器与实际程序也可能分离。移动端的分应用代理更适合按应用包进行选择，规则结果取决于客户端的“绕过所选应用”或“仅代理所选应用”语义，切换前必须读清选项。关于 Android 的授权、省电白名单与分应用代理，可查看v2rayNG 安卓使用要点。

保持规则可读、可撤销

为每组规则写清用途，并在大改前导出备份。规则名称可以直接描述业务，例如“局域网直连”“工作域名代理”“特定应用直连”，比抽象编号更容易维护。删除规则前先停用并观察一段时间，确认没有依赖后再移除。订阅规则集若由外部来源更新，应与个人规则分层存放，避免更新覆盖手工调整。

成熟的路由方案不是规则数量最多，而是能稳定解释每次命中。先满足主要场景，再处理少量例外；当例外持续增多时，重新审视默认出口是否合理。完成路由基础后，如果仍有不遵循系统代理的应用、UDP 流量或复杂子进程需要接管，才进入 TUN 模式。

TUN 模式：扩大流量接管范围并控制复杂度

TUN 为什么覆盖更多应用

TUN 模式通过虚拟网络接口接收系统流量，再交给客户端内核判断路由。它不要求每个应用主动支持 HTTP 或 SOCKS 代理，因此能覆盖忽略系统代理的程序、部分 UDP 流量和多进程应用。Android 客户端建立的系统 VPN 连接也属于类似的接管思路。覆盖范围扩大后，系统路由、DNS、权限与排除项都会参与工作，所以 TUN 更适合在基础节点和规则模式已经验证正常后启用。

TUN 并不意味着所有流量都必须走远端代理。流量进入虚拟接口后，仍然会根据路由规则选择代理、直连或阻断。若局域网访问、打印服务或开发环境需要保持直连，应在启用前确认私有地址和相关域名规则。错误的默认路由可能让本地设备不可达，错误的 DNS 设置则可能表现为“IP 能访问、域名不能访问”。

启用前的检查清单

先关闭其他可能创建虚拟接口或修改路由表的网络工具，再确认 v2rayN 的普通系统代理连接可用。检查当前节点支持需要的网络类型，记录原有 DNS 设置和路由模式，然后再启用 TUN。桌面系统可能要求管理员权限或安装必要组件，应在客户端明确提示下完成。若权限被拒绝，反复切换开关不会解决问题，需要回到系统权限设置处理。

启用后先测试三个层次：普通域名访问、直接 IP 访问、局域网资源访问。普通域名失败而 IP 成功，优先看 DNS；两者都失败，检查虚拟接口、默认路由和内核日志；外部访问正常但局域网失败，检查私有网段直连规则。测试目标保持固定，每调整一项就重新连接，避免缓存和旧会话干扰结论。

DNS、严格路由与回环问题

TUN 常需要接管 DNS，确保域名解析和后续连接使用一致的路由策略。配置过多 DNS 服务器并不会自动提高可靠性，反而可能造成结果不一致。起步时使用客户端推荐的简单方案，确认查询能够进入内核，再根据实际需求区分直连与代理解析。若出现解析循环，要检查 DNS 请求是否又被送回同一个本地监听端口。

严格路由用于减少流量绕过虚拟接口的可能，但也可能影响虚拟机、容器、局域网共享和自定义网卡。开启前应记录系统中已有的网段与接口，尤其是开发环境使用的私有地址。若容器访问突然失败，不要先改节点协议，而应比较 TUN 前后的路由表，并为必要网段添加明确处理。规则必须窄而准确，避免用过大的网段覆盖正常系统路由。

Android 上的连接授权与分应用代理

v2rayNG 或 v2flyNG 首次连接时会请求系统 VPN 授权。系统通常同一时间只允许一个活动 VPN 会话，因此切换客户端前要停止当前连接。分应用代理有两种相反逻辑：只让选中的应用进入代理，或让选中的应用绕过代理。配置时先核对界面描述，再用一个容易验证的应用测试，不要一次选择大量应用。

如果连接在锁屏后频繁中断，问题往往与系统省电策略、后台限制或厂商任务管理有关。把客户端加入省电白名单、允许后台运行，并保留持续通知，有助于维持 VPN 服务。日志级别不宜长期保持详细调试状态，否则会增加写入与处理开销。更完整的移动端续航排查方法见v2rayNG 耗电与后台运行排查。

什么时候应退回系统代理

如果主要需求只是浏览器和少量支持代理的桌面应用，系统代理通常更简单。TUN 应解决明确问题，而不是作为默认复杂度。启用后若长期遇到局域网、容器或 DNS 冲突，可以先退回系统代理，让日常工作恢复，再单独分析需要接管的应用。保持一个已验证的普通代理配置，是处理 TUN 故障的重要退路。

关闭 TUN 时，应通过客户端开关正常停止，让虚拟接口和路由得到清理，然后确认系统网络恢复。若强制结束进程后网络异常，可重新启动客户端并正常关闭一次，或在系统网络设置中检查残留接口。完成这些基础后，下一章将把更新、备份、日志和故障定位整理为可重复的维护流程。

日常维护：更新、备份、日志与稳定性排查

把更新拆成客户端、订阅与规则三类

日常更新并不是一个动作。客户端更新会改变界面、内核或功能行为；订阅更新会刷新节点参数；规则更新则可能改变流量出口。三类更新最好分开执行，每次更新后完成一次基础验证。若同一天同时更换客户端、刷新订阅并导入新规则，出现异常时很难找到变化来源。稳定环境中可以先备份配置，再更新客户端，确认启动与旧配置正常，然后刷新订阅，最后处理规则。

客户端更新前先退出正在运行的内核，记录当前使用的安装类型与架构。不要在旧程序仍运行时覆盖文件。更新后先检查订阅分组、路由模式、本地端口和 TUN 设置是否保留，再启动一个已知可用节点。订阅更新则应查看条目数量、当前选择与筛选规则；规则更新后需要重连，并通过日志确认主要目标仍走预期出口。

备份的重点是可恢复，不是文件数量

有价值的备份至少应包含订阅分组、手动节点、自定义路由、DNS 偏好和关键客户端设置。执行备份时完全退出客户端，避免复制到尚未写完的配置文件。备份目录可以按日期和客户端名称区分，但不要把含有订阅凭据的文件上传到公开位置。恢复时先在相同客户端系列中测试，再考虑跨版本或跨客户端迁移。

建议同时保留一份简短的环境记录，例如系统平台、处理器架构、客户端名称、使用的代理模式、自定义本地端口和是否启用 TUN。它不需要包含节点凭据，却能在重装后快速还原操作逻辑。复杂路由规则应附带用途说明，避免数月后只剩下无法解释的条件。可恢复的配置应能回答“从空环境开始，最少需要哪些步骤才能回到稳定状态”。

用日志定位阶段，不要只搜索错误词

日志排查先看时间顺序：客户端读取配置、内核启动、本地端口监听、DNS 查询、路由匹配、远端连接与应用请求分别发生在什么位置。单独一个 error 字样可能只是某次重试，连续重复的同类错误才更能说明阻塞阶段。记录问题发生的准确时间，再截取前后相关行，比复制整份日志更容易分析，也能减少暴露订阅地址等敏感内容的风险。

排查记录模板
1. 平台与客户端：Windows / v2rayN
2. 接管方式：系统代理或 TUN
3. 影响范围：全部应用、单个应用或单个域名
4. 最近变化：客户端、订阅、规则、DNS
5. 对照结果：直连、规则、全局分别如何
6. 日志阶段：启动、解析、路由、握手或超时

若客户端无法启动，优先查看运行环境、目录权限、配置损坏和端口占用；若订阅无法更新，检查地址与请求错误；若内核启动后所有节点失败，检查系统时间、网络和协议兼容性；若只有规则模式失败，检查规则顺序；若只有 TUN 失败，转向权限、DNS 与系统路由。按阶段分类后，大多数问题都能缩小到一两个模块。

处理端口占用、残留代理与后台限制

端口占用常发生在客户端异常退出、重复启动或同时运行多个工具时。先正常退出所有相关客户端，再检查残留进程。若修改本地端口，应同步更新系统代理和手动指定代理的应用。系统代理残留会让客户端关闭后的浏览器无法访问，此时先恢复操作系统代理设置，再重新启动客户端，不需要删除订阅或重装系统。

Android 后台中断则应检查省电优化、后台活动限制、自动启动权限和持续通知。不同设备的设置入口不同，但判断方法相同：前台稳定、锁屏后中断，通常与后台管理有关；前台也无法连接，则先看配置与 VPN 授权。不要通过无限提高日志级别维持服务，日志只负责观察，不会改变系统调度。

建立周期性的轻量检查

日常维护不需要频繁改动。可以定期更新订阅，删除明确失效的临时配置，检查筛选规则是否误伤新节点，并确认客户端设置仍符合当前需求。路由规则只在业务变化时调整，TUN 只在覆盖范围确有需要时开启。长期稳定比不断追逐新选项更重要。

遇到异常时，先回忆最近一次变化，再使用“关闭高级功能—恢复基础节点—验证系统代理—逐项加回设置”的顺序。若需要重新安装，也应先备份配置并确认旧进程退出。更多启动崩溃、权限与残留进程处理方法，可继续查看运行库与权限问题排查。下一章将把这些基础能力延伸到协议、内核与配置阅读。

进阶路线：从会用客户端走向能读懂配置

第一阶段：读懂一个完整节点

进阶学习不必从编写整份配置开始。先选择一个已经可用的节点，对照客户端界面逐项理解地址、端口、用户标识、协议、传输方式、安全层、域名和指纹等字段。重点不是记住所有选项，而是知道哪些参数必须与服务端一致，哪些属于本地偏好。把可用配置复制为测试条目，每次只修改一个非关键字段并观察日志，可以建立字段与行为之间的联系。

协议层与传输层要分开学习。VLESS、VMess、Trojan 描述身份与协议交互，TCP、WebSocket、gRPC 描述数据承载，TLS 或 REALITY 则处理相应的安全与握手要求。名称相似不代表参数可互换。阅读配置时从外向内拆分：先确认服务器地址与端口，再确认协议身份，然后看传输，最后检查安全层和域名。这个顺序也适用于连接失败的手工核对。

第二阶段：理解 Xray 与 V2Fly 的生态关系

Xray 与 V2Fly 都来自 Project V 技术生态的发展分支，客户端会根据自身定位集成相应内核。v2rayN 常用于桌面端综合管理，v2rayNG 以 Xray 内核为主要基础，v2flyNG 则提供 V2Fly 内核方向的 Android 选择。内核不同会影响协议支持、配置字段和更新节奏，因此订阅配置若明确依赖某种能力，应使用与之匹配的客户端和内核。

学习内核差异时，不要把“支持列表”简化成绝对优劣。更有用的问题是：当前配置使用了哪些协议和传输字段、客户端集成的内核能否识别、升级后行为是否变化、日志是否提示未知字段。关于两条内核路线的演进和客户端选择，可阅读Xray 与 V2Fly 内核区别详解。

第三阶段：从图形规则过渡到结构化配置

熟悉客户端路由编辑器后，可以开始阅读内核配置的基本结构。常见配置由日志、DNS、入站、出站和路由组成。入站负责接收来自系统代理或 TUN 的流量，出站定义代理与直连等出口，路由把匹配条件指向出站。阅读时先找标签之间的引用关系，再看每个对象的具体参数。标签拼写不一致会让规则指向不存在的出口，是手工编辑时常见的问题。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

这段示例只展示本地 SOCKS 入站、直连出站和私有地址规则，不包含远端服务器凭据。实际客户端通常会自动生成入站与主要出站，手工配置前应先导出当前结果进行阅读，不要直接替换正在使用的配置。每次修改后先检查 JSON 结构是否完整，再通过客户端日志确认字段被内核接受。

第四阶段：建立可重复的实验方法

进阶配置最容易陷入“改了很多但不知道哪项有效”。建议为实验建立独立订阅分组或测试配置，保留一个稳定基线，记录每次修改、预期结果和实际日志。测试路由时固定节点，测试节点时固定路由，测试 DNS 时固定目标域名。变量控制得越少，结论越可靠。出现异常后先回退最后一次修改，而不是继续叠加新参数。

日志级别可以在短期测试时提高，但完成定位后应恢复常规级别。详细日志会产生更多信息，也可能包含访问目标和配置片段，分享前要删去订阅地址、用户标识和其他访问凭据。命令行测试应只使用本地回环地址与客户端实际端口，不要把临时凭据直接写进长期脚本。

第五阶段：形成自己的维护文档

当配置包含多个订阅、路由组、TUN 和分应用规则时，应为环境写一份简短说明。内容包括客户端选择理由、订阅分组用途、默认代理模式、重要路由、DNS 方案、备份位置和恢复顺序。说明不需要记录敏感参数，但应让使用者在重装或升级后知道如何还原。每次大改后同步更新说明，比依赖记忆可靠得多。

从零到精通并不是把所有选项全部开启，而是能够解释当前配置为什么这样工作，出现异常时知道从哪一层开始检查。推荐的长期路线是：保持一个稳定客户端，掌握订阅分组和系统代理，写出最小路由集，再根据明确需求启用 TUN，最后阅读结构化配置与内核日志。若尚未完成第一次连接，回到快速上手按主线操作；需要更换平台或架构时，前往安装包页面选择对应客户端。