クライアント
クライアントは操作画面として捉えましょう。サブスクリプションの追加、ポリシーの切り替え、ログの確認、システムプロキシの有効化などは、通常クライアントの画面で行います。設定の読み込みや通信の転送はコアが担当するため、同じコアを複数の画面から利用できます。手順にあるスイッチを探すときは、まずクライアント名を確認してください。画面構成が違っても、同じ機能がないとは限りません。
用語を確認する／設定と照合する
Clash用語集
まず通信がどのようにコアへ入るかを確認し、次にルールによる出口の選択を見ていきます。分類別に用語を調べ、設定項目とクライアント画面を照らし合わせましょう。
コアとクライアント
画面、コア、通信の取り込み方を区別する
画面から設定を読み込めても、コアがすべての項目に対応しているとは限りません。トラブルの確認を始める前に、クライアント名、実際に使われているコア、通信がコアへ入る方法を確認しましょう。
mihomoコア
mihomoはネットワーク通信を処理するコアプログラムです。設定を読み込み、DNSを解決し、ルールを判定してから、直接接続またはプロキシ接続を確立します。Clash Metaの技術系譜を受け継ぎ、GUIクライアントから呼び出すほか、単独でも実行できます。未対応の項目や認識できないプロトコルがある場合は、クライアントの更新日だけでなく、実際に動作しているコアを確認しましょう。
Clash Meta
古いドキュメントでClash Metaとあれば、通常はClashエコシステムのコア派生版を指し、その歴史的な名称は現在のmihomoにつながっています。一部のクライアント、サブスクリプション形式、解説記事では、今もMetaという表記が使われていますが、同じアプリだとは限りません。古い設定を読む際は、現行コアのドキュメントで項目の意味を確認してください。特にDNS、TUN、新しいプロトコルのパラメーターには違いがある場合があります。
システムプロキシ
システムプロキシを有効にすると、OSのプロキシ設定がクライアントのローカル待ち受けアドレスとポートを参照します。この設定に従うブラウザーやアプリは通信を渡しますが、独自に通信するプログラム、一部のターミナルツールやゲームは利用しない場合があります。ブラウザーは使えるのに他のアプリが接続できない場合は、まずそのアプリがプロキシ設定に対応しているか確認し、必要に応じてTUNによる取り込みを検討しましょう。
遅延
遅延は特定のテストにかかった時間であり、ノードの速度評価そのものではありません。テスト先、接続方法、タイムアウト値、その時点のネットワーク混雑によって結果は変わります。クライアントごとの数値を単純に比較できない場合もあります。遅延が小さくても、帯域が狭かったりパケットロスが発生したりすることがあります。実際の利用では、接続先サイト、継続的な通信速度、安定性も確認しましょう。
プロキシプロトコル
プロトコルと転送パラメーターを確認する
プロトコル名は接続設定の一部にすぎません。認証情報、転送方式、TLS、サーバー側のパラメーターを合わせて確認しましょう。ノード名だけでは互換性を判断できません。
Shadowsocks
暗号方式と認証情報を使って接続するプロキシプロトコルです。一般的な設定にはサーバーアドレス、ポート、暗号方式、パスワードが含まれます。クライアントとサーバーが同じ暗号方式に対応している必要があり、プロトコル名が一致するだけでは不十分です。サブスクリプションを読み込めても接続できない場合は、暗号方式とパラメーターが正しいか確認し、現在のコアが設定の拡張機能に対応しているかも調べましょう。
VMess
ユーザーIDなどのパラメーターで認証するプロキシプロトコルです。接続にはWebSocket、gRPC、TLSなどの転送設定を組み合わせる場合もあります。ユーザーIDが正しくても、パスやホスト名が一致しなければ接続できないことがあります。サブスクリプションの変換後に特定のノードだけ使えなくなった場合は、サーバーアドレスだけでなく、関連する項目が保持されているか確認しましょう。
VLESS
軽量なプロキシプロトコルで、実際の運用ではTLSやREALITYなどと組み合わせて通信を保護するのが一般的です。設定のユーザーID、転送方式、場合によってはflowの値をサーバー側と一致させる必要があります。VMessと同じくユーザーIDを使うからといって、プロトコルの種類をそのまま置き換えることはできません。互換性に問題がある場合は、一連のパラメーターとコアの対応状況を確認してください。
Trojan
通常はTLSで通信し、パスワードで認証するプロキシプロトコルです。証明書とサーバー名も接続時の重要な条件です。アドレスとパスワードが正しくても、端末の時刻がずれていたり、証明書が期限切れだったり、サーバー名が一致しなかったりすると接続できない場合があります。TLSエラーが出たときは、まず時刻と名前の設定を確認し、証明書の検証を無効にして問題を回避しないでください。
Hysteria 2
QUICベースのプロキシプロトコルで、下位層にUDPを使用します。そのため、利用するネットワークで該当するUDP通信が許可されているかが接続可否に直結します。初期のHysteriaと設定がそのまま同等とは限らないため、読み込み時にプロトコルの種類と認証項目を確認しましょう。あるネットワークでは使えるのに別のネットワークでタイムアウトする場合は、サーバーだけでなくUDPの制限や帯域設定も確認してください。
ルールとルーティング
マッチ順から出口を確認する
まず通信がコアに取り込まれていることを確認し、次にどのルールに一致したかを調べましょう。以下の構文にあるPROXYはポリシー名の例です。実際に使う場合は、設定内に同じ名前が存在する必要があります。
ルーティングルール
ルールモードでは、コアが設定された順序で接続を確認し、通常は最初に一致したルールで使用する出口が決まります。ルールはドメイン、接続先IP、その他の条件で通信を振り分けられますが、もともとコアに入っていないリクエストは取り込めません。ルーティングを変更する前に、接続の詳細で一致したルールを確認してから該当項目を修正しましょう。サイトが開くかどうかだけで、ルールの有効性を判断しないでください。
DOMAIN-SUFFIX
指定したドメインとそのサブドメインに一致します。たとえばDOMAIN-SUFFIX,github.com,PROXYは、github.comとそのサブドメインを対象にします。照合するのはドメインの末尾で、URL全体やページのパスは確認しません。ルールにはプロトコル部分やスラッシュを含めず、先に一致する範囲の広いルールより前に配置してください。
GeoIP
IPアドレスの地理情報データベースを使って接続先の地域を判定します。たとえばGEOIP,CN,DIRECTは、該当する地域として登録されたアドレスを直接接続にします。データベース上の地域はサイト運営者の所在地とは限らず、CDNやIPアドレス情報の更新によって判定が変わる場合があります。ルールによってはドメインの名前解決も関わります。同じドメインの出口が変わる場合は、名前解決の結果、データベース、ルールの順序をあわせて確認しましょう。
MATCH
ルールの末尾に置き、それ以前のルールに一致しなかった通信を処理します。例：MATCH,PROXY。ドメインやIPの条件はなく、早い位置に置くと後続のルールは通常マッチしません。フォールバック先は用途に合わせて選びましょう。ポリシーをプロキシにしても、すでに直接接続のルールに一致した通信までプロキシ経由になるわけではありません。
ポリシーグループ
複数のノードやポリシーを名前付きのグループにまとめると、ルールから単一のサーバーではなくグループ名を参照できます。代表的な種類には、手動選択、自動テスト、フォールバックがあり、それぞれ切り替えの仕組みが異なります。ルールが正しいグループに一致しているのに出口が想定と違う場合は、同じルールを追加するのではなく、グループ内の選択状態やネスト構造を確認しましょう。
DNSとネットワーク
名前解決の経路と接続の経路を区別する
ドメイン名からアドレスを取得する処理と、その後の接続が端末からどの経路へ出るかは、関連していますが別の問題です。調査では、リゾルバー、名前解決の結果、接続の出口をそれぞれ記録しましょう。
DNS
DNSはドメイン名を問い合わせ、IPアドレスなどのレコードを取得する仕組みです。アプリは通常、名前解決の結果を得てから接続を開始します。OS、ブラウザー、コアのいずれも名前解決に関わる可能性があるため、クライアントのDNS設定を変更しても、すべてのアプリに反映されるとは限りません。ドメインに接続できない場合は、まずリクエストが実際にどのリゾルバーへ送られたかを確認し、名前解決の失敗と、アドレス取得後の接続失敗を切り分けましょう。
Fake-IP
このDNS方式を有効にすると、コアはアプリに合成アドレスを返し、そのアドレスと元のドメイン名との対応を保持します。後続の通信がコアに戻ると、対応情報からドメイン名を特定して設定に沿って処理できます。合成アドレスはプロキシサーバーのアドレスではありません。実際の名前解決結果に依存する一部のアプリで問題が起きた場合は、フィルターリストを確認しましょう。DNS設定全体をすぐに書き換える必要はありません。
TUNモード
仮想ネットワークインターフェースとルーティング設定を使い、取り込み対象のIP通信をコアへ送る方式です。システムプロキシに従わないアプリでも利用できる場合があります。通常はシステム権限が必要で、他のVPN、仮想ネットワークインターフェース、ルーティング設定と競合することもあります。TUNが変えるのは通信をコアへ入れる方法です。その後は現在のモードとルールに従って出口が決まり、すべての通信がプロキシ経由になるわけではありません。
DNSリーク
指定した名前解決の経路を通るはずの問い合わせが別の経路から送信され、問い合わせ情報が露出すると、一般にDNSリークと呼ばれます。検査ページに特定の事業者名や地域が表示されても、それだけでリークとは断定できません。リゾルバーの所在地と接続の出口は異なる場合があるためです。まず、どのリクエストをどの経路に通したいのかを明確にし、ブラウザーのセキュアDNS、システムの名前解決、コアの設定が一致しているか確認しましょう。
DNSリダイレクト設定
クライアント設定では、通常、条件に合うDNSリクエストをコアの名前解決モジュールへ転送することを指し、ネットワーク攻撃を意味するものではありません。TUN設定のdns-hijackは、このような通信の取り込みに使えますが、実際の対象範囲はプラットフォーム、ルーティング、リクエスト方式によって異なります。アプリが独自に使う暗号化DNSは同じように取り込めない場合があります。アプリの設定や接続ログもあわせて確認してください。
サブスクリプションと設定ファイル
ノード情報と設定全体を区別する
ファイルをダウンロードできても、そのまま実行できるとは限りません。まず、サブスクリプションがノード一覧を提供しているのか、設定全体を提供しているのかを確認し、項目、参照関係、更新方法を調べましょう。
サブスクリプション
サブスクリプションは、ノードや設定全体を取得・更新するためのリモートコンテンツの取得元で、特定のファイル形式を指すものではありません。返される内容はYAML、Base64でエンコードされたノード一覧、複数のURIなどさまざまです。直接読み込めるかどうかはクライアントの対応状況によります。サブスクリプションURLにはアクセス情報が含まれることが多いため、アカウント情報と同様に管理してください。トラブルの確認時も、URL全体を公開ログやスクリーンショット、オンライン変換サイトに貼り付けないでください。
ノード
ノードはプロキシサーバーへの接続に必要なパラメーター一式で、通常はプロトコル、サーバーアドレス、ポート、認証情報、転送設定を含みます。一覧に表示される名前は主に識別用であり、実際のサーバー所在地、回線品質、帯域を示すものではありません。ノードが使えない場合は、まず同じ設定の別のノードを試し、個別の接続パラメーターの問題か、端末側の通信取り込みや基本ネットワークの問題かを切り分けましょう。
YAML
Clash設定でよく使われる構造化テキスト形式です。スペースによるインデントで階層を表し、リストやキーと値の組み合わせでデータを記述します。編集時はインデントを統一し、タブを使わず、コロンの後のスペースや特殊文字にも注意してください。YAMLの構文に合っていることは、解析できるという意味にすぎません。項目が有効か、ポリシー名が存在するかは、さらにコアで確認する必要があります。
proxy-providers
この設定項目を使ってノード一覧をメイン設定から分けて管理し、指定した取得元からノード情報を読み込んだり更新したりできます。参照可能なノードの取得元を定義するもので、通常はポリシーグループ内でuseなどの項目から参照する必要があります。ダウンロードできてもグループにノードが表示されない場合は、参照名、データ形式、フィルター条件を確認してください。ノード一覧のファイルを設定全体として実行しないでください。
rule-providers
外部ルールセットを宣言し、ルール一覧からRULE-SETで参照します。ドメインやアドレスのルールを独立して更新できるため、長いルール一覧の管理に便利です。ルールセットの内容と形式は宣言に合わせ、参照時には有効なポリシーを指定する必要があります。セット内のルールが正しくても、参照位置が後ろすぎると適用されない場合があります。更新ログとメインルールのマッチ順をあわせて確認しましょう。