V2Ray 常见问题
配置与连接排查

平台优先：Windows、macOS 与 Linux 桌面端先考虑 v2rayN，便于集中管理订阅、系统代理和路由规则；Android 端先考虑采用 Xray 内核的 v2rayNG。v2flyNG 属于 V2Fly 内核家族备选，适合已有配置明确依赖该家族行为的情况。排序依据是平台覆盖与配置匹配，不代表连接速度排名。已有订阅时，应先核对协议、传输方式与安全参数，再确定客户端；不要把更换客户端当作修复服务端故障的默认办法。

职责区分：客户端提供订阅管理、节点选择和设置界面，内核负责解析配置、执行路由并建立连接，节点则描述远端服务的地址、端口与认证参数。界面能成功导入节点，只能说明配置被接收，不等于远端服务可用。排查时需要区分客户端启动失败、内核配置错误与远端连接失败三个阶段。记录客户端版本、实际运行的内核以及错误发生时间，通常比反复重新导入同一条订阅更有助于定位问题。

接管范围：系统代理主要影响遵循操作系统代理设置的应用，部分程序会忽略该设置或使用自己的代理选项。TUN 通过虚拟网卡与路由接管符合条件的流量，适合需要覆盖更多应用的场景，但也涉及权限、DNS 和其他网络工具的兼容性。初次配置建议先用系统代理验证节点能否正常访问，再单独测试 TUN。两者不是速度档位，开启 TUN 也不能修复错误的节点参数，更不能保证所有应用都按同一路径连接。

参数配套：协议、传输方式和安全层必须与服务端一致，不能仅在客户端菜单中换一个名称。VLESS、VMess 与 Trojan 属于不同的代理协议；REALITY 属于安全机制，常见于特定的 VLESS 配置组合，并不是与这些协议平行的任意替换项。导入后应保留来源提供的流控、传输和安全字段，遇到不支持的字段先确认当前内核能力。通过修改协议来尝试解决超时，通常会引入新的变量，应优先核对原配置与服务状态。

架构选择：多数近年的 Android 手机使用 arm64，可优先选择对应安装包；universal 通常包含多种处理器架构，体积更大，适合暂时无法确认架构的情况。设备上市年份只能作为参考，最终仍以设备与系统支持的架构为准。若出现安装包解析失败，先检查下载是否完成、系统是否满足该版本要求，以及包的架构是否匹配。更新时还要确认是否覆盖同一应用与兼容签名，卸载重装前先备份订阅和自定义设置。

入口与格式：先区分订阅地址和单条节点分享链接。订阅地址应添加到订阅分组后执行更新，节点分享链接则使用客户端支持的剪贴板导入入口。复制时去掉前后空格、换行和聊天软件附带的说明文字，再检查地址是否过期或需要重新授权。如果客户端提示解析失败，返回内容可能是网页、登录提示或不兼容格式，不宜直接修改编码碰运气。可根据错误日志确认失败发生在请求阶段还是解析阶段；订阅地址属于敏感配置，不要公开截图或粘贴完整内容。

启动顺序：添加订阅不会自动证明代理链路已建立。先选择一个节点并确认内核正常启动，再在 v2rayN 中启用自动配置系统代理，检查系统代理地址与客户端实际监听端口一致。端口以当前设置为准，不要照抄其他教程中的数字。若只有某个应用无法使用，检查该应用是否有独立代理设置；若所有应用都失败，查看端口占用、内核启动日志及安全软件拦截记录。测试期间先关闭其他代理工具，避免系统设置被反复覆盖。

权限检查：先确认普通代理模式可用，再处理 TUN 权限。Windows 端按客户端提示授予管理员权限；macOS 与 Linux 按当前版本要求完成辅助服务或提权授权；Android 端确认系统的 VPN 连接请求。不同平台的授权方式不能互相套用。若仍然失败，查看日志中的具体错误，并检查其他 VPN、虚拟网卡或防护软件是否冲突。不要持续重复授权或关闭全部安全防护；先退出冲突程序、重启客户端，再用最小配置复测。

