四平台系统查阅手册

v2rayN 全平台安装配置完整文档

从安装前准备开始，依次覆盖 Windows、macOS、Linux、Android 的客户端下载、订阅导入、代理接管、TUN 与平台差异，最后集中说明路由分流和故障定位。

如果只需要尽快完成第一次连接，可先阅读快速上手教程；本页保留完整的设置背景、平台边界和排错分支，适合安装时逐章核对，也适合连接异常时返回查阅。客户端安装文件统一从下载中心选择，协议、内核和路由名词可配合术语手册理解。

适用客户端：v2rayN、v2rayNG、v2flyNG 最后修订：2026-08-21

一、阅读方式与配置全景

客户端、内核与订阅分别负责什么

完成一套可用配置，需要先区分客户端界面、代理内核和订阅内容三个层次。v2rayN、v2rayNG 与 v2flyNG 是负责展示节点、保存偏好和调用系统能力的图形客户端；Xray 或 V2Fly 属于处理协议、路由和连接的内核；订阅则是服务提供方给出的配置集合，通常包含服务器地址、端口、用户标识、传输方式、TLS 参数与名称等信息。客户端导入订阅后，不是立刻替所有应用接管网络，而是先把节点交给内核，再由系统代理或 TUN 决定哪些应用流量进入本地代理入口。

因此，“客户端显示启动”与“浏览器已经使用代理”是两件事。内核运行正常，只能说明本地监听端口已经建立；浏览器是否经过该端口，还取决于系统代理设置、浏览器自身代理策略、路由规则以及 DNS 请求的处理方式。排错时应沿着数据流逐段确认：订阅内容能否解析、所选节点能否建立连接、本地入口是否监听、应用是否把请求交给入口、路由是否给出正确出站、DNS 是否返回可用结果。把这些环节混在一起反复重装，往往无法定位真正原因。

四个平台的推荐客户端范围

平台 客户端 主要接管方式 安装时重点
Windows v2rayN 系统代理、TUN 权限、防火墙与系统代理状态
macOS v2rayN 系统代理、TUN 芯片架构、应用权限与网络授权
Linux v2rayN 桌面代理、环境变量、TUN 发行版包格式、桌面环境和提权
Android v2rayNG、v2flyNG 系统 VPN 接口 后台限制、省电策略与应用分流

桌面平台统一优先使用 v2rayN，便于在相似的界面结构下管理订阅、路由与日志。Android 首选 v2rayNG；需要使用 V2Fly 内核路线时，可选择 v2flyNG。两款 Android 客户端的基础操作相近，但配置数据库和内核能力不应假定完全互通。更换客户端时，应重新导入原始订阅，而不是复制另一款客户端的内部数据目录。

完整配置的标准顺序

  1. 确认平台和架构。先判断设备运行的操作系统、处理器架构和发行版包格式，再到下载中心选对应安装文件。
  2. 完成客户端安装。首次启动时处理系统权限、防火墙或网络接口授权，确认界面可以正常打开。
  3. 导入并更新订阅。建立订阅分组，输入完整地址，主动更新一次并检查节点列表是否出现。
  4. 选择节点与模式。先使用基础系统代理完成验证，再根据应用覆盖范围决定是否启用 TUN。
  5. 验证请求路径。检查客户端日志、浏览器访问和系统代理状态，不以单一的延迟结果代替实际连接验证。
  6. 最后调整路由。基础连接成立后再增加直连、代理或阻断规则，每次只改变一类条件。

系统代理适合浏览器和遵循系统网络设置的桌面应用，配置简单、影响范围清楚；TUN 通过虚拟网络接口接管更广泛的流量，适合不读取系统代理、只发 UDP 或自行建立网络栈的程序，但它同时引入管理员权限、路由表、DNS 接管和其他网络工具冲突等变量。合理做法不是默认开启所有功能，而是从最少配置开始，确认主链路成立后再扩展覆盖范围。这也是本页各平台章节都采用“安装、订阅、系统代理、TUN、平台问题”顺序的原因。

二、安装前准备：平台、架构、订阅与权限

判断系统与处理器架构

下载前应先确认操作系统版本、处理器架构和安装包类型。Windows 常见桌面设备使用 x64；macOS 需要区分 Apple Silicon 与 Intel；Linux 除 x64、arm64 外，还要确认发行版采用 deb 还是 rpm 包管理体系；Android 近年的主流设备通常使用 arm64，只有无法确认架构或安装失败时再考虑通用包。架构选择错误通常表现为安装器无法启动、系统提示包不兼容，或应用安装后立即退出。它与订阅、节点和网络状态无关，不应通过修改代理参数解决。

