全平台指南

客户端与平台如何对应

桌面设备优先使用 v2rayN。它覆盖 Windows、macOS 与 Linux，适合通过图形界面管理订阅、节点、路由和代理状态。Android 上优先考虑 v2rayNG；如果订阅或使用环境明确围绕 V2Fly 内核配置，也可以选择 v2flyNG。两款 Android 客户端的界面细节与内核侧重点不同，但基本流程相同：导入订阅、更新节点、选择配置、启动本地 VPN 接管，再进行访问验证。

不要把客户端、内核和订阅混成同一个概念。客户端负责界面、配置管理和系统接管；Xray 或 V2Fly 等内核负责按配置建立连接与处理流量；订阅链接则由服务提供方生成，其中通常包含服务器地址、端口、用户标识、传输方式和 TLS 或 REALITY 等参数。安装客户端不会自动产生可用节点，订阅导入成功也不代表其中每个节点都能连接。

准备订阅信息，但不要急着反复导入

开始前应准备一条仍在有效期内、可正常访问的订阅地址。订阅链接属于敏感配置资料，不应粘贴到公开帖子、截图或多人共享文档。若提供方给出的是单个 VMess、VLESS 或其他分享链接，可以使用客户端的“从剪贴板导入”功能；若给出的是订阅地址，则应创建订阅分组并执行一次更新。两种入口处理的对象不同：单链接通常生成一个节点，订阅地址则可能生成一组由提供方维护的节点。

首次导入前先检查链接首尾是否带了空格、聊天软件是否截断了参数、浏览器是否把特殊字符改写。导入后重点查看节点名称和数量是否符合预期，而不是立即连续点击更新。若订阅更新失败，应先判断是地址本身无法访问、系统时间错误、证书握手失败，还是当前网络需要先通过已有代理才能访问订阅服务。持续重复更新只会制造更多相同日志，不会改变根因。

记录原有代理与 DNS 状态

配置前先记录系统代理是否开启、局域网地址是否手工设置、浏览器是否安装了单独的代理规则、系统 DNS 是否为手动值。最稳妥的做法是截取系统网络设置，或把关键值写入本地笔记。后续若出现网页打不开、局域网设备失联或退出客户端后仍残留代理，就能按原状态恢复。尤其在公司、学校或需要固定代理的网络环境中，不应直接覆盖已有设置而不留记录。

还应确认系统时间与时区正确。TLS 和 REALITY 连接都依赖合理的时间判断，明显偏差可能表现为证书失败、握手中止或连接刚建立便关闭。时间问题不会通过更换路由规则得到解决，因此应放在协议参数之前检查。

下载入口与架构选择

所有客户端入口集中在下载页。Windows 常见设备选择 x64；macOS 需要根据“关于本机”中的芯片类型选择 Apple Silicon 或 Intel；Android 近年的主流设备通常使用 arm64，无法确定时可选通用包；Linux 除 x64 与 arm64 外，还要根据发行版选择 deb 或 rpm。架构选错通常表现为安装器拒绝运行、系统报告格式错误，或应用启动后立即退出，它与订阅是否可用没有关系。

安装前关闭旧客户端并清理其仍在生效的系统代理，不必同时保留多个客户端争用同一个本地端口。若确实需要并行对比，应给每个客户端设置不同的本地监听端口，并明确当前由谁修改系统代理。准备工作完成后，再进入对应平台章节逐项操作。

选择桌面版或经典 WPF 版

下载页提供 v2rayN 桌面版和经典 WPF 版。桌面版采用新一代跨平台界面，适合希望在不同桌面系统间保持相近操作逻辑的用户；WPF 版是 Windows 上长期使用的经典界面，菜单位置和教程资料相对稳定。两者都能完成订阅管理、节点选择、路由配置与系统代理控制。第一次使用时只安装其中一种，避免两个实例同时驻留并修改同一套系统代理。

从Windows 下载入口取得适合的安装包后，先退出正在运行的旧版本。若使用安装形式，按安装界面选择当前用户可写的目录；若采用解压运行形式，应放在长期保留且具有写入权限的位置，不要直接在压缩包预览窗口中启动。客户端需要写入配置、日志和内核相关文件，目录不可写会导致设置保存失败或每次启动都像首次运行。

