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

プロトコル、転送方式、接続の階層

クライアント、コア、サーバーを区別する

クライアントのノード一覧から1つ選ぶときに選択しているのは、プロトコル名だけではなく、一連の接続パラメーターです。クライアントはサブスクリプションの表示や設定の管理、システムプロキシの設定を担当します。コアはルールを解析してサーバーに接続し、データを転送します。サーバーはクライアントの代わりに接続先へアクセスします。それぞれ異なるプロジェクトが開発しており、更新のタイミングも一致しません。そのため、画面上で項目を保存できてもコアが利用できるとは限らず、コアがプロトコルに対応していてもサーバー側にその接続口が用意されているとは限りません。

一般的なノード設定には、サーバーアドレス、ポート、プロトコル種別、認証情報が含まれます。さらに暗号化方式、TLSサーバー名、転送パス、QUICのパラメーターが必要な場合もあります。これらの項目がプロトコルの取り決めを構成するため、サーバー側の設定と1つずつ一致させる必要があります。Shadowsocksノードの種別をTrojanに変更しても、プロトコルが変換されるわけではありません。サーバーアドレスが同じでも、対応する待ち受け設定と別の認証・転送パラメーターがサーバー側に必要です。

プロトコル名と下位のネットワーク層は別

Shadowsocks、VMess、Trojan、VLESSは、プロキシ通信における認証、カプセル化、転送の取り決めを示します。TCPとUDPはデータを運ぶトランスポート層のプロトコル、TLSは認証付きの暗号化通信路を提供します。WebSocketやHTTP/2などが、さらに下位の転送方式として使われる場合もあります。Hysteria2とTUICはQUICを重要な基盤としています。互換性を判断するときは各階層を分けて考えましょう。どちらにもTLSと書かれていても、相互に接続できるとは限りません。

アプリがUDPを必要とすることと、ノードが下位層でUDPを使うことも区別が必要です。音声アプリがUDPデータグラムを生成しても、プロキシが別の通信路にカプセル化する場合があります。ブラウザーが主にHTTPSへアクセスする場合でも、QUIC型プロキシを経由することがあります。ノード詳細のudpスイッチは通常、UDPの転送を許可するかどうかを示すもので、TCP接続を自動的にQUICへ変換する機能ではありません。アプリ、プロキシの接続口、サーバーの出口のそれぞれが、最終的な動作に影響します。

アクセス時に行われる判定

リクエストがコアに届くと、通常はドメイン名、宛先アドレス、ルールに基づいてポリシーグループを選び、次にそのグループから実際の出口を選択します。DNS名前解決がローカル、コア、リモートのどこで行われるかは、設定やルールの要件によって異なります。その後、コアがサーバーへの接続を確立し、必要な認証とハンドシェイクを行ってから、アプリのデータを転送します。この段階でアクセスに失敗しても、原因はDNS、ルール、サーバー接続、接続先サイトなどさまざまです。タイムアウト表示だけでプロトコルが使えないと判断しないでください。

システムプロキシとTUNもリクエストの入口であり、ノードのプロトコルではありません。システムプロキシは、アプリがローカルのHTTPまたはSOCKS接続口を利用することで機能します。TUNは仮想ネットワークインターフェースを通じて、ルーティング条件に合う通信を受け取ります。TUNを有効にすれば取り込める通信の範囲は広がりますが、誤ったパスワード、証明書名、サーバーポートは直りません。特定のアプリだけ接続できない場合は、まずその通信がコアに届いているか確認してから、プロトコルの変更を検討しましょう。

選ぶ順序は、まずサーバーが提供する方式を確認し、次にコアの対応状況を確かめ、最後にネットワークへの適性を比較します。プロトコルの機能、クライアントの機能、通信の入口はそれぞれ独立した要素です。

本ガイドで示す速度やリソースの比較は、あくまで条件付きの目安であり、プロトコルに固定の順位を付けるものではありません。同じプロトコルでも、回線、サーバー負荷、プロセッサー、通信事業者のネットワークによって結果は大きく変わります。初期設定では、まず初心者向けガイドに沿って接続を一通り確認し、その後このページの方法で一度に1つの条件だけを変えて比較してください。DNS、TUN、プロトコル、ルールを同時に変更すると、原因を特定できなくなります。

ShadowsocksとVMess

Shadowsocks：シンプルな暗号化転送

Shadowsocks（SS）は、ローカルプロキシへのリクエストを暗号化された通信路でサーバーへ転送する仕組みです。一般的な設定は比較的シンプルで、サーバー、ポート、暗号化方式、パスワードが主な項目です。外側にTLSや追加の転送方式を重ねる構成に比べ、直接転送するプロトコルスタックは通常短く、仕組みを理解しやすく導入も容易です。ただし、設定項目が少ないからといって、安全性がパスワードの長さだけで決まるわけではありません。暗号化方式、実装の品質、鍵の管理も重要です。