Windows 可在“设置 → 系统 → 系统信息”查看系统类型。macOS 可打开“关于本机”，芯片栏出现 Apple 系列名称时选择 Apple Silicon，显示 Intel 处理器时选择 Intel。Linux 可在终端执行 uname -m，输出 x86_64 对应 x64，输出 aarch64 或 arm64 对应 arm64。Android 架构通常不必借助额外工具判断：优先安装 arm64 包，系统明确拒绝后再使用通用包，不要在来源不明的检测页面上传设备信息。

uname -m

# Debian、Ubuntu 及其衍生发行版查看包架构
dpkg --print-architecture

# Fedora、Rocky Linux 等发行版查看机器架构
rpm --eval '%{_arch}'

准备有效订阅与基础信息

订阅地址本质上是客户端获取配置集合的入口，必须保持完整。复制时常见问题包括遗漏末尾参数、混入换行、把网页展示文本而非实际地址复制到剪贴板，或者订阅已由服务端停用。建议先把订阅名称、更新地址和用途记录清楚，但不要在截图、日志或公开求助内容中暴露完整地址，因为其中可能包含用于识别账户的令牌。客户端内应为不同来源建立独立分组，避免将多个订阅覆盖到同一组后无法判断节点来自哪里。

如果服务提供方给出了多个订阅格式，优先选择明确标注适用于 V2Ray、Xray 或对应客户端的格式。普通网页地址、控制台登录地址和订阅地址不是同一内容。成功导入的判断标准也不是“没有弹出错误”，而是订阅分组下出现了可识别的配置条目，并且手动更新时日志显示获取与解析完成。如果列表为空，应先检查订阅响应和格式，不要立即切换 TUN、DNS 或路由模式。

权限、时间与网络环境

客户端的普通代理功能通常只需要用户权限，TUN 则可能需要创建虚拟网络接口、写入路由表或修改 DNS，因此会触发管理员授权。授权应在系统原生提示中完成。若设备由组织策略管理，相关权限可能被限制，此时应先确认设备管理规则，而不是反复启动客户端。Windows 防火墙可能在首次运行内核时询问网络访问范围；macOS 可能要求允许网络配置；Linux 可能通过 polkit 或终端提权；Android 首次连接会出现系统 VPN 授权对话框。拒绝授权后，界面按钮可能仍可操作，但流量接管不会完整建立。

设备时间也会影响 TLS 握手和带有效期的认证。应启用系统自动校时，并确认时区正确。错误的日期、时间或时区可能导致证书尚未生效、证书已过期或认证时间窗不匹配。另一个准备项是暂时减少网络变量：首次配置时关闭其他代理、网络过滤器和同类虚拟网卡，只保留当前客户端；优先在稳定的家庭或移动网络上验证。公共网络如果要求先打开认证页，应在启用代理前完成认证，否则所有连接都可能被重定向到登录页面。

建立可恢复的配置习惯

安装前不需要迁移来历不明的整套配置。更稳妥的方法是保存订阅来源说明、路由规则意图和少量必要偏好，然后在新客户端中重新建立配置。若从旧版客户端更新，应先退出正在运行的内核，再按照当前安装方式覆盖或并行安装。不要同时启动两个监听相同本地端口的实例，否则后启动的进程会报告地址被占用。便携目录也不应放在需要频繁授权写入的位置，日志、数据库和更新文件都需要稳定的写权限。

准备完成后，到下载中心按平台选择客户端。下载页提供 Windows 桌面版与经典 WPF 版、macOS 两种芯片架构、Linux 的 deb 与 rpm 包，以及 Android 的 v2rayNG、v2flyNG 安装入口。安装文件的选择只由平台和架构决定，不由订阅协议决定；VMess、VLESS、Trojan 等协议属于导入后的内核配置，不需要为每种协议安装不同客户端。

三、Windows：v2rayN 安装、订阅与系统代理

选择桌面版或经典 WPF 版

Windows 平台首选 v2rayN。下载中心提供桌面版和经典 WPF 版：桌面版采用新一代跨平台界面，适合希望与 macOS、Linux 使用体验保持接近的用户；WPF 版沿用经典 Windows 界面结构，适合已经熟悉旧版菜单位置和操作逻辑的用户。两者都用于管理订阅、启动内核和设置系统代理，但界面布局可能不同。不要同时运行两个版本，它们可能争用本地监听端口、系统代理状态或配置目录。

安装或解压时，目录应具有普通用户写权限，路径尽量稳定。若采用安装程序，按系统向导完成即可；若使用可独立运行的包，应先完整解压再启动，不要直接从压缩预览窗口运行。首次启动若出现防火墙提示，应允许当前可信网络范围内的访问，以便本地应用连接客户端监听端口。客户端本身通常不需要对外提供局域网服务，因此没有明确需求时，不要开启“允许来自局域网的连接”。

