Clash 全平台安装配置大全：订阅、系统代理与 TUN

通用准备：配置来源与接管边界

先分清客户端、内核与订阅

客户端负责展示设置、管理配置和申请系统权限；内核负责解析配置、匹配规则并建立连接；订阅则提供节点、策略组，有时也包含 DNS 与分流规则。这三者不是同一个东西。安装客户端并不会自动获得可连接的远端服务，拿到订阅也不意味着所有客户端都能直接读取。开始前应确认订阅有效期、支持格式，以及服务方是否提供适用于当前客户端的导入方式。

普通桌面与手机用户优先从下载页选择 Clash Plus，再按系统条件比较其他客户端。需要自己管理服务进程、路由和配置目录时，才考虑单独使用 mihomo 内核。原版 Clash、Clash.Meta 与 mihomo 的名称有演进关系，但不能据此推断任意旧配置都兼容；协议、规则字段和 DNS 功能还要结合实际内核检查，详见内核与配置兼容性梳理。

记录设备与现有网络状态

下载前记录系统类型、处理器架构和安装包格式。桌面系统还应确认当前是否已有 VPN、代理软件、虚拟机网卡或企业安全组件。先退出其他代理工具，测试普通网页在直连状态下能否打开；如果直连本身异常，应先恢复基础网络。保留一份原有代理设置与 DNS 设置的记录，便于测试结束后还原，不要同时卸载网卡、修改路由和替换解析服务器。

订阅地址通常具有访问配置的权限，分享日志或截图前应遮住完整地址、用户标识和查询参数。导入时从可信来源复制整条链接，避免聊天软件换行、尾部空格或中文标点混入。若得到的是网页而不是配置，先确认是否需要登录、链接是否过期，以及客户端是否支持返回格式；不要把带个人标识的订阅交给来源不明的转换页面处理。

确定系统代理与 TUN 的使用顺序

系统代理主要把遵循系统代理设置的应用引向本机监听端口，浏览器通常可以据此完成基础测试，但部分游戏、命令行工具和自带网络栈的应用可能不遵循。TUN 则创建虚拟网络接口，通过路由接管更多连接，通常涉及更高权限、DNS 处理和网卡配置。桌面排查时建议先验证系统代理，再按需要切换到 TUN；手机端通常使用系统 VPN 扩展承载接管，不能照搬桌面的开关逻辑。

方式	作用范围	先检查什么
系统代理	遵循系统设置的应用	监听地址、端口、绕过列表
TUN 接管	按虚拟网卡与路由进入的流量	服务权限、路由、DNS 与其他 VPN
应用单独代理	显式设置代理的单个应用	代理协议及应用自己的设置

建立最小可验证配置

下面只是基础字段片段，需要合并进已有可用配置，并不包含节点与策略组。端口应以客户端实际显示值为准；某些客户端会用设置页的端口覆盖订阅字段。保持本机访问与规则模式，先不要开放局域网。YAML 使用空格缩进，冒号后保留空格，同级字段对齐；加载报错时先看具体行号，不要通过删除整段规则来掩盖语法问题。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

导入后按三个层次验证：配置是否成功加载、所选节点能否建立连接、目标请求是否命中预期策略。先选择一个节点，不要开启频繁自动测速；访问一个直连目标和一个应走代理的目标，在连接页确认策略与出口。测试成功后保存配置副本，并记录接管方式。后面新增规则或 DNS 设置时，每次只改一项，便能判断是哪一步造成变化。

Windows：安装、系统代理与服务权限

按架构安装并保留迁移资料

在系统设置的“系统 → 系统信息”中查看系统类型，区分常见的 x64 与 ARM 设备。先到Windows 下载区查看 Clash Plus；其他可选项依次为 Clash Verge Rev、FlClash、Clash Nyanpasu。Clash for Windows 已停止维护，只适合有明确兼容需求时查阅归档。不要因为名称熟悉就把旧客户端作为新设备的默认选择，也不要把不同架构安装包混放后反复试装。

从旧客户端迁移前，记录订阅来源、手动选择的策略组、自定义规则和应用专用代理设置。可以导出的本地配置先保存到单独目录，但不要直接覆盖新客户端的整个数据目录：数据库、界面设置和服务状态未必兼容。新安装先保持默认数据目录，完成一次基础连接后再逐项迁入自定义内容。迁移的具体取舍可参照Clash for Windows 迁移步骤。

