V2Ray 常见问题
安装、订阅与连接排查

V2Ray 通常指 Project V 生态中的代理内核与相关项目；V2Fly 延续这一内核家族，Xray 是另一条发展分支。v2rayN 则是图形客户端，负责导入配置、选择服务器、设置路由并调用内核。界面能导入某种链接，不等于当前内核一定支持其中全部参数。排查兼容性时，要同时记录客户端版本、实际调用的内核及其版本，再核对协议、传输与安全设置。

Windows、macOS 与 Linux 桌面端优先看 v2rayN，按系统和处理器选择对应安装包。Android 通常先用 v2rayNG；需要 V2Fly 内核配置时，再考虑 v2flyNG。选择依据是现有配置要求，而不是客户端名称是否相近。尤其要注意，依赖 Xray 特定功能的配置不能直接视为兼容 V2Fly。换客户端前先导出必要配置，并确认订阅提供方给出的目标客户端和格式。

客户端提供的是配置管理和连接功能，安装完成不会自动生成可用服务器。需要导入自行管理或经授权取得的分享链接、配置文件或订阅地址。分享链接通常对应单项配置，订阅地址则用于获取可更新的配置集合。拿到资料后先区分类型，再使用对应导入入口；把订阅地址直接当服务器地址填写，通常得不到有效配置。订阅链接可能包含访问凭据，不要贴进公开截图或讨论区。

不是。VLESS 是代理协议，REALITY 是 Xray 提供的一种传输安全机制，两者可以组合使用，并非二选一。配置还可能包含传输类型、服务器名称、公钥、指纹与 shortId 等参数，需与服务端要求对应。不要只把协议下拉框改成 VLESS 就认为转换完成，也不要把普通 TLS 配置随意改为 REALITY。选择类型时以完整分享链接和服务端说明为准；涉及内核差异时再查协议手册。

多数较新的 Android 手机可先选 arm64，安装包通常更小；universal 包含多种架构支持，适合不确定设备架构时使用。不过，处理器支持 64 位不代表系统一定采用 64 位运行环境，部分旧设备仍可能需要通用版。若 arm64 提示与设备不兼容，可核对系统架构后改用 universal。解析安装包失败还可能与系统版本、下载未完成或签名冲突有关，不应一律归因于架构。

先确认填入的是订阅接口地址，而不是账户网页、说明页或单条分享链接，并检查复制时是否混入空格或漏掉查询参数。在 v2rayN 中保存订阅分组后，还需要执行更新订阅；在 v2rayNG 中也要触发订阅更新。随后查看更新提示与日志，区分请求失败和解析失败。前者检查访问路径与地址有效期，后者核对返回格式。已有条目但界面为空时，再检查当前分组筛选是否隐藏了结果。

重新复制完整链接，尽量使用纯文本来源，避免聊天软件把链接拆行、添加省略号或附上中文标点。确认链接类型与客户端当前版本匹配，尤其是带新传输参数的配置。订阅网址应放进订阅管理入口，不要与分享链接导入混用。若提示参数缺失，向配置提供方索取完整原文，不要凭猜测补公钥或用户标识。手动录入时逐项核对协议、端口、传输和安全设置，导入成功后再测试连接。

桌面端创建虚拟网络接口和修改路由通常需要较高权限，先按当前系统与客户端说明完成授权；Windows 可在确认程序来源后尝试以管理员身份运行。再退出其他正在接管网络的隧道工具，避免路由或接口冲突。Android 上则需接受系统的 VPN 连接授权，并留意其他 VPN 是否正在运行。不要把关闭安全防护当成常规步骤；若仍失败，查看日志中的具体接口、驱动或路由错误，再针对处理。

系统代理主要服务于遵循系统代理设置的应用；TUN 在网络层接管匹配流量，适合不读取系统代理的程序；路由规则决定进入内核后的连接走哪个出站。三者处理的是不同环节。首次配置时先用系统代理验证浏览器访问，再按实际需求启用 TUN，避免同时改变多个变量。启用 TUN 后仍需检查 DNS 和路由规则，不能把接管流量等同于全部走代理，也不要默认所有系统上的菜单与行为完全一致。

先区分测试项目：TCP 连接测试只能说明端口建立连接的情况，实际请求测试才会涉及更多协议握手与目标访问过程，下载测试还受带宽和测试目标影响。测试通过并不保证所有网站都可用，单次超时也不能直接判定配置失效。先固定同一服务器、同一路由和同一目标重复验证，再对照内核日志。浏览器额外使用的代理扩展、安全 DNS 或缓存，也可能让它与客户端测试走不同路径。

在支持自动更新的客户端中，为对应订阅分组启用更新并设置合适间隔，随后观察一次实际更新是否完成。程序退出或手机进入后台限制状态时，更新任务不一定按时运行。订阅条目通常由远端内容重新生成，直接修改其中参数可能在下次更新时被覆盖。需要长期保留的定制项，可复制到独立的手动分组，再明确区分来源。订阅凭据更换后要更新地址，单纯重复刷新旧地址不会解决授权失效。

不建议把整个目录跨系统覆盖。不同客户端的数据库、文件路径、接口名称和路由设置可能不同，同一订阅也可能返回面向特定客户端的内容。优先在各端分别添加兼容的订阅，或使用客户端支持的导入导出功能迁移必要配置。系统代理、TUN、DNS 与应用分流应在目标设备重新检查。备份文件可能包含服务器凭据和订阅令牌，应存放在受控位置；同步后先单独验证，再替换原来的可用配置。

先区分内核启动成功和远端访问成功，两者不是一回事。确认已选择服务器，再检查浏览器是否使用系统代理、客户端是否设置了相应代理模式，以及本地监听端口是否冲突。接着暂时停用浏览器代理扩展，使用同一目标重试，并查看内核日志中的连接与 DNS 错误。若只影响部分网站，再核对分流规则和浏览器安全 DNS。每次只改一项，保留原设置，避免同时更换服务器、DNS 和路由后失去排查线索。

先确认设备本身能正常访问网络，再核对服务器地址、端口与订阅是否过期。开启系统自动校时，检查当前内核是否支持配置要求，并对照传输、安全类型与服务器名称等参数。查看日志，区分域名解析失败、建立连接超时和握手失败，处理方向并不相同。若仅一条配置失败，可请提供方确认服务端状态；若多条同时失败，应优先排查本地网络、代理链与防火墙规则，不要通过随意关闭证书验证来绕过报错。

系统代理并不覆盖所有应用，一些程序使用独立网络栈或自行保存代理设置。先用遵循系统代理的浏览器验证，再查看目标应用是否提供 HTTP 或 SOCKS 代理选项，并按客户端实际监听的类型与端口填写。浏览器扩展、企业策略或其他代理工具也可能覆盖系统设置。确实需要网络层接管时再评估 TUN，并检查是否存在绕过规则。不要把监听地址扩大到局域网作为修复办法，这与应用是否读取代理设置无关。

已有配置可用只说明当前服务器连接正常，订阅接口的访问路径、授权和响应格式仍可能有问题。先看更新提示：授权错误需核对订阅凭据，超时需检查接口可达性，解析错误则要确认返回内容是否是客户端支持的格式。若客户端提供直连更新和经代理更新两种方式，可在保留可用服务器的前提下分别尝试，并确认代理已真正运行。不要先清空全部配置；记录失败时间与脱敏后的错误信息，便于继续定位。