导入订阅并选择活动节点

进入订阅分组管理，新增一个有辨识度的分组名称，粘贴完整订阅地址并保存。保存动作只建立来源记录，随后还需要执行“更新当前订阅”或“更新全部订阅”。更新完成后回到服务器列表，确认名称、地址类型和传输信息已经出现。节点数量不是可用性的证明，应选择一个配置条目设为活动服务器，再进行真连接测试。若更新后列表仍为空，先查看日志中的 HTTP 状态、解析错误或格式提示，不要重复创建相同分组。

延迟测试只能作为初步筛选。部分服务器不响应普通探测，但能够建立真实代理连接；也可能出现探测值正常、实际握手失败的情况。更可靠的方法是选中节点后执行真连接延迟测试，再启动系统代理并打开一个此前未缓存的网页。测试期间观察日志是否出现成功连接、握手失败、超时或认证拒绝。需要更细的选择方法时，可阅读v2rayN 首次连接教程。

系统代理模式的使用边界

系统代理开启后，v2rayN 会把 Windows 的代理设置指向本地监听地址。遵循系统设置的浏览器和桌面程序会把 HTTP、HTTPS 请求交给客户端，再由路由规则决定直连或代理。建议第一次验证使用“自动配置系统代理”或界面中等价的标准模式，保持默认本地端口，不急于手工修改。切换节点时通常无需关闭系统代理，客户端会让新的活动配置接管后续连接；已经建立的长连接可能继续使用旧路径，必要时重新打开应用。

命令行程序并不一定读取 Windows 图形界面的系统代理。PowerShell、包管理器和开发工具各有自己的代理规则，有的读取环境变量，有的需要单独参数，有的直接使用 WinHTTP。遇到“浏览器可用、终端不可用”时，应把它视为应用代理机制差异，而不是节点突然失效。可先查看 WinHTTP 当前状态，但不要把该结果等同于浏览器代理：

netsh winhttp show proxy

# 查看当前会话中是否设置了代理环境变量
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

若只希望当前终端会话使用本地 SOCKS 或 HTTP 入口，应按照具体工具的文档设置临时参数，退出会话后恢复。不要在不清楚影响范围时把代理环境变量写进系统级配置，因为客户端未启动时，这些程序仍会尝试连接已经不存在的本地端口。浏览器与终端分开排查的完整路径可参考系统代理不生效怎么办。

TUN、权限与 Windows 特有问题

TUN 模式适用于不读取系统代理、需要 UDP 或希望统一接管更多应用的场景。启用前先退出其他同类客户端，使用系统授权允许创建虚拟接口，再观察 v2rayN 日志是否完成接口初始化、路由写入和 DNS 监听。若启用后立即断网，先关闭 TUN 并恢复系统代理，确认基础连接仍然成立；随后检查是否存在其他虚拟网卡、企业网络软件、游戏加速工具或安全软件同时修改路由表。一次只保留一个负责默认路由的工具。

Windows 睡眠、网络切换或客户端异常退出后，可能留下开启的系统代理状态。其典型现象是 v2rayN 已关闭，但浏览器仍尝试访问本地监听端口。重新启动客户端并正常关闭系统代理通常可以恢复；也可进入 Windows 代理设置确认手动代理已关闭。不要在问题未确认前删除所有网卡或重置整套网络协议，这会同时影响无线网络、虚拟化环境和企业配置。日志提示端口被占用时，应先退出重复实例，再用系统工具确认监听进程：

netstat -ano | findstr LISTENING

# 查看系统 DNS 缓存，排查前可记录现状
ipconfig /displaydns

四、macOS：芯片架构、网络权限与代理接管

按芯片选择 v2rayN 安装包

macOS 使用 v2rayN 时，第一步是选择正确架构。Apple Silicon 设备使用 arm64 安装包，Intel 设备使用 x64 安装包。系统“关于本机”中的芯片或处理器信息是判断依据。架构不匹配可能导致应用无法打开，或依赖兼容转换层才能运行，不应把这种启动问题误判为订阅故障。安装时将应用放入常规应用目录，避免长期从下载目录或磁盘映像中直接运行，因为配置写入、更新和权限记录都需要稳定路径。

第一次打开时，系统可能要求确认应用来源或网络权限。应通过系统设置中的隐私与安全页面处理当前应用提示，不要反复复制应用生成多个实例。若客户端界面可以打开但内核无法启动，先查看应用日志是否提示文件不可执行、权限不足或架构错误。只有内核启动并建立本地监听后，系统代理与 TUN 才有可用的目标入口。

订阅管理与节点验证

