Shadowsocks
一般にSSと略され、暗号化されたプロキシ通信を行います。ノードの設定には通常、サーバーアドレス、ポート、暗号化方式、パスワードが必要です。暗号化方式はサーバーと一致させてください。ノードによっては追加のプラグインも必要なため、アドレスとパスワードをコピーするだけでは接続できないことがあります。設定をインポートできても接続に失敗する場合は、ルールを何度も変更するのではなく、コアが暗号化方式とプラグインに対応しているか確認してください。
設定用語 · 25項目
Clash用語集
プロキシプロトコル、コア、設定項目を分類したインデックスです。まず用語が属するレイヤーを確認し、次にクライアント上の実際の設定を照合してください。同じプロトコル名でも、トランスポート設定やコアの対応範囲が同じとは限りません。
プロキシプロトコル
プロトコルは、クライアントとサーバーがプロキシデータをやり取りする方法を定めます。トランスポート方式、認証、証明書は関連しつつも別の設定レイヤーです。プロトコル名だけで接続性能は判断できません。
VMess
V2Ray系のプロキシプロトコルで、UUIDなどのパラメーターでユーザーを識別し、WebSocketやTLSなどのトランスポート設定と組み合わせて使われることがあります。VMessはプロトコル、WebSocketはトランスポート方式で、互いに置き換えることはできません。古い設定を移行する際は、認証関連の項目、トランスポートのパス、システム時刻を確認してください。コアがプロトコル名を認識できても、過去のすべてのパラメーター構成がそのまま使えるとは限りません。
Trojan
通常はTLS接続でプロキシデータを転送し、パスワードで認証します。サーバーアドレス、ポート、パスワード、TLSサーバー名をあわせて確認してください。接続先のIPアドレスと証明書に対応するドメイン名は異なる場合があります。証明書の検証に失敗した場合は、有効期限、システム時刻、サーバー名を確認します。証明書検証を無効にすると接続先の認証が弱まるため、通常の対処法としては推奨されません。
VLESS
認証と通信の保護を分けて扱うプロキシプロトコルです。プロトコル自体は通信を完全には暗号化しないため、実際の接続ではTLSやREALITYなどを組み合わせるのが一般的です。UUID、トランスポートの種類、サーバー名、flowなどの設定はサーバーと一致させる必要があります。クライアントを選ぶ際はVLESSへの対応だけでなく、ノードが必要とするトランスポートとハンドシェイクの組み合わせをコアがサポートしているかも確認してください。
Hysteria2
QUICベースのプロキシプロトコルで、基盤としてUDPを使います。パケットロスや輻輳の影響を考慮する接続で利用されます。プロトコル名だけでスループットが高くなるわけではありません。UDPの疎通、サーバー負荷、帯域幅の設定が結果に影響します。同じネットワークでTCP系のノードは使えるのにHysteria2がタイムアウトする場合は、まずUDPの経路を確認し、第2世代のプロトコル項目で設定されているか確認してください。
TUIC
QUICベースのプロキシプロトコルで、多重化などの機能を使ってプロキシ接続を処理し、UDP転送に関する動作設定も備えています。クライアントとサーバーでプロトコルのバージョン、認証パラメーター、関連オプションを一致させてください。古い設定例が現在の実装で使えるとは限りません。モバイル回線での使い勝手は、ネットワークの切り替わり、電波状況、バックグラウンド動作の制限にも左右されるため、1回の遅延テストだけで判断しないでください。
コアとクライアント
コアはネットワーク処理を担い、クライアントは画面やOSとの連携を担当します。問題を報告する際は、アプリ名、コア名、実際に適用されている設定を別々に記録すると、互換性に関する認識違いを減らせます。
Clashオリジナルコア
Clashエコシステム初期のルールベースプロキシコアで、設定形式、プロキシグループ、ルーティングの仕組みの基礎となりました。Clash for WindowsなどのGUIアプリとは別のものです。また、オリジナルのオープンソースコアと、過去のPremiumコアの機能範囲も混同しないでください。古いガイドを読む際は、まず対象のフォークを確認し、後発のコアで追加されたプロトコルや設定項目を古い環境にそのまま適用しないようにしましょう。
Clash Meta
mihomoプロジェクトで以前使われていた名称です。そのため、古い記事や設定解説、一部クライアントの名称にMetaが残っています。これはコアの開発系統を示すものであり、Clashを冠するすべてのアプリに共通するバージョン名ではありません。Meta対応と記載された設定を使う場合も、実際のコアのバージョンと使用する設定項目を確認してください。古いコアが現在のmihomoの機能をすべて備えているとは限りません。
mihomoコア
Clash Metaの系譜を受け継ぐルールベースプロキシコアで、プロトコル接続、ルール判定、DNS処理、TUNなどの基盤機能を担います。GUIクライアントから管理することも、対応する環境で単独利用することもできます。アプリの画面とコアの更新は必ずしも連動しません。未知の設定項目や未対応プロトコルの問題を調べる際は、インストーラー名だけでなく、実際に動作しているコアの情報を確認してください。
GUIクライアント
サブスクリプション管理、プロキシグループの選択、ログの確認、システム設定を行うアプリです。Clash Verge Revなどがあります。クライアントはサブスクリプション、画面上の設定、ローカルの上書き設定を組み合わせて実行用設定を作るため、サブスクリプションの元ファイルを編集しても、すぐに動作へ反映されるとは限りません。選ぶ際は、OSとの連携、設定の管理方法、コアとの互換性をあわせて検討してください。違いはクライアント比較をご覧ください。
ルールとルーティング
ルーティングでは、通信がどの条件に一致するか、そして一致後にどの出先を使うかを確認します。ルールデータをダウンロードしただけでは、メインルールから参照されているとは限りません。
ルールベースルーティング
ドメイン名、接続先IPアドレス、プロセスなどの条件に応じて、接続を直接接続、プロキシ、拒否のいずれかに振り分けます。通常、ルールは上から順に照合され、最初に一致した項目で接続先が決まり、末尾のMATCHで残りの接続を処理します。順序を変更する前に、接続ログでどのルールに一致したかを確認し、ルールモードが有効かどうかも確認してください。グローバルモードでは、ルールを変更しても意図した振り分けにならないことがあります。
GeoIPによるIP分類
データベースを使ってIPアドレスを地域などのカテゴリに分類し、接続先アドレスの一括ルーティングに利用します。これはデータベース上の分類結果であり、サーバーの物理的な設置場所やWebサイトを運営する企業を示すとは限りません。ドメイン名が複数地域のCDNアドレスに解決されることもあるため、同じサービスでも一致するルールが変わる場合があります。原因を調べる際は、実際の接続先IPアドレスとデータソースの両方を記録してください。
GeoSiteドメインリスト
サービス、用途、管理者が定めたカテゴリごとにドメインをまとめ、ラベルで複数のドメイン照合条件を参照できるようにします。ラベルの有無や含まれるドメインは実際に読み込んだデータソースによって異なり、すべてのリストで同じ分類が使われているわけではありません。GeoIPとの違いは照合対象です。GeoSiteはドメイン名、GeoIPはIPアドレスを対象とします。IPアドレスしか分からない場合、ドメイン分類が適用されないことがあります。
ルールプロバイダー
ルールセットをメイン設定から分離し、個別に読み込み・更新できる仕組みです。大規模なドメインリストやアドレスリストの管理に適しています。behaviorやformatなどの設定はファイルの内容に合わせ、プロバイダーを定義した後、rules内でRULE-SETを使って参照する必要があります。リストのダウンロードに成功しても、参照名、ポリシー名、ルールの順序が正しくなければ、意図したルーティングにならないことがあります。
プロキシグループ
ノードやほかのプロキシグループで構成される出先の選択肢です。ルールは通常、特定のサーバーではなくグループ名を参照します。selectは手動選択、url-testは指定したテスト結果に応じた選択、fallbackは利用可能性と並び順に基づく切り替えに使います。選択ロジックはグループの種類で決まり、名前は参照用の識別子にすぎません。グループを入れ子にしている場合は、最終的な選択経路をたどって実際の出先を確認し、最上位の名前だけで判断しないようにしてください。
DNSとネットワーク
名前解決の経路と通信の経路をあわせて確認してください。システムプロキシ、アプリ内蔵DNS、仮想ネットワークインターフェースはそれぞれ異なる入口です。いずれか1つを有効にしても、ほかの経路まで自動的にそろうわけではありません。
DNSによる名前解決
ドメイン名をIPアドレスなどのレコードに変換する仕組みで、多くのネットワーク接続に先立って行われます。OS、ブラウザー、プロキシコアはそれぞれ独自のキャッシュを持ち、異なるDNSサーバーを使う場合があります。そのため、システムDNSを変更してもブラウザーの問い合わせ経路が変わるとは限りません。設定時は、接続先Webサイトのドメイン名とプロキシサーバーのドメイン名の解決を区別してください。後者の名前解決に失敗すると、ノード自体が接続できないことがあります。
Fake-IPによる仮想IPマッピング
コアがアプリに仮想IPアドレスを返し、ドメイン名との対応を保存します。アプリが接続を開始すると、対応情報からドメイン名を復元して出先を処理します。仮想IPアドレスは接続先サーバーの実IPアドレスではないため、名前解決結果だけで通信の出先を判断することはできません。実IPアドレスに依存するアプリでは例外設定が必要な場合があります。フィルターリストを変更する前に、問題がマッピングの互換性に起因するのか、ルールやルーティングの誤りなのか確認してください。
TUNモード
仮想ネットワークインターフェースでIP通信を受け取り、一部のシステムプロキシ設定に従わないアプリの通信も処理できます。プロキシプロトコルでも全通信を強制的にプロキシへ送る機能でもありません。取り込まれた接続も、ルールに応じて直接接続またはプロキシに振り分けられます。動作には通常、OSの権限、ルーティング、ネットワーク設定が必要です。ほかのVPNや仮想ネットワークインターフェースと同時に使う場合は、ルートの競合とDNSの取り込み範囲を重点的に確認してください。
DNS漏れ
ドメイン名の問い合わせが想定した経路を通らず、アプリがコアを介さずにシステムのDNSを使うなど、別の経路へ送られる状態です。検査ページに特定のDNSサーバーが表示されても、それだけでプロキシ接続全体の不具合が証明されるわけではありません。期待する設定と照らし合わせて判断してください。原因を調べる際は、ブラウザーの暗号化DNS、システムの名前解決、TUNによる取り込み、IPv6の経路をあわせて確認し、リクエストの発生元ごとに切り分けます。
ノードの遅延
指定されたテスト条件で、クライアントがリクエストを完了するまでにかかった時間です。接続、ハンドシェイク、応答待ちが含まれる場合があり、システムのpingとは測定基準が異なります。遅延が小さくてもダウンロード速度が速いとは限らず、1回のタイムアウトだけでノードが継続的に使えないとも判断できません。比較する際はテスト先、タイムアウト、ネットワーク環境をそろえ、パケットロス、実際の通信速度、接続先サービスの利用状況もあわせて確認してください。
サブスクリプションと設定ファイル
リモートのサブスクリプションが設定の入力元となり、ローカル設定がその組み合わせ方を決めます。コアが実際に読み込むのは、最終的に生成された実行用設定です。更新前に復元できる設定のコピーを保存しておくと、変更点を比較しやすくなります。
サブスクリプション
リンク経由でノードや設定全体を配布・更新する方式です。形式によって、ノードだけを含むものもあれば、プロキシグループ、ルール、DNS設定まで含むものもあります。ブラウザーでリンクを開けても、現在のクライアントに対応した内容とは限りません。返された形式とコアの対応項目を確認してください。サブスクリプションのURLには個人用のアクセス情報が含まれる場合があります。ログやスクリーンショットを共有する際はURL全体を隠し、個人の設定情報が漏れないようにしてください。
ノード
コアが外向きの接続を確立するためのサーバー設定です。通常、プロトコル、アドレス、ポート、認証、トランスポートの情報を含みます。画面に表示されるノード名は識別用のラベルであり、サーバーの所在地、帯域幅、利用可能性を証明するものではありません。ノードが使えるかどうかは、サーバーの稼働状況とローカルのネットワーク経路にも左右されます。インポート後はまず接続を確認し、次にプロキシグループでそのノードが選択されているか確認してください。
YAML設定形式
Clashの設定によく使われる構造化テキスト形式です。インデントで階層を表し、リストとキー・値の組み合わせで設定を記述します。インデントにはスペースを使ってください。階層の誤り、キーの重複、特殊文字の扱いによって、解析に失敗したり意図しない結果になったりすることがあります。構文が正しくても、項目名、データ型、コアの対応範囲を確認する必要があります。ファイルの拡張子が正しくても、内容の形式が正しいとは限りません。
設定のマージと上書き
サブスクリプション、ローカル設定、追加ルールを組み合わせて、最終的な実行用設定を作る処理です。DNS、ルール、ポートなどの個別設定を維持するために使われます。上書きの順序、リストの置き換え、スクリプトの実行タイミングはクライアントによって異なるため、同じ名前の機能がまったく同じ動作をするとは限りません。サブスクリプション更新後に設定が元に戻った場合は、どのレイヤーで変更したかを確認し、生成後の有効な設定を直接調べてください。
ノードプロバイダー
ノードの集合を独立して読み込む仕組みです。ノードの更新を、メイン設定内のプロキシグループやルールとは分けて管理できます。通常、プロキシグループからuseで参照する必要があります。リソースのダウンロードに成功しても、ノードが現在の選択肢に追加されたとは限りません。ルールプロバイダーとは用途が異なります。proxy-providersは出先となるノードを、rule-providersは照合条件を提供するもので、互いに置き換えることはできません。