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

プロトコル・通信方式・クライアントを区別する

プロトコルは、クライアントとプロキシサーバーが宛先や認証情報をどう表し、データをどう受け渡すかを定めます。トランスポート層は、TCPやUDP、またはそれらを基盤とする通信路でデータを運びます。クライアントは設定の読み込み、ポリシー選択、ログ、システム連携などを担います。これらは関係していますが、同じものではありません。Clash Plus、Clash Verge Rev、FlClashという名前だけでは、どのノードがどのプロトコルを使うかは分かりません。また、画面の見た目だけで特定の拡張フィールドへの対応を判断することもできません。

接続を確認できる工程に分ける

Webページを開くときは通常、ローカルDNS、ルール判定、プロキシ接続の確立、接続先への通信、アプリケーション層のネゴシエーションが行われます。体感する待ち時間は、これらすべての工程で生じます。ノードのテストに成功しても、その時点でテスト先に到達できたことしか分かりません。特定のWebページが開けない原因は、DNS、証明書、地域制限、サイト側の障害かもしれません。プロトコルを比較する前に、対象の通信が意図したポリシーを通っているか確認してください。そうしないと、プロトコルの違いではなく、別々の出口を使った結果を比べることになります。

TCPは信頼性と順序性のあるバイトストリームを提供します。データが失われると再送が必要になり、後続データの受け渡しが欠落分の補完まで待たされることがあります。UDPはデータグラム通信を提供しますが、それ自体は信頼性や順序を保証しません。一方、UDPを基盤とするQUICは、ユーザー空間で信頼性のあるストリーム、輻輳制御、暗号化ハンドシェイクを実装します。したがって「UDPベース」は「再送しない」という意味ではなく、UDPを使うアプリなら何でもプロキシ経由で通信できるという意味でもありません。実装がデータグラム転送に対応し、クライアントのトラフィック制御方法がコアへ通信を渡せる必要があります。

細かな調整より先に互換性を確認する

実際の選定では、次の4段階で候補を絞れます。まずサーバーが対応するプロトコル、次に現在のコアが解釈できるフィールド、その次に利用中のネットワークで使える通信方式を確認し、最後に速度、電池消費、機能を比べます。未対応フィールドを含む設定をクライアントに保存できても、その機能が有効になるわけではありません。特に、プロトコル名と通信方式の拡張を区別してください。同じVLESSでも、通信方式やセキュリティ層、フロー制御の設定によって必要条件は大きく異なります。

プロキシモードとプロトコルも区別が必要です。ルールモード、グローバルモード、ダイレクトモードは、接続をどのポリシーに渡すかを決めます。SSをTrojanに変換したり、ノードにUDP機能を追加したりするものではありません。TUNモードはシステムのネットワーク層で通信を取り込む仕組みであり、新しいプロトコルではありません。TUNを有効にしてゲームが接続できた場合、通信がようやく取り込まれたことが理由であるケースが多く、ノードの通信性能が急に変わったわけではありません。通信経路については、ルール・グローバル・ダイレクトモードの違いもご覧ください。

この解説は、正規に利用できるサーバー設定をお持ちの方を対象としています。サーバーの認証情報は提供せず、プロトコル名だけを見てサブスクリプションを書き換えることも推奨しません。クライアントが接続できるのは、サーバーが対応する方式に限られます。設定の種類名を別のプロトコルに置き換えても、プロトコル変換にはなりません。プロトコルを変更する場合は、サーバーの該当エンドポイントに必要なパラメーター一式を入手し、比較できるよう旧エンドポイントも残してください。複数の条件を同時に変えると、結果を判断する基準が失われます。

SSとVMess：基本プロトコルの特徴

Shadowsocksは一般にSSと略され、軽量な暗号化プロキシとして設計されています。プロトコル自体に多くのルーティング機能や管理機能を詰め込まず、宛先とアプリケーションデータをサーバーへ渡すことを重視しています。VMessはV2Rayエコシステムで生まれ、ユーザー識別、リクエスト認証、データ転送を独自のプロトコル構造にまとめています。どちらもクライアント側で広く対応されていますが、長く使われていることは、古い設定や暗号化方式、拡張プラグインが現在の実装にも適していることを意味しません。