首次启动与订阅分组

启动 v2rayN 后，先进入订阅分组管理，新增分组名称并粘贴订阅地址。分组名称应表达用途，例如“日常订阅”或“测试分组”，不建议把完整订阅地址当作名称。保存后执行更新订阅，在主列表中确认节点被实际写入。若列表保持为空，查看提示信息与日志：地址返回网页而非订阅内容、链接过期、访问被登录页重定向，都会使解析失败。

订阅分组是管理入口，不是连接状态。更新成功只说明客户端取得并解析了配置。接下来选择一个节点作为当前活动项，再执行真连接测试。测试时优先观察能否建立连接及日志是否出现明确错误，不要只看下载测速。测速还会受到目标服务器、线路拥塞和本地带宽影响，不能单独证明系统代理已经接管浏览器。

从单个链接导入与参数核对

如果拿到的是单个分享链接，可以复制后使用“从剪贴板导入批量 URL”。导入完成后打开节点编辑界面，核对服务器地址、端口、用户标识、传输方式、安全层和服务器名称等字段是否齐全。VLESS 配置使用 TLS 或 REALITY 时，还可能包含 flow、指纹、公钥、短标识和 serverName。不要为了“兼容”而随意删除不认识的参数；这些值往往必须与服务端一致。

遇到 VMess 与 VLESS 不知如何选择时，不必只按协议名称判断速度。协议负责身份和数据格式，TLS、REALITY、WebSocket、gRPC 等则属于安全与传输组合，最终是否可用取决于整套参数是否匹配。可进一步阅读VMess 与 VLESS 参数差异，再回到客户端逐项比对。

先测试系统代理

对大多数浏览器和遵循 Windows 系统代理的桌面应用，首次配置先使用系统代理更容易定位问题。在 v2rayN 的系统代理菜单中选择“自动配置系统代理”，再根据需求选择路由模式。此操作会把系统代理指向客户端的本地监听端口，但并不表示所有应用都会自动遵循。部分游戏、命令行工具、虚拟机和自行实现网络栈的软件可能绕过系统代理。

开启后先访问一个平时可以稳定打开的普通网站，确认基础网络没有中断，再访问用于验证代理路径的目标站点。同时查看客户端日志是否出现对应连接。如果浏览器仍使用旧连接，可以完全关闭并重新打开浏览器，或新建无缓存窗口复测。详细的交叉确认方法可参照v2rayN 首次连接验证。

TUN 的权限与边界

当应用不遵循系统代理，或需要统一接管更多网络流量时，再考虑 TUN。TUN 会创建虚拟网络接口并通过路由规则接收流量，通常需要管理员权限和驱动支持。启用前先清除系统代理或明确两者的职责，避免同时开启后无法判断实际路径。若启动提示权限不足，应退出客户端后以管理员方式运行；若虚拟接口创建失败，则检查旧 TUN 驱动、其他 VPN 类软件和安全策略是否冲突。

TUN 不是“连接更快”的开关，它改变的是接管范围。局域网访问、虚拟机网络、开发环境和公司内网可能受路由影响。启用后应测试本机网关、局域网设备与常用内网域名，并确认私有地址被直连规则覆盖。出现内网不可达时，先关闭 TUN 验证是否恢复，再检查 geoip:private 或私有网段直连规则，而不是立刻更换节点。

Windows 常见冲突

端口占用是 Windows 上常见问题。若日志提示本地监听失败，检查是否有另一个 v2rayN 实例、旧客户端或调试工具使用相同端口。不要只把端口随机改大；修改后还需让系统代理、浏览器扩展和依赖该端口的应用同步更新。安全软件拦截内核进程时，也可能出现界面正常但连接完全没有日志的情况，应结合系统事件和客户端日志判断。

另一个误区是把“延迟测试有结果”当作连接完成。延迟测试可能只验证 TCP 建连，真连接测试才会按节点协议发起实际请求。即使真连接成功，系统代理未开启时，浏览器仍可能直连。完整验证顺序应是：选择节点、执行真连接测试、开启一种接管方式、重新发起浏览器请求、在日志中找到对应域名或目标连接，最后再测试其他应用。

