ALL-PLATFORM SETUP MANUAL

V2Ray 全平台安装配置大全

覆盖 Windows、macOS、Linux 与 Android,从客户端选择、订阅导入到系统代理、TUN、DNS 和故障定位。需要先完成一次连接,可以从快速上手教程开始;需要查参数、平台差异和排错分支,再回到这份完整文档。

适用客户端:v2rayN · v2rayNG · v2flyNG 最后更新:2026-08-19

TABLE OF CONTENTS

章节目录

01 / PREPARE

通用准备工作:先分清客户端、内核与订阅

客户端不是节点,也不是订阅服务

安装前先把三个名词拆开。v2rayN、v2rayNG 和 v2flyNG 是图形客户端,负责保存配置、调用内核、设置系统代理以及显示运行日志。V2Fly、Xray 属于内核家族,真正处理入站、出站、路由、DNS 和传输协议。订阅链接则是一份由服务端维护的节点清单,客户端读取链接后,把清单转换成可以选择的服务器配置。只安装客户端不会自动出现可连接节点;只有订阅链接但没有兼容客户端,也不能直接让系统流量通过对应配置。

桌面平台统一优先选择 v2rayN。它在 Windows 上提供桌面版与经典 WPF 版,在 macOS 和 Linux 上提供对应安装包,菜单位置会因界面版本略有差异,但核心概念相同:订阅分组保存链接,服务器列表保存节点,系统代理负责浏览器等遵循系统设置的程序,TUN 则通过虚拟网络接口接管更广的流量。Android 优先选择搭载 Xray 内核的 v2rayNG;需要使用 V2Fly 内核家族时,再考虑 v2flyNG。具体安装包应从本站客户端页面按平台选择。

安装前记录四项基础信息

准备配置时,至少确认订阅链接是否完整、设备时间是否自动同步、当前网络是否允许正常访问常用网站,以及系统架构。订阅链接通常是一段以 HTTP 或 HTTPS 开头的地址,复制时不能夹带空格、换行或聊天软件生成的尾部标点。系统时间误差会影响 TLS 握手和证书判断,表现常常是节点看似存在、连接却立即失败。先开启系统的自动设置时间与时区,再继续处理客户端问题,比反复切换节点更有效。

系统架构决定安装包。Windows 常见设备使用 x64;macOS 需要在 Apple Silicon 与 Intel 包之间选择;Android 主流设备通常使用 arm64,无法确认架构时可以使用通用包;Linux 除架构外还要确认发行版的软件包体系,Debian、Ubuntu 及其派生系统通常使用 deb,Fedora、RHEL 系及相关发行版通常使用 rpm。包格式选错通常不会损坏系统,但安装器会直接拒绝,或者提示架构不匹配。

平台 优先客户端 安装前确认 第一次连接方式
Windows v2rayN x64、桌面版或 WPF 版 系统代理
macOS v2rayN Apple Silicon 或 Intel 系统代理
Linux v2rayN deb 或 rpm、x64 或 arm64 应用代理或系统代理
Android v2rayNG arm64 或通用包 系统连接授权

建立可回退的最小配置

第一次运行不要同时修改路由、DNS、传输层参数和 TUN。最小配置只有四步:导入订阅、更新订阅、选择一个节点、开启系统代理或移动端连接。随后用浏览器访问一个原本就稳定的网站,并观察客户端日志。连接成功后再增加分流和 DNS;每次只改一类设置,出现异常就能知道是哪一步引入的。很多“突然全部不能用”的问题,并不是节点同时失效,而是多个高级选项一起调整后失去了可追踪性。

建议给初始订阅分组取一个容易识别的名称,并保留默认路由设置。更新前不要手动改订阅生成的节点字段,因为下次更新通常会覆盖这些修改。如果确实需要针对单个节点调整传输参数,应复制成独立配置,或者先确认订阅提供方是否支持在服务端修改。订阅链接本身属于敏感配置,不应贴进公开截图、日志或求助内容。需要排错时,保留错误类型、时间点和客户端状态即可,域名、用户标识与节点地址应做必要遮盖。

最后准备一个回退路径:记住系统代理开关所在位置,并确认关闭客户端后如何恢复系统网络。桌面端如果使用系统代理,退出客户端前先清除系统代理;使用 TUN 时先关闭 TUN,再退出程序。Android 端断开连接即可释放系统连接。完成这些准备后,各平台安装过程只是界面与权限模型不同,订阅、节点、路由和 DNS 的底层逻辑是一致的。

02 / WINDOWS

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

桌面版与经典 WPF 版怎么选

Windows 平台首推 v2rayN。下载页提供桌面版与经典 WPF 版两个入口。桌面版采用新一代跨平台界面,适合新安装和同时使用多个桌面系统的人;经典 WPF 版是 Windows 原生界面路线,菜单密度更高,适合已经熟悉旧版操作逻辑的用户。两者都能完成订阅管理、节点选择、系统代理、路由和 TUN 配置,不需要同时安装。拿不准时先用桌面版,只有在界面兼容、旧配置迁移或操作习惯上有明确需求时再选 WPF 版。

