准备工作：安装包与订阅资料
先区分客户端、内核和服务端
v2rayN 是桌面图形客户端，用于管理服务器、订阅分组、代理模式与路由规则；实际建立连接的是客户端调用的代理内核。Windows、macOS、Linux 优先选择 v2rayN，Android 优先选择采用 Xray 内核的 v2rayNG，另有采用 V2Fly 内核的 v2flyNG 作为备选。图形客户端不是服务提供方，安装程序不会自动生成可用服务器，也不会自动获得订阅权限。开始配置前，应准备服务提供方交付的有效订阅地址，或包含完整连接参数的分享链接。
订阅是一份可更新的配置集合，不是网页账号密码。需要确认服务是否仍在有效期内、是否存在流量限制，以及是否对同时连接的设备有要求。仅有服务器地址和端口通常不足以恢复配置，还可能需要用户标识、传输方式、TLS 参数、服务名称等信息。不要根据网上零散示例补写缺失字段；错误的组合可能被客户端正常保存，却无法完成远端握手。订阅地址包含访问凭据，复制时应保留完整内容，分享截图时应遮住整个地址。
确认系统架构，保留恢复路径
从安装包页面按操作系统选择入口，再核对处理器架构。Windows 提供 x64 桌面版和经典 WPF 版；macOS 区分 Apple Silicon 与 Intel；Linux 区分 deb、rpm 以及 x64、arm64；Android 提供 arm64 和通用版。不要把文件能下载等同于本机能运行。系统版本和运行环境要求以安装包说明为准，较旧系统应先确认兼容性，不能仅凭客户端名称相同就覆盖安装。
首次设置前，记录当前是否启用了其他代理、VPN、手动 DNS 或浏览器代理扩展。多个接管工具叠加时，流量可能绕行，也可能形成循环。调试期间一次只保留一条清晰的代理路径。已有客户端的设备，先导出必要设置并记录原来的本地端口、订阅分组和自定义路由；备份中同样可能包含凭据，应放在受控的本地目录。升级与切换界面版本分开进行，保留可恢复的旧配置比反复覆盖更容易定位问题。
| 平台 | 客户端 | 先核对的项目 |
|---|---|---|
| Windows | v2rayN | x64 架构、桌面版或 WPF 版 |
| macOS | v2rayN | Apple Silicon 或 Intel |
| Linux | v2rayN | 软件包格式、处理器与桌面环境 |
| Android | v2rayNG；v2flyNG 备选 | arm64 或通用版、VPN 授权 |
建立最小可用的验证顺序
先打开客户端而不启用 TUN，确认内核可以启动；再导入订阅、更新服务器并指定一个活动配置；随后启用系统代理，使用愿意接受系统代理的浏览器访问目标站点。只有这条基础路径可用，才继续增加 TUN、自定义 DNS 或复杂分流。这样的顺序能把安装问题、订阅问题和流量接管问题拆开，避免同时改动多个变量后无法判断是哪一步生效。
系统时间也属于准备工作。日期、时区或时间同步异常，可能造成证书和部分协议认证失败。测试时选用平时可直接访问的页面作为直连对照，再选一个预期经代理访问的目标，分别记录表现。测速成功只说明测试目标的那条路径可用，并不代表所有网站和应用都走代理。后续验证应结合内核日志、实际页面访问与出口信息，不能只看托盘图标或连接按钮的颜色。
Windows：v2rayN 安装与初始设置
安装界面版本，确认内核能启动
在Windows 下载入口选择 v2rayN。桌面版采用跨平台界面，WPF 版是经典 Windows 界面，两者的菜单位置和配置目录可能不同。初次使用可先选桌面版，已有 WPF 使用习惯时也可继续使用对应入口。安装器按提示完成安装；若取得的是需要解压的分发形式，应先完整解压到固定目录，再运行程序，不要从压缩包预览窗口直接启动，也不要只拷走主程序而遗漏依赖文件。
普通系统代理通常不要求一直以管理员身份运行。首次启动若提示缺少运行环境，应按程序提示补齐对应组件，不要把缺失组件误判为节点失效。打开日志区域，确认客户端调用的内核没有立即退出；若启动失败，先查看安全软件拦截记录、目录写入权限及同名进程是否残留。不要通过关闭全部系统防护来排错，应根据明确的文件来源和错误提示处理。程序目录放在临时下载文件夹，容易在清理后失去依赖或配置，建议使用稳定位置。
订阅分组、服务器与系统代理
打开订阅分组设置，新建一个按来源命名的分组，将完整订阅地址粘贴到地址字段并保存。回到主界面执行更新订阅；如界面提供不同更新方式，首次优先尝试不经过当前代理的更新，避免客户端尚未连通却要求通过自身获取配置。更新完成后检查服务器是否进入预期分组，再选定一个服务器作为活动配置。仅在列表中高亮一行不一定等同于启用，需使用当前界面的设为活动服务器操作并确认状态变化。
运行真连接测速，观察失败原因而不是只按列表排序。选择可用服务器后，将系统代理设置为“自动配置系统代理”，再使用普通浏览器测试。路由可先选择“绕过大陆”等已有预设，以减少初次配置量；需要明确对照时，可临时切换全局代理规则测试同一目标，但要记住系统代理和路由是两个层次。前者决定哪些应用把请求交给本地代理，后者决定内核收到请求后选择哪个出口。浏览器代理扩展可能覆盖系统设置，验证时应先暂停扩展。
TUN 权限与 Windows 特有问题
只有系统代理路径已经验证成功，而目标应用又不遵循系统代理时，才考虑启用 Tun 模式。按当前客户端提示申请管理员权限、安装必要组件或启动所需服务，再观察虚拟网卡与内核日志。允许提权不等于可以忽略启动错误：若 TUN 未成功建立，客户端窗口仍可能正常显示。遇到虚拟网卡创建失败或权限不足，应先退出残留进程并恢复普通系统代理测试，不要连续重复安装网卡组件，也不要随意删除物理网卡或系统路由。
本地端口被占用时，内核往往会报告监听失败。先从客户端设置读出实际端口，再在系统中查询占用进程，确认是否是另一个客户端实例。修改端口后，手动设置过代理的应用也要同步修改，否则会继续连接旧端口。电脑从睡眠恢复、切换有线和无线网络后若失联，先停用 TUN 并重新建立连接，检查网络本身是否恢复，再检查代理。开机自启应在手动连接稳定后开启，并确认登录后没有两个界面版本同时接管代理。
正常退出前先停用 TUN，再使用“清除系统代理”恢复普通网络。异常关机后若所有网页都打不开，检查 Windows 的代理设置是否仍指向已经停止的本地监听端口。这里应清理的是残留代理，不是重置全部网络配置；如果设备由组织策略管理，不要覆盖组织指定的代理。更完整的首次安装说明见v2rayN 首次安装与初始设置，排错时可对照其中的目录和启动检查项。
macOS：芯片选择、权限与代理恢复
选择芯片对应安装包
先在系统的“关于本机”查看处理器信息。显示 Apple 芯片的设备选择 Apple Silicon 安装包，显示 Intel 处理器的设备选择 Intel 安装包；对应入口见macOS 安装包。下载磁盘映像后打开，将应用按提示放入应用程序目录，再从固定位置启动。不要长期从临时挂载的映像内运行，否则卸载映像后，登录项或快捷入口可能指向不存在的位置。完成安装后再处理首次启动提示，避免安装、更新和权限调整同时进行。
遇到系统安全提示时，先确认包来自所选下载入口，再根据“隐私与安全性”中的具体提示决定是否允许打开。不能为了启动一个应用而关闭全局安全机制，也不建议执行来源不明的终端命令清理限制。安装包架构不符、系统版本不满足要求和应用损坏提示是不同问题，应分别核对。窗口能够打开之后，还应确认内核能启动；图形界面可运行并不能证明内核进程或 TUN 所需组件已经具备执行权限。
导入订阅并验证系统代理
在 v2rayN 中建立订阅分组，填写备注和完整订阅地址，保存后执行更新。若订阅更新失败，先在不启用 TUN 的情况下检查当前网络和地址有效性；不要把订阅链接直接粘贴进普通服务器地址字段。更新成功后选定活动服务器，执行真连接测试，再开启自动配置系统代理。测试浏览器时确认没有独立代理配置或扩展接管请求。切换网络前后可用同一个目标页面作对照，避免因为测试目标不同而误判客户端状态。
macOS 的代理设置通常关联具体网络服务。有线网络、无线网络以及其他网络接口可能有各自的设置，切换接口后应重新确认当前使用的服务是否仍指向预期的本地端口。工作设备还可能有配置描述文件或管理策略，客户端无法自由覆盖这些设置时，应先明确限制来源。使用系统代理只会影响遵循这些设置的应用，终端工具和部分应用有自己的连接逻辑；不要因为浏览器已经可用，就假定终端中的每个程序也经过同一条代理路径。
TUN、睡眠恢复与退出处理
需要扩大接管范围时，再按界面要求配置 TUN 权限或辅助服务。不同打包方式可能采用不同的权限流程，应依据当前程序提示处理，而不是照抄其他平台的管理员操作。启用后检查内核是否保持运行，观察是否出现路由创建、设备访问或 DNS 相关错误。如果另一款 VPN 正在占用默认路由或 DNS 配置，先结束冲突连接再测试。不要叠加多个工具并反复切换默认出口，这会让客户端日志与实际流量路径难以对应。
合盖睡眠后恢复连接，网络接口、网关和 DNS 都可能变化。先确认直接网络可用，再重新建立代理连接；如果只有 TUN 模式失败而系统代理正常，应重点检查虚拟接口和路由恢复，而不是立即重新导入订阅。进入需要网页登录的公共网络时，通常要先停用接管完成网络认证，再恢复代理。认证页面打不开不一定是服务器故障，可能是本地网络尚未允许设备访问外网，此时反复换服务器不会改变结果。
关闭窗口不一定等同于退出客户端，应检查菜单栏状态和后台进程。需要恢复普通网络时，先关闭 TUN，再清除客户端设置的系统代理。若客户端异常退出，进入当前网络服务的代理设置，确认有没有残留的本地代理地址；只移除由本次客户端配置的项目，保留原有组织设置。登录项应在连接流程稳定后再添加，升级后如出现旧程序仍驻留后台，要先结束旧实例，再打开新安装的应用，防止同一个端口被重复监听。
Linux：软件包、桌面环境与运行权限
按发行版选择包格式和架构
在Linux 下载入口选择 v2rayN。deb 适用于使用相应包管理体系的发行版，rpm 适用于使用对应体系的发行版；还要核对 x64 与 arm64，不能只看扩展名相同就安装。可在终端运行下方命令查看机器架构与系统信息：常见的 x86_64 对应 x64，aarch64 对应 arm64。系统名称和处理器是两项独立信息，容器、兼容层或远程会话里的结果还应结合实际运行环境判断。
uname -m
cat /etc/os-release优先使用发行版的软件安装器或包管理工具安装本地软件包，让系统处理依赖关系。若提示缺少图形运行组件，先阅读具体依赖名称，不要通过强制忽略依赖继续安装。安装成功但窗口打不开时，可从终端启动已安装的应用查看错误输出；先区分显示环境、运行库和内核启动问题。不要把整个图形客户端长期放在超级用户会话中运行，这可能产生权限不一致的配置文件，也会扩大后续操作的影响范围。
订阅导入与桌面代理差异
打开 v2rayN 后先导入订阅并更新服务器，选定活动配置，确认内核能够监听本地端口，再设置代理。Linux 桌面环境之间的系统代理实现不同：有的提供统一网络代理面板，有的应用只读取自身设置或环境变量。因此“自动配置系统代理”执行成功，也不保证所有桌面程序都会遵循。先用明确支持所选代理类型的浏览器测试，再检查未生效应用的代理设置，避免一开始就把接管范围扩大到整个系统。
终端中的 HTTP 工具可以显式指定代理，用于区分代理链路问题和桌面设置问题。例如下面的命令仅在客户端设置确认 HTTP 或混合监听端口为 10808 时适用；如果实际端口不同，应先修改命令再运行。它让本次请求通过本地代理访问示例站点，不会修改系统代理，也不会把其他程序的流量一起转发。注意返回状态、连接错误和客户端日志是否对应，不要只凭命令结束就判断代理已经生效。
curl --proxy http://127.0.0.1:10808 --head https://example.com若给终端设置过代理环境变量，测试时应记录变量范围。一个终端会话里的变量不一定传给已经打开的图形应用，图形应用的设置也不一定传给终端。退出客户端后仍保留这些变量，会导致命令持续请求已停止的本地端口。排错应先对照显式代理测试，再决定是否调整当前会话配置；不要为了一个命令可用，就在全局启动文件中添加不清楚来源的代理变量。
TUN、DNS 管理与权限边界
Linux 的 TUN 依赖虚拟网络设备、路由操作权限以及客户端当前采用的启动方式。按照客户端文档或界面提供的权限流程配置，先看日志是否提示设备不存在、权限不足或路由冲突。不要给所有程序统一放开权限，也不要在不理解影响的情况下修改可执行文件权限。容器、受限桌面会话和远程环境可能没有可用的虚拟设备或网络管理权限，此时应退回应用级代理，而不是不断重启图形界面。
DNS 还可能由网络管理服务、系统解析服务或手工文件共同影响。TUN 开启后如果域名失败而既有连接正常，先检查客户端的 DNS 设置与系统解析路径，再核对是否存在另一个服务覆盖设置。不要直接清空系统解析配置，因为它可能由网络服务自动生成，重连后又会改变。断开 TUN 后应验证默认路由和 DNS 是否恢复；关闭客户端再检查普通网络，能帮助区分远端故障与本机残留状态。
需要开机或登录后自动启动时，先确认图形会话、密钥存储和网络均已就绪。登录自启与后台服务是不同运行方式，不应在没有明确设计时同时启用。升级后如果普通用户不能写入配置，检查是否曾用高权限运行造成目录归属变化；修复前先备份，范围限定在客户端实际使用的目录。日志中本地监听正常而浏览器失败时，优先检查桌面代理入口，不要急着替换服务器参数。
Android：v2rayNG 与 VPN 连接管理
安装客户端并授权连接
Android 首推 v2rayNG，使用 Xray 内核；需要 V2Fly 内核环境时可选择 v2flyNG。两款客户端是独立应用，不应假设彼此共享订阅、活动服务器或 VPN 状态。到Android 下载入口选择安装包，多数较新的设备可优先核对 arm64；不确定架构或 arm64 无法安装时，结合系统信息选择通用版。通用版适配范围较广，但不代表任何系统版本都满足运行要求。更新已有应用前先保存订阅资料和必要设置。
安装时根据 Android 提示为本次使用的文件来源授予安装权限，完成后可按需要收回该来源权限。若系统提示应用未安装，应核对架构、可用空间、系统兼容性和已有安装来源，不要直接清除数据作为第一步。首次建立连接时会出现系统 VPN 授权，这是客户端通过系统提供的网络接口接管流量所需的确认；授权后仍要检查应用内日志和状态，不能把系统弹窗确认完成当作远端服务器连接成功。
导入订阅、选择服务器与验证
进入订阅分组设置，新增分组并粘贴完整地址，保存后从菜单执行更新订阅。若使用剪贴板导入分享链接，导入的是单个或一组配置，不一定同时建立可自动更新的订阅关系。两种方式应区分记录，否则以后更新时会发现手动导入的服务器没有变化。订阅更新成功后，确认列表中出现预期配置，再选中一个活动服务器；没有活动服务器时，即使点击连接按钮，也无法形成有效的远端连接。
先运行真连接测试，选择测试可用的服务器，然后点击连接按钮并确认状态变化。接着用浏览器访问目标站点，必要时观察出口信息和日志。如果测试成功但某个应用不走代理，检查是否启用了应用级代理范围。只代理所选应用与排除所选应用的含义相反，列表里选中一个应用并不总是表示让它经过代理，必须结合当前模式阅读。更改应用列表或路由后，按界面要求重新建立 VPN 连接，使新设置真正进入运行状态。
后台限制、网络切换与内核差异
Android 通常只允许同一用户环境中有一个活动 VPN 连接。其他 VPN、部分基于 VPN 的网络过滤工具或工作配置可能与当前客户端竞争。出现刚连接就断开时，先核对系统中是否有其他工具自动恢复连接。按应用分流和系统 VPN 的接管范围也要一起检查，不能只改内核路由就期待所有应用都进入代理。桌面端所说的系统代理，不应机械套用到 Android；这里常见的连接方式是客户端通过系统 VPN 服务建立本地接管入口。
熄屏后失联、切回应用立即恢复，往往需要检查电池优化与后台运行限制。按设备系统提供的设置允许必要的后台运行，再观察是否稳定；不要一次性放开所有应用权限。常驻通知用于显示运行状态，隐藏通知不一定能维持后台服务。切换无线网络与移动数据时，原有连接可能需要重建，特别是网络要求网页登录、移动数据尚未可用或设备进入节电状态时。先验证直接网络，再重连客户端，避免把本地网络切换误判为订阅过期。
v2rayNG 与 v2flyNG 的内核家族不同，某个配置能否使用要看内核对其协议、传输与字段的实际支持，而不是只看分享链接能否被导入。切换客户端时重新导入订阅并独立测试，不要直接复制另一款应用的全部内部文件。若服务方明确要求特定内核能力，应以该要求为依据。没有明确兼容性需求时，先保持单一客户端配置稳定，再考虑备选，避免两个应用轮流启动造成连接状态混乱。
系统代理与 TUN：接管范围与本地端口
把接管入口与路由出口分开理解
系统代理告诉遵循系统设置的应用，把请求发送到本机的 HTTP 或 SOCKS 代理入口；它不是对全部流量的强制接管。TUN 则通过虚拟网络接口和路由，让进入相应路径的数据包交给代理内核处理，覆盖面通常更广，但仍受路由、应用排除和系统限制影响。全局代理规则只是内核内部的出口选择，不等于所有应用都已经进入内核。先判断请求有没有到达客户端，再讨论它应该直连还是代理，能避免把两个层次的问题混在一起。
“自动配置系统代理”通常用于写入当前本地代理入口；“清除系统代理”用于撤销相关设置；“不改变系统代理”则保留系统现状。最后一项不意味着内核停止运行，也不意味着此前的设置自动恢复。调试时应明确客户端是否仍在监听、系统是否仍指向该端口以及应用是否遵循系统设置。特别是异常退出后，系统代理可能继续存在，浏览器便会连接一个没有进程监听的端口，表现为所有网站同时失败。
| 设置 | 主要作用 | 不能直接证明的结果 |
|---|---|---|
| 系统代理 | 让遵循设置的应用使用本地代理 | 全部应用均已接管 |
| TUN | 通过虚拟接口与路由接收流量 | 远端服务器一定可用 |
| 路由规则 | 为已进入内核的请求选择出口 | 未进入内核的应用也会生效 |
本地监听、局域网与模式叠加
本地 HTTP、SOCKS 或混合端口是应用连接客户端的入口，不是远端服务器端口。混合端口通常可接收对应内核支持的多种代理请求，但具体协议仍要看设置说明。首次使用保持当前默认监听即可；如果日志提示地址已占用，再查找冲突进程或选择空闲端口。不要将监听地址、服务器地址和订阅地址互相替换。监听在回环地址时主要供本机访问，其他设备不能通过自己的回环地址访问这台电脑。
“允许来自局域网的连接”会扩大可访问范围，只有明确需要共享代理时才开启。开启后还涉及监听地址、防火墙和代理认证，不能仅凭局域网可信就长期暴露入口。若另一台设备要连接，应使用客户端所在机器的局域网地址和实际监听端口，并限制允许访问的网络范围。对于普通单机使用，保持仅本地访问更容易管理。排错期间不要同时开放局域网、修改端口和启用 TUN，否则难以判断是哪项变化导致结果不同。
TUN 的启用和回退顺序
开启 TUN 前，先保存可用的系统代理配置并确认远端连通；再根据平台要求完成权限、组件或服务设置。启用后观察内核是否持续运行，检查路由和 DNS 是否按预期建立。若出现网络全面中断，先停用 TUN、清除残留系统代理，验证直接网络；直接网络恢复后，再退回已知可用的系统代理路径。不要在 TUN 故障期间连续修改服务器传输参数，因为这会破坏原本可用的对照组。
两种模式并非在所有实现中都必须互斥，但初次诊断应采用单一路径。有些环境中应用显式访问本地代理，而该连接又被 TUN 接管，若排除和回环处理不正确，可能产生循环或重复处理。按客户端预设使用，避免自行把代理服务器地址也强制送回同一代理出口。遇到 UDP 应用、游戏或实时通信异常，还需分别确认应用流量是否进入内核、远端是否支持对应转发，以及当前网络是否允许相关通信，不能只用网页测试代替全部验证。
完成配置后，做一次完整的启停检查：连接时目标可访问，停止后直接网络能恢复，重新启动不提示端口或路由冲突。只有这三个环节都稳定，才适合开启自动连接或长期后台运行。更改系统网络设置前保留原始值，遇到受管理设备的限制时不要强行覆盖。模式选择应服务于具体应用需求，而不是认为接管范围越大就一定越合适。
路由与 DNS：规则顺序及分流验证
从预设开始，明确匹配顺序
路由分流根据域名、目标 IP、端口或其他条件选择出口，前提是流量已经进入代理内核。初次使用先选客户端提供的预设，确认普通访问稳定，再逐条添加自定义规则。常见的“绕过大陆”预设会结合规则资源区分直连与代理范围，但实际行为取决于当前内核和规则文件；“全局”也应理解为客户端对应预设的出口策略，而不是操作系统层面的全部应用接管。配置前先明确需要直连的服务和需要代理的服务，避免目标模糊。
规则通常按配置顺序判断，先命中的规则决定处理结果，因此更具体的例外应放在宽泛规则之前。一个覆盖范围很大的直连规则，可能让后面的精确代理规则永远没有机会匹配。修改时一次添加一条，记录测试域名、预期出口和实际日志。不要把来自不同内核的规则片段直接拼接；即使字段名称相似，资源格式、标签命名和默认行为也可能不同。图形界面的路由编辑器与内核原始配置不是同一层，应使用界面支持的导入方式。
域名、IP 与规则资源的关系
域名规则适合表达站点或服务的归属，IP 规则适合处理明确网段和解析后地址。某些连接进入内核时已经只有 IP 信息，域名规则能否匹配还取决于应用请求方式、DNS 路径及嗅探设置。使用 geosite 与 geoip 时，必须确保对应规则资源存在并与内核兼容；资源缺失或标签写错，可能导致启动失败或匹配不符合预期。不要将规则资源更新与订阅更新混为一谈，它们更新的是不同内容，排错时应分别查看结果。
下面是 Xray/V2Ray 风格的路由片段，展示精确域名后缀和私有 IPv4 网段的直连思路。它不是完整连接配置，要求现有配置已定义标签为 direct 的直连出口；没有对应出口就不能直接使用。片段中没有定义代理服务器，也不负责决定未匹配流量的默认去向。若图形界面只接受逐条规则，应按其字段分别录入，不要把整个对象粘进单个域名输入框，更不要用它覆盖客户端生成的完整配置。
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
"outboundTag": "direct"
}
]
}
}DNS 故障与分流故障分别定位
DNS 负责把域名转换为地址，但解析使用的路径与网页连接使用的出口不一定相同。系统 DNS、客户端内置 DNS、浏览器加密 DNS 都可能参与流程。浏览器开启独立解析后，客户端日志中看到的域名信息和系统查询结果可能不同。先确定哪个组件在解析，再决定是否调整；不要同时修改系统解析器、浏览器设置和内核 DNS。使用静态 IP 对照只能帮助缩小范围，不能代替正常域名测试，因为 TLS 和虚拟主机仍可能依赖正确主机名。
当少数站点异常而大部分站点正常，先比较这些站点是否走错出口、是否命中意外规则、解析地址是否符合预期。若仅在切换规则后出现问题，恢复上一份可用规则验证，比更换订阅更有针对性。IPv6 也要纳入观察：如果系统优先得到 IPv6 地址，而当前接管或远端路径没有覆盖对应流量，就可能出现连接不稳定。应按实际网络能力配置双栈路径，不要在没有证据时把全部 IPv6 功能作为故障原因。
测试规则时，新建连接比刷新一个长期保持连接的页面更可靠。浏览器缓存、连接复用和应用内缓存可能让旧出口暂时继续使用。需要时关闭相关应用并重新打开，再观察内核日志中的匹配结果。对规则结构还不熟悉时，可阅读domain、ip 与分流规则实践；多个订阅混用则先做好分组，参阅多订阅分组管理，避免把服务器筛选条件误当成流量路由条件。
配置常见问题：按故障层次恢复连接
先找到失败发生在哪一层
排查顺序从本地开始：程序是否能打开、内核是否持续运行、本地端口是否监听、应用是否把请求交给客户端、远端是否能建立连接，最后再检查路由和 DNS。每一步保留一个明确的验证结果，比同时重装程序和更换订阅更有效。先保存日志中的错误类型和发生时间，但对外提供日志前应删除订阅地址、用户标识及其他凭据。日志等级只在诊断期间按需提高，问题定位后恢复普通等级，避免长时间积累不必要的连接记录。
若所有服务器同时失败，优先检查公共因素：本地网络、系统时间、内核启动状态、订阅有效期和代理模式。只有个别服务器失败时，再核对该配置的地址、端口、传输和 TLS 参数。更新订阅可能修复服务方调整后的配置，但不会修复本地端口被占用或权限不足。具体逐层排查可继续阅读节点超时与无法连接排查顺序，需要简短问答时访问常见问题页。
订阅、测速与浏览器访问
更新订阅成功，为什么没有服务器？
先检查当前分组、搜索条件和过滤规则，避免服务器已导入却被界面隐藏。再核对地址是否指向配置订阅而不是登录页面，服务是否过期，返回内容是否为当前客户端支持的格式。复制地址时可能遗漏查询参数或混入空格，应从服务提供方重新获取完整链接。不要反复创建同名分组，因为这会让后续更新结果更难判断。保留原分组并逐项修正，再确认更新日志中的具体结果。
TCPing 可用，真连接测试却失败，先看什么？
TCPing 主要检查目标端口能否建立 TCP 连接，不会完整验证协议认证、TLS 与目标访问。真连接测试失败时，先看握手、证书、认证和解析错误，再核对系统时间及服务方配置。反过来，真连接测试也只验证其测试目标，不代表所有目的站点都能访问。如果只有测试目标不可用，应换实际业务页面作对照，而不是仅按一个测试结果删除全部配置。
浏览器能访问，其他应用为什么仍然失败？
先确认其他应用是否读取系统代理，是否有独立代理设置，以及是否被应用分流排除。浏览器扩展可能单独提供了代理入口，因此浏览器可用也不一定证明系统代理正确。需要 TUN 时按权限流程启用，并检查目标应用是否进入接管范围；涉及 UDP 的应用还要核对内核与远端能力。使用相同服务器、相同网络和相同目标做对照，才能把应用差异与远端故障区分开。
退出恢复、更新与配置备份
退出客户端后断网，是否必须重置系统网络？
通常应先检查残留系统代理、终端代理变量、VPN 状态和 TUN 路由。清除由客户端写入的代理，断开仍在运行的接管服务，再验证普通网络。若直接网络本来就不可用，应先处理无线连接、网关或网页登录认证。网络重置影响面较大，不应作为默认第一步；组织管理的设备尤其要保留原有网络策略，不能为了清理本地代理而删除全部配置。
升级前记录安装方式、配置目录和正在使用的界面版本，导出订阅分组及自定义路由，并把备份放在受控位置。配置备份可能含有服务器凭据，不能直接发布到公开讨论区。升级后先验证旧的最小可用路径，再检查新设置；遇到配置迁移异常时，不要在同一目录交替运行多个版本反复保存。若需要重新建立配置，优先从完整订阅恢复服务器，再逐项迁移手工路由和应用规则，避免一次性复制错误状态。
完整恢复后，用连接、停止、再次连接三个动作做收尾验证，并记录最终采用的模式和端口。这样下次遇到相同问题时，可以先回到已知可用状态，而不是从头修改全部参数。首次使用者可回到快速上手教程串联操作；已经明确平台和架构的读者，直接进入安装包页面选择对应客户端。手册用于解释设置边界，具体菜单和权限提示始终以当前客户端及操作系统实际显示为准。