先确认 Apple Silicon 或 Intel

打开系统的“关于本机”查看芯片信息。显示 Apple M 系列时选择 arm64 安装包；显示 Intel 处理器时选择 x64 安装包。架构与客户端功能没有高低之分，只需和设备匹配。若在 Apple Silicon 设备上误装 Intel 构建，系统可能要求额外转换环境，也可能出现性能或兼容问题，因此应优先使用原生 arm64 版本。

从macOS 下载入口取得对应 dmg 后，打开磁盘映像并把应用拖入“应用程序”目录，再从该目录启动。不要长期从只读磁盘映像中运行，因为应用的更新、辅助组件和配置写入可能受到限制。首次启动若被系统阻止，应在“隐私与安全性”设置中查看本次拦截记录并确认运行，而不是关闭整个系统安全机制。

导入订阅与选择节点

进入订阅分组管理，添加订阅名称和地址，保存后执行更新。macOS 上常见的订阅失败并不一定来自客户端：系统 DNS 无法解析、当前网络需要网页认证、时间不准或订阅服务证书异常，都可能导致请求失败。先用浏览器确认网络认证已完成，再查看日志中是解析失败、连接超时还是返回内容无法识别。

节点出现后，先选择一个配置执行真连接测试。若同一订阅中只有部分节点失败，应比较失败节点的服务器名称、端口、传输方式和 TLS 或 REALITY 参数，不要直接删除整个订阅。若全部节点都在握手阶段失败，则优先检查系统时间、网络是否拦截目标端口，以及订阅是否已更新到新的用户标识。

系统代理适合哪些应用

macOS 系统代理会写入当前网络服务的代理项目。浏览器和遵循系统网络配置的应用通常能够使用，但终端命令、部分开发工具与自行维护连接的程序未必会跟随。开启后应进入系统网络详情查看代理状态是否发生变化，并确认当前操作的是正在使用的网络服务。设备同时保留无线网络、有线网络或多个网络位置时，改错服务会表现为客户端显示已开启，但实际流量没有变化。

命令行工具通常需要自己的环境变量或配置。若只想临时让当前终端会话使用客户端监听端口，可以按客户端实际显示的本地端口设置环境变量。下面仅展示写法，端口应以本机设置为准：

export http_proxy="http://127.0.0.1:本地HTTP端口"
export https_proxy="http://127.0.0.1:本地HTTP端口"
export all_proxy="socks5://127.0.0.1:本地SOCKS端口"

这类环境变量只影响当前 shell 及其子进程，不应在未确认端口的情况下永久写入启动文件。测试结束可执行 unset http_proxy https_proxy all_proxy 恢复。若工具本身支持独立代理配置，优先在工具内明确设置，便于后续识别来源。

TUN 与网络扩展授权

需要接管不读取系统代理的应用时，可以评估 TUN。首次启用可能触发管理员验证或网络扩展授权。授权完成后仍应回到客户端确认虚拟接口是否成功创建，并在日志中观察路由写入结果。只看到系统弹窗并点击允许，不代表 TUN 已经稳定运行；接口创建、DNS 接管和路由下发分别可能失败。

macOS 上同时运行其他 VPN 类工具、网络过滤器、企业安全软件或虚拟化网络时，路由优先级可能互相影响。排查时先关闭其他会修改默认路由或 DNS 的程序，只保留 v2rayN 和基础网络。若问题消失，再逐个恢复程序。不要同时切换节点、路由模式和多个网络扩展，否则日志时间线会混在一起。

睡眠唤醒与 DNS 缓存

设备从睡眠恢复后，网络接口和默认路由可能重新分配。若客户端界面仍显示运行，但新请求持续超时，可先停止接管、等待网络恢复，再重新启动。频繁切换无线网络时也应如此。若域名连接失败而直接访问已知 IP 的测试正常，问题更可能在 DNS 路径，应检查客户端 DNS 设置、系统解析结果以及路由规则是否把 DNS 请求送往不可达出口。

不要把清理 DNS 缓存当作固定动作。只有在域名记录明显过期、切换解析策略后仍返回旧值时才需要处理。多数代理问题来自接管方式、路由匹配或节点参数，反复刷新缓存不会修复握手失败。退出客户端前先清除系统代理；若使用 TUN，则先正常停止 TUN，让客户端撤销接口与路由后再退出。