启动安装程序时核对文件来源与系统提示。正常安装完成后先以普通用户打开客户端，不必把日常操作全部放在管理员权限下。若安全组件阻止执行，先查看拦截项目和组织策略，不要为了启动程序关闭整套系统防护。公司管理的电脑可能限制代理、驱动或服务安装，这类限制应由设备管理员确认，重复点击授权并不能解决策略层面的禁止。

导入订阅与验证系统代理

进入配置或订阅管理页，选择通过链接添加，粘贴完整订阅并等待下载结束。出现配置条目后还要将它设为当前配置，再打开代理页确认策略组和节点已经加载。仅仅看到订阅名称不代表内核已切换；如果列表为空，先查看更新结果和配置解析日志。更新失败时保留原配置，不要连续删除重建，以免把还能工作的缓存一起清掉。

选择规则模式，并在需要手动选择的代理组中选定节点，然后开启系统代理。到 Windows 的网络与 Internet 代理设置核对地址与端口，通常应指向本机回环地址以及客户端显示的监听端口。浏览器若安装过代理扩展，应暂时禁用该扩展的接管功能；否则页面请求可能使用扩展保存的旧端口，即使系统设置正确也无法进入当前内核。

打开一个测试页面，同时观察客户端连接列表。若网页失败且列表没有对应请求，优先检查浏览器自身代理、系统绕过列表和本地监听；若出现请求但连接失败，再看节点认证、远端可达性与规则选择。部分应用需要重新启动才能重新读取系统代理。命令行工具也可能只读取环境变量，不能用浏览器成功来推断所有程序已经接管。

启用 TUN 与处理权限错误

当确实有应用不遵循系统代理，再启用 TUN。不同客户端可能要求先安装服务模式或授权辅助进程，按界面提示完成后检查服务是否运行，而不是只看开关是否变亮。首次测试时可以关闭系统代理，仅保留 TUN，便于确认流量来源。出现虚拟网卡创建失败，应先阅读权限或驱动错误；出现路由添加失败，则检查其他 VPN、虚拟机网络与残留服务。

若本机端口被占用，可以在 PowerShell 里查看监听进程。下面的命令只检查示例端口，不会结束任何程序；如果设置页不是这个端口，应替换为实际值。得到进程标识后在任务管理器核对所属应用，先正常退出旧工具，再重新启动当前客户端。不要看到端口占用就批量终止未知进程，系统服务和开发工具也可能使用本地端口。

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

睡眠唤醒或从有线网络切到 Wi-Fi 后连接中断，先关闭并重新打开当前接管方式，观察内核是否重新识别默认网卡。如果仅 TUN 异常而系统代理正常，应围绕路由与网卡查找，不要重新购买订阅或随机改节点协议。防火墙放行也应限制在需要的程序与网络范围内；保持 allow-lan: false 时，不需要为了本机浏览器访问而开放整个局域网入站。

最后验证退出行为：先在客户端关闭系统代理或 TUN，再正常退出，确认浏览器仍可直连。若程序异常退出后全网打不开，检查系统是否残留本机代理地址，并恢复此前记录的设置。连接稳定后再考虑开机启动；开机启动、服务启动与自动连接是三个不同选项，应分别测试，避免每次登录时两个客户端同时抢占代理设置。

macOS：芯片架构、辅助服务与网络位置

选择安装包并处理首次启动

打开苹果菜单中的“关于本机”，确认设备显示 Apple 芯片还是 Intel 处理器，再到macOS 下载区选择对应架构。优先考虑 Clash Plus，也可比较 Clash Verge Rev 与 FlClash；ClashX Meta 已停止维护，迁移旧配置时才需要特别关注其历史行为。能通过兼容层运行并不意味着这是合适的长期选择，优先使用与本机芯片匹配的包，减少额外兼容环节。

使用磁盘映像安装时，把应用复制到“应用程序”目录后再启动，不要长期从挂载映像或下载目录运行。这样更新、辅助服务路径和系统权限记录更容易保持一致。首次启动若被系统阻止，先确认下载来源，再按系统“隐私与安全性”中的提示处理。不要用一组来源不明的终端命令移除所有应用的安全属性，也不要把启动失败直接解释为订阅有问题。

