V2Ray 常见问题

Windows、macOS 与 Linux 桌面使用 v2rayN，主要操作是订阅分组管理、系统代理和路由配置。Android 优先考虑采用 Xray 内核的 v2rayNG；已有配置明确依赖 V2Fly 时，再考虑 v2flyNG。名称相近不代表安装包或配置完全通用，不能把桌面安装包用于手机。先根据操作系统选客户端，再核对节点协议、传输方式与内核支持情况；不要仅凭界面相似就直接搬用整份配置。

V2Ray 通常指 Project V 生态中的代理工具与相关配置体系，V2Fly 延续其中的内核开发，Xray 则是另一条内核分支。图形客户端负责保存订阅、选择节点和生成运行配置，实际连接由内核完成。因此，界面能识别某条分享链接，并不等于当前内核支持其中的全部参数。遇到 REALITY 或特定流控无法启动时，应同时检查客户端解析结果与内核日志，而不是只看节点名称是否已出现在列表。

客户端是配置与连接工具，本身不等于可用的远端服务。连接还需要服务器地址、端口、身份信息、协议及传输参数，这些内容通常通过订阅地址或单条分享链接导入。订阅地址是用于获取一组配置的入口，不是应当填写在服务器地址栏里的内容。导入前确认来源与使用权限，导入后还要更新分组并选中节点。订阅可能包含访问凭据，不要把完整地址、分享链接或二维码发布到公开讨论区。

Mac 先打开苹果菜单中的“关于本机”：显示 Apple 芯片的设备选 Apple Silicon 对应的 arm64 包，显示 Intel 处理器的设备选 x64 包。Android 的 arm64 与 universal 是另一组安装包选择，不要与 Mac 下载入口混用。2015 年后主流 Android 手机通常可先考虑 arm64，但最终取决于设备系统支持的应用架构；较老设备或安装时提示架构不兼容，可改用通用版。通用版包含更多架构组件，通常体积更大，并不意味着连接更快。

先分清拿到的是订阅地址、单条分享链接，还是原生 JSON。订阅地址应填入订阅分组设置，再执行更新；单条分享链接应使用从剪贴板导入等对应入口；原生 JSON 则按客户端支持的自定义配置方式处理。复制时去掉前后空格、换行和聊天软件附带的说明文字。若日志提示格式无法识别，确认该地址返回的是配置内容而非登录页或错误页，并让配置提供方给出客户端可识别的格式，不要把网页地址反复当成节点导入。

先保留当前可用分组，记录更新时的错误提示。检查订阅是否到期、地址是否已更换，以及当前网络能否访问订阅服务。若更新需要经代理访问，先选中仍可用的节点，再检查客户端是否提供通过代理更新的选项；如果当前代理本身失效，则改用可访问该服务的网络重试。浏览器能打开地址也不一定代表返回格式正确，还要排除账户登录页和访问限制。不要一开始就清空所有节点，否则会丢失仍可使用的连接与排查参照。

先确认 v2rayN 内核已成功运行，并在系统代理菜单选择“自动配置系统代理”。再到系统设置中的网络代理页面，核对当前正在使用的 Wi-Fi 或有线网络是否写入了客户端的本地监听地址和端口；不同 macOS 版本的入口名称可能不同。随后关闭并重新打开待测试应用。系统代理只影响遵循该设置的程序，应用自带的代理选项、环境变量或其他代理工具可能覆盖它。不要仅凭某个命令行程序未走代理，就判断整个系统设置没有生效。

TUN 需要创建虚拟网络接口并调整相关网络设置，通常要求额外授权。先退出其他 VPN 或同类网络接管工具，再按客户端当前版本的权限提示完成授权；Windows 可能需要管理员权限，macOS 与 Linux 的处理方式取决于客户端的权限辅助机制。不要直接套用其他平台的命令，也不要反复以高权限启动来掩盖未知错误。先用普通系统代理验证节点能连接，再单独开启 TUN；若仍失败，保存首次报错及接口创建相关日志，逐项检查权限与路由冲突。

