V2Ray 常见问题

V2Ray 属于 Project V 代理工具生态，V2Fly 延续 V2Ray 的社区维护，Xray 是从该生态发展出的内核分支。内核负责协议处理、路由与数据转发；v2rayN、v2rayNG、v2flyNG 提供配置管理和图形操作入口。v2rayNG 使用 Xray，v2flyNG 使用 V2Fly；v2rayN 的实际内核取决于所用版本与配置。判断某项协议能否使用，应同时核对客户端版本、实际启动的内核及服务端参数，不能只看界面中是否出现相似名称。

客户端安装完成只代表本地工具可运行，并不等于已经具备可连接的远端服务。通常还需导入有效订阅、分享链接，或手动填写服务端提供的地址、端口、认证与传输参数。本站提供客户端入口与配置文档，不提供节点或订阅。已有配置仍需检查有效期、服务状态和协议兼容性。不要将来历不明的订阅直接覆盖现有配置；先单独建立分组，确认来源与用途，再选择节点并进行连接测试。

系统代理向遵循系统代理设置的应用提供本地代理地址，不保证覆盖所有程序。路由规则在流量进入内核之后决定使用哪个出站，不能让未进入客户端的流量自动出现。TUN 通过虚拟网络接口接管符合条件的流量，还涉及系统路由、DNS 和权限。排查时应按应用是否进入客户端、路由是否匹配、出站是否可用的顺序检查。初次配置建议先用系统代理验证浏览器访问，再单独测试 TUN，避免同时改变多个入口。

Windows、macOS 与 Linux 桌面优先查看 v2rayN；Android 优先查看采用 Xray 内核的 v2rayNG，需要 V2Fly 内核时再评估 v2flyNG。选择依据是操作系统、设备架构及现有配置的协议要求，而不是名称相近程度。Windows 的 v2rayN 桌面版采用跨平台界面，WPF 版采用经典界面，菜单位置可能不同。切换客户端前先备份配置，确认目标客户端支持原有传输与安全参数，不要直接复制另一款工具的内部数据库。

arm64 适用于运行 64 位 ARM 系统的设备，2015 年后主流 Android 手机通常可先考虑这一项，但最终应以设备系统支持的 ABI 为准。universal 包含多种架构的原生组件，适合暂时无法确认架构时选择，体积通常更大。处理器支持 64 位不代表所装系统一定是 64 位。若提示安装包不兼容，先核对系统版本与 ABI；若提示签名冲突，则是已有应用与新包签名不一致，不能仅靠改选 universal 解决。

先区分订阅地址与单个节点分享链接：前者应加入订阅分组后更新，后者使用从剪贴板导入等节点导入入口。复制时检查首尾空格、换行和缺失字符，确认地址没有被聊天软件截断。列表为空时查看订阅更新日志，并确认当前分组筛选没有隐藏新节点。返回登录页、错误页面或空内容的地址不能作为有效订阅解析。若服务端使用客户端尚不支持的格式，应向提供方确认适配格式，不要通过反复修改地址中的认证字段尝试修复。

macOS 先在关于本机中查看芯片信息，Apple Silicon 选择 arm64，Intel 选择 x64。Linux 同时核对处理器架构与发行版包格式，Debian、Ubuntu 系通常使用 deb，Fedora 等通常使用 rpm；ARM 设备需选择对应 arm64 包。安装后无法启动时，应先读取系统给出的依赖、权限或兼容性提示，而不是直接更换节点。应用能打开但内核不能启动属于另一层问题，应继续检查日志、运行库与文件执行权限，避免将软件安装问题误判成网络故障。

先确认当前客户端版本确实提供 TUN 功能，再按该版本提示授予创建虚拟接口和修改路由所需的权限。Windows 通常需要管理员权限或客户端配套的服务机制；macOS 与 Linux 的授权方式取决于具体版本，不能照搬另一平台的步骤。Android 需确认系统 VPN 授权，并检查是否已有其他 VPN 应用占用连接。只授予功能所需权限，不要整体关闭安全防护。排查前先关闭 TUN 验证普通代理可用，若基础出站失败，提升权限也不会修复远端连接。

