V2Ray 常见问题

先按操作系统选客户端，再核对配置需要的内核功能。Windows、macOS 和 Linux 使用 v2rayN；Windows 用户可在 Desktop 跨平台界面与经典 WPF 界面之间选择。Android 通常先选采用 Xray 内核的 v2rayNG，需要 V2Fly 内核兼容场景时再考虑 v2flyNG。三者都是图形客户端，不是服务器服务。配置支持范围取决于客户端与内核的实际版本，不能只凭软件名称判断；安装包架构也要与设备匹配。

客户端负责读取配置并处理流量，安装本身不会生成可用的远端服务器。订阅地址用于批量取得和更新服务器配置，分享链接通常对应单条配置，二者不是同一种输入。应使用有权使用的服务配置，或由自建服务器生成对应信息；本站提供客户端入口与配置文档，不提供节点订阅。订阅地址可能包含访问凭据，不要放进公开截图、聊天记录或在线转换网站。导入前还应确认服务期限、流量额度以及支持的协议。

协议、传输方式与安全层属于不同配置维度，应按服务器提供的信息组合使用。VMess、VLESS 和 Trojan 是常见代理协议，REALITY 则是安全层方案，不是一个可单独替换所有协议的选项。VLESS 配置可能与 REALITY 配合，也可能使用其他安全层。导入后要核对地址、端口、用户标识、传输方式及安全参数；服务器要求的服务器名称、公钥或短标识缺失时，即使条目能够保存，也可能无法完成连接。不要为了测试而随意关闭证书验证。

系统代理和 TUN 主要决定流量如何进入客户端，路由分流决定进入后交给哪个出站。系统代理适合遵循系统代理设置的浏览器及应用，但部分软件会忽略它；TUN 通过虚拟网络接口接管符合条件的流量，通常涉及额外权限、路由和 DNS 设置。分流规则则可将特定域名、地址或端口交给直连、代理或阻断出站。新手先用系统代理验证基本连接，再按应用需求考虑 TUN，不必同时改动所有选项，以免无法判断故障来源。

已确认设备是 64 位 ARM 架构时，优先选择 arm64；不确定架构或遇到兼容问题时，可选择 universal 通用包。2015 年后推出的主流手机多采用 64 位 ARM 处理器，但处理器能力与系统实际运行架构并不总是一致，不能只看购买年份。可在设备规格或系统信息中查找架构说明。出现无法安装时，还要排除下载中断、存储空间不足、系统版本不满足要求和已安装应用签名不同等原因；不要先删除原应用，以免丢失配置。

先分清输入类型，再检查内容是否完整。以协议名称开头的分享链接通常用从剪贴板导入功能处理；订阅地址应添加到订阅分组，然后执行更新。复制时不要带上说明文字、引号、换行或聊天软件自动添加的省略内容。若导入后没有条目，查看提示是否涉及格式解析或不支持的字段，并确认客户端与内核支持该配置。网页登录地址不一定是订阅接口地址，需要回到服务管理页面重新复制。不要把含凭据的完整链接贴到公开求助区。

先看更新日志区分网络请求失败与内容解析失败，再选择对应检查项。请求失败时核对订阅地址是否过期、设备时间是否准确，以及更新是否依赖当前已经失效的代理；v2rayN 可尝试更新订阅时不通过代理，但前提是当前网络能直接访问该接口。解析失败时检查返回内容是否其实是登录页、错误页或不兼容的订阅格式，并联系服务提供方确认。先保留原分组再重试，避免清空仍可用的配置；也不要把所有问题都归结为 Base64 编码。

先确认普通代理能够正常工作，再处理 TUN 的权限与虚拟接口问题。Windows 按客户端提示检查是否需要管理员权限；macOS 和 Linux 的桌面版本按实际安装方式检查辅助服务、授权或网络接口创建提示，不要直接照搬其他平台的操作。Android 通常会请求 VPN 连接授权，拒绝后需要重新允许。与此同时，退出其他正在接管网络的 VPN 或 TUN 工具，避免接口和路由冲突。授权成功仍不能连接时，保存日志并检查路由与 DNS，而不是持续提升权限。

