安装前的通用准备工作
先确认系统架构、配置来源和网络入口，能避免把安装包选错、订阅不可用与系统代理未生效混成同一个问题。
确认系统、架构与客户端角色
下载之前先记录操作系统名称、版本和处理器架构。Windows 常见设备使用 x64，少量新设备采用 ARM64；macOS 需要区分 Intel 与 Apple Silicon；Android 安装包可能按 ARM64、ARM 或通用架构提供；Linux 除架构外还要区分 deb、rpm 与压缩包。架构不匹配时，典型表现是安装程序拒绝运行、系统提示不支持，或程序启动后立即退出。不要仅凭文件名里出现“64”就判断适用，应在系统信息中查看处理器类型，再回到下载页选择对应入口。
Clash 生态通常由“内核”和“图形客户端”两层组成。内核负责读取 YAML 配置、建立连接、执行规则和提供代理端口；图形客户端负责订阅管理、模式切换、系统代理和日志展示。普通桌面与移动设备优先选择图形客户端，服务器、路由器或需要服务化运行的 Linux 环境才直接部署 Mihomo 内核。本站各平台首推 Clash Plus；Windows 与 macOS 还可选择 Clash Verge Rev、FlClash，Android 可选择 Clash Meta for Android、FlClash 或 Surfboard。Clash for Windows 与 ClashX Meta 已停止维护，只适合处理既有环境迁移，不建议用于新的长期配置。
准备订阅或本地 YAML 配置
客户端安装完成并不等于具备可用连接，还需要导入配置。常见输入有订阅地址和本地 YAML 文件两种。订阅地址由配置提供方生成，客户端会通过该地址获取节点、策略组和规则；本地文件适合离线编辑、实验规则或在受控环境中保存固定配置。导入前应确认地址完整，复制时没有附带空格、换行或中文标点。订阅地址属于敏感配置，不要放入公开截图、论坛帖子、浏览器公开收藏或共享文档。
首次实验建议保留一份结构简单、曾经成功加载的配置。复杂配置可能包含代理提供者、规则提供者、脚本、嗅探、DNS 覆写和多级策略组，其中任何远程资源不可达都可能影响加载。先用基础配置验证客户端、系统权限与代理入口，再逐步加入复杂规则，比一次导入全部功能更容易定位问题。更新订阅之前也应记住当前可用配置的名称；若新配置解析失败，可以立即切回旧配置，而不必在网络中断状态下继续修改。
理解系统代理与 TUN 的边界
系统代理通常向操作系统写入 HTTP 与 SOCKS 代理地址。遵循系统代理设置的浏览器和应用会把请求交给 Clash，部署简单、开关直观，但部分命令行工具、游戏、商店应用或自行管理网络栈的软件可能绕过它。TUN 模式会建立虚拟网络接口，让更多 TCP、UDP 与不读取系统代理的程序进入规则处理流程，覆盖范围更广，同时需要更高权限，也更容易与其他 VPN、虚拟网卡、终端安全软件和企业网络策略发生冲突。
| 检查项 | 系统代理 | TUN 模式 | 首次建议 |
|---|---|---|---|
| 所需权限 | 写入系统代理设置 | 创建虚拟接口或服务 | 先完成系统代理验证 |
| 覆盖应用 | 遵循代理设置的程序 | 更多系统流量与 UDP | 按应用需求扩展 |
| 冲突来源 | 浏览器扩展、手工代理 | 其他 VPN、虚拟网卡、防火墙 | 一次只启用一个入口 |
建立安装记录与基线
安装前暂时退出其他代理或 VPN 工具，记录系统是否能直接访问常用站点。安装后先不启用 TUN，只导入配置、选择规则模式、开启系统代理，再访问一个普通网页并观察日志。这样可以形成清晰基线：客户端能否启动、配置能否解析、代理端口能否监听、系统代理能否写入、规则能否命中。每完成一步再进行下一步，出现异常时便能缩小到单一环节。企业设备、校园网络或受管理设备还可能限制安装服务、添加 VPN 配置和修改网络设置，应提前确认当前账户拥有相应权限。
Windows：安装、系统代理与 TUN
Windows 的关键变量是安装包架构、网络权限、系统代理残留和虚拟网卡服务。
选择安装包并完成首次启动
Windows 新安装优先选择 Clash Plus，也可按界面习惯选择 Clash Verge Rev、FlClash 或 Clash Nyanpasu。Clash for Windows 已停止维护，现有用户应先导出或记录配置，再迁移到仍在维护的客户端。打开“设置 → 系统 → 系统信息”，查看系统类型是否为 x64 或 ARM64。下载页当前提供的具体架构以卡片说明为准，不要把 macOS、Linux 压缩包或 Mihomo 内核文件当作 Windows 图形客户端。
运行安装程序时，系统可能显示账户控制确认。安装到普通应用目录后启动客户端，先观察主界面是否完整打开，再处理防火墙询问。允许专用网络访问通常足以满足家庭或办公局域网使用；是否允许公用网络，应按设备所处环境决定。若双击后没有窗口，先在任务管理器检查进程是否已经运行，并查看系统托盘，因为部分客户端会默认最小化到托盘。仍无界面时，再检查安全策略是否阻止应用，而不是反复安装多个不同客户端。
导入订阅与选择策略
在客户端的配置、订阅或 Profiles 页面找到导入入口，粘贴完整订阅地址并执行下载。导入成功后通常会出现配置名称、更新时间或策略组列表；只看到订阅记录而没有任何策略，可能是远程内容未下载、返回内容不是 Clash YAML，或配置解析失败。此时查看日志中的 HTTP 状态、YAML 行号和 provider 错误。不要马上开启 TUN，因为配置层的问题与虚拟网卡无关。
激活配置后进入代理或策略页面。规则模式会按配置中的 rules 从上到下匹配，适合日常使用；全局模式把连接交给指定策略，适合短时验证某个节点能否工作；直连模式用于确认关闭代理后本地网络是否正常。首次验证可先选择规则模式，再在主要策略组中明确选择一个可用节点。自动策略组需要完成健康检查才会选出结果，若检查地址不可达，自动组可能表现为全部超时，但这并不必然代表所有业务连接都不可用，可结合浏览器访问与连接日志判断。
开启系统代理并验证端口
开启“系统代理”后，客户端会把本机回环地址和监听端口写入 Windows 代理设置。此时打开系统的代理设置页面，应能看到脚本或手工代理状态发生变化。浏览器访问站点后，在客户端连接列表中寻找目标域名、规则名称和最终策略。若浏览器能访问而命令行工具不能访问，通常是该工具没有读取 Windows 系统代理。PowerShell 可在当前会话显式设置环境变量，端口应替换为客户端界面显示的实际混合端口：
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe https://example.com测试完成后关闭终端窗口即可清除本次会话变量。若需要长期配置，应先确认工具支持的变量范围，避免把本地端口写入不再使用的系统环境。还可执行 netstat -ano 或 PowerShell 的网络连接命令，检查对应端口是否正在监听。端口被占用时，客户端日志通常会出现 bind 或 address in use；应找到占用进程，或在配置与客户端设置中统一修改端口，不能只改界面一处而让配置继续声明旧端口。
启用 TUN 与处理 Windows 特有冲突
TUN 通常需要安装服务或以提升权限运行。先关闭其他 VPN、游戏加速器和旧 Clash 客户端，再按照客户端提示安装服务并开启 TUN。成功后，网络适配器列表会出现对应虚拟接口，连接日志也会记录更多不读取系统代理的应用流量。若开启后整个系统断网，先关闭 TUN，确认基础网络恢复；随后检查 DNS 模式、默认路由、服务状态和防火墙。不要在断网状态下同时重置网络、删除驱动和修改配置，这会丢失可对照的基线。
Windows 睡眠唤醒、网络从有线切到无线、加入企业 VPN 后，路由与 DNS 可能变化。遇到唤醒后无网络，可依次关闭系统代理、关闭 TUN、退出客户端，再重新启动并逐项开启。系统代理开关关闭后仍无法访问时，到 Windows 代理页面确认没有残留地址；必要时检查 WinHTTP 代理，但不要把浏览器代理与 WinHTTP 混为一类。客户端以管理员身份运行与安装系统服务也不是同一个概念：前者只提升当前进程权限，后者允许后台组件持续管理虚拟接口，应优先采用客户端提供的服务安装流程。
macOS：芯片架构、系统扩展与网络服务
macOS 安装需要正确区分芯片架构，并留意应用隔离、网络扩展授权与不同网络服务的代理设置。
区分 Apple Silicon 与 Intel
点击苹果菜单中的“关于本机”，查看芯片或处理器字段。显示 Apple 系列芯片时选择 Apple Silicon 或 ARM 架构安装包；显示 Intel 时选择 x64 安装包。新安装优先使用 Clash Plus，也可选择 Clash Verge Rev 或 FlClash。ClashX Meta 已停止维护，保留它通常是为了迁移旧配置，不适合作为新环境的默认选择。架构选错后，应用可能无法打开，也可能通过兼容层运行但出现额外资源消耗，因此应从源头选择匹配文件。
图形客户端常以磁盘映像或压缩文件提供。打开镜像后，应把应用拖入“应用程序”目录，再从该目录启动，不要长期在下载目录或只读镜像中运行。首次启动遇到来源确认时，通过系统设置的“隐私与安全性”查看被阻止的应用，并在确认文件来自本站下载入口后执行系统允许流程。不要通过关闭整个系统安全机制来绕过单个应用确认；正常的授权路径足以完成安装，也便于之后管理网络扩展与后台项目。
导入配置并完成系统代理授权
启动客户端后进入 Profiles、配置或订阅区域，粘贴订阅地址并更新。若 macOS 自动把地址中的特殊字符转换，建议先粘贴到纯文本编辑器确认整行内容，再复制进客户端。配置下载成功后，选择它作为活动配置，打开策略组检查是否能看到节点与 DIRECT、REJECT 等策略。YAML 解析失败时，日志通常会指出缩进或字段类型；远程 provider 失败则可能只影响某一组规则或节点，需要区分主配置加载与附加资源更新。
开启系统代理时，macOS 可能要求输入当前用户密码或使用生物识别，以允许修改网络设置。授权完成后，代理通常写入当前活动的网络服务，例如 Wi‑Fi 或以太网。切换网络服务后，如果新服务没有对应代理设置，客户端可能仍显示开关已开，但应用流量没有进入。此时先关闭再开启系统代理，让客户端针对当前网络重新写入。也可以在“系统设置 → 网络 → 当前网络 → 详细信息 → 代理”查看 Web 代理与安全 Web 代理是否指向本地回环地址。
终端程序与本地网络访问
终端中的 curl、包管理器和开发工具不一定遵循图形系统代理。可以为单次命令设置变量，实际端口以客户端为准：
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
curl -I https://example.com
unset http_proxy https_proxy把变量写入 shell 配置文件之前，应先确认是否需要长期生效。笔记本离开当前网络后，本地 Clash 若没有启动，永久代理变量会让终端请求持续指向空端口。更稳妥的方式是按项目或终端会话启用。局域网共享也应谨慎处理：只有明确需要让其他设备连接时才开启 Allow LAN，并把监听地址、防火墙与可信网络范围一并考虑。日常仅本机使用时，监听回环地址可以减少不必要的局域网入口。
TUN、网络扩展与休眠恢复
启用 TUN 时，客户端可能请求安装辅助服务或添加 VPN 配置。系统设置中应能看到对应网络扩展，菜单栏也可能出现 VPN 状态。第一次授权后若开关立即回落，先检查隐私与安全性页面是否仍有待批准项目，再重启客户端。公司管理的 Mac 可能由配置描述文件限制网络扩展，普通账户无法自行解除，应联系设备管理方确认允许范围。
macOS 同时启用 iCloud 私密转送、企业 VPN、其他代理应用或网络过滤扩展时，流量路径可能互相覆盖。排查时先保留一个接管工具，关闭其余网络扩展，然后从系统代理模式开始验证。睡眠唤醒后若域名无法解析但 IP 可连接，重点检查 DNS 与 TUN 接口是否重新建立；若所有连接都没有进入日志，则检查网络服务切换和系统代理写入。关闭客户端前先关闭系统代理与 TUN，可减少异常退出后系统继续指向本地端口的情况。
应用显示“已连接”只代表本地组件启动，不代表目标连接一定经过预期策略。应在 Connections 或日志中查找访问域名，确认命中的规则和策略组。若浏览器装有独立代理扩展，扩展可能覆盖系统设置，应暂时停用后再做基线测试。更多规则与策略组原理可结合策略组类型详解阅读，避免把自动选择组的健康检查结果直接当作系统网络结论。
Android：VPN 权限、后台运行与按应用分流
Android 客户端通过系统 VPN 接口接管流量，稳定性同时受系统省电、后台限制和厂商网络策略影响。
安装与首次 VPN 授权
Android 新安装优先选择 Clash Plus，也可使用 Clash Meta for Android、FlClash 或 Surfboard。下载前先在系统信息中确认 Android 版本和处理器架构。若下载页提供 ARM64、ARM 与通用包，近年的主流设备通常使用 ARM64，但仍应以设备信息为准。通过浏览器下载安装包时，系统可能要求允许当前浏览器或文件管理器安装应用；完成安装后可以收回该来源权限，避免让临时安装权限长期开放。
首次开启连接时，Android 会显示 VPN 连接确认，这是系统建立本地虚拟网络接口的标准流程。确认后，状态栏通常出现 VPN 标识。若设备已运行另一个 VPN、企业工作资料 VPN、广告过滤工具或私有 DNS 应用，系统可能只允许其中一个接管接口。此时需要先确定哪一个工具负责主流量入口，不应频繁在多个 VPN 应用之间抢占连接，否则会出现开关自动关闭、网络短暂中断或 DNS 路径不一致。
导入订阅与更新配置
进入配置管理页，使用 URL 导入或从文件导入。通过剪贴板粘贴订阅后，检查地址开头、路径与查询参数是否完整。部分输入法会在行尾加入空格，部分聊天软件会截断长地址，都会造成请求失败。导入成功后应主动选择新配置，使它成为当前活动项；只把订阅保存到列表而没有启用，是“能看到配置却没有节点”的常见原因。更新订阅时尽量在网络稳定、VPN 暂时关闭的状态下完成，避免旧配置的规则把订阅请求导向不可用策略。
节点和策略组出现后，先选规则模式与一个明确策略，再启动 VPN。访问网页后打开日志，检查域名是否命中规则。Android 应用可能使用 QUIC、HTTP/3 或独立 DNS，表现与桌面浏览器不完全相同；某个应用失败时，先用系统浏览器建立基础对照，再检查该应用是否被按应用设置排除、是否只走 IPv6、是否启用了自己的安全 DNS。
后台运行与电池策略
移动端最常见的问题不是配置解析，而是系统在锁屏后限制客户端。应在系统的电池设置中把当前 Clash 客户端调整为允许后台运行，并允许必要的自启动或后台活动。不同品牌的菜单名称可能是“电池优化”“后台使用限制”“自启动管理”或“应用启动管理”。只锁定最近任务卡片并不能替代系统级后台权限，它通常只是降低手动清理的概率。还应确认系统的数据节省模式没有限制客户端使用移动数据。
若连接在锁屏数分钟后断开，解锁即恢复，优先检查省电策略与后台限制；若 Wi‑Fi 正常而移动网络失败，则检查移动数据权限、IPv6 和运营商网络环境；若所有网络都会在固定时间失效，则查看订阅中的节点可用性与健康检查。移动端持续 VPN 会产生一定后台活动，规则数量、DNS 查询、频繁健康检查和大量连接都会影响耗电。可参考移动端耗电异常排查，通过减少不必要的频繁测试、保留稳定策略和检查后台唤醒来区分正常消耗与异常循环。
按应用代理、绕过与局域网
Android 客户端通常提供按应用代理，可选择“仅代理所选应用”或“排除所选应用”。建立列表前先明确目标：只让少量应用进入 Clash 时使用包含模式；大多数应用需要规则处理、只有银行或局域网工具需直连时使用排除模式。两种模式含义相反，切换后应重新核对列表。应用升级或重装可能改变内部标识，发现单个应用突然绕过时，应重新进入列表确认。
访问打印机、电视、路由器管理页等局域网设备失败时，先确认配置中局域网地址是否走 DIRECT，并检查客户端是否提供绕过局域网选项。常见私有地址包括 10.0.0.0/8、172.16.0.0/12 与 192.168.0.0/16，但实际网络也可能使用 IPv6 本地地址。不要为了访问一个局域网设备直接切换全局直连并忘记恢复，应该在日志中找到目标地址，增加明确规则或调整局域网绕过设置。
出现“VPN 已连接但没有网络”时，先停止连接，确认手机基础网络可用；再启动客户端并只测试系统浏览器。日志完全没有请求时，检查 VPN 权限和按应用排除；有请求但显示 DNS 错误时，检查 DNS 配置与私有 DNS；请求命中代理后超时，则检查策略和节点。分层观察比反复重装更有效，因为重装不会自动修复订阅、后台策略或冲突的 VPN 应用。
iOS：Clash Plus、VPN 配置与系统限制
iOS 使用系统网络扩展管理连接，安装入口、VPN 授权、按需连接和系统网络服务是主要检查点。
通过 App Store 安装 Clash Plus
iPhone 与 iPad 在本站下载页使用 Clash Plus 的 App Store 入口，客户端官网为 clashplus.io。打开商店页面后按系统流程安装，完成后从主屏幕启动。iOS 上不需要选择处理器架构，也不需要手动安装桌面端格式的文件。若商店页面无法加载，应先确认 Apple ID、网络和系统商店服务本身是否正常，再判断是否属于客户端问题。
首次连接时，系统会请求添加 VPN 配置，并要求使用设备密码、生物识别或系统确认。批准后，可在“设置 → 通用 → VPN 与设备管理”或系统当前版本对应的 VPN 页面看到配置。这个授权只说明系统允许 Clash Plus 创建网络扩展，不代表订阅已经加载或策略已经可用。若拒绝授权，客户端仍可能打开并显示配置列表，但无法真正接管网络，需要回到连接开关重新触发系统确认。
导入订阅与检查配置状态
在 Clash Plus 中打开配置管理，通过 URL 导入订阅。复制地址时应保持完整，不要把地址发送到公开位置。导入后检查配置是否出现在列表，并明确选为活动配置。若订阅下载失败，可先在 Safari 中确认当前网络能否访问订阅域名，但不要直接公开显示订阅内容。若下载成功却没有策略组，查看客户端提供的错误信息，重点区分 YAML 解析失败、远程资源获取失败和空配置。
选择规则模式后，在主要策略组中指定一个节点，再开启连接。首次测试用 Safari 访问普通网页，并回到客户端查看连接记录。连接记录能显示域名、规则和策略时，说明网络扩展已经收到流量；记录为空则检查 VPN 是否真正连接、是否有其他网络扩展接管，以及按需连接规则是否把当前网络排除。某些应用会保持旧连接，切换策略后需要完全关闭并重新打开应用，才能建立经过新路径的连接。
按需连接、蜂窝网络与本地网络
按需连接可以在网络变化或应用发起请求时自动启动 VPN，适合已经验证稳定的配置。首次安装阶段建议先手动控制开关，确认配置、策略和 DNS 正常后再开启自动行为。否则连接自动重试可能掩盖真正的错误：界面不断显示连接中，用户难以判断是配置解析、节点超时还是系统扩展启动失败。启用按需连接后，应分别测试 Wi‑Fi 与蜂窝网络，因为两类网络的 IPv6、DNS 和访问策略可能不同。
若 Wi‑Fi 下可用、蜂窝网络下不可用，检查 Clash Plus 是否允许使用蜂窝数据，并确认系统的低数据模式没有限制后台活动。若蜂窝可用、某个 Wi‑Fi 不可用，则可能是该网络需要认证页面、限制 VPN，或局域网 DNS 与配置冲突。连接公共 Wi‑Fi 时，应先在关闭 VPN 的状态下完成网页认证，再启动 Clash Plus；认证页面通常位于本地网络，若一开始就被代理规则接管，页面可能无法正常弹出。
访问家庭设备时，iOS 可能请求“本地网络”权限。需要发现或连接打印机、媒体设备和局域网服务时，应允许对应权限，并确认规则将私有地址交给 DIRECT。若只是不需要局域网访问，则不必为了排查互联网连接而扩大权限。权限状态可以在系统隐私设置中单独查看，修改后重新启动相关应用，有助于让现有连接按新状态建立。
处理系统网络服务之间的关系
iOS 可能同时启用 iCloud 私密转送、限制 IP 地址跟踪、企业内容过滤或其他 VPN 配置。它们都可能影响 DNS 与连接路径。遇到异常时，应建立单一变量环境：暂时关闭其他网络扩展，只保留 Clash Plus，使用一个手动策略进行测试。若基础连接恢复，再逐项开启其他功能并观察哪一步产生变化。不要仅根据状态栏 VPN 图标判断具体由哪个应用接管，应进入系统 VPN 页面确认当前连接名称。
从飞行模式恢复、Wi‑Fi 与蜂窝切换或设备长时间锁屏后，旧连接可能需要重建。可先在 Clash Plus 内断开再连接；若仍无网络，关闭 VPN 后确认基础网络，再重新启动客户端。日志显示 DNS 超时但代理连接正常时，检查配置中的 DNS 服务器是否适合当前网络；日志显示目标策略超时，则切换到手动节点进行对照。单个应用失败而 Safari 正常时，优先考虑应用缓存连接、系统区域服务、按应用规则或应用自己的网络实现，不要直接删除整个配置。
Linux：图形客户端与 Mihomo 服务化部署
桌面 Linux 可使用 Clash Verge Rev 或 FlClash，服务器与路由环境则适合直接运行 Mihomo 内核。
桌面环境选择安装格式
Linux 图形客户端按下载页顺序选择 Clash Verge Rev 或 FlClash。安装前执行 uname -m 查看架构：常见输出 x86_64 对应 AMD64，aarch64 对应 ARM64。Debian、Ubuntu 及其衍生系统通常使用 deb 包，Fedora、RHEL 系列可能使用 rpm；其他发行版可按下载页提供的格式与项目说明选择。不要把适用于服务器的 Mihomo 压缩包当作带界面的桌面客户端，两者的启动方式、配置目录与系统代理管理方式不同。
安装 deb 包时可使用系统软件中心，也可在终端执行本地安装。文件名应替换成实际下载文件：
sudo apt install ./clash-client-amd64.deb
uname -m
systemctl --user status包管理器能同时处理依赖，比直接调用底层解包命令更适合普通安装。首次启动后，桌面环境可能询问密钥环、后台运行或网络权限。先完成配置导入和本地代理测试，再启用 TUN。GNOME、KDE 与其他桌面对系统代理的支持程度不同，终端程序也通常不会自动读取桌面代理，因此需要通过环境变量或应用自身设置完成验证。
桌面代理与终端环境
图形客户端开启系统代理后，在桌面网络设置中检查 HTTP、HTTPS 与 SOCKS 地址是否指向本地端口。浏览器访问后观察连接日志；终端可临时设置变量：
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"
curl -I https://example.com
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY变量名的大小写支持取决于具体工具，有些程序读取小写形式，有些读取大写形式。不要在不了解应用行为时同时设置多组不同端口，否则请求可能经过与预期不同的协议。包管理器、容器服务和 systemd 服务也不会必然继承交互式 shell 的环境变量，应在对应服务或工具配置中单独声明，并在不需要时移除。
直接运行 Mihomo 内核
服务器、旁路由和没有桌面环境的主机可以运行 Mihomo。准备独立用户与配置目录，将可执行文件放到受控路径，并把配置保存为 YAML。首次启动先在前台运行，使用测试配置观察解析结果，不要一开始就隐藏到后台。下面展示通用命令形态，路径可按系统目录调整：
mkdir -p "$HOME/.config/mihomo"
cp config.yaml "$HOME/.config/mihomo/config.yaml"
chmod 600 "$HOME/.config/mihomo/config.yaml"
mihomo -d "$HOME/.config/mihomo"前台日志能够显示配置解析、监听端口、规则提供者和 DNS 初始化。确认没有错误后，再建立 systemd 服务。服务应指定明确的工作目录、配置目录和运行用户，避免以不必要的高权限长期运行。若需要 TUN，服务账户必须拥有创建网络接口和修改路由所需能力；具体权限应按发行版安全模型配置，而不是简单把所有操作交给 root。
[Unit]
Description=Mihomo Network Service
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3
[Install]
WantedBy=multi-user.target防火墙、监听地址与 DNS
只供本机使用时，应让 mixed-port、控制端口和 API 监听回环地址。需要为局域网提供代理时，才开启 Allow LAN 并配置防火墙来源范围。把控制接口直接监听所有地址而没有访问控制，会扩大管理面暴露范围。服务器上还要区分代理入站端口、DNS 监听端口与外部业务端口，使用 ss -lntup 检查实际监听状态，并确认没有端口冲突。
Linux 的 DNS 可能由 systemd-resolved、NetworkManager、桌面服务或容器网络共同管理。开启 TUN 后域名失败而 IP 可达，先查看 resolvectl status 与客户端日志，确认查询进入哪个 DNS。直接反复覆盖 /etc/resolv.conf 往往只能短时生效，因为网络管理器会重新生成它。正确做法是明确 DNS 责任层：由 Mihomo 劫持并处理，或由系统解析器负责后再进入规则，避免两个服务同时监听同一地址。
升级内核或替换配置时，先执行配置测试并保留当前可启动文件。服务启动失败可用 journalctl -u mihomo 查看日志，重点检查 YAML 解析、权限、目录、端口和网络能力。路由器部署涉及转发、策略路由与局域网 DNS，可先阅读Mihomo 路由器部署概览，确认主路由、旁路由与内核直跑的流量入口后再修改生产网络。
通用配置：端口、模式、DNS 与规则验证
平台界面不同，但内核处理流程一致：流量进入监听入口，完成域名解析与规则匹配，再交给策略组中的具体出口。
认识最小配置结构
一份可工作的配置至少要明确代理入口、运行模式、代理节点或提供者、策略组和规则。图形客户端可能把部分设置保存到应用自己的数据库中，因此界面上的端口、TUN 和 DNS 覆写不一定全部出现在订阅 YAML。排错时应先确认“当前生效配置”来自哪里：是订阅原文、客户端覆写，还是合并脚本生成的最终配置。只查看下载到本地的原始文件，可能无法解释实际运行行为。
mixed-port: 7890
mode: rule
allow-lan: false
log-level: info
proxies:
- name: example-proxy
type: socks5
server: 192.0.2.10
port: 1080
proxy-groups:
- name: PROXY
type: select
proxies:
- example-proxy
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- GEOIP,LAN,DIRECT
- MATCH,PROXY示例中的地址属于文档用途，不能直接作为真实服务使用。mixed-port 同时接受 HTTP 与 SOCKS 连接，便于桌面应用配置；mode: rule 让规则决定出口；allow-lan: false 表示仅本机使用。规则从上到下匹配，首次命中即停止，因此具体域名与局域网规则应放在兜底 MATCH 之前。修改后若客户端仍沿用旧结果，应重新加载配置，并用新建连接测试，已有长连接不会必然立即迁移。
策略组不是节点列表的别名
select 组由用户手动选择；url-test 根据健康检查选择结果；fallback 按顺序使用首个可用项；load-balance 把不同连接分配到多个出口。自动组显示的延迟只代表指定探测请求在某一时刻的结果，不等同于网页、下载或视频的完整体验。探测地址不可达、节点限制探测请求或设备后台受限时，健康检查会失真。可结合Clash 延迟测试原理判断数值范围，并在重要业务前用实际访问结果验证。
策略组还可能互相引用。例如“应用策略”指向“自动选择”，“自动选择”再包含多个节点。日志只显示最终命中组名时，应继续查看组内当前选择。切换上层组后没有变化，可能是下层仍保持同一节点；自动组频繁跳动则可能来自检查间隔过短、容差过小或网络波动。配置目标应是可解释的稳定路径，不是让所有流量都经过最多层级的自动选择。
DNS 模式与解析路径
DNS 决定域名先被解析到什么地址，也影响基于域名的规则能否准确命中。系统代理模式下，部分应用会把域名交给代理处理，另一些会先在本地解析；TUN 模式还可能启用 DNS 劫持，使查询统一进入内核。常见 fake-ip 模式为域名分配保留地址并在内核内部保存映射，便于还原域名和匹配规则；redir-host 更接近先获得真实地址再处理。局域网服务、游戏平台、设备发现和某些安全软件可能对 fake-ip 较敏感，可通过过滤列表让特定域名使用真实解析，而不是直接关闭整套 DNS 功能。
DNS 故障应按现象判断：域名失败而直接访问 IP 正常，说明重点在解析；日志中没有 DNS 请求，可能查询被其他应用或系统服务处理；返回地址正常但连接超时，则问题已进入路由或出口层。启用加密 DNS 时还要考虑其服务器域名如何解析，避免形成“需要代理才能解析代理所需 DNS”的循环。建议保留至少一条与当前网络兼容的基础解析路径，并用日志确认查询实际走向。
使用日志完成可重复验证
验证规则时选择一个目标域名，清空或记住当前日志位置，然后发起一次新访问。记录源应用、目标域名或地址、命中规则、策略组和最终节点。若没有记录，说明流量没进入 Clash，应回查系统代理、VPN/TUN 与应用自身设置；若命中 DIRECT 但预期代理，检查规则顺序、域名形式与规则提供者是否加载；若命中正确策略却连接失败，再检查节点、DNS、IPv6 与目标服务。
| 现象 | 优先观察 | 下一步 |
|---|---|---|
| 日志没有目标请求 | 系统代理、VPN、TUN、按应用设置 | 确认流量入口 |
| 规则命中与预期不同 | 规则顺序、域名、provider 状态 | 用更具体规则复测 |
| 命中正确但超时 | 策略组当前项、节点与 DNS | 切换手动节点对照 |
| 仅少数应用失败 | 应用代理支持、QUIC、IPv6 | 与系统浏览器对比 |
日志级别在日常使用中保持 info 即可；排查短时问题时可提高详细度，但应在完成后恢复，避免长期产生大量记录。分享日志前应移除订阅地址、认证信息、节点地址和个人域名。配置变更应有明确目的，例如“验证 DNS 是否导致失败”，而不是同时替换节点、规则和网络模式。一次一个变量、一次一个测试请求，是这套手册中最重要的实验方法。
配置常见问题与分层排查
把故障拆成基础网络、客户端进程、配置加载、流量入口、规则策略和目标连接六层，能减少无效重装。
客户端启动后完全无法上网
第一步关闭系统代理和 TUN 或移动端 VPN，确认设备基础网络是否恢复。若关闭后仍无法访问，问题可能是系统代理残留、DNS 没有恢复、网络本身中断或另一个 VPN 仍在运行。桌面端检查系统代理页面是否还指向 127.0.0.1 的旧端口；移动端检查状态栏和系统 VPN 页面；Linux 检查环境变量、路由与解析器。只有基础网络恢复后，才重新启动 Clash 继续验证。
第二步只开启客户端，不接管系统流量，确认配置能正常加载、代理端口正在监听。第三步开启系统代理或 VPN，使用系统浏览器访问一个目标，并观察日志。日志为空说明入口问题；日志有记录但 DNS 报错，应检查解析；日志命中策略后超时，则切换手动节点。通过这三步可以把“无法上网”从一个模糊结果拆成明确层级。更集中、按问答形式整理的处理方法可在常见问题页面继续查阅。
订阅更新失败或导入后没有节点
先确认订阅地址复制完整，并且当前基础网络能访问订阅服务。若客户端正在使用旧配置，订阅更新请求可能被旧规则导向失效节点，可暂时断开代理后重试。HTTP 错误表示远程请求没有获得预期内容；YAML 解析错误表示内容已下载，但格式或字段不符合配置要求；provider 错误可能只影响远程节点组或规则集。三种错误的处理方向不同，不应统一归结为“客户端坏了”。
导入后没有节点时，确认配置已经被选为活动项，并查看代理组是否为空。有些订阅只返回基础片段，需要客户端支持特定处理方式；有些地址在浏览器中返回登录页或提示文本，而不是 YAML。不要把网页错误内容保存成配置文件反复导入。若旧配置仍可使用，保留它作为恢复路径，再联系配置提供方确认订阅状态。频繁删除全部配置会同时移除可用基线，使排查更困难。
系统代理有效，但 TUN 无法启动
系统代理可用说明配置、节点和基本规则大致正常，问题范围可以缩小到权限、服务、虚拟接口、路由或 DNS。Windows 检查客户端服务是否安装、虚拟网卡是否创建，以及安全软件是否阻止；macOS 检查网络扩展与 VPN 配置授权；Linux 检查运行用户的网络能力、内核模块、防火墙与策略路由。移动端的系统 VPN 本身相当于主要流量入口，应检查是否被其他 VPN 抢占。
TUN 开启后立即断网时，先关闭它恢复系统代理基线，再查看启动阶段第一条错误。常见问题包括默认路由未建立、DNS 监听端口冲突、严格路由与本地网络不兼容、IPv6 路径异常或另一个虚拟接口优先级更高。不要把 TUN 视为必须开启的性能按钮；如果所需应用都遵循系统代理，系统代理模式已经能够完成规则分流。只有确实需要接管不读取代理设置的程序、UDP 或更广流量时，再处理 TUN 权限与兼容性。
节点延迟正常，但网页仍然缓慢
延迟测试通常是短请求，只覆盖 DNS、连接建立和探测目标的一部分。实际网页还受线路拥塞、丢包、TLS 建连、目标站点位置、并发资源与传输速率影响。选择节点时不要只比较一个数字，应观察多次测试的稳定性，并用实际业务建立对照。自动策略组频繁切换也可能让长连接中断，适当的容差和检查间隔比追求最低瞬时数值更重要。
只有某个网站缓慢时，查看它命中的规则和策略，确认是否被分配到不合适的组；所有网站都慢时，分别测试 DIRECT 与手动节点，区分本地网络和代理出口。浏览器正常而视频或下载慢，还要考虑应用使用 UDP、QUIC 或多连接传输。日志里出现大量重试、DNS 超时或策略切换时，应先处理这些明显信号，再考虑更换客户端。
配置修改后没有生效
首先确认编辑的是当前活动配置，而不是订阅缓存、副本或未选中的文件。订阅更新可能覆盖本地直接修改，因此长期自定义应使用客户端支持的覆写、合并或脚本机制。保存 YAML 后执行重新加载，并查看日志是否报告语法错误。YAML 对缩进敏感，列表项、冒号后的空格和字符串类型都可能影响解析。规则名称还必须与策略组名称完全对应，大小写或字符差异会导致加载失败。
其次建立新连接。浏览器已经打开的页面、即时通信长连接和下载任务可能继续沿用旧路径，切换模式并不会让所有既有连接自动重建。关闭相关应用或等待连接结束后再测试。DNS 缓存也可能保留旧结果，可先换一个未访问域名进行验证，再决定是否需要清理系统缓存。修改生效的证据应来自日志中的新规则与新策略，而不是只看开关位置。
恢复到可工作的最小状态
当修改过多导致无法判断时，按固定顺序恢复：关闭 TUN 与系统代理，退出其他网络工具，确认基础网络；启动 Clash 并加载一份曾成功的简单配置；手动选择一个策略；开启系统代理或移动端 VPN；用系统浏览器发起新请求；检查日志。基线成功后，再依次加入 DNS 自定义、规则提供者、自动策略组、按应用分流和 TUN。每加入一项都保留一次验证结果。
如果仍需重装，先记录客户端名称、系统架构、配置来源、错误文本和已尝试步骤。卸载前关闭系统代理、TUN 与后台服务，避免系统继续引用已删除的本地端口。重装后不要立即导入全部旧设置，先用最小配置验证。首次安装的完整检查清单还可参考Clash 首次安装怎么设置。这种恢复方法的目标不是回避复杂功能，而是先把变量数量降到足以观察，再逐项重建可靠环境。