下载完整安装包后,按安装器提示完成安装。若系统弹出用户账户控制窗口,应先核对程序名称与当前操作是否对应,再允许继续。安装路径尽量使用当前用户可写目录,不要把程序数据目录放进会被自动清理的位置。首次启动后,v2rayN 通常会建立配置目录并准备内核组件。防火墙提示出现时,只允许当前确实需要的网络范围;普通单机使用不需要为了“防止连接失败”而开放无关的入站访问。

导入订阅并选择活动节点

进入订阅分组管理,新增一个分组名称,将完整订阅地址粘贴到 URL 输入框并保存。接着执行更新订阅。更新成功后,主列表会出现服务器条目;如果只保存链接而没有执行更新,列表保持空白是正常现象。选中一个节点并设为活动服务器,状态栏或列表标记会显示当前选择。节点名称只是订阅中的描述,不等于连接质量,第一次测试不必连续批量测速,先选一个配置完整的条目验证基本连通性。

更新失败时先检查链接首尾是否多了空格,浏览器能否打开订阅地址,以及分组是否启用。订阅内容可能是 Base64 文本、分享链接集合或结构化配置,客户端会根据内容判断格式。不要手工把整段订阅内容粘进单节点编辑器,也不要把单条 VMess 或 VLESS 分享链接误填进订阅 URL。单条分享链接应从剪贴板导入服务器,订阅 URL 则放入订阅分组,两类入口用途不同。

先开系统代理,再判断是否需要 TUN

选择节点后启动服务,并把系统代理模式设为自动配置系统代理或清晰标注为启用的模式。此时遵循 Windows 系统代理的浏览器和桌面应用会把流量交给 v2rayN。本地监听端口由客户端管理,通常不需要手工填写。若某个程序提供自己的代理设置,可以选择“使用系统代理”;只有它不读取系统设置时,才需要查看 v2rayN 当前的本地 HTTP 或 SOCKS 端口并单独填写。

系统代理适合先验证配置,因为链路短、权限少,也容易关闭。游戏、部分命令行程序、商店应用或自行实现网络栈的软件可能绕过系统代理,此时才考虑 TUN。开启 TUN 往往需要管理员权限,并会创建虚拟网络适配器。第一次启用后要重新测试 DNS、局域网访问与休眠唤醒,不要只看浏览器是否打开网页。若开启后全局断网,先关闭 TUN,确认系统代理仍可工作,再检查驱动、路由和 DNS,而不是继续叠加更多开关。

Windows 常见的残留代理与权限问题

最常见的退出后断网,是系统代理仍指向已经关闭的本地端口。处理方法是重新打开 v2rayN,执行清除系统代理,再正常退出;也可以进入 Windows 的网络与 Internet 设置,检查手动代理和设置脚本是否残留。不要一上来重置整个网络堆栈,因为那会同时影响其他网络软件和已保存设置。先确认代理地址是否指向回环地址、对应端口是否仍在监听,问题通常就能定位。

若客户端无法写入配置、更新后设置消失或日志提示访问被拒绝,重点检查安装目录与安全软件的受控文件夹策略。日常运行不建议长期强制管理员模式;需要管理员权限的功能应在操作时按提示授权。若只有 TUN 失败而系统代理正常,说明订阅、节点和内核基本可用,排查范围应收缩到虚拟适配器、路由冲突和权限。若系统代理也失败,则回到节点、时间、订阅字段与内核日志。

命令行程序可以先检查是否继承了旧代理环境变量。下面的 PowerShell 命令只读取当前环境,不修改配置。若输出了已经失效的地址,应在对应终端配置或系统环境变量中清理,而不是反复更换客户端节点。

Get-ChildItem Env:HTTP_PROXY
Get-ChildItem Env:HTTPS_PROXY
Get-ChildItem Env:ALL_PROXY

Windows 休眠或切换网络后,虚拟适配器和旧路由可能没有立即刷新。先断开客户端连接,等待网络图标恢复,再重新启动服务。如果频繁发生,可优先使用系统代理完成日常浏览,只在确实需要接管更多程序时开启 TUN。更详细的第一遍操作顺序可参考入门指南,本章则用于选择版本和定位 Windows 特有问题。

03 / MACOS

macOS:芯片选择、权限与代理配置

先确认 Apple Silicon 或 Intel

macOS 使用 v2rayN 时,第一步不是看系统名称,而是确认处理器架构。打开系统信息或“关于本机”,看到 Apple 系列芯片时选择 Apple Silicon 对应的 arm64 安装包;看到 Intel 处理器时选择 x64 安装包。架构选错时,系统可能拒绝打开,也可能需要额外转换层,既增加变量又不利于排错。下载页已经按芯片分开入口,确认后再安装即可。

