Clashのプロトコルとコア
技術解説

1. 接続の仕組み：クライアント、コア、プロトコル

クライアント画面に表示されるノードは、実際には接続パラメーターの集まりです。通常、接続先のアドレスとポート、認証情報、プロトコルの種類に加え、必要に応じてトランスポートやセキュリティの設定が含まれます。ノード名をクリックする操作は、プロキシグループの現在の出口をその接続先に切り替えるだけで、プロトコル自体は変わりません。この関係を理解すれば、「ノードを変える」「プロトコルを変える」「ルールモードを切り替える」の違いが分かります。それぞれ接続先、接続方法、通信の振り分け方を変更するもので、トラブル対処では区別が必要です。

画面は操作を担い、接続はコアが処理する

Clash Plus、Clash Verge Rev、FlClashなどのクライアントは、サブスクリプション管理やポリシー選択、システム連携の画面を提供します。設定の解析、名前解決、ルール判定、接続の確立とデータ転送を担うのはコアです。名前の似たクライアントでも異なるコアを採用していることがあり、名前の異なるクライアントが同じ系統のコアを使う場合もあります。そのため、画面に設定項目があるかどうかだけで、コアがそのプロトコルに対応しているかは判断できません。逆にコアに機能があっても、クライアントの画面から設定できるとは限りません。

リクエストの経路は4段階に分けて考えられます。アプリの通信がローカルの入口に入り、コアがルールに基づいてポリシーを選択し、プロトコルの実装が接続先とセッションを確立して、接続先から目的のサービスにアクセスします。ローカルの入口にはHTTPプロキシ、SOCKSプロキシ、TUN仮想インターフェースなどがあります。プロキシプロトコルが主に関わるのは、コアから接続先までの区間です。ブラウザーがシステムプロキシに従うかどうかを直接決めるものではなく、端末のDNS、ルーティング、権限の問題を自動で解決するものでもありません。アプリが接続できない場合は、まず通信が本当にコアに入っているか確認しましょう。

アプリの通信と下位のトランスポートを区別する

TCPとUDPは、アプリが生成する通信を表す場合も、プロキシプロトコルが利用する下位のトランスポートを表す場合もありますが、同じ話ではありません。たとえばQUICベースのプロトコルはUDPを使いながら、アプリのTCP接続をプロキシできます。UDP転送に対応するプロトコルでも、サーバー、クライアント、ローカルの入口すべてが条件を満たす必要があります。ゲームがUDP通信を使うからといって、QUICプロトコルを選ぶ必要があるとは限りません。TUNを有効にしても、接続先がすべてUDPを受け付けるわけではありません。選ぶ際は「アプリに必要なもの」と「現在のネットワークで利用できるもの」を分けて考えましょう。

セキュリティ設定は信頼境界とあわせて考える

プロキシ接続の暗号化と、接続先サイトのHTTPSは異なるレイヤーのものです。プロキシ経路の暗号化は端末から接続先までのデータ転送を保護し、HTTPSはアプリと接続先サービス間の安全なセッションを提供します。プロキシを使っていても、証明書の検証を省略してよいわけではありません。また、接続先からすべての情報を見られないという意味でもありません。接続先のアドレス、接続時刻、通信の特徴は経路上の関係者に観測される可能性があり、範囲はプロトコル、DNSの経路、アプリ独自の暗号化の有無によって異なります。サービスを選ぶ際は、設定情報の入手元と接続先の運営者が信頼できるかも確認しましょう。

設定を記録するときは、クライアント名、コア名、プロトコル、ローカルでの通信取り込み方法、問題が起きたアプリを先に書き、その後に症状を説明するとよいでしょう。「Clashが使えない」とだけ伝えるより、原因を特定しやすくなります。通信がまだコアに入っていない場合は、まずTUNモードとシステムプロキシの違いを確認してください。正しいポリシーが適用されているなら、続くプロトコルの各章を参照しましょう。このガイドの比較は、パラメーターが正しくサーバーが利用可能であることを前提としており、サービス品質の違いをプロトコル名だけに結び付けるものではありません。

2. SSとVMess：軽量な転送とセッション設計

Shadowsocksは通常SSと略され、比較的シンプルな構成で暗号化プロキシ転送を実現することを重視して設計されています。VMessはV2Rayエコシステムのプロトコルで、認証、リクエスト情報、データ転送を独自の方式で構成します。どちらもClashエコシステムで長く使われていますが、歴史が長いからといって、すべてのクライアントで細部まで同じように対応しているとは限りません。比較する際は、サブスクリプションの種類だけでなく、暗号化方式、認証方式、外側のトランスポートを確認しましょう。

