メインコンテンツへスキップ
Raycast版Clashを作ってみました 的文章封面图

Raycast版Clashを作ってみました

手書き

以前のクライアントはよくクラッシュし、私が必要としていたのは起動、システムプロキシ、手動でのノード固定、最速ノードの自動選択、ルールスケジューリングだけでした。そこで、Clashの日常的なコントロールプレーンをRaycastに移植しました。

·5 分で読める

プログラマーにとって、外部ネットワークに接続できないと仕事にならないというのは周知の事実です。

これは冗談のように聞こえますが、多くの場合、事実です。GitHubが開けない、ドキュメントが開けない、AIプログラミングアシスタントに接続できない、パッケージマネージャーのダウンロードが失敗する、といったことでワークフローが途絶えてしまいます。

そのため、私は常に安定したプロキシクライアントを必要としていました。

しかし、いつからか、以前使っていたソフトウェアが頻繁にクラッシュするようになりました。クラッシュするたびに、再起動し、システムプロキシが有効になっているか確認し、ノードがまだ生きているか確認しなければなりません。最も煩わしいのは、特定のウェブサイトが開けないことではなく、問題がどの層にあるのか分からないことです。

クライアントが起動していないのか?システムプロキシがオフになっているのか?ノードがダウンしているのか?ルールが間違っているのか?それともブラウザがそもそもプロキシを通っていないのか?

私が本当に求めていたのは、機能が充実した大規模なクライアントではありませんでした。

毎日ログを見る必要も、複雑な設定も、常駐ウィンドウも必要ありません。私が必要なのは、いくつかの頻繁な操作だけです。

  1. 起動時に自動的に起動する。
  2. システムプロキシが自動的にオンになる。
  3. 複数のサブスクリプションを一元管理できる。
  4. よく使うノードを手動で固定したり、最速のノードを自動選択したりできる。
  5. ルールを素早く調整できる。
  6. 問題が発生したときに、どの層が壊れているかを知ることができる。

これらの操作がすべて短いのであれば、Raycastに直接組み込めないでしょうか?

そこで、私はプラグインを作成しました。それが「Clash for Raycast」です。

Raycastでclashを検索すると、Clash Dashboard、Clash Setup、Clash Rulesの3つのコマンドが表示される
Clash for RaycastのエントリポイントはSetup、Dashboard、Rulesの3つだけです。

大規模なクライアントは作らない

このプロジェクトは、最初から完全なClashクライアントを再構築することを目的としていませんでした。

現在、多くの成熟した選択肢があります。Clash Verge Rev は完全なGUIで、クロスプラットフォーム、TUN、設定強化、ノードとルールの視覚的編集をサポートしています。FlClash はデスクトップとモバイルのクロスプラットフォーム路線です。ClashX は、従来のmacOSメニューバークライアントに近いものです。

これらの製品は、「完全なプロキシクライアント」の問題を解決しています。

私が解決したいのは別のことです。プロキシが開発ワークフローのインフラストラクチャに過ぎない場合、コントロールプレーンをもっと短くできないでしょうか?

私は毎日Raycastでアプリケーションを起動し、コマンドを検索し、スクリプトを実行し、開発ツールを管理しています。私にとって、プロキシツールも、切り替えて調べる必要がある独立したウィンドウではなく、コマンドのようにあるべきです。

そのため、このプラグインは3つのエントリポイントのみを保持しています。

コマンド用途
Clash Setupコアのインストール、設定の生成、バックグラウンドサービスの起動、ヘルスチェック
Clash Dashboard状態の確認、ルートの切り替え、サブスクリプションの管理、ノードのテスト、ノードモードの切り替え、システムプロキシのオン/オフ
Clash Rulesルールの表示、カスタムルールの追加、ルールの順序調整

これは機能が多いのではなく、パスが短いのです。

まず初期化を完了する

インストール、設定、サービス、プロキシ、通過の5ステップで初期化を示す手書きのフローチャート
プラグインのインストール後、まず初期化を完了します。コア、設定、バックグラウンドサービス、システムプロキシがすべて準備できてから、DashboardとRulesが日常使用に入ります。

