V2Ray 常见问题
订阅、代理与 TUN

先区分内核与图形客户端。V2Ray 属于 Project V 生态，V2Fly 维护相关内核；Xray 是另一条内核分支，协议和传输能力随版本演进。v2rayN 提供桌面图形界面，用于管理订阅分组、服务器和路由，并调用所选内核运行连接。判断一个配置能否使用，要同时核对客户端能否解析链接、内核是否支持配置字段。不能仅凭客户端名称判断 REALITY 或某种传输方式一定可用。

客户端负责读取配置和建立连接，不会因安装完成就自动获得可用服务器。订阅地址是获取一组服务器配置的入口，通常由配置提供方交付，也可能包含账户标识。取得地址后，在订阅分组中保存，再执行更新订阅；只有地址而未更新，服务器列表可能仍为空。先确认服务状态与有效期，再处理客户端设置。不要把完整地址发到公开讨论区，排查截图时也要遮住查询参数和个人标识。

订阅地址通常通过网络返回一批配置，适合用订阅分组持续管理；单个节点分享链接描述一项服务器配置，常见前缀包括 vmess://、vless:// 和 trojan://。不要仅凭二维码外观判断类型，应先检查解码后的内容。单个链接通常通过从剪贴板导入等入口添加，订阅地址则保存到订阅分组。手动导入的节点不一定随订阅更新而变化，提供方更换端口或认证参数后，需要重新导入或核对字段。

不是。系统代理用于向遵循系统设置的应用提供本地代理入口；全局路由决定进入内核的请求通常走哪个出站；TUN 则借助虚拟网络接口接管符合条件的流量。开启全局路由不会让忽略系统代理的应用自动进入内核，开启 TUN 也不代表每条路由都会走代理。先确认应用流量如何进入客户端，再检查路由出口。首次验证优先只启用一种接管方式，避免多个入口和其他网络工具同时生效。

先查看设备处理器架构，而不是只看 Android 版本。较新的主流手机通常适合 arm64 包，体积一般比通用包小；无法确认架构或安装时提示不兼容，可选择 universal，但通用包仍受最低系统版本等条件限制。桌面设备也要对应选择架构，Apple Silicon 与 Intel 安装入口不能混用。升级前保留订阅地址和必要设置，通过下载中心选择对应平台，不要为解决架构问题随意覆盖来源不明的安装文件。

先检查复制内容是否为完整订阅地址，去掉前后空格、换行和聊天软件附加的文字。打开订阅分组设置，确认地址填入可选地址 Url，分组已启用，再执行更新订阅。若提示解析失败，返回内容可能是登录页面、错误提示或不兼容的订阅格式，应向提供方确认客户端适用格式。若更新提示成功但没有节点，清除分组筛选和过滤正则后再检查。不要通过反复新建同名分组掩盖原始错误信息。

先在当前网络下尝试更新全部订阅(不通过代理)，记录日志中的网络错误或 HTTP 状态。若地址必须经已有可用代理访问，再选择更新全部订阅(通过代理)，前提是当前活动节点和本地代理确实可用。不要依赖一个已经失效的节点去更新同一份订阅。认证失败、地址过期或服务端返回错误内容，通常不是切换更新方式就能解决的。逐项核对地址、服务状态与返回格式，分享日志前隐藏订阅参数。

先确认内核已经启动、本地监听端口存在，再核对系统代理指向的地址与端口是否和客户端设置一致。随后检查浏览器是否使用独立代理配置、扩展规则或已有的直连例外；部分应用根本不读取系统代理。可以完全退出浏览器后重新打开，并用同一测试地址对照客户端日志。若系统代理被其他网络工具反复改写，先退出冲突工具再设置。系统代理只负责入口，是否走代理仍取决于内核中的路由规则。

先关闭 TUN，阅读日志确认是权限、虚拟接口创建还是路由添加失败。Windows 通常需要管理员权限；macOS 与 Linux 需要按当前客户端版本的提示完成授权或服务设置，不能把所有报错都归为权限不足。Android 首次连接需确认系统 VPN 授权，并检查是否已有其他应用占用 VPN 通道。授权后仍失败，应核对组件是否齐全以及安全软件拦截记录。暂时改用系统代理验证节点，避免把权限故障误判为订阅失效。

TCPing 主要观察到服务器端口的 TCP 建连情况，不能证明认证、传输握手和目标请求都成功。真连接延迟会通过节点向测试地址发起实际请求，更贴近使用链路，但也受测试地址可达性、路由和网络负载影响。先确认测试地址与测试设置一致，再比较不同节点；不要把某一次较小结果当作稳定速度结论。TCPing 正常而真连接延迟失败时，继续查协议参数、TLS 握手和测试目标，不要只检查服务器端口。

先切到对应订阅分组，查看更新结果，再确认服务器列表中的活动项。订阅更新可能改变名称、地址或排序，不能把原来的行位置当作同一节点的标识。选择需要使用的服务器并设为活动服务器，检查日志是否重新加载配置；必要时停止后重新启动连接。不要同时手动修改订阅节点又期待修改永久保留，因为后续更新可能覆盖这些字段。需要长期保留自定义参数时，另存独立配置，并明确区分其维护来源。

先固定一个测试域名，检查它是否命中预期规则以及规则指向的出站标签是否存在。路由通常按顺序匹配，宽泛规则放在前面可能遮住后面的细分规则。域名策略 AsIs、IPIfNonMatch 和 IPOnDemand 会影响匹配过程中是否触发解析，也会影响基于 IP 的规则判断。结合日志中的目标和出站观察结果，不要只看浏览器页面是否打开。修改后重新加载配置，并使用新请求测试，已有长连接可能继续沿用原来的路径。

先在未开启代理时记录测试页面显示的出口 IP，再启用代理访问同一页面，并对照客户端日志中的请求与出站。测试目标应属于预期走代理的规则范围，否则出口不变可能只是正常直连。浏览器结果只能说明该浏览器的请求路径，不能推断所有应用都已接管。若结果不一致，逐项检查系统代理、应用独立代理、路由与 TUN 状态。更改设置后用新标签页或新连接复测，避免缓存和旧连接干扰判断。

先保留当前错误信息，再用同一网络测试另一个已知可用的节点，区分单节点故障和整机链路问题。单个节点失败时核对地址、端口、认证参数与服务状态；全部失败时检查本机网络、DNS、防火墙和当前活动内核。先测试端口再做真连接延迟，可帮助缩小故障范围，但端口可达不等于协议可用。不要同时改端口、传输和安全设置。每次只调整一项并复测，才能判断变化是否有效，并保留可恢复的原配置。

先关闭系统代理和 TUN，确认普通网络能够访问原本可达的网站；基础网络异常时先处理网络。随后启动内核，查看是否有启动失败或监听错误，再对活动节点执行真连接延迟。节点测试通过后，仅开启一种接管方式，核对应用请求是否进入日志。请求进入但目标无法访问，再检查路由、DNS 与目标站点状态。连接图标往往只表示运行状态，不代表每次请求成功。不要一开始就删除全部配置，先用最小设置复现问题。

先区分启动阶段与连接阶段。内核启动失败时读取最早的错误行，检查端口占用、JSON 语法、未知字段或所选内核不支持的协议；不要只看最后一行退出提示。连接阶段出现 TLS 或 x509 错误，先同步系统日期与时区，再核对 SNI、证书域名及提供方要求的安全参数。不要把跳过证书验证当作常规修复。若需分享日志，只截取相关时间段，并遮住地址、用户标识和订阅参数，保留错误关键词。