OPEN SOURCE · CLIENT AND CONFIGURATION
デバイスに合う、継続的に使いやすいClashクライアントを選び、ルール分岐、プロキシグループ、日本語設定ガイドで購読の導入、システムプロキシ設定、接続トラブル対処を進められます。
PLATFORM CONNECTORS
まずデバイスのOSを確認し、ダウンロードページでCPUアーキテクチャ、クライアントのメンテナンス状況、パッケージ形式を確認してください。トップページのリンクはプラットフォームの案内用で、インストーラーを直接配布するものではありません。
デスクトップでの日常利用に適しています。ダウンロードページではClash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuに加え、旧設定の移行に使えるClash for Windowsのアーカイブも案内しています。インストール前にシステム設定でWindowsのバージョンとCPUアーキテクチャを確認し、普段使いにはGUIを備え、現在も保守され、Mihomoに対応するクライアントを優先してください。
ダウンロード時はIntelとApple Siliconを区別する必要があります。GUIクライアントではシステムプロキシ、ルールモード、購読の更新を管理できます。初回起動時は、システムの案内に従ってアプリの権限も許可してください。旧版のClashX Metaは既存環境の移行用とし、新規インストールでは現在も保守されているクライアントを優先して確認しましょう。
スマートフォンやタブレットに適しています。インストーラーは通常、ARM64、ARM、ユニバーサル版に分かれており、近年の主流デバイスの多くはARM64を採用しています。購読を導入した後は、クライアントによるローカルVPNインターフェースの作成を許可する必要があります。省電力機能でバックグラウンド接続が停止することがあるため、継続利用時はバッテリー最適化の設定を確認してください。
App StoreからClash Plusをインストールし、システムが提供するVPN設定機能でプロキシが必要な接続を処理します。設定を導入する前に、購読内容が信頼できるものか確認してください。同じ設定を複数のデバイスで使う場合も、各デバイスに個別に導入し、現在のネットワークに合わないノードをそのまま使わないよう、プロキシグループの選択をそれぞれ確認しましょう。
デスクトップ環境ではClash Verge RevまたはFlClashを選べます。サーバー、ソフトウェアルーター、コンテナ環境では通常、Mihomoカーネルを直接実行します。カーネルを使う場合は、設定ファイルの場所、サービスの常駐、ファイル権限、制御ポートを自分で管理する必要があるため、Clashを初めて使う方はGUIクライアントから始めるのがおすすめです。
CONFIGURATION BUS
設定は、互いに無関係なスイッチの集まりではありません。接続はまずネットワークインターフェースに入り、ドメイン名の解決、ルールの照合、プロキシグループの選択を経て、最後に選択した出口から処理されます。以下では、この5つの構造を役割ごとに分けて説明します。
ルールエンジンは、ドメイン、IP、プロセス、ルールセットなどを基に、接続をどのプロキシグループへ送るか判断します。設定内のルールは上から順に照合され、通常は一致した時点で後続の確認を行いません。そのため、具体的なドメインルールは広範なルールより前に置き、MATCHでそれまでに一致しなかった接続を処理します。分岐の誤りを調べるときは、まず現在のモードがルールモードか確認し、次にルールの順序、ルールセットの読み込み状態、最終的に指定されたプロキシグループ名を確認してください。
グローバルなオン・オフだけを提供するプロキシツールとは異なり、Clashのルールチェーンでは、直結、プロキシ、ブロックの動作を同じ設定に記述できます。ルール自体が特定のノードを決めるのではなく、トラフィックをプロキシグループへ渡す仕組みです。この分離により、ルールセットを長期的に再利用しながら、出口ノードだけをネットワーク状況に応じて切り替えられます。
rules:
- DOMAIN-SUFFIX,example.cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXYプロキシグループはルールとノードの間に位置します。selectは出口を手動で指定する場合に適し、url-testはテスト結果に基づいて自動選択し、fallbackは登録順に利用可能か確認し、load-balanceは複数の出口への分散に使います。実際の設定では安定性の要件に応じてグループ種別を選び、名前が似ているからと安易に置き換えないでください。自動テスト先、テスト間隔、タイムアウトの設定も切り替え結果に影響します。
アプリのルールからは、特定のノード名ではなく、安定したプロキシグループ名を参照することをおすすめします。購読の更新でノードが増減しても、グループ内のメンバーを調整するだけで済み、ルール全体を書き直す必要がありません。複数の購読を統合する際は、同名ノードを避け、プロキシグループが参照するプロバイダーの読み込み完了も確認してください。
proxy-groups:
- name: PROXY
type: select
proxies:
- AUTO
- DIRECTDNS設定では、ドメインをどのように解決するか、どのサーバーへ問い合わせるか、解決結果をルールエンジンとどう連携させるかを指定します。Fake-IPを有効にすると、クライアントはまず予約アドレスを返してドメインとの対応を保存し、後続の接続をドメインルールに従って判定できます。Redir-Hostは従来の名前解決に近い方式です。サイトの名前解決に問題がある場合は、システムDNSが乗っ取られていないか、上流サーバーに到達できるか、拡張モードが現在のネットワークに合っているか、フィルターリストがLAN内のドメインを対象にしていないかを順に確認してください。
DNSリーク、汚染、問い合わせループは、複数のソフトウェアが同時に名前解決を管理していることから起こりがちです。設定時は、システム、クライアント、ルーターのどれが入口の名前解決を担当するかを明確にし、プロキシ経由が必要なDNS上流サーバーを誤って直結経路へ送らないようにしてください。
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 1.1.1.1TUNモードは仮想ネットワークインターフェースを作成し、システムプロキシ設定を読み取らないアプリもClashの処理チェーンに取り込めるようにします。コマンドラインツール、一部のゲームランチャー、独自のネットワークスタックを使うソフトに適していますが、ルーティング、DNS、権限設定は複雑になります。デスクトップで有効にする前に、クライアントに必要な権限があることを確認し、ほかのVPN、セキュリティソフト、仮想NICが同じルートを使用していないか確認してください。
TUNを有効にした後に完全にインターネットへ接続できなくなっても、すぐにノードを何度も切り替えるべきではありません。まずTUNを無効にして通常の状態へ戻し、次にスタックの種類、自動ルート、DNSハイジャック、ファイアウォールルールを確認する方が効果的です。システムプロキシは正常なのに特定のアプリだけプロキシを通らない場合に限り、TUNが必要か判断してください。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true外部制御インターフェースは、デスクトップクライアントや管理パネルがプロキシグループ、接続、ログを読み取り、プロキシを切り替えるために使われます。通常はローカルアドレスだけで待ち受ければ十分です。LANへ公開する場合は、アクセスキーとファイアウォールの範囲も同時に設定してください。管理パネルはあくまで操作の入口であり、実際の通信はClashまたはMihomoカーネルが処理します。そのため、パネルが開けない問題とプロキシ経路が機能しない問題は別であり、静的ページ、制御ポート、カーネルプロセスを分けて確認する必要があります。
リモート管理では、制御ポートを直接公開しないでください。管理されたネットワークや、アクセス制御を設定したリバースプロキシを経由して管理パネルへ接続し、到達可能な送信元も制限する方が安全です。制御アドレスを変更した場合は、クライアントの管理パネルにある接続パラメーターも更新してください。
external-controller: 127.0.0.1:9090
secret: "your-password"OPEN SOURCE TRACE
Clash関連のクライアント、カーネル、設定形式は、複数のプロジェクトによって構成されています。特定のクライアント名だけを覚えるより、各層の役割を把握する方が、移行やトラブル対処に役立ちます。
Clashはルール駆動型のプロキシモデルによって、設定の基盤を築きました。待ち受けポート、プロキシノード、プロキシグループ、ルール、DNSが処理チェーンを構成します。元プロジェクトのメンテナンス状況が変化した後も、コミュニティのクライアントや互換カーネルは発展を続けています。現在クライアントを選ぶ際は、名前にClashが含まれるかだけで判断せず、メンテナンス状況、カーネルの種類、OS対応、設定の互換範囲を併せて確認してください。
Clash for Windowsなどの旧クライアントは、古いチュートリアルや既存デバイスに残っている場合があります。しかし、メンテナンスが終了したソフトウェアを新規インストールの標準にするのは適切ではありません。移行時はまず元の設定をエクスポートまたは保存し、新しいクライアントが対応する購読形式、スクリプト機能、オーバーライド方式を確認してください。クライアント固有のフィールドを、互換カーネル共通のフィールドと混同しないことも重要です。
GUIクライアントは、インストール体験、購読管理、システムプロキシの切り替え、ログ表示、プロキシグループの操作を担当します。Mihomoなどの互換カーネルは、設定の解析、待ち受けポートの作成、ルールの実行を担います。購読サービスはノードとプロキシグループの内容を提供します。3つの層は組み合わせて使えますが、障害の場所はそれぞれ異なります。クライアントの画面が開いてもカーネルが起動しているとは限らず、カーネルが正常に動作していても購読内のノードが現在利用できるとは限りません。
問題を切り分けるときは、層ごとに確認します。まずローカルネットワークとシステム時刻、次に購読への応答と設定の解析、続いてカーネルログ、プロキシモード、プロキシグループの選択、DNS、システムファイアウォールを確認してください。層別に調べることで、ノードが使えないのにクライアントを何度も再インストールしたり、設定構文のエラーをシステムネットワーク障害と誤認したりするのを防げます。
MihomoはClashの設定思想を受け継ぎ、ルールプロバイダー、プロキシプロバイダー、DNS、TUN、トラフィック嗅覚、制御インターフェースなどの機能を拡張しています。多くの現代的なGUIクライアントは、カーネルのダウンロードと起動を内部で処理するため、一般ユーザーがバイナリファイルを手動で実行する必要は通常ありません。サーバー、ルーター、コンテナの利用者は、設定ディレクトリ、実行権限、サービスの常駐、ログローテーションを自分で管理する必要があります。
設定の移行では、YAMLを解析できるかだけを見てはいけません。一部のフィールドは特定のカーネルバージョンやクライアントのオーバーライド処理に依存します。同じ購読でも、クライアントによってDNS、TUNスタック、システムプロキシの既定動作が異なる場合があります。移行後は、直結サイト、プロキシサイト、ドメイン解決、アプリ終了後にシステムプロキシが元へ戻るかを個別に確認してください。
クライアント、カーネル、購読の更新は、それぞれ解決する問題が異なります。クライアントのアップグレードは通常、画面、システム連携、カーネル管理方式を変更します。カーネルの更新では設定フィールドが追加されたり、ネットワーク動作が修正されたりします。購読の更新ではノード、プロキシグループ、ルールの内容が変わります。異常が発生したら、直近に変更された層を記録し、設定を戻すか、ノードを切り替えるか、クライアントを再インストールするか判断してください。
更新前に現在利用できる設定を保存し、システムプロキシ、TUN、DNS、オーバーライドの設定を記録してください。更新後は遅延テストだけで判断せず、プロキシグループが完全に読み込まれているか、ルールプロバイダーが読み込まれているか、ログに解析エラーがないかを確認します。さらに、ブラウザーとシステムプロキシを読み取らないアプリが、それぞれ想定どおり動作するか確認してください。
QUICK DIAGNOSTICS
以下の結論は、トラブル対処の順序を組み立てるためのものです。詳しい手順は、トラブル対処または使い方ガイドをご覧ください。
新規インストールでは、現在も保守され、使用中のOSに対応し、互換カーネルを採用しているクライアントを優先してください。WindowsユーザーはClash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuを比較するとよいでしょう。古い設定を移行する場合は、購読URLとローカルオーバーライドを先に保存し、システムプロキシ、プロキシグループ、DNS、TUNを一つずつ確認してください。詳しい違いはクライアント比較をご覧ください。
まず購読リクエストが成功しているか確認し、返された内容を現在のクライアントが解析できるか確認してください。ログにYAML構文、フィールド型、プロキシグループ参照のエラーがある場合は、先に設定を修正します。購読内容が正常なのに一覧が更新されない場合は、再取得してクライアントが古いキャッシュを使っていないか確認してください。解析結果を確認する前に、プロキシモードを何度も切り替えるのは避けましょう。
まずシステムプロキシを無効にして、ローカルネットワーク自体が利用できるか確認します。次にカーネルが起動しているか、ノードへ接続できるか、現在のモードとプロキシグループが正しいかを確認してください。ブラウザーに接続できない場合はDNSも確認します。特定のアプリだけプロキシを通らない場合に限り、そのアプリがシステムプロキシを無視してTUNを必要とするか判断してください。詳しい手順はトラブル対処をご覧ください。
ルールモードは、設定に従って接続ごとに直結、プロキシ、ブロックを決定します。グローバルモードは通常、すべての接続を1つのプロキシグループへ渡すため、ノード経路を一時的に検証するのに適しています。直結モードはプロキシ出口を介さず、問題がプロキシ経路にあるか確認する際に使えます。普段はルールモードを使い、グローバルモードはルール設定の代わりではなく、短時間の診断手段として利用するのが一般的です。
TECHNICAL NOTES
ノード接続、購読の解析、クライアント選定について、再利用できる確認手順をまとめています。記事では再現性のない性能数値ではなく、設定の階層と操作手順を中心に解説します。
ローカルネットワーク、購読の状態、ノードの可用性、プロキシモード、DNS、システムファイアウォールの順に接続タイムアウトの原因を切り分け、問題の層を確認する前にクライアントを繰り返しインストールするのを避けます。
続きを読む →購読URLの期限切れ、応答内容の異常、設定形式のエラー、クライアントのキャッシュ問題を切り分け、リクエスト結果とカーネルログから障害の層を判断する方法を説明します。
続きを読む →対応プラットフォーム、カーネル、設定機能、メンテナンス状況から主要クライアントを比較し、デスクトップ、モバイル、サーバー環境で異なる選定基準を解説します。
続きを読む →