V2Ray 常见问题配置与故障排查

先区分配置界面与实际处理连接的内核。V2Ray 通常指 Project V 相关技术与软件生态；V2Fly 与 Xray 是相关内核家族，负责协议、路由和连接处理。v2rayN、v2rayNG、v2flyNG 则提供导入、选择节点和修改设置的图形界面。界面里出现某个选项，不代表当前使用的内核一定支持对应功能；排查兼容性时，应同时查看客户端版本、实际运行的内核及配置字段，不能只凭客户端名称判断。

桌面端优先按系统选择 v2rayN，Android 通常先选 v2rayNG，再根据内核兼容需求考虑 v2flyNG。v2rayN 覆盖 Windows、macOS 和 Linux；v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核。两款 Android 客户端的参数支持与更新节奏可能不同，不应把一份特定内核配置直接视为通用配置。已有订阅时，先确认提供方标注的协议与客户端要求，再决定安装哪款；更换客户端前保存必要设置，导入后重新检查路由与 DNS。

还需要有效的服务器配置或兼容的订阅链接，安装客户端本身不会生成可用连接。节点配置通常包含地址、端口、身份参数，以及传输和 TLS 等设置；订阅链接则用于批量获取这些配置。导入后要选择活动节点，并按应用需求启用系统代理或 TUN。订阅链接可能携带访问凭据，应当像密码一样保存；求助时不要贴出完整链接、二维码或配置截图中的身份信息，只提供经过遮挡的错误描述和日志片段。

确认设备使用 ARM64 且系统支持对应应用架构时，优先选 arm64；无法确认时可考虑 universal。近年的主流 Android 手机通常使用 ARM64，但处理器支持不等于系统一定开放了对应运行环境，旧设备与模拟器尤其需要单独确认。通用包通常包含多个架构的组件，因此文件较大，具体覆盖范围仍以该包说明为准。遇到安装解析失败，还要检查 Android 系统版本、下载是否完成，以及设备已有应用的签名冲突，不能直接归因于架构。

先确认复制的是订阅地址，而不是登录页面、分享页面或单个节点的说明文字。去掉首尾空格与换行，在订阅分组中新增地址并保存，再执行该分组的更新。若提示格式错误，检查提供方是否提供了当前客户端可识别的订阅格式；返回网页、登录提示或空内容都不能当作节点列表解析。单节点分享链接应走剪贴板导入等对应入口。仍然失败时，记录错误原文与发生时间，并确认订阅有效期，避免反复粘贴同一条失效地址。

新安装可先了解跨平台桌面版，习惯经典 Windows 界面的用户可选择 WPF 版。两者主要区别在界面技术与运行环境要求，不代表名称相似就能共享所有设置文件。安装前核对系统架构及该发行包要求的运行库；启动提示缺少组件时，应按错误信息补齐对应环境，而不是反复更换节点。迁移时先使用客户端提供的备份或导出能力，再在新界面中检查订阅分组、监听端口和路由。不要将两套程序放在同一目录中覆盖使用。

先用系统代理完成基础验证，再根据应用需求决定是否启用 TUN。系统代理告诉遵循系统设置的应用使用本地代理端口，路由规则则决定进入内核后的连接走哪个出站；两者处理的环节不同。TUN 通过虚拟网络接口接管更多流量，但仍需要合适的路由、DNS 和权限。初次配置不要同时开启多个客户端的系统代理或 TUN，也不要叠加不明来源的网络接管工具。先保持一条清晰路径，连接正常后再逐项增加分流与接管设置。

先按当前系统与客户端提示完成必要授权，再检查虚拟网络组件是否正常。Windows 上部分实现需要提升权限或安装对应服务，macOS 与 Linux 也可能需要系统授权、辅助组件或网络接口访问权限，具体取决于发行包。Android 应确认已允许建立 VPN 连接，并检查是否有其他应用占用了同类连接。授权失败时先关闭 TUN，确认普通代理可以工作，再查看启动日志。不要为解决单次报错而长期关闭安全防护，也不要同时启用两个虚拟网络接管入口。