安装通常是打开 dmg,再把应用移入 Applications。第一次运行遇到系统安全确认,应通过系统设置中的隐私与安全页面查看被拦截原因,并在确认来源与当前下载操作一致后允许打开。不要为了一个应用长期降低整机安全策略。v2rayN 需要修改系统代理或创建网络扩展时,系统会单独请求权限;这些权限与普通文件访问不同,应在功能实际启用时按提示授予。

订阅导入和节点选择

进入订阅设置,新建分组,粘贴订阅链接并保存,然后执行更新。macOS 版界面布局可能与 Windows 版不同,但仍然围绕订阅分组、服务器列表、当前活动节点和代理模式四部分展开。更新后如果出现节点列表,先选定一个节点,再启动服务。不要把“订阅已更新”理解成“流量已经接管”,订阅更新只完成配置同步,系统是否通过客户端连接还取决于代理开关。

若从聊天工具复制链接,尤其要注意换行和文本替换。可以先粘贴到纯文本编辑器,确认链接只有一行,再放进客户端。订阅地址含有查询参数时,末尾部分同样不能截断。更新时出现证书或握手错误,应先确认系统时间、当前网络和订阅地址本身;如果只有某个节点失败而其他节点正常,则排查该节点字段,不要删除整个订阅分组。

系统代理与应用代理的边界

启用系统代理后,Safari、遵循系统网络设置的浏览器以及大量桌面软件会使用 v2rayN 提供的本地代理。终端命令和部分开发工具不一定自动读取系统代理,这取决于工具自身。不要因为终端请求未变化就判断整个客户端失效,应同时用遵循系统代理的浏览器验证。如果某个命令行工具明确支持 HTTP 或 SOCKS 代理,可以在该工具自己的配置中填入客户端显示的本地地址和端口。

关闭客户端前应先清除系统代理。若应用已经退出但网页全部无法打开,进入系统设置的网络详情,检查 HTTP 代理、HTTPS 代理和自动代理配置是否仍启用。残留地址常常指向 127.0.0.1 的某个端口,而此时本地已经没有进程监听。关闭对应项目后网络会恢复。这里不需要删除 Wi-Fi、忘记网络或清空 DNS,先处理最直接的代理残留即可。

TUN、网络扩展与局域网访问

macOS 上的 TUN 会涉及网络扩展或虚拟接口权限。系统首次询问时允许后,可能需要重新启用功能才能生效。开启前先确认系统代理模式连接稳定,因为 TUN 失败时最有价值的对照组就是“同一节点在系统代理下是否可用”。如果系统代理正常、TUN 打开后断网,优先检查 DNS 接管、默认路由和其他网络扩展冲突。多个接管全局流量的软件同时工作时,路由优先级和 DNS 设置可能互相覆盖。

需要访问打印机、文件共享或路由器管理页时,应让局域网地址保持直连。常见私有地址段包括 10.0.0.0/8、172.16.0.0/12 与 192.168.0.0/16,回环地址和本地链路地址也不应交给远端节点。使用默认分流配置时通常已经包含这些规则,但自定义路由后要重新核对。若只有局域网设备不可达,先不要改节点协议,而应检查路由规则是否把私有地址错误送入代理出站。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

切换 Wi-Fi、热点和有线网络后,旧的系统代理仍可能保留,但本地端口会随着客户端重启恢复。正确顺序是先断开连接,完成网络切换,确认基础网络可用,再重新连接。若网络切换后订阅能更新但网页不能打开,应查看当前活动节点、代理模式和 DNS;若订阅也无法更新,则先排除新网络自身的认证页面与连通性。

macOS 平台的核心不是增加特殊配置,而是尊重系统权限和网络扩展边界。系统代理能覆盖需求时就保持简单;需要接管更多应用再开 TUN;需要局域网服务时明确保留私有地址直连。每次网络扩展变化后都重新验证浏览器、终端和局域网三个方向,能比只测一个网页更快发现边界问题。

04 / LINUX

Linux:软件包、桌面代理与 TUN 权限

deb、rpm 与架构选择

Linux 桌面端使用 v2rayN。下载前先确认发行版的软件包体系和 CPU 架构。Debian、Ubuntu、Linux Mint 等通常选 deb;Fedora、RHEL 系及使用 rpm 包管理的发行版选择 rpm。x86_64 设备使用 x64 包,arm64 设备使用对应的 arm64 包。可以在终端执行 uname -m 查看架构:常见输出 x86_64 对应 x64,aarch64 对应 arm64。

uname -m
cat /etc/os-release

安装本地 deb 包时,优先让 apt 处理依赖;安装 rpm 包时使用发行版当前的包管理命令。下面命令中的文件名应替换为实际下载到当前目录的文件名,不要照搬一个不存在的名称。图形软件中心也可以完成安装,但出现依赖错误时,终端输出更便于定位。