两者处在不同环节。“自动配置系统代理”决定遵循系统代理的应用是否把请求交给本地客户端；“绕过大陆”是流量进入内核以后如何选择直连或代理出站的路由预设。可以同时启用自动配置系统代理与绕过大陆，也可以让进入客户端的流量按全局代理规则处理。若应用没有把请求交给客户端，单独切换路由预设通常不会改变结果。排查时先确认流量入口，再看规则匹配和最终出站，不要把系统代理菜单当作路由模式开关。

先看测试方式，再比较结果。TCP 连接测试主要说明端口能否建立连接，应用层延迟测试还会涉及握手与测试目标响应，两者都不能直接等同于下载速度。建议固定同一网络、同一测试目标和同一时间段，先确认常用网页能正常打开，再检查持续传输是否稳定。不要并发测试大量节点后立即依据单次结果排序，网络拥塞和服务端限流都可能干扰判断。若低延迟节点仍无法访问目标站点，应继续查 DNS、路由和远端出口，而不是只重复测速。

先记录当前 DNS 配置，区分系统解析、浏览器的加密 DNS 与内核 DNS 各自是否参与请求。仅在部分域名访问失败时，检查日志中的解析错误、DNS 请求走向及路由是否形成循环；不要同时更换所有解析器与分流规则。使用 TUN 时尤其要确认 DNS 接管范围，以及解析器地址本身能否按预期直连或经代理访问。测试应使用同一个域名并按需清理相关缓存。远端服务器不可达或证书参数错误，不会因为随意更换 DNS 就自动恢复。

先备份订阅分组信息、自定义路由、DNS 设置和需要手动维护的节点参数，并确认备份中含有的凭据不会被公开。切换内核前核对目标内核是否支持当前协议、传输方式、REALITY 参数与流控，不要只看协议名称相同就认为完全兼容。每次只改一项：先换节点验证连接，再考虑内核或路由调整。订阅更新可能覆盖由订阅生成的节点，长期手动修改前应另存独立配置。需要在多台设备使用时，也应分别检查客户端支持情况，而不是直接复制整套运行配置。

先关闭代理确认基础网络能访问原本可直连的网站，再检查客户端日志。连接超时、连接被拒绝、域名解析失败和认证失败是不同故障，不应统一按超时处理。确认服务器地址与端口未被误改，设备时间准确，然后用同一节点切换到另一种可用网络测试。如果只有一个节点失败，优先核对该节点服务与参数；如果所有节点都失败，先排除本地防火墙、网络限制或内核未启动。排查期间避免频繁更换多个参数，否则很难判断是哪一步影响了结果。

“已连接”有时只说明本地服务已经启动，不代表每个远端请求都已成功。先看浏览器发起请求时客户端是否出现对应日志：没有记录，检查系统代理、浏览器自带代理与本地端口；有记录但失败，继续查看 DNS、握手或路由出站错误。再区分是所有网站失败，还是只有个别域名失败。若系统代理与 TUN 同时启用，先关闭其中一种接管方式，保留最小配置复测。不要同时修改 DNS、节点和路由；按请求是否进入客户端这条线索逐层定位更有效。

先核对安装包架构与操作系统要求，并保留完整报错。Windows 应区分缺少所需 .NET 桌面运行库与应用配置异常，是否需要另装运行库取决于具体发行包；Linux 检查发行包类型与缺失依赖。Mac 应区分未识别开发者提示、文件访问权限问题和程序实际崩溃，在确认来源可信后按系统隐私与安全性页面的提示处理。不要把所有打不开都归为同一种权限问题，也不要批量关闭系统防护。若更新后才出现问题，先备份配置，再参考启动日志定位。

退出后断网，先检查系统是否仍指向已经停止的本地代理端口。可重新打开客户端，选择“清除系统代理”后再退出，并检查是否有其他网络工具重新写入设置；使用过 TUN 时，还要确认虚拟接口与路由已恢复。只有某个应用不走代理，则检查该应用自己的网络设置，命令行工具还可能读取代理环境变量。不要把本地监听开放到所有网卡来解决本机应用问题。需要进一步求助时，说明系统、客户端、接管方式和错误摘要，日志中的订阅凭据及身份信息应先遮盖。