Clash Meta（Mihomo）アップグレード完全ガイド

Clash Meta と Mihomo の関係（プロジェクト改称について）

Clash Meta は、MetaCubeX がメンテナンスする Clash 互換の高性能コアです。オリジナル Clash の開発が停滞したあとも、活発なコミュニティと継続的なアップデートにより、事実上の標準的な選択肢のひとつとして広く使われています。2024 年以降、GitHub 上のリポジトリ名は Mihomo に変更されましたが、設定フォーマットはこれまでと下位互換であり、既存ユーザーが設定を書き直す必要は基本的にありません。

改称は単なるブランド変更にとどまりません。「Clash の互換実装」から一歩進み、独立した成熟したプロキシスタックとしてプロトコル対応・ルールエンジン・DNS サブシステム・メモリ管理などを総合的に見直した結果です。新しい Mihomo は、従来の Clash の枠にとらわれず、現代的なプロトコルを積極的に取り込みつつ、安定性とパフォーマンスを大きく伸ばしています。

古い Clash 系コアや、しばらく更新していない Clash Meta ビルドをお使いなら、今が最新 Mihomo へ揃える好機です。以下では Windows・macOS・Android を例に、安全にバージョンを上げる手順と、注目の三つのプロトコルについて整理します。関連する解説は技術ブログの一覧からも辿れます。

アップグレード前に押さえておきたいこと

作業を始める前に、数分だけ確認しておくとトラブルが減ります。

1. 設定ファイルのバックアップ

現在使用中の config.yaml と、読み込んでいるルールファイル一式を、デスクトップやクラウドなど別場所にコピーしておきましょう。複数プロファイルを運用している場合は、バージョン番号や日付を付けて整理しておくと、問題発生時のロールバックが素早くなります。

2. GUI クライアントとコアの対応

グラフィカルなフロントエンド（GUI）は、内蔵する Mihomo の世代によって挙動が変わります。アップデート前に、お使いのクライアントが最新の Mihomo に追従しているか確認してください。当サイトのクライアント公式ダウンロードページでは、GUI とコアの組み合わせが検証されたパッケージをまとめています。まとめて更新すると、起動時の不整合を避けやすくなります。

3. サブスクリプション（購読 URL）の互換性

多くのプロバイダが提供する購読形式は、Mihomo でもそのまま利用できます。ごく一部、古い Shadowsocks のみなど特殊な形式だとパースエラーになることがあります。更新後にノードが読み込めない場合は、後半の FAQ を参照してください。

ヒント：Mihomo は、正規の Clash 設定フィールドについて下位互換です。既存の YAML をそのまま新バージョンに載せ替えても、基本的にそのまま動作します。

プラットフォーム別：アップグレードの手順

Windows

クライアントを開き、「バージョン情報」または「コア設定」などで、現在の Mihomo コアの版をメモします。
当サイトのダウンロードページから、最新の Windows 用インストーラ（最新コア同梱）を取得します。
実行中の Clash 系クライアントを終了します（タスクトレイのアイコンから終了）。
インストーラを実行し、ウィザードに従います。多くの場合、コアの置き換えは自動で行われます。
再起動後、バージョン画面でコアが最新になっているか確認します。
「遅延テスト」や接続確認で、プロキシが期待どおり動くか確かめます。

macOS

ClashX Pro や Mihomo Party など GUI を使う場合は、当サイトから最新の .dmg を入手し、Applications フォルダへドラッグして上書きします。

Homebrew でコアだけ管理している場合は、ターミナルで次のように実行できます。

# Stop the existing service
brew services stop mihomo
# Update package to latest version
brew upgrade mihomo
# Restart the service
brew services start mihomo

「開発元を確認できないため開けない」と出たら、「システム設定 → プライバシーとセキュリティ」から「それでも開く」を選びます。
設定ファイルは通常、そのまま引き続き利用できます。

Android

Android では、当サイトのダウンロードページから最新 APK を取得し、上書きインストールするのが簡単です。多くのクライアントではプロファイルと購読情報が保持されるため、再インポートは不要なことが多いです。インストール後、「について」などでコア版を確認してください。

注意：Android 14 以降では、ストア外 APK を上書きする前に「提供元不明アプリ」の許可が必要です。オフのままだとインストールがブロックされます。

Hysteria2：高スループット・悪路線向けのプロトコル

Hysteria2 は、Mihomo で人気の高い新プロトコルのひとつです。QUIC をベースに、パケット損失や往復遅延が大きい回線でも速度を維持しやすいよう調整されています。環境によっては、従来の TCP ベースのプロキシと比べてスループットが数倍になる例も報告されており、国際回線の品質が不安定なケースに向きます。

