基础认知
先确认客户端负责什么、连接需要什么，以及各类代理入口的作用。
V2Ray、Xray 与 v2rayN 分别是什么？
V2Ray 属于 Project V 代理工具生态，V2Fly 延续了相关内核的开发；Xray 是另一条独立演进的内核路线。v2rayN 则是管理服务器、订阅、路由和本地代理的图形客户端，实际连接由所选内核执行。遇到配置字段或协议不被识别时，先看客户端当前调用的内核及其版本，不要只看窗口上的客户端名称。来自不同内核的 JSON 配置也不宜直接混用，尤其要核对传输、安全设置和路由字段。
v2rayN、v2rayNG 与 v2flyNG 应该怎么选？
Windows、macOS 和 Linux 桌面使用 v2rayN；Android 通常先选择使用 Xray 内核的 v2rayNG。已有配置明确依赖 V2Fly 行为时，再考虑 v2flyNG。三款客户端都负责把订阅或服务器参数交给内核运行，但界面菜单、可用协议和进阶字段并不完全一致。选择时先匹配操作系统，再核对服务器使用的协议与传输方式。更换客户端前保存订阅地址和必要设置，不能把另一款应用的整个数据目录直接当作可导入配置。
安装客户端之后，为什么还没有可用连接？
客户端安装完成，只代表本地管理界面和运行环境准备就绪，并不会自动生成可用服务器。还需要导入有权使用的订阅地址，或填写服务器地址、端口、用户标识及相应传输参数。订阅是一组服务器配置的分发入口，不等于客户端本身；订阅是否有效、服务器是否可达，也由对应服务决定。先确认配置来源与有效期，再导入并选择活动服务器。请勿把含访问凭据的订阅地址贴到公开评论、截图或在线转换工具中。
系统代理、路由分流和 TUN 模式有什么区别？
系统代理告诉遵循系统设置的应用，把请求交给本地代理端口；部分终端程序和应用不会读取它。路由分流是在流量进入内核后，按域名、IP 或其他条件决定走代理、直连或阻断。TUN 模式通过虚拟网络接口接管符合条件的流量，通常涉及系统网络权限、路由表和 DNS。排错时先用普通本地代理验证服务器能连接，再单独启用系统代理或 TUN。不要同时更改三类设置，否则很难判断是哪一层产生了问题。
安装配置
按系统与架构选择安装包，保存订阅，再处理必要的网络权限。
Android 安装包的 arm64 与 universal 怎么选？
多数较新的 Android 手机可选择 arm64 包；universal 通用包包含多种架构，体积通常更大，适合无法确认设备架构时使用。不能只凭手机购买年份判断：部分设备的处理器支持 64 位，但安装的系统或应用运行环境仍可能是 32 位。可以查看设备规格或可信的系统信息页面；arm64 包提示架构不匹配时，改用通用包。若提示签名冲突，则不是架构问题，应先确认已安装应用的来源和应用标识，备份配置后再处理安装冲突。
订阅导入失败，应该粘贴哪一种地址？
需要粘贴完整的订阅链接，而不是服务后台首页、付款页面或浏览器登录后的页面地址。在 v2rayN 中进入订阅分组设置，新增分组并保存地址，再执行更新订阅；在 v2rayNG 中也要先保存订阅分组，再更新对应分组。复制时检查首尾空格、换行和被截断的查询参数。若日志显示返回 HTML，通常拿到的是登录页或错误页，应重新取得正确链接。不要反复更换编码方式来掩盖地址问题，也不要公开包含访问凭据的完整链接。
Linux 安装 v2rayN 时，deb、rpm 与处理器架构如何对应？
先看发行版使用哪种包管理方式：Debian、Ubuntu 及其衍生系统通常选择 deb，Fedora 等 RPM 系发行版通常选择 rpm。再运行 uname -m 查看架构：x86_64 对应 x64，aarch64 通常对应 arm64。包格式与处理器架构是两项独立条件，需要同时匹配。使用发行版的软件安装器或包管理器安装，让依赖关系得到正常处理；提示缺少依赖时先阅读具体包名。不要用强制忽略依赖的方式继续，也不要为了普通安装把整个桌面客户端长期以 root 身份启动。
启用 TUN 时提示权限不足，如何处理？
先关闭 TUN，确认普通本地代理可以正常连接，再处理系统授权。Linux 需要可用的 TUN 设备以及创建虚拟接口、修改路由所需的权限；具体授权方式以当前 v2rayN 版本提供的提示和发行版机制为准，不要随意给未知程序设置高权限。Windows 按客户端提示授权相关操作；macOS 检查系统设置中对应的网络或 VPN 授权。Android 需要确认系统 VPN 请求，且通常不能与另一个占用 VPN 通道的应用同时运行。授权后重启相关连接，并检查日志中失败的具体操作。
使用技巧
把首次验证、按需分流和配置备份分开完成，减少反复试错。
订阅里有多个服务器，首次连接应该怎样选择？
先更新订阅，选择一个协议与当前内核兼容的服务器，再使用客户端提供的真连接测试检查实际握手，而不是只根据名称或地区判断。普通延迟测试和真连接测试的探测路径可能不同，单项结果不能代替实际访问。设为活动服务器后启用所需代理入口，访问一个明确的 HTTPS 地址，再查看日志是否出现相应请求。首次验证期间保持路由模式不变，也不要连续切换服务器和 DNS；先建立一条可重复的成功路径，后续才便于比较其他配置。
浏览器可以访问，终端里的 curl 却不能连接，怎么办？
终端程序不一定读取桌面的系统代理。先在客户端核对本地 HTTP 或混合监听端口；若确认为 10808，可用 curl -I -x http://127.0.0.1:10808 https://example.com 显式指定代理测试。只有 SOCKS 监听时，应改用与该监听类型匹配的参数，不能把 HTTP 写法直接套上。需要临时环境变量时，在当前终端设置 http_proxy 与 https_proxy，并在测试结束后清除。显式代理成功而普通 curl 失败，通常应检查程序的代理读取方式，而不是立刻更换服务器。
怎样让局域网和指定网站直连，其余请求走代理？
优先使用客户端提供的路由预设，再根据需要添加少量自定义规则。局域网与私有地址应匹配到直连出站；指定网站可用域名规则匹配，不要只写网站首页解析出的一个 IP，因为同一网站可能调用多个子域名或内容分发地址。规则通常按顺序匹配，具体行为还取决于所用内核，应把更具体的例外放在合适位置。保存并应用规则后，通过日志确认命中了哪个出站。DNS 解析策略也会影响基于 IP 的匹配，因此不要同时大幅修改 DNS 与路由。
怎样备份设置，换设备时又该保留哪些内容？
优先使用客户端自身提供的导出或备份入口；若需要复制配置目录，先完全退出客户端，避免复制到尚未写完的文件。至少保留订阅分组、手动添加的服务器、自定义路由以及确有需要的 DNS 设置。备份可能包含用户标识、密码或订阅访问凭据，应放在受控位置。换设备后先恢复服务器信息，再核对监听端口、系统代理和 TUN 权限；这些与系统环境相关的设置不应照搬。跨客户端迁移时优先重新导入订阅，不要直接覆盖整个应用数据目录。
故障排查
记录具体错误，每次只改一个条件，再用相同请求复测。
v2rayN 订阅更新失败，先检查哪些地方？
先确认订阅地址完整、服务仍有效，再查看更新日志中的错误类型。超时表示连接路径没有在限定时间内完成；域名解析失败应检查当前 DNS；HTTP 401 或 403 需要确认访问授权、地址是否失效以及服务端限制。若客户端提供通过代理更新的选项，要先保证当前代理服务器可用；代理已失效时继续依赖它更新订阅，可能形成循环。可在直连与已有可用代理两条路径间分别测试，每次只改一项。日志出现敏感链接时，先遮去凭据再分享错误信息。
节点测试总是超时，怎么区分本机问题与服务器问题？
先确认设备本身能够正常联网，再检查服务器域名、端口、协议及传输参数是否与配置来源一致。手动填写的 TLS serverName、WebSocket path 等字段若有偏差，即使端口能建立连接，也可能在握手阶段失败。查看客户端日志，区分解析失败、连接超时、连接被拒绝和 TLS 错误；同时确认系统时间准确。可以换一个已知可用配置或另一条网络做对照，但每次只更换一个条件。不要把单次超时直接解释为服务器停机，也不要为了连接而随意关闭证书验证。
客户端显示已启动，但网页无法打开，如何逐层检查？
已启动通常只说明内核进程开始运行，不代表服务器握手或网站访问成功。先用显式本地代理请求测试，确认本地端口和服务器链路；再检查浏览器是否使用了系统代理，最后检查路由与 DNS。若显式代理成功而浏览器失败，重点查看浏览器扩展、独立代理设置与缓存连接。若只有特定域名失败，检查对应路由命中和 DNS 日志。TUN 开启后才出现问题时，先关闭 TUN 对照测试，并检查是否与其他 VPN 或网络过滤程序冲突，不要同时开启多套流量接管工具。
Linux 系统代理不生效，为什么有的应用仍然直连？
Linux 的代理设置可能来自桌面环境、应用自身设置或进程环境变量，没有一个开关能保证所有程序都采用相同路径。先核对系统代理地址是否为本机回环地址，端口是否与客户端的 HTTP 或混合监听一致，再用显式代理请求验证该监听确实可用。浏览器若配置了独立代理或扩展，应单独检查；已经运行的应用可能需要重新启动。终端还要排查 http_proxy、https_proxy、ALL_PROXY 与 NO_PROXY 是否冲突。确实不支持代理的应用，可在理解权限和路由影响后再考虑 TUN。