V2Ray 从零到精通完整手册

CHAPTER 01

核心概念：先区分内核、客户端与配置

V2Ray、V2Fly 与 Xray 分别处于哪一层

开始配置前，最重要的不是记住菜单位置，而是把几个经常同时出现的名称放到正确层级。V2Ray 通常用来指代 Project V 形成的代理技术生态和配置体系；V2Fly 延续并维护其中一条内核路线；Xray 则是同一技术家族中的另一套内核实现。内核负责解析配置、建立入站与出站、完成协议握手、执行 DNS 策略并按路由规则转发流量。它通常在后台运行，不直接承担订阅列表、托盘菜单和系统代理开关等图形操作。

v2rayN、v2rayNG 与 v2flyNG 属于客户端层。客户端把订阅管理、服务器选择、日志查看和代理模式做成可操作界面，再调用对应内核处理连接。桌面环境首选 v2rayN，它覆盖 Windows、macOS 与 Linux；Android 上优先使用采用 Xray 内核的 v2rayNG，需要 v2fly 内核路线时再选择 v2flyNG。理解这层关系后，遇到问题时就能判断它属于界面设置、订阅内容、内核启动还是网络环境，而不是反复重装整个客户端。

一条连接由哪些部分组成

一份可以建立连接的配置至少包含入站、出站和路由三个逻辑部分。入站描述本机程序如何把流量交给内核，例如本地 SOCKS 端口、HTTP 代理端口或由 TUN 虚拟网卡接收的数据；出站描述内核如何处理流量，常见标签包括代理出站、直接连接和阻断；路由位于二者之间，根据域名、IP、端口、网络类型或入站标签决定采用哪个出站。图形客户端会生成其中一部分配置，因此日常使用不必手写完整文件，但理解结构有助于阅读日志和检查规则。

服务器条目则提供远端连接所需的地址、端口、身份信息、协议与传输参数。协议决定双方如何交换数据，传输层决定数据承载在 TCP、WebSocket、gRPC 等哪种通道中，TLS 或 REALITY 一类安全参数再约束握手方式。任何关键字段不一致都会导致连接失败。客户端能够导入链接并不等于配置一定有效；导入只表示语法被识别，真正可用还要经过 DNS 解析、网络连通、系统时间和远端状态等多层检查。

订阅不是协议，节点也不是客户端

订阅地址是一种配置分发入口。客户端请求该地址后，服务端返回一组服务器条目或结构化配置，客户端再把结果转换成列表。订阅本身不负责转发流量，也不代表某一种协议。常见误区是把“订阅更新成功”理解成“代理已经启用”：前者只说明客户端取得并解析了列表，后者还需要选择服务器、启动内核，并让应用流量进入本地代理或 TUN 入站。

“节点”是界面中对服务器配置条目的习惯称呼。一个条目可能包含 VMess、VLESS、Trojan 等协议参数，也可能引用同一远端入口的不同传输组合。判断条目是否适合当前环境时，应先看协议和传输是否被客户端内核支持，再看地址能否解析、端口能否到达，最后才检查路由模式。不要仅凭名称判断用途，因为显示名称通常只是订阅提供方设置的备注，不参与实际握手。

从应用请求到远端出站的完整路径

以浏览器访问网站为例：浏览器先解析域名，再根据操作系统代理设置把请求交给 v2rayN 的本地监听端口；内核取得目标域名和目标 IP 后，从上到下匹配路由规则；命中 direct 时由本机网络直接访问，命中 proxy 时通过当前服务器出站，命中 block 时停止转发。若应用不读取系统代理，则请求不会进入这条路径，此时需要应用内单独设置代理，或使用 TUN 接管其网络流量。

这个流程解释了为什么“客户端显示运行中”仍可能没有实际代理效果。运行中只说明内核进程存在；系统代理可能未启用，应用可能绕开系统设置，规则也可能把目标分到直连。相反，某个网站能打开也不能证明所有规则都正确，因为它可能恰好走了直连。验证配置应同时观察客户端日志、系统代理状态和目标请求的路由结果，而不是只看一个网页是否加载。

CHAPTER 02

客户端选择与安装：按平台建立稳定起点

三款客户端的职责边界

桌面平台优先选择 v2rayN。它把订阅分组、服务器列表、系统代理、路由规则、TUN 与日志集中在一个工作台中，适合从基础连接逐步扩展到复杂分流。Windows 可根据界面实现选择桌面版或经典 WPF 版；前者采用跨平台桌面界面，后者延续经典 Windows 操作方式。二者的核心任务一致，不需要同时运行。macOS 与 Linux 使用对应平台的 v2rayN 安装包，下载时根据处理器架构和发行版包格式选择。

Android 平台优先使用 v2rayNG，它采用 Xray 内核，配置概念与桌面端接近，但代理接管方式由系统 VPN 接口完成，界面路径也更紧凑。v2flyNG 是采用 v2fly 内核的备选客户端，适合明确需要该内核路线的配置。两款 Android 客户端可以分别安装，但日常连接时只应启用一个系统 VPN 会话，避免两个客户端争用接管权限。完整安装包入口与平台说明集中在下载页。

