客户端入口 · 配置字段 · 问题排查

Clash 客户端下载
与配置帮助中心

查找多平台客户端,理解 mihomo 内核,按中文配置文档完成连接。

  • config.yaml
  • 订阅与规则
  • 系统代理与 TUN

客户端下载入口

先确认操作系统与处理器架构,再选择安装包。桌面图形客户端、移动应用与独立内核的使用方式不同。

客户端负责配置导入、策略选择与系统集成,内核负责执行代理协议和分流规则。只下载独立内核不会出现桌面设置窗口,也不会自动替应用填写系统代理。首次使用建议先选图形客户端,按教程完成一次订阅导入和连接验证,再考虑透明代理或路由器部署。

安装成功不等于已有可用配置。订阅地址通常由用户使用的服务提供,本站不生成节点或订阅。导入前确认链接来源,避免把含有访问凭据的完整地址贴到公开讨论中。更换客户端时先保留原配置与策略选择,待新客户端验证通过,再停止旧客户端,减少同时监听相同端口造成的冲突。

已经安装 Clash for Windows 的用户,应先了解其停止维护状态,再评估迁移。保留配置文件并不代表所有旧字段都能直接沿用;迁移到使用 mihomo 的客户端后,仍需检查代理协议、DNS 配置和策略组名称。下载页按平台列出可选客户端,具体系统要求与维护状态以对应条目为准。

Clash 配置使用场景

从具体任务进入字段参考。以下片段用于解释配置结构,使用前需要与现有配置合并并检查引用关系。

订阅导入与更新

订阅管理解决的是配置来源与持续更新问题,不是网络接管本身。先在客户端的配置或订阅页面添加 URL,更新成功后选中对应配置,再检查策略组是否出现可选项。链接返回的内容必须符合客户端支持的格式,节点文本列表不能一律当作完整 YAML 使用。与逐条录入节点相比,订阅便于集中维护,但远端更新也可能覆盖本地修改。建议把个人规则放入客户端提供的覆写入口,更新失败时先看下载错误和解析日志,不要反复删除已可用的配置。

查看配置参考 ›

配置与代理集合分开

完整配置可以同时定义监听端口、DNS、策略组和规则;代理集合则只提供代理条目,通常由 proxy-providers 引入。两者职责不同,导入入口也不一定相同。需要保留自定义分流时,可以让主配置引用代理集合,再由策略组通过 use 关联。与整份配置替换相比,这种方式能减少节点更新对规则结构的影响,但需要自行维护名称、路径和策略组引用。开始拆分前先备份原文件,确认集合能够加载,再逐项迁移,避免一次改动多个层级。

查看配置参考 ›

开源生态与维护依据

把客户端、内核和配置来源分开理解。遇到问题时,先确定负责这一行为的组件,再选择对应的文档与排查入口。

CLIENT / CORE

Clash、mihomo 与客户端的关系

Clash 生态并不是一个统一更新的应用。历史上的 Clash 内核、后续分支以及不同图形客户端,各有自己的发布与维护范围。mihomo 是这一生态中持续发展的内核项目,常见桌面客户端会在其外部提供配置管理、代理切换和系统集成界面。界面相似,不代表内核能力和默认设置完全相同;迁移配置时,应以实际运行的内核及客户端说明为准。

图形客户端上的开关通常会影响内核配置或操作系统状态。例如系统代理开关修改系统代理入口,TUN 开关则涉及虚拟网络接口和路由。部分客户端会在启动时生成最终配置,因此编辑磁盘中的某份 YAML 后,界面不一定立即使用它。判断配置是否生效,应同时确认当前选中的配置、覆写结果以及重载日志,不能只凭文件保存成功作结论。

查阅开源代码可以了解实现与配置演进,但源代码仓库不是普通用户安装应用的必要步骤。首次使用从下载页选择适合系统的客户端即可。需要核对底层行为时,再查看 mihomo 项目的文档、发布说明或相关代码。本站提供中文查阅路径与字段解释,不把不同客户端的功能归并成一个统一产品,也不代替项目维护者作兼容性承诺。