Shadowsocksでは、歴史的にさまざまな暗号化方式が使われてきました。既存のサーバーを使う場合は、提供元が明示的に対応する現代的なAEAD方式を優先し、古いクライアントとの互換性だけを理由に旧式の方式へ安易に切り替えないでください。AEADは暗号化とメッセージ認証を同時に行い、データの改ざんを検出できます。比較的新しいプロトコルの派生版では、異なる鍵形式やセッション処理を導入しているものもあります。方式名を変更するだけで旧式のサーバーと通信できるわけではありません。

設定時はcipherをサーバー側と完全に一致させる必要があり、パスワードにも形式上の制約がある場合があります。特に一部のShadowsocks 2022方式では、指定された長さのBase64鍵が必要です。一般的な短いパスワードをそのまま設定することはできません。AESとChaCha20のどちらを選ぶかは、端末が対応するハードウェアアクセラレーションを備えているかも踏まえて検討しましょう。デスクトップのプロセッサーで得られる利点が、低消費電力のルーターでも同じとは限りません。名称から推測するより、実際にスループットを測定するほうが確実です。

プラグインとUDPも互換性に関わる

プラグインを使用するShadowsocksノードでは、クライアントのコアが同じプラグインとオプションに対応している必要があります。共有リンクをインポートできても、パーサーが基本構造を認識しただけで、プラグインのパラメーターがすべて保持されたとは限りません。接続直後に切断される場合は、パスワードを何度も入力し直すのではなく、元の情報を参照してプラグイン名、ホスト項目、転送オプションを確認しましょう。プラグインによってプロトコルスタックや導入条件も変わるため、すべてのSSノードを同じ性能モデルとして扱うことはできません。

UDPを利用するには、クライアントとサーバーの両方が対応している必要があります。クライアント側でUDPが許可されていても、サーバーが転送を提供し、ホストのファイアウォールが該当する通信を許可していなければ、音声やゲームに問題が生じる可能性があります。Webページを表示できても、それは該当するTCPリクエストが成功したことを示すだけで、UDP経路が使える証明にはなりません。プラグインを使う場合は、プラグインがUDPをどこまで扱えるかも確認してください。直接転送方式の機能をプラグイン経由の通信にそのまま当てはめることはできません。

VMess：認証方式と転送方式の組み合わせ

VMessはV2Rayエコシステムから生まれ、ユーザー認証とプロキシデータのカプセル化を備え、複数の転送方式と組み合わせて使えます。VMessを比較する際は、TLSを使うか、WebSocketなどの中間層を経由するかを少なくとも明らかにする必要があります。そうしなければ、「VMessは遅い」といった比較は対象が曖昧です。直接TCPで接続する構成と多層カプセル化の構成では、ハンドシェイク、バッファー処理、サーバーでの処理経路が異なります。最終的なオーバーヘッドはVMess自体だけで決まるとは限りません。

現在のVMess設定では通常AEAD認証が使われます。古い資料にあるalterIdや旧式の認証設定をそのまま使うのは避けましょう。互換用の項目が残っていても、旧来の動作をあえて有効にすべきとは限りません。認証には時刻が関係するため、端末の時計も正確に保ってください。システム時刻が大きくずれていると認証に失敗することがあります。問題を調べる際は暗号化オプションを次々に切り替えるより、まず時刻を同期し、UUID、転送方式、TLS、サーバー側のパスを確認するほうが効果的です。

使い分けの目安は、信頼できるSSサーバーがすでにあるなら設定の簡潔さが利点となり、V2Rayの転送環境をすでに運用しているならVMessのエコシステムとの互換性が重要になる、という点です。プロトコル名が新しいという理由だけで、既存の環境を一式作り直す必要はありません。新たに選ぶ場合は、クライアントの対応状況、サーバーの保守状況、サブスクリプションでパラメーターを完全に表現できるかを確認しましょう。「設定項目が多い」「登場が新しい」といった理由だけで価値を判断するべきではありません。

Trojan、VLESSとTLS

Trojan：TLS通信路内でプロキシ認証

Trojanは、プロキシ通信をTLS通信路内に置き、プロトコル層でパスワード認証を行う設計が特徴の1つです。独自のデータ暗号化・カプセル化を備えるプロトコルと異なり、通信の保護には成熟したTLSの仕組みをより多く利用します。そのため、証明書、サーバー名、TLSハンドシェイクは任意の追加項目ではなく、接続の成立に不可欠です。従来のTrojan設定は比較的分かりやすいものの、実際の導入では別の転送方式を重ねることもあるため、サーバー側の説明に沿って設定してください。