在 v2rayN 中建立独立订阅分组，填入完整地址后主动更新。macOS 上的订阅操作逻辑与 Windows 相同：保存订阅来源、执行更新、确认列表、选择活动节点、进行真连接验证。若剪贴板中包含前后空格或换行，应重新复制干净地址。订阅响应超时可能来自当前网络、DNS 或服务端状态；解析失败则更可能是格式不匹配。两类错误的处理方向不同，运行日志中的第一条明确错误通常比界面最终提示更有价值。

连接验证应先使用系统代理，而不是直接开启 TUN。系统代理会修改当前网络服务的代理配置，Safari 和多数遵循系统网络设置的应用会使用该入口。开启后可以在终端查看系统代理状态，确认 HTTP、HTTPS 或 SOCKS 条目是否指向本地地址：

scutil --proxy

# 查看系统当前默认路由
route -n get default

scutil --proxy 只说明系统配置已经写入，不代表节点连接一定成功。接下来仍需打开实际网页并观察客户端日志。如果系统代理显示启用，但应用请求没有出现在日志中，应检查该应用是否使用独立代理、是否启用了绕过规则，或是否复用了开启代理前建立的连接。关闭并重新打开应用可以排除连接复用干扰。

系统代理与不同网络服务

macOS 会为无线网络、有线网络和其他网络服务分别保存设置。用户切换网络后，代理状态可能需要重新应用。若 v2rayN 显示系统代理已开启，而新接入的网络仍然直连，可先关闭再开启一次系统代理，让客户端针对当前活动服务写入配置。公共网络存在认证页面时，应先关闭代理完成网络认证，再重新启用。否则认证跳转可能被送入代理，表现为所有页面都无法打开。

终端工具与图形应用之间也存在代理差异。部分命令读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 环境变量，部分工具忽略系统图形代理。只在当前终端会话内设置变量更容易恢复，关闭终端后不会持续影响其他任务。不要把固定端口写入全局 shell 配置，除非已经确认 v2rayN 的本地入口长期保持一致，并且知道客户端未启动时如何取消。

TUN 与网络扩展冲突

在 macOS 上启用 TUN 时，系统可能要求网络相关授权。完成授权后，应检查日志是否成功创建虚拟接口和写入路由。若连接按钮开启后网络完全中断，常见原因包括另一款网络工具仍在运行、系统中存在并行的过滤扩展、DNS 被多个程序同时修改，或者休眠恢复后旧接口未释放。先关闭其他接管工具并重新启动 v2rayN，再判断是否需要重启系统；不要直接删除不认识的系统网络服务。

TUN 的范围通常比系统代理广，也更容易影响局域网设备发现、打印服务和开发环境。启用后若互联网访问正常但局域网地址不可达，应检查路由规则是否保留私有地址直连，例如 geoip:private 或等价的局域网规则是否位于通用代理规则之前。规则顺序错误会把局域网请求送往远端出站，设备自然无法响应。对于需要访问本地服务的用户，保留局域网直连应作为启用 TUN 前的固定检查项。

应用无法退出或系统代理未恢复时，应先在 v2rayN 内执行关闭系统代理，再正常退出。若应用已经异常结束，可在系统网络设置中检查当前网络服务的代理项。恢复后重新启动客户端，以默认设置做一次连接验证。只有重复出现同一问题时，才需要结合日志判断是权限、接口还是应用生命周期问题。

五、Linux：软件包、桌面代理、环境变量与 TUN

选择 deb、rpm 与处理器架构

Linux 平台使用 v2rayN，需要同时确认架构和软件包体系。Debian、Ubuntu 及其衍生发行版通常使用 deb；Fedora、Rocky Linux 等通常使用 rpm。x64 设备选择对应的 x64 包，arm64 设备选择 arm64 包。包格式选错时，包管理器会直接拒绝；架构选错时，会出现无法执行或依赖无法满足。安装前可通过 uname -m 确认架构，并通过发行版自带包管理器安装，这样桌面菜单、依赖和卸载记录更容易保持一致。

# deb 软件包安装示例，文件名以实际下载结果为准
sudo apt install ./v2rayN-linux-x64.deb

# rpm 软件包安装示例，文件名以实际下载结果为准
sudo dnf install ./v2rayN-linux-x64.rpm

上面的命令仅展示本地软件包的安装方式，文件名应以下载中心实际取得的文件为准。若包管理器提示依赖问题，应先刷新当前发行版的软件源并处理系统依赖，不要从不明位置拼接共享库。图形应用启动后，配置目录需要当前用户可写。不要用 root 身份长期运行整个桌面客户端；只有创建 TUN 或修改路由时，才通过系统授权提升所需操作的权限。

订阅导入与桌面环境差异

