V2Ray 常见问题
配置与连接排查

先按设备系统缩小范围：Windows、macOS 与 Linux 桌面使用 v2rayN；Android 通常先选采用 Xray 内核的 v2rayNG，需要 V2Fly 内核路线时再考虑 v2flyNG。同一客户端的功能还会随版本与内核变化，不能仅凭名称判断协议兼容性。已有配置时，先确认配置提供方要求的协议、传输与安全参数，再核对客户端是否支持这些组合；不要把更换客户端当作解决所有连接问题的第一步。

客户端负责图形界面、配置管理与代理开关；内核负责按配置处理连接、路由和协议。节点是一组远端连接参数，订阅则是用于获取或更新这些参数的地址。安装客户端并不等于已经拥有可用节点，界面能够启动也不代表内核与远端连接正常。排查时要分清问题发生在界面操作、内核启动、订阅获取还是节点连接阶段。订阅地址可能包含访问凭据，应像账户信息一样保管，不要公开到截图或讨论区。

不能直接互换。VMess、VLESS 与 Trojan 属于不同的代理协议；REALITY 是一种安全层方案，不是与它们并列的独立节点协议。连接能否建立，取决于客户端与服务端的协议、传输、安全层及相关字段是否一致。只改协议名称或打开某个开关，通常不会得到可用配置。优先导入配置提供方给出的完整链接，手动编辑前备份原配置，并逐项核对端口、用户标识、服务器名称及公钥等适用字段。

系统代理向操作系统登记代理地址，主要影响愿意读取该设置的应用；TUN 通过虚拟网络接口接管符合路由条件的流量，覆盖范围更广，也更依赖权限、路由和 DNS 配合。首次使用建议先关闭 TUN，用系统代理验证一条配置是否可用，再处理不遵循系统代理的应用。TUN 不是连接质量增强开关，也不保证接管所有流量。切换方式时一次只改一项，避免与其他虚拟网卡或代理程序同时接管网络。

确认设备支持 64 位 ARM 应用时，优先选择 arm64；无法确认架构时，可以选择包含多种架构组件的 universal 通用包。通用包通常体积更大，但不会因此让连接更快。不能只按购买年份判断，部分设备的处理器支持 64 位，系统却仍使用 32 位运行环境。若提示应用不兼容，先核对系统要求、设备架构和安装包来源；若提示签名冲突，应先备份配置，再确认已有应用是否来自同一发布渠道。

先区分订阅地址与单条节点分享链接：订阅地址应添加到订阅分组，单条链接应使用从剪贴板导入等对应入口。复制时检查首尾空格、换行和截断，确认拿到的是原始地址而非网页标题或登录页面。添加分组后通常还需执行更新，节点才会出现。若能获取内容却无法解析，可能是返回格式不兼容或返回了错误页面；向提供方确认适用客户端与输出格式。不要为排查而把完整订阅地址提交给陌生转换网站。

先记录错误提示，再按系统、处理器架构和安装包类型核对运行要求。压缩包应完整解压到可写目录，不要直接在压缩软件里启动；安装包则按提示完成安装。Windows 的桌面版与 WPF 版使用不同界面技术，所需运行环境应以对应发布说明为准，不能把所有启动错误都归为同一种运行库缺失。若曾经正常运行，先退出残留进程并备份配置，再尝试独立目录中的新配置，区分程序问题与旧配置问题。

桌面端先查看日志中的具体失败环节，再按当前系统与客户端要求授予管理员权限或网络扩展权限；不要长期关闭系统安全防护。Android 需要确认系统 VPN 授权，且通常不能同时运行另一个占用该通道的应用。若此前可用，检查是否有其他 VPN、虚拟网卡工具或安全软件改变了网络环境。关闭其他接管程序后重新启动客户端，仍失败时先退回系统代理验证节点，避免把权限错误误判为服务端故障。

