v2rayN 疑难解答

v2rayN 是桌面图形客户端，负责订阅分组、服务器选择、系统代理和路由设置；实际建立连接的是它启动的代理内核。v2rayNG 与 v2flyNG 面向 Android，分别以 Xray 与 V2Fly 内核为主要技术路线。Project V 是理解这套生态的起点，客户端名称相近并不表示配置文件可以直接互换。排查问题时，应分别记录客户端版本、实际运行的内核和所用协议。仅确认客户端已经打开，还不能说明内核启动成功，也不能说明应用流量已经进入代理。

Windows 用户可以在 v2rayN 桌面版与经典 WPF 版之间选择；macOS 和 Linux 使用跨平台桌面版。桌面版采用 Avalonia 界面，WPF 版使用 Windows 界面技术，两者的托盘行为、菜单位置和部分系统集成可能不同。先按操作系统与处理器架构选包，再根据已有配置和使用习惯选择界面版本。切换前备份客户端设置，不要把两版解压到同一目录覆盖运行。若只有某一版出现问题，应记录具体界面版本和操作步骤，而不是直接判断订阅或服务器已经失效。

先查看设备的处理器架构或系统提供的设备信息。使用支持对应运行环境的六十四位 ARM 设备时，通常选择 arm64 包；无法确认架构时，可以尝试包含多种架构组件的 universal 通用包，代价是文件通常更大。不能只凭购买年份判断，处理器支持六十四位也不代表系统一定提供相同的应用运行环境。安装提示不兼容时，还要核对系统要求；提示签名冲突时，应先备份配置，再检查已安装应用的来源与签名，不要把所有安装失败都归因于架构选择。

订阅地址用于获取一组服务器配置，并可能在以后更新内容；单条服务器链接通常只描述一个连接配置；完整配置文件还可能包含入站、出站、路由和 DNS 等设置。三者对应的导入入口并不相同，把订阅地址当作单条服务器链接导入，可能得到无法识别或列表为空的结果。订阅地址也不等于可直接访问的网站，浏览器显示的页面不能单独证明内容符合客户端要求。此类地址常包含访问凭据，提交截图或日志前应遮盖完整地址和身份信息，避免公开分享。

先区分输入的是订阅地址还是单条服务器链接。订阅应放入订阅分组的地址字段，再执行该分组的更新操作；单条链接则使用对应的链接导入功能。检查复制时是否带入空格、换行、聊天软件附加文字或缺失的参数。若更新请求成功但列表仍为空，查看客户端日志是否提示内容格式无法解析，也要确认提供方没有返回登录页面、到期通知或错误页面。不要反复删除全部服务器来试错，先保留现有分组，建立独立测试分组核对来源与返回内容。

自动配置系统代理只修改系统提供给应用读取的代理设置，并不保证所有程序都会使用它。先确认代理内核已启动、本地监听端口正常，再检查系统代理中的地址与端口是否和客户端一致。浏览器扩展、独立代理选项、企业策略或另一个代理程序都可能覆盖系统设置，修改后可关闭并重新打开浏览器测试。对比一个明确读取系统代理的应用与出现问题的应用，有助于区分入口故障和程序行为差异。确需接管不读取系统代理的程序时，再考虑 TUN，而不是先改成全局路由。

TUN 需要创建虚拟网络接口并调整路由，通常需要管理员授权或平台对应的提权流程。先退出重复运行的客户端，再按当前平台要求授权启动，并查看日志中的首个错误。权限不足、接口创建失败和路由写入失败属于不同环节，不能只靠重复点击开关解决。若设备受组织策略管理，应遵循设备管理规则，不要尝试绕过限制。同时检查其他虚拟网卡或 VPN 是否正在占用路由。排查期间先关闭 TUN，确认系统代理方式可以工作，再逐项恢复虚拟网卡接管与 DNS 设置。

导入后先确认目标分组中存在可识别的服务器条目，再选择其中一项作为活动服务器，检查内核是否成功启动。随后选择需要的系统代理模式，用确实读取该入口的应用访问测试页面，并观察对应的访问记录或路由日志。服务器列表中出现条目只代表配置已保存，测试有响应也不等于所有应用都能正常联网。验证时一次只改变一个条件，例如保持服务器不变，仅切换系统代理设置。这样可以把配置解析、服务器连接、流量入口和路由匹配分开确认，避免同时修改多项后失去判断依据。