SSの特徴はシンプルな構成と暗号化方式の選択肢

SSの一般的な設定項目は、サーバーアドレス、ポート、パスワード、暗号化方式です。現在の導入では、受信側がデータの改ざんを検知できる認証付き暗号がよく使われます。従来のストリーム暗号方式と、現代的なAEAD方式は同じものではありません。Shadowsocks 2022系の方式を使う設定もあり、鍵の形式や実装要件は従来のパスワード方式と異なります。通常のパスワードをどの方式にもそのまま入力できるわけではありません。クライアントがssタイプを認識できることは、このプロトコルの入口に対応していることを示すだけで、個別の暗号化方式への対応を保証するものではありません。

対応するハードウェア命令を備えたデバイスでは、AES系の暗号化方式が高速化される場合があります。該当する命令がないプロセッサでは、ChaCha20系の実装が適していることもあります。ただし、最終的な負荷はコアの実装、パケットサイズ、同時接続数、デバイスの温度にも左右されます。暗号化方式はまずサーバー側の設定に合わせてください。「高速化」を狙って独自に変更するものではありません。両端の方式が一致しなければ接続に失敗することが多く、別の方式へ自動的に切り替わることはありません。同じSSノードでもデバイスによって性能が異なるからといって、設定の破損と決めつけないようにしましょう。

SSはTCPを転送でき、実装とサーバー側の対応があればUDPも転送できます。サブスクリプションにプラグインが含まれる場合は、現在のコアがプラグイン名とパラメーターを受け付けるかも確認してください。プラグインは接続経路に処理を追加するもので、SS対応クライアントならどのプラグインも使えるというわけではありません。読み込み後に該当ノードだけ接続できない場合は、まずプラグインの項目とログの解析メッセージを確認しましょう。不明なパラメーターを削除して試すより、設定の提供元に現在のクライアントで使える完全な形式を確認するのがおすすめです。

VMessの認証と外側のトランスポートを分けて考える

VMessはユーザー識別子を使って認証し、独自のセッションおよびデータ保護の仕組みを備えています。一般的な共有リンクには、TCPやWebSocketなどのトランスポート情報と、任意のTLS設定も含まれます。WebSocketは外側のトランスポートであり、新しいプロキシプロトコルではありません。TLSもVMessと同じ意味ではありません。パス、ホスト名、証明書の設定が誤っているとVMess接続に失敗することがありますが、その場合、UUIDを変更しても解決しません。接続先のアドレスからトランスポート、認証の順に確認しましょう。

古い資料にあるalterIdや旧式の認証設定を、現在の構成例としてそのまま使うのは避けましょう。現在の設定では通常AEAD認証が使われますが、具体的な互換性はコアとサーバーによって異なります。VMessの認証にはシステム時刻が関係するため、デバイスの時刻が大きくずれていると、設定が正しく見えても認証に失敗することがあります。ネットワーク時刻の自動設定を有効にしてから再テストする方が、同じリンクを何度も読み込むより有効です。ただし、時刻が正しくログにTLSエラーが出ているなら、証明書とサーバー名を確認してください。すべての失敗を時刻の問題と決めつけないようにしましょう。

SSとVMessを実際に使い分けるには

すでに安定したSS設定があり、デスクトップでのウェブ閲覧や一般的なアプリ接続に使うのであれば、シンプルな設定は管理しやすいでしょう。サーバーがVMessと指定トランスポートを前提に構成されているなら、項目の少なさより、両端の設定を一致させることが重要です。どちらのプロトコルも、名前だけで帯域や遅延を予測することはできません。接続先の混雑、経路の距離、サービス側の制限が、プロトコルの処理負荷の差を上回ることはよくあります。同じアプリ、近い時間帯、同じ接続先でテストし、異なる事業者のノードを比べてプロトコルの優劣を決めないようにしましょう。

3. TrojanとVLESS：TLS、セキュリティレイヤー、トランスポートの組み合わせ

TrojanとVLESSはサブスクリプションでTLSとともに記載されることが多く、同じ技術の別名だと誤解されがちです。実際には、TrojanはTLS接続とその内部で行うプロキシリクエストを中心に設計されています。一方、VLESSは比較的シンプルな認証とリクエスト形式を提供し、VMessと同じデータ暗号化機能は担いません。セキュリティ境界、設定構造、組み合わせの自由度は異なるため、ポートや証明書の設定が同じだからといって互換性があるとは限りません。

