Windows
一般的なデスクトップ利用に適しています。インストール後は、システムプロキシ、待受ポート、UWPアプリのループバックを確認してください。より多くのアプリを対象にする場合は、権限要件を確認してTUNを設定します。
ダウンロードページへクライアント比較から始め、サブスクリプションの読み込み、プロキシモード、ルール振り分けを順に設定します。Windows・macOS・Linuxとモバイル版の入口や操作上の注意点をまとめています。
RULE ENGINE INDEX
クライアントの画面は操作の入口にすぎず、実際の動作は設定、プロキシグループ、ルールの評価順、システムでの適用範囲によって決まります。ここでは、利用時によく遭遇する5つのポイントに分けて説明します。
現在の確認ポイント
ルールの問題は、構文そのものより、前方にある範囲の広いルールがリクエストを先に捕捉しているケースが多くあります。接続ページで対象ドメインを探し、適用されたルールとプロキシグループを記録してから、設定ファイルに戻って順序を調整します。変更後は設定を再読み込みして新しい接続を作成してください。既存の接続が完全なマッチング処理を自動でやり直すことはありません。
現在の確認ポイント
ルールモードでは異常が出るのにグローバルモードでは正常な場合、ノードは利用可能で、問題はルールのマッチングまたはプロキシグループの選択に集中している可能性があります。両方のモードで失敗するなら、待受ポート、サブスクリプションの状態、ノード接続を続けて確認します。ダイレクトモードは元のネットワーク経路に戻し、プロキシの有無による違いを比較するために使います。
現在の確認ポイント
サブスクリプションURLが内容を返した後も、クライアントは形式の解析、ファイル保存、設定の選択、コアの再読み込みを完了する必要があります。読み込みに失敗したら、URLがWebページや汎用形式のサブスクリプション、ログイン案内ではなく、Clashが読み取れるYAMLを返しているか確認します。読み込み後は、現在有効な設定名も確認してください。
現在の確認ポイント
ブラウザがシステムプロキシ経由でアクセスできれば、ノード、ポート、基本設定はおおむね利用可能です。その後TUNを有効にし、システムプロキシを参照しないアプリをテストすれば、権限、仮想ネットワークアダプター、ルーティングの問題をノードの問題から切り分けられます。一度に変更する設定を1つにすると、結果を判断しやすくなります。
現在の確認ポイント
接続ページに対象リクエストがまったく表示されない場合、アプリはClashの待受入口まで到達していません。リクエストは表示されるもののポリシーが誤っているなら、ルールとプロキシグループを確認します。ポリシーが正しいのに接続できない場合は、ノードの状態、DNS結果、ログのエラーを確認してください。経路を区間ごとに確認すれば、無関係な設定を同時に変更せずに済みます。
PLATFORM ENTRANCE
同じClash設定でも、異なる画面のクライアントで読み込めます。選ぶときはOS、CPUアーキテクチャ、TUN対応、メンテナンス状況を重視し、画面の見た目だけで判断する必要はありません。
一般的なデスクトップ利用に適しています。インストール後は、システムプロキシ、待受ポート、UWPアプリのループバックを確認してください。より多くのアプリを対象にする場合は、権限要件を確認してTUNを設定します。
ダウンロードページへダウンロード時はApple Silicon版とIntel版を区別してください。初回起動ではネットワーク拡張機能やシステム権限の確認が必要になる場合があります。メニューバーの状態表示とシステムプロキシのスイッチも別々に確認します。
ダウンロードページへスマートフォンとタブレットに適しています。サブスクリプションを読み込むと、システムのVPNインターフェースがアプリの通信を引き受けます。省電力設定、バックグラウンド制限、常時接続設定は、接続の継続性に直接影響します。
ダウンロードページへシステムネットワーク拡張機能で接続し、設定、プロキシグループ、オンデマンド接続をアプリ内で管理します。初回利用時はVPN構成の追加を許可し、その後システムのステータスバーで接続状態を確認してください。
ダウンロードページへデスクトップ、サーバー、ルーター環境に適しています。GUIクライアントなら日常の切り替えが簡単です。Mihomoコアを直接実行する場合は、設定ファイル、サービスプロセス、権限を自分で管理する必要があります。
ダウンロードページへQUICK START
初期設定では、ルール、DNS、TUN、システムプロキシを同時に変更しないでください。まず最小限の通信経路を作り、その後対象範囲を一つずつ広げます。どの段階で問題が起きても、直前の正常な状態へ明確に戻せます。
詳しい手順を見るダウンロードページで、OSとCPUアーキテクチャに合うクライアントを選びます。初回起動後はログまたはステータスページを確認し、設定ディレクトリへの書き込み、待受ポートの作成、同じポートを使用する他のプロキシプログラムがないことを確認してください。
設定ページにサブスクリプションURLを貼り付けてダウンロードします。設定項目が表示されても、手動で選択してクライアントにコアを再読み込みさせる必要があります。その後プロキシページで、選択可能なプロキシグループに具体的なノードを指定します。
まずシステムプロキシを有効にし、ブラウザでテスト対象へアクセスして接続ページで該当リクエストを探します。ブラウザが正常になったら、ターミナルや他のアプリを個別に検証してください。より広い範囲を対象にする場合は、最後にTUNとDNSを設定します。
OPEN SOURCE CONTEXT
Clashクライアントを長期利用に適しているか判断するには、グラフィカルインターフェース、プロキシコア、設定形式、サブスクリプションの提供元を分けて考える必要があります。これらは異なるプロジェクトやサービスによって維持され、更新のペースもそれぞれ異なります。
Clashは当初、ルール駆動のクロスプラットフォーム対応プロキシコアとして広く使われる設定構文とポリシーモデルを築きました。元のプロジェクトが更新を停止した後も、既存の設定形式、ルール表現、クライアントの操作方法はエコシステムで受け継がれています。古いガイドを読むときは、原初のClash、後継コア、特定のGUIクライアントのどれを扱っているかを先に確認し、異なる時期の項目や機能を混同しないようにしてください。
一般的なデスクトップクライアントは、グラフィカルインターフェース、設定管理、システムプロキシ制御、コアプロセスで構成されています。画面側のプロジェクトはインストール体験、サブスクリプション更新、ポリシー選択、システム統合を担当し、コアはプロトコル接続、DNS、ルールマッチング、通信転送を担当します。あるクライアントの画面がメンテナンスされなくなっても、設定構文がすぐ無効になるわけではありませんが、システム互換性とコア機能には徐々に差が生じます。
MihomoはClashの設定体系を引き継ぎ、プロトコル、ルール、DNS、TUNなどの機能を拡張しています。現在の多くのデスクトップクライアントでは、交換可能なコアまたは内蔵コアとして利用されています。設定ファイルを読み込めるかどうかは、YAML構文だけでなく、使用中のコアが該当項目に対応しているかにも左右されます。見慣れない設定項目がある場合は、クライアント画面で同名のスイッチを探すだけでなく、まずコアのドキュメントを確認してください。
クライアント更新、コア更新、サブスクリプション更新は、それぞれ独立した経路です。クライアント更新は画面とシステム互換性を改善し、コア更新はプロトコルやネットワーク処理を変更します。サブスクリプション更新はノード、プロキシグループ、リモートルールを置き換えます。日常のメンテナンスでは3つの状態を分けて記録し、障害発生時は一度に1つの要素だけを戻すことで、変化の原因がソフトウェア、設定、サブスクリプションのどれか判断できます。
SOURCE COMMAND
以下のコマンドで公開ソースコードを取得できます。コアのビルドには独立したGo開発環境が必要です。日常利用だけが目的なら、GUI付きのクライアントを選ぶほうが適しています。
git clone https://github.com/MetaCubeX/mihomo.git
FIRST CHECKS
以下の4種類は、初めて使うときによく発生するつまずきをまとめたものです。詳しい操作手順は入門ガイドと利用マニュアルに掲載し、ここでは判断の方向性だけを示します。
まずURLがWebページや別形式のサブスクリプションではなく、Clashが読み取れるYAML設定を返しているか確認します。次に設定のダウンロードが成功し、現在有効な項目として選択されているか確認してください。ノードがプロキシグループ内にあり、トップページへ直接表示されない場合もあります。
サブスクリプションの読み込み手順を見る →一部のターミナルプログラムはOSのプロキシ設定を読み取らないため、HTTP、HTTPS、SOCKSの環境変数を個別に設定する必要があります。必要に応じてTUNを使うこともできます。トラブル対処では、ブラウザとターミナルを分けてテストし、それぞれのリクエストが接続ページに表示されるか確認してください。
システムプロキシとTUNを見る →日常利用では通常ルールモードを使い、ローカルサービス、プロキシ対象、拒否対象をそれぞれ処理します。グローバルモードはノードへ接続できるか短時間で確認する用途に適していますが、完全なルールの代わりにはなりません。モードを切り替えたら新しいテスト接続を作り、古いセッションが判断に影響しないようにしてください。
プロキシモードの説明を見る →リモートサブスクリプションが生成したファイルへ直接書き込んだ内容は、次回更新時に全体が置き換えられる可能性があります。長期的にカスタマイズする場合は、クライアントが提供する上書き、マージ、スクリプト機能を使ってください。変更前に起動可能なコピーを保存し、ルールが最終的に挿入される位置とMATCHとの順序も確認します。
ルールの管理方法を見る →LATEST NOTES
システムプロキシ、Windowsへのインストール、クライアント画面という3つの頻出場面を中心に、再現可能な確認手順で操作のポイントをまとめています。
システムプロキシを有効にしても通信がプロキシを通らない場合、ブラウザとターミナルを一緒に判断してはいけません。この記事では、プロキシ設定、拡張機能の競合、環境変数、待受ポートを分けて確認します。
記事を読む →インストーラーの選択、システムの警告、サブスクリプションの読み込み、システムプロキシまで、Windowsでの操作順を段階的に解説します。UWPループバック、ポート競合、スタートアップ設定にも対応します。
記事を読む →操作目的に応じてプロキシページ、設定ページ、接続ページ、ログページを区別し、ノード選択、サブスクリプション管理、リアルタイムセッション、障害記録の関係を説明します。
記事を読む →