V2Ray Windows版新手到进阶手册

核心概念：客户端、内核与代理配置

先分清三层，再开始操作

v2rayN、v2rayNG 和 v2flyNG 都是图形客户端。客户端负责保存服务器资料、管理订阅、生成内核配置，并提供系统代理、路由、日志等操作入口。Xray 或 V2Fly 则属于代理内核，负责按照配置建立连接、处理协议与传输、执行域名和 IP 路由。两者不能混称：点击客户端里的“启动”并不是图形界面亲自处理所有网络流量，而是客户端整理配置后调用内核。排错时应先判断问题发生在界面管理、内核启动、远端配置，还是应用根本没有接入本地代理。

第三层是代理配置。它描述服务器地址、端口、用户标识、协议、传输、TLS、路由和 DNS 等参数。客户端只是这些数据的管理工具，配置能否使用取决于各字段是否彼此匹配。订阅是批量分发配置的一种方式，不等同于客户端，也不等同于内核。更新订阅成功，只说明客户端取得并解析了内容；它不直接证明其中每个配置都能建立连接。反过来，订阅更新失败也不代表本地内核损坏，可能只是订阅地址、网络入口或返回格式存在问题。

一次请求经过哪些环节

以浏览器访问网页为例，完整路径通常是：浏览器读取系统代理设置，把请求交给 v2rayN 的本地 HTTP 或 SOCKS 监听端口；内核根据路由规则选择直连或代理出口；若选择代理出口，再依据服务器配置建立远端连接。任意一环断开，外观都可能只是“网页打不开”。因此不应一开始就反复更换配置。先确认本地监听是否存在，再确认应用是否把流量送到该监听端口，然后看内核日志是否收到请求，最后才检查远端参数和网络条件。

系统代理与路由分流也属于不同层次。系统代理回答“哪些遵循系统设置的应用会把请求交给客户端”，路由规则回答“内核收到请求后使用哪个出口”。如果终端程序没有读取系统代理，修改十次路由规则也不会改变结果，因为请求从未进入内核。同样，打开 TUN 只是扩大接入范围，不会自动修复错误的服务器地址、TLS 参数或用户标识。明确这条边界，是后续设置不互相干扰的基础。

建立可回退的学习环境

首次配置时只保留一个已知来源的服务器配置，暂时使用默认路由，不立即启用 TUN，也不同时改 DNS。先让浏览器通过系统代理完成一次可重复验证，再逐项增加功能。每完成一个阶段，记录客户端中的关键选项、本地端口和当前配置名称。这样即使后续分流规则有误，也可以退回“单配置、默认路由、系统代理”的基线，而不是重装客户端。重装通常只清理界面或文件，不能自动修正订阅内容、远端参数和应用自身代理设置。

选择客户端：按平台与内核需求判断

桌面平台优先使用 v2rayN

Windows、macOS 和 Linux 的主线选择是 v2rayN。它提供桌面图形界面，统一管理订阅、配置、系统代理、路由、DNS、TUN 和日志。Windows 下载页同时提供桌面版与经典 WPF 版：桌面版采用跨平台界面，适合希望在不同桌面系统保持相近操作逻辑的用户；经典 WPF 版使用 Windows 原生桌面技术，适合已经熟悉传统 v2rayN 操作位置的用户。两者都是客户端选择，不应与协议或内核类型混为一谈。

选择桌面包时还要核对处理器架构和包格式。常见 Windows 桌面设备选择 x64；macOS 需要先确认设备使用 Apple Silicon 还是 Intel 芯片；Linux 除 x64 与 arm64 外，还应按发行版选择 deb 或 rpm。架构不匹配通常表现为安装程序不能启动、系统提示格式不受支持，或程序启动后立即退出。这类问题发生在客户端运行层，与订阅地址和服务器配置无关，应先返回客户端下载页重新确认平台入口。

Android 在 v2rayNG 与 v2flyNG 之间选择

Android 首推 v2rayNG。它以 Xray 内核为主要执行组件，适合需要常见协议、路由和分应用代理设置的场景。v2flyNG 使用 V2Fly 内核，可作为明确需要 V2Fly 行为或已有对应配置流程时的备选。两款应用的界面和设置位置并不完全相同，同一个订阅能否导入也要看配置字段与内核能力，不应仅凭名称接近就假设所有选项可以一一对应。