sudo apt install ./v2rayN-linux-x64.deb

sudo dnf install ./v2rayN-linux-x64.rpm

如果安装器报告架构不匹配,应重新选择安装包,而不是强制忽略检查。若提示缺少桌面运行库,先确认发行版版本仍处于维护周期,并通过系统软件源安装依赖。不要从不相关来源混装库文件。应用能够启动后,先检查窗口、托盘图标和配置目录是否属于当前用户;长期使用 root 启动图形客户端会让配置文件所有者混乱,之后普通用户可能无法保存设置。

导入订阅并理解桌面环境差异

v2rayN 的订阅流程与其他桌面平台一致:新建分组、粘贴链接、保存、更新、选择活动节点。差异主要来自 Linux 桌面环境。GNOME、KDE 以及其他桌面对于系统代理的设置入口和应用继承方式并不完全相同。浏览器通常能读取桌面代理,终端程序、容器、后台服务则往往不会。首次验证时应先用桌面浏览器,确认内核和节点正常后,再单独配置命令行工具。

某些精简桌面环境没有统一系统代理接口,此时 v2rayN 的“设置系统代理”可能无法覆盖全部应用。可以查看客户端当前监听的 HTTP 与 SOCKS 端口,把地址填入目标应用自己的代理设置。只在当前终端临时测试时,也可以设置环境变量;测试结束后关闭终端即可回退,避免把失效端口长期写入 shell 配置。

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=socks5://127.0.0.1:10808

示例端口用于说明格式,实际值必须以客户端界面显示为准。如果 v2rayN 修改过本地端口,环境变量也要同步。大小写变量可能被不同工具分别读取,排错时可执行 env | grep -i proxy 查看当前会话。命令行可用而浏览器不可用,通常是桌面代理未设置;浏览器可用而命令行不可用,通常是工具没有继承系统代理,这两种情况不应混为一谈。

TUN 所需的权限与路由检查

Linux 上开启 TUN 需要访问 /dev/net/tun、创建虚拟接口并修改路由。v2rayN 可能通过权限提升机制完成这些操作。若界面提示 TUN 启动失败,先确认内核模块和设备节点存在,再查看日志中的权限错误。不要直接把整个应用永久以 root 身份运行;正确方向是让需要网络管理权限的组件获得有限授权,同时让用户配置继续归普通账户所有。

ls -l /dev/net/tun
ip address
ip route

开启 TUN 前后分别记录默认路由和 DNS 状态。若开启后完全断网,关闭 TUN 后检查默认路由是否恢复;若只有域名打不开但直接访问已知地址有响应,问题集中在 DNS;若局域网设备不可访问,则检查私有地址是否被错误送入 TUN。NetworkManager、systemd-resolved 与桌面环境的 DNS 管理可能同时存在,配置时应确认最终生效层,不要在三个位置反复写不同服务器。

休眠、托盘与后台进程

部分桌面环境关闭窗口只是隐藏到托盘,另一些环境没有托盘扩展,关闭窗口会结束程序。第一次使用时应确认 v2rayN 的退出行为,避免误以为客户端已经关闭而系统代理仍然保留。可以用进程列表和端口监听判断内核是否仍在运行。系统代理指向本地端口但进程已结束时,浏览器会表现为所有页面连接失败。

休眠恢复后,网络接口名称、默认路由和 DNS 可能重新生成。系统代理模式通常只需重连;TUN 模式则可能需要关闭后重新开启。若恢复后日志仍显示旧接口,先让系统网络稳定,再重启客户端。容器和虚拟机拥有独立网络命名空间,宿主机系统代理不会自动覆盖其中流量。需要让容器使用代理时,应明确配置容器的代理地址,并确认它能访问宿主机监听端口。

Linux 排错最重要的是区分“客户端内核是否工作”“桌面应用是否读取代理”“系统路由是否被 TUN 接管”三个层次。不要用一个命令的结果代替全部判断。浏览器、带代理环境变量的终端请求和 ip route 分别对应三个层次。只要逐层验证,就能避免把桌面环境差异误判为节点故障。

05 / ANDROID

Android:v2rayNG、v2flyNG 与连接授权

客户端与安装包选择

Android 首推 v2rayNG,它使用 Xray 内核,适合大多数订阅和常见协议配置。v2flyNG 使用 V2Fly 内核,可作为内核家族不同的备选。两款客户端都提供 arm64 与通用安装包。2015 年后的主流手机通常可以先选 arm64,设备架构不明确、安装时提示不兼容或需要覆盖更广设备时再选通用包。不要同时让两款客户端保持连接,因为系统同一时间只会将网络交给一个此类连接。