SSは暗号化方式の一致が前提

SSでは、サーバーアドレス、ポート、パスワード、暗号化方式を一組として一致させる必要があります。AEAD方式はデータの認証も行いますが、利用できる方式は双方の実装を確認してください。新しいプロトコル派生型では鍵の要件が異なる場合があるため、専用の形式で指定する鍵に通常のパスワードを入力してはいけません。認証エラーが起きたら、ローカルDNSやルールを変える前に、方式名、パスワードの欠落、サブスクリプションの期限を確認しましょう。

SSは基本構造が比較的シンプルで、プロトコル処理を抑えやすい一方、実際のCPU使用率は暗号化アルゴリズム、プロセッサーの命令セットへの対応、実装の最適化にも左右されます。AESのハードウェアアクセラレーションを備えた機器もあれば、別の方式のほうが適する機器もあります。どの機器でも「この方式が常に省電力」とは言えません。設定にプラグインが含まれる場合は、そのハンドシェイク、プロセス、互換性もコストに含めてください。SS本体だけの説明では、実際の接続経路にかかる負荷を見誤ります。

VMessは認証方式と通信方式の組み合わせを確認

VMessはUUIDなどのパラメーターでユーザーを識別し、過去には複数の認証方式が使われていました。現在も保守されている実装では、より新しい認証方式が一般的です。古い解説にある互換用フィールドをそのまま流用しないでください。認証チェックの一部はシステム時刻に依存するため、端末の時刻が大きくずれているとリクエストが拒否されることがあります。まず自動時刻設定を有効にし、ユーザー識別情報とサーバー側の要件を確認しましょう。GUIクライアントを何度再インストールしても、時刻や認証パラメーターの不一致は通常解決しません。

VMessはWebSocketやTLSと組み合わせて使われることもよくあります。この場合、接続先ポートへのTCP接続に成功しても、プロキシ経路全体が成立したとは限りません。TLSのサーバー名、WebSocketのパス、リクエストヘッダー、サーバー側のルーティングも一致させる必要があります。接続直後に切断される場合は、各層を順番に確認してください。画面にどちらもVMessと表示されていても、2つのエンドポイントの設定を交換できるとは限りません。同じプロトコル名でも、通信のカプセル化方式によって主要な接続コストが変わることがあります。

現在のSSまたはVMessエンドポイントが普段使うネットワークで安定し、アプリに必要なTCP、UDP、各プラットフォームとの互換性を満たすなら、プロトコル名だけを理由に移行する必要はありません。一方、古いエンドポイントがクライアントでサポートされなくなったプラグインや認証方式に依存している場合は、ソフトウェア全体を古い状態に保つのではなく、設定の提供元から対応するエンドポイントを入手してください。基本プロトコルを評価するときは、実際の通信経路と保守要件を満たすかどうかで判断します。機能が少ないことを、そのまま時代遅れとみなすべきではありません。

TrojanとVLESS：セキュリティ層を分けて考える

Trojanは、TLS接続の内側でプロキシ認証と転送を行い、標準的なTLSの仕組みで通信を保護するよう設計されています。VLESSはXrayなどのエコシステムで使われ、より軽量なプロトコルヘッダーと識別情報を採用し、通信の保護を外部のセキュリティ層に委ねます。どちらも現在のサブスクリプションで使われますが、同じ意味ではありません。一般的なTrojanの構成はTLSを前提とします。一方、VLESSの実際の動作は、設定されたセキュリティ層と通信方式の組み合わせに大きく左右されます。

Trojanでは証明書も重要な設定

一般的なTrojan設定には、サーバーアドレス、ポート、パスワード、TLSで使うサーバー名が含まれます。アドレスは接続先を指定し、サーバー名は相手の認証に使われます。アドレスにIPアドレスを指定する場合でも、サーバー名と証明書を別途設定する必要があることがあります。証明書チェーン、有効期限、システムの信頼ストア、端末の時刻はいずれもハンドシェイクに影響します。名前が一致しない場合は、証明書検証を無効にするのではなく、まずエンドポイントの案内を確認してください。検証を無効にすると、接続先が正しいサーバーかを確実に判断できなくなります。