系统代理决定应用是否把流量交给本地代理入口，路由规则决定进入内核后的流量使用哪个出站。自动配置系统代理不会自动让所有目标走代理，全局路由也不会接管忽略系统代理的应用。使用绕过大陆等预设时，还要理解域名、地址与规则数据库的匹配条件。遇到某个网站路径不符合预期，先检查流量是否进入内核，再查看匹配规则与出站标签。为了排查可以临时调整预设，但应记录原设置并在测试后恢复；需要长期例外时，增加范围明确的规则比长期使用宽泛规则更容易维护。

在订阅分组设置中确认启用更新，并按字段说明填写自动更新间隔，注意单位是分钟。更新频率应参考订阅提供方的要求，过于频繁可能触发请求限制，也会增加排查噪声。通过代理更新适用于直连无法访问订阅服务、但已有可用代理的情况，前提是当前活动服务器和代理内核已经正常工作。若所有服务器都失效，而订阅又依赖它们更新，就会形成更新依赖，应先恢复直连访问或使用已有的可用配置。设置后执行一次手动更新，确认日志正常，再观察后续自动更新是否触发。

先检查日志中是解析失败、连接失败，还是请求已经发往不符合预期的出站。应用自身的安全 DNS、系统 DNS 与内核 DNS 可能走不同路径，修改其中一处未必影响另外两处。使用 TUN 时，还应确认 DNS 请求是否被接管，以及是否出现解析请求再次进入自身入口的循环。涉及按地址匹配的规则时，解析结果也会影响路由选择。每次只调整一个解析设置，并重新建立应用连接后复测；不要同时更换所有解析器和路由规则。直接用地址访问还可能破坏证书名称匹配，因此不能把这种测试当作最终修复。

优先使用当前客户端提供的备份或导出功能，保留订阅分组、手动添加的服务器、自定义路由和必要的参数设置，并记录原客户端与内核信息。导出文件可能包含订阅凭据与服务器认证信息，应保存在受控位置，避免上传公共网盘分享链接。迁移到不同平台或不同客户端时，不要默认整个数据目录可以直接覆盖，先检查导入格式与字段兼容性。恢复后逐项确认本地端口、系统代理、TUN 和自定义路径，尤其不要沿用旧系统的绝对路径。新环境验证完成前保留原备份，减少回退成本。

超时只说明当前测试没有在限定时间内完成，不能单独证明服务器永久失效。先确认客户端使用的测试方式与测试地址，再检查本地网络是否正常、系统时间是否准确、服务器域名能否解析，以及协议参数是否完整。握手失败、目标不可达和测试网站不可达可能表现相似，应结合内核日志区分。保持网络不变，换一个已知可用配置作对照；也可以保持配置不变，更换网络复测。若多个配置同时失败，应优先排查本机入口、网络与内核启动状态，而不是逐条删除服务器或频繁重装客户端。

客户端的运行状态、测试请求成功与应用实际联网是三个不同层面。先确认出问题的应用是否使用系统代理或被 TUN 接管，再检查活动服务器与路由出站是否正确。如果只有域名访问失败，重点看 DNS；如果只有部分网站异常，检查规则命中、连接日志与目标服务自身状态。还要排除代理扩展、旧的手动代理设置和安全软件造成的干扰。测试时使用普通浏览器窗口与另一个应用交叉验证，并重新建立连接，避免旧连接沿用原路径。不要仅凭状态图标判断整条链路正常，也不要把全局路由当作所有故障的通用修复。

先查看更新日志，区分地址失效、名称解析失败、连接超时、证书错误和服务端拒绝请求。证书错误应先检查设备日期、时区及系统信任证书是否正常，再核对订阅域名；不要把关闭证书验证当作常规解决方法。收到请求限制时，停止连续手动重试，按提供方要求延长更新间隔。地址过期或返回认证错误则需要确认订阅有效期与访问凭据，客户端重新安装通常不能修复这些问题。记录日志时保留错误类型和发生环节即可，提交给支持人员前应遮盖完整订阅地址及可能包含的认证参数。

先检查系统是否仍指向已经停止监听的本地代理端口，必要时通过系统设置恢复原有网络代理配置。使用 TUN 时，按客户端的正常流程关闭虚拟网卡接管，再退出程序，避免直接结束进程留下尚未恢复的网络状态。多个代理或 VPN 同时运行时，可能分别修改系统代理、默认路由和 DNS，排查时只保留一个接管者。若端口被占用，应确认占用程序后再处理，不要随意结束系统进程。恢复基础联网后逐个启用功能，观察哪一步复现问题；远程操作设备时，调整路由前应准备可用的回退方式。