安装前先确认架构与权限

处理器架构决定安装包能否启动。Windows 与 Linux 常见桌面电脑通常使用 x64；采用 ARM 处理器的设备需要 arm64。macOS 可从系统信息中的芯片或处理器字段判断：显示 Apple 芯片时选择 Apple Silicon 对应包，显示 Intel 时选择 x64。Android 可在设备信息或硬件检测页面查看 ABI；近年的主流设备通常支持 arm64，无法确认时可使用通用包，但通用包体积通常更大。

安装权限会影响系统代理、虚拟网卡和服务注册。普通系统代理通常只需要修改当前用户设置；TUN 模式需要创建虚拟网络接口和调整路由表，因此可能触发管理员授权。授权应发生在用户主动开启相应功能时。若客户端可以打开但 TUN 无法启动，应优先检查权限与驱动状态，而不是先修改服务器协议。企业设备还可能由策略统一管理代理或网络扩展，这类限制需要在系统管理范围内处理。

首次启动后的最小检查

第一次打开客户端时，不要立即开启所有选项。先检查客户端能否正常显示主界面，设置区能否找到核心路径，日志窗口是否能够打开，然后再导入订阅。v2rayN 的主界面通常包含订阅分组、服务器列表、系统代理和路由设置；v2rayNG 的主界面则以配置列表、当前选中项和连接按钮为中心。此时保持系统代理关闭，可以把安装问题与配置问题分开。

接着检查系统时间、时区和网络基础状态。TLS 与 REALITY 等握手对时间偏差较敏感，系统时间错误可能表现为证书或握手失败。先用不经过代理的网络确认常规网站和 DNS 可以工作，再启动客户端。如果当前网络本身需要网页登录认证，应先完成认证，因为认证页面往往在代理启动前处理更稳定。网络环境发生切换后，也应等待系统取得新的地址和 DNS，再重新连接。

Windows PowerShell
Get-Date
Get-NetIPConfiguration
Test-NetConnection example.com -Port 443

macOS / Linux
date
curl -I https://example.com

这些命令只用于确认本机时间、网卡配置与基础 HTTPS 连通性，不判断代理服务器是否有效。若基础连接已经失败，应先恢复本地网络；若基础连接正常而客户端内核无法启动，再查看配置解析和端口占用。这样可以避免在网络断开的情况下反复更换订阅条目。

升级、并行安装与配置目录

升级客户端前应先退出正在运行的内核，并记录当前订阅分组、路由模式和自定义规则。客户端配置通常保存在用户目录或应用数据目录中，具体位置由平台和安装形态决定。覆盖安装前先使用客户端提供的备份或导出功能保存必要设置，不要把缓存、日志和服务器列表当作唯一备份。订阅地址可以重新更新，但手工添加的服务器、路由规则与 DNS 配置可能无法从订阅恢复。

同一台电脑可以保留不同界面实现用于迁移测试，但不要让两个客户端同时监听相同本地端口，也不要同时修改系统代理。端口冲突通常会在日志中显示“地址已被使用”或监听失败。切换客户端时，先清除旧客户端设置的系统代理并完全退出，再启动新客户端。若异常退出后系统仍保留代理地址，可在操作系统网络设置中关闭代理，然后回到客户端重新启用。

CHAPTER 03

订阅导入：从地址取得配置并建立分组

订阅地址的结构与保存方式

订阅地址通常是一个 HTTPS URL，路径或查询参数中包含用于识别账户的令牌。它的作用是让客户端定期取得服务器列表，因此应按账户凭据管理，不要发布在公开页面、截图或日志中。复制地址时要确保从协议头到最后一个字符完整保留，避免聊天工具自动截断查询参数。客户端中保存的是地址，不是网页正文；若在浏览器中打开后看到编码文本或下载响应，这不代表地址错误。

https://example.com/sub?token=xxxx

上面的地址只展示常见结构。实际订阅可能使用不同路径和参数名。导入时不要手工删除看似多余的等号、斜杠或百分号编码，因为这些字符可能属于令牌或签名。若复制后末尾带有空格和换行，应先清理不可见字符。订阅地址发生轮换时，建议编辑原分组而不是不断新建重复分组，避免旧服务器与新服务器混在同一列表中。

在 v2rayN 中导入与更新

桌面端应先建立订阅分组，再把地址放入分组配置。打开“订阅分组”相关菜单，添加分组名称和订阅地址，保存后执行更新。分组名称只用于本地识别，可以按用途或配置来源命名，不影响远端响应。更新成功后，服务器列表会根据订阅内容生成；若开启了删除旧条目的更新策略，客户端会用本次结果替换该分组之前的条目，因此手工添加的服务器最好放在独立分组中。

更新完成后先检查条目数量是否合理、协议是否被识别、地址与端口列是否存在，再选中一个条目设为活动服务器。不要在更新过程中连续点击多次，因为并发请求可能触发订阅端频率限制，也会让日志难以阅读。多个订阅并存时，每个来源建立独立分组，按需设置更新间隔；需要进一步整理服务器时，可参考多订阅分组与关键字过滤，将分组、筛选和路由用途分开管理。