プロキシ経路のTLSエラーと、ブラウザーで接続先サイトを開く際の証明書エラーも区別しましょう。通常のプロキシ転送では、HTTPSをブラウザーの代わりに復号する必要はありません。ブラウザーのエラーは、システム時刻、接続先サイトの証明書、システムにインストールされた検査用プロキシ、または異常な出口経路が原因かもしれません。1つのサイトだけ開けない場合は、まずサイト側を確認してください。すべてのHTTPS接続で失敗する場合は、システムプロキシの経路と証明書環境を調べます。関連する対処手順はプロキシ利用時の証明書エラー対処をご覧ください。

VLESSが軽量でもセキュリティ設定は必要

VLESS自体は、独立した暗号化通信路と同等のデータ保護を提供しません。使用時は、実際の構成でTLS、REALITY、その他の対応するセキュリティ機構のどれが使われているかを把握してください。サブスクリプション内のUUID、サーバー名、公開鍵、短い識別子、フロー制御フィールドには、それぞれ役割があります。互いに置き換えることはできません。設定によっては特定の通信方式とコア機能が必要です。画面に入力欄があっても、任意のフィールドを組み合わせれば接続できるとは限りません。

REALITYはセキュリティ層に関する機構であり、単独で選べる別のプロキシプロトコルではありません。同様に、Visionは双方で設定を一致させる必要があるフロー制御で、すべてのVLESSノードに指定すべき高速化スイッチではありません。これらのフィールドを手動で追加すると、正常に動作していたエンドポイントが使えなくなることがあります。まず設定の提供元が示す一式をそのまま保持し、使用中のコアが対応している範囲を確認してください。サーバー側で機能が有効になっていると確認できてから、パラメーターの調整や通信方式の変更を検討しましょう。

接続の使い勝手は、TrojanもVLESSも高品質なTCP経路で動作する場合があり、複雑なカプセル化、サーバーの混雑、誤ったルーティングで遅くなる場合もあります。外側のTLSの影響は、接続の再利用、セッション再開、実装方法によって異なります。「暗号化が1層増える」だけで所要時間を単純計算することはできません。同じ宛先と近い経路条件で、初回接続と確立済み接続の両方を確認してください。ブラウザーで何度も再読み込みすると既存の接続が再利用されることがあり、コールドスタートのコストを単独で測る方法にはなりません。

証明書とパスワードの設定を分かりやすく確認したい場合、すでにサーバーから提供されているTrojanエンドポイントなら項目ごとに確認しやすいことがあります。サーバーが特定のセキュリティ層を使うVLESS構成なら、その組み合わせに明確に対応した保守中のクライアントを選びましょう。優先すべきなのはパラメーターの完全性と双方の一致であり、どちらの名称が新しいかではありません。現在のエンドポイントが安定しているなら、再現可能な比較結果を得てから移行を判断してください。

Hysteria2とTUIC：まずUDP経路を確認

Hysteria2とTUICはいずれもQUICでプロキシ通信路を構築しますが、同じプロトコルの別名ではありません。QUICは通常UDP上で動作し、暗号化ハンドシェイク、複数ストリームの転送、輻輳制御を統合します。そのため、TCPの順序どおりの受け渡しを全ストリームで共有することで生じる、一部のブロッキングを避けられます。ただし、受信確認や失われたデータの再送、送信量の制御は必要です。ネットワーク容量の制限を回避できる通信路ではありません。サーバーの帯域が不足していれば、QUICに切り替えても出口の容量が増えるわけではありません。

Hysteria2の帯域設定には根拠が必要