Trojan：TLSに安全な通信を任せる

Trojanでは通常、TLSが通信の機密性とサーバー認証を提供し、その接続内でプロトコル認証と接続先へのリクエストを行います。主な設定項目は、アドレス、ポート、パスワード、サーバー名です。クライアントが接続するIPアドレスと証明書のドメイン名は異なる場合がありますが、検証には正しいサーバー名が必要です。サーバー名は任意のメモではなく、TLSハンドシェイクと証明書の検証に使われます。ノードの表示名をサーバー名に入力すると、証明書が一致しないことがあります。

TLSセッションを再開できるか、接続を再利用できるか、サーバーがどのトランスポートに対応しているかによって、実際の接続コストは変わります。TLSだから必ず「ハンドシェイク分遅くなる」とは言えず、すべての実装が同じ方法で接続を再利用するとも限りません。初回接続、短時間での再接続、アプリが接続を長時間維持する場合では、負荷が異なることがあります。比較結果を読む際は、新規の接続を測定したのか、セキュリティセッション確立後のデータ転送を測定したのか確認しましょう。条件が違えば、同じプロトコルでも一見矛盾した結果になることがあります。

証明書エラーは、正しいドメイン名、有効な証明書、システム時刻を確認して解決しましょう。検証を無効にする設定を常用するのは避けてください。検証をオフにすると重要なサーバー認証が失われ、接続できたとしても、意図したサービスにつながっている証拠にはなりません。設定の提供元から特別な信頼方法を指定された場合は、その根拠とリスクを確認し、クライアントが対応しているか判断しましょう。他のノードの設定をそのままコピーするのは避けてください。パスワードが正しくても、証明書の信頼関係の誤りを補うことはできません。それぞれ役割が異なります。

VLESS：プロトコル、トランスポート、セキュリティレイヤーを個別に確認

VLESSはシンプルなリクエスト設計により、さまざまなトランスポートやセキュリティ機構と組み合わせられます。type: vlessを確認したら、TCPなどのネットワークトランスポート、TLSやREALITY関連の設定、サーバーが特定のflowを要求しているかを続けて確認しましょう。VLESS自体は完全なデータ暗号化を提供しないため、ユーザー識別子があるからといって、暗号化されていない通信にも安全性があるとは限りません。種類の項目だけで判断せず、接続の組み合わせ全体を確認してください。

REALITYは特定のセキュアハンドシェイク方式で、Visionは特定のフロー制御とデータ処理の経路に関わる機能です。どのノードにも自由に追加できる汎用の高速化機能ではありません。サーバー名、公開鍵、Short ID、flowなどの項目は、サーバー設定と一致し、現在のコアでも対応している必要があります。クライアントによって画面上の項目名は異なり、完全なYAMLのみ受け付ける場合もあります。読み込みには成功しても接続できないときは、ノード名が一覧に表示されているかだけでなく、項目が実際にコアへ渡っているかをログで確認しましょう。

設定項目の数ではなく、組み合わせ全体への対応を確認する

サーバーが両方の接続方式を提供している場合は、クライアントが明確に対応し、必要な設定情報がそろい、証明書検証を維持できる組み合わせを選びましょう。項目が少なくても省電力とは限らず、複雑な構成が速いとも限りません。日常的なウェブ閲覧では、接続の安定性、アプリの復帰の速さ、設定更新の確実さがより重要です。特定のVLESS機能が必要なら、まずmihomoのビルドとクライアントへの読み込み方法を確認してから実際の動作を比べましょう。ノードリンクしかなくトランスポートの説明がない場合は、リンクの見た目で推測せず、完全な設定を提供元に確認してください。

4. Hysteria2とTUIC：QUICを使う通信の特徴

Hysteria2とTUICはいずれもQUICを利用したプロキシ用トランスポートですが、同じプロトコルの別名ではありません。QUICはUDPを基盤とし、セキュアハンドシェイク、ストリーム管理、輻輳制御などの機能を組み合わせ、従来のTCP接続とは異なる形でプロキシセッションを構成します。選ぶ前に、現在のネットワークでUDPに到達できるか、制限がないかを確認してから、輻輳制御や帯域の設定を調べましょう。UDP経路が通らなければ、認証パラメーターが正しくても有効なセッションは確立できません。

QUICでできること、できないこと

