Shadowsocks(SS)
比較的シンプルな構成の暗号化プロキシプロトコルです。ノードには通常、サーバーアドレス、ポート、パスワード、暗号化方式が含まれ、どれか1つでも一致しないと接続に失敗します。対応する暗号化方式はコアによって異なるため、設定を移行する前に対応範囲を確認してください。
まず用語がプロトコル、ルール、設定、コア、名前解決のどれに属するかを確認し、接続確立、トラフィック経路、クライアント操作のどこに影響するかを判断します。ここでは主要な名称と混同しやすい適用範囲をまとめています。
「クライアント」は操作画面、「コア」は実際の接続処理を担当します。「サブスクリプション」は設定の取得元で、「ノード」は接続パラメータの一種にすぎません。「プロキシグループ」が候補経路を決め、「ルール」が各接続をどのポリシーへ送るかを決めます。接続トラブルでは、この階層に沿って順番に確認すると、ノードを何度も切り替えるより原因を特定しやすくなります。
プロトコル名は接続方式を示すだけで、速度や安定性を直接保証するものではありません。実際の挙動は、サーバー側の実装、ネットワーク経路、TLSパラメータ、クライアントのコアバージョン、DNS設定にも左右されます。プロトコルとコアの違いを詳しく比較する場合は、プロトコルとコアの技術リファレンスをご覧ください。
プロトコルは、クライアントとサーバーが接続を確立し、認証し、データを転送する方法を決めます。選択前に、サブスクリプションで提供されるプロトコルが現在のコアで認識できるか確認してください。
比較的シンプルな構成の暗号化プロキシプロトコルです。ノードには通常、サーバーアドレス、ポート、パスワード、暗号化方式が含まれ、どれか1つでも一致しないと接続に失敗します。対応する暗号化方式はコアによって異なるため、設定を移行する前に対応範囲を確認してください。
V2Rayエコシステムのプロトコルです。一般的な設定にはユーザーID、トランスポート方式、TLS、ホスト名、パスなどが含まれます。同じVMessノードでも、トランスポートの組み合わせが異なる場合があります。インポートに失敗したときは、プロトコル項目だけでなくWebSocketやgRPCなど外側のトランスポートパラメータも確認してください。
TLS接続を利用するプロキシプロトコルです。一般的な設定にはサーバーアドレス、ポート、パスワード、ドメイン、証明書関連の項目が含まれます。ドメイン、SNI、証明書検証の設定は一致させる必要があります。証明書検証を無効にするだけでは、アドレス、ポート、パスワードの誤りは解決できません。
軽量なプロトコルで、安全性は通常TLSやRealityなどの外側の機構によって確保されます。インポート時はVLESSという名称だけで判断せず、トランスポート方式、フロー制御、サーバー名、公 ключなどの追加パラメータも確認してください。旧版のClashコアでは一部の拡張フィールドを認識できない場合があります。
QUICをベースとするプロトコルで、遅延が大きい、または変動しやすいネットワーク向けです。基盤トランスポートにUDPを使用するため、ネットワーク、ファイアウォール、サーバー側で対応する通信を許可する必要があります。利用前に、クライアントがHysteria2対応のmihomoまたは互換コアを使用しているか確認してください。
QUICベースのプロキシプロトコルです。設定には通常、ユーザー認証情報、輻輳制御、TLSパラメータが含まれます。Wi-Fiとモバイル回線を切り替えた際の復旧速度は、コアの実装とサーバー設定によって異なります。同じプロトコル名でも、クライアント間で機能項目が完全に一致するとは限りません。
ルールは接続先を判定し、プロキシグループは選択可能な経路を提供します。振り分けミスを調べるときは、まずルールが一致したか、次に一致したプロキシグループで何が選択されているかを確認します。
ドメイン、IPアドレス、ポート、プロセス、ルールセットに応じて、接続を異なるポリシーへ振り分けます。通常は上から順に照合し、最初に一致した後は後続項目を確認しません。範囲の広いルールを早い位置に置くと、後の詳細なルールが適用されないことがあります。
複数のノードや他のポリシーで構成される選択単位です。一般的な種類には手動選択、自動検出、障害時の切り替えがありますが、名称は設定作成者が決めます。ルールは通常プロキシグループ名を参照するため、名前を変更した場合は関連ルールも修正してください。
プロキシノードを経由せず、接続先へ直接アクセスすることを示します。LANアドレス、システムサービス、明示的に指定した直結ドメインなどで使用されます。DIRECTに一致しても接続成功が保証されるわけではなく、宛先アドレス、DNS結果、ローカルネットワークの影響を受けます。
条件に一致する接続を拒否し、プロキシノードや直結経路へ渡さないことを示します。アクセス不要と確認されたドメインやリクエストの処理に適しています。ルール範囲が広すぎるとアプリに必要なAPIまで遮断する可能性があるため、変更後はログの一致記録を確認してください。
IPアドレス範囲を地域やネットワーク種別に対応付けたデータセットです。GeoIPルールは宛先IPを処理するため、DNSの解決先やデータベースの更新時期に影響されます。データベースの欠落、パスの誤り、未対応のカテゴリ名があると、ルールを読み込めない場合があります。
サイトのカテゴリ別に整理されたドメインルールの集合で、大量のドメインを手作業で管理する負担を減らせます。利用可能なカテゴリはデータファイルの内容とコアの対応状況によって異なります。カテゴリの更新で既存のルール名が変わる場合もあるため、データを更新する際は読み込みログも確認してください。
サブスクリプションは設定の取得を担い、設定ファイルはクライアントの動作を定義します。サブスクリプションを更新できても設定の互換性が保証されるわけではなく、読み込み結果は現在のクライアントとコアで確認する必要があります。
サービス提供者が公開するリモート設定の入口です。クライアントはサブスクリプションURLからノード、プロキシグループ、完全な設定を取得します。更新時にはリモート内容を再読み込みするため、手動変更部分が上書きされることがあります。ルールを調整する前に、クライアントが設定を上書きするのか完全に置き換えるのか確認してください。
クライアントがプロキシ接続を確立するためのサーバーパラメータ一式です。プロトコル、アドレス、ポート、認証情報、トランスポート項目によって利用可否が決まります。ノードの遅延テストに成功しても、すべての宛先やプロトコルが正常に動作するとは限りません。
外部ファイルやリモートURLからノード一覧を読み込むための設定機構です。1つのProviderを複数のプロキシグループで再利用でき、指定間隔で更新できます。Providerのダウンロードに成功してもプロキシグループが空の場合は、フィルター条件、ノード形式、参照名を確認してください。
Clashでよく使われる構造化テキスト形式で、インデント、階層、記号に敏感です。リスト項目は通常ハイフンで始まり、キーと値は正しく区切る必要があります。Tab文字、全角記号、不統一な空白階層は解析エラーの原因になります。
ポート、ノード、プロキシグループ、ルール、DNS、実行オプションを記述する完全なファイルです。同じYAMLファイルでも、コアが異なれば互換性の結果が完全に一致しない場合があります。インポート前に現在動作している設定を保存し、新しいファイルが正常に読み込まれたことをクライアントログで確認してください。
GUIは操作を担い、コアは処理を実行します。似た名前のクライアントでも、コアのバージョン、設定拡張、システムへの取り込み方式が完全に同じとは限りません。
プロトコル接続、ルール照合、DNS処理、トラフィック転送を担う中核プログラムです。GUIクライアントは通常、コアの外側にサブスクリプション管理、プロキシグループ選択、ログ画面を提供します。プロトコルが利用できるか判断するときは、入力欄の有無ではなくコアの対応能力を確認してください。
Clash Metaから発展したコアプロジェクトで、多くのプロトコル、ルール、DNS機能に対応します。クライアントによって内蔵バージョンや更新ペースが異なる場合があります。設定を移行する際は、拡張フィールド、ルールデータベース形式、実行プラットフォームのアーキテクチャを確認してください。
コアに対して、サブスクリプションのインポート、システムプロキシ、プロキシグループ選択、ログ確認、更新を操作するGUIを提供するアプリです。GUIクライアントによって表示される設定は異なりますが、基盤となるプロトコル処理はコアが実行します。選定時はOS対応、コアの種類、設定互換性をあわせて比較してください。
システムの仮想ネットワークインターフェースでトラフィックを取り込む動作方式です。システムプロキシ設定を参照しない一部のアプリにも適用できます。有効化にはシステム権限が必要な場合があり、ルーティングテーブル、DNSの取り込み方式、他のネットワークソフトの影響も受けます。通信できなくなった場合は、まずTUNを無効にしてからコアのログと仮想NICの状態を確認してください。
OSのHTTPまたはSOCKSプロキシ設定をClashのローカルリスニングポートへ向けます。システムプロキシ設定に従うアプリだけに適用され、ゲーム、コマンドラインツール、独自のネットワークスタックを使うアプリは迂回することがあります。より広い範囲を取り込む必要がある場合は、TUNモードを検討してください。
接続確立前には通常、まずドメイン名が解決され、その後にルール判定とプロトコル接続へ進みます。DNS経路の誤りは、ノードは正常なのに特定ドメインへアクセスできない症状として現れます。
ドメイン名をネットワークアドレスへ変換する基盤サービスです。Clashは設定に応じて名前解決リクエストを転送、キャッシュ、書き換えし、ドメインルールによる振り分けにも利用できます。名前解決の問題を調べるときは、OSのDNS、ブラウザーのセキュアDNS、コアのDNSを個別に確認し、1層だけを変更しないようにします。
コアがまず予約アドレスを返してドメインとの対応を記録し、後続の接続段階で本来の宛先ドメインを復元するDNS拡張モードです。ドメイン情報を保持しながら早期にルール判定できる利点があります。一部のLAN機器や実アドレスを必要とするアプリはフィルター対象に追加する必要があります。
アプリの名前解決リクエストが想定したDNS経路を迂回し、別のリゾルバーで処理される現象です。ブラウザーがセキュアDNSを個別に有効化している、OSに古いDNS設定が残っている、TUNの取り込み範囲が不完全などが主な原因です。確認時はウェブページが開くかではなく、リクエストが実際にどのリゾルバーへ送られたかを記録してください。
1つのローカルリスニングポートでHTTPとSOCKSプロキシ接続を同時に受け付け、異なるアプリで同じポート設定を使えるようにします。LAN上の他の機器から利用する場合は、リスニングアドレス、LANアクセス設定、OSのファイアウォールも確認が必要です。ポートが他のプログラムに使用されていると、コアは通常ログにバインド失敗を記録します。
クライアントが指定したテストアドレスへ接続し、応答時間を記録する処理です。結果はテスト時点、テスト対象、現在のネットワーク経路における接続状況を示すもので、ダウンロード速度や継続的な転送性能とは異なります。ノードを比較するときは同じテストアドレスを使い、実際のアクセス結果もあわせて判断してください。