需要辅助服务时，仔细区分客户端本身与其安装的后台组件。修改系统代理、建立虚拟网卡或管理路由，可能需要一次管理员授权；授权成功后，应回到客户端查看服务状态。若迁移过应用位置或更换过同类工具，旧服务路径可能已经失效，应通过对应客户端的修复或卸载入口处理，而不是只把应用图标拖到废纸篓后留下后台组件。

订阅导入与系统代理检查

在配置页添加订阅地址，等待下载和解析完成，再选中该配置。先检查策略组是否存在、当前选择是否指向有效节点，并保持规则模式。若订阅含客户端不支持的字段，日志一般会给出字段或协议名称；应向配置来源确认兼容输出，或使用支持该字段的客户端，不宜直接删掉报错行，因为它可能正是建立远端连接所需的关键参数。

启用系统代理后，打开系统设置中的网络，进入当前正在使用的网络服务，查看详细信息里的代理项目。Wi-Fi 与有线网络可能分别保存设置，检查时要选实际有流量的那一项。地址通常是本机回环地址，端口与客户端一致。若浏览器可以访问但终端不行，先查终端工具是否读取系统代理；若两者都失败，再检查监听进程和配置加载状态。

系统代理的绕过列表会影响哪些目标不进入本地代理。公司内网、打印机与本地开发地址可能需要保留直连，不应为了测试把所有例外永久删除。反过来，过宽的域名或地址段也可能让预期走代理的请求绕开客户端。修改前记录原值，选一个明确目标复测，并在连接页观察是否出现请求；只盯着菜单栏开关，无法判断最终路径。

TUN、休眠恢复与 DNS 缓存

启用 TUN 前先完成辅助组件授权，并暂停其他 VPN。不同客户端使用的接管实现与服务管理方式不完全相同，系统弹出的权限提示也可能不同，应以当前应用说明为准。首次验证时暂时关闭系统代理，用规则日志确认流量确实从 TUN 进入。若启动时报默认网卡识别或路由错误，记录当时的网络接口与其他网络扩展状态，再决定是否重启辅助服务。

笔记本从睡眠恢复、切换热点或进入需要网页登录的公共网络时，旧连接与旧解析结果可能暂时失效。先关闭代理完成网络门户登录，再重新连接。若只有个别域名仍解析异常，可以在确认 DNS 设置正确后刷新系统缓存；下面的命令需要管理员权限，只清理本机缓存，不会修复订阅、远端节点或错误的 DNS 配置，因此不应把它作为所有故障的第一步。

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

某些浏览器会自行使用加密 DNS，应用还可能长期保留已建立的连接。改完解析策略后，应关闭相关测试标签或重新启动应用，再观察新请求。若使用 fake-ip，不要把缓存中的虚拟地址直接当成真实服务器地址进行手工连通测试；这类地址需要由对应内核解释。解析行为与目标出口应结合连接日志判断，不能只根据一次命令行查询下结论。

迁移完成后，依次验证浏览器、需要代理的桌面应用，以及应直连的局域网服务。最后关闭接管并退出客户端，检查网络是否恢复正常。若只有某个网络位置异常，重点比较该位置保存的代理与 DNS，而不是删除全部系统网络服务。保留一份可回退的配置，有助于区分系统更新、客户端更新与订阅变化分别带来的影响。

Android：安装架构、VPN 授权与后台运行

下载与安装前核对设备

到Android 下载区优先查看 Clash Plus，其后可选 Clash Meta for Android、FlClash 与 Surfboard。常见手机使用 ARM64，但旧设备或特定系统可能需要其他包，应结合设备信息与下载页说明选择。安装失败先看系统给出的具体原因：架构不匹配、系统条件不满足、存储不足和签名不一致的处理方式不同，不应只靠反复下载同一个文件解决。

通过浏览器或文件管理器安装时，系统可能要求允许该来源安装应用。只为当前使用的来源授权，完成后按需要收回。若旧版与新版签名不同，覆盖安装可能被拒绝；卸载前先导出订阅与本地规则，并确认能重新取得配置，因为卸载通常会删除应用私有数据。不要把备份文件放在聊天群或公开网盘中，订阅地址本身就可能足以访问账户配置。