QUICの複数ストリームでは、1つのパケット損失によるストリーム間のトランスポート層のブロッキングを抑えられます。すべてのデータを1本のTCPバイトストリームに載せる方式とは異なります。ただし、ストリーム内で順序どおりの配信が必要なデータは再送を待つことがあり、すべてのストリームが帯域、輻輳状態、端末のリソースを共有します。「パケットロスが速度に影響しない」技術ではありません。ネットワークが混雑すれば送信速度の調整が必要です。アプリのリクエスト間の依存関係やサーバーの応答時間も、QUICを使うだけで解消するものではありません。

ネットワークによっては、UDPに独自の速度制限、タイムアウト、パケットロス対策が適用されています。ビデオ通話ができても、あらゆる接続先ポートへのUDP通信が同じ品質とは限りません。一度ハンドシェイクに成功しても、長時間の大容量転送が安定するとは限りません。テストでは、継続的なアクセス、短時間中断した後の復帰、デバイスのスリープ後の再接続も確認しましょう。QUICは接続を移行できる場合がありますが、プロキシの実装、アドレスの変化、ネットワーク機器の状態に左右されます。Wi-Fiからモバイル通信に切り替えても必ず接続を維持できると考えないでください。

Hysteria2：実際の回線状況に合わせた送信設定

Hysteria2は、不安定な回線でのデータ転送を想定して設計されており、帯域に関する設定や異なる輻輳制御方式が使われます。帯域の申告を前提とする送信方式を使う場合は、上下の帯域をデバイスの公称値ではなく、実際に継続して利用できる速度に近づけて設定しましょう。数値を高くしても帯域が増えるわけではありません。キューが長くなりパケットロスが増えて、同じネットワーク上のほかのアプリに影響することがあります。サーバー側の制限もあるため、クライアントの設定で接続先のリソース制約を回避することはできません。

mihomoの設定に取り込む際は、現在対応しているHysteria2の種類と項目を使い、古いHysteriaの設定を名称だけ変えて流用しないでください。認証情報、TLSサーバー名、任意の難読化パラメーターは、接続先と一致させる必要があります。帯域項目を省略するかどうか、どの方式を使うかは、提供元の説明と現在のコアのドキュメントに従ってください。接続は確立するものの、ダウンロードの継続中に速度が大きく変動する場合は、DNSを何度も変更する前に、UDP経路、帯域の見積もり、デバイスの処理能力を確認しましょう。

TUIC：セッション管理とUDP転送方式

TUICもQUICを利用し、プロキシセッション、認証、データ転送の仕組みを独自に定義しています。プロトコルの世代や実装によって互換性がない場合があるため、共有された設定情報はコアが受け付ける形式と一致している必要があります。UDP転送方式、輻輳制御の選択肢、接続維持、タイムアウトの設定は、使い勝手に影響することがあります。追加の負荷を抑える方式もあれば、配信のセマンティクスを重視する方式もあり、項目名だけで選ぶことはできません。特にリアルタイム通信では、大容量ファイルのダウンロード完了だけでなく、一時停止やパケットロスにも注目しましょう。

QUICはユーザー空間で多くのプロトコル処理を行うことがあり、暗号化、パケット処理、高いパケットレートはCPUを消費します。新しいデスクトップなら余裕があっても、低消費電力のルーターや発熱し続けるスマートフォンでは、先に処理能力の限界に達することがあります。プロトコルの負荷はデバイスや実装次第であり、すべての環境に当てはまる性能順位はありません。同じ回線でTCP系の接続が安定して要件を満たしているなら、QUICに変えても明確な効果がないことがあります。高遅延やパケットロスが実際に問題なら、条件をそろえてテストし、改善を確認するのが確実です。

5. 性能と電池消費：意味のある比較方法

プロトコルを比較するときは、少なくとも新規接続にかかる時間、継続転送時の速度、リクエストの安定性、デバイスのリソース消費という4つの指標を分けて考えましょう。クライアントに表示されるミリ秒単位の測定値は、通常、特定の経路で行った1回または少数回のリクエスト時間です。帯域でも、アプリの使用感全体でもありません。測定対象、出口、時間帯、デバイスの条件が近い場合に初めて、プロトコルの違いを比較できます。地域や事業者の異なるノードの結果を、そのままプロトコルの順位付けに使うことはできません。

接続速度、帯域、突発的な遅延

