CLASH / CONCEPT REFERENCE
コア、プロトコル、ルール、DNS、サブスクリプション。設定ファイルに登場する用語の意味を確認し、名前が似ていても役割が異なる設定を区別できます。
初期設定にはClash設定ガイドをご覧ください。プロトコルやコアの機能を比較する場合は、プロトコルリファレンスを参照してください。このページでは用語を解説しており、各クライアントの設定手順を説明するものではありません。
CORE & CLIENT
接続を処理するコアと、操作画面を提供するアプリを区別しましょう。
Clashエコシステム初期のルールベースプロキシコアです。接続の確立、DNS処理、ルール判定を担い、GUIは通常、別のプロジェクトが提供します。オープンソース版と後発のMeta、mihomoでは、対応プロトコルやフィールドが異なります。古いガイドの機能をすべての派生版にそのまま当てはめることはできません。設定が使えるか判断するには、クライアント名にClashが含まれているかだけでなく、コアの種類を確認してください。
関連：Clash Meta →Clashをベースにプロキシプロトコル、ルール、ネットワーク機能を拡張したコアの系統で、後にmihomoとして開発が続いています。古い設定ガイドや配布パッケージ、クライアント画面にはMetaの表記が残っている場合があります。通常はコアの系統を指し、特定のデスクトップアプリを意味するものではありません。Metaとだけ記された機能の対応状況は、実際のコアのバージョンも確認してください。
関連：mihomo →Clash Metaから発展したルールベースプロキシコアで、多様なプロキシプロトコル、ルールセット、DNS機能に対応します。GUIクライアントから利用できるほか、サーバーやルーター上で単独実行することもできます。クライアントのバージョンとコアのバージョンは一致しない場合があります。設定が有効になるかどうかは、実際に動作しているコアのバージョンとビルドの対応機能で判断してください。
プロトコルとコアのリファレンスを見る →サブスクリプションの読み込み、ポリシー選択、ログ表示、システム連携などの操作画面を提供するアプリです。Clash Verge Revなどがあります。操作をまとめるのがクライアント、接続を処理するのがコアです。同じコアでもクライアントによって設定画面の場所が異なります。また、クライアントが生成する上書き設定によって、実際に適用される内容がサブスクリプションの原文と異なる場合があります。
クライアントを比較する →OSのプロキシ設定を利用し、その設定に従うアプリをローカルのHTTPまたはSOCKSプロキシポートに接続します。一部のゲーム、コマンドラインツール、独自のネットワークスタックを使うアプリは、システムプロキシを無視する場合があります。そのため、設定をオンにしてもすべての接続が取り込まれるとは限りません。オフにしてもTUNなどの取り込み機能が動作している場合があるため、個別に状態を確認してください。
比較：TUNモード →PROXY PROTOCOLS
プロトコル名だけでは不十分です。認証、通信方式、TLSの条件も一致させる必要があります。
暗号化プロキシプロトコルの一つです。ノードの設定には通常、サーバー、ポート、暗号化方式、パスワードが含まれます。クライアントとサーバーの双方が同じ暗号化方式に対応している必要があり、新旧の方式は名前を変えるだけでは移行できません。読み込み後に接続できない場合は、まず方式と認証情報を確認し、次にUDP転送や追加機能が使用中のコアに対応しているか確認してください。
プロトコルの選び方を見る →V2Rayエコシステムのプロキシプロトコルです。通常はUUIDでユーザーを識別し、接続時にはシステム時刻も正確である必要があります。VMessとWebSocketなどの通信方式は別の層に属するため、読み込み時にはプロトコルの識別情報と通信設定の両方を保持してください。サーバーに到達できてもハンドシェイクに失敗する場合は、ノード名を変えるのではなく、システム時刻、UUID、パス、TLS設定を確認してください。
比較：VLESS →通常、TLS接続上でパスワード認証を使うプロキシプロトコルです。サーバー証明書とサーバー名も接続条件の一部です。アドレス、ポート、パスワードだけをコピーすると、SNIなどの必要な設定が抜けることがあります。証明書エラーが発生したら、まずドメイン名、システム時刻、証明書の信頼チェーンを確認してください。証明書検証の無効化を一般的な解決策として使うのは避けましょう。
関連：ノードの設定項目 →UUIDで識別する軽量なプロキシプロトコルです。プロトコル自体に通信内容の暗号化機能はなく、接続の安全性は通常TLSやREALITYなどの仕組みに依存します。VLESSが特定の通信方式を指すわけではなく、同じ名前のノードでも構成は異なる場合があります。クライアントを選ぶ際は、通信方式、セキュリティ機能、関連する拡張設定にコアが対応しているか確認してください。
プロトコルの互換性を確認する →QUICベースのプロキシプロトコルです。接続には下位層のUDP通信が必要なため、UDPが制限されたネットワークでは正常に動作しないことがあります。実際の速度は、パケットロス、輻輳、サーバーのリソース、端末の性能によって変わります。プロトコル名だけで速度を予測することはできません。Hysteriaの第1世代と第2世代は設定をそのまま置き換えられないため、読み込み時に世代を確認してください。
比較：TUIC →QUICベースのプロキシプロトコルで、TCPとUDPの通信を運べます。下位ネットワークで対応するUDP通信が許可されている必要があります。Hysteria2とは別のプロトコルで、認証項目、接続動作、輻輳制御の設定を相互に流用することはできません。接続前にサーバー側のプロトコルバージョン、認証情報、TLS設定を確認し、現在のネットワークやモバイル端末での動作も確認してください。
関連：遅延と実際の使い心地 →RULES & POLICIES
マッチ条件で使用するポリシーが決まり、そのポリシーが実際の接続先を決めます。
ドメイン、宛先アドレス、プロセスなどの条件に応じて、直接接続、プロキシ、拒否などの処理を選びます。ルールモードでは通常、リストの上から順に判定され、最初に一致したルールが適用されます。そのため、具体的な条件を広範な条件より前に置いてください。グローバルモードや直接接続モードに切り替えた後は、元のルール判定を前提に接続動作を予測できません。
ルール振り分けの実践ガイドを見る →ノードやほかのポリシーを論理上の出口としてまとめ、ルールから名前で参照できるようにします。selectは手動選択、url-testは自動テスト、fallbackはフェイルオーバーを主な用途とします。実際の動作はグループ設定によって異なります。ルールがグループを指定しても、グループ内のすべてのノードが同時に通信を処理するわけではありません。
IPアドレスの地域データベースに基づいて判定する仕組みです。例：GEOIP,CN,DIRECT。データベース上のアドレスの地域は、サービス運営者やユーザーの所在地を示すものではありません。CDNの利用により、同じドメインでも異なる地域のアドレスが返る場合があります。DNSの応答、データベースの更新、ルールの順序が判定結果に影響します。no-resolveを指定する場合は、名前解決を省略する影響も把握してください。
マッチ条件をローカルまたはリモートのファイルにまとめ、rule-providersで定義し、RULE-SETルールから参照します。ドメインやアドレスなどの条件を提供するもので、プロキシノードを提供するものではありません。ルールセットの形式、behaviorの種類、更新方法、コアの対応状況を一致させる必要があります。ファイルをダウンロードできても、ルールが正しく判定に使われているとは限りません。
それまでのルールに一致しなかった通信を受け取る最後のマッチルールです。通常はrulesリストの末尾に置きます。MATCH,PROXYは、残りの通信をPROXYという名前のポリシーに渡すことを意味します。ポリシー名が設定内に存在する必要があります。MATCHを先頭に置くと、通常は後続のルールが判定されません。また、クライアントをグローバルモードに切り替える設定とは異なります。
DNS & NETWORK STACK
通信の取り込み、ドメイン名の解決、出口の選択はそれぞれ異なる処理です。個別に確認してください。
ドメイン名をIPアドレスなどのレコードに変換するシステムです。アプリ、OS、プロキシコアがそれぞれこの処理に関わる場合があります。接続先サイトの名前解決とプロキシサーバーのドメインの名前解決では、経路が異なることがあります。暗号化DNSを使っていても、リクエストが必ずプロキシ経由になるわけではありません。接続に失敗した場合は、誰がどのリゾルバーに問い合わせているか、応答がキャッシュされていないかを確認してください。
関連：Fake-IP →コアがアプリに予約済みアドレスを返し、内部でそのアドレスとドメイン名の対応を管理します。後続の接続では、この対応関係から接続先のドメイン名を復元します。これは接続先サーバーの実際のグローバルIPアドレスではなく、サービスが移転したことを意味するものでもありません。実際の名前解決結果を必要とするアプリでは、必要に応じてfake-ip-filterを設定してください。フィルターモードやほかのDNSルールも確認し、問題をすべてマッピングの仕組みに結び付けないようにしましょう。
仮想ネットワークインターフェースとルーティング設定を使ってIP通信を取り込み、システムプロキシに従わない接続にも対応できます。TUNは通信を取り込む方式であり、ノードのプロトコルではありません。取り込んだすべての通信がプロキシ経由になるわけでもありません。有効にする前に権限、ルート、DNSの取り込み設定を確認してください。ほかのVPNと同時に使う場合は、ルートの競合やLANへの接続可否も確認が必要です。
比較：システムプロキシ →対応する接続の初期データからドメイン名の手がかりを検出し、コアによるドメインルールの判定を補助します。HTTPSの内容を自由に復号する機能ではなく、検出できるかどうかはプロトコル、暗号化方式、参照可能なハンドシェイク情報によって異なります。接続先として使う情報を調整できる設定もあります。有効化後に互換性の問題が起きた場合は、ログと関連する上書き設定を確認してください。
関連：ドメインルールによる振り分け →DNSリクエストが想定していた名前解決経路から外れる現象です。たとえば、コアで処理する予定のリクエストが、アプリから別のリゾルバーへ直接送信される場合があります。漏れに当たるかどうかは、設定したポリシーに照らして判断してください。テストページに特定の地域名が表示されたことだけでは判断できません。アプリ独自のDNS、ブラウザーの暗号化DNS、IPv6、システムリゾルバー、実際のリクエスト経路を確認し、名前解決結果と通信経路を区別してください。
戻る：DNSの名前解決を担う要素 →SUBSCRIPTION & CONFIG
まず読み込むデータの形式を確認し、次にノード、ポリシー、ルールの参照関係を確認してください。
URLを使ってノード情報や設定ファイルを取得・更新する配信方式です。内容には完全なYAMLが含まれる場合も、ノード一覧のみの場合もあります。形式に応じたクライアントの読み込み画面、または信頼できる変換方法を使ってください。読み込みに成功しても、すべてのプロトコルやルールが対応しているとは限りません。サブスクリプションURLにアクセス認証情報が含まれることがあります。ログやスクリーンショットを共有する前に、URLの機密部分を削除してください。
サブスクリプションの読み込み手順を見る →プロキシ接続に使う設定のまとまりで、通常はサーバーアドレス、ポート、プロトコル、認証情報が含まれます。プロトコルによっては通信方式やTLSの設定も必要です。ノード名は表示用のラベルにすぎず、名前に含まれる地域や用途は、実際の出口や接続テストの代わりにはなりません。ノードの利用可否はサーバーの状態、認証情報の有効性、ローカルのネットワーク経路にも左右され、クライアントをインストールしただけで保証されるものではありません。
関連：プロキシグループ →クライアントが指定したテスト先にリクエストを送り、応答までにかかった時間です。接続確立、ハンドシェイク、応答などが含まれる場合があり、必ずしもICMP pingとは限りません。テスト先、タイムアウト設定、ネットワーク状態によって結果が変わるため、遅延の数値をダウンロード速度に換算することはできません。テストがタイムアウトしてもノードが完全に使えないとは限らないため、実際の通信や実行ログも確認してください。
ログから原因を特定する方法を見る →Clashの設定でよく使われる構造化テキスト形式です。インデントで階層を表し、リストとキー・値の組み合わせでノード、ルール、DNS設定を記述します。編集時はスペースでインデントをそろえ、タブが混入しないようにしてください。特殊文字を引用符で囲む必要があるかも確認しましょう。YAMLの構文が正しくても、ファイルを解析できることを示すだけです。フィールドが対応しているか、ポリシー名が存在するかは、使用中のコアで確認する必要があります。
関連：ルールセットの設定項目 →ノード群を個別に読み込み、更新する仕組みです。リモートまたはローカルのデータを使い、プロキシグループからuseで参照できます。マッチ条件を提供するrule-providersとは役割が異なり、ノード群をメイン設定全体の代わりに使えるわけではありません。データ形式、プロバイダー名、更新設定を確認し、リモート更新によって手作業で管理しているメイン設定の内容が上書きされないようにしてください。