Surfboard 与 Clash 系列配置不能简单视为完全相同的输入格式，导入前要核对服务方是否提供对应格式。即使两个应用都能显示同一协议名称，规则语法和订阅内容也未必通用。选择客户端时先确认配置来源，再考虑界面习惯；转换格式会增加变量，基础连接未建立前，尽量使用服务方明确支持的原生导入方式。

导入配置并批准 VPN 连接

在配置管理页新建远程订阅，粘贴地址后下载，再把该条目设为活动配置。若通过二维码导入，先确认识别结果是订阅、单个节点还是网页登录地址，不能仅凭扫描成功判断配置有效。下载失败时检查手机时间、网络是否需要门户认证，以及订阅是否仍有效；导入成功但没有策略组，则继续查看配置格式和解析结果。

首次连接通常会出现 Android 的 VPN 连接请求，这是应用通过系统接口接管设备流量所需的授权。确认请求来自刚安装的客户端后再允许。多数常见设备同一用户空间同时只能维持一个活动 VPN，其他 VPN、防火墙或基于本地 VPN 的过滤工具可能把当前连接替换掉。状态栏出现 VPN 标识只说明通道存在，并不证明远端节点或 DNS 已经正常。

先保持规则模式，选定一个节点，打开浏览器并在连接页核对策略。手机端通过 VPN 接管时，不需要再照着桌面教程填写系统 HTTP 代理。Wi-Fi 高级设置中的手动代理主要针对该无线网络，两套接管混用会增加排查难度；除非明确需要连接另一台设备的代理，否则应先恢复该 Wi-Fi 的代理设置，再测试客户端自己的 VPN 通道。

按应用分流与后台限制

按应用代理通常有“只代理选中应用”与“绕过选中应用”两种相反含义，选之前要读清界面说明。初次使用可以先不设应用筛选，验证整体接管，再逐个添加例外。某个应用不出现在连接列表时，先检查它是否被排除、是否运行在工作资料或其他用户空间，以及当前连接是否由另一款 VPN 接管，不要立刻归因于节点故障。

灭屏后断连，常见原因是系统电池优化、后台活动限制或厂商自启动管理。先把客户端加入允许后台运行的范围，并保留其要求的前台服务通知；不同品牌菜单名称不同，以系统搜索到的电池和后台管理项为准。不要一次给所有应用放开限制。允许后台运行后，仍要分别测试灭屏、切换网络与系统清理任务三种情况，才能确定是哪一种操作中断了服务。

系统的始终开启 VPN 与阻止未使用 VPN 的连接属于设备级策略。后者启用后，客户端断开时普通网络也可能被阻止，因此不适合在基础连接尚未稳定时立即开启。手机的私人 DNS、浏览器加密 DNS和客户端 DNS 之间也可能形成不同解析路径；先记录当前设置，再通过日志判断实际请求，避免同时更换所有解析入口后失去对照。

耗电排查先减少自动测速频率与不必要的日志，观察是持续传输、频繁重连还是后台更新导致唤醒。不要把更短的健康检查间隔当成更稳定的保证；网络切换时连续测速反而可能增加负担。可以结合手机后台与耗电设置对照逐项调整。最终保留能满足连接需求的最少功能，并在系统升级后重新检查后台权限。

iOS：商店安装、配置导入与按需连接

从商店确认应用与配置格式

iPhone 与 iPad 在本站优先使用 Clash Plus，可从iOS 下载区前往商店，或直接打开Clash Plus 的 App Store 页面；产品官网为 clashplus.io。安装前查看商店中当前列出的系统兼容条件，并确认设备可安装。不要把桌面端的文件安装步骤套到手机，移动端的权限与配置存储方式不同。

准备订阅时，先确认 Clash Plus 当前支持的导入类型。文件扩展名相同、链接都以 HTTPS 开头，并不能证明内容完全兼容。桌面配置可能包含本地路径、外部脚本或仅适用于某个内核的字段，手机端未必能执行。服务方若提供客户端专用订阅，应优先选用对应入口；若只有单节点信息，就按应用提供的节点添加流程填写，而不是把它粘贴进远程配置地址栏。