初回アクセスでは、DNS、下位の接続、安全なハンドシェイク、プロキシ認証、接続先サーバーの応答がすべて影響します。アプリが既存の接続を再利用すれば、その後のリクエストでは一部の処理を省けるため、初回は遅くても、その後の閲覧が速いことはあり得ます。大容量ファイルの転送では継続的なスループットを測りやすい一方、ページ内の多数の小さなリクエストがどれだけ早く完了するかは分かりにくくなります。リアルタイム通信では、突発的なパケットロスや大きな遅延がより重要です。平均時間が近くても、ときどき発生する長い停止が使い心地を左右することがあります。

比較するなら、サーバー側の条件ができるだけ近い接続先を2つ選び、近い時間帯に同じタスクを交互に実行しましょう。ページの初回表示、表示済みページの再読み込み、短時間のファイル転送、実際に使う音声通話やリモートアプリなどを試します。それぞれ数回繰り返し、最良の結果だけでなく失敗も記録してください。複数の大容量通信を同時に行うと、帯域の奪い合いが差を見えにくくするため避けましょう。測定の考え方はノードの遅延テストと実際の通信速度の違いも参照してください。

リソース消費に一律のプロトコル順位はない

CPU負荷は、暗号化の実装、システムコール、パケット処理、データのコピーなどに左右されます。メモリ使用量には、接続数、バッファー、ルールデータベースも影響します。TUNモードによる通信の取り込み処理の方が、2つのプロキシプロトコルの差より大きな負荷になることもあります。メモリ使用量が増えた場合は、接続数の増加、キャッシュの蓄積、継続的な異常のどれが原因かを確認しましょう。特定のプロトコルを使用しているというだけで、原因と決めつけてはいけません。クライアントを比較するときは、画面を表示するプロセスとコアのプロセスも区別してください。そうしないとデスクトップ画面の負荷までプロトコルのコストに含めてしまいます。

ハードウェアアクセラレーションやネットワークオフロードによっても結果は変わります。暗号化命令に対応したプロセッサ、OSごとのネットワークスタック、コアのビルド時に採用された実装によって、同じプロトコルでもデバイスごとに異なる挙動を示すことがあります。低消費電力のデバイスは、温度が上がると動作周波数が下がり、最初の数分は速くても次第に遅くなる場合があります。接続数やバッファーを増やして負荷を上げるのではなく、温度、CPU負荷、回線状況の関係を確認しましょう。

モバイルの電池消費は、スリープ解除と接続のライフサイクルがポイント

スマートフォンの電池は暗号化処理だけでなく、無線の稼働、バックグラウンドでの復帰、再接続の繰り返しでも消耗します。ヘルスチェック、サブスクリプションの更新、キープアライブの頻度が高すぎると、アイドル状態でも通信が続きます。逆にタイムアウトを短くしすぎるとセッションが頻繁に切れ、アプリの復帰時に何度も接続を確立し直すことになります。まずはクライアントの妥当な初期設定を使い、実際に切断が起きる場合に調整しましょう。一時的な速度測定の数値を追うために、高頻度の通信を常時有効にするのは避けてください。

電池消費を比較する際は、画面の明るさ、ネットワークの種類、使用時間、アプリの負荷をそろえ、OSのバッテリー使用状況でバックグラウンドの動作を確認しましょう。モバイル通信の電波が弱い場合、無線の消費電力がプロトコルの差を上回ることがよくあります。Wi-Fiとモバイル通信の結果をそのまま比べることもできません。Androidでは省電力機能によってバックグラウンドサービスが終了することがあり、iOSではネットワーク拡張のライフサイクルをシステムが管理するため、両者の挙動は完全には一致しません。復帰後に再接続するからといって、必ずしもプロトコルに問題があるとは限りません。動作環境がOSに維持されていたかも確認しましょう。

6. コアの系譜：オリジナル版、Meta、mihomo

Clashは当初、YAML設定、プロキシグループ、ルールによる通信の振り分けを中心とした使い方で広まりました。その後のエコシステムでは、これらの考え方をもとに複数のコアやGUIクライアントが開発されています。オリジナルのオープンソースコア、過去の派生版、Meta系統は、完全に同じ実装ではありません。mihomoはClash.Metaが後に使用するようになったプロジェクト名のため、資料やクライアント画面には今もMetaの表記が残ることがあります。この名前の変遷は古いガイドを理解する手掛かりになりますが、実際のコア機能を確認する代わりにはなりません。

共通の書式でも、機能がすべて一致するわけではない

