客户端入口
先确认操作系统与处理器架构，再选择安装包。桌面图形客户端适合日常使用；内核包面向需要自行管理配置与服务的用户。
安装包、客户端和订阅是三个不同环节。安装客户端只提供本机配置与流量转发能力，实际连接还需要可用的服务配置。已有订阅的用户应先确认订阅格式是否适配所选内核，再进行导入；第一次使用时，建议保留默认端口与规则模式，待基本连接成功后再调整高级选项。
从旧客户端迁移时，不必直接覆盖整个数据目录。先备份订阅地址、本地规则和策略选择，再在新客户端中逐项恢复。旧配置里的脚本、覆写字段或专属设置未必能原样迁移；遇到报错时，应先用原始订阅测试，再加入本地修改。
查看全部客户端 →设置页陈列台
下面的界面碎片用于说明设置含义，并非可操作的客户端窗口。不同客户端的菜单位置可能不同，排查顺序可以保持一致：配置、内核、监听端口、流量入口、匹配规则。
系统代理将 Windows 的代理地址指向客户端的本机监听端口，适合浏览器和遵循系统设置的应用。使用前先导入可用配置，确认内核已经启动，再打开系统代理。若只有部分应用能连接，不代表订阅失效；有些程序使用独立网络栈，需要单独设置代理或改用 TUN。与直接修改系统设置相比，客户端开关便于统一启停。排查时先关闭其他代理工具，避免多个程序反复覆盖同一项设置。
去教程看这一步 →TUN 通过虚拟网卡和路由设置接入流量，适合需要处理命令行、游戏或独立网络栈应用的场景。Windows 上通常需要先安装客户端服务或授予相应权限，再开启 TUN。它与系统代理的区别在于流量入口，而不是自动改变分流策略；进入内核后仍按当前模式和规则处理。开启后应检查 DNS、路由与局域网访问。若连接异常，先停用其他 VPN，再单独测试 TUN，避免同时修改多处网络设置而难以定位原因。
去教程看这一步 →规则分流把域名、目标 IP 或其他匹配条件映射到直连策略与代理策略组。规则通常自上而下匹配，先命中的条目决定连接路径，因此局部例外应放在兜底规则之前。示例中的 PROXY 需要是配置里真实存在的策略组，并非固定内置名称。与全局模式相比，规则模式可以分别处理不同目标；与直连模式相比，它保留代理出口。测试时查看连接记录中的命中规则和最终策略，避免只凭网页是否打开判断规则是否生效。
去教程看这一步 →订阅导入负责取得配置，选择配置负责让内核使用它，两者不是同一步。粘贴链接后先确认下载与解析成功，再激活对应配置并检查策略组。远程更新可能替换原始文件，因此端口、规则等本地调整更适合放在客户端支持的覆写或合并功能中。与每次手动编辑订阅文件相比，这种方式更利于持续维护。更新失败时先看返回内容与错误提示，区分链接过期、格式不兼容和请求失败；订阅地址可能包含访问凭据，不应公开分享。
去教程看这一步 →混合端口在同一监听入口接受 HTTP 与 SOCKS 代理连接，常见示例为 7890，但应以当前配置为准。端口被占用时，先定位占用进程，再决定结束重复客户端或更换端口；修改后还要同步检查系统代理和应用独立设置。局域网共享则需要额外检查允许局域网、监听地址、防火墙与访问控制。与仅供本机使用相比，共享会扩大可访问范围，应限于可信网络并配置认证，不能把监听服务直接暴露到公共网络。
去教程看这一步 →图形客户端负责订阅管理和系统集成，内核负责协议连接、DNS 与规则处理。部分客户端允许切换内核或更新通道，另一些则随安装包一同更新，应以实际界面为准。与更换主题不同，内核变化可能影响协议支持和配置字段。操作前先备份可用配置，阅读对应更新说明，再确认配置能够解析、内核正常启动。普通使用优先选稳定通道；出现新字段报错时，应核对内核兼容性，而不是反复重新导入同一条订阅。
去教程看这一步 →开关显示开启，只能说明客户端尝试应用设置，不等于每个程序都已经接入。先使用一个遵循系统代理的浏览器访问目标，再查看连接记录是否出现请求。如果完全没有记录，优先检查系统代理、应用独立设置与监听端口；如果已经有记录但请求失败，再检查策略组选择、DNS 解析和服务配置。这个顺序能把本机入口问题与远端连接问题分开。
节点延迟测试只反映特定测试地址和测试方式下的结果，不能替代实际应用验证。网页、下载、实时通信对连接的需求不同，某项测试成功也不保证所有目标均能访问。记录失败应用、发生时间、当前模式和命中规则，再一次只改变一项设置，通常比同时重装客户端、换端口和改 DNS 更容易找到原因。查看节点延迟与连接验证说明 →
开源生态
客户端名称、内核名称与订阅格式经常同时出现。分清各自负责的部分，更容易选对软件，也更容易判断问题应该从哪里查起。
Clash 生态包含内核与多个独立维护的图形客户端。原版 Clash 项目停止维护后，社区延续了相关开发；Clash.Meta 分支后来采用 mihomo 名称。旧教程里的 Meta 与新文档里的 mihomo 往往有关联，但不能据此认为每份旧配置都能直接适配当前客户端。阅读说明时，应同时核对文章所指的内核家族和实际使用环境。
配置兼容不只是能否读取 YAML。某个协议、DNS 选项或规则类型是否可用，取决于内核实现；订阅导入、服务模式、开机启动等功能则取决于客户端。遇到缺少功能时，先确认它属于哪一层。更换图形界面不一定改变内核能力，更新内核也不一定改变客户端的菜单位置。
需要比较协议时，重点看现有服务支持什么、设备资源是否适合、网络条件是否匹配。不能仅凭协议名称判断连接表现，也不宜把某一种协议当作所有场景的固定答案。移动设备还要考虑后台运行与电量消耗。阅读协议与内核技术参考 →
开源仓库可以帮助确认项目的实现、许可证与问题讨论。mihomo 的源代码与文档由项目社区维护，更新说明会记录功能变化和修复内容。本站提供下载入口与中文使用资料，不代替上游项目的发布说明，也不把不同维护者的客户端视为同一个产品。选择时应关注项目当前维护状态与系统兼容情况。
更新前先保存本地规则、覆写设置及可用配置。安装完成后检查内核能否启动，再验证系统代理或 TUN；若变更涉及 DNS、路由或配置语法，应逐项复测。日常使用可优先稳定发布，遇到明确修复需求时再评估其他通道。不要因为某个安装包时间较新，就忽略配置迁移说明或当前系统的支持范围。
下面的命令用于取得 mihomo 源代码，适合开发与查阅，不是安装图形客户端的步骤。执行前需要本机已安装 Git；普通用户直接进入下载页选择客户端即可。复制命令不会运行程序，也不会修改本机代理设置。
git clone https://github.com/MetaCubeX/mihomo.git客户端安装完成后，还需要导入可用配置并激活。先检查配置是否解析成功、策略组是否存在，再确认系统代理或 TUN 的流量入口。订阅获取失败与代理连接失败是两个环节，错误提示也不同；应先解决导入问题，再验证连接。查看订阅导入步骤 →
不必把两个开关同时开启作为固定前提。浏览器等遵循系统设置的应用可先用系统代理验证；需要接管其他应用时，再按教程启用 TUN。两者配合方式取决于客户端与路由设置，排查时建议逐项测试，并留意其他 VPN 或虚拟网卡的影响。查看 TUN 配置步骤 →
远程订阅更新通常会重新取得原始配置。如果本地规则直接写进该文件，更新时可能被替换。建议把例外规则保存在客户端支持的覆写或合并区域，并检查合并后的规则顺序。迁移到另一个客户端时，需要重新确认覆写方式，而不是只复制文件。查看规则维护步骤 →
配置与排查文章
基础连接完成后，再按具体问题深入。排查前记下客户端名称、当前模式和错误提示，分享日志时移除订阅地址与连接凭据。
归纳订阅更新失败的常见原因：链接失效、返回格式不兼容、更新请求被自身代理拦截，并说明如何设置自动更新间隔和手动强制刷新。
阅读文章 →微软商店应用的回环访问限制可能导致系统代理对其无效。了解客户端内置工具、CheckNetIsolation 命令和 TUN 模式三种处理方式。
阅读文章 →区分 TUN 虚拟网卡与系统代理，了解 Windows 服务模式、DNS 劫持与流量接管的检查顺序，判断哪些应用需要进一步配置。
阅读文章 →