iOS 对应用沙盒和后台扩展有明确边界，电脑上可直接编辑的配置目录，在手机上通常不能照搬。需要导入本地文件时，通过应用支持的文件导入或分享入口操作；导入后检查是否生成独立副本，以及它是否会自动更新。文件能在“文件”应用中看到，不代表客户端会持续读取该位置，更不能据此推断电脑修改后手机会同步生效。

添加订阅与 VPN 配置授权

打开应用的配置或订阅管理入口，新增远程订阅并等待内容加载。确认策略组、节点和规则均已出现，再选择活动配置。若订阅更新卡住，先用普通网络确认设备能访问互联网，检查是否停留在公共 Wi-Fi 登录页；再核对链接是否过期、是否需要特定格式。不要在同一次测试中同时更换 Wi-Fi、订阅来源和客户端设置，否则很难知道哪项改变起了作用。

首次连接时，系统通常要求允许添加 VPN 配置，按系统提示完成验证。授权后回到应用查看连接状态，再到系统 VPN 管理中确认启用的是对应配置。设备上存在旧 VPN、组织下发配置或其他网络扩展时，应先识别各自用途；受管理设备可能限制修改。不要删除不认识的企业配置来尝试连接，先向设备管理方确认权限范围。

连接按钮显示开启，只说明应用已尝试建立接管通道。仍需选择策略并发起真实请求，在应用可提供的连接或日志页面确认结果。对于需要直连的本地服务，也要单独测试。手机端的 VPN 扩展不是桌面系统代理的同名替代品，通常不需要在 Wi-Fi 设置里再填本机端口；误留的手动代理应在记录后恢复，避免额外路径影响判断。

按需连接、网络切换与局域网访问

如果应用提供按需连接，可以在基础连接稳定后再配置，并逐项核对触发条件。有的策略按网络类型或无线网络条件判断，有的按域名请求触发，不能只根据“自动”二字猜测行为。首次测试应覆盖锁屏后唤醒、Wi-Fi 切到蜂窝、蜂窝回到 Wi-Fi 三种场景。若切换后只出现短暂断流，先观察扩展重建和 DNS 刷新，不要立即把所有规则改成全局。

公共网络需要网页认证时，先暂停自动重连，完成登录，再恢复连接；否则按需规则可能不断把流量送回尚未可用的网络。需要访问家庭存储、打印机或投屏设备时，检查应用的局域网访问权限与配置中的直连规则。发现设备通常还涉及广播或组播，单独添加一个域名规则不一定足够，应区分设备发现失败与已知地址连接失败。

不要把 mihomo 的完整 TUN 或 DNS 段直接粘进手机配置并假定一定有效。移动客户端可能采用不同配置模型，也可能只支持其中一部分字段，应以导入结果和功能说明为准。浏览器自身解析策略、系统隐私功能与 VPN 扩展的交互也会影响观测；需要对照时，一次只临时调整一项，并记录原状态，测试完成后恢复不相关设置。

若灭屏后耗电明显增加，先检查是否存在频繁测速、持续日志、过密更新或网络不稳导致的重连。后台扩展能否持续运行还受系统调度与资源条件影响，不能用桌面常驻进程的经验保证手机行为。选择足够但不过密的更新安排，比反复强制关闭和重启应用更便于定位；具体对照可阅读移动端运行策略文章。

更换设备前，把订阅来源与必要的自定义规则单独保存，不要假设系统备份必然包含全部敏感配置。迁移后重新确认活动订阅、策略选择和按需条件，再测试两种网络。若长期不用，应在应用内断开并检查系统 VPN 状态；遇到网页异常，先确定是否仍有按需连接在自动恢复，避免误以为关闭应用界面就已经停止网络接管。

Linux：桌面安装、内核运行与路由检查

桌面客户端与包格式选择

Linux 桌面用户先到Linux 下载区查看 Clash Verge Rev，其后是 FlClash。按发行版选择可用的 DEB 或 RPM 包，并核对处理器架构；包格式对应的软件管理体系与架构是两回事，不能因为同为 Linux 就混用。服务器、路由器或没有图形环境的设备，可以查看内核区，但需要自行承担配置目录、进程管理、日志与路由维护，不宜仅因文件小就优先使用裸内核。