Android 下载包通常分为 arm64 与通用版。较新的主流手机通常使用 arm64，无法确认架构时再选通用版。安装完成后，系统会在首次启动 VPN 接入时显示授权提示；该授权用于建立本地虚拟网络接口，是应用接管流量所需的系统机制。若设备中已有其他 VPN 类连接处于活动状态，应先结束冲突连接，因为系统通常只允许一个此类接口同时生效。后台运行还会受到省电策略影响，这部分应在连接基线正常后再处理。

不要用功能数量替代实际需求

客户端选型应从三个问题开始：设备平台是什么，现有配置要求哪类内核能力，应用准备通过哪种方式接入。若主要需求是 Windows 浏览器和常规桌面程序，v2rayN 配合系统代理通常已经足够；若 Android 需要分应用代理，可在 v2rayNG 中配置纳入或排除范围；只有遇到不读取系统代理的程序，才进一步评估应用自身代理参数或 TUN。先用最小方案覆盖需求，维护成本会明显低于一开始同时启用所有高级功能。

从旧客户端迁移时，优先重新导入订阅或标准分享配置，不要直接搬运整个程序目录。旧目录可能包含过期的路由文件、端口设置、日志和界面状态，复制后容易把历史问题一起带入。迁移完成后，先选择单个配置并确认本地监听，再逐项恢复分流规则。服务器配置属于敏感连接资料，应只保存到受控设备和可靠备份位置；截图或排错记录中应遮盖订阅地址、用户标识和认证信息。

如果仍无法确定，可先阅读客户端对比。确定平台与客户端后再进入安装阶段，避免把错误架构、错误包格式造成的启动失败误判为订阅或网络故障。

安装与首次启动：先确认内核和监听端口

Windows 的安装与目录边界

在 Windows 上取得与系统架构匹配的 v2rayN 包后，按下载页标注的包类型完成安装或解压。若使用需要解压的形式，应放到当前账户具有读写权限的固定目录，不要长期从压缩文件预览窗口或临时下载目录运行。客户端需要保存配置、更新组件并写入日志，目录权限不足时可能出现界面能打开但配置无法持久化、内核无法释放或更新后文件缺失等现象。

首次启动后先不要导入大量订阅。打开客户端的设置或日志区域，确认内核进程能够被调用，并记录本地 HTTP 与 SOCKS 监听地址。常见监听地址使用回环接口 127.0.0.1，表示只允许本机程序访问；端口由客户端配置决定，不应把教程中的示例端口当成当前设备的固定值。若系统防护工具弹出网络访问提示，应根据本机使用范围判断，不需要为了本机回环代理而把监听暴露到公共网络。

macOS、Linux 与 Android 的首次授权

macOS 首次运行下载的应用时，系统可能要求确认应用来源或授予网络配置相关权限。完成授权后，应检查菜单栏或客户端界面中的系统代理操作是否能写入当前网络服务。切换 Wi-Fi、有线网络或其他网络服务后，系统代理状态可能需要重新确认，因为不同网络服务可以保存各自设置。Linux 的桌面环境对系统代理的支持并不完全一致；部分应用读取桌面代理设置，部分命令行程序只读取自身参数或环境变量，所以“客户端已运行”与“所有程序已接入”仍是两回事。

Android 首次连接时需要确认系统 VPN 授权。授权后，状态栏出现系统提供的 VPN 标识，只表示虚拟接口已经建立，不表示远端配置一定可用。应先选中一个配置，观察客户端是否出现明确错误，再用浏览器做基础访问测试。若应用切到后台后很快断开，应检查电池优化、后台活动权限和系统任务清理策略；若只有部分应用不通，则继续检查分应用代理范围，而不是反复重新安装。

1. 确认客户端自身可以稳定启动 关闭重复打开的同名进程，再启动一个实例。若界面立即消失，先检查系统架构、运行权限与客户端日志，不处理订阅。
2. 确认内核被正常调用 在日志中查找配置解析、监听失败或权限相关信息。此阶段只判断本地执行链，不以网页访问结果代替内核检查。
3. 确认本地端口处于监听状态 记录 HTTP、SOCKS 或混合监听的实际端口。后续浏览器、终端和系统代理都必须指向相同端口类型。
4. 保存一份初始设置记录 记录客户端类型、内核选择、监听地址、端口和是否启用系统代理，作为后续排错的基线。

Windows 查看指定端口是否处于监听状态，示例端口为 10809：

netstat -ano | findstr :10809

