V2Ray 全平台安装订阅、代理与排错配置

通用准备：平台、订阅与配置备份

先区分客户端、内核与节点

v2rayN 负责桌面的节点列表、订阅管理、代理入口和内核运行；v2rayNG 与 v2flyNG 提供安卓端的图形操作入口。内核负责解释协议、执行路由和建立连接，节点则是远端服务的参数集合。安装客户端不会自动获得可连接的节点。开始前需要准备有效的订阅地址、分享链接或完整配置，并确认这些资料来自有权使用的服务。

桌面平台优先选择 v2rayN。安卓端优先从使用 Xray 内核的 v2rayNG 开始，已有 V2Fly 配置需求时再考虑 v2flyNG。协议名称相同不代表所有扩展字段都能互用，传输方式、安全层参数与内核能力必须同时匹配。出现导入成功但连接失败时，先核对配置来源要求的内核，而不是反复安装不同客户端。

安装包还要与处理器架构对应。Windows 本页按下载页提供的 x64 桌面版和 WPF 版说明；macOS 区分 Apple Silicon 与 Intel；Linux 同时区分架构和软件包格式；Android 区分 arm64 与通用版。系统名称、处理器架构、应用界面类型是三个不同维度，不能仅凭文件名里出现自己的系统名称就认定适用。

订阅资料与本机环境检查

订阅地址通常包含访问凭据，应按账号密码的敏感程度保存。复制时检查首尾空白、换行和聊天软件附带的标点；分享截图时遮住地址、用户标识和节点认证字段。订阅更新失败也可能只是地址过期或返回了网页，不能仅凭状态栏的失败提示判断软件损坏。记录报错摘要即可，不要把整条私人地址提交到公开讨论区。

开始连接前确认系统时间和时区正确，并开启系统提供的自动校时。证书校验和部分协议握手依赖时间，偏差过大会表现为安全连接失败。再检查基础网络是否能正常访问本地服务、是否需要先完成网络登录，以及系统中是否已有其他代理或虚拟网卡程序运行。第一次测试只保留一套流量接管入口，便于确定请求究竟经过哪里。

订阅、分享链接与原生 JSON 不是同一种输入。订阅一般用于批量更新节点，分享链接通常描述单个节点，原生 JSON 则可能包含入站、出站、路由与 DNS 的整套结构。应使用客户端对应的导入入口，不能把完整配置当作订阅地址更新。格式边界可继续查阅订阅格式与分享链接对照。

建立可回退的最小配置

首次配置只需要一个有效节点、一种接管方式和明确的路由模式。先不要叠加自定义 DNS、复杂规则和应用分流。把订阅更新、节点可达、浏览器访问分别验证，再逐项增加设置。这样每次改动都有前后对照，出现问题时能回退到刚才可用的状态，避免多个开关同时变化后失去排查依据。

升级或迁移前，通过客户端提供的备份、导出功能保存配置；需要手动备份时先完全退出客户端，再复制其实际配置目录。不同安装方式的数据位置可能不同，应从界面或日志确认，不要凭网上的旧路径覆盖文件。备份应包含订阅分组、路由设置及必要的自定义配置，同时限制备份文件的访问权限，防止节点凭据泄露。

Windows：v2rayN 安装与系统代理

选择桌面版或经典 WPF 版

从Windows 安装包入口选择 v2rayN。桌面版使用新一代跨平台界面，WPF 版保留经典桌面操作方式；二者不代表两套节点服务。已有使用习惯时按界面选择，首次安装可从桌面版开始。下载页提供的是 x64 入口，安装前在系统信息中确认处理器架构及当前系统满足该包的运行要求。

运行安装程序后按界面选择安装位置；若实际取得的是需要解压运行的分发形式，应先完整解压到稳定目录，再启动主程序，不能直接在压缩包预览中运行。目录尽量不要放在临时下载区，也不要只复制主程序而遗漏附带资源。内核、规则数据或运行依赖缺失时，界面可能正常打开，但启动连接阶段仍会失败。