サーバーアドレスにIPアドレスを使い、証明書はドメイン名に対して発行されていることがあります。その場合、クライアントにサーバー名を別途指定し、TLSハンドシェイクで正しい名前を使って証明書を検証する必要があります。この名前は一般にSNIと呼ばれますが、クライアントによって項目名は異なります。接続できるドメインなら何でも指定してよいわけではなく、WebSocketのHostと同じとも限りません。Hostは別のプロトコル層に属し、構成によっては両者が同じ場合も異なる場合もあります。

証明書エラーは、具体的な原因に応じて対処してください。システム時刻、証明書の有効期限、名前の一致、証明書チェーンの完全性、ローカルのHTTPS検査ツールの有無を確認します。証明書検証を無効にしたまま使うことを恒久的な解決策にしてはいけません。検証を無効にすると接続先の身元を確認する重要な保護が失われ、ネットワーク経路上の機器がサーバーになりすましやすくなります。対処の手順はHTTPS証明書エラーの原因と対処法をご覧ください。

VLESS：軽量な認証と独立した暗号化は別

VLESSはV2Ray関連のエコシステムから発展し、軽量な認証と転送構造を重視しています。重要なのは、VLESS自体が一般的な意味での独立した通信暗号化を提供しない点です。全体の保護を判断するには、TLSやREALITYなど、適切なセキュリティ層と組み合わせる必要があります。ノード種別がVLESSというだけでは、安全性や接続コストは分かりません。転送方式、セキュリティ層、任意のフロー制御設定も確認してください。

REALITYは特定のセキュアな転送方式であり、TLSスイッチの別名ではありません。公開鍵、短いID、サーバー名、関連するハンドシェイク設定を組み合わせる必要があり、利用できるかどうかはコアの実装にも左右されます。Visionなどのflowオプションも適用できる構成が限られ、すべてのVLESS接続で有効にできるわけではありません。サーバー側が対応する構成を使っていない場合、クライアントにパラメーターを追加すると接続に失敗します。他のノードから一見完全に見える設定をコピーしても、サーバー側の実際のパラメーターの代わりにはなりません。

VLESSを選ぶ場合は、まず提供されている具体的な構成を確認し、次に現在のコアが対応しているかを確かめてください。クライアントでVLESSの共有リンクをインポートできても、リンクに含まれるすべての拡張機能をコアが使えるとは限りません。特に古いクライアント、変換済みのサブスクリプション、上書きされた設定では、項目が無視、変更、削除されていることがあります。問題の調査では、サブスクリプション一覧に表示されたプロトコル名だけでなく、最終的にコアへ渡された設定を確認しましょう。

ハンドシェイクの再利用と遅延の実際

TLS通信路の確立には通常、下位の接続とセキュリティハンドシェイクが必要です。初回接続と、すでに確立した接続上の後続リクエストでは、所要時間の内訳が異なります。セッション再開、接続の再利用、接続先サイト自身のHTTP接続も体感速度を左右します。そのため、クライアントの単発の遅延テストで分かるのは、テスト対象の経路における接続確立と応答の状況が中心です。長時間のダウンロード、動画再生、複数アプリの同時利用時の性能まで単独で示すものではありません。

TrojanとVLESSはどちらも適切な選択肢になり得ます。従来のTLS構成では、Trojanはパスワードと証明書を手掛かりに問題を切り分けやすく、VLESSは適切なセキュリティ層と組み合わせることで柔軟な構成が可能です。実際の選択は、既存サーバーと保守体制を基準にしてください。拡張機能を増やせば必ず改善するわけではありません。転送方式や特殊なオプションを追加するたびに互換性の確認項目が増え、将来のトラブルシューティングで説明すべき変数も増えます。

証明書の検証、サーバー名、アプリケーション層のHost、プロトコルの認証情報は、それぞれ異なる役割を担います。1つが正しくても、別の項目の誤りを補うことはできません。証明書の警告が出た場合は、まず原因を調べてください。

Hysteria2、TUICとQUIC

UDPベースの転送方式が使われる理由

QUICはUDP上でセキュアな接続、信頼性の高い転送、複数ストリームなどを実現し、TLSハンドシェイク機能も統合しています。「配信を保証しない高速なTCP」ではなく、従来トランスポート層が担っていた多くの機能をユーザー空間のプロトコルスタックに組み込んだものです。Hysteria2とTUICはどちらもQUICを利用しますが、認証、輻輳制御の選択、データグラムの扱い、設定構造は異なります。相互接続はできず、UDPを使うという共通点だけで設定を流用することもできません。

