V2Ray 常见问题

V2Ray 所属的 Project V 生态提供代理通信相关的组件，V2Fly 与 Xray 是相关的内核项目，负责处理协议、连接、路由和 DNS 等工作。v2rayN、v2rayNG、v2flyNG 则提供图形界面，用于导入服务器信息、管理订阅和调整配置。界面能够打开不代表内核已经成功运行，内核运行也不代表远端服务可用。遇到问题时，应分别确认客户端设置、内核启动日志与服务器参数，而不是只根据界面上的连接状态判断。

Windows、macOS 与 Linux 桌面环境优先查看 v2rayN；Android 通常先考虑使用 Xray 内核的 v2rayNG，需要 V2Fly 内核环境时再查看 v2flyNG。选择前应核对订阅使用的协议、传输方式和内核功能要求，不能只比较界面是否相似。不同客户端及版本的导入格式、路由预设与配置入口可能不同，迁移时先保留原有可用配置，再用一个条目验证。客户端不会自动提供服务器，仍需准备有效的节点信息或订阅地址。

arm64 安装包面向支持 ARM 64 位应用的设备，universal 通常包含多种处理器架构的组件，因此文件往往更大。多数较新的 Android 手机可优先检查 arm64，但购买年份不能代替架构信息：部分设备的处理器支持 64 位，系统却仅支持 32 位应用。可在系统设备信息中确认架构；无法确认时考虑通用包，并以该客户端当前发行说明为准。出现安装失败时，还要检查系统版本、剩余空间和现有应用签名冲突，不要直接归因于网络。

不能只修改客户端的协议名称就完成切换。VLESS、VMess、Trojan 是不同的代理协议，REALITY 属于相关连接安全配置，通常还需匹配服务器端的传输与握手参数。服务器地址、端口、用户标识或密码，以及按需使用的服务器名称、公钥和短标识，都应与服务端一致。订阅已提供完整参数时优先保留原值；手动调整前保存原配置。协议选择首先看服务端支持和当前内核兼容性，不能仅凭名称判断连接速度或可用性。

先区分订阅地址与单个节点分享链接：前者通常添加到订阅分组，后者通过剪贴板或分享链接导入入口处理。复制时去掉首尾空格，确认链接没有被聊天软件截断，也没有把网页标题一起复制。订阅分组保存后，通常还要执行一次更新，并检查是否启用了过滤条件。若返回的是登录网页、错误页面或客户端不支持的配置格式，地址能够打开也不会产生有效条目。记录更新提示，向提供方确认适配格式；订阅地址含有访问凭据，不应公开粘贴。

订阅下载与已有节点连接是两条不同的请求路径，因此一种成功不能证明另一种正常。先查看失败提示是域名解析、连接超时、证书错误还是授权失效，再确认设备时间和订阅有效期。如果客户端提供通过代理更新的选项，可在已有节点确实可用时尝试；反过来，代理路径失效时也可检查直连更新是否可达。排查期间保留原订阅分组和可用条目，避免先清空再更新。若提示访问频率受限，应等待后再试，不要连续点击或反复创建相同分组。

TUN 模式需要创建虚拟网络接口并调整相关路由，所需权限高于普通本地代理。Windows 可按客户端说明使用管理员权限或安装对应服务；macOS、Linux 应按当前版本的图形提示完成授权，避免随意更改整个配置目录的权限。Android 需要确认系统的 VPN 连接授权，并检查是否有其他应用正在占用同类连接。授权后仍失败时，查看日志中的接口、驱动或路由错误。先恢复普通代理验证节点，再处理 TUN；不应为了排查而长期关闭防火墙或其他系统防护。

先确认客户端内核已经启动，再检查系统代理是否指向客户端当前监听的本地地址与端口，注意 HTTP 与 SOCKS 端口可能不同。浏览器若启用了自己的代理扩展或独立网络设置，可能覆盖系统设置；某些应用也不会读取系统代理。可暂时只保留一种代理管理方式，重新启动浏览器后验证，并检查系统代理例外列表。不要把监听地址改成所有网卡来解决本机问题。若应用本身不使用系统代理，可查看其手动代理选项，或在理解接管范围后使用 TUN。