如果命令没有结果，说明该端口当前没有监听，或实际端口并非示例值；应回到客户端查看本地监听设置。如果结果显示端口已被其他进程占用，可根据最后一列 PID 在任务管理器中定位进程。重复启动 v2rayN、其他本地代理程序或开发工具都可能产生冲突。详细处理步骤可参考v2rayN 本地端口被占用排查。

首次连接只验证最短路径

完成本地检查后，导入一个配置并选择它作为活动项。先使用客户端默认路由和默认 DNS，不启用复杂规则。打开系统代理后，用一个明确读取系统代理的浏览器访问普通 HTTPS 页面，同时观察日志是否出现对应域名请求。如果浏览器有请求而连接失败，问题进入远端配置或网络层；如果日志完全没有请求，重点检查浏览器是否使用独立代理、系统代理是否写入成功以及端口是否一致。

验证结束后主动测试“清除系统代理”。关闭客户端前先恢复系统代理，可以避免操作系统仍指向已经停止的本地端口。若客户端异常退出后所有网页都无法访问，第一步也应检查并清除残留系统代理，而不是立即修改 DNS。安装阶段的目标不是开启全部功能，而是建立一个可启动、可监听、可接入、可退出的本地基线。

订阅与配置管理：区分获取、解析和连接

订阅更新包含三个独立结果

订阅更新至少经过地址访问、内容解析和配置写入三个阶段。客户端首先访问订阅地址；取得响应后，再判断内容格式并解析配置；最后把有效项目写入对应分组。只有三个阶段都完成，列表才会更新。若提示网络请求失败，应检查订阅地址能否从当前网络访问、系统时间是否正确，以及客户端更新订阅时是否使用了合适的网络路径。若提示解析失败，则应关注返回内容是否为客户端支持的格式，而不是继续更换本地端口。

订阅地址本身通常具有访问权限，应视为敏感数据。不要把完整地址放进公开截图、日志附件或浏览器同步笔记。添加订阅时，为它设置清楚的分组名称，例如按用途或来源命名，而不要只写“订阅一”“订阅二”。分组名称不会改变连接行为，但能帮助后续判断哪次更新覆盖了哪些配置。多个来源混在同一组时，一旦出现同名项目或字段差异，很难确认问题来自哪一侧。

导入后的检查不止是“列表里出现了”

配置进入列表后，至少核对协议类型、服务器地址、端口、传输方式、TLS 状态和服务器名称等关键字段。用户标识等认证数据可以不在日常界面完整展示，但其存在与格式必须正确。VLESS、VMess 等协议名称只描述配置的一部分；WebSocket、gRPC、TCP 等传输方式以及 TLS、SNI、路径或服务名仍需匹配。只把协议字段改成相同名称，不能修复其他字段不一致的问题。

批量测试的结果只能作为筛选线索。测试失败可能来自当前网络、远端状态、测试目标或 DNS，测试成功也不等于所有应用都已正确接入。更可靠的方法是选中一个配置，保持默认路由，用浏览器发起实际请求并结合内核日志判断。对同一问题同时轮换多个配置，会让日志和系统代理状态频繁变化，不利于确认因果。

1. 新增订阅并命名分组 从客户端的订阅管理入口添加地址，确认首尾没有空格或换行。保存后只更新刚添加的分组，便于识别返回结果。
2. 查看更新提示与分组变化 区分请求失败、解析失败和写入后无有效项目。不同阶段需要检查的对象不同，不要统一归因于内核。
3. 选择单个配置核对字段 确认协议、地址、端口、传输和 TLS 相关字段完整，再设为活动配置并启动内核。
4. 保留最近可用的回退项 更新前导出或备份当前配置数据库。若来源内容发生变化，可快速判断是更新引入的问题还是本机环境变化。

更新失败时按阶段检查

若客户端显示无法连接订阅地址，先确认地址是否完整，并检查系统代理当前是否指向一个未运行的本地端口。某些情况下，浏览器能访问并不代表客户端的订阅请求走相同路径，因为两者可能使用不同代理设置。若返回的是登录页面、错误页面或普通文本，客户端通常会报告格式异常。此时应核对订阅来源，而不是手工把网页内容当作分享配置导入。

若更新成功但列表为空，检查是否启用了会过滤特定项目的分组设置，以及返回内容是否包含当前客户端可识别的配置。若列表更新后原有项目消失，先不要连续多次刷新；查看该订阅是否采用覆盖更新，并从备份恢复需要保留的手工项目。更完整的分类步骤可在订阅更新常见问题中查阅，首次导入的精简流程则见快速上手的订阅步骤。