QUICの大きな特徴の1つは、複数のストリーム間でTCP層の順序どおりの配信制約を共有しなくてよいことです。あるストリームでパケットロスが発生しても、ほかのストリームのデータは配信を続けられる可能性があり、ストリーム間の一部の遅延を抑えられます。ただし、共通の輻輳制御、回線容量、プロセッサー性能の制約は受けます。すべてのストリームが同じ混雑した回線を奪い合う場合や、サーバー負荷が高い場合、プロトコル自体が帯域を増やすことはできず、すべての通信が同時に高速化する保証もありません。

Hysteria2：帯域幅パラメーターと輻輳制御

Hysteria2は、複雑な回線環境でのスループットを重視した設計で、設定やネゴシエーションの条件に応じた輻輳制御が可能です。一部の構成では上り・下りの帯域幅を指定しますが、これらはアルゴリズムやサーバーの制限判定に使う入力値であり、速度測定の結果ではありません。大きな値を設定するほど速くなるわけでもありません。実際の上り速度を大きく上回る値を設定すると、キューの増大やパケットロスを招き、ほかのアプリの使い勝手が悪化することがあります。家庭用ブロードバンドや共有のモバイル回線では特に注意してください。

実装やサーバーの方針によって、帯域推定、明示的な速度パラメーター、その他の輻輳制御方式が使われます。共通のサンプルからすべてのHysteria2ノードに同じ設定が必須だと判断せず、サーバーの要件に従って入力してください。パスワード、TLSサーバー名、任意の難読化設定、ポート範囲もサーバー側と一致させる必要があります。ポートホッピングは基本的な接続性の代わりにはなりません。サーバー側で開放されていなければ、有効にしても接続口は増えません。

名前が似ていても、プロトコルの世代間で互換性があるとは限りません。HysteriaとHysteria2にはプロトコル上の違いがあるため、クライアントで正しい種別を選んでください。変換ツールが名称だけを頼りに判定すると、見た目は整っていても認証できない項目が生成されることがあります。ハンドシェイクに失敗した場合は、帯域幅や高度なオプションを調整する前に、提供元が指定するプロトコルの世代、UDPの到達性、証明書、認証項目を確認しましょう。

TUIC：接続の多重化とデータグラム転送

TUICもQUICを基盤とし、一般的な設定にはUUID、パスワード、TLS関連パラメーターが含まれます。UDP転送方式、輻輳制御、接続維持のオプションが用意されている場合もあります。プロトコルの進化過程には互換性のない旧実装もあるため、TUICという名前のサービスならどのクライアントでも使えると考えてはいけません。サーバーが指定する要件とコアの対応範囲を照合し、共有リンクの接頭辞だけで互換性を判断しないでください。

対話型アプリでは、データグラムをどのように運ぶかが特に重要です。データグラムを信頼性の高いストリームに載せる方式では、パケットロス時に再送を待つ場合があります。信頼性のないデータグラムを使う方式は元のUDPの動作に近い一方、経路MTU、データグラムのサイズ、実装方針の影響を受けます。音声、ゲーム、ファイル転送ではパケットロスや待ち時間への許容度が異なるため、同じスイッチですべての用途を改善することはできません。高度なモードをむやみに有効にするより、通常は既定の設定を維持するほうが安全です。

UDPが利用できない場合の制約

公衆Wi-Fi、企業ネットワーク、ルーター、通信事業者の回線でUDPが制限されることがあり、NATがアイドル状態のマッピングを早く削除する場合もあります。そのような環境ではQUICベースのノードがハンドシェイクできなかったり、画面消灯後の再接続に時間がかかったりします。Hysteria2やTUICをカーネルが自動でTCPプロトコルに変換すると期待するのではなく、検証済みのTCP型出口を独立した予備として用意してください。自動切り替えには、明確なポリシーグループと利用可能なノードが必要です。

QUIC型プロトコルは、UDP経路が利用できることを条件に、実測して比較する候補に加えられます。利点はプロトコル名そのものではなく、具体的な転送方式と回線環境から生まれます。

接続速度、リソース、モバイル端末の電池消費

「速度」を複数の指標に分ける

接続速度には少なくとも、初回接続にかかる時間、最初のデータを受け取るまでの時間、持続スループット、複数接続時の応答性があります。Webページの初回表示が遅い場合は、DNS、プロキシのハンドシェイク、接続先サイトが原因かもしれません。大容量ファイルの転送速度は、回線帯域、パケットロス、サーバーの速度制限、CPUの制約を受けます。ゲームや音声通話では遅延の変動やパケットロスが重要で、ダウンロード速度で代用できません。測定前に改善したい用途を決めておけば、確認すべき指標が分かります。