在 v2rayNG 与 v2flyNG 中导入

Android 客户端一般从订阅设置中添加地址，再返回主界面执行更新。更新时系统需要允许客户端访问网络；省电限制、后台数据限制或私有 DNS 异常都可能导致请求失败。更新完成后，配置条目出现在主列表中，需要手动选择其中一项作为当前配置。选中状态只是指定下一次连接使用的配置，不代表系统 VPN 会话已经建立，还要执行连接并确认状态栏中的 VPN 标记出现。

v2rayNG 与 v2flyNG 的订阅数据应分别维护。虽然部分通用分享链接都能被识别，但两套内核对新协议字段和扩展选项的支持节奏可能不同。某条配置在一款客户端中无法解析时，先查看它是否包含当前内核不支持的字段，不要直接认定订阅整体失效。若订阅同时提供适配不同内核的入口，应使用与客户端匹配的入口。

更新成功、解析成功与连接成功的区别

订阅更新包含三个可独立判断的阶段。第一阶段是 HTTP 请求成功，意味着客户端能够访问订阅地址并取得响应；第二阶段是内容解析成功，意味着返回格式能转换成服务器条目；第三阶段才是选择条目并建立代理连接。响应状态正常但列表为空，通常属于内容格式、账户状态或过滤条件问题；列表存在但全部无法连接，则要检查服务器参数、时间、DNS 和当前网络。

日志中的错误信息应按阶段阅读。域名解析失败说明订阅域名未取得 IP；连接超时说明请求没有在期限内完成；未授权或禁止访问通常与地址令牌、账户状态或请求策略有关；解析失败则表示响应内容不是客户端预期格式。若客户端设置了“通过代理更新订阅”，而当前代理本身已经失效，更新会形成依赖闭环。排错时可暂时改为直连更新，更新成功后再恢复原策略。

分组、过滤与去重策略

分组的价值不只在于视觉整理，它还限定更新和删除操作的范围。工作、日常浏览和测试配置可以分开保存，更新其中一个来源时不会覆盖其他分组。服务器名称包含地区或用途关键字时，可使用客户端过滤功能缩小列表，但过滤只改变显示或选择范围，不改变远端配置。创建过滤规则前先观察命名规律，避免使用过宽关键字把不相关条目一起选入。

重复条目常由多次导入同一订阅、订阅端重复返回或迁移时保留旧分组造成。处理时先确认条目所属分组，再删除旧来源；不要只按显示名称批量删除，因为不同配置可能使用相同备注。若订阅更新后旧条目仍存在，检查该分组的更新方式是否采用追加策略。长期维护应让自动更新负责订阅条目，让手工配置留在独立分组，两类数据的生命周期不同，混合保存会增加误删概率。

订阅更新失败时的最短诊断路径

先关闭通过代理更新订阅的选项，用当前基础网络请求一次；随后检查地址是否完整、系统时间是否正确、订阅域名能否解析。若只有某一个地址失败而其他地址正常，问题更可能在该订阅的权限或响应；若所有地址都失败，应检查 DNS、系统代理残留和安全软件的网络策略。更新后没有服务器时，再查看客户端是否启用了名称过滤，或者返回内容是否被识别为网页错误信息。

不要通过频繁删除重装来处理单个订阅错误，因为客户端重新安装不会改变远端响应，也不会修复错误地址。保留一次失败日志，找到请求阶段和状态信息，再决定是修改地址、切换更新网络还是调整解析方式。更多集中问题可在常见问题中按“安装配置”和“故障排查”分类查找。

CHAPTER 04

代理模式：决定哪些应用把请求交给客户端

系统代理与内核路由解决不同问题

系统代理负责把支持操作系统代理设置的应用请求送到客户端本地端口；内核路由则在请求已经进入客户端后，决定它最终走代理、直连还是阻断。前者控制“是否进入”，后者控制“进入后往哪里走”。很多配置混乱都源于把两者当成同一个开关：即使路由选择全局代理，未读取系统代理的应用仍不会自动进入；即使系统代理已经开启，路由也可能将特定目标分到直连。

v2rayN 的“自动配置系统代理”适合浏览器和遵循系统设置的桌面应用。启用后，客户端把操作系统的代理地址指向本地监听端口；清除系统代理会撤销这项设置；不改变系统代理用于只启动内核、由其他应用手工连接本地端口的场景；PAC 模式则通过规则文件向应用返回不同代理决策。日常使用先选择自动配置系统代理，再配合内核路由做分流，路径最容易理解。

全局、规则与绕过大陆模式如何理解

客户端界面中的“全局”通常表示进入内核的流量默认使用代理出站，适合短时间排查规则问题，但它不会强制接管所有应用。规则模式按照路由表逐条匹配，常见目标是让局域网、私有地址和特定域名集合直连，其余请求使用代理。绕过大陆模式是一种预设规则组合，通常将中国大陆域名与 IP 分到直连，再让其他目标使用代理。预设规则便于开始使用，但仍需要结合实际应用检查误判。