系统代理决定哪些应用请求会被交给客户端，路由模式决定进入内核的请求选择哪个出站，TUN 则改变流量接管方式，三者不是同一层设置。客户端所称的全局模式，通常是让已接管的流量优先使用代理出站，并不意味着所有程序都自动受控。规则分流会按域名、地址或其他条件选择代理、直连或阻断。TUN 接管后仍可能继续应用路由规则。排查时先确定请求有没有进入内核，再看规则匹配结果，避免把接管问题误认为节点问题。

测试结果只反映某种探测方式在当时的表现。端口探测成功可能只说明远端端口可达，不能保证协议握手、域名解析和目标网站请求都成功；实际请求测试也只代表所用测试地址。选节点时应先确认能够完成真实访问，再观察连续使用中的稳定性，并核对订阅方说明的流量倍率与地区信息。一次延迟较低不等于吞吐量更高。比较时固定测试方式和网络环境，逐个切换，避免同时更改 DNS、路由和节点后无法判断是哪项起作用。

按来源建立独立分组，使用能识别用途的名称，并分别确认更新地址和过滤条件。自动更新前先验证新订阅是否能够正常解析；需要保留的手动条目应放在独立位置，避免订阅刷新时被覆盖。名称重复不一定代表同一服务器，比较时还要看地址、端口、协议和分组来源。更新后列表变短，先检查过滤条件与提供方返回内容，不要立即删除全部分组。导出或备份配置时注意其中可能包含订阅凭据、用户标识和密码，应保存在受控位置。

修改前记录当前预设与可用节点，每次只调整一个变量，并按客户端要求保存、重载或重启内核。路由规则通常与匹配顺序有关，应确认更宽泛的规则没有提前覆盖目标规则；DNS 还可能受到浏览器独立解析、系统缓存和内核缓存影响。使用同一目标重复验证，并从日志查看实际出站或解析错误，不能只看设置页上的开关。验证结束后恢复临时日志级别；若需要分享日志，先移除地址、凭据和个人访问记录，再提交与问题有关的少量内容。

先关闭代理确认基础网络可以正常访问，再核对当前节点的地址、端口、协议与订阅状态。若只有一个节点失败，可切换同订阅的其他条目对比；若全部失败，优先查看内核是否启动、设备时间是否准确，以及本地防火墙是否阻止客户端联网。日志中的连接超时与认证失败含义不同，后者更应检查凭据和协议参数。必要时更换一个已知可用的网络进行对照，但不要同时重装软件和重写配置。节点服务故障或订阅到期需要由服务提供方处理。

界面显示已连接可能只代表内核正在运行。先确认浏览器请求确实进入客户端：检查系统代理模式、本地监听端口与浏览器独立代理设置；再查看日志是否出现解析失败、握手失败或路由到错误出站。使用同一个网站切换一条已知可用节点，区分节点问题和本地配置问题。随后核对 DNS 设置与分流规则，必要时暂时恢复客户端默认预设进行对照。若只有个别网站异常，还要考虑站点本身的可用性或访问限制，不应直接认定整个代理连接失败。

先判断失败的是服务器域名解析，还是目标网站域名解析：前者会阻止节点连接，后者可能表现为节点可连接但网页打不开。检查所填 DNS 的协议、地址与可达路径，使用加密 DNS 时还要留意其自身域名如何完成初始解析。不要把所有解析都指定走一个尚未建立的代理，以免产生循环依赖。浏览器独立 DNS 与系统解析可能使用不同路径，应分别确认。每次只修改一个设置，重载内核后重新测试；公共 DNS 地址并不能自动解决所有网络环境中的解析问题。

退出后先检查系统代理是否仍指向已经停止的本地端口，必要时在系统网络设置中恢复自动或关闭手动代理，并检查是否还留有其他代理工具的配置。使用 TUN 时优先通过客户端正常关闭，再检查虚拟接口与路由是否恢复，避免直接删除不熟悉的系统接口。切换无线网络或从休眠恢复后，可重新连接基础网络，再重启内核并验证节点。若问题持续，保存错误日志后逐项恢复最近修改；不要直接重置全部网络设置，以免影响其他工作连接。