订阅流程与其他桌面平台相同：创建分组、粘贴地址、保存、主动更新、选定活动节点。若应用无法从剪贴板读取内容，可在普通文本编辑器中确认地址完整后再粘贴。Wayland 与 X11 的剪贴板、托盘和窗口行为可能不同，但不会改变订阅格式。托盘图标未显示不代表内核没有运行，应以客户端主窗口和进程日志为准；部分桌面环境需要扩展才能显示传统托盘项目。

更新订阅后，应先确认服务器列表出现内容，再启动内核。日志若提示本地端口已占用，可使用 ss 查看监听情况。不要看到端口存在就直接结束系统进程，先确认是否有另一个 v2rayN 实例、遗留内核或其他代理程序占用相同端口。

ss -lntp

# 查看当前用户会话中的代理变量
env | grep -i proxy

# 查看默认路由
ip route show default

桌面系统代理与环境变量

Linux 没有一套覆盖所有桌面和命令行程序的统一代理设置。GNOME、KDE 等桌面环境可以保存图形代理，浏览器是否读取它还取决于浏览器设置；终端程序常通过环境变量或自身配置决定代理。v2rayN 写入系统代理后，应先用当前桌面中的浏览器验证，再单独检查终端工具。不要因为终端直连就判断系统代理完全失效，也不要因为浏览器可用就假定所有后台服务都会自动使用代理。

需要让某个终端会话使用本地 HTTP 入口时，可以临时设置环境变量；需要 SOCKS 时，应确认目标工具是否支持对应变量和解析方式。临时设置应使用 v2rayN 界面显示的实际监听地址与端口，下面使用回环地址和常见本地端口演示语法：

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、权限和 DNS

Linux TUN 依赖系统虚拟网络接口、路由和权限。启用前应确认系统支持 TUN 设备，并退出其他会修改默认路由的程序。v2rayN 请求提权时，只授权当前需要的网络操作。启用后通过 ip addr 和 ip route 可以观察接口及路由变化；若默认路由被错误替换，先在客户端内关闭 TUN，再重新检查。远程管理的设备尤其要谨慎，因为错误路由可能中断当前远程连接。

DNS 可能由 systemd-resolved、NetworkManager、桌面环境或手工文件共同管理。TUN 开启后网页域名无法解析，但直接访问已知地址仍有响应时，应优先检查 DNS 请求是否进入客户端、系统当前解析器指向哪里，以及其他网络工具是否覆盖配置。不要长期直接改写系统解析文件来掩盖问题，网络管理器可能在下一次连接时重新生成它。正确方案是明确由系统、客户端或本地解析服务中的哪一个负责 DNS，并避免多个组件争用相同监听端口。

Linux 上最稳定的排查方式是分层：先验证 v2rayN 图形界面和内核能运行，再验证浏览器系统代理，随后测试终端环境变量，最后才启用 TUN。每层都留下明确结果，出现问题时便能知道是桌面设置、应用配置、权限、路由还是 DNS。若日志出现重复的 timeout、rejected 或解析错误，可配合运行日志阅读指南定位具体环节。

六、Android：v2rayNG、v2flyNG 与应用分流

选择客户端与安装包

Android 首选 v2rayNG，它使用 Xray 内核路线，适合常见订阅和路由配置；需要 V2Fly 内核时，可使用 v2flyNG 作为备选。两款客户端都通过系统 VPN 接口接管流量，但内核支持范围、设置名称和配置存储并不保证完全一致。切换客户端时，应从原始订阅重新导入，不要复制另一款应用的数据目录。下载时，近年的主流设备优先选择 arm64 包；架构无法确认或 arm64 安装被系统拒绝时，再使用通用包。

安装完成后，第一次连接会由系统显示 VPN 授权提示。允许后，状态栏会出现系统管理的连接标识。该标识只说明虚拟接口已经建立，并不证明远端节点可用。真正的验证仍需结合客户端日志和实际网页请求。若设备中已有另一款占用系统 VPN 接口的工具，新客户端连接时通常会让原连接退出；两个应用不能同时控制同一个系统接口。

导入订阅、更新与选择节点

在 v2rayNG 或 v2flyNG 中打开订阅分组设置，添加完整订阅地址并命名，保存后执行更新。部分系统会对后台网络访问进行限制，若更新一直停留或立即失败，可先保持应用在前台，并确认当前网络本身能够访问订阅来源。更新成功后应看到配置列表，选择其中一个作为活动配置，再进行真连接测试。二维码适合导入单条配置，订阅更适合长期更新；两者用途不同，不应把单节点二维码当成可自动更新的订阅分组。