一般的な設定では、proxies、proxy-groups、rulesなどの構造が引き継がれ、多くの基本的な考え方を共通して利用できます。ただし、プロトコルの種類、DNSの挙動、TUN機能、ルールプロバイダー、拡張項目は、派生元やビルドによって異なります。オリジナル版の資料に項目が載っていても、すべてのクライアントで同じように使えるとは限りません。mihomoの拡張機能を、古いオリジナル版コアにそのまま渡すこともできません。移行時は、ファイル拡張子が同じかではなく、個々の項目に互換性があるかを確認しましょう。

Hysteria2、TUIC、特定のVLESS構成、より高度なルーティング機能は、現代的なコアの対応状況を確認する際によく検討される項目です。実際に利用できるかは、具体的なビルド、プラットフォームの制限、クライアントとの連携方法によって異なります。GUIが一部の項目を除外する場合や、中間設定を生成する場合、元のYAMLをそのまま読み込む場合があります。「単体のコアなら動くのに、クライアントに読み込むと動かない」ときは、読み込み前に保存したファイルだけでなく、最終的に適用されている設定を比べましょう。

コアを確認する手順

まず、クライアントの「バージョン情報」、コア管理画面、実行ログでコア名を確認し、実際に起動しているビルドを特定しましょう。インストール先に複数のコアファイルがあっても、すべてが同時に動作しているわけではありません。画面に表示されるクライアントのバージョンも、コアのバージョンとは異なります。コアを切り替えられるクライアントでは、切り替え後にサービスの再起動を待ち、ログで確認してください。画面に明確な表示がない場合は、クライアントの説明と実行ログを基準にし、インストーラーの名称から推測しないようにしましょう。バージョン履歴はトラブル対処に役立ちますが、選び方のために更新のたびに追いかける必要はありません。

アップグレード前に元のサブスクリプションと必要なローカル上書き設定を保存し、現在の通信取り込み方式、ポート、DNS設定を記録しておきましょう。アップグレード後は、まず最小限の動作する設定で基本接続を確認してから、カスタムルールや拡張機能を戻します。これにより、「プロトコル解析の変更」「システム連携の変更」「ローカル上書き設定の競合」を切り分けられます。起動直後に失敗する場合は設定解析ログを確認します。コアが動いているのにアプリが通信できない場合は、システムプロキシ、TUNの権限、ルーティングを確認しましょう。原因の異なる問題に、同じ対処法を使わないでください。

クライアントの選択とメンテナンス上の注意

一般ユーザーはClash Plusから試し、デバイスのOSに応じてプロトコルの読み込み方法とシステム要件を確認するとよいでしょう。デスクトップで特定の管理方法を使いたい場合は、Clash Verge Rev、FlClash、Clash Nyanpasuを比較してください。Androidでは設定の入手元に応じてClash Meta for AndroidとSurfboardも選べますが、Surfboardの設定方式はClash YAMLと同じではありません。LinuxデスクトップではClash Verge RevとFlClashが候補になります。サーバーやルーターでは、mihomo単体のコアやサービス管理も検討しましょう。

Clash for WindowsとClashX Metaは、当サイトでは開発終了済みのアーカイブ版クライアントとして案内しています。新しいプロトコル機能の標準的な比較対象としてはおすすめしません。既存環境で従来の運用を続ける場合は、利用できるプロトコルと設定範囲を確認してください。新しい設定の未知の項目を、起動できるまで一つずつ削除するのは避けましょう。ルーティングやセキュリティの動作が変わる可能性があります。各プラットフォームのダウンロード先とアーカイブ表示はクライアントのダウンロードページをご覧ください。画面や機能の違いはクライアントの選び方ガイドで解説しています。

7. サブスクリプションと設定：形式の判別と互換性の確認

サブスクリプションリンクは設定を取得するための入口であり、返される内容の形式まで保証するものではありません。見た目が似たHTTPSアドレスでも、ノード共有リンクの一覧、Base64エンコードされたテキスト、完全なYAML設定のいずれかが返されることがあります。読み込み後にそのまま使えるかは、返された内容と読み込み方法が合っているかによります。ブラウザーで開けることはサーバーが何らかの内容を返したというだけです。ログイン画面、エラーメッセージ、空のテキストが表示されても、有効なプロキシ設定とは限りません。

ノード一覧、プロバイダー、完全な設定を区別する