选择 arm64 或通用包

近年的主流 Android 手机通常使用 arm64 架构，明确设备架构时优先选择 arm64 包；无法确认或安装器提示不兼容时，可使用通用包。通用包覆盖范围更广，但体积通常会包含多种架构资源。架构只决定应用能否在处理器上运行，不会改变节点协议和订阅内容。下载入口按 v2rayNG 在前、v2flyNG 在后的顺序列出，可前往Android 下载区选择。

安装前若设备中已有同名应用，应确认签名来源和现有配置是否需要保留。系统拒绝覆盖安装时，不要直接卸载后再想起订阅尚未备份。可以先记录订阅地址、路由模式、应用分流和 DNS 设置，再决定升级或重新安装。订阅地址属于敏感信息，备份文件也应只保存在受控位置。

导入订阅与单节点链接

打开 v2rayNG 后，可通过订阅分组添加地址并更新，也可以从剪贴板导入单个分享链接。若使用二维码，应确认二维码来自可信来源，扫描后仍需检查服务器地址、端口、用户标识、传输方式和安全参数。扫码只是减少手工录入，不会验证配置是否正确。

订阅更新后，点击节点名称使其成为当前配置，再启动连接。Android 会请求创建 VPN 连接，这是系统为本地流量接管提供的标准授权。若设备已经有其他 VPN 类连接，系统通常只允许其中一个保持活动，应先停止旧连接。授权弹窗被拒绝后，客户端无法仅靠后台服务完成接管，需要重新启动并允许。

应用分流与绕过选择

应用分流用于决定哪些应用进入本地 VPN 接口。首次连接建议暂时不启用复杂分流，先让一个浏览器完成验证。确认基础连接正常后，再按“仅代理选中应用”或“绕过选中应用”的逻辑配置。两种模式含义相反，切换后应重新检查列表，避免把目标应用放到错误一侧。

银行、局域网控制、投屏和设备发现类应用可能依赖本地网络，应根据实际需求直连。将应用设为直连不等于它不受 DNS 影响；若 DNS 请求仍由客户端接管，域名解析结果也可能改变。遇到某个应用异常而浏览器正常时，先清除该应用的分流限制复测，再检查它是否使用 QUIC、私有 DNS或固定地址，不要先改动全局节点。

后台限制与断线重连

Android 厂商常对后台服务实施电池优化、休眠和自启动限制。表现通常是锁屏一段时间后连接停止、切换网络后没有恢复，或系统回收客户端进程。处理时先在系统电池统计中确认客户端是否被限制，再为其选择合适的后台策略。并非所有设备都需要完全放开限制；应先观察，再只调整影响连接的项目，避免把持续流量误判为系统限制。

频繁重连也会增加耗电。日志中若反复出现网络变化、连接超时和立即重试，应区分是移动网络信号不稳、节点不可达，还是系统在后台暂停网络。可以在同一地点保持屏幕亮起测试一段时间，再锁屏对比。详细排查顺序见v2rayNG 后台耗电异常排查。

私有 DNS 与客户端 DNS

系统私有 DNS、浏览器内置安全 DNS和客户端 DNS可能同时存在。首次排查时应明确当前由谁解析域名。若系统私有 DNS 设置为严格主机名，但该服务在当前网络不可达，可能在代理启动前就造成域名解析失败。可先恢复自动模式验证，再决定是否让客户端接管 DNS。

客户端 DNS 的作用不仅是“换一个服务器”，还涉及域名请求通过哪个出口发送、路由规则用域名还是解析后的 IP 匹配，以及是否需要避免本地结果与代理出口不一致。若只有域名失败而节点的服务器地址是 IP，可重点检查 DNS；若服务器地址本身无法建立 TCP 或协议握手，调整域名服务器通常没有作用。

切换无线网络与移动网络

网络切换会更换本地地址、默认路由和 NAT 状态，原有连接可能无法继续复用。切换后等待系统网络稳定，再观察客户端是否自动重建。如果界面显示已连接但没有新日志，可停止后重新启动本地 VPN。不要快速连续点击启动按钮，以免旧服务尚未释放接口时又创建新实例。