プラグインをインストールした後、最初のエントリポイントは Clash Setup であるべきです。

Clash Setupのヘルスチェックで、コア、サブスクリプション、設定ファイル、launchdサービス、コアAPI、システムプロキシがすべて準備完了と表示される
Setupページは初期化とヘルスチェックを担当します。コア、サブスクリプション、設定、バックグラウンドサービス、API、システムプロキシがすべて正常かどうかを確認します。

これは、インフラストラクチャを稼働させる役割を担っています。コアのインストール、設定の生成、バックグラウンドサービスの起動、Core APIとシステムプロキシのチェックを行います。

このステップが完了すると、日常使用は Clash DashboardClash Rules に戻ります。その後、ネットワークに問題が発生した場合も、まずここに戻って、どの層が準備できていないかを確認します。

まず状態を確認する

私が最も必要としているのは、総合的なコントロールパネルです。

以前は、ネットワークの問題に遭遇すると、システムプロキシがオフになっているのか、コアが実行されていないのか、ポートが競合しているのか、ルールが間違っているのか、と推測しなければなりませんでした。今では Clash Dashboard を開くと、すぐに重要な状態を確認できます。

Clash Dashboardにシステムプロキシ、現在のルート、コアバージョン、アウトバウンドモード、プロキシグループ、サブスクリプションが表示される
Dashboardは日常のエントリポイントです。システムプロキシ、現在のルート、コアの状態、プロキシグループがすべて1つのリストに表示されます。

このページは、すべての情報を網羅することを目指しているのではなく、すぐに仕事ができるかどうかを判断できることを目指しています。

システムプロキシがオンになっているか、現在のルートは何か、コアが実行されているか、現在のモードはルールモードかそれ以外のモードか、よく使うプロキシグループでどれが選択されているか、これらの情報で十分です。

一時的に特定のルートに切り替えたいだけなら、完全なクライアントを開く必要はありません。Raycastでルートを選択し、Enterキーを押せば完了です。

次にノードを選択する

私が最も望んでいた機能は、ルートの固定でした。

例えば、私はよくシンガポールノードを経由したいと思っています。しかし、「シンガポールを経由する」というのには、全く異なる2つのシナリオがあります。

1つは、どのノードが安定しているかを知っていて、それを固定したい場合で、クライアントが勝手に切り替わるのを望まない場合です。もう1つは、このグループの中でどれが最も速いかだけを気にしていて、遅延に基づいて自動的に選択してほしい場合です。

したがって、私の本当のニーズは単純な「自動選択」ではなく、すべてのサブスクリプション内のシンガポールノードを1つのグループにまとめ、その日の作業状態に応じて、手動で固定するか、自動で最速を選択するかを決定することでした。

これがカスタムプロキシグループです。

シンガポールノードリストがサブスクリプションソースごとにグループ化され、異なるノードの遅延が表示される
複数のサブスクリプション内のシンガポールノードを同じグループに入れ、必要に応じて手動で固定したり、最速ノードを自動選択したりできます。

カスタムグループは2つのモードのみを保持しています。

戦略意味
Manual Select手動でノードを選択します。安定した固定ルートが必要な場合に適しています。
Always Fastest選択されたノードの中から現在最も速いノードを自動的に選択します。遅延だけを気にする場合に適しています。

これは、すべての戦略を広げるよりも、私の使用習慣に合っています。

時には「今日はこのノードで、動かさないで」と表現したいこともあります。時には「今日はシンガポールを経由して、どのノードにするかはあなたが選んで」と表現したいこともあります。

これら2つの操作は、同じノードページで完了できるべきであり、設定ファイルに戻ってプロキシグループを変更するように強制されるべきではありません。

ルールは調整しやすいように

もう一つの頻繁な問題はルールです。