Hysteria2は、高いスループットと複雑な通信経路への適応を重視した設計です。帯域推定や輻輳制御に関わる機能は、クライアントとサーバー双方の実装や実際の設定を踏まえて理解してください。クライアントの上り・下り帯域欄は、契約プランの宣伝値でも、数値を上げるほど性能が上がる設定でもありません。利用可能な帯域を大きく超える値を指定すると、キューやパケットロスが増え、同じネットワークを使う通話やWeb閲覧に悪影響が出る場合があります。分からない場合は、他人の環境の数値を流用せず、サーバー側の案内と使用中のコアのドキュメントに従ってください。

HysteriaとHysteria2も、設定のプロトコル名を書き換えるだけでは相互に切り替えられません。プロトコルとパラメーターが異なるため、認証や難読化などの設定をサーバー側に合わせる必要があります。古い解説を参考に、現在のエンドポイントでは不要なフィールドを追加すると、認証前に接続が切れることがあります。接続に失敗したら、まずサブスクリプションに記載されたプロトコルの世代、ポート、認証パラメーターを確認します。次にTLSのサーバー名とUDPの到達性を調べ、最後に輻輳制御を検討してください。ハンドシェイクがまったく成立しない場合、輻輳制御が最初に疑うべき原因とは限りません。

TUICは通信機能と設定の世代を区別する

TUICもQUIC接続でプロキシ通信を運び、TCPとUDPの転送を考慮しています。認証、UDP転送モード、輻輳制御のオプションは、サーバー、サブスクリプション形式、コアがそろって対応している必要があります。世代の異なるTUIC設定では認証フィールドが異なる場合があり、プロトコル名だけでは互換性を判断できません。エンドポイントが求めるフィールドの組み合わせを確認してください。変換ツールが表現できない設定を通知せず削除し、接続失敗を回線の不安定さだと誤解することも避けましょう。

設定によっては0-RTTハンドシェイクや関連する再開オプションが利用できますが、セッション再開などの条件が満たされた場合に限り、待ち時間を短縮できる可能性があります。リプレイに関する意味など、実装側で扱うべき制約もあります。これらを万能な高速化スイッチとして使わないでください。クライアントの初回起動、ネットワーク切り替え、サーバー再起動、セッションチケットの失効などで、接続の挙動は変わります。日常利用では、短いテストでハンドシェイクが1回減ったかではなく、継続的な転送、復旧のしやすさ、アプリとの互換性を確認しましょう。

ホテルやオフィスのゲストネットワーク、一部のモバイルネットワークではUDPが制限されたり、継続的なUDP通信に異なる制御が適用されたりすることがあります。あるネットワークではQUICエンドポイントが使えても、別のネットワークで失敗するからといって、サブスクリプションの期限切れとは限りません。対応済みのTCP系エンドポイントも残して比較し、同じ端末で再テストしてください。モバイル端末でネットワーク切り替え後に復旧できるかは、クライアント、コア、サーバーの実装にも左右されます。QUICに接続移行機能があるからといって、すべてのプロキシセッションが途切れずに切り替わるとは限りません。

Hysteria2やTUICを選ぶ前提は、通信経路が利用でき、双方の設定が明確であることです。往復遅延が大きい環境や通信が不安定な回線では候補になりますが、結果は利用環境でテストして判断してください。軽いWeb閲覧やバックグラウンド待機が主な用途なら、電池消費や接続開始の速さを既存のエンドポイントと実測で比べましょう。大容量ファイルの転送結果から推測することはできません。

速度・リソース・モバイルの電池持ちを比較する

プロトコルの比較では、異なる指標をひとまとめにして「速度」と呼びがちです。接続確立までの待ち時間、ページの最初の1バイトを受信するまでの時間、継続ダウンロードのスループット、通信の揺らぎ、接続成功率は、それぞれ別の問いに答える指標です。大容量ファイルの転送が速いエンドポイントでも、短時間の接続や電波の弱い場所では快適とは限りません。遅延テストの値が低くても、夜間に負荷が高まるとタイムアウトが頻発することがあります。まずアプリに必要な条件を整理してから測定内容を決めましょう。目的が曖昧なまま測定値を増やすと、結論が実際のニーズから遠ざかりかねません。

再テストできる比較手順を作る