遅延テストでは通常、プロキシ経由で指定されたアドレスへリクエストを送ります。測定値は端末からサーバーまでの純粋な往復時間ではなく、名前解決、安全な接続のハンドシェイク、接続先の応答、接続の再利用状況も含む場合があります。テスト先が異なるクライアント同士では、数値をそのまま比較できません。テストに成功すれば、その時点で特定の経路から応答があったことは分かりますが、すべてのサイトへ接続できるとは限らず、アプリに必要なUDP転送に対応している証明にもなりません。

プロトコルのオーバーヘッドとハードウェア負荷

直接転送のSSは通常、カプセル化が少なめです。TLSと追加の転送方式を組み合わせると、ハンドシェイクやフレーム処理が増えます。QUICの実装では、暗号化、輻輳制御、タイマー、ユーザー空間でのパケット処理が必要です。これは仕組みの違いであり、性能の固定順位を示すものではありません。最新のデスクトップ端末なら軽く処理できる一方、高負荷時の低消費電力ルーターやスマートフォンでは、単一コアの処理能力、温度制御、メモリー帯域の限界に先に達することがあります。

メモリー使用量はプロトコルだけでは決まりません。同時接続数、接続バッファー、ルールセット、DNSキャッシュ、ログレベル、クライアントの画面も使用量に影響します。同じコアを使っていても、一方のクライアントでより多くのルールを読み込み、詳細なログを保持していれば、メモリー使用量に大きな差が出ることがあります。比較する際は設定の規模をそろえ、不要なデバッグログを無効にし、GUIプロセスとコアのプロセスを分けて確認しましょう。画面が使うリソースをノードのプロトコルに誤って帰属させないよう注意してください。

スマートフォンの電池消費は、まず通信の使い方を見直す

スマートフォンの電池消費は、無線電波の状態、データ量、端末の起動頻度、接続維持の方法に左右されます。電波が弱い環境では、無線モジュールの送信や再送にかかる電力がプロトコルの暗号化処理を上回ることがあります。頻繁すぎるヘルスチェック、サブスクリプション更新、キープアライブ、ログ書き込みも、端末が低消費電力状態に入りにくくする要因です。プロトコルを選ぶ前に、高頻度の速度測定が有効になっていないか、複数のプロキシやVPNアプリが通信の入口を奪い合っていないか確認しましょう。

キープアライブにはトレードオフがあります。間隔を短くするとNATマッピング失効後の再接続を減らせる可能性がある一方、バックグラウンド通信と無線の起動が増えます。間隔が長ければ維持コストを抑えられますが、接続復帰に時間がかかることがあります。QUICの接続移行機能も、プロトコルの実装、サーバー、クライアントの設定に左右されるため、Wi-Fiとモバイル回線の切り替え時に接続が必ず維持されるとは限りません。モバイルでは、単発の最高速度より待機後に安定して復帰できることのほうが重要な場合があります。

同じ端末、同じネットワーク、同じ接続先、近い時間帯で、起動直後のアクセス、持続的な通信、一定時間待機した後の復帰をそれぞれ記録しましょう。毎回ノードまたはプロトコルを1つだけ変更し、数回繰り返して傾向を確認しながら端末温度にも注意してください。電池消費を比較するには、近い負荷条件と十分な観察時間が必要です。十数秒の速度測定で電池残量にほとんど変化がないからといって、特定のプロトコルが省電力だとは判断できません。

長時間の通信で通話やWebページの応答が悪化する場合は、まず大容量タスクを制限し、ローカルのキューと帯域幅の設定を確認してから、プロトコルの変更を検討してください。プロトコルによって回線の挙動を改善できる場合はありますが、すでに飽和した上り回線で無制限の通信を同時に処理することはできません。最高速度の数値だけでなく、安定性、復帰速度、保守のしやすさも結果に含めるほうが、日常の使い勝手をより正確に把握できます。

Clash、Metaとmihomo

名称の関係と機能の範囲

オリジナルのClashは、プロキシ、ポリシーグループ、ルールをYAMLで記述する使い方を確立しました。Clash.Metaはそのエコシステムから発展した派生版で、プロトコルやネットワーク機能を拡張しました。mihomoはMeta系の開発を引き継いでいます。古い資料、サブスクリプション形式の選択肢、クライアントの設定には、今もMetaという名称が残っている場合があります。Clash Metaの解説を見つけたら、名称だけで適用可否を判断せず、記事が説明するコアの機能を確認してください。

