カーネルとクライアント
カーネルはネットワーク接続を実際に処理し、GUIクライアントはその機能を操作しやすい画面にまとめます。役割分担を理解すると、問題が設定、カーネル、クライアント機能のどこにあるか判断しやすくなります。
- mihomo
-
mihomoはClash Metaから発展したプロキシカーネルで、プロトコル接続の確立、DNS処理、ルール照合、トラフィック転送を担います。多くのGUIクライアントはカーネルを呼び出し、設定管理、システムプロキシ、ログ画面を提供します。
問題を調べる際は、まずクライアント画面の設定とカーネル設定を分けて考えます。ログに出るルールのヒット、DNS問い合わせ、接続エラーは、通常カーネルが直接出力したものです。
- Clash Meta
-
Clash MetaはClashカーネルエコシステムの拡張実装で、より多くのプロキシプロトコル、ルール機能、ネットワーク処理オプションを追加しています。関連ドキュメントのMetaフィールドは、通常この拡張構文または互換機能を指します。
現在の資料では、Clash Metaとmihomoという2つの名称が併記されることがあります。古い設定を読む際は、名称だけで機能の対応可否を判断せず、フィールドとカーネルのバージョンを確認してください。
- GUIクライアント
-
GUIクライアントはグラフィカルな画面を備えたデスクトップまたはモバイルアプリです。サブスクリプション更新、ポリシー切り替え、システムプロキシ、TUNのオン・オフ、ログ確認などに対応します。クライアントとプロキシカーネルは個別に更新でき、バージョンが一致するとは限りません。
ある設定が画面に表示されないからといって、カーネルが対応していないとは限りません。一部の高度なフィールドは、上書きやYAML設定の直接編集で有効にする必要があります。
- YAML
-
YAMLはClash設定でよく使われるデータ形式で、インデントによってフィールドの階層を表します。空白、コロンの位置、リスト記号の影響を受けやすく、タブ、階層のずれ、空白の不足は解析失敗の原因になります。
設定を変更する際は、同じ階層のインデントをそろえてください。特殊記号を含む文字列は引用符で囲むと、真偽値、数値、コメントと誤認されにくくなります。
- 設定ファイル
-
設定ファイルには、ポート、動作モード、DNS、ノード、プロキシグループ、ルールセットなどが保存され、カーネル起動時に読み込まれます。サブスクリプションの内容も設定ファイルとしてクライアントに読み込まれます。
設定をダウンロードできても、カーネルが正しく解析できるとは限りません。読み込みに失敗した場合は、まずYAML構文を確認し、その後で現在のカーネルが各フィールドに対応しているか調べてください。
プロキシプロトコル
プロトコルは、クライアントがプロキシサーバーと接続を確立する方法を決めます。システムプロキシで使うHTTPやSOCKS5と、ノードで使うShadowsocksやTrojanは、異なるレイヤーの概念です。
- HTTPプロキシ
-
HTTPプロキシインターフェースは、プロキシ設定に対応したアプリのリクエストを受け付けます。ブラウザ、ダウンロードツール、開発ツールなどで使われ、HTTPSサイトでは通常CONNECTメソッドでトンネルを確立します。プロキシを使っても、対象サイトが通常のHTTPになるわけではありません。
Clash設定のHTTPポートは、ローカルで待ち受ける入口です。リモートノードがどのプロトコルを使うかとは直接対応しません。
- SOCKS5
-
SOCKS5は汎用性の高いプロキシプロトコルで、さまざまな上位接続を扱えます。ドメイン名をローカルまたはプロキシ側で解決するかをアプリが選べる場合もあります。多くのコマンドラインツールや開発ソフトでSOCKS5アドレスを直接指定できます。
socks5hのような記法では、通常ドメイン名をプロキシ側で処理します。一方、通常のsocks5での名前解決方法はアプリの実装によって異なります。 - Shadowsocks
-
Shadowsocksは暗号化通信を利用するプロキシプロトコルです。ノード定義には通常、サーバーアドレス、ポート、パスワード、暗号化方式を指定します。どれか1つでも一致しなければ接続に失敗します。
設定の暗号化方式はサーバー側と一致させる必要があります。名前が似たアルゴリズムでも互換性はないため、ノードのパラメータは元の表記を保ってコピーしてください。
- Trojan
-
TrojanはTLSで暗号化接続を確立します。ノード設定には通常、サーバー、ポート、パスワード、証明書のドメイン名を指定します。証明書検証を有効にすると、ドメインと証明書が一致しない場合にハンドシェイクが失敗します。
sniはTLSハンドシェイクで送るサーバー名を指定します。接続先アドレスと異なる場合もありますが、サーバーの構成と証明書設定に合わせる必要があります。
ルールと分岐
ルールは上から順に接続を照合し、ヒットするとトラフィックをプロキシグループ、ノード、または組み込みアクションに渡します。順序、対象名、ルールデータの更新状況が最終的な出口を左右します。
- ルール分岐
-
ルール分岐は、ドメイン、IP、ポート、プロセス、ルールセットなどに基づいて接続先を判断する仕組みです。通常は上から順に確認し、最初にヒットした結果で使用するポリシーが決まります。
広範囲なルールを前に置くと、後ろの精密なルールが永遠にヒットしなくなる場合があります。ルールセットを変更する際は、順序と対象ポリシー名を同時に確認してください。
- Rule Provider
-
Rule Providerは、独立したファイルやリモートアドレスからルールセットを読み込む機能です。メイン設定ではセット名を参照するだけで、ルール内容を指定間隔で個別に更新できます。
ルールセットには正しい動作タイプとデータ形式を指定する必要があります。ダウンロード失敗、パスの誤り、形式不一致があると、該当するルール参照が正常に機能しないことがあります。
- プロキシグループ
-
プロキシグループは複数のノードや他のポリシーを1つの論理的な入口にまとめます。ルールは通常プロキシグループを指定し、ユーザー選択、自動速度測定、障害時切り替え、負荷分散によって出口を決めます。
プロキシグループは他のプロキシグループを参照できますが、名称は完全に一致させる必要があります。循環参照や存在しない名称の参照は設定エラーの原因になります。
- DIRECT
-
DIRECTは組み込みの直接接続ポリシーで、プロキシノードを経由せず現在のデバイスから対象アドレスへアクセスします。LANアドレス、デバイスサービス、ローカル経路に適した接続などで使われます。
直接接続でも、本体のルーティング、ファイアウォール、DNS結果の影響を受けます。DIRECTにヒットしたことは、カーネルが直接接続を選んだことを示すだけで、対象へ到達できるとは限りません。
- REJECT
-
REJECTは接続を拒否する組み込みアクションです。特定のドメイン、アドレス、リクエスト種別のブロックに使われ、プロキシノードを選ぶのではなく、ルール段階で対象トラフィックを終了させます。
拒否ルールが広すぎると、ウェブリソース、アプリのAPI、システムサービスまで影響することがあります。ページの一部が読み込めない場合は、ログで対象リクエストがREJECTにヒットしていないか確認してください。
- GeoIP
-
GeoIPは対象IPの所属地域に基づいて照合し、ローカルの地理情報データベースに依存します。対象IPが判明している接続に適していますが、結果はデータベースの範囲と更新時期に左右されます。
ドメインに対応するサーバーアドレスは、地域、ネットワーク、CDNの制御によって変わることがあります。GeoIPは分岐条件の1つとして使うもので、固定的な住所情報と考えるべきではありません。
- GeoSite
-
GeoSiteは用途、サービス、地域ごとに整理されたドメイン集合です。ルールでカテゴリを指定すれば関連ドメインを一括照合でき、ドメイン末尾を個別管理する手間を減らせます。
GeoSiteとGeoIPでは照合対象が異なります。前者はドメイン、後者はIPを対象にします。データベースが古いと、新しいドメインやカテゴリ変更がすぐに反映されないことがあります。
DNSと名前解決
DNSはドメイン名をアドレスへ変換し、ルールでドメイン情報を利用できるかどうかにも影響します。名前解決の問題を調べる際は、拡張モード、名前解決サーバー、実際の問い合わせ経路をあわせて確認してください。
- DNSリーク
-
DNSリークとは、ドメイン名の問い合わせが想定していたプロキシや暗号化された名前解決経路を迂回し、システム標準DNS、ルーター、その他のDNSサーバーで処理される現象です。ウェブ接続の出口だけでなく、問い合わせが実際にどこへ送られたかを確認します。
システムDNS、ブラウザのセキュアDNS、クライアントのDNS設定、TUNが取り込む範囲をあわせて確認してください。nameserverを1つ変更するだけでは、すべての問い合わせ元をカバーできない場合があります。
- Fake-IP
-
Fake-IPモードでは、カーネルがまず予約アドレスを返し、そのアドレスと元のドメインの対応関係を保持します。アプリがそのアドレスへ接続すると、カーネルはドメイン情報を復元してドメインルールを適用できます。
一部のLAN機器、接続確認、実際のアドレスを必要とするサービスでは、
fake-ip-filterへの追加が必要になることがあります。例外を広げすぎると、ドメインマッピングの効果が弱まります。 - Redir-Host
-
Redir-Hostモードはアプリに実際の名前解決アドレスを返し、ドメインと接続の関連付けを保持しようとします。アドレスの返し方がFake-IPと異なるため、互換性やルール照合の経路も異なります。
実IPを必要とするアプリでは2つの拡張モードを比較できますが、切り替え後はDNSの出口、ドメインルール、ローカルサービス検出を再テストしてください。
- Nameserver
-
Nameserverは通常のドメイン名前解決を担うサーバー一覧です。従来型DNS、DoH、その他の対応アドレスを指定できます。複数サーバーの選択方法は、カーネル設定と問い合わせ結果によって決まります。
暗号化DNSのアドレス自体にドメイン名を使う場合、カーネルはまずそのサーバーのドメイン名を解決する必要があります。導入時の名前解決設定を誤ると、解決不能な依存関係が生じることがあります。
- DoH
-
DoHはDNS over HTTPSの略称で、HTTPS経由でDNS問い合わせを送信します。デバイスと名前解決サーバー間の内容を暗号化できますが、その後のウェブ接続が直接接続になるかプロキシ経由になるかを自動的に決めるものではありません。
ブラウザが独自のDoH設定を使い、システムやクライアントのDNSを迂回することがあります。名前解決経路を調べる際は、ブラウザとOSに追加の入口がないか確認してください。
サブスクリプションと設定ファイル
サブスクリプションは更新可能な設定内容を提供し、ノードはその中の接続定義、上書きはローカル調整を保持する仕組みです。速度測定とTUNは、クライアント利用時によく使われる補助機能です。
- サブスクリプション
-
サブスクリプションはサーバー側が提供し、定期的に更新できる設定またはノードの集合です。クライアントがサブスクリプションURLから内容を取得し、ノード、プロキシグループ、ルールなどの操作項目に解析します。
サブスクリプションを更新すると、以前に直接変更した内容が上書きされることがあります。長期的に保持したいローカルルールやDNS設定は、クライアント対応の上書きまたはマージ設定に入れるのが適しています。
- ノード
-
ノードは単一プロキシサーバーの接続定義で、通常はプロトコル、サーバーアドレス、ポート、認証パラメータを含みます。ノード名は表示用ラベルにすぎず、回線品質や実際の所在地を保証するものではありません。
同じノードを複数のプロキシグループから参照できます。ノード名を変更または削除した場合は、その名前を参照するすべてのプロキシグループも更新する必要があります。
- 遅延
-
遅延は通常、クライアントが指定されたテストアドレスへ接続確認を行った際の応答時間を指します。ノードの到達性や応答速度を大まかに判断できますが、ダウンロード速度や継続的な安定性とは異なります。
クライアントによってテストアドレス、タイムアウト、接続の再利用方法が異なるため、数値をクライアント間で直接比較するのは適切ではありません。単発の結果ではなく、複数回の測定で判断してください。
- TUNモード
-
TUNモードはシステムの仮想ネットワークインターフェースでトラフィックを取り込み、手動プロキシ設定に対応しないアプリもカーネルのルール処理へ渡します。システムプロキシだけを有効にするより広い範囲をカバーできます。
TUNの有効化にはシステム権限が必要な場合があり、他のVPN、仮想NIC、セキュリティソフトとルーティングが競合することもあります。通信できなくなった場合は、デフォルトルート、DNSの乗っ取り、他のネットワークツールの動作を確認してください。
- 上書き
-
上書きは、サブスクリプションの原文を直接変更せずに設定項目を追加、置換、削除する仕組みです。固定ポート、DNS調整、ルール追加、プロキシグループ変更などに使われます。
クライアントによって、上書き、マージ、スクリプト処理の名称や実行順序が異なる場合があります。変更後は上書き部分だけでなく、最終的に生成された設定を確認してください。