mihomo
コアとエンジン KernelClash Meta プロジェクトが改称されて続いているコアで、Clash Verge Rev、FlClash、Clash Plusなど主要クライアントに標準搭載されている。プロトコルのハンドシェイク、ルールマッチング、トラフィック転送を担うシステムの心臓部であり、VLESSやHysteria2といった新しいプロトコルを認識できるのもこのコアだけ。クライアントを選ぶときはまずコアがmihomoかどうかを確認しよう。
高頻出用語26語を5分類で整理:コア、プロトコル、ルール、サブスクリプション、DNSの各セクションに分類し、各語2〜4文で意味・使い方・よくある誤解を解説。チュートリアルや対処ガイドで知らない用語に出会ったら、このページで確認できる。
クライアントの内部で動いているもの、トラフィックがどう引き受けられるか──まずはこれらの用語を押さえよう
Clash Meta プロジェクトが改称されて続いているコアで、Clash Verge Rev、FlClash、Clash Plusなど主要クライアントに標準搭載されている。プロトコルのハンドシェイク、ルールマッチング、トラフィック転送を担うシステムの心臓部であり、VLESSやHysteria2といった新しいプロトコルを認識できるのもこのコアだけ。クライアントを選ぶときはまずコアがmihomoかどうかを確認しよう。
初期のクローズドソース版Clashコアで、かつてClash for Windowsの標準エンジンとして使われていた。2023年に元プロジェクトと共に更新が停止し、新しいプロトコルやルールタイプには対応していない。古い設定でPremium専用機能に触れている場合、大抵mihomoに同名または強化版の実装が存在する。
システム内に仮想ネットワークカードを作成し、すべてのネットワークトラフィックをコアに取り込んで処理する動作モード。コマンドラインツールやゲームクライアントなどシステムプロキシを無視するプログラムは、TUNモードでなければ捕捉できない。初回起動時は通常管理者権限やシステムサービスのインストールが必要なので、うまく起動しない場合はまずこの点を確認しよう。
OSのHTTP/SOCKSプロキシ設定をClashのローカルリスニングポート(一般的に7890/7897)に向けるモード。システムプロキシに従うブラウザなどのソフトは自動的にプロキシを経由するが、従わないプログラムは完全に迂回してしまうため、TUNモードや手動でのプロキシ指定で補う必要がある。
コアが公開しているローカルRESTful APIで、設定ではexternal-controllerと記述され、デフォルトでは9090系のポートを監視する。クライアントパネルやWebダッシュボードはこれを通じてノードリストの取得、ポリシーグループの切り替え、接続・ログの確認を行う。パネルが真っ白になったら、まずこのインターフェースが占有されていないか、設定が変更されていないかを確認しよう。
サブスクリプション内に並ぶプロトコル名の正体を、このセクションで一気に理解する
設定ファイルのproxiesセクションにある1件のプロキシサーバー記録で、サーバーアドレス、ポート、プロトコル種別、パスワードなどのフィールドを含み、トラフィック出口の最小単位となる。ノード名の前にある地域表記はサービス提供者が付けた名称にすぎず、実際の所属地は実測で判断すべき。
老舗の暗号化プロキシプロトコルで、構造が単純で伝送オーバーヘッドが小さく、設定にはサーバー、ポート、暗号化方式、パスワードの4要素だけで済む。Clash系クライアントは全面的に対応しており、サブスクリプション内の基本プロトコルとしてよく登場し、安定性の評価も高い。
V2Rayエコシステムのネイティブプロトコルで、UUIDを認証情報として使い、WebSocketやTLSと組み合わせた多層伝送によく使われる。フィールド数はShadowsocksよりかなり多く、基本的にサブスクリプションから自動配布され、手入力だとパラメータが漏れやすい。システム時刻のずれに敏感なので、接続できないときはまず時刻を確認しよう。
プロキシトラフィックを標準的なHTTPSアクセスに偽装するプロトコルで、サーバー側が有効なTLS証明書を持つことに依存し、ハンドシェイクの特徴は通常のウェブサイトとほぼ同じ。設定フィールドが少なく導入も速いため、目立たない伝送が求められる場面でよく使われる。
QUICをベースにした新しいプロトコルで、パケットロスが多い長距離環境でのスループット性能を強みとし、動画視聴で帯域をフルに使うのが得意。この種のノードを認識できるのはmihomoコアのみで、旧版Premiumコアのクライアントでは非対応と表示される。
クライアントがテストアドレス(一般的にGoogleのgenerate_204)にリクエストを送り、ミリ秒単位の所要時間を計測する機能。数値はハンドシェイクの往復時間を反映するもので帯域幅を表すものではない。timeoutと表示されてもノードが使えないとは限らず、テストアドレスがノード側でブロックされているだけの場合もあるので、別のテストURLで再確認しよう。
どのトラフィックをプロキシ経由にし、どれを直接接続にするか──それを決めるのがこのセクションの仕組み
Clashの中核機能:各接続はrulesセクションを上から順に1件ずつマッチングし、命中したらそこで停止し対応するアクションを実行する。順序がそのまま優先度になるため、細かいルールを前に、広範なルールを後ろに置くことで、地域内は直接接続・地域外はプロキシ経由といった精密な制御が実現できる。
最もよく使われるドメイン接尾辞マッチングルール:DOMAIN-SUFFIX,example.com,PROXYと書くと、そのドメインとすべてのサブドメインが命中する。単一ドメインに絞りたい場合はDOMAIN、キーワードでの曖昧マッチにはDOMAIN-KEYWORDを使い、この三兄弟を必要に応じて組み合わせる。
宛先IPの地理データベース上の所属地でマッチングするルールタイプで、代表的な書き方GEOIP,CN,DIRECTは中国本土のIPを一律直接接続にする。データベースはコアと共に配布される独立ファイルで、古すぎると誤判定するため、クライアントの更新に合わせて更新しておこう。
複数のノードを1つの選択可能なグループにまとめる仕組み:selectは手動選択、url-testは最速ノードを自動選択、fallbackは順位に沿ったフェールオーバー、load-balanceはトラフィックを分散する。ルールの出口は通常具体的なノードではなくポリシーグループを指すため、ノードを切り替えてもグループ内の選択を変えるだけでルール自体は一行も書き換える必要がない。
数千件規模のルールを独立したリモートファイルに分割し、メイン設定内で名前を指定して参照する仕組みで、interval設定による定期自動更新にも対応する。大規模な分流方案は基本的にこれで構成されており、メイン設定を数十行までスリム化でき、ルールのメンテナンスにメイン設定を触る必要がなくなる。
ルールリストの最後にある全マッチルールで、それまでのルールに命中しなかったトラフィックはすべてここに落ちる。フォールバック先がPROXYかDIRECTかで、未知のトラフィックのデフォルトの行き先が決まる。原因不明のトラフィックが意図しない出口に流れているときは、まずMATCHの指定先を確認しよう。
ノードはどこから来るのか、設定はどんな形か──このセクションが調達ルートを扱う
サービス提供者が発行する1本のURLで、クライアントが取得すると完全なノードリストと設定が自動生成され、定期更新も可能。大多数のユーザーがノードを取得する標準的な方法であり、サブスクリプションURLはアカウント認証情報に等しいので公開の場に貼らないこと。
Clash設定ファイルが採用しているテキスト形式で、インデントで階層を表し、コロンとスペースでキーと値を区切るため、スペースの扱いに非常に敏感。手動で設定を編集する際にインデントが1つずれたりスペースが足りなかったりすると、ファイル全体の読み込みに失敗する。編集後はYAML検証を一度通してから読み込むと、トラブルシューティングの時間を大幅に節約できる。
他のクライアント形式のノードリンクやサブスクリプションをClashが読み込めるYAMLに変換するサービス・ツールで、既存の分流ルールテンプレートを適用できるものも多い。変換過程ではノード情報が経由するため、自前で構築したインスタンスやコミュニティで評価の分かる実例を優先し、出所不明のオンラインサービスに気軽に投げないこと。
クライアント内で1つの完全な設定を管理する単位で、複数のプロファイルを同時に保存し、ワンクリックで切り替えて有効化できる。サブスクリプションの更新とは、本質的には現在アクティブなプロファイルを更新する行為であり、複数のサービスを使うユーザーはサービスごとにプロファイルを分けておけば互いに干渉せず、問題発生時にどの設定が原因かも特定しやすい。
名前解決がどこを経由するか、漏れがあるか──厄介なトラブルの半分はこのセクションに起因する
プロキシは有効になっているのに、ドメイン名解決リクエストが依然として現地の通信事業者DNSに直接送られてしまう現象で、アクセス意図が漏れてしまう。よくある対処法は、Clash内蔵DNSを有効にしてFake-IPやTUNモードと組み合わせること。オンラインのDNSリーク検査ページで一度チェックすれば、塞げているか確認できる。
Clash DNSの応答モードの1つ:まず198.18.0.0/16の予約セグメントにある仮想IPを返して接続を即座に確立し、実際の解決はルールマッチングの後に行う。メリットは初回パケットが速く、DNSポリューションを自然に回避できること。実IPに依存する一部のプログラムは合わないため、fake-ip-filterで除外できる。
Clash DNSセクションにある2種類の上位サーバー:nameserverは日常的な解決を担い、通常は現地の高速DNSを設定する。fallbackは結果がポリューションされている疑いがあるときに使われ、通常DoH/DoTの暗号化DNSを設定して海外ドメインの解決精度を保証する。両者は役割が異なるので、暗号化DNSを全部nameserverに詰め込んで解決を遅くしないように。
Fake-IPと対をなすDNSモードで、まず実際の解決結果を取得し、そのIPで接続を確立する。互換性は良いが初回パケットが遅く、ポリューションされた結果を受け取りやすいため、新しい設定ではあまり採用されない。古い設定を移行する際に解決系の不調に出会ったら、モードをFake-IPに切り替えると即効性が高いことが多い。
ノードとプロトコルがUDPトラフィックに対応する能力で、音声通話、オンラインゲーム、ビデオ会議は高くこれに依存している。ノードがUDPに対応していない場合の典型症状は、接続はできるが音声が出ない、ゲームでパケットロスが多発するなど。ノード設定でudpフィールドがtrueになっているか確認するか、UDP対応と明記されたノードに切り替えよう。
用語は入口にすぎない。実践するならこの3つを見よう