打开安装包时,系统可能要求允许当前浏览器或文件管理器安装应用。这个权限应只授予实际执行安装的应用,安装结束后可以在系统设置中关闭。若系统提示无法安装,先检查是否下载完整、架构是否匹配,以及设备上是否存在签名来源不同的同名应用。直接覆盖失败时,应先备份客户端内的重要配置,再决定是否卸载旧应用,避免订阅和手工节点一起丢失。

导入订阅、剪贴板链接与扫码

打开 v2rayNG 后,可以进入订阅设置新增订阅地址,保存后返回主界面执行更新订阅。更新成功会生成节点列表,点选其中一项使其成为当前配置。单条分享链接则使用“从剪贴板导入”一类入口;二维码适合导入单条节点或客户端支持识别的配置内容。订阅二维码与单节点二维码外观相同,最终应根据扫描结果进入订阅管理还是节点列表来判断。

如果扫码没有反应,先确认相机权限、二维码是否完整显示以及屏幕反光。没有必要把敏感二维码上传到在线识别工具。复制链接时同样要防止文本截断。订阅更新后节点为空,应检查分组是否启用、订阅内容格式是否受当前内核支持,以及链接是否返回了登录页面或错误页面。详细的订阅入口差异可以参阅订阅链接导入步骤

第一次连接与分应用代理

选中节点后点击连接按钮,系统会弹出网络连接授权。允许后,状态栏出现连接标记,客户端日志开始记录连接过程。第一次测试先保持默认路由,不开启复杂分应用规则。打开浏览器验证连接,再检查其他应用。Android 上不需要像桌面系统那样额外切换“系统代理”,授权连接后,系统会将符合规则的应用流量交给客户端。

分应用代理用于决定哪些应用进入客户端。通常有两种思路:只代理选中的应用,或者绕过选中的应用。配置前先读清模式名称,避免逻辑反转。系统组件、浏览器内核和应用主程序可能是不同包,某个应用仍不符合预期时,要确认它是否调用了外部浏览器或系统下载器。第一次配置不建议启用分应用代理;全局连接验证成功后,再逐个加入或排除应用,问题更容易定位。

后台限制、电池优化与网络切换

连接一段时间后自动中断,常见原因是系统对后台应用的电池限制。可在应用信息中允许 v2rayNG 或 v2flyNG 后台运行,并根据设备系统提供的选项关闭针对该客户端的严格电池优化。只调整当前客户端,不需要把所有应用都设为无限制。若任务清理工具会强制结束后台进程,也要将客户端从对应清理规则中排除。

Wi-Fi 与移动网络切换时,现有连接可能短暂失效。先等待系统网络获得地址,再观察客户端是否自动恢复;没有恢复时手动断开并重新连接。若 Wi-Fi 需要网页认证,应先断开客户端完成认证,再重新连接。只有某个 Wi-Fi 失败而移动网络正常,说明客户端配置大概率可用,应排查该网络的 DNS、认证页面或 IPv6 路径,而不是重装应用。

DNS、IPv6 与局域网访问

Android 上出现“应用显示已连接,但域名打不开”,应优先检查 DNS。客户端内置 DNS、系统私人 DNS和节点远端解析可能共同影响结果。第一次排错可以暂时保持客户端默认 DNS,并确认系统私人 DNS没有指向当前网络不可达的服务器。若只有个别域名解析异常,再配置分流 DNS,而不是直接切换所有查询路径。

IPv6 可用性取决于当前移动网络、Wi-Fi 和节点配置。如果日志显示请求选择了 IPv6 地址但连接超时,可以先在客户端 DNS 策略中优先返回与当前链路匹配的地址族,或检查节点是否支持对应出口。不要把所有超时都归因于 IPv6;先看日志中的目标地址和错误阶段。局域网设备不可达时,检查是否允许绕过私有地址,并确认分应用规则没有把文件管理器或投屏组件送到不合适的出站。

v2rayNG 与 v2flyNG 的菜单名称会因界面更新而变化,但操作主线稳定:导入配置、选择节点、允许系统连接、观察日志。只要先用默认设置完成这条主线,再处理分应用、DNS 和后台限制,绝大多数 Android 问题都能被拆成单一变量。更换两款客户端时也应使用同一条节点做对照,才能判断差异来自内核兼容还是节点本身。

06 / SUBSCRIPTION

订阅与节点管理:更新、覆盖和兼容性

订阅更新实际做了什么

订阅更新不是测速,也不是重新安装内核。客户端向订阅地址发起请求,读取返回内容,解析节点字段,再更新对应分组中的服务器列表。节点名称、地址、端口、用户标识、传输方式和 TLS 参数通常都来自订阅。更新完成后,当前活动节点可能继续保持,也可能因原条目被移除而需要重新选择。遇到“更新成功但连接没变化”,先看当前活动节点是否仍是旧条目。

订阅分组便于隔离不同来源的配置。多个订阅不要全部塞进一个难以辨认的名称,建议按用途建立分组。更新某个分组前,可以先记住当前活动服务器。若新列表异常,切回其他已验证分组即可继续排查。客户端中的订阅链接应视为敏感信息,因为链接本身可能包含访问标识;截图时不要让地址栏、二维码或完整节点字段出现在画面中。