普通系统代理测试不需要一开始就长期使用管理员权限。先以正常用户启动，观察日志能否创建监听端口、读取配置并启动内核。如果系统安全提示阻止某个组件，先核实提示对应的文件和操作来源，不要直接关闭整套安全功能。确实需要提升权限的 TUN 操作应单独处理，不能用提高权限掩盖路径错误或端口冲突。

导入订阅并建立第一次连接

在订阅管理区域新增分组，填写容易识别的备注和完整地址，保存后执行该分组的更新。不同界面的菜单名称可能略有差异，但新增记录与拉取节点通常是两个动作。更新结束后检查分组内是否出现节点，并查看日志是否提示认证失败、解析失败或返回格式不符。不要把一个空分组误认为已经完成订阅导入。

从新分组中选择节点并设为活动配置，再进行真连接测试。延迟探测只说明某种探测路径有回应，不等于协议握手、目标访问和 DNS 均正常。优先选择测试能够完成的节点，记录其名称与协议类型。若一整组都失败，检查订阅有效性与系统时间；只有单个节点失败，则先换同组其他节点，避免直接重置全局设置。

启动内核后启用系统代理，让遵循系统设置的应用把流量交给本地监听地址。代理模式的具体名称以当前界面为准，关键是确认代理已写入系统并且客户端仍在运行。随后打开浏览器访问已知可用的测试页面，结合出口地址检查与客户端日志确认请求经过预期出站。详细的验证方法见首次连接与代理生效验证。

系统代理边界与 TUN 排错

系统代理并不强制接管所有程序。部分命令行工具、游戏或独立网络组件需要单独设置代理，浏览器扩展也可能覆盖系统选择。出现浏览器可用而某个应用失败时，先查该应用是否读取系统代理、使用何种传输以及是否有自己的网络设置。不要因为一个应用没有走代理，就断定活动节点整体不可用。

如果确实需要更广的流量覆盖，再检查当前 v2rayN、所选内核及系统环境是否提供可用的 TUN 功能。启用前记录系统代理状态和原有网络设置，按提示完成所需权限或组件配置。先停用其他虚拟网卡接管程序，再验证局域网、域名解析和目标访问。TUN 是流量进入客户端的方式，最终直连还是代理仍由路由决定。

退出后网络异常时，首先检查 Windows 的手动代理是否仍指向已经关闭的本地端口；恢复到原来的设置后再测试。端口占用则应从日志查出具体端口，关闭重复运行的客户端或调整本地监听，而不是修改远端服务器端口。升级后规则丢失、启动路径变化和开机自启失效也应分别核对，不能混成一次节点故障。

macOS：芯片选包与网络权限

按芯片安装 v2rayN

打开系统的“关于本机”查看芯片信息，再到macOS 安装包入口选择对应的 v2rayN。Apple Silicon 使用 arm64 包，Intel 使用 x64 包；不要依据电脑外观、购买年份或设备名称猜测架构。架构选错可能表现为无法启动、需要兼容运行环境或组件异常，遇到这些现象应先核对下载选择，而不是修改订阅。

打开 DMG 后，按安装界面把应用放入应用程序目录，再从稳定位置启动。不要长期在挂载的安装映像内运行，否则推出映像、清理下载文件或重新登录后，原来的启动路径可能失效。首次启动若出现系统安全提示，应先确认应用来源与文件对应关系，再使用系统提供的允许打开流程处理，不需要关闭全局安全策略。

应用能够显示窗口并不表示所有网络权限都已完成。系统代理修改、后台组件和 TUN 接管可能在实际启用时才请求授权。应阅读提示的权限范围，按当前功能逐项授权；如果此前拒绝过请求，再到系统设置检查相应项目。不要重复点击启动来代替授权，也不要把权限对话框中的失败误判为远端节点不可达。

订阅、系统代理与验证