端末、ネットワーク、クライアント、テスト先、プロキシモードを固定し、バックグラウンドのダウンロードやシステム更新が帯域を使っていないことを確認します。複数のダウンロードを同時に走らせて競合させず、候補を1つずつテストしてください。実施時刻、初回接続かどうか、ネットワークを切り替えたかを記録し、複数回の結果のばらつきを見ます。異なるプロトコルのエンドポイントが別のデータセンターや出口を使っている場合、「現在の環境ではどちらが適しているか」は比較できますが、差のすべてをプロトコルの仕組みに帰することはできません。

短時間の接続テストでは、ページを初めて開く場合と続けて開く場合の違いを確認できます。ただし、ブラウザーのキャッシュ、接続プール、HTTP接続の再利用に注意してください。継続的な転送では、Web、音声通話、リモート端末の操作が圧迫されていないかも確認します。ダウンロード速度が上がる一方で操作が明らかに重くなる場合、キューの蓄積が疑われ、全体的に改善したとは限りません。ノード一覧のテスト結果は通常、指定されたテスト先への通信しか示さず、対象アプリでの検証には代わりません。また、サーバー側のリソース消費を間接的に測った値でもありません。

CPUとメモリは実行環境と合わせて見る

クライアント全体のリソース消費には、GUI、コア、ルールセット、DNSキャッシュ、接続追跡、ログが含まれます。プロトコルはその一要素にすぎません。ルールや接続が増えるとメモリ使用量が上がることがあります。詳細ログ、接続一覧の頻繁な更新、画面描画も負荷を増やします。比較ではログのレベルとルールの規模をそろえ、アイドル時の使用量と通信中の増加分を分けてください。デスクトップのタスクマネージャーに表示されたアプリ全体の使用量を、特定のプロトコルヘッダーが複雑である証拠として扱うことはできません。

暗号化アルゴリズムがハードウェア支援に対応しているか、省電力モードか、システムが動作周波数を制限しているかによってもCPUの結果は変わります。低価格ルーターと最新ノートPCでは、順位が逆になることもあります。サーバー側CPUの過負荷もクライアントの速度を不安定にする要因ですが、手元の観察だけでは特定できません。サーバーの監視情報や設定提供元の説明も参考にしてください。テスト中の発熱や処理速度の低下も記録し、熱による制限をプロトコル固有の上限と取り違えないようにしましょう。

電池消費はプロトコル名だけでなく通信状態で決まる

モバイル端末の電池消費は、無線の起動、電波が弱い場所での再送、接続維持、バックグラウンド制限、画面の明るさなど複数の要因に左右されます。長時間のスループット測定は転送効率の比較には適していますが、1日の待機時の電池持ちを示すものではありません。少量のデータを頻繁に送ると無線が起動した状態の時間が長くなる場合があります。逆に接続を頻繁に切りすぎると、ハンドシェイクが繰り返されます。QUIC、TCP、システムプロキシ、TUNのどれが省電力かは、名称だけでは判断できません。実際の通信量やバックグラウンド動作のほうが重要なこともあります。

調整では一度に1つの条件だけを変え、元の設定を残してください。まず不要な高頻度ログや画面の更新を止め、その後に接続維持、同時接続数、プロトコル設定の変更が必要か判断します。エンドポイントを変えた後に電池消費が下がっても、出口回線や電波状況も変わっていれば、確認できたのはその組み合わせの結果です。一般的な利用者にとっては、最高スループットが少し高くても常に調整が必要なものより、接続が安定し、待機中も許容でき、復旧しやすいエンドポイントのほうが実用的です。

原版Clash、Meta、mihomoの関係

原版Clashは、設定、プロキシグループ、ルールによる振り分けの仕組みを確立しました。その後、互換性や機能拡張を目的とする複数の派生系が登場しました。Clash Metaは後にmihomoの名称で開発が続いたため、現在Metaとmihomoについて語る場合、多くは同じ系譜を指しており、別々のコアを両方インストールする必要があるわけではありません。古い記事にMetaという名前が残っているのは珍しくありません。資料が現在も参考になるかは、タイトルの名称ではなく、設定フィールドと実装機能を確認してください。