オリジナルのClashにも歴史上さまざまな配布形態があり、すべてが同じ機能を備えていたわけではありません。オープンソースの実装と過去の別の配布形態を、同じ機能セットとして扱うことはできません。古い記事では、ルールセット、TUN、スクリプト、特定の設定項目の説明が、当時の特定の実装だけを対象にしていることがあります。新しいプロトコルを選ぶ際は、実際に動作しているコアとその設定ドキュメントを確認してください。過去の記事の機能一覧をすべてのClashクライアントに共通する基準として扱ってはいけません。

mihomoは複数の最新プロトコルやDNS、TUN、ルール機能の対応を追加・継承していますが、対応範囲は実装の進化とともに変わります。設定ドキュメントに項目があっても、古いバイナリで実装済みとは限りません。反対に、クライアント名にMetaが含まれないからといって、mihomoを使っていないとは断定できません。確かな手掛かりは、クライアントに表示されるコア情報、起動ログ、実際の読み込み結果です。アプリアイコンやインストーラーの名前だけで判断しないでください。

設定の互換性は項目ごとに確認する

基本的なポート、一般的なポリシーグループ、ルールには共通する構文が多く、設定を移行できる場合があります。ただし互換性は項目単位であり、ファイル全体が無条件に使えるわけではありません。オリジナルの設定をmihomoへ移行する場合も、廃止された動作、パス、プラットフォーム固有の機能を確認してください。VLESS、Hysteria2、TUIC、拡張DNS項目を含む設定が、古いコアで完全に認識されるとは期待できません。未知の項目はエラーになる場合も無視される場合もあるため、どちらも確認が必要です。

クライアントが読み込み前に最終設定を生成することもあります。サブスクリプションの統合、ローカルポートの追加、コントロールインターフェースの設定、DNSの上書き、ルールの注入などがその例です。サブスクリプションの元ファイルを編集しても反映されない場合、コアが未対応なのではなく、その後の上書きで変更が消えている可能性があります。調査時は実行中の設定またはエクスポート機能を使い、最終的な項目を確認してからログと照合してください。コアに直接渡されていない中間ファイルを何度も編集しないようにしましょう。

クライアント選びとOSとの連携

デスクトップとモバイル端末では、まずClash Plusのダウンロードとプラットフォーム別の選択肢を確認し、必要なプロトコルが対象OSで使えるかも調べましょう。Linuxデスクトップでは、ダウンロードページからClash Verge RevまたはFlClashを選べます。WindowsではClash Nyanpasuも比較できます。Clash for WindowsとClashX Metaは保守が終了したアーカイブ版です。古い画面を使い続けるためだけに、新しいプロトコルを使う際の標準として選ぶのはおすすめできません。

AndroidではClash Plus、Clash Meta for Android、FlClash、Surfboardを比較できますが、これらのアプリが同じコアや設定形式を使うとは限りません。iOSではネットワーク拡張機能やバックグラウンド動作もシステムの仕組みに左右されます。プラットフォームをまたいで設定を移行する際は、同じデスクトップ用の実行設定がスマートフォンでもそのまま使えると考えず、「必要なプロトコルに対応しているか」「現在のサブスクリプションを受け付けられるか」「どのように通信を取り込むか」を改めて確認してください。

Ubuntu：GUIと独立したサービス

Ubuntuデスクトップでは、GUIでシステムプロキシや設定を管理する方法が一般的です。サーバー環境や常時稼働が必要な環境では、mihomoを個別に導入できますが、設定ディレクトリ、実行ユーザー、ログ、TUNの権限を自分で管理する必要があります。デスクトップクライアントとsystemdサービスで同じポートを使ったり、ルートを奪い合ったりしないようにしてください。詳しい手順はUbuntuへのmihomoコアの導入をご覧ください。

mihomo -v
mihomo -t -d "$HOME/.config/mihomo"

1つ目のコマンドで実際の実行ファイル情報を確認し、2つ目で指定ディレクトリ内の設定がコアのテストに通るか確認します。コマンドがインストール済みで、ディレクトリにconfig.yamlがあることが前提です。テストに合格しても、その段階で設定エラーが見つからなかったことを示すだけで、ノードに接続できる保証にはなりません。アップグレード前に設定と既存の実行ファイルを保存し、テスト後にサービスを置き換えてください。コアの更新、サブスクリプションの再取得、ルートの変更を同時に行うのは避けましょう。

サブスクリプション形式と設定の互換性

共有リンク、ノード一覧、完全な設定ファイル