选择模式时应从使用目的出发。日常浏览优先使用规则或绕过大陆模式，减少不必要的代理路径；调试某个目标是否被规则误分时，可临时切换全局模式对照；需要只代理单个开发工具时，可以保持“不改变系统代理”，在该工具中手工填写本地 SOCKS 或 HTTP 地址。模式比较与典型场景可继续阅读系统代理、全局与绕过大陆模式区别。

本地 SOCKS 与 HTTP 端口

内核常同时提供 SOCKS 和 HTTP 两种本地入站。SOCKS 能转发 TCP，并可根据客户端实现处理 UDP；HTTP 代理更适合原生支持 HTTP CONNECT 的应用。端口由客户端配置生成，不应随意复制其他教程中的固定数字。需要在单独应用中设置代理时，应从当前客户端设置页面读取本地监听地址和实际端口，主机通常使用回环地址 127.0.0.1，避免把本地代理暴露给局域网。

应用设置中还要区分“代理 DNS”与“本地解析”。某些 SOCKS 客户端会先在本机解析域名，再把 IP 交给代理；另一些会把域名交给远端链路解析。前者可能绕开内核基于域名的路由规则，后者更有利于保持域名信息。应用提供 socks5h 一类模式时，其中的主机名解析通常随 SOCKS 请求交给代理。具体选择应与内核 DNS 和路由策略一致。

HTTP_PROXY=http://127.0.0.1:本地HTTP端口
HTTPS_PROXY=http://127.0.0.1:本地HTTP端口
ALL_PROXY=socks5h://127.0.0.1:本地SOCKS端口

以上写法用于说明环境变量结构，实际使用时应把文字端口替换为客户端显示的数字。命令行工具只在读取这些环境变量时才会使用代理；关闭终端或清除变量后，行为可能恢复为直连。不要同时配置多个互相冲突的代理来源，例如系统代理、环境变量和应用内代理都指向不同客户端，这会让请求路径难以判断。

如何确认系统代理真正生效

首先在 v2rayN 状态栏确认系统代理显示为自动配置，然后打开一个遵循系统代理的浏览器请求页面，同时观察客户端访问日志。日志中出现新连接，说明请求已经进入内核；没有日志则应检查浏览器是否使用独立代理、是否启用了直连策略或是否从旧进程继承了环境变量。浏览器完全退出再打开，能够排除部分连接池和代理设置缓存。

若日志存在但目标访问失败，继续查看路由标签和出站错误。命中 direct 表示规则选择直连，命中代理出站后超时则属于远端链路或网络问题。若系统代理关闭后仍无法正常直连，操作系统可能残留了旧地址。此时在系统网络设置中检查手动代理字段，清除不再使用的回环地址和端口，再重新由客户端自动配置。

移动端的接管方式

v2rayNG 与 v2flyNG 通过系统 VPN 接口接收应用流量，因此不需要单独修改每个浏览器的系统代理。点击连接后，系统会请求建立 VPN 会话；允许后，客户端根据路由和分应用设置决定流量走向。连接图标存在只表示接口已经建立，仍要通过日志确认当前配置成功连接远端。切换网络、进入省电模式或长时间后台运行后，系统可能回收进程，需要检查电池优化与后台运行权限。

按应用代理可以限定哪些应用进入客户端，适合将工作应用与其他流量分开。配置时应明确使用“仅代理选中应用”还是“绕过选中应用”，两者含义相反。修改列表后重新建立连接，确保系统重新加载路由。若某应用内部还设置了自己的代理，应避免与系统 VPN 形成二次转发，先恢复应用默认网络设置再测试。

CHAPTER 05

路由分流：按域名、IP 与入站选择出站

规则从上到下匹配

路由规则的核心不是规则数量，而是匹配顺序。内核通常按列表从上到下检查，请求命中一条规则后使用对应出站，不再继续匹配后面的普通规则。因此，范围小、意图明确的规则应放在前面，范围大的兜底规则放在后面。例如广告域名阻断应位于通用域名代理之前，局域网和私有地址直连应位于默认代理之前。顺序颠倒时，规则语法完全正确也会产生错误结果。

域名规则只在内核能够取得目标域名时发挥作用。如果应用先在本机解析并只提交 IP，geosite 规则可能无法匹配，后续只能依靠 geoip 或其他 IP 规则。反过来，IP 规则需要解析结果；解析策略和 DNS 返回会影响它。稳定分流需要让应用入站、DNS 和路由处在同一设计中，而不是只复制一段规则列表。

geosite、geoip 与 domainStrategy

geosite 是按域名集合匹配的规则数据，例如 geosite:cn 表示相应域名集合，geosite:category-ads-all 常用于广告域名分类。geoip 按 IP 集合匹配，例如 geoip:private 用于私有地址，geoip:cn 用于对应地区 IP。规则数据会随客户端或内核资源更新，若日志提示集合不存在，应检查资源文件是否完整以及标签是否被当前数据集支持。