手工配置适合精确核对

当只有单个配置或需要确认具体字段时，可以使用客户端的手工新增功能。填写时从上到下逐项核对，不根据相似名称猜测。服务器名称用于 TLS 握手时，应与配置要求一致；传输路径、Host、服务名等字段也有各自作用。出现证书或 TLS 握手错误时，优先检查系统时间、证书有效期、域名匹配与 SNI，相关原理可参考TLS 握手与证书报错排查。不应把关闭证书验证当作日常处理方式。

完成订阅阶段后，应能回答四个问题：配置来自哪个分组，当前活动项是哪一个，内核使用哪类配置，本地监听端口是什么。只有这些信息明确，下一阶段的系统代理和应用接入测试才有可靠基础。

代理模式与应用接入范围

系统代理只覆盖读取系统设置的应用

v2rayN 中的“自动配置系统代理”通常会把操作系统代理地址指向客户端的本地监听端口。浏览器和部分桌面应用会读取这项设置，因此可以在不单独配置的情况下接入。另一些程序拥有独立代理设置，或者完全忽略系统代理，例如部分终端命令、开发工具、游戏平台和自带网络栈的应用。系统代理已经开启但某个程序仍直连，并不自动说明 v2rayN 或内核失效，应先查该程序的接入能力。

“清除系统代理”用于移除客户端写入的系统设置。当客户端停止、本地端口变化或准备切换到其他网络工具时，应先清除旧代理。若系统仍指向 127.0.0.1 的某个端口，但该端口没有进程监听，遵循系统代理的应用会统一出现连接失败。这类故障常发生在程序异常退出之后，表现看似是整个网络不可用，实际只需要恢复系统代理。

HTTP 与 SOCKS 端口不能随意互换

本地 HTTP 代理适合明确支持 HTTP 代理的应用，SOCKS 代理则通过 SOCKS 协议转发连接。客户端可能提供独立端口，也可能提供兼容多种接入的混合端口。应用填写时必须与监听类型一致：把 SOCKS 端口填进只接受 HTTP 代理的字段，通常会得到协议握手错误或连接被重置。地址一般使用 127.0.0.1，表示连接本机客户端；除非明确配置了局域网监听和访问控制，不应把回环地址替换成任意网卡地址。

浏览器可以先使用系统代理做基线测试。如果浏览器安装了代理扩展，应确认扩展处于“跟随系统”还是自定义模式。扩展中的固定端口可能覆盖系统设置，造成客户端切换端口后浏览器仍访问旧监听。隐私窗口、不同浏览器配置文件也可能使用独立规则。浏览器可用而终端不可用时，应把两者分开排查，具体步骤见浏览器与终端的代理范围检查。

终端程序通常需要显式设置

很多命令行工具读取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 等环境变量，但具体支持范围由工具决定。环境变量还分当前进程、当前终端会话和系统永久设置。排错时建议只在当前终端临时设置，验证结束后关闭窗口即可恢复，避免把过期端口长期写进全局环境。下面示例假设 v2rayN 的 HTTP 监听端口确实为 10809；使用前应替换为客户端界面显示的实际端口。

Windows 命令提示符当前会话：

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
curl https://example.com

PowerShell 当前会话：

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
curl.exe https://example.com

若命令执行后，内核日志仍看不到请求，应检查该工具是否读取这些变量、变量名是否正确，以及地址和端口是否对应 HTTP 监听。若日志已经出现请求但连接失败，再进入路由、DNS 或远端配置检查。不要只凭终端输出中的“超时”判断具体层次，因为本地端口未监听、远端不可达和域名解析失败都可能产生类似表象。

验证代理范围，而不是只看出口结果

可靠验证应同时观察三个信号：应用确实使用目标代理设置；客户端日志收到该应用产生的域名或连接；路由结果符合预期。只查看一个出口页面不能说明所有应用都采用相同路径，也不能说明 DNS 查询经过了预期处理。测试时分别打开浏览器、终端和一个目标应用，每次只产生少量可识别请求，再从日志中判断是否进入内核。

完成本阶段后，应能明确哪些应用跟随系统代理，哪些应用使用自身设置，哪些仍无法接入。只有第三类应用确实存在且无法逐项设置时，才有理由考虑 TUN。对于已经能通过系统代理稳定工作的环境，直接进入路由分流通常更简单。