先保留已有节点，不要删除分组后再尝试恢复。订阅更新请求与节点连接是两条不同路径，已有节点可用并不能证明订阅地址可访问。检查订阅是否到期、地址是否被更换，以及客户端是否配置了通过代理更新订阅；如果直连更新失败，可在已有可用连接下尝试代理更新，反之亦然。具体入口随版本变化，应以当前界面为准。遇到证书或 HTTP 状态错误时记录原文；不要通过关闭证书验证来掩盖问题，也不要连续高频刷新。

先确认匹配到的规则，再把需要直连的规则指向实际存在的 direct 出站。常见配置会将 geoip:private 与 geosite:cn 放在兜底代理规则之前，但具体顺序仍要结合拦截规则和个人需求。规则通常按顺序匹配，提前出现的宽泛代理规则可能让后面的直连规则失去作用。若使用 geosite 或 geoip，还要确认当前内核能够加载所需规则数据。修改后保存并重新加载配置，再用新连接验证；已建立的连接可能继续沿用旧路径。

先确定域名由应用、系统还是内核解析，再决定修改哪一层。浏览器的安全 DNS、系统 DNS、内核 DNS 和 TUN 的 DNS 接管可能同时存在，只改其中一处不一定改变实际查询路径。排查时记录原设置，每次只修改一个环节，并分别测试域名访问与连接日志。路由中的 domainStrategy 会影响特定条件下的域名解析与 IP 匹配，不等于全局 DNS 开关。不要直接照抄其他内核的字段；只有确认查询路径后，再考虑分域名解析或 FakeDNS。

按来源或用途建立独立分组，并为每组保留清晰名称，不要把所有地址混在一个无法辨认的列表里。更新单组后，先检查该组返回的节点及当前活动项，再执行连接。筛选条件可能隐藏节点，因此更新后列表为空时，还要检查名称过滤、协议过滤和分组选择。不同客户端的更新行为不完全一致，手动修改订阅生成的节点可能在下次更新时被覆盖；需要长期保留的自定义项应按客户端支持的方式单独管理。删除分组前先备份必要配置。

按本机时间、订阅状态、本地内核、连接参数、服务端状态的顺序检查，避免一开始就改动全部设置。先开启系统自动校时，更新订阅并确认活动节点；再看内核是否成功启动、端口是否被占用，以及日志中是连接超时还是 TLS 握手失败。核对地址、端口、传输类型、服务器名称与身份参数，注意不同协议的字段不能互相套用。最后换一个网络或另一条已知可用配置做对照。测速超时也可能受测试目标影响，应结合实际访问判断。

先确认流量是否进入客户端；界面显示运行中，只能说明服务或接管流程已启动，不等于目标连接成功。查看访问时是否产生新日志，再分别检查活动节点、系统代理或 TUN 状态、路由出站与 DNS。若所有域名均失败，重点看解析错误及本地监听；若只有部分站点失败，重点看规则命中、目标连接和协议参数。可临时使用简化规则做对照测试，但测试结束后应恢复所需分流。一次只改一项，并记录修改前后的结果，便于定位真正原因。

要分开检查，因为浏览器与命令行工具不一定读取同一套代理设置。浏览器先检查系统代理开关、代理扩展、PAC 和应用自身设置，确认实际指向当前客户端的监听地址与端口。终端程序则要检查是否支持代理环境变量，已有终端进程也可能需要重新打开；部分工具还具有独立的代理选项。不要把一个协议的监听端口直接填给另一种代理类型。浏览器正常而终端失败时，优先查终端设置，而不是立即更换节点；需要接管更多应用时再评估 TUN。

先判断是客户端进程被结束、VPN 连接被替换，还是节点本身失效。观察断连前后的常驻通知与日志，再检查系统电池优化、后台运行和自动启动权限；不同厂商的设置位置可能不同。若另一款应用启动了 VPN，同类连接可能发生冲突，应只保留当前需要的接管入口。切换移动网络与无线网络后出现问题时，可重新连接并检查 DNS 与网络状态。不要仅凭锁屏后打不开网页就判定订阅失效，也不必一次关闭所有省电策略，应逐项测试必要权限。