v2rayN 与 v2rayNG
常见问题

桌面设备先选 v2rayN，再按 Windows、macOS 或 Linux 选择安装包；Android 通常先选使用 Xray 内核的 v2rayNG，需要 V2Fly 内核时再考虑 v2flyNG。客户端名称相近，但不是同一个应用的不同皮肤。选择时还要核对配置需要的协议、传输方式和安全参数，尤其不要默认两条内核分支支持完全相同的功能。迁移之前保留原配置，新客户端完成导入并验证连接后，再决定是否移除旧客户端。

客户端负责读取配置、运行代理内核和处理本机流量，本身不等于可连接的服务器。订阅地址通常用于获取一组服务器配置，单条分享链接则一般只包含一项配置；两者都需要来自有权使用的服务。导入后应检查列表是否出现服务器，再选定活动项并启动连接。订阅地址可能包含访问凭据，不要贴到公开评论、截图或在线解析工具中。遇到故障求助时，只保留错误类型和必要设置，先遮盖地址、用户 ID 及订阅参数。

VLESS 是代理协议，REALITY 属于传输层安全相关机制，Xray 则是执行配置的内核，三者不是互相替代的客户端名称。实际连接还涉及传输方式、端口、流控以及服务端提供的安全参数。配置标注 REALITY 时，应确认所选客户端和内核支持对应功能，再核对公钥、服务器名称、短 ID 等项目。不要只把安全选项改成 REALITY 就尝试连接，也不要把普通 TLS 的配置直接套用过来；具体字段应以服务端提供的配置为准。

多数近年的 Android 手机可先选 arm64，它面向对应的处理器架构，安装包通常比通用版小。universal 包含多种架构所需的组件，适合无法确认架构时使用，但不是功能更多的高级版。仅凭手机购买年份不能准确判断架构，旧设备或特殊设备应查看系统信息。安装提示不兼容时，先核对系统版本、架构和存储空间；若提示签名冲突，不要立刻卸载原应用，应先备份配置，并确认新旧安装包是否属于同一客户端及可覆盖安装的发布来源。

先区分订阅地址与单条服务器分享链接，分别使用订阅分组和从剪贴板导入等对应入口。复制时检查首尾空格、换行和聊天软件附带的文字，确认复制的是完整地址，而不是订阅管理网页的地址。若已建立分组但服务器列表为空，可手动更新一次并查看日志：获取失败优先检查网络、地址有效期和访问权限，解析失败则核对返回内容格式及客户端兼容性。网页能打开不代表内容一定是有效订阅，也可能返回登录页面或错误说明。

先保留现有服务器列表，不要为重试而清空所有配置。检查订阅是否到期、地址是否变更，以及设备日期和时间是否准确，再从日志判断是连接超时、证书错误还是服务器返回拒绝访问。如果客户端提供通过代理更新订阅的选项，确认所用活动服务器确实可连接；若更新正依赖已失效的服务器，可在允许的网络条件下尝试直接更新。每次只改一项并记录结果。持续失败时向订阅提供方确认状态，反复点击更新通常不能解决权限或地址失效问题。

先确认服务器已设为活动项且内核正常启动，再在系统代理菜单选择自动配置系统代理。启动内核与修改系统代理是两个动作，不能只看主窗口是否打开。随后检查系统代理设置中的地址和端口是否与客户端本地监听一致，浏览器是否使用系统代理，以及是否有其他代理工具或扩展覆盖设置。部分应用不读取系统代理，需要在应用内部配置代理或使用适合的流量接管方式。退出客户端后若网络异常，检查是否残留了指向已关闭本地端口的代理设置。

先关闭 TUN，确认普通代理方式能够正常连接，避免把服务器故障误判成权限问题。TUN 涉及虚拟网络接口和路由设置，所需权限取决于系统与客户端版本；Windows 可按客户端提示授予管理员权限，其他桌面系统按对应版本的授权说明操作。若日志提示接口创建失败，再检查虚拟网卡组件、安全软件拦截和其他隧道工具冲突。不要为了排查长期关闭防火墙。测试时仅运行一个接管流量的工具，成功后再检查 DNS 与路由是否符合预期。