HISTORY / MIGRATION

停止维护后的迁移判断

Clash for Windows 停更后,旧客户端仍可能在已有环境中运行,但这不能推导出它会持续适配新的系统、协议或配置字段。选择迁移对象时,重点检查维护状态、所用内核、设备架构和原配置中的功能需求。只因为名称相近就直接替换程序,容易忽略系统服务、配置目录及开机启动项的差异,也可能留下重复运行的代理进程。

迁移前先导出或备份当前配置,记录本地监听端口、使用中的策略组以及自定义规则。新客户端首次启动时先导入配置,不必立即启用全部接管功能。完成语法检查后,选择一个明确的测试目标,确认连接能够出现在客户端中,并核对匹配规则和实际出口。只有这一条链路通过验证,才继续迁移覆写、局域网连接或 TUN 等设置。

如果遇到端口占用,先确认旧客户端或后台服务是否仍在监听,再决定停止进程或修改端口。不要直接删除旧配置目录来解决冲突。修改 mixed-port 后,还需要同步调整手动填写代理地址的应用;否则内核虽然启动成功,应用仍会访问原端口。常见差异可先查看 FAQ,具体操作顺序可对照 Clash 使用教程。

SOURCE / PRIVACY

配置来源与分享边界

代码开源意味着可以查阅实现,不意味着任意订阅、转换服务或网络出口都值得信任。客户端、配置提供方和出口服务承担不同职责,下载一个客户端不会自动获得远端服务。添加订阅前应确认来源和用途,理解配置中包含哪些代理、规则及 DNS 上游。来自陌生来源的完整配置可能改变流量路径,导入后仍应检查关键字段与策略组。

订阅链接可能带有访问凭据,配置文件也可能包含账户、密码或专属服务器信息。求助时优先提供客户端名称、系统类型、报错文本和经过脱敏的最小片段,不要直接上传完整配置。截图同样要检查地址栏、二维码和日志中的敏感信息。需要说明规则问题时,通常只需给出规则顺序、相关策略组名称以及目标连接的命中结果。

排查应尽量保持测试条件稳定。先固定一个目标、一种接管方式和一个出口,再观察 DNS、规则与连接结果。一次同时更换订阅、节点、模式和解析方案,即使恢复访问也难以确认原因。保留可工作的基线配置,逐项调整并记录结果,比复制大量来历不明的参数更便于长期维护。涉及工作网络或受管理设备时,还应遵守所在环境的网络使用规定。

UPDATE / VERIFICATION

程序更新与配置更新分开

客户端更新、内核更新、订阅更新和规则资源更新是不同过程。更新应用不一定会刷新远程订阅;订阅更新也不代表内核已经具备新增字段的支持。发现某个选项无法解析时,先核对字段属于哪个内核及适用范围,再检查客户端实际运行的内核信息。不要把配置解析失败简单归因于节点不可达,两者发生在不同阶段,需要不同的排查证据。

涉及 GeoIP 或规则资源时,应确认配置究竟引用哪种数据格式、存放位置和更新入口。更换一个文件名不能保证内核会读取它,文件存在也不代表当前规则正在使用它。修改后重新加载配置,检查日志中是否出现资源加载错误,再查看目标连接匹配到的规则。若使用远程规则集合,还应区分资源下载失败、格式错误以及规则顺序不当这几种情况。

验证结果时,网页能够打开只是第一步。还应检查需要直连的局域网服务、未遵循系统代理的应用以及设备休眠后的恢复情况。节点测速用于观察指定测试请求的表现,不能替代实际业务验证。遇到异常时,记录发生条件、错误信息与最近改动,再按端口、解析、规则、出口的顺序缩小范围。字段级解释和 YAML 示例集中在 配置参考,便于按需查阅。

配置与排查近期文章

按具体问题阅读操作步骤。先理解流量经过的层级,再修改相关配置,避免同时调整多个变量。