自动更新与手动更新的边界

手动更新适合首次导入、配置变更后立即同步以及排错。自动更新适合长期维护,但不应设置过于频繁。订阅内容没有变化时,反复请求不会改善节点连接。自动更新失败也不一定影响已经保存的旧节点,客户端通常仍能使用本地列表。此时要分别判断“订阅地址不可访问”和“现有节点不可连接”,两者不是同一故障。

若订阅返回空内容、网页文本或认证页面,客户端可能提示格式错误。可以在不公开链接的前提下,用本机浏览器检查请求结果是否符合预期。浏览器能打开但客户端失败时,再看系统代理是否造成订阅更新绕路、证书是否被本地网络替换,以及客户端是否支持返回格式。更新订阅时使用代理还是直连,应根据订阅地址的可达性决定;不要把一个固定模式当成所有网络都适用的答案。

手工修改为什么会被覆盖

订阅节点由远端清单生成,下次更新通常会重新写入字段。手工改节点名称、端口或传输参数后,更新可能覆盖修改,这是订阅管理的正常行为。需要保留定制项时,可以复制节点为独立服务器,不让它归属于自动更新分组;或者在订阅提供的管理界面完成修改,再重新同步。直接修改生成结果适合临时测试,不适合作为长期维护方式。

路由和 DNS 通常属于客户端级配置,不一定随节点更新覆盖。应把“服务器字段”和“本地策略”分开管理:服务器字段决定如何连接远端,路由决定流量走哪个出站,DNS 决定域名如何解析。节点更新后所有网站行为突然改变时,先看活动节点和服务器字段;只有部分域名走向不符时,再看路由与 DNS。

协议字段与内核兼容

常见订阅可能包含 VMess、VLESS、Trojan 等节点。协议名称只是第一层,真正决定能否连接的还有传输方式、TLS、安全参数、服务器名称和路径等字段。不能因为客户端识别出节点名称,就认为全部字段都完整。日志中的“未知字段”“不支持的传输方式”或配置解析失败,通常说明订阅生成格式与当前内核能力不匹配。

Android 上可以用 v2rayNG 与 v2flyNG 做内核家族对照,但对照时应保持同一节点、同一网络和尽量一致的路由设置。某条配置只在其中一个内核工作,不代表另一客户端整体故障,可能是特定字段的实现或支持范围不同。桌面端 v2rayN 也要确认当前选择的内核与节点要求匹配。不要凭节点名称猜协议,打开配置详情查看实际字段更可靠。

订阅异常的分层检查

第一层检查链接:是否完整、是否过期、是否混入空格。第二层检查请求:当前网络能否访问、返回的是否为订阅正文。第三层检查解析:客户端是否识别格式、日志是否报告字段错误。第四层检查连接:节点能否完成域名解析、TCP 建连和 TLS 握手。按层处理比不断删除重加订阅更快,也能保留可用配置。

如果订阅里几十个节点同时失败,应优先怀疑共同条件,例如设备时间、DNS、网络、订阅字段整体变化或内核配置。只有一个节点失败,则检查该节点地址、端口和传输参数。节点能连接但特定网站失败,则进入路由和 DNS 层。这个判断树能避免把所有问题都归结为“订阅失效”。

订阅管理的目标不是让列表越长越好,而是让配置来源、更新时间和当前活动节点都可追踪。保持分组清晰,保留一个已验证节点作为对照,修改高级参数前记录原值。这样即使订阅内容发生变化,也能快速判断是远端清单、客户端解析还是本地网络出了问题。

07 / PROXY AND TUN

系统代理、TUN、路由与 DNS 的关系

系统代理只接管愿意读取它的程序

系统代理本质上是把一个本地 HTTP 或 SOCKS 入口告诉操作系统和应用。浏览器、部分桌面软件会读取这项设置,再把请求交给 v2rayN。它不会强制拦截每一个数据包,因此某些游戏、命令行工具、后台服务和自行实现网络栈的程序可能绕过。系统代理的优势是权限要求低、路径清楚、关闭容易,最适合作为第一次连接和日常浏览的默认方案。

客户端本地通常会监听回环地址,例如 127.0.0.1 上的 HTTP 与 SOCKS 端口。回环地址只允许本机访问,符合单机使用场景。若开启允许局域网连接,就要明确监听范围和防火墙规则,不要为了连接本机应用而把端口开放到所有网卡。应用手工配置代理时,协议类型和端口必须对应;把 SOCKS 端口填进 HTTP 代理栏会产生看似连接被拒绝或协议握手失败的结果。

TUN 为什么能接管更多应用