进入订阅管理新增分组并保存地址，随后更新该分组，确认节点列表确实刷新。跨设备复制地址时注意剪贴板是否带入换行或空格；如果同一地址在其他设备可用，本机却没有节点，应先检查更新日志和当前网络的访问条件。导入分享链接时使用对应入口，完整原生配置则需要按客户端支持的自定义配置流程处理。

选定一个节点并启动内核，先验证连接测试能够完成，再开启系统代理。macOS 的代理设置与网络服务关联，Wi-Fi、有线网络及其他服务可能各自保存状态。切换网络后出现行为变化时，检查当前实际使用的网络服务，而不是只查看另一个接口的代理开关。客户端显示已开启也应与系统当前网络设置相互核对。

浏览器是否使用系统代理还取决于其自身配置。测试时暂时停用会接管代理的扩展，保持一条明确的入口链路，再访问已知可达的页面并查看日志。只看到网页加载不能证明所有流量都被接管，因为页面也可能通过直连出站成功。需要代理的目标应结合路由日志和出口信息判断，不要求所有站点都显示相同出口。

TUN、休眠与网络服务切换

当应用不遵循系统代理时，可在当前客户端和系统支持的范围内考虑 TUN。开启前检查是否已有其他网络过滤、虚拟网卡或隧道功能占用接管路径，避免同时接管默认路由。授权完成后先测试基础域名解析，再验证目标连接和局域网访问。若启用后整机断网，先关闭 TUN 回到系统代理基线，再检查路由与 DNS 设置。

电脑休眠唤醒或从有线切换到无线后，原有连接可能失效，本地监听却仍然存在。此时先检查基础网络是否恢复，再重启当前连接或内核，不必立即删除订阅。若只有解析失败，应查看系统 DNS 与客户端 DNS 的实际使用路径；若所有连接都超时，再检查节点可达性、网络登录状态以及是否遗留了失效的路由接管。

迁移配置时优先使用客户端的导出与导入功能，不要直接用另一台设备的整套运行目录覆盖本机应用。不同架构的可执行组件不能互换，配置中的绝对路径也可能不再有效。升级前保留订阅、路由和自定义配置副本；升级后依次检查内核启动、系统代理和必要权限。完全退出时再确认代理是否恢复，避免系统继续访问已停止的本地服务。

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

同时确认发行版格式与架构

从Linux 安装包入口选择 v2rayN。使用 deb 软件包体系的发行版选择对应 deb，使用 rpm 软件包体系的发行版选择对应 rpm，再区分 x64 与 arm64。桌面环境名称不决定包格式，处理器品牌也不能替代架构确认。先在系统信息中核对发行版与架构；需要命令行辅助时，可用下面的只读命令查看，不会修改系统设置。

uname -m
cat /etc/os-release

x86_64 通常对应下载页的 x64，aarch64 通常对应 arm64。确认后通过图形软件安装器打开下载的软件包，按提示处理依赖并完成安装。包格式正确仍可能受系统库版本限制，应阅读安装器给出的具体依赖错误。不要为了消除提示就强制忽略依赖，也不要把其他架构的软件包当作当前系统的替代方案。

安装完成后从应用菜单启动 v2rayN，先确认图形界面、配置写入和内核启动都正常。不同桌面会话的托盘支持可能不同，关闭主窗口后的程序状态应通过进程和日志确认，不能仅凭托盘图标是否存在判断。若界面无法启动，应先处理运行依赖或图形会话问题；这类故障发生在读取节点之前，与订阅内容没有直接关系。

导入订阅与桌面代理边界

新增订阅分组、保存地址并执行更新，确认获得节点后再选定活动配置。Linux 上尤其要区分图形客户端使用的网络环境和终端环境：终端能够访问订阅地址，不表示图形应用继承了同样的代理变量。若更新失败，查看客户端自己的日志，核对它实际采用的是直连、系统代理还是其他已配置的入口，避免形成对自身监听端口的依赖循环。