Hysteria2 の主な利点

損失に強い：UDP／QUIC ベースのため、ある程度のパケットロスがあっても速度の落ち込みが抑えられやすいです。
接続が速い：QUIC の 0-RTT などにより、従来の TLS over TCP と比べてハンドシェイクが短くなることがあります。
トラフィックの見た目：HTTPS に近い特徴を持ち、DPI（ディープパケットインスペクション）による単純な特徴検出を避けやすい設計です。
ネイティブ対応：追加のプラグインや外部バイナリなしで、YAML にノードを定義するだけで利用できます。

設定例（proxies）

config.yaml の proxies に、次のようなエントリを追加します。

proxies:
  - name: "HY2-Node"
    type: hysteria2
    server: your-server.example.com
    port: 443
    password: "your-password"
    sni: your-server.example.com
    skip-cert-verify: false
    up: "100 Mbps"
    down: "200 Mbps"

up と down はクライアント側の帯域目安です。実測に近い値を入れると、輻輳制御が働きやすくなります。

TUIC v5：短い接続が多い用途向け

TUIC（Transparent UDP in TCP Carrier）v5 も QUIC 系のモダンプロトコルで、握手遅延の小ささと接続の再利用に強いのが特徴です。Hysteria2 が帯域伸長に寄りがちなのに対し、TUIC v5 は Web 閲覧やチャット、多数の短いリクエストが続くワークロードと相性がよいことが多いです。

Mihomo では追加コンポーネントなしで利用でき、設定は次のような形です。

proxies:
  - name: "TUIC-Node"
    type: tuic
    server: your-server.example.com
    port: 443
    uuid: "your-uuid-here"
    password: "your-password"
    version: 5
    alpn:
      - h3
    congestion-controller: bbr
    udp-relay-mode: native

congestion-controller: bbr は BBR 系の輻輳制御を指定します。udp-relay-mode: native は低遅延の UDP 転送に向き、オンラインゲームやビデオ会議などでも検討の価値があります。

VLESS + Reality：TLS フィンガープリントを活用した構成

VLESS に Reality を組み合わせた方式は、実在するウェブサイトの TLS フィンガープリントを参照することで、プロキシトラフィックを「普通の HTTPS 閲覧」に近い外観へ寄せるアプローチとして知られています。厳しいネットワーク環境でトラフィック特徴に基づく識別を避けたい場合の選択肢のひとつです。

従来の難読化だけに頼らず、サーバー側が独自ドメインの証明書を必須としない点も、運用上の自由度が高い理由です。外部サイト（例：マイクロソフトや Cloudflare など）の公開 TLS 情報と、X25519 鍵ペアを組み合わせて認証します。

設定例（VLESS + Reality）

proxies:
  - name: "VLESS-Reality"
    type: vless
    server: your-server.example.com
    port: 443
    uuid: "your-uuid-here"
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: www.microsoft.com
    reality-opts:
      public-key: "your-public-key"
      short-id: "your-short-id"

flow: xtls-rprx-vision は XTLS Vision を有効にするための指定です。servername には参照したい正当なサイトのホスト名を入れ、public-key と short-id はサーバー管理者から渡された値を使います。

まとめ：三つのプロトコルは用途が異なります。悪路線でスループットを稼ぎたいなら Hysteria2、短い接続が密集するなら TUIC v5、TLS 側の見え方を最重視するなら VLESS+Reality、という整理がわかりやすいでしょう。

ルールエンジンと DNS の改善

プロトコル以外でも、ルールマッチングと DNS のまわりは体感で差が出やすい領域です。

ルールエンジンの高速化

新しい実装では、大規模なルールセット（GitHub 上のコミュニティルールなど数万行規模）でも、ハッシュベースの照合などにより旧版より応答が速く、メモリ使用量も抑えられやすくなっています。複雑なポリシーを組んでも、マシンへの負荷は比較的穏やかに保てる設計です。

DNS の細かい振り分け

ドメインサフィックス、geosite カテゴリ、カスタム条件ごとに上流 DNS を切り替えられるため、国内向けと海外向けを分けたり、特定カテゴリだけ信頼できるリゾルバへ流したりしやすくなりました。以下は一例です（nameserver は自国・自環境に合わせて差し替えてください）。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com
  nameserver:
    - https://223.5.5.5/dns-query
    - https://119.29.29.29/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    geosite:
      - gfw

この例では、主に国内向けの DoH を nameserver に置き、フォールバックで海外の DoH を使う構成です。日本やその他の地域で使う場合は、利用したいプロバイダの DoH／DoT に読み替えてください。fallback-filter により、不要なフォールバックを減らし遅延を抑える意図があります。