路由分流：在请求进入内核后选择出口

路由解决的是出口选择

路由规则只处理已经进入内核的流量。它根据域名、IP、端口、网络类型、入站标签等条件，把请求交给代理、直连或阻断等出口。最常见的目标是让局域网与明确的内部地址直连，其余请求使用代理；也可以按域名列表细分。无论使用哪种策略，都应先定义默认行为，再添加范围清楚的例外规则。如果规则只写了若干例外，却没有理解最终兜底出口，未命中的请求可能走向与预期不同的路径。

规则通常按顺序匹配，前面的宽范围条件可能遮住后面的精确条件。例如先写一条覆盖全部 TCP 与 UDP 的代理规则，后面的私有地址直连规则就没有机会命中。设计顺序时，一般先放必须直连或必须单独处理的精确规则，再放范围较大的分类规则，最后使用兜底。修改后要用明确域名逐条验证，而不是一次导入很长的规则集后只测试一个网页。

域名规则、IP 规则与解析策略

域名规则在内核仍掌握原始目标域名时最直观，可以匹配完整域名、域名后缀或预定义分类。IP 规则依赖目标 IP；当请求最初以域名形式出现时，是否为路由执行额外解析受 domainStrategy 等设置影响。解析策略改得过于激进，可能增加 DNS 查询并改变匹配路径；完全不解析，又可能让只写 IP 条件的规则无法处理域名请求。应根据规则实际使用的条件选择，而不是把某个策略名称当作普遍最优值。

私有地址直连通常用于本机、局域网设备和内部服务，但仍需结合实际网络。企业网络、虚拟机、容器和开发环境可能使用不同私有网段；同时存在多个虚拟网卡时，系统路由也会影响连接去向。域名最终解析到私有地址时，还要留意 DNS 结果是否来自当前网络。遇到“域名访问失败但直接输入内网 IP 可用”，应比较域名解析结果和路由命中，而不是只调整代理出口。

用于解释规则结构的 Xray 路由片段，出口标签需与完整配置中的 outbound 标签一致：

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

这段配置表达的是：指定内部域名直连，私有 IP 直连，其余 TCP 与 UDP 交给名为 proxy 的出口。它是完整配置中的路由部分，不能单独作为客户端全部配置运行。若客户端通过图形界面管理路由，应在对应规则编辑器中表达同样逻辑，不要直接覆盖客户端生成的其他字段。出口标签不存在时，内核会报告配置错误；规则数据文件缺失或名称不受支持时，也会在启动或匹配阶段出现提示。

从最小规则集逐步扩展

建立路由时，先保留一条私有地址直连和一个明确兜底，确认浏览器、终端与局域网服务都符合预期。然后一次增加一组域名规则，每组都写清目标和维护来源。规则命名应反映用途，例如“局域网直连”“开发服务直连”，不要只写“规则一”。当某条规则导致异常时，可以临时停用该组并回到上一个稳定状态。

DNS 与路由应分别记录。路由决定出口，DNS 决定如何取得地址，两者会相互影响但不是同一个设置。若只有域名失败，先对比解析结果；若 IP 连接也失败，再看出口和远端连接；若请求根本没有进入日志，则返回应用接入层。把这三种现象分开，可以避免在路由页面里不断改 DNS，同时在系统里又设置另一套解析服务。

分流完成后的验收

至少选择三类目标分别测试：一个局域网地址、一个明确要求直连的域名和一个使用代理出口的普通域名。对每个目标记录应用接入方式、解析结果、命中规则和最终出口。如果局域网访问在开启代理后中断，先检查私有地址是否被更宽的代理规则提前匹配；如果某个域名偶尔走不同路径，检查它是否解析到多个地址，以及规则是按域名还是按 IP 生效。

路由稳定后再考虑 TUN。此时即使扩大流量接入范围，仍能依靠已经验证过的规则判断出口。若系统代理阶段尚未厘清路由，直接启用 TUN 会把更多程序和系统流量带入同一套未验证规则，故障范围反而更大。

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

TUN 改变的是流量入口

TUN 通过虚拟网络接口接收系统流量，使不支持 HTTP 或 SOCKS 代理设置的应用也有机会进入内核。它解决的是应用接入范围，不是更换协议，也不会让错误的远端配置自动恢复。启用后，系统路由、虚拟网卡、DNS 和内核入站共同参与处理，因此比系统代理多出若干故障点。只有基础配置已经通过系统代理验证、且确实存在无法单独设置代理的应用时，才建议进入这一阶段。