启用系统代理后，在桌面网络设置中检查实际写入的主机、端口与忽略列表。不同桌面环境对系统代理的实现并不一致，部分应用只读取自身配置或启动时继承的环境变量。浏览器可用而终端工具不可用时，应检查后者的代理支持方式；反过来，终端设置过代理也不意味着整个桌面会话已被接管。

本地 HTTP 与 SOCKS 入口应按客户端实际显示的端口填写，不要照搬他人的端口数字。应用要求 SOCKS 时不能直接当作 HTTP 地址输入；使用远端解析还是本地解析，也取决于应用采用的协议和设置。第一次验证只测试一个应用、一种入口，确认请求出现在日志后再扩大范围，避免同时修改桌面代理、终端变量和客户端路由。

TUN 权限与多网络接口

TUN 通常涉及创建虚拟接口和修改路由的权限，是否可用取决于当前 v2rayN、内核与系统环境。优先按客户端提供的权限配置流程操作，不要把整套图形程序长期作为高权限进程运行。权限不足、设备节点不可用和路由冲突是不同故障，应从日志中的具体阶段判断。容器、受限会话或定制系统的网络能力也可能与普通桌面不同。

同时使用有线、无线、容器网络或虚拟机时，检查是否存在需要直达的局域网地址。接管默认路由后，原来的局域网访问路径可能改变；应在路由中为确有需要的私有网段设置明确策略，而不是停用整个系统防火墙。DNS 还可能由系统解析服务、网络管理器或其他组件维护，手动修改配置前先确认哪个服务是当前设置的管理者。

停止客户端后若命令行仍无法联网，检查终端会话中是否残留指向本地端口的代理环境变量；若只有桌面应用失败，则检查桌面代理是否仍开启。升级后优先重新验证安装依赖、配置目录权限和规则数据路径。迁移配置不要复制旧架构的内核文件，卸载应用前也应先恢复网络接管状态，避免删除程序后还留下不可用的代理入口。

Android：订阅导入与 VPN 接管

选择 v2rayNG 或 v2flyNG

从Android 安装包入口选择客户端。v2rayNG 使用 Xray 内核，是本页的安卓首推；v2flyNG 使用 V2Fly 内核，适合已有对应配置需求的场景。两者的设置界面和内核能力不能完全等同，尤其是含有特定扩展字段的配置，应先确认目标内核能解释这些字段，不能仅凭分享链接能够导入就判断连接必然成功。

主流 arm64 设备优先选择 arm64 包；不确定处理器或系统架构时查看系统信息，再考虑通用版。处理器具有某种能力，不代表系统用户空间一定采用同样架构。安装器提示解析失败时，先检查包是否适合设备、系统要求是否满足以及下载是否正常完成，再尝试通用包，不要把安装阶段的问题与远端服务器混在一起处理。

安装时按系统提示为当前下载工具或文件管理器授予安装权限，完成后可按需要收回该权限。若覆盖安装提示签名不匹配，应先核对现有应用的来源，备份订阅与配置，再决定如何迁移；直接卸载可能丢失分组和自定义规则。更新前还应记下当前可用的节点和路由模式，便于升级后用同一条件复测。

导入节点并完成系统授权

复制订阅地址后，在订阅设置中新增记录，填写备注并保存，再执行更新。分享链接应通过剪贴板导入等对应入口处理，二维码也应确认编码的是节点还是订阅地址。若更新后没有节点，先查看日志与分组筛选状态；若导入后仅出现一个节点，不一定是失败，可能输入内容本来就是单节点分享链接，而非批量订阅。

在节点列表中选择活动节点，启动连接时系统会请求 VPN 授权。这里的 VPN 接口用于把设备流量交给本地客户端，不表示已经确认远端节点可达，也不是桌面系统代理的同名功能。授权后观察客户端状态与日志，再访问目标页面验证。系统状态栏出现连接标识只能说明接口已建立，不能替代协议握手和实际访问测试。