排查完成后，如果只在某个无线网络失败，而移动网络正常，检查该网络是否需要网页登录、是否限制目标端口、DNS 是否返回异常结果。若两个网络都失败，再回到节点参数、订阅有效性和系统时间。通过这种对照，可以把“设备设置问题”和“当前网络问题”分开。

deb、rpm 与处理器架构

Debian、Ubuntu 及其常见衍生发行版通常使用 deb；Fedora、Rocky Linux、openSUSE 等环境常见 rpm，但具体仍应以发行版包管理体系为准。普通桌面电脑多为 x64，arm64 常见于部分开发板和 ARM 桌面设备。可以运行 uname -m 查看架构：常见输出 x86_64 对应 x64，aarch64 对应 arm64。

uname -m
cat /etc/os-release

从Linux 下载入口取得匹配的 v2rayN 包。安装本地 deb 时，可在包所在目录使用系统包管理器处理依赖；rpm 发行版也应使用自身包管理器，而不是只解压文件。下面命令中的文件模式需要与实际下载名称匹配，并确保目录里没有多个旧包：

sudo apt install ./v2rayN*.deb
sudo dnf install ./v2rayN*.rpm

若系统提示架构不匹配，回到下载页重新选择，不要使用强制参数跳过。若提示依赖缺失，先刷新发行版软件源并确认桌面环境版本受支持。用强制忽略依赖的方式安装，往往只会把错误推迟到启动阶段。

首次启动与配置目录

从桌面应用菜单启动 v2rayN，确认界面、托盘和配置保存均正常。若终端启动能看到错误而桌面菜单无反应，可以从终端运行应用入口观察缺失库、显示服务或权限提示。不要长期使用 root 身份运行整个图形客户端，否则配置目录可能归 root 所有，之后普通用户启动时无法写入。

订阅管理流程与其他桌面平台一致：新增分组、粘贴订阅地址、保存、更新、选择节点并执行真连接测试。Linux 桌面常在系统和用户会话之间区分代理设置，因此客户端显示“设置成功”后，还应进入桌面网络设置检查当前用户的代理值。若使用轻量桌面或独立窗口管理器，可能没有统一的系统代理接口，需要为浏览器和具体应用分别设置。

桌面代理与环境变量

GNOME、KDE 等桌面环境提供系统代理设置，但应用是否遵循仍取决于其网络实现。浏览器通常可以跟随桌面代理，终端工具则经常读取环境变量或自己的配置。临时测试时可在当前 shell 设置代理变量，结束后立即取消：

export http_proxy="http://127.0.0.1:本地HTTP端口"
export https_proxy="$http_proxy"
export all_proxy="socks5://127.0.0.1:本地SOCKS端口"

# 测试结束
unset http_proxy https_proxy all_proxy

这里的端口必须从 v2rayN 设置中读取。若客户端只监听本机回环地址，局域网其他设备不能直接使用该端口，这是更稳妥的默认边界。只有明确需要共享代理时才考虑监听局域网地址，同时检查防火墙和访问控制，避免把未授权的代理入口暴露给同一网络中的其他设备。

TUN、能力与路由冲突

Linux TUN 依赖内核设备、网络管理权限和路由写入能力。首先确认 /dev/net/tun 存在，再从客户端日志判断是设备不可用、权限不足，还是路由规则写入失败。不要直接给整个应用永久 root 权限。优先使用客户端提供的授权流程或系统能力配置，并了解升级后可执行文件变化可能使旧授权失效。

ls -l /dev/net/tun
ip route
ip rule

容器、虚拟机、公司 VPN 和多网卡环境可能已有策略路由。启用 TUN 前保存 ip route 与 ip rule 输出，启用后再比较新增项目。若内网失联，重点检查私有网段是否被送入 TUN、默认路由优先级是否变化，以及 DNS 请求是否进入了不同命名空间。关闭 TUN 后应确认新增接口和规则被撤销。

DNS 与 systemd-resolved

Linux 的解析链可能包含应用、glibc、NetworkManager、systemd-resolved 和上游 DNS。修改客户端 DNS 后，不能只看 /etc/resolv.conf 的表面内容，因为它可能是指向本地解析服务的链接。可使用 resolvectl status 查看每个接口的 DNS 与域配置，再结合客户端日志判断查询是否真正进入代理。

