准备 / 客户端与网络边界
通用准备：明确配置来源与接管方式
先区分客户端、内核与连接配置
v2rayN 是桌面图形客户端，负责保存服务器资料、管理订阅、生成运行配置，并控制系统代理等功能；实际建立连接的是它调用的内核。Project V 是相关代理技术的项目背景，V2Fly 与 Xray 是常见内核家族。Android 端可选以 Xray 为内核的 v2rayNG，或以 V2Fly 为内核的 v2flyNG。客户端名称相似，不代表参数支持完全相同。收到连接资料后，应先确认协议、传输方式与安全设置，再确认所选客户端及内核能否处理。
安装客户端并不会自动获得可用服务器。开始前需要准备可信来源的订阅地址、单条分享链接，或完整的服务器参数。订阅地址通常带有账户识别信息，能够读取它的人可能取得相同的连接资料，因此不应公开贴进截图、论坛或共享笔记。还要确认系统日期与时区正确，网络本身能正常访问必要的服务。时间明显错误会影响证书验证，也可能使部分依赖时间的认证失败，容易被误判为节点不可用。
识别架构，再选择安装入口
桌面端优先使用 v2rayN，并在下载页按系统和处理器架构选择。Mac 在“关于本机”查看芯片；Windows 查看“系统信息”中的系统类型；Linux 同时确认处理器架构和发行版的软件包格式。Android 通常选择 arm64，只有设备架构不确定或安装提示不兼容时才考虑通用包。不要用文件名中的某个熟悉词猜架构，也不要把不同系统的包混用。已有客户端时，先记录当前工作模式与必要设置，再安排升级，避免把升级和网络改动混在一次操作里。
| 方式 | 接管入口 | 主要边界 |
|---|---|---|
| 系统代理 | 操作系统的代理设置 | 应用必须愿意读取并使用该设置 |
| 应用手动代理 | 应用自己的 HTTP 或 SOCKS 设置 | 仅影响设置过的应用 |
| TUN | 虚拟网络接口与路由 | 取决于权限、排除规则与内核实现 |
建立可回退的初始状态
首次配置从系统代理开始，不要同时开启 TUN、第三方网络加速、另一套代理客户端和自定义 DNS。系统代理只是把遵循设置的应用交给本地监听端口，不等于所有网络连接都会经过代理。TUN 则通过虚拟接口接管符合规则的流量，涉及路由和权限，排查范围更广。只为浏览器建立连接时，先用系统代理即可；确有应用不读取系统代理，再研究手动代理或 TUN。把需求与模式对应，才能知道哪些现象属于正常边界。
记录客户端显示的实际监听地址、端口与当前服务器，不要把示例端口当成本机事实。默认仅供本机使用时，应保留回环监听地址，避免直接开放给整个局域网。测试前选一个普通 HTTPS 页面，并准备另一个独立服务作为对照；单一网站的账户限制、地区策略或服务异常，不能证明客户端整体故障。更改设置时一次只动一项，保存后观察日志与访问结果，再决定保留还是恢复。
安装前也应检查存储位置是否可写，是否有旧进程占用监听端口，以及公司或学校设备是否由管理策略统一控制网络。受管理设备上的代理、证书与虚拟网络权限可能无法自行修改。此时应遵循设备管理要求，不要绕过策略反复尝试。对于已有可用配置的设备，先导出必要资料并妥善保存；配置导出可能包含访问凭据，不能当成普通无敏感信息的设置文件传播。
平台 / macOS
macOS：安装 v2rayN 与系统代理设置
按芯片安装，并固定应用位置
打开苹果菜单中的“关于本机”，看到 Apple 系列芯片选择 Apple Silicon 入口，看到 Intel 处理器选择 Intel 入口。进入macOS 下载区取得对应安装包，打开磁盘映像后，将 v2rayN 拖到“应用程序”，再从该目录启动。不要长期在磁盘映像内运行，也不要把程序放进可能被清理的临时目录。固定应用位置有利于保存权限与后续更新；首次启动后若要退出，可推出安装映像，不影响已复制的应用。
系统提示无法打开时，先核对下载来源、芯片选择和安装是否完成，再查看“系统设置 → 隐私与安全性”是否提供针对这次启动的允许操作。只在确认来源后使用系统提供的单次放行方式，不要为打开一个程序关闭整套系统保护。若设备由组织管理，权限可能受策略限制。反复双击通常不能改变结果，应保留提示的完整文字，区分系统安全拦截、应用损坏提示与处理器不兼容，这些问题对应的解决路径不同。
导入订阅，先验证当前服务器
进入订阅分组相关设置，新建分组并填入完整订阅地址。保存分组后，还需要执行订阅更新，分组名称出现不代表服务器已经下载成功。更新结束检查服务器列表，再选择其中一项作为当前服务器。若手里是以协议前缀开头的单条分享链接，应走剪贴板导入入口，而不是填进远程订阅地址栏。不同构建中的菜单布局可能变化，操作目标始终是“保存订阅来源 → 更新 → 选择服务器”，不要只照某张截图找按钮。
接着启用“自动配置系统代理”，确认客户端内核已启动。该操作会写入系统网络代理设置，使愿意遵循这些设置的应用连接到本地代理。更换 Wi-Fi、连接有线网络或新建网络服务后，如果访问表现不同，应查看当前活动网络服务的代理页，确认它指向客户端正在监听的地址与端口。不要盲目将所有代理协议都勾选；HTTP、HTTPS 和 SOCKS 是否需要配置，应以客户端的自动设置及所用应用要求为准。
TUN、睡眠恢复与退出后的网络
系统代理能够工作后，再评估是否需要 TUN。开启前阅读当前构建的权限提示，按要求授权辅助组件或网络相关能力，并确认没有其他虚拟网络工具同时接管默认路由。TUN 启动后若普通网络反而失效，先关闭它，验证系统代理模式是否仍然正常。不能因为开关显示启用，就认为虚拟接口、路由与 DNS 都已成功建立；应结合日志判断内核有没有报权限不足、接口创建失败或路由写入失败。
Mac 从睡眠恢复、网络热点切换或外接扩展坞后，原有连接可能已经失效。先确认当前网络可用，再重新连接客户端；若仅个别应用异常，完全退出并重开该应用，避免旧连接池继续使用断开的连接。浏览器正常而终端失败并不罕见，许多命令行程序不读取系统代理，需要单独指定代理参数。反过来，终端可用也不能证明浏览器没有独立代理设置或扩展干预，测试时要区分入口。
正常退出前先清除系统代理并关闭 TUN。若应用意外退出后网页打不开，进入当前网络服务的代理设置，检查是否仍指向已经停止的本地端口；确认属于本次客户端写入的项目后再移除。不要删除不认识的组织代理配置。需要共享给同一网络的设备时，也不能只把本机回环地址发给对方，应额外处理监听范围和防火墙，细节见允许局域网连接说明。
平台 / Windows
Windows：桌面版、WPF 与代理接管
选择界面分支，避免共用运行目录
Windows 下载区提供 v2rayN 桌面版与经典 WPF 版入口。桌面版采用新一代跨平台界面，WPF 版保留经典 Windows 界面；两者都是图形客户端，不能把界面差异理解为服务器协议天然不同。按设备架构和安装包说明选择，缺少运行组件时依据明确的启动提示处理。不要凭其他用户的截图推断本机一定缺少某项依赖，更不要为了测试启动而批量安装来源不明的运行组件集合。
安装或解压位置应保持可写，避免在只读目录、临时压缩包视图中直接运行。若需要同时比较两种界面，使用各自独立的程序与数据位置，先导出必要配置，不要直接让两个进程共同改写同一份数据。确认任务栏或托盘里没有旧实例驻留；重复启动可能造成端口占用，也可能让用户误以为改动未生效，因为正在接管系统代理的其实是另一个实例。关闭窗口是否退出程序，要以托盘状态和进程为准。
订阅更新与系统代理不是同一步
添加订阅分组后执行更新，再到服务器列表选择当前服务器。先看更新日志是否成功取得内容，再判断服务器本身能否连接。对于从其他设备复制的链接，特别注意换行、空格和末尾查询参数；聊天工具有时会把显示文字与实际链接分开。导入后若名称正常但连接失败，应检查协议、安全层和传输字段是否完整，不要只依据服务器名称判断配置等价。手动修改前先保存原始资料，以便恢复。
启用“自动配置系统代理”后，遵循 Windows 用户代理设置的应用会尝试使用本地代理。浏览器能访问不意味着系统服务、后台更新程序或全部命令行工具都走同一路径，一些程序使用独立代理设置或不同网络接口。首次测试保持默认用户权限即可，只有 TUN 或明确提示需要的系统操作才申请更高权限。长期以管理员身份运行并不能修复错误的订阅或不匹配的服务器参数，反而会混淆权限与配置问题。
处理防火墙、TUN 与端口冲突
如果日志提示绑定端口失败，先停止其他代理程序并检查旧的 v2rayN 进程，再考虑更换本地端口。改变端口后，所有手动填写过代理的应用都要同步调整；系统代理也应重新应用。防火墙提示需要根据程序来源、网络类型和使用范围决定，单机使用通常不需要主动开放对局域网的入站访问。不要通过关闭整套防火墙来判断问题，应该定位被阻止的具体程序或连接，再添加范围明确的规则。
TUN 涉及虚拟网络接口、路由和权限，启用前先验证系统代理模式。设备上同时运行其他虚拟网络工具时，可能出现默认路由、DNS 或网段冲突。遇到 TUN 启动后全部断网，先停用 TUN 并恢复普通连接，接着查看接口创建和路由相关日志。若关闭其他工具后恢复正常，应逐一比较它们的接管范围，而不是反复重装客户端。远程桌面环境更要谨慎，路由变动可能中断当前管理连接。
恢复网络时先在客户端清除系统代理，再退出程序；如果客户端已崩溃，可在 Windows 的代理设置中核对残留的手动代理。自动配置脚本与手动代理是不同入口，若设备本来由组织下发脚本，不应一并清空。系统休眠或网络切换后，也可以先重启连接而不是重装应用。升级前保存订阅来源和自定义路由，升级后先复测原有系统代理流程，再开启额外功能，这样一旦异常就能判断是升级变化还是新设置引起。
平台 / Linux
Linux：软件包、桌面代理与权限边界
同时确认架构与发行版包格式
Linux 安装前需要做两次判断：处理器是 x86_64 还是 aarch64，以及发行版使用 deb 还是 rpm 软件包。前者决定程序能否执行，后者决定系统包管理器能否安装，二者不能互相替代。进入Linux 下载区按架构和格式选择 v2rayN。图形安装器无法处理软件包时，先查看具体报错，区分架构不匹配、依赖缺失和系统环境不满足，不要把所有安装失败都当成文件损坏。
可在终端使用下面的只读命令确认环境。uname -m 的 x86_64 通常对应 x64，aarch64 通常对应 arm64；发行版名称与版本信息可帮助判断包管理体系，但不代表任意同格式软件包都一定兼容。安装依赖时使用发行版本身的软件源与包管理流程，避免从多个不明来源拼接底层库。若程序启动后立即退出，可从桌面应用启动记录或终端输出读取错误，先确认是图形环境问题还是内核没有启动。
uname -m
cat /etc/os-release订阅导入后，检查桌面环境的代理设置
启动 v2rayN 后建立订阅分组，保存地址并更新服务器列表，再选定当前服务器。Linux 的剪贴板由桌面会话管理，远程会话、不同显示协议或权限变化都可能导致读取失败。如果剪贴板导入没有反应，应先确认链接确实存在于当前用户的剪贴板，必要时使用客户端提供的手动输入方式。不要把剪贴板读取失败误判为协议不支持，也不要为此把整个客户端提升为高权限运行，以免数据归属和桌面会话脱节。
不同桌面环境对系统代理的实现并不一致。客户端自动设置完成后，应进入当前桌面环境的网络代理页确认，而不是假定所有发行版行为相同。浏览器可能读取桌面代理，终端程序则经常依赖自身参数或代理环境变量；已经启动的进程也不一定会重新读取环境变化。测试时可以暂时对某个命令显式指定代理，从而把“内核连接是否正常”和“桌面代理是否被读取”分开判断。下面的诊断命令将在故障章节说明。
理解回环监听与 TUN 权限
本机使用应优先绑定回环地址。绑定到全部网络接口并不只是让本机更容易连接，还可能把端口暴露给同网段设备，需要同时考虑防火墙与访问控制。服务器列表中选定的远程地址，与本地入站监听地址是两类参数，不要相互替换。端口被占用时，先检查旧客户端或其他代理进程；更换端口后重新应用桌面代理，并更新终端或应用里写死的地址，否则新内核正常监听，应用仍会连接旧位置。
TUN 通常需要创建虚拟接口及修改路由的权限，具体授权方式取决于发行版和客户端构建。按客户端的明确说明完成授权，不要随意赋予整个程序目录广泛权限。先以普通用户管理订阅与配置，再处理明确需要的网络能力；使用不同用户启动可能产生不同的数据目录，表现为“服务器列表消失”。遇到这类情况先核对运行用户和数据位置，不要立即覆盖原目录，也不要把空白界面当成原资料已经被删除。
网络异常时检查是否同时存在容器网络、其他隧道和自定义路由，它们可能与 TUN 的接管范围重叠。若 TUN 关闭后恢复，应从路由及 DNS 入手，而不是修改远程服务器参数。退出前恢复桌面代理；异常退出后，再检查代理环境变量是否仍被启动脚本持久设置。维护时保留可用配置副本，安装更新后验证程序启动、订阅更新、系统代理和 TUN 四个环节，避免把桌面环境的变更误归因于客户端本身。
平台 / Android
Android：v2rayNG、v2flyNG 与 VPN 授权
先选内核，再选安装包架构
Android 下载区首推 v2rayNG，它使用 Xray 内核；v2flyNG 使用 V2Fly 内核，作为需要相应兼容性的备选。选择时以服务器协议和传输参数为依据，不要根据名称相似就来回切换。多数较新的主流设备可选择 arm64，通用包覆盖更多架构但体积通常更大。若安装器提示解析失败或不兼容，应核对系统要求、包是否下载完成和架构，不能只把所有错误归结为手机性能不足。
从浏览器或文件管理器打开安装包时，Android 可能要求允许该来源安装应用。只对实际使用的来源进行必要授权，安装结束后可按自身安全习惯收回。更新已有客户端时，系统可能因签名、安装来源或包身份不同拒绝覆盖；先保存需要保留的订阅与自定义设置，再判断是否要迁移。直接卸载会影响应用内部数据，不应把它作为第一步。尤其不要把弹窗中的“更新失败”理解成已有服务器配置也一定失效。
导入、更新与启动服务
在 v2rayNG 的订阅分组设置中添加地址，保存后执行订阅更新，随后回到服务器列表选中一项。如果收到的是单条分享链接，可以使用剪贴板或二维码导入入口；二维码只是传递配置的载体，并不天然比文本链接包含更多参数。确认当前选择的是刚导入的服务器，避免列表更新后仍连着旧条目。v2flyNG 的入口名称可能不同，但同样需要区分远程订阅更新与单条配置导入，不能把普通网页地址当作订阅。
启动连接时，系统会请求建立 VPN 连接的授权。该授权允许客户端通过 Android 的虚拟网络接口接收流量，并不表示服务器已经连接成功，也不代表所有应用必然走远程代理。系统状态栏出现连接标识，只能说明接管机制处于工作状态，还需要结合客户端日志和实际访问判断。不要把桌面端“写入系统代理”的经验直接套用过来：Android 客户端通常以系统 VPN 服务建立入口，路由规则仍可把部分请求送往直连。
按应用分流与后台保持
按应用代理通常存在“只代理选中应用”和“绕过选中应用”等相反逻辑，具体以界面说明为准。修改后应停止并重新启动服务，再测试目标应用，避免旧连接继续保留原路径。排查时先关闭按应用筛选，让入口范围保持明确；确认基本连接正常，再逐一加入例外。网页能开但某个应用不能用，还可能与该应用的独立 DNS、长连接、账户状态或服务策略有关，不能仅凭一次失败就改变整个客户端的协议设置。
如果屏幕亮着正常、锁屏后断开，应检查电池优化、后台活动与厂商自启动管理。只为确有需要的客户端放宽限制，不必关闭所有系统节能功能。客户端常驻通知被系统限制时，也可能影响后台服务持续运行。网络从 Wi-Fi 切到移动数据后，先等系统完成切换，再重启连接测试；如果仅某种网络失败，比较网络权限和服务器可达性，而不是立即删除订阅。移动网络的信号、计费限制和热点环境也会影响结果。
初期不要立刻启用始终开启或阻止未经过 VPN 的连接等系统策略。先确认客户端在重启、锁屏和网络切换后都能恢复，否则强制阻断策略会让普通网络也无法使用。出现完全断网时，先停止连接并恢复系统网络，再查看客户端日志。换用 v2flyNG 也不是通用修复方法，只有明确判断为协议或内核兼容性差异时才值得对照；迁移时重新检查路由、DNS 与按应用规则，不能只复制服务器条目就视作完整迁移。
配置 / 订阅与节点资料
订阅管理：格式、更新与跨设备同步
识别远程订阅、分享链接与完整配置
远程订阅地址是客户端请求配置内容的入口，通常表现为 HTTPS 地址。单条分享链接则以 vmess://、vless:// 等协议前缀表示一项连接资料。完整 JSON 配置还可能同时包含入站、出站、DNS 与路由，不能把三者当成可以随意互换的文本。看到很长的编码字符串，也不能仅凭外观判断它是订阅还是单条链接；应依据来源说明和客户端支持的导入方式处理，避免反复转码把原始数据破坏。
部分订阅使用 Base64 包装多条分享链接，另一些直接返回客户端可理解的结构化内容。Base64 是编码方式，不是保护访问权限的加密措施。客户端是否能处理某个订阅，取决于返回格式与内核兼容性，而不只取决于链接能不能在浏览器打开。更细的入口对照可查阅订阅导入与 Base64、URI 格式说明。若服务返回的是登录页、错误页面或验证页面，客户端通常无法把它解析成服务器列表。
把更新失败分为请求与解析两层
订阅分组保存成功，只说明地址进入了本地设置。执行更新后，先看客户端有没有取得远程响应，再看响应能否解析。连接超时、证书验证错误属于请求阶段；提示格式不支持、内容为空则需要检查返回内容与订阅类型。遇到更新失败，不要先删除原有可用条目；保留当前分组和日志，确认地址没有过期、查询参数没有丢失，并检查系统时间。公开转发日志前应遮住完整订阅地址与账户识别信息。
更新是否通过代理，由客户端的更新选项与实现决定。只有确认当前网络不能直连订阅入口、而已有代理确实可用时，才尝试相应的通过代理更新选项。没有任何可用服务器时，开启这一选项可能形成依赖循环：需要更新才能得到服务器，却又需要服务器才能更新。此时应恢复可直接访问的更新路径，或向配置提供方确认适合当前网络的获取方式，不要不停切换未知节点并重复请求。
管理分组与手动修改的生命周期
按来源或用途划分订阅组，有利于确认哪些服务器由哪个地址维护。订阅更新可能重建条目、刷新名称或覆盖字段，因此不要默认手动改过的服务器会永久保留。需要试验参数时，先复制为独立配置，清楚标注它不再自动跟随原订阅，并记录修改原因。订阅更新后应重新确认当前服务器，名称一样也可能代表地址或传输参数已有变化；旧连接是否重建，则取决于客户端的运行行为。
跨设备复用订阅主要同步服务器资料，并不保证路由、DNS、按应用筛选、系统代理和 TUN 权限一起迁移。Mac 上的进程规则也不能直接当成 Android 的应用规则使用。二维码适合少量单条资料的传递，完整导出更适合迁移本地设置，但需要核对目标客户端能否导入相同格式。可以参考多设备同步方案，先确定要同步的是服务器来源，还是整套客户端行为，再选择方法。
更新频率也应与实际需要相符，不要用高频刷新代替排障。若多个设备同时出现空列表，先核对来源状态和返回格式，再分别检查客户端兼容性；若只有一台失败，优先比较本地网络、代理更新选项和系统时间。配置提供方撤销或替换条目后，旧客户端仍保留名称不代表它还能连接。清理前先确认分组归属，避免把手动配置一并删除，并保留足够的信息用于恢复，而不是只记住一个容易重复的服务器显示名称。
配置 / 入站、出站与解析
路由与 DNS：按请求链路理解配置
从入站到出站，而不是从按钮猜行为
一个请求通常先进入本地入站，再由路由规则决定交给哪个出站。inbounds 描述本地监听方式，outbounds 描述实际连接去向，routing 在两者之间作选择。系统代理与 TUN 解决的是流量怎样进入客户端，路由解决的是进入以后怎样处理。“全局”通常是尽量把已接管请求送到代理出站，不等于强迫所有应用使用客户端；“规则”则按条件区分代理、直连或阻断。界面标签最终都要落实到配置内容。
下面是一份用于检查本地入站与标签关系的最小 V2Ray 配置。它只包含直连与阻断出站，不提供远程代理连接，也不是要覆盖客户端自动生成的运行文件。两个端口仅是教学示例，若本机已占用就不能同时启动。回环监听限制为本机访问，direct 与 block 是自定义标签，真正的行为分别由 freedom 和 blackhole 协议决定。理解这一点，才能避免把标签名称当成内核预设功能。
{
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
},
{
"tag": "http-in",
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http",
"settings": {}
}
],
"outbounds": [
{ "tag": "direct", "protocol": "freedom", "settings": {} },
{ "tag": "block", "protocol": "blackhole", "settings": {} }
],
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "direct"
}
]
}
}规则按顺序匹配，资源文件也参与结果
常见路由配置按规则顺序检查，先命中的规则决定处理方式，所以具体例外一般应放在宽泛条件之前。outboundTag 必须与真实存在的出站标签一致，拼写不一致并不会自动纠正。没有命中规则时的默认出口，需要结合内核配置和客户端生成方式确认。阅读config.json 结构拆解时，应把完整出站列表与规则一起看，不要单独截取一行就判断最终流向。
geosite 表示域名集合，geoip 表示 IP 地址集合，它们不是对任意目标都自动成立的魔法关键词。使用相关规则前，需要确认当前内核支持相应语法，且所需资源文件存在并能加载。域名集合与 IP 地理归属也不能替代具体服务策略，多地址服务、内容分发和规则数据变化都会影响命中。配置境内直连等方案时，先明确目标范围，参考geosite 与 geoip 分流说明，再通过日志核对实际结果。
区分系统 DNS、内核 DNS 与远端解析
DNS 可能发生在应用、操作系统、客户端内核或远程连接的另一端。只修改系统 DNS，不代表已改变所有代理请求的解析路径；应用启用独立的加密解析时，也可能绕过系统设置。domainStrategy 影响路由判断何时需要解析域名，不是“改成某值就全部远端解析”的总开关。常见的 IPIfNonMatch 会在域名规则未匹配时尝试通过解析补充 IP 匹配，但具体交互仍应以所用内核的配置语义为准。
排查 DNS 时先判断域名有没有解析成功，再看得到地址后连接是否建立。出现证书名称不符时，不应通过关闭证书验证来掩盖问题，而要核对目标域名、安全层服务器名称及网络是否存在认证页面。TUN 下还要留意 DNS 请求是否被接管、解析服务器本身是否可达，以及是否形成递归依赖。每次只调整一处解析入口，记录修改前后的日志；同时更换 DNS、规则和服务器，即使恢复连接也无法知道是哪一项起作用。
排查 / 从现象定位到层级
配置常见问题：按层验证与恢复
先判断基础网络与本地监听
遇到无法访问时，先关闭 TUN、清除系统代理并停止其他接管工具，验证普通网络是否正常。酒店或公共网络可能需要先完成网页认证；基础网络本身未连通时，继续换服务器通常没有意义。恢复普通网络后，再启动客户端并确认内核运行状态。日志里的“连接被拒绝”若发生在本地回环地址，通常优先检查监听是否存在、端口是否写错，而不是检查远程服务器密码；同样一句错误，目标地址不同，定位方向也不同。
如果客户端显示运行中，但所有应用都连不上，先核对本地监听端口，再用显式代理请求隔离系统设置因素。下面命令适用于提供 curl 的桌面环境，示例假设本地 SOCKS 端口为 10808，使用前必须替换为客户端实际显示的端口。socks5h 会把域名交给代理端处理；命令访问的示例站点只是普通 HTTPS 测试目标。测试成功只能证明这条链路可用，不能代表所有应用或所有协议都已经被接管。
curl --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 10 \
--max-time 20 \
--head https://example.com/若显式代理成功而浏览器失败，应检查系统代理是否应用到当前网络、浏览器是否有独立代理，以及扩展是否覆盖设置。若显式代理也失败，则看内核日志区分本地入口、远端连接与握手错误。不要把终端的成功结果直接套用于 Android；移动端应通过客户端日志和应用访问对照判断。测试过程中保持同一个服务器与同一目标，先控制变量，再更换对照项，才能避免网络波动造成误判。
按错误类型决定下一步
连接超时优先检查目标地址、端口、当前网络可达性与服务器状态；认证失败优先核对凭据和协议字段；TLS 握手失败则检查系统时间、安全层服务器名称、传输设置与服务端要求。某个字段为空不一定错误，也不应随意从其他配置抄一个值填入。传输参数是成组配合的，只修改其中一项往往会造成更难辨认的失败。日志可缩小范围，却通常不能单凭一行文字确定唯一原因，需要结合改动记录与对照测试。
订阅能更新但服务器都失败，说明获取资料的路径至少部分可用，不代表代理连接参数已经验证。只有部分服务器失败时，优先对照这些条目的协议和传输差异；所有服务器同时失败时，再检查公共因素，例如系统时间、内核启动和网络环境。只有某个网站异常，则要分别考虑 DNS、规则命中、目标服务状态与账户限制。不要为了一个服务就把全部流量模式改掉，也不要把客户端显示的连通性测试当作业务访问的完整替代。
TUN 故障与网络恢复分开处理
系统代理正常、TUN 异常时，远程连接资料通常不是第一怀疑对象。先检查权限、虚拟接口、路由、DNS 和其他隧道的重叠情况；关闭 TUN 后若立即恢复，保留这一对照结果。需要从远程管理设备时，避免直接修改默认路由，先准备本地恢复手段。切换网络后出错，可以先停止并重启接管服务，不必立即清空全部设置。重新安装往往会保留或改变部分数据，不能作为判断配置正确与否的可靠实验。
正常退出后断网，检查系统代理是否残留；TUN 停止后异常，检查其他网络工具是否仍在运行，并先恢复系统的普通联网状态。提交问题前记录系统与架构、客户端名称、接管模式、失败发生时间、是否能复现，以及最近一次改动。日志只保留与故障相关的片段，遮住订阅地址、用户标识和服务器凭据。提供“显式代理成功、系统代理失败”这样的对照，比只写“不能用”更容易确定排查入口。
需要重新走操作主线时，返回使用文档，按导入、选择模式和验证的顺序执行；需要换平台安装时，进入客户端下载页核对系统与芯片。日常维护把订阅更新、客户端升级和网络策略调整分开进行，并保留可回退的记录。这样既能减少配置之间的相互影响，也能在出现问题时明确故障层级，而不是依赖反复重装或同时切换多个开关。