共有リンクは通常、単一のノードを記述します。プロトコルの接頭辞の後に、エンコードされた認証情報やクエリーパラメーターが含まれることがあります。ノード一覧は複数のリンクの場合も、YAML形式のプロキシ項目の場合もあります。完全な設定ファイルには、さらにポリシーグループ、ルール、DNS、ローカルの待ち受け設定が含まれます。それぞれ役割が異なります。共有リンクをインポートできるアプリでも、完全なClash YAMLを読み込めるとは限りません。YAMLを読み込めても、あらゆるプロキシ種別に対応しているとは限りません。

サブスクリプションURLは、内容を取得するための入口にすぎません。同じサービスでも、形式の選択やリクエストパラメーターによって返されるデータが異なる場合があります。ファイルの拡張子だけでは実際の形式を確実に判断できません。インポート後に一覧が空の場合は、まずクライアントが求めるサブスクリプション種別を確認し、ログインページ、エラーテキスト、非対応形式が返されていないか調べましょう。個人用の識別情報を含む完全なURLを公開ページに貼り付けないでください。他人がサブスクリプションの内容を取得したり、利用枠を消費したりできる可能性があります。

サブスクリプション変換でできることと制限

サブスクリプション変換ツールは、共有リンクをYAML形式のノードに変換し、ポリシーグループやルールを組み合わせるなど、表現形式を変更できます。ただし、サーバーにプロトコル機能を追加することはできず、TUIC非対応のコアにTUICの実装を与えることもできません。変換ツールが項目を認識できない場合、プラグインのパラメーター、TLS名、特殊な転送オプションが失われることがあります。その結果、一覧には基本的なノードが表示されていても、実際のハンドシェイクに必要な情報が欠けている場合があります。

サービス提供元が直接配布する形式のうち、現在のコアに合ったものを優先して使いましょう。変換が必要な場合は、信頼でき、明確に必要性のある方法を選び、サブスクリプションの内容を誰が受け取るのか把握してください。オンライン変換ではプロトコル名だけでなく、サーバーアドレスや認証情報も扱われる可能性があります。変換結果を確認する際は、ノード名や件数が一致するかだけでなく、プロトコル種別、認証項目、セキュリティ層、転送オプションを重点的に照合してください。

YAMLのルート階層とポリシーグループの参照

チュートリアルで使われるgeneralは、基本設定の区分を示すことが多く、ファイルに記述する実際のトップレベルキーではありません。ポートやモードなどの項目はYAMLのルート階層に直接記述します。次の最小構成の例にはリモートノードが含まれていません。ローカルの待ち受け、ポリシーグループの参照、フォールバックルールを理解するためのもので、出口には直結を選びます。これだけでリモートプロキシが作られるわけではありません。実際のノードは有効なサブスクリプションまたはサーバーのパラメーターから取得してください。例から認証情報を推測することはできません。

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

proxy-groups:
  - name: 出口の選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口の選択

YAMLではインデントにスペースを使い、リストのハイフンや同じ階層の項目の字下げをそろえる必要があります。ポリシーグループの参照名は正確に一致させてください。名前を変更した場合は、ルールやほかのグループ内の参照も合わせて変更します。名前の重複、存在しないノードやグループへの参照、グループ間の循環参照は、設定の読み込み失敗や予期しない動作につながることがあります。7890番ポートが別のプロセスに使われている場合は、ポート使用中の問題を調べるで原因を確認し、アプリのプロキシ設定も合わせて変更してください。

サブスクリプション更新で変更が上書きされる理由

リモートサブスクリプションから取得した内容を直接編集すると、次回の更新時に新しい内容へ置き換わることがよくあります。クライアントが明示的に対応しているローカル上書き、設定のマージ、ルール拡張機能を使い、適用順序を記録しておくのが安全です。proxy-providersは仕様に沿ってプロキシの集合を読み込むためのもので、rule-providersはルールの集合に使います。どちらも完全な設定ファイルを任意に読み込むための汎用機能ではありません。トップレベル設定をすべて含むファイルを、ノードプロバイダーとしてそのまま使うことはできません。

設定の互換性にはDNSも関係します。ノードを正常にインポートできても、名前解決の異常が原因でWebページを開けないことがあります。fake-ipもリクエストの入口と名前解決経路を連携させる必要があり、項目を1つ有効にしただけでDNSが処理されるとは限りません。名前解決の全体像はnameserver、fallback、DNSハイジャックの設定項目を解説をご覧ください。サブスクリプションを移行するときは、まず基本的な接続を確認し、その後にカスタムDNSとルールを段階的に戻すと、どの層で違いが生じたかを特定しやすくなります。

用途別の選択と結果の検証

普段使いのデスクトップ：まず挙動を把握しやすい接続を