系统代理通常只是告诉遵循该设置的应用，把请求交给本地代理端口；TUN 通过虚拟网络接口接管符合规则的流量，影响范围更广。Android 客户端常用 VpnService 建立本地流量转发入口，首次连接需要系统授权，这不代表客户端自动获得了服务器配置。三种方式都仍受路由、DNS 和应用自身行为影响。日常浏览可先用满足需求的简单方式；需要覆盖不读取系统代理的应用时，再评估 TUN 或移动端的接管设置，不必一开始就叠加所有模式。

先按实际访问需求选择路由：绕过大陆通常根据域名和 IP 规则将匹配流量直连，其余交给代理；全局代理通常用于让已进入客户端的流量优先走代理，但不能保证接管所有应用。排查时可以临时切换全局代理，观察同一目标是否恢复，再判断是否为分流规则问题。切换后最好重新建立连接，因为已有连接可能沿用旧路径。若只有个别域名异常，应检查规则顺序、规则资源和 DNS 结果，而不是把全局代理长期当作所有故障的通用修复。

启用分应用功能后，先确认当前模式的含义：绕行模式通常让选中的应用不进入代理通道，仅代理模式则通常只让选中的应用进入通道，具体以当前界面说明为准。先用一个容易验证的应用测试，再逐步增加列表，避免一次选择过多后难以判断效果。修改后应重启客户端连接，并关闭目标应用后重新打开。系统组件、下载服务或由其他应用代发的请求可能不完全跟随前台应用的选择，因此需要结合日志和实际请求验证，不能只凭勾选状态判断。

先确认主机自身可用，再开启允许来自局域网的连接，核对实际监听协议与端口，并在主机防火墙中仅向可信局域网放行对应入站连接。其他设备填写主机的局域网 IP 和代理端口，不能填写只代表设备自身的 127.0.0.1。两端还应处于能相互访问的网络，访客网络和无线客户端隔离可能阻断连接。不要把本地代理端口直接映射到公网。使用结束后可关闭共享；主机休眠、地址变化或客户端退出都会使其他设备的代理连接中断。

先看日志是否能解析服务器域名，再判断是否能够建立到目标地址和端口的连接；域名解析失败与连接超时不是同一类问题。核对端口、传输方式、系统时间及服务状态，再用另一个已知可用的配置做对照。有条件时可切换手机热点测试，但不要同时更改多项参数。若所有配置只在同一网络超时，优先检查该网络、防火墙和本机接管设置；若只有一项持续失败，应联系配置提供方确认服务端状态。延迟测试失败本身不能完整证明实际业务连接不可用。

已连接可能只表示本地服务启动或系统隧道建立，并不代表目标网站请求成功。先选择一个普通 HTTPS 页面测试，再看客户端日志中是否出现该请求：没有记录时检查系统代理、浏览器设置、分应用列表或 TUN 接管范围；有记录但连接失败时检查活动服务器及协议参数；只有域名访问失败时继续检查 DNS。测试期间先关闭其他代理工具和可能覆盖代理的浏览器扩展。每次变更后重新加载页面或重建连接，避免缓存与旧连接干扰判断，不要一次重置全部设置。

可能，但也可能是路由规则、目标站点限制或服务端连接失败。先记录具体域名和报错，再查看日志中的解析结果、匹配规则与出站选择。如果同一域名在直连和代理路径表现不同，应检查客户端 DNS、系统 DNS 及浏览器加密 DNS 的组合，确认是否绕过了预期解析路径。不要随意填写来源不明的解析地址，也不建议用直接访问 IP 代替 HTTPS 域名测试，因为证书和站点托管方式可能使结果失真。调整一项后清理相关缓存或重启连接，再重复相同测试。

先在系统电池统计中确认耗电是否确实集中在客户端，并区分持续大流量传输与频繁重连。若只在锁屏后断开，检查后台运行限制、自启动权限和电池优化设置；需要长期连接时，可按系统选项允许后台活动，但这可能增加待机耗电。不要同时运行多个占用系统 VPN 通道的应用。若连接频繁重建，再核对无线网络切换、服务器稳定性和日志中的错误，避免仅靠保活掩盖链路故障。调整后用相近使用场景观察一段时间，不要只比较一次短时电量变化。