Android 的普通 VPN 使用通常不要求设备取得额外的系统级控制权限，但同一用户环境下通常不能同时由两款普通 VPN 应用接管。启动本客户端前检查是否有其他网络工具正在使用该接口。如果连接按钮能按下但系统接口很快被替换，先处理接管冲突，不要在两个客户端之间反复切换节点和 DNS，以免失去稳定的测试条件。

应用分流、后台限制与网络切换

需要按应用接管时，先读清列表含义是“仅代理所选应用”还是“绕过所选应用”。两种模式相反，选中同一个应用会产生不同结果。修改后按客户端要求重新建立连接，再在目标应用中测试；原有长连接可能继续使用修改前的路径。测试浏览器是否被选中也很重要，否则浏览器直连成功或失败都不能反映节点的真实状态。

部分设备会在息屏或长时间后台运行后限制应用。出现亮屏可用、息屏断开时，先查看系统的电池优化、后台运行和自启动设置，再检查客户端是否持续保有连接。系统常驻通知与 VPN 标识可作为状态线索，但仍要结合日志。若开启始终连接或阻止未经过 VPN 的连接，节点失效时整机可能表现为无法联网，应理解这些开关的作用后再使用。

从 Wi-Fi 切换到移动网络后，旧连接可能需要重建，订阅更新路径和 DNS 访问条件也可能变化。先确认当前网络本身能访问基础服务，再重新连接同一节点；若仅某个应用失效，检查应用分流与自身缓存。v2rayNG 和 v2flyNG 的配置导出也应分别保管，迁移时核对协议、安全层和路由字段，避免把界面相似当作配置完全兼容。

路由与 DNS：从流量入口到出站

先确定接管范围，再决定出站

系统代理、TUN 和 Android VPN 接口决定请求能否进入客户端；路由规则决定进入之后使用哪个出站。开启 TUN 并不等于所有流量都要走代理，选择全局代理也不能让未进入客户端的应用自动受控。排查时先确认请求出现在内核日志中，再检查命中的规则与出站，能避免把入口问题误当成规则问题。

路由通常按规则顺序匹配，具体处理方式由所选内核决定。精确的域名例外应放在更宽泛的集合之前，局域网规则要与实际网络需求对应，最后保留清晰的兜底策略。多个规则覆盖同一目标时，不应只看规则名称推测结果，应检查匹配字段、先后顺序和最终出站。规则改动后还要重新建立测试连接，避免旧连接影响观察。

下面是 Xray 配置中的局部路由示例，用于说明私有地址直连。它不是完整配置，需要已有名为 direct 的出站以及可用的 GeoIP 数据。图形客户端可能自动生成同类设置，应优先使用其路由编辑入口，避免同时修改生成文件。自定义文件被下次启动覆盖时，也应回到负责生成它的设置源头修改。

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

域名规则、IP 规则与解析路径

geosite 用于引用域名集合，geoip 用于引用地址集合，二者不是可互换的关键字。集合名称必须存在于当前加载的数据文件中，且要符合内核支持的格式。只写域名规则时，直接以 IP 访问的流量未必会命中；只写 IP 规则时，解析结果又可能受 DNS 路径影响。两类规则应围绕明确目标组合，而非盲目堆叠。

DNS 至少要区分应用发起的解析、系统解析和内核为了路由或连接进行的解析。使用系统代理时，应用可能先在本机解析域名，再把地址交给客户端；也可能把域名交给代理端处理，取决于应用与代理协议。启用某个 DNS 开关并不能自动统一所有解析路径，尤其要检查目标应用是否自行使用加密 DNS 或缓存旧结果。

下面展示 Xray 内置 DNS 的局部结构。localhost 表示使用系统解析，queryStrategy 限制查询的地址类型；该示例用于解释字段，不是适合所有网络的通用方案。只取 IPv4 可能绕开某些地址族问题，也会放弃可用的 IPv6 路径。修改前应确认节点、目标站点和本地网络需要哪种地址族。