domainStrategy 决定路由在什么条件下为域名解析 IP。AsIs 倾向于按原始域名匹配，不主动为了 IP 规则进行解析；IPIfNonMatch 表示域名规则未命中时再解析 IP 并继续匹配；IPOnDemand 会在规则需要 IP 时更积极地解析。日常域名与 IP 混合分流常使用 IPIfNonMatch，它在保留域名匹配的同时允许后续 IP 规则工作，但具体选择还要考虑 DNS 配置和性能。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

这段 JSON 展示可放入 Xray 配置中的路由对象，前提是完整配置已经定义名为 block 与 direct 的出站。默认代理通常由客户端在未命中规则时选择，或者通过最后一条范围更广的规则明确指定。复制片段前要核对客户端生成的出站标签，不同客户端可能使用不同标签名；标签不一致会导致内核启动时报找不到出站。

建立最小可解释规则集

初次自定义时，建议只保留四类意图：阻断明确不需要的域名集合、私有网络直连、确定需要直连的域名与 IP、其余交给默认代理。每增加一条规则，都应能回答“匹配对象是什么、为什么放在这个位置、命中后走哪个出站”。如果无法说明，先不要加入。数量庞大但来源不明的规则集会增加更新依赖，也会使误判难以定位。

私有地址直连尤其重要。局域网打印机、路由器管理页、文件共享和本地开发服务通常位于私有网段，不应被送到远端代理。除 geoip:private 外，还可以按目标端口、入站标签或明确网段补充规则。需要从 TUN 访问局域网时，还要确认虚拟网卡路由没有覆盖本地链路，规则直连只是内核决策，操作系统路由表也必须能到达目标。

按域名、端口和进程做细分

自定义域名可使用完整域名、子域名后缀、关键字或正则形式。优先使用完整域名和后缀匹配，它们更容易预测；关键字可能误中不相关站点，正则表达式则应控制复杂度并记录用途。端口规则适合限定特定服务，但端口本身不能判断网站归属，同一端口可能承载大量不同服务。将域名与端口放在同一条 field 规则中时，通常表示条件共同约束，配置前要确认内核对字段组合的匹配语义。

进程分流依赖平台能力和客户端实现。即使界面提供进程名规则，也可能受权限、进程派生方式和容器环境影响。进程规则适合桌面应用的补充控制，不应替代域名与 IP 规则。应用更新后可执行文件名称或路径变化，也可能让旧规则失效。维护时应在日志中确认实际进程识别结果，而不是只看规则仍然存在。

DNS 泄漏与分流错位

如果目标域名由本地 DNS 直接解析，而连接本身走代理，解析请求和业务连接就处于不同路径。这可能造成地域结果不一致、域名规则信息丢失或解析失败。解决方向不是简单更换 DNS 地址，而是明确哪些域名由哪组 DNS 服务器解析，以及这些 DNS 请求通过哪个出站发送。内核 DNS、系统 DNS、浏览器安全 DNS和 TUN DNS 劫持可能同时存在，应尽量减少重复层级。

排查时先关闭浏览器独立 DNS 功能，用系统与客户端的统一路径测试；随后观察日志中是否保留目标域名、DNS 查询走哪个出站、返回地址是否进入预期 IP 规则。需要进一步检查时，可阅读V2Ray DNS 泄漏检测与配置实操。修改 DNS 后应清理系统和应用缓存，再重新建立连接，否则旧结果可能持续影响判断。

规则变更后的验证清单

保存路由后应重新加载内核，确认日志没有字段、标签或资源错误；分别访问一个预期直连目标、一个预期代理目标和一个局域网地址；检查每个请求的目标域名、目标 IP 与出站标签；最后切换网络再测试一次，排除 DNS 缓存和旧连接池影响。若只有某个应用不符合规则，检查它是否读取系统代理、是否使用独立 DNS、是否复用旧连接或启用了 QUIC。

规则维护应保留简短说明和修改原因。客户端支持备注时直接记录；只能编辑 JSON 时，可在外部文档保存规则意图，不要向严格 JSON 文件加入注释。删除规则前先确认它是否被其他入站依赖。长期稳定的规则集通常比频繁叠加规则更短，因为明确的默认行为和少量例外更容易验证。

CHAPTER 06

TUN 模式：接管不读取系统代理的流量

TUN 与系统代理的根本差异

系统代理依赖应用主动读取操作系统设置，TUN 则创建虚拟网络接口，让操作系统把符合路由表的 IP 流量交给客户端。对不支持代理设置的应用、部分命令行程序和需要 UDP 的场景，TUN 覆盖范围更完整。代价是配置层级增加：除了内核入站和路由规则，还要处理虚拟网卡权限、系统路由、DNS 劫持、MTU 和局域网绕过。

TUN 不是“更快的系统代理”，也不应作为所有问题的第一解决方案。如果浏览器通过系统代理已经稳定工作，先完成订阅、服务器与路由验证，再开启 TUN。这样一旦出现异常，可以确定基础代理链路没有问题，诊断范围集中在虚拟网卡和系统网络层。直接从 TUN 开始，连接失败时很难区分是服务器、DNS、权限还是路由表造成。

开启前的权限与冲突检查