先检查系统代理指向的本地地址和端口是否与客户端监听设置一致，再确认内核已经启动。v2rayN 的自动配置系统代理会写入系统设置，清除系统代理会移除对应设置，而不改变系统代理通常只保留原有状态。浏览器扩展、独立代理选项或企业策略可能覆盖系统配置，应暂时停用冲突项并重启浏览器测试。注意 SOCKS 与 HTTP 端口不能随意互换，部分版本提供混合端口。Android 的常用接管方式是应用内 VPN 授权，不应照搬桌面的系统代理检查路径。

先看规则集的实际匹配范围，而不是仅凭模式名称决定。绕过大陆通常将特定中国大陆域名和地址交给直连，其余流量按默认出站处理；黑名单模式通常只代理规则中指定的目标；全局模式常用于让大部分流量经过所选代理，以便做对照测试。具体默认规则与例外项会随客户端配置而不同，全局也不代表忽略所有本地地址保护。日常使用应保留局域网和私有地址直连，修改自定义规则后检查优先顺序，避免宽泛规则抢先匹配。

延迟测试只说明某种测试条件下的可达性，不能替代实际应用验证。选中服务器并启动内核后，先确认系统代理或 VPN 接管已经启用，再用浏览器打开一个已知可访问的 HTTPS 页面，并查看客户端日志是否出现对应请求及预期出站。若还需验证 UDP 或特定应用，应分别测试，不要用网页结果推断所有流量都正常。比较直连与代理结果时尽量使用同一目标和相近时间，并关闭其他代理工具。分享排查信息时记录错误类型即可，不必公开服务器凭据。

先备份可恢复的用户配置，再升级或迁移。重点包括订阅分组、手动添加的服务器、自定义路由、DNS 设置及本地监听端口；可使用客户端提供的导出或备份功能，并将文件保存在受保护的位置。备份可能含订阅凭据和服务器认证信息，不能当作普通截图公开分享。升级后先检查配置是否正确读取、内核是否可启动，再逐项恢复自定义设置。切换到不同客户端时，部分专属字段不能直接迁移，应重新核对；确认新环境可用后再处理旧设备上的配置。

先做最小范围对照，判断是单条配置失败还是所有配置都失败。只有一个条目超时时，检查服务器地址、端口、服务期限及认证字段，并向服务提供方确认服务状态；全部超时时，先确认本地网络能够访问普通网站，再查看客户端内核启动日志、系统时间与安全软件的拦截记录。可切换到另一条有权使用的已知可用配置进行对照。注意 TCP 延迟可测不代表协议握手成功，某些测试方式也可能被服务器限制；不要因一次超时就反复更换所有协议参数。

已连接通常表示内核或 VPN 接口已经启动，不保证远端服务、分流和 DNS 都正常。先查看访问网页时日志中是否产生请求；没有请求时检查应用是否进入客户端，包括系统代理、浏览器独立设置或 VPN 接管范围。有请求但失败时，根据错误继续检查握手、域名解析或出站路由，并用另一条已知可用配置对照。若只有部分网站失败，检查是否被规则误判为直连，以及目标服务本身是否异常。一次只调整一个环节，记录修改前后的结果，避免同时改端口、DNS 和路由。

先确认失败发生在系统、客户端还是远端解析环节，再决定是否更换 DNS。检查设备是否已完成当前网络的登录认证，以及客户端填写的 DNS 地址是否可达；使用加密 DNS 时，还要检查服务器名称、访问路径和请求所走的出站。TUN 场景中，DNS 接管与路由不一致可能造成请求回环或流向错误，FakeDNS 也不能只凭名称随意开启。可暂时恢复客户端默认 DNS 配置做对照，再逐项恢复自定义项。不要仅用直接打开网站 IP 的结果判断 DNS，因为 HTTPS 与虚拟主机可能依赖域名。

先区分单个目标缓慢、单条配置缓慢与整个网络不稳定，再做同条件对照。暂停后台下载，比较同一目标在不同网络及不同可用配置下的表现，同时记录发生时间和客户端错误类型。Android 若在锁屏后才断开，检查电池优化、后台运行权限以及 VPN 是否被其他应用替换；桌面设备则关注休眠恢复、网络切换和其他代理工具冲突。吞吐速度受本地链路、远端负载与目标站点共同影响，单个延迟数字不足以判断。频繁掉线时优先收集日志，不要立即改动 MTU 等进阶参数。