GUIクライアントとネットワークコアは別のもの

Clash Plus、Clash Verge Rev、FlClashなどのクライアントは、設定管理やシステム連携を担います。実際のネットワーク動作は、搭載されたコアとビルド方法にも左右されます。GUIクライアントとコアの更新時期は異なる場合があります。設定画面に項目があっても、OSの権限や現在のビルドによって利用できないことがあります。対応機能を調べるときは、アプリの情報画面、コア情報、起動ログを確認してください。インストーラーの名前だけで、すべてのmihomo機能に対応している、または全プラットフォームで同じ動作をすると判断しないでください。

mihomoは原版Clashと比べ、対応プロトコル、ルールの種類、DNS機能、通信取り込み機能が拡張されています。ただし、実際の対応範囲は使用中のビルドのドキュメントで確認してください。原版の多くの基本フィールドを引き続き使えるからといって、新しい設定も旧コアで扱えるとは限りません。よくある移行時の問題は、サブスクリプションに新しいプロトコルやフィールドが含まれているのに、ユーザーがそれを認識しない古い実装を使い続けていることです。詳しくはmihomoと原版Clashコアの比較をご覧ください。

設定の互換性は3段階で確認する

第1段階は構文を解析できるかです。YAMLのインデント、リスト構造、文字列の型などを確認します。第2段階は実装がフィールドを理解するかです。プロキシプロトコル、ルールの種類、DNSオプションなどが該当します。第3段階は実行条件を満たせるかです。TUNの権限、システムルート、ポートの使用状況、サービスの状態などを確認します。第1段階を通過したのはファイルを読み込めるというだけで、残り2段階が成立する保証にはなりません。「インポートできたのに使えない」場合は、この3段階に沿って原因を調べてください。

TUNモードでは、特に役割の境界をまたぐため問題が起きやすくなります。クライアントはシステムの通信取り込み機能を作成または呼び出し、コアは取り込まれたトラフィックを処理し、OSは権限やルートを許可するか判断します。スイッチを有効にしても効果がない場合は、サービスが動作中か、ルートが設定されたか、他のVPNやネットワークツールと競合していないか確認してください。プロトコルを変えると一時的に症状が変わることはありますが、通信取り込み層の問題は解決しません。システムのネットワーク設定を変更する前に現在の設定を保存し、通信取り込みを無効にして元に戻す方法も用意してください。

クライアントは、当サイトではClash Plusを第一候補としています。利用するプラットフォームと必要な機能に対応したインストール項目を選んでください。LinuxではClash Verge RevとFlClashを優先して比較できます。他のプラットフォームやアーキテクチャ向けの候補はクライアントダウンロードページをご覧ください。Clash for WindowsとClashX Metaは開発が終了したアーカイブ版です。古い記事の画面に見覚えがあるという理由だけで、新規インストールの第一候補にするのはおすすめしません。移行時は旧設定のコピーを保管し、新しいクライアントで最小限の接続を確認してから、ルール、DNS、通信取り込みの設定を戻してください。

サブスクリプション形式と設定フィールドの互換性

サブスクリプションは設定を配布する方法であり、プロキシプロトコルではありません。リンク先から完全なYAML、ノード一覧、エンコードされた共有リンクの一覧、別のコア向けのJSONなどが返される場合があります。クライアントでテキストを取得できても、現在のパーサーで読み込める形式とは限りません。インポートできない場合は、ノードのパラメーターを検討する前に、応答の形式と対象クライアントの種類を確認してください。ログイン画面やエラーページ、別形式の設定をYAMLだと思い込み、何度も書き換えてしまうのを防げます。

完全な設定とノードプロバイダーは別の内容

完全な設定には通常、プロキシ、プロキシグループ、ルール、DNS、リスナーの設定が含まれます。ノードプロバイダーは主に、メイン設定から参照できるプロキシ項目を提供します。どちらもYAMLで記述されていても、インポート先を自由に入れ替えられるわけではありません。完全な設定をノード一覧だけを受け付ける場所に読み込むと、構造エラーが起きることがあります。ノード一覧だけを追加しても、プロキシグループやルールがなければ、意図した振り分けができない場合があります。クライアントの「設定をインポート」と「プロバイダーを追加」がそれぞれどの形式を受け付けるか確認してください。

