Clash
Clashは、ルールに基づいてプロキシ設定と通信の振り分けを行う仕組みです。一般にClash Android版は、グラフィカルなクライアントとプロキシコアの2つで構成されます。クライアントは設定のインポート、切り替え、表示を担当し、コアは接続の確立、ルール判定、DNS処理、通信転送を担います。クライアントによって画面は異なりますが、基本的な設定構造はおおむね共通しています。
設定用語クイックリファレンス
Clash Android用語集
mihomoコアからTUN、Fake-IP、プロキシグループ、サブスクリプションの上書きまで、設定の流れに沿って主要な用語を解説します。各項目で概念、役割、利用時の注意点を確認できます。
6
設定カテゴリ
26
主要用語
設定の流れ
サブスクリプションのインポートから通信制御まで
基礎レイヤー
基本概念
まず、クライアント、コア、設定、ノードを区別しましょう。これらを理解すると、その後のルール、DNS、TUN設定の確認が容易になります。
mihomo
mihomoは、Clash Metaから発展したオープンソースのプロキシコアです。ルールベースの振り分け、TUN、Fake-IP、ルールセットのサブスクリプション、複数のプロキシプロトコルに対応し、多くの新しいクライアントでネットワーク処理の実行コアとして使われています。クライアントのバージョンとコアのバージョンは別の概念であり、画面側のアプリを更新してもコアが同時に変わるとは限りません。
設定ファイル
設定ファイルはプロキシの動作を記述するYAMLドキュメントです。ノード、プロキシグループ、ルール、DNS、待受ポート、TUNパラメータなどを記述します。完全な設定をクライアントへ直接インポートすることも、サブスクリプションURLからリモート取得することもできます。読み込みの成否は、フィールド名、インデント、データ型、コアとの互換性に左右されます。
ノード
ノードは設定ファイルに記述するプロキシサーバーへの接続項目です。通常、サーバーアドレス、ポート、プロトコル、認証情報、トランスポートパラメータを含みます。ノードは接続経路であり、プロキシグループそのものではありません。ルールは通常プロキシグループを参照し、グループが実際に使うノードを決定します。ノードの可用性は、サーバーの状態、回線の混雑、ローカルネットワーク環境にも影響されます。
遅延
遅延はテストリクエストの往復にかかる時間を示し、通常はミリ秒で記録します。遅延が小さいほど操作への応答は速い傾向がありますが、ダウンロード帯域、パケットロス、長時間の安定性を単独で示すものではありません。クライアントの遅延テスト結果は、テスト先、DNS解決、現在のネットワーク状態にも左右されます。
接続レイヤー
プロキシプロトコル
プロキシプロトコルは、クライアントとサーバーが通信する方法を決めます。ローカルのプロキシインターフェースとリモートノードのプロトコルは用途が異なるため、設定時は対象のフィールドがどのレイヤーに属するかを確認してください。
HTTPプロキシ
HTTPプロキシは、HTTPおよびHTTPSリクエスト向けのアプリケーション層プロキシインターフェースです。手動プロキシ設定に対応するブラウザやアプリは、ClashのローカルHTTP待受ポートへ接続し、コアがルールに従って出口を選択します。アプリ側でプロキシ設定を明示的に利用する必要があるため、Androidアプリの通信すべてを自然にカバーできるわけではありません。
SOCKS5
SOCKS5は汎用プロキシインターフェースで、複数のTCP通信を転送でき、クライアントの実装によってはUDPにも対応します。HTTPプロキシと異なり、具体的なWebリクエスト形式を理解する必要がないため、適用範囲が広いのが特徴です。アプリがSOCKS5の待受アドレスへ明示的に接続しない場合は、Android VPNインターフェースまたはTUNによる通信制御を検討してください。
Shadowsocks
Shadowsocksは暗号化通信を使用するプロキシプロトコルです。ノード設定では通常、サーバーアドレス、ポート、暗号化方式、パスワードが必要で、いずれか1つでも一致しないとハンドシェイクに失敗することがあります。これはクライアントとリモートサーバー間の接続方法を定義するもので、どのドメインをプロキシ経由にするかは決定しません。
VLESS
VLESSは軽量なプロキシプロトコルで、TLS、REALITY、WebSocket、gRPCなどのトランスポートやセキュリティ層と組み合わせて使われます。ユーザー識別子だけでなく、サーバー名、トランスポート種別、パス、公鍵などのパラメータも確認が必要です。同じプロトコル名でも、すべてのトランスポート構成を相互に置き換えられるわけではありません。
判断レイヤー
ルールとプロキシグループ
ルールは接続の振り分け先を判定し、プロキシグループはどの出口を使うかを決めます。この2つが連携して、Clash設定の主要な振り分けロジックを構成します。
ルールベースの振り分け
ルールベースの振り分けは、ドメイン、IP、ネットワーク種別、プロセスなどの条件に基づき、接続を指定したプロキシグループへ渡す処理です。ルールは通常、上から順に判定され、一致すると後続の項目は確認されません。そのため、具体的なルールを広範なルールより前に置き、早い段階の一般条件に取り込まれないようにします。
プロキシグループ
プロキシグループは、ノードや他のプロキシグループをまとめる論理コンテナです。一般的な種類には、手動選択の select、定期テストの url-test、フェイルオーバーの fallback、接続を分散する load-balance があります。ルールが参照するのはプロキシグループ名で、その後グループが実際の出口を決定します。
ルールセット
ルールセットは、個別に管理してメイン設定から参照できるルールの集合で、rule providerとも呼ばれます。サービスドメイン、地域IP、広告ドメインなどの分類をメイン設定から分離するのに適しています。リモートルールセットでは、取得元、更新周期、動作種別を設定します。更新に失敗した場合は、通常、既存のキャッシュが引き続き使われます。
GEOIP
GEOIPは、対象IPが地域データベース上で属する地域に基づいて判定します。通常、ドメインの名前解決が完了した後に判定されるため、DNSが返すアドレスやデータベースのバージョンに結果が左右されます。世界各地に分散したアドレスを使うサービスでは、GEOIPだけでサービスの地域を正確に表せない場合があります。
MATCH
MATCH はルール一覧の最終フォールバック項目で、それまでの条件に一致しなかった接続を受け取ります。通常はルール一覧の末尾に置き、統合管理用のプロキシグループ、直結、拒否のいずれかへ向けます。適切なフォールバックがないと、未分類通信が想定外の方法で処理される可能性があります。
名前解決と通信制御
DNSと通信制御
DNSはドメインからアドレスを取得する方法を決め、TUNはどの接続をコアへ入れるかを決めます。両方を一体として考える必要があり、片方だけを調整すると名前解決とルーティングにずれが生じやすくなります。
DNSリーク
DNSリークとは、通信がプロキシを経由している一方で、ドメイン検索が想定外のリゾルバーによって処理される現象です。検索経路が露出したり、プロキシ出口の地域と合わないアドレスが返されたりする可能性があります。確認時は、AndroidのプライベートDNS、ClashのDNSモジュール、TUNのDNSハイジャック、ブラウザ独自の暗号化DNS設定をまとめて確認してください。
Fake-IP
Fake-IPモードでは、ドメインに対して予約アドレスプール内の一時的なマッピングアドレスを返します。アプリがそのアドレスへ接続すると、コアが元のドメインを復元し、ドメインルールに従って出口を決定できます。ドメイン情報を維持しやすい一方、LANサービス、ゲーム、厳格な検証を行うアプリでは除外リストへの追加が必要になる場合があります。
Nameserver
nameserver は、ClashのDNSモジュールが通常の名前解決に使用する上流リゾルバーの一覧です。上流には従来のUDPやTCPを使えるほか、コアの対応状況に応じて暗号化DNSも指定できます。リゾルバーは単発の検索速度だけでなく、ネットワーク到達性、応答結果、ルール要件を考慮して選びます。
TUNモード
TUNモードは仮想ネットワークインターフェースを通じてシステム通信を制御し、HTTPやSOCKS5の設定に対応しないアプリにも適しています。Androidでは通常、システムのVPNインターフェースを利用して動作し、自動ルート、厳格なルート、DNSハイジャックと組み合わせることもできます。同じ端末で、この種のVPNインターフェースを同時に占有できるツールは通常1つだけです。
デバイスレイヤー
Androidプラットフォーム関連
Androidには、バックグラウンド動作、VPNインターフェース、アプリの対象範囲を個別に管理する仕組みがあります。クライアントの設定が正しくても、システム権限が実際の接続状態に影響する場合があります。
Android VPN権限
Android VPN権限により、アプリはローカルの仮想ネットワークインターフェースを作成し、端末の接続をプロキシコアへ渡せます。通信制御を初めて有効にすると、システムに許可確認が表示されます。この権限は、必ずしもリモートVPNサービスを経由することを意味せず、端末内部のTUN転送にも利用できます。
アプリ別振り分け
アプリ別振り分けでは、Androidアプリごとにプロキシ制御の対象に含めるかを選択します。ホワイトリスト方式は選択したアプリだけを処理し、ブラックリスト方式は大半のアプリを制御して指定した項目を除外します。対象範囲を変更した後は、既存の接続が変更前の経路を使い続けないよう、接続を再確立してください。
バッテリー最適化
バッテリー最適化は、Androidがバックグラウンドアプリに適用する省電力制限です。画面消灯後や長時間のバックグラウンド動作後にクライアントが停止し、通知は残っているのに新しい接続だけ失敗したり、プロキシサービスが再起動されたりすることがあります。安定した常駐が必要な場合は、システム設定でクライアントのバックグラウンド動作とバッテリー管理を確認してください。
実行ログ
実行ログには、設定の読み込み、ルール判定、DNS検索、ノード接続、エラー情報が記録されます。問題を調べる際は、まずエラー発生時刻、接続先、適用されたプロキシグループ、エラー種別を確認します。ログの単発の失敗だけで全体が利用不能とは限らないため、発生頻度と該当アプリを併せて判断してください。
設定の取得元
サブスクリプションと設定ファイル
サブスクリプションはリモート内容を更新し、YAMLはローカル設定の構造を定義し、上書きは端末側の調整を両者の間で維持します。
サブスクリプション
サブスクリプションは、リモートURLからノード一覧や完全な設定を取得する更新方式です。インポートに成功しても、その時点で返された内容をクライアントが読み取れたことを示すだけで、すべてのノードが利用できるとは限りません。サブスクリプションURLの内容が更新されたら、クライアントで設定を再取得して読み込む必要があります。既存の接続は通常、新しいノードへ自動移行しません。
自動更新間隔
自動更新間隔は、クライアントがサブスクリプションやルールセットを再取得する周期で、通常は分または時間で指定します。短い間隔ならリモートの変更を早く取得できますが、リクエスト頻度とバックグラウンド動作が増えます。設定後は、Androidがクライアントのバックグラウンド定期実行を許可しているかも確認してください。
YAML
YAMLはClash設定でよく使われるデータシリアライズ形式で、インデントによってオブジェクトとリストの階層を表します。タブ、誤ったインデント、重複キー、不完全な引用符は設定の解析失敗につながります。編集時は同じ階層のインデントを統一し、コロンの後ろにスペースを入れてください。
上書きとマージ
上書きとマージは、リモートサブスクリプションを基にローカルのパラメータを適用する機能です。DNSの追加、ルール順の調整、プロキシグループの変更などに使えます。サブスクリプションの更新機能を保ちながら、更新のたびに手動編集を繰り返す手間を減らせます。クライアントによって上書き構文やマージ順が異なるため、設定を移行する際は再確認が必要です。