日常のブラウジング、ドキュメントの同期、開発ツールへのアクセスでは、安定した接続と保守しやすい設定が重要です。すでに検証済みのSS、Trojan、その他のTCP型接続口があるなら、プロトコル名を追いかけるためだけに乗り換える必要はありません。クライアントはClash Plusを候補にし、OSや必要な機能に応じてほかの選択肢と比較できます。ルールモードでプロキシ経由と直接接続のリクエストを振り分ければ、転送方式の拡張を増やすより、不要な迂回を減らせることがあります。

開発ツールによっては、システムプロキシではなく環境変数や独自のプロキシ設定だけを参照します。ブラウザーは使えるのにターミナルから接続できない場合は、ツール側のプロキシ設定と証明書環境を確認しましょう。企業向けソフトウェアには独自のネットワークスタックやアクセス方針があることもあります。TUNは適切な用途で利用できる入口ですが、有効にした後もルーティング、DNS、ローカルネットワークへのアクセスを確認してください。アプリがプロキシを使っていない問題を、ノードのプロトコルのせいにしないようにしましょう。

モバイル回線：復帰と待機中の動作もテスト

Wi-Fiとモバイル回線を頻繁に切り替える場合は、回線変更後の初回リクエスト、待機後の復帰、音声通話の継続性、バックグラウンドでの電池消費を確認しましょう。Hysteria2やTUICも比較対象にできますが、対象ネットワークで利用できると確認済みのTCP型の代替経路を残してください。特定の公衆ネットワークでQUIC接続だけ失敗するなら、認証情報をすぐに変更するのではなく、まずUDP経路の制限を疑いましょう。別のネットワークでは同じ設定で成功するという情報は、原因の切り分けに役立ちます。

モバイル端末では、VPNやネットワーク拡張機能に対するOSの管理も考慮してください。バックグラウンド制限、別のVPNアプリの起動、システムの省電力設定、ネットワーク権限の変更によって接続が切れることがあります。ヘルスチェックの頻度を下げ、キープアライブを過度に短くしないことは、プロトコルを何度も切り替えるより先に試す価値があります。通信の入口、権限、バックグラウンド状態をそろえて初めて、プロトコルごとの電池消費を比較できます。

大容量通信と低消費電力デバイス：ボトルネックを見極める

長時間のダウンロード、リモートバックアップ、高い同時接続数を扱う場合は、サーバー負荷、上り回線のキュー、端末温度、単一コアの使用率を確認してください。プロセッサーが先に限界に達するなら、カプセル化が比較的少なく、ハードウェアアクセラレーションに対応する方式を比較できます。主な問題がパケットロスや回線の変動なら、QUIC型の方式を試す方法があります。ルーターではプロセッサーのアーキテクチャ、メモリー容量、UDPの処理能力も確認しましょう。デスクトップ端末でのテスト結果をそのまま適用することはできません。

Ubuntuサーバーへの導入では、サービス管理、障害からの復旧、最小権限を重視します。まず通常のローカルプロキシでコアとノードを検証してから、必要に応じてTUN、ルーティング、起動時サービスを追加してください。変更のたびに設定を確認し、対象のサービスを再起動してログを読みます。デスクトップクライアントとサービスの両方がネットワークを制御しないようにしてください。リモートでルートを変更する場合は、独立した管理経路と元に戻せる方法を確保し、誤った変更で保守用接続を失わないようにしましょう。

再現可能なトラブルシューティングの手順

接続を一通り検証するには、4つの段階に分けます。まずリクエストがローカルのコアに届いているかを確認し、次にサーバーへ接続できるかを確かめます。その後、接続先のドメインが名前解決され、ルールが適用されているか確認し、最後に実際の用途で動作を検証します。ログに認証エラーがあれば認証情報を、証明書エラーなら時刻と名前を確認します。接続タイムアウトの場合は、ネットワーク、ポート、プロトコルを合わせて調べましょう。エラーの種類ごとに確認すべき変数は異なり、クライアントをやみくもに再インストールしても新たな手掛かりは得られません。

動作する設定を比較の基準として保存し、変更のたびに、どの項目を変えたか、どのネットワークでテストしたか、どのような結果になったかを記録してください。ログを共有する前に、サブスクリプションURL、認証情報、個人のアクセス履歴を隠しましょう。見かけ上の成功のためにセキュリティ検証を無効にしてはいけません。操作手順を確認する場合は初心者向けガイドへ、特定のアプリや設定段階だけで起きる問題を探す場合はよくある質問をご覧ください。プロトコル選びの基準は、必要な用途で動作が確認でき、問題の原因を説明でき、設定を長期的に保守できることです。