安装前可以运行下列命令查看架构与发行版信息。常见的 x86_64 通常对应 AMD64，aarch64 通常对应 ARM64；路由设备还可能有不同浮点与指令条件，应按具体设备资料选择。下载页提供的桌面包并不覆盖所有架构，遇到不匹配时不要用强制忽略依赖的方式安装，这往往只把错误推迟到启动阶段。

uname -m
cat /etc/os-release

使用发行版的软件安装工具安装本地包，并留意缺失依赖与图形运行环境提示。客户端窗口能够打开之后，再处理代理与服务权限，避免把显示服务器、桌面库缺失和网络问题混在一起。安装了多个同类工具时，先停止其他实例及其后台服务；同一端口被占用或两个服务同时调整路由，都可能表现为客户端启动后立刻断开。

导入订阅与桌面系统代理

在图形客户端中添加远程订阅、完成下载并选为当前配置，然后检查策略组。Linux 桌面的系统代理行为与桌面环境、应用实现有关，某些浏览器会读取桌面设置，终端工具则可能只读取环境变量。开启系统代理后先测试浏览器，再用显式代理参数测试终端，这样可以区分内核本身不可用，还是应用没有采用桌面的代理设置。

curl --proxy http://127.0.0.1:7890 --head https://example.com
ss -lntp

这里的端口必须与客户端实际监听一致，测试网址只是用于发起请求，收到某个 HTTP 状态不等于所有业务都已正常。观察连接日志是否显示该请求、选择了哪个策略，才能确定路径。需要临时设置环境变量时，先在当前终端会话测试，不要立刻写入系统全局配置；部分工具对变量大小写、SOCKS 与 HTTP 代理的支持不同，也可能有独立配置覆盖环境。

裸内核运行与最小权限

单独使用 mihomo 时，先建立独立配置目录，将已验证的完整配置保存为 config.yaml，并根据配置引用准备规则文件等资源。下面假定解压后的可执行文件已经命名为 mihomo，且配置放在用户目录下的专用位置。先执行配置测试，再以前台方式运行，直接阅读报错；未通过语法检查前，不要急着创建开机服务。

mkdir -p "$HOME/.config/mihomo"
chmod u+x ./mihomo
./mihomo -t -d "$HOME/.config/mihomo"
./mihomo -d "$HOME/.config/mihomo"

基础代理监听不一定需要管理员权限，但创建 TUN、修改路由和某些 DNS 操作需要额外能力。图形客户端可以提供服务管理入口；裸内核则应结合发行版的服务与权限机制配置。不要长期在整个桌面会话里使用高权限，也不要把未经检查的订阅交给拥有广泛系统权限的进程。远程控制接口只在确有需要时启用，并限制监听范围与访问权限。

TUN、DNS 管理与远程设备回退

启用 TUN 前确认系统提供所需虚拟网络设备，并检查当前路由、其他 VPN 与防火墙规则。系统可能使用 NetworkManager、systemd-resolved 或其他解析管理方式，直接覆盖 /etc/resolv.conf 可能很快被管理器重写，也可能破坏原有设置。先查看该文件是否为符号链接，弄清解析管理者，再按客户端支持方式配置 DNS，不要同时启用多个互相覆盖的劫持方案。

服务器通过 SSH 远程操作时尤其要谨慎：修改默认路由可能让管理连接也进入代理，造成会话中断。先保留控制台或其他回退途径，确认管理目标的直连策略，再测试接管范围。通过 ip route 与 ip rule 观察变化，并用客户端日志验证实际请求；仅看到虚拟网卡出现，不能证明策略路由和解析已经正确。

基础运行稳定后再交给服务管理器，固定可执行文件、工作目录和配置路径，避免升级时服务引用临时下载目录。服务的用户、环境变量和交互终端不同，因此手动运行成功而后台失败时，应先检查路径、读取权限和日志，不是重新改节点。最后验证停止服务后是否撤销路由与恢复解析，并保存可工作的配置，后续升级一次只替换一个层面。

配置常见问题：订阅、规则、DNS 与验证

订阅更新失败与配置覆盖

先区分“地址无法下载”和“下载后解析失败”。前者检查网络、时间、门户认证、订阅权限及服务方状态；后者查看返回格式、协议支持与 YAML 行号。如果返回登录页面或错误页面，即使下载请求有响应，也不是有效配置。部分客户端允许选择更新走直连还是代理，只有已有可用配置时才适合对照这两个路径，不能依赖尚未建立的代理更新唯一订阅。

