Windows
デスクワーク、ブラウザのプロキシ利用、TUN制御が必要なプログラムに適しています。ダウンロードページではGUIクライアントをまとめ、現在も保守されているプロジェクトとアーカイブ済みのプロジェクトを分けて掲載しています。インストール後はサブスクリプションをインポートしてから、必要に応じてシステムプロキシを有効にしてください。システムプロキシを使わないアプリだけ、追加でTUN設定が必要です。
ダウンロードへコア世代交代の比較
システムトラフィックの制御からDNS解決経路まで、現在の設定は単純な転送だけではありません。左側の機能を選ぶと、解決できる課題、設定場所、利用時の注意点を確認できます。
TUNモードは、システムプロキシ設定を参照しないアプリの通信を制御します。ゲームランチャー、コマンドラインツール、独立したネットワークプログラムなどが対象です。有効にすると、コアが仮想ネットワークインターフェースですべての通信を受け取り、ルールに従って直接接続、プロキシ、拒否を判定します。システムプロキシだけを使うより適用範囲は広い一方、管理者権限、ルーティング設定、DNSとの連携が重要になります。初回はまずmixedスタックを使い、ローカルネットワークが直接接続できることを確認してください。LAN機器に接続できない場合は、ノードを何度も替えるのではなく、ルーティングの除外設定を確認します。
tun:
enable: true
stack: mixed
auto-route: true
strict-route: false
ルールモードでは、ドメイン、IP、プロセス、ネットワーク種別を設定ファイルで順に判定し、プロキシグループが実際に使うノードを決めます。「すべての通信を同じ経路に通す」ことで起きる迂回を解消し、ローカルサービスは直接接続、指定サイトはプロキシグループ、未一致の通信は末尾のルールで処理できます。設定では、より具体的なルールを前に、フォールバックルールを最後に置いてください。プロキシグループ名はルールのターゲットと完全に一致させる必要があります。グローバルプロキシよりも長時間の運用に向き、各リクエストがどのルールに一致したかも確認しやすくなります。
proxy-groups:
- name: 手動選択
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,手動選択
- MATCH,DIRECT
DNS処理を統一すると、システムの解決結果とプロキシルールの判定が食い違うケースを減らせます。クライアントがDNS問い合わせを引き受ければ、ドメインの種類に応じて解決サーバーを選び、Fake-IPのマッピングと接続記録を対応させられます。重要なのは単純な応答速度ではなく、「ドメインルールの判定」と「実際の接続先」を同じ経路に置くことです。設定では、LANドメイン、時刻同期サービス、一部ゲームドメインの除外ルールを残してください。コアのDNSを無効にする場合は、システム、ブラウザ、セキュリティソフトが別途暗号化DNSを有効にしていないかも確認し、複数の解決経路が互いに上書きしないようにします。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
respect-rules: true
mihomoは複数のプロキシプロトコルを一つの設定体系で扱うため、クライアントはサブスクリプションをコアに渡すだけで利用でき、プロトコルごとに接続プログラムを個別インストールする必要がありません。ただし、互換性があるからといってすべてのパラメータを混用できるわけではありません。トランスポート層、TLS、サーバー名、ユーザー識別子、ポートは提供元の情報と一致させる必要があります。インポートに失敗した場合は、まずサブスクリプションが完全か確認し、次にクライアントがmihomoコアを正しく呼び出しているか確認してください。旧コア依存のクライアントより新しいエコシステムのほうが、進化するプロトコル項目に対応しやすい一方、誤った項目は起動ログに明確に現れます。ログを見ながら一つずつ修正しましょう。
サブスクリプションの更新では通常、リモート設定が置き換えられます。個人ルールをサブスクリプション本文に直接書くと、次回の更新で失われる可能性があります。上書きとマージの仕組みを使えば、ローカルポート、DNS、ルール、プロキシグループの変更を独立した層に置き、サブスクリプションと組み合わせて実行用設定を生成できます。固定したいLAN設定、直接接続ルールの追加、プロキシグループ名の変更などに適しています。「追加」と「上書き」は区別してください。追加ルールは順序の影響を受け、同名フィールドの上書きでは元の値が置き換わります。変更後は上書き部分だけでなく、最終的に生成されたYAMLを確認しましょう。
mode: rule
mixed-port: 7890
allow-lan: false
log-level: info
クライアントのダウンロード
GUIクライアントはサブスクリプションのインポート、プロキシ切り替え、システムプロキシ制御を担当し、mihomoコアは実際の接続とルール判定を担います。まず端末のOSに合ったダウンロードページへ進み、インストール方法と利用スタイルに合わせてクライアントを選んでください。
デスクワーク、ブラウザのプロキシ利用、TUN制御が必要なプログラムに適しています。ダウンロードページではGUIクライアントをまとめ、現在も保守されているプロジェクトとアーカイブ済みのプロジェクトを分けて掲載しています。インストール後はサブスクリプションをインポートしてから、必要に応じてシステムプロキシを有効にしてください。システムプロキシを使わないアプリだけ、追加でTUN設定が必要です。
ダウンロードへApple SiliconとIntel Macに対応します。インストーラーを選ぶ前にプロセッサのアーキテクチャを確認し、初回起動時はシステムネットワーク拡張またはプロキシ権限の許可が必要です。メニューバー型クライアントは日常的なプロキシグループの切り替えに便利で、デスクトップ型は接続履歴、ルールの一致状況、サブスクリプション内容の確認に向いています。
ダウンロードへAndroidクライアントは通常、システムVPNインターフェースを通じてアプリの通信を制御するため、アプリごとにプロキシを設定する必要はありません。設定をインポートした後、アプリ単位でプロキシ経由にするか選択できます。バックグラウンドで切断される場合は、ノードだけを調整せず、省電力設定、VPN権限、バックグラウンド実行制限を確認してください。
ダウンロードへiPhoneとiPadでは、システムネットワーク拡張を使ってプロキシ接続を確立します。インストール後にVPN構成の追加を許可し、クライアントでサブスクリプションをインポートしてください。モバイル通信とWi-Fiを切り替えると、システムが接続を再確立することがあります。ルールが期待どおりに動作しない場合は、まず設定を再読み込みし、現在のプロキシグループを確認します。
ダウンロードへデスクトップではGUIクライアントを選べますが、サーバー、ソフトルーター、コンテナ環境ではmihomoコアを直接実行することも多くあります。コアを直接動かす場合は、設定ファイルの場所、実行権限、ログ、起動時の自動実行を自分で管理し、透過プロキシに必要なルーティングとファイアウォールのルールも明確にする必要があります。
ダウンロードへクイックスタート概要
初回からすべての設定を変更する必要はありません。まずクライアントをインストールしてサブスクリプションをインポートし、基本接続を確認してから、プロキシグループ、DNS、TUNを順に調整します。
ダウンロードページで現在のOSを選び、プロセッサのアーキテクチャと利用目的に合わせてクライアントを選択します。WindowsとmacOSでは通常GUIクライアントから始め、AndroidとiOSではシステムVPN権限を許可します。Linuxサーバーではコアを直接利用できます。インストール後はまずクライアントを開き、画面が正常に読み込まれることを確認してください。設定をインポートする前にシステムプロキシを何度も切り替えるのは避けましょう。
設定またはサブスクリプションのページに、サービス提供元から発行されたサブスクリプションURLを貼り付け、更新後にインポートした設定を選択します。続いてプロキシまたはグループのページを開き、選択グループに利用可能なノードが表示されていることを確認してください。サブスクリプションURLは通常のウェブページのリンクではないため、ブラウザで内容の完全性を判断することはできません。解析に失敗した場合は、コピー時に空白が混入していないか、URLの有効期限が切れていないか、設定がYAML構造に適合しているかを確認します。
まずルールモードを選択し、その後にシステムプロキシまたはモバイル端末のVPNを有効にします。接続ログを開いてリクエストが想定したプロキシグループに入っているか確認し、ローカルサービスにもアクセスして直接接続ルールが機能していることを確かめます。通常のブラウザは接続できるのに独立したアプリだけ通信できない場合はTUNを検討してください。ドメイン解決に問題がある場合はDNS設定に戻り、拡張モードとフィルターリストを確認します。この順序で調べると、ノード、ルール、システムによる制御、名前解決の問題を分けて特定できます。
オープンソースエコシステムとコアの移行
クライアントの画面とプロキシコアは、独立した2つのコンポーネントです。この関係を理解すれば、更新がどこから来たのかを判断でき、問題発生時にも適切なログと設定の入口を見つけられます。
Clashは当初、YAML設定、ルールリスト、プロキシグループを中心とした利用方法を築き、多くのデスクトップ・モバイルクライアントがこの構造を基に開発されました。旧コアの開発が停止した後も、既存のサブスクリプション形式、ルールの使い方、クライアントの操作体系が同時に消えたわけではありません。mihomoは一般的なClash設定との互換性を保ちながらコア機能の開発を続けています。そのため現在見られる多くの「Clash Metaクライアント」は、実質的にはGUIからmihomoを呼び出し、接続、DNS、ルール判定、トラフィック制御を行うものです。
この移行により、通常は設定をゼロから書き直す必要はありません。ただし、古いフィールドをすべてそのまま残してよいわけでもありません。長期間更新されていないテンプレートには、意味を失った項目や旧クライアント固有のフィールドが含まれている場合があります。移行時は元の設定をまずインポートし、起動ログを確認してから、DNS、TUN、プロキシグループを一つずつ整理するのが安全です。大量の上書き設定を一度にコピーする方法は避けましょう。
mihomoコアはネットワーク接続とルール実行を担当し、Clash Plus、Clash Verge Rev、FlClashなどのクライアントはGUI操作、システム連携、設定管理を担当します。ルールセットのプロジェクトは、再利用可能なドメインまたはIP分類を提供します。各コンポーネントはそれぞれのペースで更新でき、ユーザーはプラットフォームに合わせてUIを変更しながら、近い設定方針を維持できます。画面のクラッシュ、トレイ機能の停止、システムプロキシの切り替え失敗は、まずクライアントを確認してください。設定の解析、プロトコル接続、ルール一致の問題では、コアのログを確認します。
この層構造により、特定のクライアントへの依存も減らせます。デスクトップの設定をmihomo対応の別クライアントへ移行したり、サーバー設定をパスと権限を確認したうえでコアに直接実行させたりできます。ただし、上書きスクリプト、設定の保存場所、システムサービスの実装はクライアントごとに異なります。移行前にローカルルールをエクスポートし、現在使っているDNSとプロキシ設定を記録しておきましょう。
Clash設定では主に、ポート、プロキシノード、プロキシグループ、DNS、ルールを宣言します。クライアントは設定を読み込んだ後、サブスクリプションとローカル上書きを先にマージし、最終結果をmihomoに渡すことがあります。接続先を実際に決めるのは、マージ後の実行設定であり、サブスクリプション本文や単独の上書き部分ではありません。問題を調べる際は、クライアントが生成した最終設定を見つけ、ログと照合して判断するほうが、サブスクリプション編集画面だけを見るより確実です。
ルールは順番に照合され、前方にある具体的な条件が後方の広範な条件より優先されます。プロキシグループは、一致後にどのノードを選ぶかを決めます。DNS解決はドメインルールとIPルールが見る対象に影響し、TUNはどのアプリの通信がコアに入るかを左右します。この4つは相互に関係するため、「ノードを替えても改善しない」からといって、直ちにノードの問題とは限りません。リクエストがそもそもコアに入っていない、または前方のルールによって別のプロキシグループへ送られている可能性もあります。
クライアントの更新とコアの更新では、解決する問題が異なります。クライアント更新ではインストール方法、画面構成、システムサービス、サブスクリプション管理が変わることがあり、コア更新ではプロトコル実装、DNSの動作、ルール構文、ネットワークスタックが変わる可能性があります。更新後も基本接続が正常なら、通常はすぐに設定を書き直す必要はありません。フィールドの廃止、解析エラー、既存のネットワーク動作の明確な変化がログに現れた場合に限り、対応するドキュメントを確認して該当箇所を調整してください。
長期運用では、シンプルな基礎設定を1つ残しておくと便利です。動作モード、ポート、DNS、プロキシグループ、末尾ルールを明確にし、必要な機能はルールセットや上書きで拡張します。設定が複雑になるほど、更新時にどの層で衝突したのか判断しにくくなります。まず基本経路が動く状態を確保し、その後にカスタムルールを一つずつ追加する方法が、旧コアから新コアへ移行する際の負担を抑えます。
設定とトラブル対処の記事
DNSの仕組み、証明書エラー、ルーターへの導入まで、具体的な問題ごとに設定経路を解説します。クライアントは接続できるのに動作が期待どおりでない場合も、原因を段階的に切り分けられます。
DNSクエリがコアに入るところから、仮想アドレスプールによるドメインのマッピング、接続時の宛先復元までを整理します。ブラウザ、ゲーム、LANサービスに適したフィルタリング方針も解説し、Redir-Hostの解決経路とあわせて、異常がアドレスマッピングにあるのか上流DNSにあるのか判断できるようにします。
記事を読む →証明書エラーは、システム時刻、ブラウザキャッシュ、ノード経路、ローカルのセキュリティソフト、復号設定などが原因で発生します。まず特定のサイトだけに影響するのかを確認し、直接接続の結果、システム証明書の状態、プロキシログを順に照合します。証明書の問題をすべてノードのせいにしないための切り分け方法を解説します。
記事を読む →メインルーターで直接実行する構成と、バイパスルーターで通信を制御する構成を比較します。バイナリのアーキテクチャ、設定ディレクトリ、透過プロキシ、DNS転送、自動起動の関係を説明し、導入前の構成判断に焦点を当てます。どの通信がコアを通るのか、元のルーターがDHCPとゲートウェイの役割を継続するのかを確認できます。
記事を読む →