resolvectl status
getent hosts example.com
ss -lntup

ss 可用于确认本地代理端口是否监听及是否发生冲突。若客户端退出后网络异常，先清除桌面代理和 shell 环境变量，再检查 TUN 接口及策略路由。重启设备虽然可能恢复状态，但会丢失最有价值的现场信息；在重启前保存日志和路由输出，更有利于找到根因。

接管方式决定哪些流量进入客户端

系统代理本质上是向应用公布一个 HTTP 或 SOCKS 代理入口。只有读取并遵循系统设置的应用才会使用它，优点是边界清晰、开启和恢复简单，适合浏览器与多数桌面程序。TUN 则通过虚拟接口与路由接收流量，能够覆盖更多不支持代理设置的应用，但也更容易影响局域网、虚拟化环境和已有网络工具。

两种方式并非必须同时开启。第一次配置应从系统代理开始：如果目标应用能够被接管，就没有必要为了“更完整”而立即增加 TUN。只有确认某类应用绕过系统代理，且确实需要统一接管时，再启用 TUN。Android 的本地 VPN 接管在体验上更接近 TUN，但应用分流由系统接口和客户端共同完成。

路由规则按顺序匹配

路由负责决定已经进入内核的流量走哪个出口。常见条件包括域名分类、IP 分类、端口、网络类型和进程。规则通常按顺序匹配，先命中的规则生效，因此更具体的规则应放在更通用的规则之前。若一条覆盖范围很大的代理规则排在前面，后面的局域网直连规则可能永远没有机会执行。

下面是一个用于说明结构的路由片段。它先让常见私有地址和指定分类直连，其余行为由配置中的后续规则与默认出口决定。实际使用时，出口标签必须与客户端生成的出站配置一致：

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy 决定路由判断是否以及何时解析域名。使用 AsIs 时优先按原始域名规则匹配；其他策略可能在需要时解析为 IP 再判断。没有一种策略适合所有环境。若依赖域名分类分流，应确保请求到达内核时仍带有域名信息；若应用直接连接 IP，域名规则自然无法命中。

GeoIP 与 GeoSite 数据

GeoIP 是 IP 分类数据，GeoSite 是域名分类数据。路由规则引用的是分类标签，不是“自动智能分流”。数据库缺失、标签不存在或内核版本不兼容时，客户端可能启动失败，也可能在日志中报告规则加载错误。更新数据后应检查日志确认新文件被读取，并保留原有文件以便回退。完整维护流程可参考GeoIP 与 GeoSite 数据库更新指南。

不要在一次调整中同时更换数据库、规则集与内核。若更新后出现问题，先恢复原数据并保持规则不变；恢复正常后，再单独验证新数据是否包含所需标签。规则标签名称拼写错误时，更换节点不会有帮助。

DNS 应与路由路径一致

DNS 决定域名得到什么地址，路由决定请求如何到达该地址。若域名通过本地 DNS 得到不可达或与出口不匹配的结果，连接会在协议握手前失败。若 DNS 请求本身需要通过代理访问，则必须保证启动阶段已有可用的基础解析路径，避免出现“需要先解析代理服务器，而解析又依赖代理”的循环。

排查 DNS 时先用日志确认请求是否到达客户端，再比较系统工具与客户端内的解析结果。只有域名失败、直接地址可达时，才重点检查解析链；若 TCP 连接已建立后在 TLS 或 REALITY 阶段失败，应核对 serverName、公钥、短标识、指纹和系统时间。把握手错误当成 DNS 问题会把排查带到错误方向。

四步验证法

第一步确认订阅更新结果。节点列表应出现预期内容，当前节点的关键参数完整。第二步执行真连接测试，观察客户端是否能按协议建立实际请求。第三步开启一种接管方式，并让目标应用发起全新的网络请求。第四步在日志中找到与该请求时间对应的域名、目标地址、路由出口或错误信息。四步全部成立，才能说明“节点可连接且应用流量确实进入客户端”。