节点列表中显示的延迟仅用于辅助判断。移动网络在基站切换、弱信号和省电状态下波动明显，单次结果不能代表持续质量。选择节点后启动连接，打开一个新的浏览器页面，并立即回到日志查看是否产生实际请求。若日志只有接口启动信息而没有任何出站记录，说明应用流量可能未进入客户端；若出现 timeout、TLS 或认证错误，则流量已经进入，问题位于远端连接或配置参数。

系统 VPN 接口与应用分流

Android 客户端通常支持按应用决定是否经过代理。应用分流有两种常见思路：仅让选定应用进入，或让大多数应用进入并排除少数应用。规则越复杂，后续安装新应用时越容易遗漏。初次配置建议先关闭按应用分流，确认全局接管能够工作，再根据需求建立白名单或排除列表。遇到“浏览器可用、某个应用不可用”时，应首先检查该应用是否被排除，而不是修改服务器参数。

某些应用会直接使用 IP、使用特定 UDP 流量，或不遵循传统 HTTP 代理，因此 Android 客户端通过系统 VPN 接口接管比桌面系统代理更全面。与此同时，本地局域网、投屏、打印和设备发现也可能受到影响。需要访问同一网络中的设备时，应打开局域网绕过或建立私有地址直连规则。若应用分流和路由规则同时存在，数据先由系统决定是否进入客户端，进入后才由内核路由决定出站；被系统分流排除的应用不会再匹配内核规则。

后台限制、电量与网络切换

Android 的省电策略可能限制客户端后台运行。典型表现是锁屏一段时间后连接中断，重新点亮屏幕后恢复，或系统清理后台后状态标识消失。可在系统应用设置中允许必要的后台活动，并避免使用激进的自动清理策略。不同设备的设置入口名称不同，但判断标准一致：客户端在屏幕关闭后仍应保持系统 VPN 服务运行。无需给予与网络无关的权限。

从无线网络切换到移动网络时，已有连接可能失效，内核需要重新建立出站。若切换后长时间没有恢复，可在客户端中停止再启动一次，不必删除订阅。公共无线网络要求网页认证时，应先断开客户端连接，完成认证后再重新连接。若无线网络可用而移动网络失败，检查移动网络的 DNS、IPv6 和运营商接入差异；若所有节点都只在某一种网络失败，更可能是网络路径问题，而不是每条订阅同时失效。

启用“始终开启”一类系统选项前，应先确保客户端稳定，并理解系统的阻断策略。如果同时启用“未连接时阻止网络”，客户端异常退出或更新期间，其他应用也会无法联网。这一设置适合已经完成长期验证的配置，不适合作为首次安装的默认步骤。排查断网时，应检查系统 VPN 页面是否启用了此类限制，以免把系统主动阻断误认为节点故障。

v2rayNG 与 v2flyNG 的日志入口位置可能不同，但排错思路一致。关注首次失败前后的错误，而不是连续重试后大量重复信息。分享日志时删除订阅地址、用户标识、服务器地址等敏感内容，只保留错误类型、发生阶段和系统环境。若客户端显示已连接但网页仍无法访问，可继续阅读代理已连接但无法上网排查清单。

七、路由、DNS 与 TUN：从默认规则到可维护分流

路由规则的匹配顺序

路由决定已经进入客户端的请求应使用哪个出站。常见出站包括直连、代理和阻断。规则通常从上到下匹配，命中后不再继续，因此具体规则应放在通用规则之前。例如局域网和明确的直连域名应先处理，最后再用兜底规则把其余流量交给代理。若把“全部代理”放在最前面，后面的局域网直连永远不会生效；若把范围过大的直连规则放在前面，本应代理的请求也可能提前退出。

域名规则与 IP 规则解决不同阶段的问题。请求最初只有域名时，可以匹配 geosite 或明确域名；解析后得到 IP，则可匹配 geoip、私有地址或网段。一个连接可能同时具有域名和目标 IP，但客户端能获得的信息取决于入口协议、DNS 流程和应用行为。不要依赖单一规则覆盖所有情形，尤其是直接连接 IP 的应用不会触发域名规则。更完整的规则通常同时保留域名集合、IP 集合和最终兜底。

推荐的基础路由结构

基础配置可以从三层开始：局域网和私有地址直连；明确属于本地网络环境的站点与地址集合直连；其余请求代理。是否增加阻断规则，应根据实际需求单独维护，不要把大范围域名列表直接并入而不检查影响。下面的 JSON 片段展示 Xray 风格路由结构的核心关系，实际在图形客户端中可以通过路由设置界面建立等价规则：

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategy 控制域名规则未匹配时是否进一步解析 IP。IPIfNonMatch 表示先尝试域名匹配，未命中时再解析并尝试 IP 规则。它不是越激进越好：额外解析会增加 DNS 参与程度，而完全不解析又可能让 IP 规则无法匹配域名请求。图形客户端可能用“域名策略”下拉框呈现这一参数。调整前先明确需要解决的问题，不要只因为某个选项看起来更全面就切换。