订阅获取与节点连接是两条不同的请求链路，旧节点可用不代表订阅地址一定可访问。先保留现有配置，确认地址未过期、凭据未撤销，再检查更新日志中的超时、拒绝访问或解析错误。若客户端提供通过代理更新与直接更新两种方式，可在已有可用节点的前提下分别尝试；不同版本的入口名称可能不同。返回登录页面或拒绝访问时，应向提供方确认权限，不要反复删除分组，也不要频繁连续更新。

日常使用可先采用规则分流，让不同目标按规则选择直连、代理或阻断。全局模式适合临时对照测试，但其含义取决于客户端当前配置，并不等于所有应用流量都已进入客户端；接管范围仍由系统代理、应用代理或 TUN 决定。切换后重新发起请求，必要时关闭应用中的旧连接，因为已建立的连接可能继续沿用原路径。若只有规则模式失败，应查看匹配规则与 DNS 结果，而不是先更换节点。

不可以。TCP 连通测试通常只说明指定地址与端口能够建立连接；实际请求测试还会受到测试目标、TLS、DNS 与服务端策略影响。某项测试失败，不能单独证明节点完全不可用；显示有响应，也不代表所有网站与应用都能正常访问。应使用自己的常用目标做小范围验证，并结合日志观察失败阶段。批量测试可能产生额外流量或触发服务限制，建议减少并发，优先比较同一环境下的结果，而不是追逐单个数字。

先使用客户端提供的导出或备份功能，另外记录当前内核、代理模式、监听端口与自定义规则。若需要复制配置目录，先正常退出客户端，避免复制到尚未写入完成的文件。备份中可能含节点凭据和订阅地址，应存放在受控位置，分享日志或配置前移除敏感字段。每次只修改一类设置，保存后重新测试同一目标，并记下结果。恢复时确认客户端版本与配置格式兼容，不要只把某个内核 JSON 覆盖回图形客户端的管理数据库。

先关闭代理确认基础网络可用，再检查系统时间、节点地址、端口和当前网络是否需要网页认证。查看日志：解析失败应先检查 DNS，建立连接超时则关注目标地址、端口与网络路径，握手失败再核对协议、安全层及身份字段。用同一节点在另一条获授权的网络上测试，或在当前网络测试另一条已知可用配置，可以缩小范围。不要一开始就同时修改 DNS、路由和协议；连续改动会让原始故障与新问题混在一起。

已连接可能仅表示内核已启动或系统 VPN 通道已建立，不等于远端请求已经成功。先用浏览器访问明确的测试目标，同时查看客户端是否产生对应连接日志。没有日志时检查应用是否进入代理；有日志但域名解析失败时检查 DNS；出现证书或握手错误时核对系统时间与安全参数。再临时用另一种路由模式对照，判断是否为规则误匹配。若关闭代理后仍无法上网，先恢复基础网络，退出其他接管程序并检查遗留代理设置。

并非所有应用都会读取操作系统的代理设置，有些使用自己的代理选项，有些只在启动时读取，还有些流量类型不适用普通 HTTP 代理。先检查客户端是否确实写入系统代理，并核对监听地址与端口；再完全退出目标应用后重新打开。若应用支持手动代理，按客户端提供的协议与端口填写，不要混用 HTTP 与 SOCKS。确需更广范围接管时再评估 TUN，并检查应用排除列表和路由规则，不要只凭系统代理开关判断流量路径。

先确认受影响的是某个域名、某类应用还是全部连接，并记录日志中的解析结果与匹配出站。应用、系统和内核可能各自参与解析，开启浏览器的加密 DNS 后，请求也未必经过预期的内核 DNS 链路。逐项核对 DNS 服务器是否可达、解析请求如何出站、路由使用域名还是 IP 匹配，以及是否存在过期缓存。调整后重新建立连接再测试。FakeDNS、IPv6 与域名解析策略会相互影响，不建议为了单个失败域名一次开启所有高级选项。