如果真连接测试成功但浏览器没有变化，重点检查系统代理、浏览器独立代理、旧连接缓存和当前网络服务。如果浏览器请求已进入日志但失败，则查看失败发生在 DNS、TCP、TLS、REALITY 还是远端关闭阶段。如果日志完全没有目标请求，说明接管环节还未成立，不应先调整协议参数。

按错误阶段读日志

日志中的“解析失败”通常指域名没有得到可用地址；“连接超时”表示在限定时间内没有完成网络连接，但原因可能是目标不可达、端口受限或路由错误；“连接被拒绝”说明目标地址有明确响应但该端口未接受连接；TLS 或 REALITY 握手错误则更应检查服务器名称、时间、公钥、短标识和指纹等参数。

日志应按时间线阅读，不要只截取最后一行。最后一行可能只是上层对前面错误的总结。复现前先清空或记住当前时间，只执行一次目标操作，再保存从请求开始到失败结束的连续片段。公开求助时应遮盖订阅地址、用户标识、服务器地址和其他敏感参数，但保留错误类型、时间顺序和客户端操作步骤。

用对照实验缩小范围

有效对照只改变一个变量。例如同一节点在两个网络下测试，可以判断当前网络是否参与问题；同一网络下更换同订阅中的另一个节点，可以比较节点侧差异；保持节点不变，在系统代理与 TUN 之间分别测试，可以判断接管方式；保持其他设置不变，恢复默认 DNS，可以判断自定义解析是否引入异常。

无效对照通常一次改变太多：更新订阅、切换节点、启用 TUN、替换 DNS 和更新规则数据库同时进行。即使问题暂时消失，也无法知道是哪项起作用，下一次故障仍要从头开始。建议为稳定配置保留一份文字记录，包括客户端、接管方式、路由模式和必要的自定义项。

订阅更新与配置备份

订阅更新可能增加、删除或修改节点。更新前若有手工调整的重要配置，应确认客户端是否会在更新时覆盖。订阅节点与本地自建节点最好分组管理，避免更新订阅时误删本地内容。更新后先比较节点数量和名称变化，再选一个节点验证，不必立刻对全部节点进行高频测试。

备份应包含订阅分组信息、必要的路由设置和自定义 DNS，但不要把敏感资料放进公开同步空间。恢复备份后仍需重新确认系统权限、TUN 授权和本地端口，因为这些状态可能不完全包含在客户端配置中。跨平台迁移时也不要假设所有设置字段一一对应，应优先重新导入订阅，再手工恢复少量必要策略。

更新客户端、内核和规则数据

客户端界面、代理内核和 GeoIP、GeoSite 数据属于不同层。更新客户端可能带来界面或配置格式变化；更新内核可能影响协议参数支持；更新规则数据则影响分类标签。稳定环境中应分开更新，每次更新后完成一次基础连接、接管与路由验证。若出现问题，才能准确回退对应层。

不要依据网上某个具体版本号判断本机必须升级。本页不固定版本信息，实际可用包以下载页动态展示为准。更新前退出正在运行的客户端，并保留当前可工作的配置。更新后若旧设置无法加载，先查看迁移提示和日志，不要立即覆盖原配置目录。

订阅更新成功，为什么仍然不能访问？

订阅更新成功只代表客户端取得并解析了配置。接下来还要选择节点、确认节点能完成真连接、开启一种接管方式，并验证应用请求进入日志。先检查当前节点是否真正被设为活动项，再执行一次真连接测试。若测试失败，按日志阶段检查网络、时间和连接参数；若测试成功但应用没有请求日志，检查系统代理、TUN 或 Android 应用分流。

还要注意订阅可能包含暂时不可用或条件不同的节点。不要只测试列表第一项，也不要把全部节点失败简单归因于客户端。选择同一订阅中参数类型不同的少量节点做对照，能帮助判断是单节点问题还是订阅整体问题。

系统代理和 TUN 要同时开启吗？

通常不需要。先根据目标应用选择一种方式。浏览器和多数遵循系统代理的桌面应用先用系统代理；不读取系统代理、需要更广接管范围的应用再评估 TUN。两者同时使用可能仍能工作，但会增加路径判断难度，尤其在 DNS、局域网和虚拟网卡环境中。

