2026年のClashエコシステム:いまメンテされているコアとクライアントは?
Clash for Windows や ClashX がアーカイブ・更新停止に入ったあとも、コミュニティの開発は止まっていません。本稿では 2026 年時点の「Clash 周辺」を地図に落とし込みます。どのコアと GUI が引き続きリリースされているか、どの名前はレガシー扱いにすべきか、そして最新の購読フォーマットと両立しやすい組み合わせの選び方です。
いわゆる「定番」だった Clash の構成はどう変わったか
2023 年後半、上流まわりの景色は一気に変わりました。公開されていたオリジナルの Clash コアのリポジトリが手元から消え、Clash for Windows(CFW) はアーカイブ、ClashX も実質的な機能更新が止まりました。多くの方にとって、デスクトップや macOS で「Clash」と言えばこの三つだったはずです。突然の静まり返りに、代替クライアントと「これから先も追従できるコア」を探す動きが一気に広がりました。
ただし開発そのものが終わったわけではありません。コミュニティ主導のフォークや新しいアプリへ重心が移った、と捉えるのが近いです。2026 年現在、本気で使うデスクトップ向けクライアントの多くは Clash Meta 互換のエンジン(上流プロジェクト名では Mihomo)を同梱するか、初回起動時に取り込む運用が一般的です。Android と iOS では、オープンソース性・ストア配信・自動化のしやすさなど、優先したい条件ごとに「現役」の選択肢が分かれます。
しばらくブランクがあった方は、エコシステムをコア(YAML を解釈し、ルールを当て、ノードに接続するエンジン)とクライアント(GUI や OS 連携でコアを包む側)の二層で考えると整理しやすいです。Meta 系コアの上に乗っていれば、これまでの Clash プロファイルの感覚はかなり引き継げます。プラットフォーム別の細部を詰める前に、全体の流れはClash のチュートリアルで押さえておくと、あとから設定をいじるときも迷いにくくなります。
押さえておきたい、メンテが続いているコア
Mihomo(Clash Meta)— 新規構成ならまずここ
上流リポジトリは MetaCubeX/mihomo で、古い資料では Clash Meta と書かれていることが多いです。Clash ファミリーでは最も活発に開発が続いているフォークのひとつで、旧 Premium 時代の能力を土台に、VLESS・Reality・Hysteria2 など現代的なトランスポートまで幅広くカバーします。ルール表現も豊かで、デスクトップ OS では TUN による透過的なトラフィック捕捉の道筋も成熟しています。
2026 年にそれが重要なのは、購読プロバイダやパネル側が「Meta 前提」の挙動を前提にし始めているからです。メンテが止まった枝に留まっていると、パーサエラー、ダイアラのオプション不足、プロファイルの微妙な非互換などが出やすくなります。活発に保守されている GUI は、だいたい Mihomo を同梱するか初回に取得します。ユーザーが意識すべき「Clash の版」とは、窓の見た目よりコアのビルドだと考えた方が実務的です。
リリースノートを見るときは、セキュリティ修正やプロトコル追加が継続的に出ているかもチェックしましょう。TLS スタックや QUIC、OS のネットワーク API は常に動いていて、プロキシコアが更新されなければ、見た目は新しくてもチェーンの弱点になり得ます。
旧 Clash Premium(クローズドソース)
歴史的な Clash Premium バイナリはアーカイブのあいだを漂っていることもありますが、これから新規に載せる用途としては前向きにはおすすめしません。古いマシンで TUN をちょい試す程度なら動くかもしれませんが、Mihomo とプロトコル対応や長期メンテの面で並べるのは無理があります。毎日使うノート PC なら、Meta 系スタックへの移行を前提にした方が安全です。
デスクトップ/クロスプラットフォームで更新が続くクライアント
Clash Verge Rev — Windows・macOS・Linux
リポジトリは clash-verge-rev/clash-verge-rev。Tauri 製の Clash Verge Rev は、モダンな UI、プロファイル管理のしやすさ、CFW 時代の作業フローからの移行パスがわかりやすいことで知られています。Windows ユーザーにとっては CFW の第一候補の代替として広く使われており、古い ClashX ビルドから乗り換える macOS ユーザーにも選ばれやすいです。オープンソースでリリース頻度も高い、という点も安心材料になります。
体験面では、購読の管理、ルール編集の補助、ターミナルを開かなくても追えるログなど、「迷子になりにくい」方向に振られています。上級者向けの TUN の切り替えや mixin 的な上書き、コアの切り替えも残っていて、初日から生 YAML 一択にされるわけではありません。移行途中であれば、Clash for Windows から Clash Verge Rev への移行手順とあわせて読むと、カスタムルールやスクリプトまわりを落とし込みやすくなります。
FlClash — Flutter ベースのマルチプラットフォーム
リポジトリは chen08209/FlClash。Windows・macOS・Linux・Android でFlutter の UI 感を揃えたい方向けの強い選択肢です。見た目を軽めにしたい場合や、Android とデスクトップを同じ思想のプロジェクトで揃えたい場合に向きます。2026 年時点でも健全なクライアント同様、Mihomo クラスのコアと整合するので、プロファイルの持ち運びはしやすいです。
モバイル:Android と iOS
Clash for Android(CFA)
リポジトリは Kr328/ClashForAndroid。Android ではいまも参照実装に近い位置づけで、コミュニティの記事も多く、ローカルプロファイル中心でも購読駆動でも使いやすいです。端末の OS バージョンやメーカー ROM によっては、省電力設定や VPN 権限まわりの差は残りますが、プロジェクト自体は Meta 世代の設定と両立しやすい第一候補のひとつです。
Stash — iOS・iPadOS・Apple Silicon Mac
Apple のモバイルでは、Android とは条件が違います。App Store 経由か、TestFlight 的なベータか、サンドボックスの制約か、といったトレードオフがつきまといます。Stash はネイティブに近い仕上がりで Clash 系の設定言語に寄せたクライアントで、有料ながらストア更新が続く体験を求める層に共通して推されます。Clash ネイティブな書き方を優先し、サイドロードの手間を減らしたい場合の現実解のひとつです。
別の路線として、Shadowrocket のような汎用クライアントに手作りルールを載せる運用もあります。Clash 構文そのものを優先するか、遅延実験を最優先するか、地域のストアポリシーに合わせるかで最適解は変わります。いずれにせよ、いまもアップデートが出るものを選ぶことが重要で、TLS や DNS の変化に追従できない放置ビルドは避けた方がよいでしょう。
アーカイブ・実質メンテ終了のプロジェクト(注意して使う)
- オリジナルの Clash コア(上流から削除。セキュリティ上重要な用途で謎ミラーを当てにしない)
- Clash for Windows(CFW)— アーカイブ済み
- ClashX/ClashX Pro — 新世代の要件では実質メンテなし
古いインストーラが起動したとしても、セキュリティのバックポートや新プロトコル、OS ベンダーがネットワーク API を変えたときの修正は期待できません。日常のブラウジングや仕事口座にまでつながる用途では、移行計画を立てる方が合理的で、obsolete なバイナリをまた一年延命するよりマシです。
プラットフォーム別の移行の目安(2026年の現実的なデフォルト)
絶対ルールではありませんが、「迷ったときの置き場所」として使える早見です。
- Windows(CFW ユーザー) → Clash Verge Rev または FlClash
- macOS(古い ClashX ユーザー) → Clash Verge Rev(OSS 路線)または Stash(Apple エコシステム寄り)
- Android → Clash for Android または FlClash
- iOS/iPadOS → Stash、あるいはコンプライアンス要件に合うストア系の現役クライアント
移行前に、購読 URL のエクスポート、カスタムルール断片、スクリプトや mixin 層のメモを残しておきましょう。資産自体は移植しやすく、もろいのは「古いコアが、プロバイダが明日配る YAML をそのまま解釈できる」という期待です。
プロファイル、ルールプロバイダ、将来に備えるには
多くの人は YAML の一行から全部を書くのではなく、リモートプロファイルを取り込んだり、購読 URL からプロキシ・ルールプロバイダ・外部ルールセットまで展開したりします。2026 年は、その束ね方が Meta 系パーサ前提になりつつあり、ネストしたグループ、新しめの proxy-groups 型、DNS の厚みなどが増えています。クライアントがエラーを静かに飲み込むと、本当はスキーマ不一致なのに「回線が悪い」と誤解しがちです。
自分で変えた部分は版管理の習慣をつけるとよいです。仕事用ドメイン直送、ストリーミング地域を select グループに固定、広告リストをベースに足す、といった上書きは、手元にプライベートなコピーを残しておきましょう。上流を更新するときは、丸ごと上書きせず、差分を見ながらマージする。プロバイダがラベル名や地域タグを変えたときに、壊れた「Proxy」チェーンで詰まらずに済みます。
DNS は隠れた結合部です。TUN、fake-ip、ハイブリッドは OS のリゾルバやブラウザの DNS over HTTPS と相互作用します。メンテされたコアと新しい GUI は、ループバックや IPv6 優先まわりの変更にも追従しやすいです。2024 年には通っていたのに今は不安定、というときは、ping だけでなくクライアントとコアの版から疑うと早いです。
健全なクライアントを選んだあと、グループとルールの噛み合わせを深掘りしたい方は、Clash の proxy-groups 解説で select・url-test・fallback やネストの型を追うと、Mihomo 系アプリ全体に応用できます。
「生きているプロジェクト」かどうかの見分け方
GitHub のスター数だけでは足りません。コミット頻度、Issue が整理されているか、リリースが依存関係(TLS ライブラリ、Go のランタイム、QUIC まわり)のアップデートを追っているかを見てください。健全なプロジェクトは、年一回の派手な機能だけでなく、小さな修正を継続的に出します。また、自分の OS 版でプラットフォーム特有の退行が報告されていないかも Issue で確認すると安心です。
透明性も大切です。changelog が読めること、可能ならバイナリに署名があること、破壊的変更の説明があること。バージョン間で何が変わったか分からないまま、出張前日に本番マシンだけ更新、はリスクが高いです。
クライアントの入手先(このサイトの考え方)
オープンソースのリポジトリは、コードを読む・Issue を出す・ライセンスを確認する場所として優秀ですが、エンドユーザー向けのインストーラは、検証できる配布経路から取るのが安全です。当サイトでは言語別にメンテの続くビルドへ誘導するClash のダウンロードページを用意しており、チュートリアルやブログでも「まず公式サイト」の方針に揃えています。ソース監査やパッチ送付が目的なら、日々のインストールフローとは別に上流ページを開く、という切り分けがおすすめです。
凍結したレガシーフォークに比べ、メンテの続く Clash スタックは、アップグレードの予測可能性、障害時のログの読みやすさ、プロバイダの新機能をプロファイル貼り付けで通しやすい確率、の面で有利です。最新ビルドを試す準備ができたら、→ Clash を無料ダウンロードして、実際の接続体験を確かめる。