请求路径：先确认订阅地址仍有效，再区分连接超时、访问被拒绝与内容解析失败。如果直连无法获取订阅，而当前已有可用节点，可以尝试启用更新订阅时使用代理，然后手动更新一次并查看日志。该选项依赖现有代理可用；首次配置没有可用节点时，开启它反而可能形成依赖循环。若请求返回成功但解析失败，应核对订阅格式与返回内容，而不是继续切换代理。自动更新间隔应结合来源的更新频率设置，避免短时间连续重复请求。

分组管理：按来源建立订阅分组，再用清晰的备注区分用途，不要把多个地址反复导入同一组。更新前记录当前选中的节点及所属分组，更新后检查节点是否被删除、重命名或替换。自动更新通常会重建来源提供的节点信息，因此不宜把重要的手动改动直接写在订阅节点上；需要长期保留的配置应独立保存。删除分组前确认其中是否包含手动添加的项目。过滤规则先用少量条件测试，防止把可用节点一起隐藏。

路由选择：日常可先使用与实际需求匹配的规则分流，让指定目标走代理，其他目标按规则直连。全局代理适合短时间对照测试，用于判断异常是否来自分流规则，但它仍受客户端接管范围影响，不代表设备所有流量都会被接管。若全局正常而规则模式失败，应检查规则顺序、域名识别与 DNS 路径，而不是立即更换节点。局域网、打印设备和内部服务通常需要明确的直连规则；修改前保留原设置，每次只调整一项并记录结果。

域名映射：FakeDNS 用虚假 IP 与域名建立映射，适合在支持它的 TUN 和路由组合中保留域名信息，帮助域名规则匹配。它不是通用的网络加速开关，也不应在尚未理解 DNS 路径时直接启用。某些应用依赖真实解析地址，可能出现访问异常。测试前保存 DNS 与路由设置；如果开启后只有特定应用失败，可先关闭 FakeDNS，恢复原解析配置，再重连客户端并清理应用或系统 DNS 缓存，观察问题是否随之消失。

分层定位：先确认本机能够正常联网，再查看内核是否启动、监听端口是否被占用、系统代理是否指向正确地址。随后核对当前节点和订阅更新时间，检查设备时钟，再依据日志判断是域名解析、连接建立还是握手阶段超时。可用另一条已知可用的配置或另一种网络做对照，但一次只替换一个条件。延迟测试失败不一定代表应用访问必然失败，两者可能采用不同测试目标。若多个设备在同一节点上均失败，再向配置来源确认远端服务状态。

状态解释：已连接或运行中通常只表示本地服务已经启动，不代表每个目标都能访问。先检查浏览器实际使用系统代理还是独立代理，再用同一目标对比规则模式与全局代理模式。查看日志是否有 DNS 解析失败、路由落到错误出站或认证失败。若普通代理可用而 TUN 不可用，重点检查虚拟网卡、DNS 与路由冲突；若仅浏览器失败，检查扩展和浏览器代理选项。不要同时重装客户端、换节点和改 DNS，否则难以判断哪一步真正影响结果。

握手参数：先把系统日期、时间与时区设为准确值，再核对配置来源要求的服务器名称、SNI、传输路径及相关安全参数。连接地址与用于证书验证的名称可能不同，应按服务端配置填写，不能因为两者不同就直接改成相同。普通 TLS 连接需要验证证书对应名称；REALITY 配置还需要核对其专用参数与内核支持情况。不要把跳过证书验证作为长期解决方案。保留具体错误信息并隐藏地址和认证内容，有助于区分证书、参数与服务端配置问题。

对照方法：先确认异常是否仅发生在某个应用或域名，再查看日志中的域名解析结果与实际出站。若同一目标在全局代理下正常、规则模式下失败，优先检查规则命中顺序、域名规则数据和 DNS 选择；若两种模式都失败，继续检查节点及目标服务。不要只凭直接访问 IP 的结果判断，因为部分服务需要域名和正确的 TLS 名称。调整 DNS 后重新建立连接，必要时清理缓存；每次保留修改前后的记录，避免同时更换多个解析器导致结果难以复现。