TUN 创建虚拟网络接口,把系统路由指向该接口,再由客户端判断每个连接应走代理还是直连。应用不需要理解代理协议,所以覆盖范围比系统代理更广。代价是需要更高权限,并且会与系统路由、DNS、其他虚拟网络软件产生交互。TUN 不是“更快模式”,也不会修复错误节点;它解决的是应用不读取系统代理的问题。

启用顺序应是:先确认同一节点在系统代理下可用,记录当前 DNS 与局域网状态,关闭其他会接管默认路由的软件,再开启 TUN。验证时至少测试普通域名、局域网地址和一个原本绕过系统代理的程序。若浏览器可用但局域网失效,应检查私有地址直连;若全部域名失败,查看 DNS;若只有某个程序失败,查看它是否使用特殊协议或独立网络环境。

模式 接管范围 权限要求 适用阶段
系统代理 遵循系统代理的应用 较低 首次验证、浏览器与常规桌面应用
应用内代理 单个应用 较低 命令行工具和独立代理设置
TUN 经系统路由进入虚拟接口的流量 较高 需要接管更多应用时

路由规则按顺序匹配

路由规则决定流量交给哪个出站。通常先写明确的私有地址直连,再写需要代理的域名或地址,最后设置兜底行为。规则顺序很重要:流量命中前面的规则后,后续规则通常不再参与。一个过宽的域名规则放在顶部,可能让后面的直连规则永远没有机会生效。排查分流时,应查看实际目标域名、解析后的 IP、命中的规则和最终出站标签。

domainStrategy 决定路由阶段如何使用域名和解析结果。AsIs 优先按原始域名匹配,适合域名规则明确的配置;其他策略可能在需要时解析地址,再参与 IP 规则。不要在不了解行为时同时修改路由策略和 DNS。先保持默认值验证,再根据“域名规则未命中”或“需要按目标 IP 分流”的具体需求调整。

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

DNS 泄漏、远程解析与分流 DNS

DNS 负责把域名转换成地址,它与连接流量可以走不同路径。如果域名在本地解析、连接却走代理,解析结果可能受到当前网络影响;如果所有查询都送到远端,又可能让本地域名和局域网服务解析不正确。合理做法是根据域名类别决定解析路径,并让路由和 DNS 的判断保持一致。相关实操可查看DNS 泄漏检测与配置步骤

出现 DNS 问题时,先区分解析失败与连接失败。日志若明确显示找不到域名或 DNS 查询超时,才进入 DNS 层;已经解析出地址但 TCP 连接超时,则要看节点、路由或目标网络。浏览器还可能启用自己的安全 DNS,绕过系统设置。对照测试时可暂时让浏览器遵循系统 DNS,避免客户端、系统和浏览器三套解析同时变化。

所谓防泄漏配置,不是简单填一个服务器地址,而是确保应用查询、系统查询和 TUN 接管之间没有意外旁路。验证时应在系统代理与 TUN 两种模式下分别观察,因为系统代理通常不强制接管全部系统 DNS,而 TUN 可以更集中地处理查询。修改后还要清理旧缓存或等待缓存过期,否则会把历史结果误当成新配置效果。

推荐的渐进配置顺序

第一阶段只用默认路由和系统代理,验证订阅与节点。第二阶段加入私有地址直连和必要域名规则,确认每条规则的命中。第三阶段配置 DNS,让解析路径与分流一致。第四阶段才开启 TUN,测试更多应用、局域网和休眠恢复。每完成一阶段都保留可回退配置。这个顺序看起来比一次打开全部功能慢,实际能省掉大量无方向的试错。

系统代理、TUN、路由和 DNS 是四个相互连接但职责不同的层次。系统代理决定应用是否把请求交给客户端;TUN 决定系统数据包是否进入虚拟接口;路由决定进入客户端后的出站;DNS 决定域名如何得到地址。按职责定位问题,比记菜单位置更持久,也适用于不同平台和后续界面变化。

08 / DIAGNOSIS

配置常见问题:按日志阶段逐层排查

先判断故障发生在哪一层

完整连接链路可以拆成六层:本地应用是否进入客户端、域名是否解析、客户端是否连接节点地址、传输层是否建立、TLS 等安全层是否完成、目标请求是否按路由出站。日志中的错误位置比“网页打不开”更有信息量。排错时记录时间点,重新发起一次请求,再查看这个时间附近的日志,避免被早先错误和后台重试淹没。

如果日志完全没有新连接,说明应用可能绕过系统代理、分应用规则排除了它,或 TUN 没有接管对应路由。日志出现 DNS 超时,检查解析服务器和查询路径。节点地址连接超时,检查当前网络、地址可达性和端口。TLS 握手失败时,检查系统时间、服务器名称与安全参数。连接建立后目标返回错误,则继续看路由和目标服务,不要立刻重装客户端。

订阅能更新,但所有节点都不能连接

