开始之前
通用准备：客户端、订阅与代理模式
如果只需要完成一次基础连接，可以先读篇幅更短的快速上手教程。本页承担系统查阅功能：每个平台从下载与安装讲起，再分别处理订阅、系统代理、TUN、权限和平台限制。遇到具体问题时，不必从头阅读，可以通过上方目录直接进入对应章节。所有客户端应从下载中心按平台选择，桌面与移动平台均优先考虑 Clash Plus；其他可选项与维护状态也以下载页当前清单为准。
先分清客户端、内核和配置文件
Clash 使用过程包含三个相互独立的部分。客户端提供窗口、菜单、开关和订阅管理；mihomo 等内核负责监听端口、解析 DNS、匹配规则并建立连接；配置文件则记录代理信息、策略组、规则、DNS 与 TUN 参数。更换界面客户端并不等于更换订阅，导入同一份兼容配置后，规则结果通常保持一致。反过来，如果客户端界面能正常打开，但内核没有启动，系统代理即使已写入也不会产生有效转发。
订阅链接通常由服务提供方生成。客户端获取链接后，会下载一份 YAML 配置或经过转换的配置内容。导入成功只说明格式可以读取，不代表其中的代理入口一定可连接。为了减少变量，首次配置建议先保留订阅原有规则，不要立即叠加大量自定义规则、覆写 DNS 或改动监听端口。确认基础连接稳定后，再逐项加入个人设置，每次只改一个部分，排错时更容易回退。
订阅导入前的检查
复制链接时应确认没有带入前后空格、换行或聊天软件附加的标点。链接属于个人配置入口，不宜发到公开页面或截图中。若服务方同时提供“一键导入”和普通订阅地址，优先使用客户端明确支持的导入方式；普通地址则粘贴到“订阅”“配置”或“Profiles”页面。导入完成后，先观察配置名称、策略组和规则是否出现，再把该配置设为当前配置。仅把地址存进客户端而没有启用对应配置，是新安装后最常见的遗漏之一。
系统代理与 TUN 的选择
系统代理适合浏览器、桌面通讯工具和主动读取操作系统代理设置的应用。客户端通常会写入 HTTP 与 SOCKS 监听地址，常见本机地址是 127.0.0.1，端口由配置中的 mixed-port、port 或 socks-port 决定。它的优点是权限要求低、开关清晰；限制是某些游戏、命令行程序、商店应用和自带网络栈的软件可能忽略系统代理。
TUN 模式通过虚拟网络接口接管更广的系统流量，适合不能读取系统代理的程序，也能统一处理更多 TCP、UDP 和 DNS 请求。代价是需要较高系统权限，并可能与其他 VPN、虚拟机、容器网络、安全软件或企业网络组件冲突。首次使用时建议先验证系统代理，再根据实际需要开启 TUN，而不是同时打开多套接管工具。移动端的 VPN 开关在工作方式上更接近 TUN，系统通常只允许一个此类网络扩展处于活动状态。
| 工作方式 | 适合场景 | 需要关注 |
|---|---|---|
| 系统代理 | 浏览器、常规桌面应用、日常分流 | 应用是否读取系统代理，退出时是否恢复设置 |
| TUN 或移动端 VPN | 游戏、命令行、UDP、忽略系统代理的应用 | 管理员权限、路由冲突、DNS 接管与其他 VPN |
| 应用内代理 | 只希望单个工具经过本机 SOCKS 或 HTTP 端口 | 代理协议、监听地址和端口必须与客户端一致 |
建立可重复的验证步骤
每个平台都可以使用同一套验证顺序：先确认客户端内核处于运行状态；再确认当前配置确实被选中；随后检查代理模式是规则、全局还是直连；然后查看目标请求在连接记录中命中了哪个规则与策略组；最后才判断代理入口本身是否可用。只看网页是否打开，很难区分 DNS、规则、代理入口和系统接管中哪一层出了问题。连接记录与日志能提供更可靠的依据，相关错误字段可继续参考Clash 日志报错定位方法。
桌面平台
Windows：安装、订阅与系统网络接管
Windows 上可选择 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu，以及用于归档场景的 Clash for Windows。新配置优先使用仍在维护并支持 mihomo 的客户端。下载时先在“设置 → 系统 → 系统信息”确认设备架构，多数常见电脑使用 x64；只有明确采用 ARM 处理器的设备才需要 ARM 版本。安装包与便携压缩包的使用方式不同：安装包会创建程序目录和快捷方式，便携包则应完整解压到固定目录后运行，不要直接在压缩软件预览窗口中启动。
安装与首次启动
从Windows 下载区取得安装文件后，先退出旧的 Clash 客户端，避免两个程序争用同一监听端口。按安装向导完成后启动客户端；如果 Windows 弹出防火墙提示，只在确实需要局域网共享时允许相应网络类型。单机使用时，核心监听地址保持本机回环地址即可，不必为了“能连接”而开放所有网络接口。若程序能打开但核心启动失败，应先检查旧客户端是否仍在托盘运行，再查看端口占用和内核日志。
便携版本不要放在临时下载目录、同步盘的冲突目录或受严格权限保护的位置。客户端通常需要在自身数据目录写入配置、缓存与日志，路径不可写会表现为配置导入后消失、更新失败或每次启动都回到初始状态。首次运行后可在客户端设置中确认数据目录位置，并把长期使用的配置备份到个人可控的位置。
导入订阅并选择策略
进入“配置”或“订阅”页面，选择从 URL 导入，粘贴订阅地址并等待拉取完成。新配置出现后，点击启用或设为当前配置。接着进入“代理”页面，把模式设为“规则”。规则模式会从上到下匹配配置中的规则，首条命中后停止；策略组决定命中后实际采用的出口。首次验证时不要把模式误设为“直连”，也不要在不了解影响时长期使用“全局”。规则模式可以同时保留局域网直连、常用国内服务直连和指定目标代理，是更适合日常使用的默认选择。
如果策略组是手动选择类型，需要在组内明确选择一个可用选项。若是自动测试、故障转移或负载均衡类型，则由配置定义的探测与切换逻辑处理。客户端中显示的探测结果只反映指定测试地址的连接过程，不等同于下载速度或所有网站的真实体验。关于这一区别，可阅读节点延迟测试原理。
启用系统代理
确认内核运行后再打开“系统代理”。此操作会把 Windows 的代理设置指向客户端本地端口。打开浏览器访问目标网站，并在客户端连接页面观察是否出现对应域名、命中规则和策略组。如果浏览器可用而某个命令行程序不可用，通常不是订阅失效，而是该程序没有读取 Windows 系统代理。可以为该程序单独配置 HTTP_PROXY、HTTPS_PROXY 或 SOCKS 地址，也可以根据需要改用 TUN。
set HTTP_PROXY=http://127.0.0.1:7890
set HTTPS_PROXY=http://127.0.0.1:7890
curl https://example.com上例仅对当前命令提示符窗口生效，端口应替换为客户端实际显示的混合端口。PowerShell、Git、包管理器和开发工具各自可能有独立代理设置，不应看到浏览器可用就默认所有程序都会自动跟随。排查时先查看工具自身配置，再决定是否需要环境变量或 TUN。
TUN 模式与权限
需要接管游戏、商店应用、UDP 或不读取系统代理的软件时，可以关闭其他 VPN 工具，以管理员权限启动客户端，然后开启 TUN。首次开启可能触发虚拟网卡或网络组件安装，完成后应检查默认路由和 DNS 是否由客户端接管。若 TUN 打开后整个系统断网，先关闭 TUN，再检查是否同时运行了虚拟机桥接、容器网络、加速器或安全软件的网络过滤模块。不要在异常状态下反复切换多个接管工具，这会让路由表与 DNS 状态更难判断。
Windows 特有问题
休眠恢复后出现连接中断，可以先刷新订阅状态，再重启内核，而不是立刻重装客户端。系统时间误差会影响 TLS 连接，应确保自动时间同步正常。局域网共享时，需要在配置中开启“允许局域网连接”，把监听地址调整为客户端允许的局域网形式，并在防火墙中只放行所需端口；其他设备应填写这台电脑的局域网地址，而不是 127.0.0.1。共享完成后及时关闭入口，避免在不可信网络中暴露代理端口。
桌面平台
macOS：芯片架构、系统代理与网络扩展
macOS 下载前需要先确认芯片架构。打开左上角苹果菜单中的“关于本机”，显示 Apple 芯片时选择 Apple Silicon 或 ARM 构建，显示 Intel 处理器时选择 x64 构建。可选客户端包括 Clash Plus、Clash Verge Rev、FlClash，以及处于归档状态的 ClashX Meta。新安装优先使用仍在维护的客户端，并从macOS 下载区取得与芯片一致的文件。架构选错时，应用可能无法打开，或需要额外转译层才能运行。
安装应用与首次授权
常见安装方式是打开磁盘映像后把应用拖入“应用程序”目录，再从该目录启动。不要长期直接在磁盘映像中运行，因为应用更新、辅助组件与数据目录可能无法按预期写入。如果系统对首次打开进行确认，应核对应用来源与下载路径，再按系统提供的安全流程处理。涉及系统代理、网络扩展或 TUN 时，macOS 可能要求输入管理员凭据，这是修改系统网络配置所需的授权。
启动后先不要同时打开系统代理和 TUN。进入配置页面，通过订阅 URL 导入配置，等待策略组与规则加载完成，将其设为当前配置，然后选择规则模式。若导入后只有一个配置条目却看不到策略组，可能是配置下载内容异常、订阅转换结果不兼容，或当前仍选中了旧配置。此时应查看配置更新时间和客户端日志，不要只重复点击更新。
系统代理的工作范围
macOS 系统代理会写入当前网络服务的 HTTP、HTTPS 或 SOCKS 设置。浏览器和多数遵循系统网络框架的应用会读取这些值，但终端命令、部分开发工具和自带网络栈的应用不一定跟随。打开系统代理后，可在“系统设置 → 网络 → 当前网络 → 详细信息 → 代理”中观察对应项目是否指向本机端口。一般不需要手动修改这里的值，客户端关闭代理时应负责恢复。
终端工具需要时，可以只为当前会话设置环境变量。端口以客户端的实际混合端口为准，退出终端后设置自动失效：
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
curl https://example.com如果 Git、Homebrew 或其他工具已经保存过独立代理地址，还应检查其内部配置。旧地址优先级可能高于当前环境变量，形成“浏览器正常、终端仍失败”的现象。排错时使用 env | grep -i proxy 查看当前环境，再检查具体工具是否保存了额外参数。
TUN、网络扩展与 DNS
对不读取系统代理的应用，可使用客户端提供的 TUN 或网络扩展模式。首次启用通常需要系统授权，部分客户端会安装辅助服务，以便在后台调整路由。授权完成后如果开关立即回落，应检查系统设置中的网络扩展许可、客户端日志和辅助服务状态。企业设备可能受配置描述文件限制，普通用户权限无法覆盖组织策略，此时应遵循设备管理要求，而不是反复安装。
macOS 同时运行多个 VPN、过滤器、内容检查工具或虚拟网卡时，路由优先级可能发生竞争。表现包括连接建立但没有流量、特定域名解析到错误地址、局域网设备无法访问或唤醒后断网。处理顺序是先关闭其他网络接管工具，只保留 Clash；重启内核后检查 DNS；确认单独运行正常，再逐一恢复其他软件。这样可以判断冲突来自哪一层。
睡眠、切换网络与本地服务
Mac 从睡眠恢复或在无线网络、有线网络与手机热点之间切换时，本地 IP、默认路由和 DNS 都可能变化。发现连接停留在旧状态时，先暂停再启动内核，必要时关闭并重新打开系统代理。运行本地开发服务时，localhost、127.0.0.1 和局域网网段通常应直连；若自定义规则把这些地址过早交给代理，会导致本地页面、数据库或局域网设备不可达。应把局域网直连规则放在通用代理规则之前。
菜单栏图标退出后网页全部不可用，多半是系统代理没有恢复。重新启动客户端关闭系统代理，或进入当前网络服务的代理设置取消对应项目。若只有某个浏览器异常，则检查浏览器扩展或浏览器自身的代理配置。系统层和应用层不要同时保存不同的本机端口，否则更新端口后容易留下旧值。
移动平台
Android：应用安装、VPN 权限与后台运行
Android 可选 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard。安装前从Android 下载区选择客户端。安装包可能按 ARM64、ARM 或通用架构区分，大多数近年的手机和平板使用 ARM64；较旧设备才可能需要其他架构。不能确定时，可优先选择下载页提供的通用构建，或在系统信息工具中确认 ABI。架构不匹配通常会在安装阶段直接提示无法安装，而不是订阅或网络问题。
安装与 VPN 授权
下载完成后按 Android 的安装流程打开文件。系统可能要求为当前浏览器或文件管理器授予一次安装权限，完成后可按个人安全习惯关闭该权限。首次启动客户端并开始连接时，Android 会显示 VPN 连接请求。确认后，状态栏通常出现 VPN 标识。系统同一时间一般只允许一个 VPN 服务运行，因此其他 VPN、企业隧道、防火墙或本地过滤应用可能被停止，或反过来阻止 Clash 建立连接。
移动端没有桌面系统代理那样的全局开关，客户端通常通过 Android VPN API 创建虚拟接口。启动按钮显示已连接，只代表接口建立成功；仍需确认当前配置、规则模式和策略组。进入配置页面，通过 URL 新建订阅，更新后选择该配置。若订阅下载需要已有网络路径才能访问，可先在可用网络环境完成首次导入，再启动代理。
分应用代理与绕过设置
Android 客户端常提供分应用代理，可以选择“仅代理所选应用”或“绕过所选应用”。两种模式含义相反，切换时应重新检查列表。只代理浏览器适合测试，但可能导致浏览器调用外部应用时路径不一致；绕过银行、局域网控制或对 VPN 敏感的应用时，应了解绕过后它们将直接使用当前网络。若系统启用了“始终开启 VPN”或“阻止未使用 VPN 的连接”，绕过行为还会受到系统策略影响。
规则模式与分应用代理是两层判断。应用先决定是否进入 VPN，进入后才由 Clash 规则决定 DIRECT、PROXY 或 REJECT。把某个应用放入绕过列表后，修改 Clash 域名规则不会影响它。排查“规则为什么不生效”时，先确认该应用流量是否进入客户端连接记录，再检查规则顺序。
后台限制与耗电策略
部分 Android 系统会在锁屏、清理任务或省电模式下限制 VPN 客户端。表现为刚启动时可用，锁屏一段时间后连接消失，重新打开应用又恢复。可以在系统的电池与后台管理中允许客户端持续运行，并避免把它加入自动清理列表。不同厂商菜单名称不同，但目标一致：允许前台 VPN 服务保留、允许后台网络、不要在熄屏后强制结束进程。
订阅自动更新也依赖后台网络。如果更新只在打开应用时发生，应检查客户端更新间隔、后台数据权限和省电限制。更新失败时保留上一次成功配置通常比删除后重导更稳妥；删除唯一可用配置后，可能失去用于重新获取订阅的网络路径。
DNS、IPv6 与热点共享
Android 的私人 DNS、客户端内置 DNS 与网络运营方 DNS 可能同时参与解析。若仅部分域名失败，可以临时关闭私人 DNS 做对照，再检查配置中的 enhanced-mode、上游解析器和 Fake-IP 排除项。不要同时大范围修改 IPv6、私人 DNS、TUN 堆栈与规则，否则无法判断是哪项起作用。IPv6 网络下出现“有些应用正常、有些应用超时”，应查看客户端是否接管 IPv6，以及配置是否存在相应规则。
手机开启热点后，连接到热点的设备不一定自动经过手机上的 VPN。是否共享取决于 Android 系统实现、客户端能力和路由权限，不能仅凭手机自身访问正常就判断热点设备也会分流。需要稳定共享时，优先在每台设备单独安装客户端，或使用明确支持透明代理的网关方案。局域网访问失败时，还要检查规则是否将私有地址段保持为直连。
移动平台
iOS：App Store 安装、订阅导入与按需连接
iPhone 与 iPad 可从iOS 下载区进入 Clash Plus 的 App Store 页面，客户端官网为 clashplus.io。安装完成后，首次建立连接会请求添加 VPN 配置。系统确认后，客户端才能创建网络扩展。iOS 同一时间通常只保留一个活动 VPN，已有的企业 VPN、个人 VPN 或内容过滤工具可能与之互相替换。
导入订阅与启用配置
复制订阅地址后，在客户端的配置或订阅页面选择从 URL 添加。粘贴时注意不要把聊天应用中的省略号、空格或换行带入。保存后执行更新，确认配置中出现策略组与规则，再设为当前配置。某些订阅链接可以从 Safari 直接唤起客户端，但手动粘贴更便于核对完整地址。若跳转后客户端没有新增配置，应返回应用内使用 URL 导入，并查看是否收到格式错误或网络错误。
启动连接后，可先选择规则模式。打开 Safari 进行测试，同时查看客户端的连接记录。如果网页未经过预期策略，先看域名命中了哪条规则，而不是反复切换策略组。Clash 规则按配置顺序自上而下判断，首条命中即停止；更靠后的规则不会覆盖已经命中的结果。需要理解 DOMAIN、IP-CIDR、GEOSITE 与 MATCH 的差异时，可查阅Clash 自定义规则与匹配顺序。
按需连接与系统网络切换
支持按需连接的客户端可以根据网络状态自动启动 VPN，例如在蜂窝网络或指定无线网络下连接。设置前应先手动连接并验证配置稳定，再逐步增加条件。条件过宽可能导致在家庭局域网中也持续接管，条件相互冲突则会出现频繁连接和断开。若希望某个可信无线网络不自动连接，应使用客户端提供的网络例外，而不是依赖每次手动关闭。
从无线网络切换到蜂窝网络时，iOS 会重建底层接口，已有连接短时间停顿属于常见现象。长时间未恢复时，可以在客户端停止后重新启动，而不必删除 VPN 配置。飞行模式、低数据模式和系统级网络限制也会影响后台连接。判断问题时先确认普通网络本身可用，再启动客户端，避免把运营商或无线网络故障误认为订阅问题。
DNS 与局域网访问
iOS 上的 DNS 请求可由网络扩展接管，具体行为取决于客户端实现与配置。Fake-IP 模式会先返回保留地址，再在连接阶段根据映射恢复域名，便于规则匹配；如果某些局域网设备、打印机、投屏服务或特殊应用依赖真实局域网解析，可能需要加入 Fake-IP 排除列表，或为局域网域名配置直连解析。修改前先记录原设置，并只针对明确异常的域名增加例外。
访问家庭路由器、网络存储或投屏设备时，应确保私有地址段与本地域名保持直连。常见私有网段包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。如果配置中较早的通用规则把这些地址交给代理，本地设备会表现为超时。调整规则后重新建立连接，使 DNS 映射和已有会话一并刷新。
后台行为与系统限制
iOS 会统一管理后台任务，关闭客户端界面不等于停止已建立的 VPN 网络扩展。是否仍在运行应以系统状态栏、控制中心与客户端连接状态为准。反过来，从应用切换器划掉界面后，系统可能仍保留网络扩展；需要停止时应在客户端内关闭，或在系统 VPN 设置中断开。这样可以避免误判“应用已经关掉但网络仍走代理”。
如果连接开关刚打开就自动关闭，常见原因包括 VPN 授权没有完成、另一网络扩展抢占、配置无法启动内核或系统网络暂时不可用。按顺序检查授权、其他 VPN、当前配置和日志。不要先删除所有配置，因为日志中的启动错误通常能直接指出 DNS、规则或配置格式问题。更完整的 iOS 操作路径也可参考iPhone 上的订阅导入步骤。
桌面与服务器
Linux：图形客户端、mihomo 内核与服务管理
Linux 桌面可选择 Clash Verge Rev 或 FlClash；服务器、路由器与无桌面环境更适合直接运行 mihomo 内核。图形客户端可从Linux 下载区取得发行版支持的安装包。选择前确认 CPU 架构与包格式：Debian、Ubuntu 及其衍生系统通常使用 deb，其他发行版可能使用不同包管理方式。内核压缩包还会区分 AMD64、ARM64、ARMv7 与 MIPS 等架构，架构错误会直接导致可执行文件无法运行。
桌面客户端安装
安装 deb 包时，可以使用系统软件中心，也可以在终端执行包管理命令。文件名以实际下载结果为准：
sudo apt install ./clash-client-amd64.deb安装完成后从应用菜单启动，导入订阅并选择规则模式。Linux 桌面环境对系统代理的处理并不完全统一：GNOME、KDE、浏览器、终端工具和沙盒应用可能读取不同设置。客户端显示“系统代理已开启”后，应在桌面网络设置中确认值是否写入，并分别验证浏览器与命令行。Flatpak、容器或远程开发环境还可能拥有独立网络命名空间，不会自动继承宿主机代理。
直接运行 mihomo
无图形环境下，先为 mihomo 创建独立目录，放置可执行文件和 config.yaml。赋予执行权限后，通过 -d 指定工作目录。以下路径只是清晰的目录示例，可以按实际系统调整：
sudo mkdir -p /etc/mihomo
sudo cp mihomo /usr/local/bin/mihomo
sudo chmod +x /usr/local/bin/mihomo
sudo cp config.yaml /etc/mihomo/config.yaml
mihomo -d /etc/mihomo前台启动适合首次验证，因为配置解析错误会直接输出到终端。确认配置可以加载、端口可以监听、规则与 DNS 正常后，再交给服务管理器。不要一开始就放入后台，否则启动失败时只能从日志间接判断。配置中引用的规则集、Geo 数据文件和相对路径，都以工作目录为基准，应确保运行用户有读取权限。
使用 systemd 管理服务
需要长期运行时，可以创建 systemd 服务。服务账户应拥有读取配置和写入缓存的权限；如果启用 TUN，还需要相应网络能力。最小服务示例如下：
[Unit]
Description=mihomo service
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3
[Install]
WantedBy=multi-user.target保存为系统服务文件后，重新加载配置并启动。使用 systemctl status 查看状态，用 journalctl 查看日志。更新内核时先停止服务，替换文件后再启动，避免正在运行的进程与磁盘文件状态不一致。订阅更新也应先生成完整配置并完成语法检查，再替换当前文件，防止下载到错误页面或不完整内容后导致服务退出。
代理环境变量与服务作用域
桌面系统代理不会自动作用于所有 Shell、SSH 会话、Docker 构建或 systemd 服务。临时命令可以使用环境变量：
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export all_proxy="socks5h://127.0.0.1:7890"socks5h 表示域名解析交给 SOCKS 端处理，能减少本地解析与代理规则不一致的问题。长期设置前应明确作用域：写入 Shell 配置只影响对应用户会话；写入 systemd 服务环境只影响该服务；为 Docker 守护进程设置则影响镜像拉取。排错时检查变量是否仍指向旧端口，并注意大小写变量可能同时存在。
TUN、权限与防火墙
Linux TUN 涉及虚拟接口、策略路由、DNS 与防火墙。直接以高权限运行虽然简单，但长期部署更适合授予必要能力并限制服务账户。若 TUN 接口创建失败，检查内核是否提供 TUN 设备、容器是否放行对应设备、服务是否拥有网络管理能力。若接口存在却没有流量，检查路由表、策略规则与防火墙转发链。
服务器上开放 mixed-port 给其他设备时，不应默认监听全部公网接口。优先绑定受控的局域网地址，并用防火墙限制来源。控制接口同样需要保护，不能直接暴露在不可信网络。普通桌面单机使用时保持回环监听最省事；只有明确需要局域网共享时再开启 allow-lan，并验证访问范围。
问题定位
配置常见问题：从网络入口到规则结果逐层排查
Clash 无法上网时，最有效的方法不是同时更换客户端、订阅、DNS 和模式，而是沿数据路径逐层确认。完整路径可以概括为：设备基础网络 → 客户端内核 → 当前配置 → 系统代理或 TUN → DNS → 规则 → 策略组 → 代理入口 → 目标服务。每次只验证一层，结论才可复现。更多短问题可以在疑难解答中按分类查询，本章重点给出适用于各平台的系统排错顺序。
第一步：确认关闭 Clash 后基础网络可用
先关闭系统代理、TUN 或移动端 VPN，使用当前无线网络、网线或蜂窝网络直接访问普通网站。如果直连本身不可用，应先修复路由器、运营商网络、登录认证或系统网络设置。公共无线网络常要求先完成网页认证，TUN 提前接管可能让认证页面无法弹出。完成认证后再启动客户端。
如果关闭客户端后仍无法联网，检查系统代理是否残留。桌面端可能仍指向 127.0.0.1 的本机端口，但客户端已经退出，所有读取系统代理的应用都会连接失败。重新打开客户端并正确关闭系统代理，或在操作系统网络设置中取消代理。移动端则检查系统 VPN 状态，确认没有另一个网络扩展仍处于连接中。
第二步：确认内核和配置已启动
客户端窗口可以打开，不代表内核一定运行。查看状态页是否显示运行，日志中是否出现配置加载、监听端口或启动错误。常见失败包括端口被占用、配置语法不合法、规则集文件缺失、数据目录无权限、TUN 权限不足。若日志提示地址已被使用，先退出其他代理客户端，或找出占用相同端口的进程。不要随意把端口改成多个不同值而忘记同步系统代理。
确认当前配置是刚导入的目标配置，而不是客户端内置示例或旧文件。订阅条目存在但没有被选中时，内核仍会加载之前的配置。更新订阅后若启动失败，切回上一次成功配置可以判断是否由新内容引起。YAML 对缩进敏感，手动编辑时使用空格并保持层级一致，避免制表符和错误的冒号结构。
第三步：区分接管失败与代理入口失败
打开系统代理后，观察连接记录中是否出现浏览器请求。完全没有记录，说明流量没有进入客户端，应检查系统代理是否写入、应用是否读取代理、监听端口是否一致。连接记录出现请求但持续超时，则继续看命中的规则、策略组和代理入口。TUN 模式下没有记录，优先检查虚拟接口、路由与权限；移动端则检查 VPN 授权和分应用代理列表。
同一设备可以用两种方式做对照：先关闭 TUN，仅开启系统代理测试浏览器；再关闭系统代理，仅开启 TUN 测试同一目标。如果系统代理可用而 TUN 不可用，订阅与大部分规则通常没有问题，应集中排查 TUN 权限、路由和 DNS。反过来，如果 TUN 可用但系统代理无效，应检查系统设置、应用代理行为和本地端口。
第四步：检查 DNS 与规则命中
只有域名访问失败，而已知地址或客户端内置连接测试可以工作时，应检查 DNS。日志中的解析超时可能来自上游不可达、引导解析失败、端口冲突或 DNS 请求没有被接管。临时切换到原始订阅的 DNS 配置可以验证是否由自定义项造成。不要把多个解析器、Fake-IP、私人 DNS 和系统加密 DNS一起改动。
若连接记录显示请求走了 DIRECT，而预期是 PROXY，查看命中的具体规则。某条较宽的 DOMAIN-SUFFIX、GEOSITE 或地区规则可能提前命中。若显示 REJECT，则检查广告规则集是否误收目标域名。若落到 MATCH，说明前面没有更具体规则。规则调整后重新发起连接，已有长连接不会自动改用新策略。
第五步：判断订阅和代理入口状态
配置能加载但所有代理请求都失败时，先执行一次订阅更新并查看返回错误。HTTP 状态异常、空内容或格式错误说明订阅获取阶段有问题。更新成功后选择不同的策略组选项进行对照，但不要把客户端探测结果等同于实际速度。某个测试地址可能被目标网络限制，也可能与日常网站走不同链路。
如果只有单个目标服务失败，检查域名规则、协议支持和目标服务自身状态。若所有目标均在建立连接阶段超时，才更可能是代理入口或当前网络阻断。日志里的 timeout、connection refused 和 DNS 错误含义不同，不能统一归为“节点失效”。可结合常见日志字段说明逐项判断。
高频现象对照
| 现象 | 可能位置 | 处理顺序 |
|---|---|---|
| 客户端退出后浏览器全部失败 | 系统代理残留 | 恢复系统代理，再检查客户端退出设置 |
| 浏览器可用，游戏或终端不可用 | 应用未读取系统代理 | 设置应用代理，或在确认无冲突后启用 TUN |
| 启动 TUN 后局域网设备消失 | 私有网段路由或 DNS | 检查 LAN 直连规则、自动路由和 Fake-IP 过滤 |
| 锁屏后 Android 连接中断 | 后台与电池限制 | 允许后台运行，关闭针对客户端的自动清理 |
| iOS 开关立即回落 | VPN 授权、配置或扩展冲突 | 检查系统授权、其他 VPN 与启动日志 |
| Linux 服务反复重启 | 配置解析、权限或路径 | 以前台方式启动，修复首条明确错误 |
收集足够但不过量的信息
向服务方或社区描述问题时，应说明操作系统、客户端名称、接管方式、代理模式、问题开始时间、是否所有目标都失败，以及日志中的首条相关错误。不要只写“不能用”，也不要直接粘贴完整配置。订阅地址、认证字段和代理信息应遮挡。若问题可以稳定复现，写出最短步骤，例如“关闭 TUN 时浏览器正常，开启 TUN 后所有连接记录为空”，这比大段无关日志更容易定位。
日志级别保持 info 通常足够。只有需要追踪复杂规则或 DNS 流程时才临时提高详细程度，完成后恢复，避免日志快速增长。判断问题解决后，再逐项恢复自定义 DNS、规则覆写、开机启动和其他网络工具。每恢复一项都做一次连接验证，最终得到一套可解释、可回退的配置。
何时重置，何时重装
配置损坏、客户端数据目录无法写入或升级后设置结构异常时，可以先导出必要配置，再使用客户端提供的重置功能。重装程序并不一定清除数据目录，因此“重装后问题完全一样”并不意外。反过来，直接删除数据目录会丢失订阅、覆写和策略选择，应先保留恢复材料。只有在确认程序文件、辅助服务或系统组件安装异常时，重装才是合理步骤。
完成排错后建议记录最终原因，例如“旧客户端占用混合端口”“Android 后台限制结束 VPN”“MATCH 前存在过宽直连规则”。这类记录比保存大量临时设置更有价值。后续更换平台时，先沿本手册的共同逻辑建立最小可用配置，再加入平台特有功能，可以显著减少重复排查。