GeoIP / GeoSite データの更新

geoip.dat と geosite.dat は、地域やカテゴリ判定の基礎です。クライアントやコアの更新とあわせてデータも新しく保つと、意図しないプロキシ迂回や到達不可を防ぎやすくなります。

移行時のよくある質問

旧 Clash や古い Clash Meta から乗り換える際に多い疑問をまとめます。

Q：アップデート後に「unknown config field」と出て起動しない

GUI 専用の拡張フィールド（例：clash-for-windows ブロック）が残っていると、厳密なパーサで弾かれることがあります。非標準のブロックを削除またはコメントアウトし、再読み込みしてください。

Q：これまでの購読 URL はそのまま使える？

ほとんどの場合、再発行は不要です。古い Shadowsocks のみ・廃止済みの VMess パラメータなどが混ざっていると、一部ノードだけ解釈に失敗することがあります。大量に失敗する場合は、プロバイダに形式の更新を依頼するのが確実です。

Q：Mihomo とオリジナル Clash の設定の違いは？

プロキシ、プロキシグループ、ルール、DNS、TUN など中核は互換です。そのうえで hysteria2、tuic、vless などのノード型や reality-opts、実験的な ssh などが追加されています。従来の YAML は基本的にそのまま読み込めます。

Q：TUN モードがアップデート後に動かない

Windows では管理者権限、Linux／macOS では適切な権限が必要です。また tun セクションが正しいか確認してください。

tun:
  enable: true
  stack: system      # or "gvisor" as alternative
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - "any:53"

gvisor で不具合が出る場合は system に切り替えて試してください。

Q：コアのバージョンはどう確認する？

GUI の「バージョン情報」から確認できるほか、CLI なら mihomo -v や mihomo version です。セキュリティ修正や互換性のため、可能な範囲で最新の安定版に追従することをおすすめします。

ここまで読めば、Mihomo 世代で何が変わったかの全体像は掴めたはずです。理屈の上では、GitHub からコアだけ入手して自分で差し替えることも可能です。ただ現場では、GUI とコアの組み合わせ、新プロトコルのパラメータ、TUN や DNS の細部まで、ひとつずつ潰していくのに時間がかかる、という声も少なくありません。

当サイトで配布している Clash クライアントは、その手間を減らすためにパッケージ化したものです。例えば次のようなメリットがあります。

検証済みの組み合わせ：新コア公開後も、主要 OS で GUI とコアの整合を確認したビルドを用意しています。
購読の取り込みが簡単：URL を貼って更新するだけで、YAML を一から書かずに運用を始められます。
新プロトコル対応：Hysteria2、TUIC v5、VLESS+Reality を、ノード側が対応していればクライアント側でもそのまま扱えます。
DNS まわりの配慮：漏えいしやすい典型的なパターンを抑えるプリセットを意識した構成です。
マルチプラットフォーム：Windows、macOS、Android、iOS、Linux 向けに最適化され、同じ購読を複数端末で使い回しやすいです。

古いクライアントのまま接続が不安定だったり、新プロトコルが使えなかったりする場合は、環境に合わせてパッケージを選び、実際の体感を比べてみる価値があります。オープンソースの所在やライセンスを確認したい場合は、公式リポジトリで情報を得つつ、実行ファイルの入手とインストールの主導線は当サイトのダウンロードページにそろえるとスムーズです。→ Clash を無料ダウンロードして、最新 Mihomo 世代の体験を試す

Clash Meta と Mihomo の関係（プロジェクト改称について）

アップグレード前に押さえておきたいこと

1. 設定ファイルのバックアップ

2. GUI クライアントとコアの対応

3. サブスクリプション（購読 URL）の互換性

プラットフォーム別：アップグレードの手順

Windows

macOS

Android

Hysteria2：高スループット・悪路線向けのプロトコル

Hysteria2 の主な利点

設定例（proxies）

TUIC v5：短い接続が多い用途向け

VLESS + Reality：TLS フィンガープリントを活用した構成

設定例（VLESS + Reality）

ルールエンジンと DNS の改善

ルールエンジンの高速化

DNS の細かい振り分け

GeoIP / GeoSite データの更新

移行時のよくある質問

Q：アップデート後に「unknown config field」と出て起動しない

Q：これまでの購読 URL はそのまま使える？

Q：Mihomo とオリジナル Clash の設定の違いは？

Q：TUN モードがアップデート後に動かない

Q：コアのバージョンはどう確認する？

まとめ：なぜ当サイトの Clash クライアントが楽か