先手动成功更新一次，再在客户端的订阅分组设置或订阅设置中查找自动更新选项；具体名称、时间单位与触发条件以当前版本界面为准。根据提供方更新频率设置合理间隔，不要用极短周期反复请求。桌面客户端退出后通常不会继续执行自身定时任务，Android 的后台限制也可能延迟更新。若更新依赖代理，应保留一个可用的当前节点，并核对更新请求的联网方式。自动更新只刷新配置内容，不会延长订阅有效期或恢复已停用服务。

通常不需要。订阅用于批量获取和刷新节点配置，切换节点是在已有列表中选择活动配置，两者是不同操作。切换后检查客户端是否已应用新配置，以及日志中是否出现重载失败。浏览器的现有长连接可能继续使用旧连接，测试时可关闭原页面后重新打开，必要时重启对应应用。若列表由自动选择或负载均衡规则控制，界面选择还可能不是最终出口，需要检查当前模式。只有节点参数发生变化、配置过期或列表确实需要刷新时，才应更新订阅。

先确认内核启动成功，再启用系统代理，并核对系统代理指向的地址和端口与客户端本地入站一致。打开一个新的浏览器页面，同时查看客户端访问日志；日志中出现对应请求，才说明该请求进入了内核。日志未开启时需先启用适当级别，测试后可恢复原设置。浏览器扩展、独立代理设置或应用自身连接策略可能覆盖系统设置。延迟测试成功只能证明测试路径可用，不能证明浏览器已接入；出口地址也只能辅助判断，直连规则可能让不同请求使用不同出口。

优先使用当前客户端提供的备份或导出功能，并记录订阅分组、活动节点、路由模式、本地端口与 DNS 设置。导出的内容可能包含订阅凭据和节点认证信息，应保存在受控位置，不要上传到公开讨论区。升级前确认目标版本的系统要求及配置迁移说明；迁移完成后先测试基础连接，再逐项恢复自定义路由和 TUN。订阅节点可能在下次更新时被覆盖，因此自定义修改应另存。切换到另一款客户端时，以通用分享链接或受支持的配置格式导入更稳妥。

先确认当前设备可以正常连接基础网络，再核对服务端地址、端口和订阅有效状态。真连接测试超时可能涉及解析、连接建立、TLS 握手或测试目标不可达，单个结果不能直接证明节点永久失效。查看同一时刻的日志，区分域名解析失败、连接被拒绝与握手错误。可在同一网络下换一个已知可用配置作对照，再在获准使用的另一网络测试原配置。若所有配置都失败，优先检查本地网络与内核；只有某一配置失败，再核对该配置的传输、安全参数与服务状态。

已连接可能只表示本地 VPN 接口或内核进程已经启动，不代表远端请求成功。先看浏览器请求是否出现在访问日志中：没有请求就检查系统代理、浏览器设置或 TUN 接管范围；有请求则检查匹配的出站与错误日志。若域名访问失败但其他连接正常，重点核对 DNS 配置和系统时间；若仅个别网站失败，检查对应路由规则与目标服务状态。排查时先恢复简单配置，关闭重复的代理入口，每次只改一项并重新测试，避免同时修改 DNS、路由和节点后无法确定原因。

先检查客户端内核是否成功监听本地入站，再比较系统代理中的主机与端口，不能只看系统代理开关状态。部分程序不读取系统代理，需要在程序内设置受支持的 HTTP 或 SOCKS 入口，或另行评估 TUN。日志出现 address already in use 时，关闭重复运行的客户端实例，或将本地监听端口改为未被占用的端口，并同步更新引用该端口的应用设置。不要终止无法确认用途的系统进程。若由代理扩展或其他网络工具反复覆盖设置，应先停用冲突项，再重新应用系统代理。

订阅更新失败发生在获取或解析订阅内容时，应检查链接有效期、认证状态、请求所走网络与证书错误。可先确认系统时间正确，再分别测试直连更新与通过已有可用代理更新；不要在公开日志中暴露完整订阅地址。内核启动失败发生在加载本地配置时，应找日志中的首个具体错误，例如 JSON 语法、未知字段、缺失文件或端口冲突。前者不一定影响已有节点继续使用，后者会使依赖该内核的连接无法建立。先判断故障阶段，再修复对应设置，不要把清空全部配置作为第一步。