在桌面系统中，创建虚拟接口或修改路由可能需要额外权限。权限不足时，客户端界面可能显示开关已操作，但日志会出现接口创建、路由写入或驱动访问失败。Android 的 VPN 接入本身采用系统提供的虚拟网络机制，仍需关注授权、其他 VPN 冲突、分应用范围和后台限制。不同平台实现细节不同，不应照搬另一平台的驱动或权限处理步骤。

启用前先固定基线

• 当前活动配置已通过系统代理完成浏览器测试。
• 本地监听端口和内核日志正常，没有持续配置错误。
• 路由规则至少完成私有地址直连与默认出口验证。
• 系统中没有同时运行另一套 VPN 或虚拟网络接管工具。
• 已经记录启用前的 DNS、系统代理和客户端设置。

满足这些条件后，先清理重复的网络接管方式。若准备由 TUN 处理主要流量，可以按客户端说明调整系统代理，避免同一请求经过不必要的重复入口。启用后先测试基础网页，再测试原本不能读取系统代理的目标应用，最后测试局域网服务。每一步都查看日志是否出现请求以及路由选择是否正确。不要在第一次启用时同时导入新的 DNS、复杂规则和多套绕过列表。

1. 关闭可能冲突的虚拟网络连接 结束其他 VPN 会话和同类接管程序，保留正常物理网络。虚拟机与容器网络不必盲目删除，但要记录其网段和路由。
2. 以所需权限启用 TUN 根据客户端日志确认虚拟接口创建成功、路由已写入。只看开关颜色不足以判断系统层是否完成。
3. 验证 DNS 与普通 TCP 请求 先测试域名解析，再测试浏览器连接。如果 IP 可用而域名失败，重点检查 TUN 使用的 DNS 路径。
4. 测试目标应用与局域网 确认原本未接入的程序已进入日志，同时确认打印机、路由器管理页和内部服务仍能按规则直连。

常见冲突如何分层判断

启用后完全断网，首先查看虚拟接口和默认路由是否建立，再检查内核是否仍在运行。若关闭 TUN 后立即恢复，问题集中在 TUN 入口、路由或 DNS，不必重装客户端。若只有域名失败而直接 IP 可用，优先检查 DNS 服务器可达性、查询是否进入预期出口以及解析结果。若只有局域网失败，检查私有地址规则和系统路由优先级，尤其是虚拟网卡与实际局域网使用重叠网段时。

某个应用仍未进入代理时，检查它是否被分应用规则排除、是否使用独立网络接口，或目标流量是否属于当前 TUN 实现未接管的范围。Android 上还要确认应用是在“仅代理所选应用”还是“绕过所选应用”的逻辑下配置，两个模式含义相反。相关后台与分应用问题可参考Android 权限、省电设置与分应用代理。

DNS 是 TUN 排错的重点

TUN 接管范围扩大后，系统服务和更多应用的 DNS 请求也可能进入处理链。需要明确由谁接收查询、使用哪个服务器、查询结果是否用于路由，以及返回地址是否能从当前出口访问。若同时配置系统 DNS、客户端 DNS 和应用内加密 DNS，实际路径可能与预想不同。应暂时减少层数，先使用一套明确的客户端 DNS 方案完成验证，再按需求恢复应用自有设置。

日志中若出现域名解析成功但后续连接失败，应继续查看解析到的地址和路由出口；若没有查询记录，可能是应用使用缓存或自有解析机制。刷新缓存可以用于验证，但不应把反复清缓存当作长期方案。最终目标是让同一域名在相同网络条件下得到可解释、可重复的解析和路由结果。

退出 TUN 时恢复系统状态

关闭 TUN 后确认虚拟接口和临时路由被清理，并检查系统代理是否仍指向正在运行的客户端。如果客户端异常退出导致路由残留，可先重新启动客户端并正常关闭 TUN，再使用系统网络工具检查路由。恢复过程中不要同时重置所有网络设置，否则会丢失原有静态地址、企业网络或虚拟机配置。保留启用前记录，可以逐项对照变化。

TUN 阶段完成的标准不是“开关保持开启”，而是目标应用确实进入内核、局域网仍可访问、DNS 路径明确、关闭后系统能恢复。若系统代理已覆盖全部需求，继续使用较简单的接入方式同样合理。

日常维护与故障排查：从最近变化开始

维护重点是配置、状态和变化记录