プロトコルの共有リンクに、設定に必要な情報がすべて含まれているとも限りません。リンクのパラメーターで表せるフィールドもあれば、別途の取り決めが必要なものもあります。パーサーによって、名前のエンコード、特殊文字、拡張パラメーターの扱いが異なる場合もあります。ノード名が文字化けしても接続には影響しないことがありますが、パスワード、パス、認証情報が誤ってデコードされれば接続に失敗します。再インポート時に手元で比較できるよう、元のリンクを保管してください。認証情報を含むリンク全体を公開の掲示板に貼り付けないでください。

変換で情報を並べ替えることはできても、機能を追加することはできない

サブスクリプション変換では、既存のノード情報を別の構造に整理できます。しかし、旧コアにHysteria2を新たに対応させたり、設定にないサーバー公開鍵を推測したりすることはできません。変換ツールが未知のパラメーターを削除したり、ルールを置き換えたり、DNS設定を上書きしたりする場合もあります。まず、設定の提供元が現在のコアに対応すると明示している形式を使ってください。変換が必要なら、変換の前後でプロトコルの種類と重要なフィールドを比較し、サブスクリプションのリンクや認証情報が処理中にどのように扱われるかを確認しましょう。

以下は、単体で解析できるローカル振り分けの例です。リモートノードは含まず、リスナーポート、モード、ルールの順序だけを示しています。実行すると、そのリスナーポート経由の接続は直接接続され、プロキシ出口が自動で使われることはありません。コアが起動できるかと、リモートノードに接続できるかを分けて確認するための例です。実際に使う際は、対応しているご自身の設定に戻してください。この部分をサブスクリプションに上書きしても、元のノードが残るわけではありません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

YAMLではインデントの階層が重要です。リスト項目と所属するフィールドの位置をそろえ、タブとスペースを混在させないでください。ポートには適切な数値を指定し、特殊文字を含む文字列はYAMLの構文に従って引用します。まず構文エラーを修正してからプロトコルのフィールドを確認してください。そうしないと、ログに最初の構文エラーだけが表示され、後続の設定にある本当の問題が隠れることがあります。ルールは記述順に評価されるため、広すぎるルールを先に置くと、後続の詳細なルールが機能しない場合があります。詳しくはカスタムルールの構文と優先順位をご覧ください。

サブスクリプション更新前にローカル変更を保存

自動更新でローカル設定がサーバー側の内容に置き換わり、手動で追加したルールやDNS設定が消えることがあります。クライアントに上書き、マージ、独立したルール管理機能がある場合は、適用順序を理解したうえで利用してください。更新に失敗したら、リンクを変更する前にリクエストの状態、応答形式、解析ログを確認します。何度再試行しても期限切れの認証は直りません。また、変換機能を使ってサーバーのエラーページが返された問題を隠すべきではありません。詳しくはFAQの「インストールと設定」または「トラブル対処」をご覧ください。

用途に合わせて選び、原因を調べる手段も残す

実用的な選び方は、6つのプロトコルから永久に使える1つを決めることではありません。普段使うメインのエンドポイントと、条件の異なる予備のエンドポイントを用意します。メインは日常のネットワーク、アプリ、電池持ちの要件を満たすもの。予備はネットワーク経路が変わったのか、ローカル設定に問題があるのか判断するために使います。たとえば、片方はUDPに依存し、もう片方は対応済みのTCP通信を使うなど、違いを説明できる組み合わせが理想です。出所の分からないエンドポイントを大量に残しても、プロトコル名をそろえるだけでは役立ちません。管理の手間も利用コストの一部です。

日常のWeb閲覧とモバイルワーク