这说明客户端至少能访问订阅地址,但不能证明节点链路正常。先确认设备时间与时区自动同步,然后选择一个节点,清空旧日志并重新连接。若所有节点报相同的 DNS 错误,检查系统和客户端 DNS;若都在连接节点地址时超时,检查当前网络和路由;若都在配置解析阶段失败,订阅格式或内核兼容性更值得关注。

不要连续切换几十个节点并只看界面颜色。每次切换后保留一段完整日志,比较错误阶段是否一致。相同阶段说明有共同条件,错误阶段不同才可能是节点个体差异。还可以用系统代理模式与 TUN 模式做对照:系统代理正常而 TUN 失败,范围在权限、路由和 DNS 接管;两者都失败,范围更靠近节点、订阅或内核。

显示已连接,但网页打不开

“已连接”通常只表示客户端进程或系统连接状态已经建立,不代表每个目标请求都成功。先检查浏览器是否读取系统代理,或者移动端目标应用是否包含在分应用规则中。随后看日志有没有对应域名请求。没有请求就处理接管层;有 DNS 查询但无结果就处理 DNS;已经得到地址却连接失败,再看路由和节点。

桌面端还要检查系统代理地址是否对应当前 v2rayN 的本地端口。升级、迁移配置或手工调整后,系统可能仍指向旧端口。浏览器自身的代理扩展也可能覆盖系统设置,排错时应暂时只保留一条代理链路。若只有一个浏览器异常,用另一个遵循系统代理的应用测试,可以快速判断问题在浏览器还是客户端。

只有部分网站或应用失败

部分失败通常与分流、DNS、IPv4 和 IPv6 选择、应用独立网络栈有关。先查看失败目标是否命中预期路由规则,再看 DNS 返回的地址。域名规则使用的匹配形式也要确认:完整域名、子域名和关键字匹配范围不同。规则过宽会影响无关目标,规则过窄则只匹配单一主机名。调整后清理相关缓存,再重新测试。

应用失败而浏览器正常时,检查它是否支持系统代理、是否使用 UDP、是否运行在容器或虚拟机中。系统代理主要覆盖 HTTP 类请求,TUN 才能接管更多通用流量,但也要确认客户端配置对 UDP 的处理。Android 分应用代理应检查包选择;Linux 容器应检查网络命名空间;Windows 后台服务可能运行在不同账户上下文。这些平台差异都属于接管层,而不是订阅层。

TUN 开启后全局断网

第一步关闭 TUN,确认基础网络和系统代理恢复。第二步查看虚拟接口是否创建成功、默认路由是否指向预期位置。第三步检查 DNS 是否被改到不可达地址。第四步排除其他虚拟网络程序的路由冲突。不要在全局断网状态下继续修改节点协议和订阅字段,因为这些设置与虚拟接口未建立没有直接关系。

如果关闭 TUN 后仍然断网,检查残留系统代理、默认路由和 DNS。Windows 查看手动代理,macOS 查看网络代理项目,Linux 查看环境变量、桌面代理和 ip route。恢复基础网络后再重新启用。频繁切换网络或休眠后出现问题,可以先重建客户端连接,而不是重启整个设备。只有路由持续不恢复时,才考虑更深层的系统网络处理。

日志怎么读,哪些内容适合提供

有效日志包含时间、模块、错误类型和上下文。常见关键词可以分为解析错误、连接超时、拒绝连接、握手失败、配置字段错误和权限错误。排错时复制错误前后数行,说明平台、客户端、当前使用系统代理还是 TUN,以及问题能否稳定复现。不要只截一行“failed”,因为同一单词在不同阶段代表完全不同的原因。

提供日志前应遮盖订阅链接、节点地址、用户标识、认证字段和本地个人路径。节点名称如果包含账户信息也要处理。保留协议类型、传输方式、错误模块和时间顺序通常已经足够。更多常见问答可进入FAQ 页面,生态与客户端关系则可查看Project V、V2Fly 与 Xray 的关系

一套可重复的恢复流程

当设置已经改得难以追踪时,不要继续叠加参数。先导出或记录现有配置,然后关闭 TUN、清除系统代理、恢复默认路由与 DNS策略。保留一个订阅分组,更新后选择一个节点,用系统代理完成最小测试。成功后按“路由、DNS、TUN、分应用”的顺序逐项恢复,每加一项就验证日志和目标行为。

如果最小配置仍失败,换一个已知正常网络做对照,可以区分设备配置和当前网络。再用同一订阅中的另一个节点对照,可以区分节点个体问题和共同配置。Android 还可以在 v2rayNG 与 v2flyNG 之间进行内核家族对照,但应保持网络和节点一致。对照实验一次只换一个变量,结果才有解释价值。

最终目标不是消除日志中的所有提示,而是确认请求按预期进入客户端、解析正确、连接成功并命中正确出站。部分重试和非关键提示可能不会影响实际使用。先解决导致请求中断的第一条错误,再处理后续派生错误。掌握这一顺序后,界面名称即使变化,排错方法也不会失效。