我做了一个 Raycast 版 Clash
原来的客户端总闪退，而我只需要启动、系统代理、手动固定节点、自动选择最快节点和规则调度，于是把 Clash 的日常控制面搬进了 Raycast。
众所周知，对于一个程序员来说，连不上外网就不会工作了。
这句话听起来像段子，但很多时候就是事实。GitHub 打不开，文档打不开，AI 编程助手连不上，包管理器下载失败，工作流一下就断了。
所以我一直需要一个稳定的代理客户端。
但不知道从什么时候开始，我原来用的软件经常闪退。它一闪退，我就要重新打开，再确认系统代理有没有生效，再看节点是不是还活着。最烦的不是某个网站打不开，而是我不知道问题到底出在哪一层。
是客户端没启动？系统代理没开？节点挂了？规则走错了？还是浏览器根本没有走代理？
我真正想要的其实不是一个功能完整的大客户端。
我不需要每天看日志，不需要复杂设置，也不需要一个常驻窗口。我只需要几个高频动作：
- 开机能启动。
- 系统代理能自动打开。
- 多个订阅能统一管理。
- 常用节点能手动固定，也能自动选最快的。
- 规则能快速调整。
- 出问题时能知道是哪一层坏了。
既然这些动作都很短，为什么不能直接放进 Raycast？
于是我做了一个插件：Clash for Raycast。
不做大客户端
这个项目一开始就不是为了重写一个完整 Clash 客户端。
现在已经有很多成熟选择。Clash Verge Rev 是完整 GUI，支持跨平台、TUN、配置增强、节点和规则可视化编辑。FlClash 走桌面和移动端跨平台路线。ClashX 更像传统 macOS 菜单栏客户端。
这些产品解决的是“完整代理客户端”的问题。
我想解决的是另一件事：当代理只是开发工作流里的基础设施时，控制面能不能更短？
我每天已经在 Raycast 里启动应用、搜命令、执行脚本、管理开发工具。对我来说，代理工具也应该像一个命令，而不是一个需要切过去研究的独立窗口。
所以这个插件只保留三个入口：
| 命令 | 用来做什么 |
|---|---|
Clash Setup | 安装 core、生成配置、启动后台服务、检查健康状态 |
Clash Dashboard | 看状态、切路线、管订阅、测节点、切换节点模式、开关系统代理 |
Clash Rules | 查看规则、添加自定义规则、调整规则顺序 |
这不是功能更多，而是路径更短。
先完成初始化
安装插件之后，第一个入口应该是 Clash Setup。
它负责把基础设施先跑起来：安装 core，生成配置，启动后台服务，检查 Core API 和系统代理。
这一步完成后，日常使用才会回到 Clash Dashboard 和 Clash Rules。如果之后网络又出问题，我也会先回到这里看是哪一层没准备好。
先看状态
我最需要的是一个总控台。
以前遇到网络问题，我要先猜：是不是系统代理关了，是不是 core 没跑，是不是端口冲突，是不是规则走错。现在打开 Clash Dashboard，第一眼就能看到关键状态。
这个页面不追求信息很全，只追求我马上能判断现在能不能工作。
系统代理开没开，当前路线是什么，core 有没有运行，当前是 rule 模式还是别的模式，常用代理组现在选中了谁，这些信息够了。
如果我只是想临时切到某个路线，也不用打开完整客户端。在 Raycast 里选中 route，回车，完成。
再选节点
我最想要的功能，其实是固定路线。
比如我经常希望走新加坡节点。但“走新加坡”其实有两种完全不同的场景。
一种是我已经知道哪个节点稳定，想先固定住，不希望客户端自己切来切去。另一种是我只关心这个分组里哪个最快，希望它自己根据延迟选择。
所以我的真实需求不是简单的“自动选择”，而是先把所有订阅里的新加坡节点放到一个组里，再根据当天的工作状态决定：手动固定，还是自动最快。
这就是自定义代理组。
自定义组只保留两个模式：
| 策略 | 含义 |
|---|---|
Manual Select | 我手动选一个节点，适合需要稳定固定路线的时候 |
Always Fastest | 从选中的节点里自动选择当前最快的，适合只关心延迟的时候 |
这比把所有策略都摊开更贴近我的使用习惯。
有时候我想表达的是：“今天就走这个节点，不要动。”有时候我想表达的是：“今天走新加坡，具体哪个节点你帮我选。”
这两个动作都应该在同一个节点页面里完成，而不是逼我回到配置文件里改代理组。
规则要好调
另一个高频问题是规则。
很多时候不是节点坏了，而是规则把流量打到了错误方向。比如某个开发工具、AI 服务、海外文档站没有被规则集覆盖，最后走了直连，就会出现很难判断的失败。
所以我做了一个 Clash Rules 页面。
它不是为了替代完整配置编辑器，只是把最常用的几个动作放到 Raycast 里：
- 看规则顺序。
- 看这条规则走
DIRECT、PROXY还是REJECT。 - 添加一条自定义规则。
- 调整自定义规则的位置。
- 打开规则集来源。
因为 mihomo 的规则是从上到下匹配的，所以规则顺序本身就会影响结果。这个页面要解决的不是“重新设计规则”，而是让我能快速看懂：当前这条流量为什么会这样走。
规则本身没有重新造一套，主要沿用成熟客户端里常见的配置思路：内置规则负责基础分流，自定义规则负责临时补充，最后未知流量默认走 PROXY。
为什么是 Raycast
这个插件最重要的设计取舍，其实不是 Clash，而是 Raycast。
如果做成完整客户端，我就会不可避免地开始做菜单栏、设置页、流量图、配置编辑、TUN、同步、日志面板。那些都可以做，但它们不是我最痛的地方。
我的痛点是操作路径太长。
我想要的是：
- 搜
clash就能看到入口。 - 安装后先把 core、配置和系统代理检查清楚。
- 打开 Dashboard 就知道当前网络状态。
- 切路线像切一个命令。
- 新加坡节点能手动固定，也能自动选最快。
- 规则问题能快速补一条。
- 出故障能先看健康检查。
这就是 Raycast 适合它的原因。
它不是一个“更完整”的 Clash 客户端，而是一个“更靠近我工作入口”的 Clash 控制台。
做完后的感觉
这个项目让我再次确认了一件事：AI 时代，很多个人工具都值得重做一遍。
以前这种需求大概率会被放弃。客户端偶尔闪退，忍一下；节点不好选，手动切；规则不好调，去配置文件里改；系统代理漂移，重启客户端。
因为专门为自己做一个工具，成本太高。
现在不一样了。
你可以把现成能力重新组合起来：mihomo 负责代理核心，Raycast 负责入口，launchd 负责后台服务，macOS system proxy 负责系统接入，插件负责把它们变成一个顺手的工作流。
Clash for Raycast 对我来说就是这样一个工具。
它不是更大的 Clash。
它是我自己的网络开关。
项目地址
源码已经放到 GitHub：wuyuxiangX/clash-for-raycast。