ノードリンクには通常、1つのプロキシの接続パラメーターが記述されています。複数のリンクをまとめても、ローカルポート、DNS、プロキシグループ、ルールまで含まれるとは限りません。完全なClash設定では、通信の取り込み方、名前解決、出口の選び方などをまとめて定義します。プロキシプロバイダーは別の仕組みで、主に既存設定へプロキシを提供し、動作に必要な設定全体を担うものではありません。読み込み先を間違えると、ノードは表示されても適切なプロキシグループがなかったり、ファイルを解析できても単独の設定として動作しなかったりします。

Base64は単なるエンコード方式で、追加の秘匿性を提供するものではありません。ノード一覧を自動的にYAMLに変換するものでもありません。サブスクリプション変換ツールは元の形式を解析し、利用先のコアが受け付ける項目やポリシー構造を生成します。変換時に、トランスポートの詳細、固有のセキュリティ設定、UDP設定など、認識できない拡張情報が失われることがあります。変換後にノード名が表示されても、すべての機能が保持されているとは限りません。複雑なVLESSやQUICの設定では、提供元が利用を明示している形式を優先し、重要なパラメーターを照合しましょう。

何度も読み込み直すより、設定の構造を確認する

設定を確認するときは、まずプロキシ定義を探し、次にそれらを参照するプロキシグループ、最後にルールの振り分け先が存在するかを確認します。以下は参照関係を示す最小限の例で、完全な動作設定ではありません。ここでは既存設定に「既存ノード」という名前のプロキシが定義されているものとします。使用時は既存設定に対応する形で統合し、同じ名前のトップレベルキーを重複して作らないでください。一般的なルールの書き方を使っており、どの出口が選ばれるかを確認できます。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 既存ノード
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - MATCH,DIRECT

この設定では、ルールがまずドメインのサフィックスを照合し、一致するとPROXYグループに渡します。その後、グループで現在選択されている項目が出口になります。一致しない通信は最後のDIRECTへ進みます。グループ内にDIRECTがあっても、すべてのリクエストが直接接続されるわけではありません。手動で選べる項目を用意しているだけです。ルールは上から順に評価され、最初に一致した時点で処理が終わります。より広い条件のルールが先にあると、その後の細かいルールが適用されないことがあります。構文と並び順はカスタムルールとMATCHによるフォールバックを参照してください。

YAML、上書き、更新はそれぞれ役割が異なる

YAMLはインデントと構造が重要です。スペースを使い、同じ階層の項目をそろえましょう。パスワード、特殊文字を含む文字列、別の型として解釈されやすい値は、形式に合った引用符で囲んでください。構文エラーは該当行付近を示すことが多いものの、実際の原因は前の行のコロン抜けやリスト階層の誤りの場合があります。まず構文エラーを解消し、次に参照関係、最後にプロトコル接続を確認します。一度に多くの項目を変更するより効率的です。長いルール名やノード名は完全な形で保ち、画面上の折り返しをファイル内の改行と取り違えないようにしましょう。

サブスクリプションの更新で手動変更が上書きされる場合があるため、継続して使うローカルルールにはクライアントが対応する上書き機能やマージ機能を使いましょう。マージの順序はクライアントごとに異なり、リストを置き換える場合も追加する場合もあります。変更後は、特にルールの順序やDNS項目など、最終的に適用される設定を確認してください。DNSのFake-IPは名前解決とアドレスのマッピング方式であり、プロキシプロトコルの種類ではありません。ノード形式を変換しても、アプリのFake-IP対応問題は解決しません。DNSを調整する前に、障害が名前解決と接続先への接続のどちらで発生しているか確認しましょう。

同じサブスクリプションを2つのクライアントで使ったとき、ノード数やプロトコルの種類が異なる場合は、サブスクリプションが無効だとすぐに判断せず、フィルター設定、形式の選択、コアの対応状況を確認しましょう。形式の詳しい比較はBase64ノードリンクとYAML設定の解説を参照してください。元の情報とローカルでの変更を分けて管理すると、後の更新や移行が追跡しやすくなります。

8. 用途別の選び方とトラブル対処：条件から候補を絞る

プロトコル選びは「どれが最先端か」ではなく、デバイス、ネットワーク、アプリ、設定の入手元という4つの条件が合うかどうかから始めましょう。まず、既存の設定を正しく読み込めて、継続して使えるクライアントを選びます。次に通信の取り込み方法を決め、最後に同じサーバーの接続先同士で性能を比較します。一般ユーザーは、まずClash Plusと設定の提供元が対応する形式から始めるのがおすすめです。明確な互換性の要件や再現性のある性能問題がある場合に限り、新しいコアやプロトコルの組み合わせを試し、トラブル対処の条件を複雑にしないようにしましょう。