多くの場合、ノードが壊れているのではなく、ルールがトラフィックを間違った方向にルーティングしていることがあります。例えば、特定の開発ツール、AIサービス、海外のドキュメントサイトがルールセットでカバーされておらず、最終的に直接接続されてしまい、判断が難しい失敗が発生することがあります。

そこで、私は Clash Rules ページを作成しました。

Clash Rulesに組み込みルール、カスタムルール、ルールタイプ、DIRECT/PROXY/REJECTターゲットが表示される
ルールページは、組み込みルール、カスタムルール、ターゲット方向をまとめて表示し、トラフィックがどこへ向かうかを素早く判断できるようにします。

これは完全な設定エディタを置き換えることを目的としているのではなく、最もよく使ういくつかの操作をRaycastに配置するだけです。

  • ルールの順序を確認する。
  • このルールが DIRECTPROXYREJECT のどれを経由するかを確認する。
  • カスタムルールを追加する。
  • カスタムルールの位置を調整する。
  • ルールセットのソースを開く。

mihomoのルールは上から下にマッチするため、ルールの順序自体が結果に影響を与えます。このページが解決しようとしているのは、「ルールを再設計する」ことではなく、現在のトラフィックがなぜこのように流れるのかを素早く理解できるようにすることです。

ルール自体は新しく作成されたものではなく、成熟したクライアントで一般的な設定の考え方を踏襲しています。組み込みルールは基本的なトラフィック分割を担当し、カスタムルールは一時的な補完を担当し、最終的に未知のトラフィックはデフォルトで PROXY を経由します。

なぜRaycastなのか

このプラグインの最も重要な設計上のトレードオフは、ClashではなくRaycastでした。

Raycastコマンドエントリポイントがコア、バックグラウンドサービス、システムプロキシ、ルールモジュールに接続されている手書きのアーキテクチャ図
Raycastはエントリポイントに過ぎず、コア、バックグラウンドサービス、システムプロキシ、ルールはそれぞれ自身の部分を担当します。

もし完全なクライアントとして作っていたら、メニューバー、設定ページ、トラフィックグラフ、設定編集、TUN、同期、ログパネルなどを避けられずに作り始めていたでしょう。それらはすべて作ることができますが、私の最も痛いところではありませんでした。

私の問題点は、操作パスが長すぎることでした。

私が求めていたのは:

  • clash を検索するだけでエントリポイントが見えること。
  • インストール後、コア、設定、システムプロキシをまず確認できること。
  • Dashboardを開けば現在のネットワーク状態がわかること。
  • ルートの切り替えがコマンドの切り替えのようにできること。
  • シンガポールノードを手動で固定したり、最速を自動選択したりできること。
  • ルールの問題が発生した場合、素早く1つ追加できること。
  • 故障が発生した場合、まずヘルスチェックを確認できること。

これがRaycastがそれに適している理由です。

これは「より完全な」Clashクライアントではなく、「私の作業エントリポイントにより近い」Clashコントロールパネルなのです。

完成後の感想

このプロジェクトを通じて、私はあることを再確認しました。AI時代において、多くの個人ツールは作り直す価値があるということです。

以前なら、このようなニーズはほとんどの場合、諦められていたでしょう。クライアントがたまにクラッシュしても我慢する。ノードが選びにくいなら手動で切り替える。ルールが調整しにくいなら設定ファイルを変更する。システムプロキシがずれたらクライアントを再起動する。

なぜなら、自分専用のツールを作るコストが高すぎたからです。

今は違います。

既存の機能を再構成できます。mihomoがプロキシコアを担当し、Raycastがエントリポイントを担当し、launchdがバックグラウンドサービスを担当し、macOSシステムプロキシがシステム統合を担当し、プラグインがそれらを使いやすいワークフローに変えます。

Clash for Raycast は私にとって、まさにそのようなツールです。

これはより大きなClashではありません。

これは私自身のネットワークスイッチです。

プロジェクトアドレス

ソースコードはGitHubに公開されています:wuyuxiangX/clash-for-raycast

コメント

Raycast版Clashを作ってみました | Yuのサイバーデスク