创建虚拟网卡通常需要管理员权限。v2rayN 在开启 TUN 时可能请求授权或安装相关组件，操作完成后应在系统网络接口列表中看到新的虚拟接口。若日志显示创建接口失败、访问被拒绝或路由写入失败，先以系统允许的方式授予权限，并检查终端安全策略是否阻止虚拟网卡。不要通过反复点击开关尝试绕过错误，重复创建可能留下多条临时路由。

其他 VPN、虚拟机网络、容器网络和安全软件也可能调整路由表或 DNS。启用 TUN 前先退出不需要的同类工具，记录基础网络的默认网关和 DNS，然后再启动客户端。若两个工具都声明默认路由，最终流量可能进入错误接口或形成回环。确实需要并行时，应通过更具体的网段和路由优先级划分边界，而不是让两边都接管全部流量。

路由表、严格路由与自动路由

自动路由会为 TUN 接口写入系统路由，使目标流量进入虚拟网卡。严格路由通常会进一步限制可能绕过 TUN 的路径，有助于让 DNS 与业务流量保持一致，但也可能影响虚拟机、局域网发现或特殊网卡。初次启用可使用客户端推荐的自动路由设置，确认基本访问后，再根据需求决定是否开启更严格的策略。

局域网访问异常时，先确认私有网段是否保留直连系统路由，再检查内核中 geoip:private 是否指向 direct。这两个条件缺一不可：操作系统要能把局域网目标交给正确网关，内核也要选择直接出站。若公司网络使用不常见的内部网段，应添加明确网段规则，而不是假设所有内部地址都落在常见私有范围内。

Windows PowerShell
Get-NetRoute | Sort-Object RouteMetric
Get-DnsClientServerAddress

macOS
netstat -rn
scutil --dns

Linux
ip route
ip address

这些命令用于观察 TUN 开启前后的接口、默认路由和 DNS 变化。检查重点是默认路由是否被预期接口接管、局域网网段是否仍有更具体路由、关闭 TUN 后临时路由是否撤销。不同系统输出形式不同，不要直接照搬他人的接口名称或网关地址。

DNS 劫持与 FakeDNS

TUN 接收到的是 IP 数据包，而路由规则经常依赖域名。DNS 劫持用于把系统 DNS 请求交给内核，使内核保留域名与解析结果之间的关系。FakeDNS 则可以为域名分配一段临时映射地址，应用连接该地址时，内核再还原原始域名并执行路由。这类机制能改善域名分流，但要求地址池不与局域网、虚拟机或其他 VPN 网段冲突。

出现“能解析但无法连接”时，应检查 FakeDNS 地址是否被其他路由抢走；出现“关闭客户端后网络仍异常”时，应确认系统 DNS 和路由是否恢复。某些应用使用内置 DNS 或加密 DNS，可能绕过系统的普通 DNS 请求，此时需要在应用内关闭独立解析，或通过 TUN 路由确保其解析连接也进入客户端。DNS 配置应一次只启用一套主要逻辑，避免系统 DNS、客户端 DNS 和浏览器 DNS相互覆盖。

MTU、UDP 与连接异常

MTU 决定单个网络数据包的最大尺寸。TUN 叠加代理传输后会增加额外开销，如果路径不允许分片或丢弃必要的控制消息，过大的 MTU 可能造成小页面能打开、大文件或特定网站长时间卡住。遇到这类症状时，可在客户端允许范围内逐步降低 TUN MTU，每次调整后重新建立连接并测试相同目标。不要一开始就使用极小值，因为过小会增加包数量和处理开销。

UDP 依赖服务器协议、出站能力和客户端设置共同支持。语音、游戏、DNS 与基于 QUIC 的连接可能使用 UDP；若 UDP 不通而 TCP 正常，先检查当前配置是否允许 UDP，再查看 TUN 入站是否接收 UDP、路由规则是否把它送到正确出站。为了快速判断，可暂时让浏览器关闭 QUIC，观察网页是否恢复；这只是定位手段，最终仍应修正 UDP 或路由配置。

何时适合长期使用 TUN

需要统一接管多个不支持系统代理的应用、依赖 UDP、或希望通过一套路由覆盖桌面程序时，TUN 更合适。只使用浏览器和常规办公工具时，系统代理通常更简单，也更容易与局域网服务共存。长期使用 TUN 应定期检查系统更新后虚拟网卡权限是否变化，网络切换后默认路由是否重建，以及睡眠恢复后 DNS 是否仍指向有效接口。

从系统代理迁移到 TUN 时，先清除系统代理，避免同一请求先进入本地代理再被 TUN 捕获。启用后通过日志确认入站标签来自 TUN，并分别测试 TCP、UDP、局域网与 DNS。完整的开启步骤和平台差异可参阅v2rayN TUN 模式原理与开启步骤。

CHAPTER 07

日常维护：更新、备份、日志与故障定位

把维护对象分成四层

稳定使用依赖四类对象：客户端程序、内核与规则资源、订阅数据、本地自定义配置。它们的更新来源和风险不同。客户端更新可能改变界面与配置迁移逻辑；内核更新影响协议和配置字段；规则资源更新影响 geosite 与 geoip 匹配；订阅更新则替换服务器条目。一次同时更新全部内容，出现问题后难以判断是哪一层变化造成。