デスクトップ、モバイル、ルーターで重視するポイント

デスクトップでのウェブ閲覧や業務アプリでは、まずシステムプロキシが必要なアプリをカバーしているか確認します。ブラウザーは使えてもコマンドラインツールだけ動かない場合、ツールがシステムプロキシを参照していないだけで、接続先のプロトコルが非対応とは限りません。より多くのアプリを通信対象にする場合はTUNを検討し、仮想インターフェースの権限、ルートの競合、ローカルネットワークへのアクセスに注意してください。プロトコルについては、安定して動作しているSS、Trojan、完全なVLESS構成ならそのまま使えます。名称が新しいという理由だけで移行する必要はありません。開発ツールでは、ツール独自のプロキシ設定と環境変数も個別に確認しましょう。

モバイルでは、スリープからの復帰、ネットワーク切り替え、バックグラウンドでの安定性を重視しましょう。Wi-Fiとモバイル通信を頻繁に切り替える場合は、固定ネットワークで速度を測るだけでなく、実際に切り替えた後の既存セッションと新規セッションを確認してください。QUIC系プロトコルも候補になりますが、利用中の通信事業者ネットワークでUDPを使えるか検証が必要です。再接続を1回減らすためにキープアライブをむやみに増やすのは避けましょう。OSがバックグラウンドサービスを停止したことによる切断を、認証失敗と誤解しないでください。iOSではClash PlusのApp Storeから利用を始め、公式サイトのclashplus.ioで製品情報を確認できます。

ルーターやサーバーでは、単体のコア、自動起動、ログ管理、明確なルーティング境界が必要になることがよくあります。低消費電力のプロセッサは、高スループットの暗号化やQUICのパケット処理で負荷が高くなりやすく、大量の接続やルールがメモリを消費することもあります。まず少数の接続で安定性を確認し、徐々に負荷を増やしましょう。デスクトップ向けの複雑な設定をそのままコピーして、長期間運用するのは避けてください。別経路のルーター、多数のネットワークインターフェース、既存の透過プロキシルールがある環境では、通信のループにも注意が必要です。プロトコルを変えても誤ったルーティングテーブルは修正されず、管理者によるファイアウォールルールの確認の代わりにもなりません。

複数の設定を同時に変えず、レイヤーごとに原因を調べる

最初にコアが起動しているか確認します。設定の解析エラー、未対応プロトコル、項目不足の場合は設定とコアの互換性を確認し、待ち受けに失敗している場合はポートと使用中のサービスを調べます。次に、アプリのリクエストが接続ログに記録されているか確認します。記録がなければローカルでの通信取り込みを見直しましょう。その次に、どのポリシーが適用されたかを確認し、意図せずDIRECTや利用できないプロキシグループを選んでいないか調べます。最後に、接続先への通信でタイムアウト、認証、証明書、UDP経路の問題を確認します。この順序なら、接続先が正常なのにノードを何度も変更するような無駄を避けられます。

ログに証明書エラーがある場合は、サーバー名、時刻、証明書チェーンを確認します。認証失敗の場合は、パスワードまたはユーザー識別子を確認しましょう。タイムアウトが続く場合は、TCPまたはUDPのトランスポートに応じて接続性を調べます。特定のサイトだけ失敗する場合は、接続先の出口とサイトの相性、DNSの解決結果も確認してください。ポートの競合などローカルでの起動問題はポート使用中の原因特定と混合ポートの変更を参照してください。初回の読み込み手順や一般的な操作の問題は使い方ガイドに戻って確認すれば、設定全体を最初から変える必要はありません。

再現可能な選定記録を残す

最後に、デバイスとOS、クライアントとコア、プロトコルの組み合わせ全体、通信の取り込み方法、テストしたアプリ、ネットワークの種類、再現できる症状を簡潔に記録しておきましょう。重要な条件は一度に一つだけ変更し、動作が確認できている設定を残します。新しい組み合わせで測定値がよくなっても、スリープからの再接続、リソース消費、互換性に問題が出るなら、従来の安定した設定を使い続けてかまいません。プロトコルは接続のための手段であり、優劣を示すラベルではありません。信頼できる設定情報に基づき、動作を説明でき、更新後も元に戻せる設定が長く使うのに適しています。