从同时开启的状态排查时，先关闭 TUN，只保留系统代理并测试浏览器；系统代理验证成功后，再清除它并单独测试 TUN。这样可以确认两个入口各自是否正常。不要在同一次测试中来回切换而不关闭旧连接，应用可能继续复用原有会话。

退出客户端后为什么网络异常？

最常见原因是系统代理仍指向客户端已经停止监听的本地端口。重新打开客户端，执行“清除系统代理”，再正常退出。Windows 和 macOS 还可以进入系统网络设置核对代理值；Linux 除桌面代理外，还要检查终端环境变量。Android 则查看系统 VPN 状态是否仍保留旧连接。

如果之前使用 TUN，还应确认虚拟接口和路由已撤销。正常停止 TUN通常会恢复，但强制结束进程、系统崩溃或权限异常可能留下状态。Linux 可检查 ip route 与 ip rule，桌面系统则先禁用残留虚拟接口或重启网络服务。恢复网络后再分析日志，不要一开始就删除所有客户端配置。

只有某个应用不能连接，应该换节点吗？

先不要换。浏览器正常而单个应用异常，说明节点和基础接管大概率可用。检查该应用是否遵循系统代理、是否被 Android 应用分流排除、是否使用独立代理、固定 DNS、QUIC 或特殊网络权限。桌面应用若不读取系统代理，可在其设置中指定本地 HTTP 或 SOCKS 端口，或单独测试 TUN。

如果日志能看到该应用请求但特定域名被直连或阻断，再检查路由规则。如果完全没有请求日志，则问题仍在接管层。只有确认请求进入客户端并在远端连接阶段失败时，更换节点才是合理对照。

REALITY 配置连接失败，应检查哪些字段？

先确认服务器地址、端口、用户标识和 flow，再核对 serverName、公钥、短标识与指纹。字段名称可能因客户端界面而略有差异，但取值必须与服务端提供的配置一致。系统时间明显偏差、订阅参数被聊天软件截断、复制时遗漏字符，都可能导致握手失败。

不要自行猜测缺失值，也不要因为看到 VLESS 就默认关闭安全层。REALITY 是与连接安全相关的组合参数，不是单独的节点名称。若配置来自订阅，先更新订阅并比较提供方说明；若来自单链接，重新导入原始链接通常比手工修补更可靠。

更新 GeoIP 或 GeoSite 后客户端无法启动怎么办？

先查看日志是否报告数据库读取失败、分类标签不存在或文件格式不兼容。恢复更新前的数据文件，保持路由规则不变并重新启动。若恢复后正常，说明问题集中在新数据或兼容关系；若仍失败，再检查规则编辑过程中是否出现拼写或 JSON 结构错误。

不要同时更换内核来掩盖数据错误。应分别验证内核、规则和数据库。恢复稳定后，再确认当前内核支持所引用的标签。数据更新与加载回退的完整步骤已在规则数据库维护文章中展开。

DNS 应该填写哪个地址？

没有适合所有网络的固定答案。首先明确 DNS 请求是本地直连还是通过代理出口发送，再选择在该路径上稳定可达的解析服务。若没有特殊需求，先保留客户端默认策略完成连接验证；只有出现域名解析异常、分流需要或隐私边界要求时，再单独调整。

修改后用系统解析工具、浏览器请求和客户端日志交叉确认。若直接地址也无法连接，问题通常不在 DNS；若域名得到地址但在 TLS 或 REALITY 阶段失败，应检查连接参数。不要连续更换多个 DNS 地址而不记录返回结果。

怎样恢复到最小可用配置？

先停止 TUN，清除系统代理和应用分流，恢复默认 DNS 与基础路由。保留一个来源明确的订阅分组，更新后选择一个节点进行真连接测试。测试成功后只开启系统代理，用一个浏览器发起新请求并核对日志。桌面环境若目标应用不遵循系统代理，再单独关闭系统代理、启用 TUN 测试。

Android 上则先取消复杂应用分流，保留系统 VPN 授权并用浏览器测试；Linux 还要清除 shell 中的代理环境变量。最小配置稳定后，按路由、DNS、应用分流和后台策略的顺序逐项恢复。每增加一项就复测一次，这比反复重装客户端更快，也能保留问题发生的证据。