订阅更新后自定义规则消失，多半是直接改了远端配置缓存。把长期设置移到客户端的覆写或合并入口，并确认规则是追加还是前置：常见规则按顺序首次匹配，放在末尾的自定义项可能永远到不了。保留远端原始配置与本地扩展两份记录，遇到问题先暂时关闭扩展测试。更完整的失败分支见订阅更新常见问题。

规则模式、全局模式与节点测试

规则模式按规则选择策略，全局模式把进入内核的连接交给全局策略组，直连模式则通常让这些连接直接访问。模式控制的是已经进入内核的流量，不会自动让未接管的应用进入代理。全局能用、规则不能用时，先看规则是否选择了直连或空策略；两种模式都失败，再检查节点与接管。不要把全局模式误解为能修复所有 DNS 或权限问题。

节点测试通常只反映特定测试地址的一次请求，不代表实际下载带宽、所有网站可用性或长期稳定性。测试成功而目标失败，应核对目标命中规则、远端服务限制和连接协议；测试失败但网页能打开，则需检查测试地址与超时条件。避免用一次结果批量删除节点，先固定同一网络和同一目标做对照，可继续阅读节点延迟解释与连接速度分层排查。

fake-ip、DNS 劫持与应用缓存

fake-ip 会给域名分配虚拟地址，后续连接进入同一内核时，再映射回域名并参与规则匹配。它解决的是域名与连接关联问题，不是单独开启就能保证所有解析都走同一出口。应用绕开系统解析、浏览器使用独立加密 DNS，或旧缓存仍保留真实地址时，观测会不同。下面是 mihomo 的组合片段，需要结合已有配置与客户端能力合并，不是手机端通用模板。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

示例中的上游必须在当前网络与路由策略下可达；如果解析上游本身不可达，不能靠重复清缓存修复。对五十三端口的劫持也不等于接管任意加密 DNS。使用按域名选择上游的策略时，还需考虑上游域名如何完成初始解析，以及远端节点域名是否形成解析循环。局域网域名、设备发现和特殊应用可按需求设置例外，但例外应具体，避免把全部域名都绕开。

验证 DNS 时结合系统查询、应用请求与连接日志，不要只看检测页出现某个地区就断言泄漏。递归解析服务器的位置与网站看到的出口地址并非一一对应；缓存、公共解析服务的调度和检测方法都会影响结果。需要检查解析外溢时，先明确预期路径，再对照具体查询，操作细节可见DNS 检测与 fake-ip 配置实操。

按故障层次回退，而不是重置全部设置

现象	优先检查	对照方法
连接页没有请求	系统代理、应用例外、TUN 路由	显式指定本地代理测试
请求进入但连接失败	节点认证、远端可达性、策略选择	固定目标并更换一个节点
仅域名失败	解析上游、缓存、DNS 接管	观察查询与内核错误日志
停用客户端后也断网	残留代理、路由、设备级 VPN 策略	恢复安装前记录的网络设置

遇到速度慢时，先确认不是目标服务限速，再比较同一节点、同一网络和相近时段的表现。只有部分大流量连接卡住，才进一步考虑 MTU、UDP 路径或网络设备兼容；不要从网上复制一个固定 MTU 就用于所有平台。日志临时调到更详细级别可以帮助定位，但复现完成后应恢复常规级别，并在对外提交前移除订阅、认证信息与个人访问记录。

什么时候应该回到快速上手流程？

当已经不清楚当前配置改过哪些地方时，先备份现状，选择一份有效订阅，仅保留一种接管方式，按订阅导入与模式选择重新建立对照。基础连接成功后再逐项恢复扩展，每加一项就验证一次，通常比整套系统网络重置更容易保留线索。

最终验收应包含代理目标、直连目标、局域网服务、网络切换和停止接管五项。把正常时的监听端口、活动配置、模式与权限状态记录下来，后续出现变化就能找到对照点。完整文档用于解释边界与分支，具体问题可继续查阅常见问题；恢复稳定后，不必为了增加设置项而继续修改一份已经满足需求的配置。