日常维护不需要频繁重装。更重要的是保留订阅分组、手工配置、路由规则、DNS 设置和本地端口的记录，并在更新客户端或调整规则前创建备份。备份中可能包含订阅地址和连接认证数据，应存放在受控位置，不应作为普通文本公开传输。恢复时先导入最小配置并验证，再恢复大规模规则，避免无法判断问题来自备份本身还是新环境。

更新客户端后，先确认界面设置是否保留、内核能否启动、本地端口是否变化，再测试系统代理。不要把更新、订阅刷新、路由替换和 TUN 调整安排在同一次操作中。每次只改变一类变量，出现异常时才能回退。若必须迁移设备，记录原客户端类型、架构、内核选择、订阅分组、监听端口、路由策略和特殊应用代理设置，比复制整个旧目录更容易控制风险。

建立统一的故障分类

排错时先记录发生时间、最近变更和受影响范围。若所有遵循系统代理的应用同时失败，检查客户端进程、本地监听和系统代理；若只有单个应用失败，优先看它的独立设置；若相同配置在不同网络表现不同，关注 DNS、网络路径和系统时间。范围判断比错误文字本身更有价值，因为很多“连接超时”不会指出究竟是哪一层超时。

日志要从第一条有效错误开始读

客户端和内核日志可能在一次失败后产生大量连锁提示。应从本次启动或操作时间点开始，寻找最早出现的配置解析、监听、DNS、TLS 或连接错误。后续重复重试产生的行通常只是结果。分享日志前，应删除订阅地址、用户标识、服务器地址和其他敏感字段，只保留错误类型、时间顺序与必要上下文。

若内核提示地址已被使用，先定位占用端口的进程。若提示配置字段无效，回到最近编辑或订阅更新，确认是否导入了当前内核不识别的字段。若出现 TLS 证书相关错误，先同步系统时间，再核对服务器名称和证书域名。若 DNS 查询超时，确认 DNS 请求走向和服务器可达性，不要直接归因于服务器配置。

端口、系统代理与异常退出

本地端口被占用时，先判断是否重复启动了同一客户端，再检查其他程序。直接修改端口可以绕开冲突，但会影响所有手工接入方。修改后应同步浏览器扩展、终端变量、开发工具和局域网设备设置。若占用来自不再需要的旧进程，正常结束该进程通常比长期更换端口更容易维护。

客户端异常退出后，系统代理可能残留。此时浏览器会继续把请求发往不存在的本地端口。可重新打开 v2rayN 使用“清除系统代理”，或在操作系统网络设置中恢复。不要因为网页全部失败就立即删除网络适配器。若使用 TUN，还要额外确认虚拟接口和路由是否清理；系统代理残留与 TUN 路由残留是两类问题，需要分别检查。

订阅、时间与证书的周期检查

订阅不必在每次启动时无条件连续刷新。按实际更新需求设置周期，并保留最近可用配置。刷新后若大量项目同时变化，先验证一个项目，不要立即清空旧记录。系统时间应保持自动同步，因为 TLS 证书验证依赖准确时间；时间偏差可能表现为证书尚未生效或已经过期。服务器名称、SNI 与证书域名也需要匹配，不能通过重复连接消除字段错误。

长期使用中还应关注磁盘空间和日志增长。日志用于排错，但无限保留会增加查找难度。按客户端提供的清理方式处理旧日志，不直接删除不认识的配置数据库。更新前阅读界面中的变更提示，更新后验证最短路径。更多常见现象可从常见问题按“安装配置”和“故障排查”分类查找。

形成可复用的排错记录

一次有效记录应包含平台、客户端、内核、接入方式、活动配置类型、监听端口、是否启用路由与 TUN、错误发生时间、第一条有效日志和已经验证的步骤。不要只写“不能用”。这些信息能快速把问题定位到客户端、内核、配置或应用范围，并避免下次从头尝试。解决后补充真正起作用的修改，同时撤销排错过程中无效的临时设置，防止它们成为下一次故障来源。

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

进阶不是打开更多开关

完成基础阶段后，进阶目标应是让配置可解释、可测试、可回退，而不是同时启用更多功能。一个成熟环境应能明确回答：哪些应用通过系统代理，哪些通过自身设置或 TUN；DNS 查询由谁处理；每类域名和 IP 命中哪条路由；活动配置使用什么协议、传输和 TLS 参数；客户端更新或端口变化后需要同步哪些位置。能回答这些问题，比界面中启用了多少选项更重要。