更稳妥的方法是分批执行。先导出本地设置和自定义规则，再更新客户端并确认能启动；随后检查内核和资源是否加载；最后逐个更新订阅并测试活动服务器。若只需要刷新服务器，不必同时改动路由和 DNS。每次维护后记录改变了什么、测试了哪些路径，出现回归时可以快速恢复上一套可用设置。

备份哪些内容才有恢复价值

订阅服务器列表可以重新取得，但订阅地址、分组结构、手工服务器、路由规则、DNS、端口和 TUN 参数属于本地管理信息，应纳入备份。使用客户端导出功能时，确认导出范围是否包含订阅地址和敏感字段；备份文件应放在受控位置。截图适合记录界面状态，不适合作为完整备份，因为长地址、隐藏字段和规则顺序无法可靠恢复。

迁移到另一台设备时，不应直接复制所有缓存和运行状态。先安装匹配平台的客户端，导入订阅与必要规则，再按新设备的处理器架构、权限和网络环境调整。监听端口、网卡名称与系统代理状态不一定适合原样迁移。恢复后从最小系统代理测试开始，确认正常再启用 TUN 与高级 DNS。

日志应该从第一条错误开始读

内核日志往往会在一个根因后产生多条连锁错误。例如 DNS 解析失败会导致连接目标为空，随后出现出站失败和请求关闭；端口占用会导致入站创建失败，之后所有应用都无法连接。排查时找到本次启动后的第一条明确错误，比只看最后一条超时更有效。重新测试前清空日志或记住时间点，避免把旧错误当作当前状态。

常见信息可按阶段分类：配置解析错误说明字段、JSON 结构或标签存在问题；监听失败通常与端口占用或权限有关；域名解析失败属于 DNS；连接被拒绝表示目标可达但端口未接受连接；超时可能发生在本地网络、远端链路或握手阶段；认证与握手错误通常需要核对服务器条目的协议参数和系统时间。日志包含服务器地址或订阅信息时，分享前应删除敏感内容。

建立可重复的故障定位流程

第一步检查基础网络：关闭客户端后确认普通网络、DNS 和系统时间正常。第二步检查客户端进程：使用一个已知可用的配置启动内核，确认没有解析或监听错误。第三步启用系统代理，用遵循系统设置的浏览器测试并观察日志。第四步比较全局与规则模式，判断是否为分流问题。第五步才开启 TUN，检查虚拟接口和 DNS。每一步都建立在上一步成功的基础上。

如果问题发生在网络切换后，先重新连接当前活动服务器，因为旧 TCP 连接和旧 DNS 结果可能已经失效。睡眠恢复后异常，则检查内核进程、虚拟接口和系统代理三者是否仍一致。客户端退出但系统代理未清除时，应用会继续尝试连接不存在的本地端口，表现为所有网页立即失败。此时清除系统代理比更换服务器更直接。

订阅与规则的更新频率

订阅不需要在每次打开客户端时连续更新。根据来源的变更频率设置合理间隔，并保留手动更新入口。更新太频繁会增加请求失败和列表频繁重排的概率；长期不更新则可能保留已失效条目。多个分组可以错开更新时间，避免同时请求。更新前正在使用的服务器若被删除，客户端可能切换到其他条目，应在更新后确认当前选中项。

规则资源更新后，集合内容可能发生变化。重要业务域名不应只依赖宽泛集合，可以添加更明确的高优先级规则。更新资源后抽查常用直连、代理和阻断目标，尤其检查内部域名和局域网服务。若新资源导致异常，先使用自定义规则纠正具体目标，再分析集合变化，不要直接堆叠多个相互覆盖的规则包。

安全处理配置与诊断信息

订阅地址、服务器身份字段和导出的完整配置都可能包含账户信息。保存备份时应限制访问范围，发送日志时只保留错误上下文，并替换地址、令牌和身份字段。不要把完整配置直接粘贴到公开讨论区。需要展示问题时，通常保留协议类型、传输方式、错误阶段和已匿名化的路由结构就足够诊断。

远程协助前先创建临时备份，记录系统代理与 TUN 当前状态。完成后检查订阅分组、自定义规则和操作系统网络设置是否被改动。客户端行为突然变化时，也应先比对本地设置，而不是仅关注服务器。更多具体症状与恢复步骤可查阅常见问题的故障排查分类。

CHAPTER 08

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

第一阶段：固定一条最小工作链路

进阶的起点不是增加参数，而是建立一条能够稳定复现的最小链路。选择一个客户端、一项活动服务器、自动配置系统代理和一套简单路由，记录本地入站、默认出站与 DNS 行为。确认浏览器请求能够进入日志，直连与代理目标分别命中预期出站。以后每次修改都与这条基线比较，才能知道改变产生了什么结果。

在基线阶段不要同时使用多个客户端、多个系统代理来源和多个 DNS 接管层。v2rayN 负责桌面连接时，让它成为唯一修改系统代理的工具；Android 上只保持一个活动 VPN 会话。服务器列表可以很多，但测试时只固定一个条目。若条目切换与配置修改同时发生，连接结果变化无法归因。