DNS 请求为什么会影响连接

DNS 负责把域名转换为地址，它既可能由系统完成，也可能由客户端转发、接管或按规则分流。常见异常包括系统得到不可达地址、客户端与系统使用不同结果、TUN 接管后 DNS 请求没有进入预期监听、IPv4 与 IPv6 返回顺序不适合当前网络。表现上可能是域名打不开、直接使用地址有响应，或者某些站点可用而另一些持续超时。此时反复更换节点只能偶尔绕过症状，无法修正解析链路。

排查 DNS 时先回答三个问题：应用把查询交给谁，解析请求从哪个出站发送，最终返回了哪类地址。系统代理模式下，浏览器可能自行处理安全 DNS，也可能交给系统；TUN 模式下，客户端通常能接管更多查询。若浏览器启用了独立 DNS 设置，其结果可能绕开系统与客户端预期。应先使用默认浏览器网络设置验证，再决定是否加入自定义 DNS。多个解析方案同时开启会让日志和结果难以对应。

系统代理和 TUN 如何选择

比较项 系统代理 TUN
覆盖范围 主要覆盖遵循系统设置的应用 可覆盖更广的 TCP、UDP 流量
权限要求 通常较低 需要虚拟接口和路由权限
排错复杂度 入口清晰，便于分应用判断 涉及路由、DNS 和接口冲突
适用场景 浏览器、常规桌面软件 不读取代理设置或需要 UDP 的程序

应先使用系统代理完成基础连接，再决定是否需要 TUN。如果目标应用已经能通过系统代理工作，开启 TUN 不会自动提高节点质量，只会改变流量进入方式。确有应用不读取系统代理、需要 UDP 或希望统一管理时，再启用 TUN，并保留局域网直连。启用前记录当前系统代理、DNS 和其他虚拟网卡状态，异常时才能恢复。

修改规则的验证方法

每次只修改一组规则，并使用明确目标验证。例如新增局域网直连后，测试局域网设备与互联网各一次；修改 geosite 规则后，查看日志中的目标域名和最终出站；调整 DNS 后，分别测试新域名与已缓存域名。不要一次导入庞大规则、切换 DNS、开启 TUN并更换节点，因为成功或失败都无法说明是哪项改动造成。

路由规则名称应表达意图，例如“局域网直连”“常用本地域名直连”“其余代理”，而不是使用难以理解的临时编号。长期维护时，先写清规则目的，再记录匹配条件和出站。订阅更新通常只更新服务器配置，不应覆盖用户自定义路由；但不同客户端的导入方式可能影响当前选择，因此更新后如出现行为变化，应确认活动路由配置仍然正确。

八、配置常见问题与分层排查

先按数据路径定位故障层

有效排查不是从“重装客户端”开始，而是判断请求停在哪一层。第一层是订阅获取：能否更新、能否解析并生成节点；第二层是内核启动：配置能否加载、本地端口能否监听；第三层是远端连接：节点能否完成 DNS、TCP、TLS 与协议握手；第四层是应用接管：系统代理、环境变量或系统 VPN 接口是否让流量进入客户端；第五层是路由与 DNS：请求进入后是否选到正确出站、域名是否解析为可达地址。每层都有独立证据，应先找到最早失败点。

日志阅读时，重点看一次操作对应的时间段。先清空或记住当前位置，再执行一次订阅更新、连接或网页访问，然后阅读新产生的内容。后续连续重试会制造大量重复 timeout，掩盖最初的解析、权限或认证错误。常见关键词中，timeout 表示规定时间内未完成，原因可能是网络不可达、服务无响应或 DNS 缓慢；rejected 表示连接被规则、远端或协议条件拒绝；invalid user 通常与用户标识、认证信息或服务端配置不一致有关。具体判断可查阅运行日志怎么看。

订阅更新失败或更新后没有节点

先确认订阅地址完整，且没有复制到显示省略号的文本。删除地址前后的空格和换行，保留原始参数。随后在客户端内手动更新一次对应分组并查看日志。如果日志显示网络超时，检查当前网络和 DNS；如果返回内容无法解析，确认所选订阅格式适用于当前客户端；如果响应为空或权限被拒绝，需要在订阅来源一侧确认状态。不要连续新增相同订阅，这只会产生多个失败副本。

更新显示成功但列表为空时，检查当前界面是否筛选了分组、搜索词或配置类型；也要确认节点被导入到哪个分组。若从另一款客户端迁移，不要直接复制内部数据库，重新导入原始订阅更可靠。订阅更新后旧节点仍在，可能是客户端设置为保留旧配置；此时应先确认新内容是否生成，再决定是否清理，不要在没有备份来源信息时一次删除全部分组。