Web閲覧、文書作成、メッセージのやり取りでは、接続の安定性とバックグラウンドからの復帰が重視されます。既存のSS、Trojan、その他の対応済みエンドポイントが安定しているなら、そのまま使い、スリープからの復帰、ネットワーク切り替え、長時間待機後の動作を確認しましょう。モバイル端末では、OSによるバックグラウンド動作の制限や、別のVPNとの競合も確認してください。iOSではダウンロードページからClash Plusを選び、公式サイトのclashplus.ioに記載された情報も確認できます。Androidでは、電池の最適化設定とアプリの通信取り込み範囲に特に注意してください。

大容量ファイル、弱いネットワーク、リアルタイムアプリ

継続的なダウンロードを行う場合、利用中のネットワークでUDP経路が安定していることを確認したうえで、Hysteria2やTUICを既存のTCP系エンドポイントと一緒に比較できます。電波の弱い環境では、ピークスループットより接続成功率、復旧時間、操作時の遅延の揺らぎを先に見ましょう。ゲーム、音声通話、リアルタイム通信では、アプリの通信が実際に取り込まれているか、ノードが必要なデータグラム転送に対応しているか、サーバーの出口が接続先に適しているかも確認します。グローバルモードを有効にしても、システムプロキシの対象外のアプリまで通信が取り込まれるとは限りません。必要であれば、対応済みのTUN方式を確認してください。

リアルタイムアプリで問題が起きたら、「ログインできるがセッションに入れない」「音声が片方向だけ」「継続的に映像や操作が途切れる」など、症状を分けて記録します。それぞれ異なる接続やポートが関係している可能性があります。まず接続一覧に対象の通信が表示されているか確認し、次にどのルールとポリシーが適用されたかを見てから、プロトコルを切り替えてください。別のプロトコルで改善しても、UDP対応、サーバー経路、設定の違いのどれが影響したか確認しましょう。一度うまくいった切り替えを、すべての環境で通用する法則とみなさないことが大切です。

デスクトップ、ルーター、複数人での共有

デスクトップクライアントは、画面からサブスクリプション、ログ、システムプロキシを管理するのに適しています。サーバーやルーターでは、リスナーのアドレス、権限、プロセス管理、リソース制限をより意識する必要があります。LAN接続を許可すると待ち受ける範囲が広がるため、アクセス制御も設定してください。ローカル端末だけで使う初期設定を、そのまま共有ネットワークに適用するのは危険です。コア単体のパッケージには、GUIクライアントが提供するシステム連携機能がすべて含まれるわけではありません。一般の利用者はまずGUIクライアントを選び、「より低レイヤー」を求めて運用を複雑にする必要はありません。

複数人で共有する場合、プロトコルヘッダーの違いより、帯域の競合、DNSの方針、ルールの管理が重要になることがあります。ある端末の大容量ダウンロードで他の端末が遅くなるなら、各端末のプロトコルを次々に切り替えるのではなく、帯域使用量とキューを確認してください。ルーターの負荷が高い場合は、CPU性能、接続数、ルールの規模も調べます。機器のリソース不足は実行環境の制約です。複雑なルールを増やしたり通信取り込み機能を追加したりしても、解決できるとは限りません。

最短の手順でトラブルを切り分ける

まったくインポートできない場合は応答内容と構文を確認します。インポートできてもコアが起動しない場合は、フィールド、ポート、権限を確認します。起動するのにノードへ接続できない場合は、認証、TLS、通信経路を調べます。ノードに接続できても特定のアプリだけ使えない場合は、通信の取り込み、DNS、ルール、アプリ自体を確認してください。一度に変更するのは1つの条件だけにし、変更前後の結果を記録します。クライアントを起動してもすぐ終了する場合は、プロトコル速度を議論する前に起動時クラッシュをログから特定する手順を確認してください。

メインのエンドポイントが安定し、予備のエンドポイントでネットワークの問題を切り分けられ、設定更新で重要な変更が失われないなら、その構成は継続して運用する価値があります。プロトコル解説の目的は、次に問題が起きたとき、明確な層に沿って原因を説明できるようにすることです。すべての設定を常に複雑にしておくためではありません。検証済みの組み合わせを絞って管理するほうが、プロトコル名の変化を追い続けるより長く使いやすいでしょう。