第二阶段：掌握配置对象与标签

能够阅读完整配置后，重点理解 inbounds、outbounds、routing、dns 和 log。入站标签可用于区分系统代理、TUN 或特定应用来源；出站标签让路由指向代理、直连、阻断或其他链路；DNS 服务器也可指定出站路径。标签名称本身可以自定义，但引用必须一致。很多“规则不生效”问题实际是标签拼写或作用域不一致。

阅读客户端生成配置时，应把自动生成部分与用户自定义部分分开。客户端可能在启动时重写配置文件，直接编辑临时文件会在下次启动时丢失。优先使用客户端提供的自定义配置、路由规则或高级设置入口；确实需要外部维护时，先了解合并顺序。若自定义对象与客户端生成对象使用相同键名，后写入的一方可能覆盖前者。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

这段示例可以作为配置结构练习，但没有包含远端代理出站，因此不能单独完成代理连接。它展示了本地 SOCKS 入站、直接出站和阻断出站的关系。实际客户端通常自动分配端口并生成远端协议字段，手动合并时要避免端口与现有入站冲突。监听地址保持回环地址，可以限制局域网设备访问本地代理。

第三阶段：让 DNS 与路由使用同一套意图

成熟配置会明确回答三个问题：某类域名由哪台 DNS 解析，DNS 请求通过哪个出站发送，解析结果由哪条路由处理。仅设置一个公共 DNS 地址并不能自动解决分流问题。可以根据域名集合选择 DNS 服务器，让直连域名通过直连 DNS 解析，让需要代理的域名通过代理路径解析，同时保留对局域网域名的系统解析能力。

调整 DNS 时先保留一条可用回退路径，并记录浏览器是否使用独立 DNS。测试应覆盖域名首次解析、缓存命中和网络切换。出现同一域名时好时坏时，检查是否同时得到不同地址族、是否存在多个 DNS 返回，以及路由是否对 IPv4 与 IPv6 使用不同结果。禁用某个地址族可以作为定位手段，但长期方案应根据当前网络和远端能力决定。

第四阶段：按入站与场景拆分策略

当系统代理、TUN 和应用专用端口并存时，可以通过入站标签采用不同规则。例如系统代理保持日常分流，专用 SOCKS 入站默认走代理，TUN 则优先直连局域网并处理 UDP。这样比在一套超长域名列表中猜测应用来源更清晰。拆分时应给每个入站明确端口、用途和调用方，未使用的入站及时关闭。

场景切换可以通过路由配置组实现，而不是反复编辑单条规则。日常、调试和全局代理可分别保存为清晰预设，切换后在状态栏显示当前模式。调试结束应回到日常规则，避免长期保留全局状态。多个配置组共享自定义规则时，要确认更新顺序，防止一个预设仍引用旧资源。

第五阶段：观察连接而不是猜测连接

进阶排错应建立可观测性。将日志级别临时提高到能够看到路由和连接阶段的信息，复现一次请求后立即恢复日常级别，避免日志快速增长。记录目标域名、解析结果、入站标签、命中规则、出站标签和最终错误，这六项通常能定位问题所在层。只记录“打不开”无法区分应用未进入代理、DNS 失败、规则直连还是远端握手失败。

系统工具可以补充客户端日志。查看监听端口确认内核是否接受连接，查看路由表确认 TUN 是否接管，查看 DNS 配置确认解析入口，使用连接测试确认目标端口是否可达。工具结果应与客户端状态一起解释：目标端口可达不代表协议握手正确，日志显示内核运行也不代表应用已经连接本地端口。

第六阶段：建立变更与回退纪律

每次只改一个主要变量，是配置长期可维护的关键。修改路由时不同时更换 DNS，调整 TUN 时不同时更新客户端，切换服务器时不同时改变传输参数。变更前导出当前配置，变更后使用固定测试目标验证；失败时直接回退，而不是继续叠加临时修复。临时修复一旦验证有效，也应整理成明确规则并删除重复项。

配置文档应记录目的而不只是参数。例如“私有网段直连用于访问局域网设备”比单独记录 geoip:private 更有维护价值。未来规则资源或网络环境变化时，可以根据目的重新实现，而不是机械保留旧写法。订阅、路由、DNS 和 TUN 都应有各自的恢复方法，避免一项损坏时重置全部设置。

推荐的持续学习顺序

先熟练使用系统代理和最小路由，再学习订阅分组与规则顺序；随后理解 DNS、域名策略和出站标签；基础链路稳定后开启 TUN，观察虚拟网卡与路由表；最后再处理按应用分流、多入站和复杂 DNS。每一阶段都应保留一套简单配置作为对照。遇到新协议或新字段时，先判断它处于协议、传输、安全还是路由层，再查对应文档。

需要快速完成一次连接时，回到快速上手主线；需要选择平台安装包时前往下载页；需要比较 v2rayN、v2rayNG 与 v2flyNG 的适用环境时查看客户端对比。本手册适合作为配置过程中的索引：先根据现象定位章节，再沿数据路径逐层检查，不需要每次从头重做全部设置。