客户端启动但系统代理不生效

先打开客户端日志，然后从浏览器发起一个新请求。如果日志完全没有记录，问题位于应用到本地入口之间：系统代理没有写入、浏览器使用独立设置、应用未重新建立连接，或当前网络服务没有应用代理。如果日志出现请求但远端连接失败，说明系统代理已经生效，问题应转向节点、DNS或路由。用这种方法可以避免把代理接管问题和服务器问题混为一谈。

Windows 与 macOS 可进入系统网络设置确认代理状态；Linux 需要分别检查桌面代理与终端环境变量；Android 则检查系统 VPN 授权和应用分流。终端工具不随浏览器生效属于常见机制差异，应查看该工具支持的代理参数。客户端退出后无法上网时，检查是否留下系统代理或“未连接时阻止网络”设置。相关桌面排查流程可继续阅读浏览器与命令行终端分开排查。

显示已连接但网页打不开

“已连接”通常只表示内核或虚拟接口已经启动。首先切换到一个经过真连接验证的节点，确认设备时间和时区正确；其次观察网页请求是否进入日志；随后检查 DNS 是否报错、路由是否把请求送到预期出站；最后检查系统代理或 TUN 是否与其他网络工具冲突。如果所有节点都在同一设备、同一网络失败，而另一网络可用，应优先调查当前网络路径。若只有单个节点失败，则更可能是该配置或远端状态。

不要把 Ping 结果当成最终判断。服务器可能不响应普通探测，但代理协议仍能连接；反之，地址可以响应探测，也不代表认证和 TLS 握手成功。真连接测试与实际网页请求更接近使用路径。完整清单见v2rayN 与 v2rayNG 逐项排查清单，其中按节点、时间、DNS、路由和系统代理顺序整理了检查项。

TUN 开启后断网或局域网不可达

立即在客户端内关闭 TUN，确认基础网络能否恢复。如果仍未恢复，再检查系统代理、系统 VPN 阻断选项和残留虚拟接口。基础网络恢复后，只保留当前客户端，关闭其他修改路由或 DNS 的程序，再次启用 TUN并观察第一条错误。权限不足通常会在接口创建阶段失败；端口冲突发生在监听阶段；默认路由或 DNS 错误则常表现为接口建立后请求超时。

互联网可用但局域网不可达时，检查私有地址直连规则是否存在并位于兜底代理之前。常见私有地址和本地链路不应交给远端出站。Android 还要检查应用设置中的局域网绕过；桌面平台要确认防火墙没有把新虚拟接口归入不合适的网络范围。修改后分别测试局域网地址和普通域名，不能只验证其中一项。

端口占用、重复实例与配置回退

日志提示地址已被使用时，通常是另一个客户端实例、遗留内核进程或其他代理程序占用了同一端口。先从任务管理器、活动监视器或进程列表确认归属，再正常退出对应程序。随意更换端口虽然可能让当前实例启动，但系统代理、环境变量和应用内固定配置也必须同步修改，容易留下新的不一致。优先解决重复实例，再考虑调整端口。

如果问题发生在一次设置改动之后，最有效的方法是回退最近一项，而不是恢复所有配置。按相反顺序关闭 TUN、自定义 DNS、新增路由和应用分流，保留订阅与单一节点。基础连接恢复后逐项加回。若客户端配置已经难以判断，可记录订阅来源，创建一个新的最小配置进行对照；新配置可用说明旧偏好存在冲突，新配置也失败则继续检查平台权限、网络和订阅内容。

最终检查清单

  1. 安装包与当前平台、处理器架构和发行版格式一致。
  2. 订阅分组可主动更新，节点列表不是空白，也没有被筛选条件隐藏。
  3. 活动节点通过真连接验证，系统时间与时区正确。
  4. 内核成功启动，本地监听端口没有被重复实例占用。
  5. 浏览器或目标应用的请求能够出现在客户端日志中。
  6. 路由规则按具体到通用排列，局域网与私有地址保留直连。
  7. DNS 由明确的单一链路负责，没有多个工具同时覆盖。
  8. TUN 只在基础系统代理验证后启用，异常时能够关闭并恢复。

完成以上检查仍无法定位时，应把现象缩小到一个平台、一个客户端、一个订阅分组、一个节点和一种接管方式，再记录完整复现过程。先说明“在哪一步失败”，再说明“日志出现什么”，比只描述“无法连接”更容易得到有效判断。需要重新走一遍最短操作链时，返回快速上手教程；需要更换安装包或确认平台入口时，前往下载中心。