v2rayNG 常见问题

Windows、macOS 与 Linux 桌面环境选择 v2rayN；Android 通常先选使用 Xray 内核的 v2rayNG。v2flyNG 是使用 V2Fly 内核的备选客户端，是否适合取决于订阅提供的协议与传输组合。不要只看应用名称判断兼容性，应核对节点要求和客户端实际支持的字段。已有可用配置时，先保留原客户端，再测试替代客户端；不同客户端的设置备份不一定可以直接互相恢复。

客户端负责读取配置、运行内核和转发流量，安装完成并不等于已经具备可连接的服务。还需要有效的订阅地址、节点分享链接，或服务端对应的完整参数。先确认配置来源和使用权限，再导入节点并选择一个作为活动配置。订阅可能包含个人访问凭据，不要把地址发到公开讨论区。排查时可以说明协议、传输方式和报错类型，但应遮盖地址中的令牌、用户标识及其他认证内容。

协议描述客户端与服务端如何交换代理数据，例如 VMess、VLESS；传输方式描述数据如何承载，例如 TCP、WebSocket；内核则是实际解析配置和建立连接的执行程序。REALITY 属于安全传输相关机制，不是可以替代所有节点参数的通用选项。同名协议也可能搭配不同传输和安全设置。导入后应一起核对协议、端口、传输、安全选项和服务端名称，不能只把协议名称改成另一种就期待连接成功。

三者作用不同。系统代理向遵循系统设置的应用提供代理入口；路由分流决定进入内核的连接应该使用哪个出站；TUN 通过虚拟网络接口接收流量，覆盖范围通常比系统代理更广，但仍受路由、权限和应用设置影响。启用系统代理不代表所有应用都会使用代理，启用 TUN 也不代表每条连接都走代理出站。初次配置建议先使用一种接管方式验证连接，再按实际需求调整路由与 TUN。

多数较新的 Android 手机可以选择 arm64 包，但最终应以设备支持的应用架构为准，不能只按购买年份判断。universal 包包含多种架构，通常体积更大，适合无法确认架构时尝试；它不能绕过最低系统要求。若安装提示解析失败或不兼容，先确认文件已完整下载、系统版本满足要求，再检查架构。已有应用无法覆盖安装时，还应核对包名与签名来源；卸载前先备份配置，避免丢失订阅分组和自定义规则。

先分清输入的是订阅地址还是单个节点分享链接：订阅地址应保存到订阅分组，节点链接则使用客户端对应的导入入口。复制时去除首尾空格、换行和聊天软件附带的标点，不要把网页说明地址当成订阅地址。保存分组后还需要执行更新订阅，列表才会生成。如果提示格式无法识别，确认来源提供的格式适用于当前客户端；地址能在浏览器打开，也不代表返回内容一定是节点配置，可能只是登录页或错误页。

订阅更新与节点连接访问的是不同目标，因此已有节点可用并不能证明订阅地址可访问。先保留现有节点，不要立即清空分组；检查地址是否变更、访问凭据是否失效，以及客户端日志中的状态码或解析错误。部分客户端提供直连更新与通过代理更新选项，可在已有可用连接的前提下对照测试。若返回认证失败，应向订阅来源确认权限；若返回网页内容，应确认链接是否被重定向到登录页，而不是反复导入同一地址。

桌面端 TUN 需要创建虚拟网络接口并修改相关路由，按客户端提示授予所需权限；Windows 可检查是否需要管理员权限或配套服务，其他桌面系统按各自授权流程处理。Android 首次建立本地 VPN 通道时，需要确认系统连接请求。若已有其他 VPN 应用占用通道，应先停止冲突的连接，再重试。受设备管理策略限制时，不应强行修改系统策略。授权后仍失败，应查看虚拟接口或服务启动错误，而不是持续切换节点。

系统代理主要影响主动读取该设置的应用，有些应用使用自己的网络设置，也有些连接类型不会自动经过系统代理。先用浏览器验证当前代理入口，再检查目标应用是否需要单独填写代理地址。地址和端口应读取客户端当前的本地监听设置，不要照抄其他设备的数值；同时确认应用要求的是 HTTP 还是 SOCKS 代理。确有接管更多应用流量的需求时，再考虑 TUN，并检查路由是否把目标流量设为直连。

先确认当前菜单控制的是系统代理接管方式，还是内核中的路由预设，两者不能混为一谈。路由预设中的全局代理通常把更多进入内核的连接交给代理出站；绕过大陆通常按域名或地址规则把中国大陆相关目标交给直连，具体以预设内容为准。它们都不能自动接管未进入客户端的流量。日常使用可先选符合需求的分流预设，排查单个网站时临时对照全局规则，确认后恢复原设置，不要同时修改 DNS 和多条路由。

先检查自定义规则是否位于更宽泛的匹配规则之前，以及规则引用的出站标签是否真实存在。路由通常按顺序匹配，前面的规则已命中时，后续规则不会再处理该连接。随后确认客户端获得的是域名还是 IP：域名规则无法在所有情况下匹配只有 IP 的连接，DNS 解析位置也会影响基于地址的判断。修改后应用配置，关闭目标应用已有连接再测试；部分长连接会继续沿用修改前的连接路径，不能据此判断新规则失效。

优先保存订阅分组、手动添加的节点、自定义路由、DNS 设置与应用分流选择，并记录当前使用的代理模式。客户端支持导出配置时，可使用其备份功能；备份可能包含凭据，应存放在受控位置，不要公开上传。更新后先确认原配置能正常读取，再考虑清理旧文件。跨客户端迁移时，优先使用兼容的订阅或分享链接重新导入，逐项重建本地设置，不要直接覆盖整个配置目录，以免字段差异导致启动失败。

先确认设备基础网络可用，再检查系统日期与时间是否自动同步；随后更新订阅，确认节点参数没有过期或变更。选择单个节点测试，并在相同网络下与另一个已知可用配置对照，避免把所有故障归因于客户端。接着核对协议、端口、服务端名称和安全传输参数，最后查看日志中的 DNS、连接超时或握手错误。单次延迟测试失败不足以证明节点不可用，应结合实际请求判断；若所有节点同时失败，优先检查本地网络与接管设置。

已连接有时只表示本地服务或 VPN 通道已启动，不代表远端请求已成功。先检查活动节点是否选对，再确认浏览器流量是否进入客户端；查看日志中是否出现对应访问记录。若没有记录，检查系统代理、应用独立代理或 TUN 接管范围；若有记录但报解析失败，继续检查 DNS；若出现握手或远端连接错误，则回到节点参数与服务可用性检查。一次只调整一项，并用同一个目标重复测试，避免多个设置互相掩盖问题。

先确认内核已正常启动，本地监听端口没有被其他程序占用，再检查操作系统代理设置是否指向当前客户端的地址与端口。浏览器扩展、其他代理客户端或设备管理策略可能覆盖系统设置，应逐项排除，不要让多个程序同时写入代理。关闭并重新打开浏览器后再测试，同时查看客户端是否收到请求。若停止客户端后网络反而中断，检查系统是否残留指向已关闭端口的代理设置，使用清除系统代理功能或在系统设置中恢复原状态。

DNS 错误先检查基础网络、解析服务器可达性，以及解析请求实际走直连还是代理；若只有个别域名异常，再检查对应分流规则。TLS 握手失败则优先核对系统时间、服务端名称、证书相关设置和节点安全传输参数，不能直接认定为 DNS 问题。不要把跳过证书验证当作通用修复办法。提交日志求助前，保留错误类型和前后相关行，遮盖订阅地址、认证信息及个人访问域名；完整配置也应先脱敏再分享。