{
  "dns": {
    "servers": ["localhost"],
    "queryStrategy": "UseIPv4"
  }
}

按访问目标设计 DNS，而非堆叠服务器

需要按域名类别分开解析时，先明确哪些域名应使用本地解析、哪些需要经过另一条解析路径，再核对 DNS 请求自身如何出站。把远端解析地址填进列表，不代表访问该地址的流量已经走代理。若节点服务器本身使用域名，还要保证连接建立前能解析该域名，避免“先连接代理才能解析代理地址”的循环依赖。

规则数据更新与订阅更新作用不同。订阅更新节点参数，规则数据更新站点或地址集合；其中一个成功不会自动修复另一个。出现某类网站分流异常时，先用单个明确域名测试，确认规则名存在、顺序正确、数据文件被内核实际读取。完整场景可查阅geosite 与 geoip 路由实战。

DNS 故障应按症状拆分：域名失败而已知 IP 路径正常，优先检查解析；解析得到地址但握手失败，继续查安全层与连接；只有某类域名走错出站，则查匹配与缓存。更换 DNS 后应重新建立连接并按系统方式处理缓存，不要靠关闭证书验证维持访问。更细的字段解释见Xray DNS 分开解析配置。

配置常见问题：日志与回退顺序

先保存现场，再缩小故障范围

排错记录至少包含操作系统、客户端名称、所选内核、流量接管方式和失败发生的步骤。日志只截取启动到失败附近的必要内容，并遮住订阅地址、认证信息与私人服务器资料。先保存当前设置，再一次只改一个变量；若同时更换节点、重写 DNS、启用 TUN 并更新规则，即使恢复连接也难以判断原因，后续还容易复发。

读取日志时从最早的明确错误开始，而不是只看最后一行退出提示。配置读取失败会导致后续监听和连接全部缺失；端口占用会使内核无法启动；握手错误则说明程序已进入更后面的连接阶段。把故障归入配置、监听、解析、握手或路由中的一层，再选择下一步操作，通常比重复安装更能保留有效线索。

下表用于确定检查方向，不把某一种错误文本机械对应到唯一原因。同样的超时可能来自基础网络、远端不可达、DNS 或接管循环。需要将日志与实际现象放在一起看：其他节点能否连接、其他应用是否正常、关闭接管后基础网络是否恢复，这些对照条件比单独一个错误词更有判断价值。

安装、订阅与内核错误分开处理

安装失败时先确认平台、架构、包格式、系统要求和写入权限。运行时缺少组件则应检查完整安装结果，不要只替换一个主程序。升级后启动失败，可在备份基础上用最小配置复测，判断是应用运行环境变化还是旧配置不兼容。需要读懂具体启动报错时，继续查阅内核启动失败日志排查。

订阅更新失败时，先区分无法访问、认证被拒绝、返回内容无法解析和更新后列表被筛选隐藏。重新复制地址能解决输入错误，但不能修复过期服务；反复删除分组还可能丢失本地备注。更新成功后原节点名称变化也可能影响手动选择，应重新确认活动节点，不能只看旧节点还留在列表里就认定它仍是当前有效配置。

握手失败时核对服务器地址、端口、协议、传输方式、安全层和服务端要求的名称字段。订阅提供的参数通常应作为一个整体使用，不要只修改其中一项来追求暂时通过。证书错误还要检查系统时间与名称匹配；跳过验证会改变安全边界，不应作为通用排错步骤。只有确认具体字段有误，才按服务端资料修正并重新测试。

常见问答与恢复基线

恢复基线时保留备份，停用新增的自定义规则与 DNS，选择一个已知可用节点，只启用一种接管方式。按准备章节的顺序重新验证，找到最后一个成功环节。能够稳定连接后再恢复分流和应用例外，并记录每次改动。若只是需要重新走通首次连接流程，可返回快速上手教程；需要调整选包或更换平台，则回到安装包页核对入口。