Mihomo
Mihomoは、以前Clash Metaの名称で呼ばれていたプロキシコアです。プロトコル接続、ルール照合、DNS処理、通信の転送を担います。一方、GUIクライアントはコアとは別のアプリで、設定管理や操作画面を提供します。互換性を確認する際は、アプリ名だけで判断せず、クライアントのバージョンと実際に動作しているコアのバージョンを確認してください。
コアとクライアントの解説を見る →MIHOMO / GLOSSARY
クライアントの設定やYAMLのフィールドを調べる際にお使いください。まずコア、ノード、プロキシグループの違いを押さえ、ルール、DNS、ルーティングを通じてリクエストが処理される流れを確認しましょう。
このセクションでは、設定を実行する要素と設定の構成、リモートの設定情報をクライアントに取り込む方法を解説します。
Mihomoは、以前Clash Metaの名称で呼ばれていたプロキシコアです。プロトコル接続、ルール照合、DNS処理、通信の転送を担います。一方、GUIクライアントはコアとは別のアプリで、設定管理や操作画面を提供します。互換性を確認する際は、アプリ名だけで判断せず、クライアントのバージョンと実際に動作しているコアのバージョンを確認してください。
コアとクライアントの解説を見る →YAMLはMihomoで使われる設定形式です。インデントで階層を表し、キーと値、リストでフィールドを構成します。インデントにはスペースを使い、真偽値、数値、文字列も各フィールドの要件に合わせる必要があります。編集後に構文エラーが出た場合は、まずエラー行付近のインデント、コロン、引用符を確認してください。構文を解析できても、フィールドの組み合わせが有効とは限りません。
設定ファイルの管理を見る →サブスクリプションURLは、クライアントがノード一覧や設定全体を取得するためのアドレスです。返される内容によってインポート方法が異なります。ノードだけを提供するURLもあれば、プロキシグループ、ルール、DNS設定まで含むものもあるため、URLの見た目だけでは判断できません。サブスクリプションの更新はリモートの内容を再取得する操作で、ノードの問題を解決する万能な方法ではありません。アクセス情報が含まれる場合もあるため、公開スクリーンショットやログへの掲載は避けてください。
サブスクリプションの追加と更新を見る →プロキシプロバイダーはproxy-providersで定義し、ローカルファイルまたはリモートURLから複数のノードを読み込みます。プロキシグループからuseで参照することで、ノードの取得元と振り分け構成を分けて管理できます。プロバイダーの更新後は、プロキシグループから正しく参照されているか確認してください。定義しただけでは、既存ルールの接続先は変わりません。
プロトコルによって、クライアントからサーバーへの接続方法が決まります。プロトコル名だけでは回線品質はわからず、認証やトランスポートに関する設定も別途必要です。
ノードはプロキシ接続先を記述するパラメーターのまとまりです。通常、プロトコル、サーバーアドレス、ポート、認証情報が含まれ、プロトコルによってはトランスポートやTLSの設定も必要です。ノード名は画面や設定で参照するための識別名であり、実際の出口の地域を示すものではありません。接続に失敗した場合は、表示名を変えるだけでなく、ログで認証、名前解決、サーバーへの到達性を確認してください。
Shadowsocksは、指定した暗号化方式とパスワードでプロキシ接続を確立します。Mihomoではtype: ssを指定します。クライアントとサーバーで互換性のある暗号化方式を使う必要があり、方式によってはプラグインの設定も必要です。UDP通信にも対応できますが、実際に利用できるかは両端の対応状況、ノード設定、中継するネットワークによって異なります。プロトコル名だけで判断しないでください。
VLESSはUUIDを使って認証するプロトコルです。プロトコル自体は通信内容を暗号化しないため、通常はTLSやREALITYなどと組み合わせて使います。トランスポート方式、サーバー名、フロー制御などの設定が必要な場合もあり、いずれもサーバー側と一致させる必要があります。サーバーアドレスとUUIDだけではノード設定を完全に再現できないことが多いため、インポート時は提供元のほかの項目も保持してください。
Trojanは通常、TLS接続を通じてプロキシ通信を行い、パスワードで認証します。パスワードが正しくても接続できるとは限らず、証明書の有効性、サーバー名、トランスポート方式もハンドシェイクに影響します。証明書エラーが出たら、まずシステム時刻とノード設定を確認してください。証明書の検証を無効にすると本人確認が弱まるため、恒久的な対処として使うべきではありません。
Hysteria2はQUICベースのプロキシプロトコルで、基盤となる接続にはUDPを使います。設定内の帯域幅は輻輳制御に関するもので、回線速度を保証する値ではありません。利用中のネットワークでUDPが制限されていると、Web通信がTCPでもプロキシ接続を確立できず、通信に失敗することがあります。ネットワークの制限とサーバーの状態を確認してください。
TUICはQUICベースのプロキシプロトコルで、TCPとUDPの通信を転送できます。認証情報、プロトコルバージョン、輻輳制御などの設定をサーバーに合わせてください。ほかのQUICプロトコルの設定をそのまま流用することはできません。テストでは、基盤となるハンドシェイクの失敗と、特定の通信の転送失敗を切り分けます。前者はまずUDPの到達性を確認し、後者はルールと転送設定も確認してください。
WireGuardは、UDPで通信し、公開鍵と秘密鍵で相手を識別するトンネルプロトコルです。Mihomoではアウトバウンドとして設定できます。アドレス、公開鍵、エンドポイント、MTUなどの設定は接続やデータ転送に影響し、秘密鍵は機密情報として扱う必要があります。WireGuardをアウトバウンドに追加しても、システム上のすべての通信が自動的にトンネルを通るわけではありません。実際の経路は通信の取り込み設定と振り分けルールで決まります。
まずリクエストに一致したルールを確認し、次にルールが指定するプロキシグループを確認します。最後に、グループ内で選択されているノードを確認してください。
ルールベースの振り分けは、ルールモードで設定の記述順にリクエストの処理先を決める仕組みです。処理先には、プロキシグループ、個別のプロキシ、DIRECTなどの組み込み方式を指定できます。条件に合うルールが複数ある場合、通常は先に記述されたルールが通信先を決定します。Webサイトが意図しない出口を使う場合は、ノード一覧を何度も切り替えるのではなく、実際に適用されたルールを確認して順序を調整してください。
プロキシグループは複数のノードやほかのグループをまとめ、ルールから参照できる接続先としてproxy-groupsで定義します。主なタイプには、手動選択、自動テスト、フォールバックがあり、タイプによって接続先の選び方が異なります。ルールがグループに一致した後、実際のノードはグループの状態によって決まります。そのため、ルールに表示される名前と現在のノード名が異なる場合があります。
GEOIPは地理データベース上の宛先IPアドレスの所在地に基づいて照合します。Webページの言語や運営会社の登記地を判定するものではありません。データベースの更新が遅れる場合があり、CDNや共有インフラの利用によって直感と異なる結果になることもあります。ドメイン名のリクエストでは名前解決が関係する場合もあり、no-resolveを指定すると、照合のために名前解決するかどうかが変わります。
DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致するルールです。たとえばexample.comを指定すると、そのサブドメインも対象になります。任意の文字列を含むかどうかの照合ではなく、DOMAIN-KEYWORDとは意味が異なります。ルールの適用には、コアが対象のドメイン情報を取得できることも必要です。IPアドレスへの直接アクセスやドメイン情報が紐付いていない通信では、必ず一致するとは限りません。
MATCHは、それ以前のルールに一致しなかったリクエストを処理するためのルールで、通常はルール一覧の末尾に記述します。指定したプロキシグループや処理方式によって、残りの接続先が決まります。すべての通信を自動的にプロキシするルールではありません。前方に置きすぎると後続のルールが適用されないため、新しいルールを追加するときは記述位置を確認してください。
名前解決、通信の取り込み、出口の選択はそれぞれ別の処理です。いずれかのフィールドを変更しても、ほかの処理の設定が自動で置き換わるわけではありません。
TUNモードは仮想ネットワークインターフェースでIPパケットを受け取り、コアに接続を処理させる方式です。システムプロキシ設定に従わない一部のアプリの通信も取り込めます。ただし、実際の対象範囲はシステムのルーティング、プロセスの除外設定、権限、クライアントの実装によって異なります。有効化後にインターネットへ接続できなくなった場合は、TUNを単にプロキシ範囲を広げるスイッチと考えず、ルーティングとDNSのループを確認してください。
TUNとルーティングの設定を見る →Fake-IPは、マッピング用アドレスを使ってドメイン名と接続リクエストを関連付けるDNSの動作モードです。アプリが受け取るアドレスは、Webサイトの実サーバーのものとは限りません。コアはマッピングを使ってドメイン情報を保持し、その後の接続にルールを適用します。実際のアドレスを必要とするアプリでは、フィルター設定が必要になる場合があります。マッピングアドレスが表示されても、名前解決に失敗したとは限りません。実際の接続結果も確認してください。
Fake-IPとフィルター設定を見る →redir-hostはFake-IPのマッピングアドレスではなく、実際に名前解決したIPアドレスをアプリに返します。実アドレスが必要な場面に適しています。上流DNSの正しい設定が必要で、コアが接続とドメイン名を関連付けられることも重要です。モードを切り替えるとキャッシュやアプリの動作が変わる場合があります。比較する際はほかの条件をそろえ、既存の接続とDNSキャッシュも考慮してください。
DNSモードの選び方を見る →nameserverは、Mihomoが通常のドメイン名の名前解決に使う上流DNSサーバーの一覧を指定します。対応する形式で通常のDNSまたは暗号化DNSのアドレスを設定できます。すべてのクエリがこの設定だけを使うわけではありません。ポリシー用、ブートストラップ用、プロキシサーバーのドメイン名解決には別のフィールドが使われることがあります。DNSサーバーを増やせば必ず速くなるとは限りません。各アドレスへの到達性と、想定した経路で問い合わせが行われるかを確認してください。
TUNの設定におけるDNSのリダイレクトとは、条件に合うDNSリクエストをコアのDNSリゾルバーに転送して、名前解決を一元的に処理することです。これはリクエストの取り込み方法を指し、上流DNSの変更と同じ意味ではありません。通常のDNSポートの指定だけでは、アプリ内の暗号化DNSをすべて取り込むことはできません。対象範囲を確認するには、アプリの設定、ルーティング、実際のリクエスト形式も確認してください。
DNSリクエストの取り込みを見る →DNS漏洩とは、想定していないDNSリゾルバーやネットワーク経路を通じてドメイン名が照会され、アクセス先が意図せず知られる可能性のある状態です。ブラウザーのセキュアDNS、システムのリゾルバー、ほかのネットワークサービスが照会に関与する場合もあります。Webサイトへの出口IPだけでは判断できません。まず想定するDNSの経路を明確にし、クエリログと出口を確認してください。DNSリゾルバーが特定の地域にあるというだけでは、漏洩の証拠にはなりません。
DNSのトラブルシューティングを見る →画面上の接続状態、システムプロキシの状態、テスト結果はそれぞれ意味が異なります。個別に確認してください。
GUIクライアントは、設定のインポート、モード切り替え、ノード選択、ログ確認などの画面を提供し、コアの起動や管理も行います。クライアントによって設定の統合方法が異なり、同じ名前のボタンでも生成されるフィールドが異なる場合があります。手順を調べる際は、対象のアプリとプラットフォームを確認してください。設定が最終的にどう動作するかは、コアに渡された実行時の設定で判断します。
プラットフォーム別にクライアントを見る →システムプロキシは、プロキシのアドレスとポートをOSに登録する設定です。通常は、この設定に対応したアプリが利用します。コマンドラインツール、ゲーム、独自のネットワーク処理を行うアプリの一部は自動で使用しないため、スイッチを有効にしてもすべての通信が取り込まれるわけではありません。ブラウザーは使えるのに特定のアプリが使えない場合は、サブスクリプションを変更する前に、アプリのプロキシ設定、環境変数、TUNを確認してください。
接続と確認手順を見る →クライアントの遅延テストでは通常、ノード経由で指定したアドレスに接続し、その所要時間を測定します。ICMP Pingと同じとは限りません。測定値はテスト先、接続の再利用、DNS、ネットワーク状況に左右されるため、異なるクライアントの数値を単純に比較できない場合があります。低遅延でもダウンロード帯域が広いとは限りません。タイムアウトした場合は、ログでテスト先に到達できないのか、プロキシ接続に失敗したのかを確認してください。
速度テストと接続の問題を見る →VpnServiceはAndroidがアプリに提供するVPNサービス用インターフェースです。クライアントはこれを使って仮想ネットワークインターフェースを作成し、通信を受け取れます。システムの許可はアプリが接続を作成できることを示すだけで、リモートのプロキシノードが提供されたり、ノードが利用可能になったりするわけではありません。アプリごとの設定、ほかのVPNアプリ、システムの省電力機能も実際の動作に影響します。バックグラウンドで切断される場合は、それぞれ確認してください。
モバイル版の使い方を見る →