建议把学习路线分为观察、规则、协议和自动化四层。先学会看客户端与内核日志，建立请求从应用到出口的路径；再维护小规模路由和 DNS 规则；随后理解协议、传输与 TLS 字段之间的组合关系；最后才考虑配置备份、迁移和重复验证流程。每一层都以前一层的稳定基线为前提。

协议、传输与 TLS 分开理解

VLESS、VMess 等属于代理协议；TCP、WebSocket、gRPC 等描述传输承载；TLS 用于建立加密连接并验证对端身份。一个配置能否连接取决于这些层的字段共同匹配。看到“协议相同”不能推断传输路径、服务名、服务器名称或安全参数也相同。学习新配置时，应按协议层、传输层、TLS 层分别列出关键字段，再对应内核日志判断失败发生在哪一步。

TLS 握手发生在建立受保护连接的阶段。系统时间错误、证书有效期不符、服务器名称与证书域名不匹配，都可能导致握手失败。SNI 用于在连接时表明目标服务器名称，不应随意填写为与配置无关的域名。传输层中的路径或服务名则由远端服务配置决定，同样不能凭经验猜测。进阶排错的核心是逐层核对，而不是尝试随机组合。

为路由和 DNS 建立测试清单

路由规则增加后，应维护一组固定测试目标：局域网地址、内部域名、普通直连目标、代理目标以及需要 UDP 的应用。每次修改规则后按相同顺序测试，并记录命中出口。DNS 测试还要记录解析服务器、返回地址和查询是否经过预期入口。固定样本能帮助判断变化来自规则本身，还是目标站点、缓存或当前网络。

规则文件和分类数据更新时，也应先在少量目标上验证。分类名称可能存在包含范围变化，宽范围规则的位置尤其需要复查。自定义规则应写清建立原因和日期，但不需要记录虚构性能数字。若一条规则长期没有明确用途，应考虑移除，减少未来冲突。简单且能解释的规则集通常比大量来源不明的规则更可靠。

把不同设备视为独立环境

桌面与 Android 可以使用同一订阅来源，但系统代理、VPN 接口、后台策略和分应用能力不同。不要假设在 Windows 上验证过的接入方式可以原样复制到 Android，也不要把 Android 的 VPN 授权问题归因于订阅。跨设备排错时，应先确认两端是否选择了同一配置、系统时间是否正确、网络条件是否相近，再比较内核与字段支持。

若多个桌面设备都使用 v2rayN，可统一订阅分组命名和路由目标，但监听端口、安装路径和系统代理仍应按设备记录。macOS 与 Linux 对系统代理的实现不同，命令行工具也可能采用各自环境变量。共享的是配置逻辑，不是操作系统状态。迁移文档应描述“要达到的行为”，同时为每个平台保留具体检查方法。

设计三个稳定配置档位

可以把日常配置分为三个档位。基础档只包含单个活动配置、默认路由和系统代理，用于验证内核与浏览器；分流档加入经过测试的直连规则和明确 DNS 路径，用于日常桌面使用；扩展档在分流档基础上启用 TUN，覆盖不读取系统代理的应用。三个档位都应能够独立回退，出现问题时先降到基础档，而不是删除全部配置。

档位之间的差异需要书面记录，包括系统代理状态、TUN 状态、DNS 设置、路由规则组和应用独立代理。切换后使用同一组测试目标验收。这样可以快速判断故障是由远端配置变化引起，还是由本地高级功能引入。若基础档也失败，就不必继续调整 TUN；若基础档正常而扩展档失败，问题范围已经缩小到虚拟接口、路由或 DNS。

持续学习的资料顺序

先使用概念速查补齐协议、内核、订阅、系统代理和路由术语，再通过客户端对比理解平台差异。遇到具体故障时，从常见问题定位类别，再阅读对应文章。理解 Project V、V2Fly、Xray 与三款客户端的关系，可参考开源生态与客户端选型说明。资料之间应形成“概念—操作—验证—排错”的顺序，而不是只收集零散参数。

到这一阶段，配置工作的重点已经从“让一次连接成功”转为“让行为长期可预测”。保留最小基线、限制同时变化的变量、记录应用接入范围、验证每条路由的命中证据，并对订阅和敏感配置做好受控备份。这套方法适用于 v2rayN、v2rayNG 与 v2flyNG，也能帮助区分客户端界面差异、内核行为和操作系统网络机制。