おすすめの設定手順
まず設定ファイルを導入して有効化し、次にプロキシグループで普段使う出口を選び、システムプロキシを有効にしてブラウザのアクセスを確認します。アプリがシステムプロキシに従わない場合に限り、TUNを設定してください。DNSの調整は基本接続が安定してから行います。そうすれば、問題の原因がサブスクリプション内容、プロキシ入口、ルート、名前解決経路のどこにあるかを切り分けやすくなります。
利用するデバイスと目的に合わせて、クライアントの選択、サブスクリプションの導入、システムプロキシの設定をまとめて解説します。まず基本接続を確立し、必要に応じてTUN、DNS、ルールを調整します。
Clash クライアントのグラフィカルインターフェースは、主に設定の管理、動作モードの切り替え、システムのネットワーク入口の制御を担います。コアは設定ファイルに従って接続を処理し、クライアントはよく使う操作を画面上の設定にまとめます。ここでは、実際の設定順に沿って混同しやすいポイントを整理します。
Profiles
config.yaml
設定ファイルには通常、プロキシ提供元、プロキシグループ、ルール、ポート、DNSパラメータが含まれます。初回利用時は、まずサブスクリプションURLの入手元を確認し、クライアントの設定画面またはサブスクリプション画面から導入します。導入に成功しても、ファイルを読み込めたことを示すだけなので、アクティブ設定に指定する必要があります。サブスクリプションを更新すると、クライアントはリモートの内容を再取得します。ローカルで手動変更した内容は上書きされる可能性があるため、継続利用するカスタムルールは上書き設定やマージ設定に置くのが適しています。更新に失敗した場合は、URLが完全か、ネットワークに接続できるか、システム時刻が正確か、リモートサービスが有効なYAMLを返しているかの順に確認してください。
DOMAIN-SUFFIX,example.com,ProxyGEOIP,CN,DIRECTMATCH,Finalルールモードは、すべての接続を同じプロキシに一括して渡す仕組みではありません。設定内のルールを上から順に照合します。ドメイン、IP、プロセス、ルールセットのいずれかに一致すると、指定されたプロキシグループへ送られます。プロキシグループは手動選択できるほか、可用性に応じた自動選択も可能です。利用時はまずプロキシ画面で、Proxy、Streaming、Finalなどのグループの現在の選択先を確認してから、システムプロキシを有効にします。ルールの順序は結果に直接影響するため、具体性の高いルールを通常は前に置き、最後に最終マッチ用のルールを置きます。単一のグローバルスイッチだけを備えたツールと比べ、直結、プロキシ、拒否の方針を同じ設定内で確認しやすい構造です。
localhost
システムプロキシを有効にすると、OSのHTTPおよびSOCKSプロキシの入口がクライアントの待受ポートへ向き、ブラウザや多くのデスクトップアプリがこの設定を自動的に読み取ります。有効にした後はクライアントを起動したままにし、アクティブ設定が読み込まれていることを確認してください。一部のプログラムはシステムプロキシを読み取らず、独自のネットワークスタックを使用します。その場合、システムプロキシを有効にしただけでは接続経路は変わりません。クライアントを終了する前にシステムプロキシを無効にし、停止したローカルポートをシステムが参照し続けないようにすることをおすすめします。LAN接続は、他のデバイスから本機のプロキシポートへアクセスする必要がある場合だけ有効にし、ファイアウォールと信頼できるネットワーク環境でアクセス範囲を管理してください。
TUNモードは仮想ネットワークインターフェースでシステムの通信を受け取るため、ゲームランチャー、コマンドラインツール、システムプロキシを読み取らないアプリに適しています。通常のシステムプロキシより対象範囲が広い一方、OSの権限、ルーティングテーブル、ファイアウォールの状態に大きく左右されます。初回有効化時には、管理者権限やネットワークコンポーネントのインストールを求められることがあります。設定後は、よく使うサイトとLANへのアクセスを確認してから、厳格なルートやインターフェース除外などの詳細項目を調整してください。通信できなくなった場合は、まずTUNを無効にして基本のシステムプロキシが使えることを確認し、仮想インターフェース、他のVPNソフト、セキュリティソフトの間でルートが競合していないか確認します。
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
DNS設定はドメインの解決方法だけでなく、一部のルールが想定どおり照合されるかどうかにも影響します。内蔵DNSを有効にすると、クライアントは設定に従ってnameserver、fallback、拡張モードを選択でき、システムの名前解決経路とプロキシ経路の不一致を減らせます。fake-ipは透過的な通信取り込みに適していますが、LANデバイス、特殊なドメイン、一部のアプリでは除外リストへの追加が必要になる場合があります。切り分けでは複数のパラメータを同時に変更せず、まず設定を読み込めることを確認し、次にクエリがクライアントを経由しているか、最後に対象ドメインがどのルールに一致したかを確認してください。システム上で他のDNSツールも動作している場合は、待受ポートとネットワークインターフェースの競合にも注意が必要です。
まず設定ファイルを導入して有効化し、次にプロキシグループで普段使う出口を選び、システムプロキシを有効にしてブラウザのアクセスを確認します。アプリがシステムプロキシに従わない場合に限り、TUNを設定してください。DNSの調整は基本接続が安定してから行います。そうすれば、問題の原因がサブスクリプション内容、プロキシ入口、ルート、名前解決経路のどこにあるかを切り分けやすくなります。
ルールモードは設定ファイルの各ルールに従って、直結、プロキシ、拒否を決めるため、日常利用に適しています。グローバルモードでは、ほとんどの接続を現在のグローバルポリシーへ渡すため、短時間だけルールのマッチ漏れを調べたい場合に便利です。ダイレクトモードはプロキシを迂回します。モードを切り替えても、無効なサブスクリプションが直るわけではなく、システムプロキシが有効になっていない問題も自動では解決しません。判断時は設定の状態と入口の状態を分けて確認してください。
プラットフォームごとに、インストール形式、システム権限、プロキシの入口は異なります。ダウンロードページでは、現在も利用できるグラフィカルクライアント、開発終了したアーカイブ版クライアント、サーバー向けのコアファイルをプラットフォーム別に掲載しています。トップページは各プラットフォームへの入口のみを提供し、インストーラー自体は配布していません。
システムプロキシとTUNに対応するGUIクライアントです。導入前にアーキテクチャを確認し、UWPアプリがプロキシを迂回する場合はループバック設定を確認します。
ダウンロードページへApple Silicon版とIntel版を選択します。初回起動ではセキュリティ許可が必要です。コマンドラインツールには環境変数やTUNを使います。
ダウンロードページへAndroidのVPN機能を使用します。導入後にVPN接続を許可し、省電力設定で停止しないよう必要なバックグラウンド動作を許可します。
ダウンロードページへiOSのネットワーク拡張を使用します。初回接続でVPNを許可し、サブスクリプション導入後は用途に合うプロキシグループを確認します。
ダウンロードページへデスクトップではGUI、サーバーやルーターではMihomoコアを利用できます。アーキテクチャを合わせ、TUNやTProxy、DNS、自動起動を設定します。
ダウンロードページへグラフィカルクライアントは、設定の導入、プロキシの切り替え、ログの確認、システムスイッチを提供し、個人用デバイスに適しています。コアは設定を読み込み、接続を処理するもので、コマンドライン、サービス管理、ネットワークルーティングに慣れたユーザー向けです。両者は同じインストール形態ではありません。初めて使う場合は、グラフィカルクライアントから始めるほうが問題を切り分けやすいでしょう。
Clashは単一プラットフォーム向けの固定されたインストーラーではなく、コア、グラフィカルクライアント、ルールプロジェクト、設定ツールで構成されるエコシステムです。これらの境界を理解すると、更新元を判断しやすくなり、クライアント画面の問題とコア設定の問題を混同せずに済みます。
初期のClashコアは、YAML設定、ルール照合、プロキシグループ選択を基盤とする利用方法を確立し、その後Windows、macOS、Androidなどのプラットフォーム向けグラフィカルクライアントが登場しました。一部の初期プロジェクトはすでに開発を終了していますが、そこで使われた設定構造や操作方法は今も広く残っています。現在利用する際は、古いガイドにあるクライアント名だけで利用可否を判断せず、プロジェクトのメンテナンス状況、対象システムの対応、使用するコアの分岐を同時に確認してください。
MihomoはClash Meta関連の機能を継承・拡張し、設定の解析、待受ポートの開設、ルール処理、プロキシグループの実行、DNSロジックを担います。グラフィカルクライアントはその外側に操作画面を提供し、更新方法、設定の上書き構造、システム統合方式はクライアントごとに異なる場合があります。そのため、同じサブスクリプションでもクライアントによって入口の名称は異なりますが、切り分けの流れは共通しています。設定が有効か、コアが動作しているか、システム通信が待受入口へ入っているか、ルールが想定したプロキシに一致しているかを確認します。
サブスクリプションは通常、サービス提供元が生成し、ルールセットは独立したオープンソースプロジェクトが管理している場合があります。クライアントはこれらの内容を読み込んで実行するだけで、リモートのサブスクリプションに含まれる形式エラーを修正するものではありません。導入前にURLの入手元と用途を確認し、個人のアクセス情報を含むサブスクリプションURLをログ、スクリーンショット、コードリポジトリに公開しないでください。カスタムルールを長期的に管理する場合は、個人用の上書き設定とリモートサブスクリプションを分けて保存し、更新のたびに修正をやり直す事態を避けます。
クライアントの更新、コアの更新、サブスクリプションの更新は、それぞれ独立した経路です。クライアント更新は画面とプラットフォーム統合を変更し、コア更新は設定機能の追加やネットワーク処理の修正をもたらす場合があります。サブスクリプション更新では、プロキシ提供元、プロキシグループ、ルールの内容が変わります。更新後に異常が起きた場合は、まずどの層で変更が発生したかを確認し、対応するログと設定差分を調べてください。安定運用中はすべての層を同時に変更せず、段階的に更新するほうがロールバックと原因特定が容易です。
YAMLファイルでは、待受ポート、DNS、プロキシグループ、ルールの順序を明確に記述できます。変更前に動作するコピーを保存し、一度に一種類のパラメータだけを調整すると、エラーが発生した際に原因となった設定箇所を特定しやすくなります。
接続失敗が必ずしもノードの問題とは限りません。ログを使えば、設定の解析失敗、DNS解決異常、ルールの照合結果、ポート競合、システム入口が取り込まれていない状態を区別できます。トラブルシューティングは具体的なエラーメッセージを起点に進めてください。
サブスクリプション、ルールセット、コア、グラフィカルクライアントにはそれぞれ境界があります。グラフィカルクライアントの開発が終了しても、互換性のあるクライアントへ移行できます。移行前に個人用の上書き設定をエクスポートし、プラットフォーム権限とシステムプロキシ設定を改めて確認してください。
技術メモでは、初回利用、DNS、ポート競合、プラットフォーム固有の問題を扱います。操作場所、コマンドの用途、判断の順序を示しているため、基本ガイドを読んだ後に具体的な症状から調べたい場合に適しています。
クライアントの選び方、サブスクリプションURLの導入方法、ルールモードとグローバルモードの違い、システムプロキシが機能しない理由、プロキシ切り替え後の確認場所をまとめて解説します。各質問をクライアント内の実際の設定場所に結び付けています。
記事を読む →ブラウザでの検査とコマンドラインから始め、DNSがクライアントを迂回していないかを確認します。そのうえで、enhanced-mode、nameserver、fallbackの関係を順に解説します。設定変更では一度に一つのパラメータだけを変え、名前解決経路とプロキシ経路を同時に変えないことを重視します。
記事を読む →Windows、macOS、Linuxで待受ポートを使用しているプロセスを特定し、残ったクライアントなのか別のネットワークツールなのかを判断する方法を解説します。クライアントの待受ポートとシステムプロキシ設定を併せて変更し、一方だけ変更して接続できない状態を避けます。
記事を読む →