Clashのプロトコルとコア
技術ガイド

接続のレイヤー：クライアント、コア、プロトコル

画面上の操作と実際の接続を分けて考える

クライアントは設定画面の入り口で、設定一覧、プロキシモード、ログ、スイッチなどを表示します。コアは設定の読み込み、アプリからの接続受付、ルール判定、上流への接続を担います。Clash Nyanpasuの画面とmihomoコアは別のレイヤーに属します。画面に設定項目が表示されていても、起動中のコアがそのパラメーターを受け付けるとは限りません。問題を調べる際は、クライアント名、実際に動作しているコア名、設定の取得元を記録し、デスクトップのアイコンだけで機能を判断しないようにしましょう。

プロトコルは、クライアントのコアとリモートサーバーがデータを認証、カプセル化、転送する方法を定めます。サブスクリプションに記載されたSS、VMess、VLESSは接続方式であり、クライアントの製品名でも地理的な回線の種類でもありません。サーバー側が該当プロトコルと設定を提供している必要があり、クライアントのプルダウンを切り替えても、既存のサーバーが別のプロトコルに変わるわけではありません。プロトコルを選ぶ前に、サーバーがどの接続方式を提供しているか、それぞれが同じサーバーとネットワーク経路を使うかを確認してください。

リクエストを観測可能な段階に分ける

ブラウザーでWebページにアクセスすると、通常はまずドメイン名を解決し、その後、システムプロキシまたは仮想ネットワークインターフェースを経由してコアに接続が渡されます。コアはルールに基づいて直結またはプロキシグループを選び、プロキシグループが上流の接続先を決定します。その後にサーバーとの通信、認証、データの送受信が行われます。どの段階で問題が起きても、Webページが開かないことがあります。そのため、接続できないからといってプロトコル自体に問題があるとは限りません。リクエストがクライアントに届いていない場合や、ルールによって利用できない出口に送られている場合もあります。

トランスポート層とプロキシプロトコルも分けて考えましょう。TCPは信頼性のある順序付きのバイトストリーム、UDPはデータグラムを提供します。TLSは認証と暗号化された通信路を提供し、QUICはUDP上で安全な接続と複数のストリームを構成します。WebSocketは別のカプセル化方式です。VLESSの設定は複数のトランスポートやセキュリティ設定と組み合わせられるため、同じVLESSでもハンドシェイクの手順や遅延、互換性の条件が異なる場合があります。

システムプロキシやTUNでリモートプロトコルは変わらない

システムプロキシは、システムのプロキシ設定に従うアプリからのリクエストを、ローカルの待ち受けポートに転送します。TUNは仮想ネットワークインターフェースを使って、より多くの通信を取り込みます。どちらも変わるのはコアに通信が入る経路であり、リモート側の帯域が自動で増えたり、サーバーにUDP転送機能が追加されたりするわけではありません。システムプロキシでは動かないアプリがTUNで動く場合、まず入口の経路の違いを確認してください。すぐにSSとTrojanの速度差が原因だと判断するのは適切ではありません。

同様に、ルールモード、グローバルモード、直結モードは出口を選ぶ仕組みであり、暗号化プロトコルの種類ではありません。ルールモードはルールを順に照合し、グローバルモードは対象のリクエストをグローバル設定に従って転送し、直結モードはプロキシを経由しません。プロトコルを比較するときはモードとプロキシグループを固定してください。そうしないと、気づかないうちに直結で測定していることがあります。ルールの順序が与える影響については、ルール振り分けの実践ガイドもご覧ください。

おすすめの確認手順：リクエストがコアに届いているか → どのルールに一致したか → どの出口が選ばれたか → サーバーとの接続が確立したか → アプリのデータを正常に送受信できるか。まず問題のレイヤーを特定してから、プロトコルのパラメーターを調整しましょう。

問題を記録するときは、「接続できない」という曖昧な説明ではなく、状況を一文で具体的に書きましょう。例：あるアプリの通信がシステムプロキシ経由でmihomoに入り、指定したプロキシグループに一致した後、特定のプロトコル接続先でハンドシェイクエラーが発生した。このように記録すれば、調査範囲を絞れます。ログのドメイン、アドレス、認証情報には個人の設定が含まれる場合があります。共有前に機密情報を削除してください。初期調査には、通常、エラーの種類、発生段階、設定項目名があれば十分です。

SSとVMess：軽量なカプセル化と多様なトランスポート

Shadowsocksの設計上の特徴

ShadowsocksはSSとも呼ばれ、シンプルな暗号化プロキシとして設計されました。クライアントとサーバーでパスワードと暗号化方式を共有し、比較的少ない設定項目でTCPまたはUDPの通信を転送します。証明書やWebサービス、複雑なトランスポートの組み合わせを必須としていないため、一般的な構成はシンプルです。ここでいう「軽量」とは、プロトコルと導入手順が比較的シンプルという意味で、どの端末でも他のプロトコルよりリソースを節約できるという保証ではありません。実際の負荷は暗号化の実装や端末の性能によって異なります。

SSを選ぶ際は、プロトコル名だけで判断しないでください。暗号化方式はクライアントとサーバーの双方が対応している必要があり、パスワードの形式もその方式に合っていなければなりません。新しい方式と古い方式では鍵の扱い、リプレイ対策、実装上の要件が異なり、名前を変更するだけでアップグレードできるわけではありません。特に固定長の鍵を使う方式では、サーバー設定またはサブスクリプションで正しい値を確認してください。通常のテキストパスワードを無理に当てはめないようにしましょう。解析エラーが起きた場合は、まず暗号化方式と鍵の形式を確認し、その後にネットワークを調べます。

TCPとUDPの対応状況は個別に確認する

SSの接続先でWebページが開けても、ゲーム、音声通話、その他のデータグラムを使うアプリが動くとは限りません。Web通信はTCPが一般的ですが、リアルタイムアプリはUDPに依存する場合があります。UDP転送の可否には、サーバー、ファイアウォール、サブスクリプションの設定、クライアントのオプションが影響します。クライアントのUDPスイッチを有効にしても、サーバーにデータグラム転送機能がなければ利用できません。確認には実際にデータグラムを送るアプリを使い、接続ログも見てください。Webページを開いたり、速度測定を一度行ったりするだけでは不十分です。

SSの負荷は暗号化方式によっても変わります。特定のアルゴリズム向けのハードウェアアクセラレーションを備えたプロセッサーもあれば、ソフトウェア効率の高い実装に適した端末もあります。低消費電力ルーターとデスクトップPCでは、結果が逆になることもあります。アルゴリズムの優劣を推測する必要はありません。サービス提供元が明確にサポートし、現在のコアで安定して読み込める現代的な方式を優先し、継続通信時のCPU使用率と実効スループットから端末のボトルネックを確認してください。

VMessの認証とトランスポートの組み合わせ

VMessはV2Rayのエコシステムから生まれ、ユーザーID、認証、暗号化を使ってプロキシ接続を構成し、複数のトランスポートと組み合わせられます。一般的な設定には、サーバーとポートのほか、ユーザーID、セキュリティ設定、WebSocketのパスやリクエストヘッダーなどが含まれます。既存のサーバー構成に合わせやすい一方、互換性の確認項目も増えます。設定をインポートできたとしても、ローカル側で形式を読み取れたというだけで、リモートの経路、証明書、認証まで一致しているとは限りません。

VMessの認証には時刻が関係します。端末の時計が大きくずれていると、認証に失敗することがあります。ネットワークには到達でき、ポート接続も確立するのに認証エラーが続く場合は、まずシステム時刻、タイムゾーン、自動時刻設定を確認してください。古い資料には過去の互換設定が含まれている場合があり、現在のコアがすべての旧仕様に対応しているとは限りません。古いサブスクリプションを追加して設定項目の警告が出た場合は、手当たり次第にパラメーターを変更せず、設定の提供元に形式を確認しましょう。

SSとVMessを選ぶポイント

サーバーが安定したSS接続先を提供しており、設定も簡単で、アプリの要件を満たしているなら、別のプロトコル名が新しいという理由だけで乗り換える必要はありません。既存のサービスが特定のトランスポートに依存している場合は、VMessの柔軟な組み合わせが現状に適していることもあります。比較する際は、サーバーの場所、ネットワーク出口、測定時間帯をできるだけ揃えましょう。条件が違えば、測定結果はプロトコルより回線の差を反映していることがほとんどです。混雑した接続先と空いている接続先を比べて、プロトコルの優劣を判断しないでください。

移行時は元の設定を残し、複製したテスト用設定で作業してください。新しい接続先の認証方式、トランスポート、UDP対応を確認します。接続先は一度に1つだけ切り替え、同じアプリで初回リクエスト、継続ダウンロード、一時切断後の再接続を試します。テストに問題がなければ、日常使用のプロキシグループを更新しましょう。新しい接続先が現在のネットワークに合わなくても、すぐ元に戻せます。サブスクリプション、ルール、プロトコルの変更を一度に行い、原因を追いにくくするのを避けられます。

TrojanとVLESS：認証とセキュリティ層の役割

TrojanはTLSの通信路内でプロキシ認証を行う

Trojanの一般的な設計では、最初にTLS接続を確立し、その安全な通信路内でプロキシ認証とリクエスト転送を行います。成熟したTLSの仕組みで通信の暗号化とサーバー認証を処理し、プロキシ層ではパスワードなどを使ってユーザーを認証します。クライアント側で重要な設定は、サーバーアドレス、ポート、パスワード、証明書の識別情報です。一般的な安全な接続に似た構成ですが、接続先はTrojanに対応したプロキシサーバーである必要があります。任意のWebサイトのアドレスをTrojanの接続先として使うことはできません。

接続先アドレスと証明書の名前は異なる場合があります。クライアントはあるアドレスに接続しつつ、SNIでサービス名を指定し、その名前に合った証明書か検証できます。証明書の期限切れ、名前の不一致、端末に必要な信頼チェーンがない場合は、ハンドシェイクに失敗することがあります。その際は、サブスクリプションに記載された名前、システム時刻、証明書の設定を確認してください。検証をすぐに無効にするのは避けましょう。証明書検証を無効にすると相手の正当性を確認しにくくなります。接続が復旧しても、設定やサーバー側の問題を解決したことにはなりません。

VLESSはプロキシ層をシンプルに保つ

VLESSも関連するプロキシのエコシステムから生まれましたが、プロキシ層をよりシンプルにし、この層自体では完全なコンテンツ暗号化を行いません。通常はTLSやその他のセキュリティ機構が通信を保護します。ユーザーID、トランスポート、セキュリティ層の役割が分かれており、柔軟に組み合わせられる一方、それぞれの役割を理解する必要があります。「VLESS」という名前だけでは通信が暗号化されているかどうかは分かりません。セキュリティ設定と実際の構成を確認してください。

VLESSの設定には、TCP、WebSocket、gRPCなどのトランスポートや、flowなどの追加項目が含まれる場合があります。トランスポートの種類、パス、サービス名、関連パラメーターは、サーバー側の設定と一式で一致している必要があります。コアが基本的なVLESSに対応していても、すべての新しい拡張や組み合わせに対応するとは限りません。特に別のコアから出力した設定は、項目名が似ていても意味まで一致するとは限りません。現在使っているコアのドキュメントで対応範囲を確認しましょう。

TLS、REALITY、flowは同じレイヤーの概念ではない

TLSは汎用的なセキュアトランスポート、REALITYは一部のエコシステムで使われる別のセキュアハンドシェイク方式、flowは特定の接続処理方法を指定する設定項目です。互いに自由に置き換えられるラベルではありません。サーバーが採用する組み合わせに合わせて、クライアントに必要なパラメーターを設定し、コアもその組み合わせに対応している必要があります。公開鍵、名前、その他の必須情報がない場合は、サブスクリプションの提供元から完全な設定を入手してください。無関係なチュートリアルからパラメーターを寄せ集めないようにしましょう。

失敗した段階を特定すると、調査が進めやすくなります。証明書やセキュリティハンドシェイクのエラーは、まずセキュリティ層を確認します。ハンドシェイク後の認証エラーは、パスワードやユーザーIDを確認してください。特定の経路だけが失敗する場合は、WebSocketのパス、リクエストヘッダー、gRPCのサービス名を調べます。ログにタイムアウトしか表示されない場合は、アドレス解決の誤り、ポートへの接続不可、サーバーが待ち受けていない可能性も確認しましょう。プロトコル名は分類の目安ですが、互換性を左右するのは組み合わせる設定項目であることが多いです。

名称の長さではなく、サーバー構成で選ぶ

証明書を導入済みで、安定したTLS接続先を提供できる環境なら、Trojanは仕組みを説明しやすく、管理もしやすいでしょう。特定のトランスポート構成を使い続ける必要があり、双方のコアが対応していると確認できる場合は、VLESSも候補になります。これは速度の順位を示すものではありません。追加のカプセル化、接続の再利用、証明書のハンドシェイク、サーバー負荷などが使い心地に影響します。同じサーバーを使う2つの設定でも、異なる接続先やリバースプロキシを通る可能性があります。比較前に実際の経路を確認してください。

証明書検証をスキップする方法を、一般的な解決策として使わないでください。まずサービス名、証明書の有効性、端末の時刻を確認します。検証方法の一時的な変更を検討するのは、信頼境界を理解した上で行う管理下のテストに限ります。

移行時はサブスクリプション変換にも注意が必要です。変換処理によってサーバー、ポート、ユーザーIDは維持されても、拡張項目が失われる場合があります。その結果、一覧には表示されても接続に失敗します。元の設定と照合し、トランスポートとセキュリティ層の項目がすべて残っているか確認してください。クライアントの画面に概要しか表示されない場合は、コアのログと有効な設定も確認しましょう。画面上のプロトコル名だけで変換が成功したと判断してはいけません。設定を移行する詳しい方法は、後述のサブスクリプション互換性の章をご覧ください。

Hysteria2とTUIC：QUICを使う場合の選び方

UDPベースの信頼性ある通信を採用する理由

Hysteria2とTUICは、どちらもQUICを基盤とする設計です。QUICはUDP上で安全なハンドシェイク、信頼性のあるデータ転送、複数のストリームを実現し、接続制御をOSのTCPスタックだけに依存しません。ストリーム間で一部の待ち時間が連鎖する状況を減らせますが、物理回線の混雑やパケットロスをなくせるわけではありません。QUICに切り替えるとは通信方式を変えることであり、回線の帯域が増えたり、地理的な距離が短くなったりすることではありません。

これらのプロトコルを使うには、現在のネットワークで該当するUDP通信が許可されている必要があります。WebページがTCPで開けても、QUICの接続先に到達できるとは限りません。オフィスのネットワーク、ゲスト用ネットワーク、一部のネットワーク機器がUDPを制限している場合があり、リモート側のファイアウォールでポートを許可する必要もあります。同じ設定がモバイル回線では動くのに、特定のWi-Fiではハンドシェイクがタイムアウトし続ける場合、まず経路の違いを疑いましょう。タイムアウトを延ばし続けるより、利用できるTCP接続先を予備として残すほうが効果的です。

Hysteria2の帯域設定と輻輳制御

Hysteria2は、高いスループットや複雑なネットワーク環境を想定して設計され、帯域の想定値に関係する設定を利用できます。実際の輻輳制御は、クライアントとサーバーの実装や設定のネゴシエーションによって異なります。どの接続も一定速度で送信すると単純化して説明することはできません。クライアントに設定するアップロード、ダウンロードの帯域値も速度の保証ではなく、関連する制御機構に渡す入力値です。設定時は方向と単位を確認し、実際に利用できる回線の能力に合わせてください。

帯域の想定値を実際の回線能力より大幅に高く設定すると、キューやパケットロスが増え、他のアプリが待たされることがあります。速度測定の数値は良く見えても、操作の応答性が不安定になる可能性があります。モバイル回線の速度は電波状況や時間帯によって変わるため、固定回線で適切な設定が通勤中にも適するとは限りません。ビデオ通話に影響が出たり、ダウンロード中にWebページの表示が遅くなったりしたら、値をさらに上げるのではなく、同時接続数と帯域の想定値を下げて混雑が緩和するか確認しましょう。

TUICの接続再利用とデータグラム

TUICもQUICを使ってプロキシ接続を構成し、認証、ストリーム、データグラム転送などの機能を備えています。設定には通常、ユーザーID、パスワード、証明書に関する情報が含まれます。実装によっては輻輳制御、UDP転送方式、接続維持のオプションもあります。プロトコルの世代と実装の対応範囲を一致させる必要があります。同じ名称でも、古い形式と新しい形式で認証項目や挙動が同じとは限りません。サブスクリプションが現在のコアでサポートされる形式か確認してください。

短時間の接続が多い場合、既存の安全な接続を再利用することで、接続を作り直すオーバーヘッドを減らせる可能性があります。ただし、実際の効果はセッションの維持、ネットワークの安定性、コアの接続管理に左右されます。基盤となるQUICは物理回線と輻輳制御の枠を共有するため、大量通信を行うタスクが他のリクエストに影響することもあります。複数のストリームがあるからといって、アプリごとに独立した帯域が割り当てられるわけではありません。一度の短い速度測定だけで、長期的に使うプロトコルを決めないようにしましょう。

データグラム、MTU、ネットワーク切り替えの限界

QUICのデータグラム通信は、経路MTU、フラグメントの処理、中間ネットワーク機器の動作にも影響されます。ハンドシェイクは成功して少量のデータは正常でも、大きなデータの転送が何度も止まることがあります。TUNや追加のトンネル、アクセスネットワークが重なると、表面的な症状だけで原因を判断するのはさらに困難です。一般のユーザーはまずクライアントとサーバーの標準設定を使い、別のネットワークでも再現するか試してから、一項目ずつ確認してください。MTU、輻輳制御、証明書のパラメーターを一度に変更するのは避けましょう。

QUICには接続移行に関する機能がありますが、どのクライアントでもWi-Fiとモバイル回線を意識せず切り替えられるわけではありません。クライアントの実装、サーバーの対応、IPアドレスの変更、アプリ側の接続状態が結果に影響します。日常的にネットワークを切り替える場合は、画面ロック後の復帰、回線切り替え後の再接続、電波が弱い場所での動作をテスト項目に加えましょう。長時間ダウンロードでの利点が、メッセージの即時性やバックグラウンド同期の安定性につながるとは限りません。

Hysteria2とTUICは、実測してから候補に加えるのが適切です。すべてのTCP接続先を置き換えるものとして、最初から選ぶ必要はありません。まずUDP経路と証明書認証を確認し、継続的なデータ転送とアプリの応答性を比較しましょう。ネットワークの制限が大きい場合は、安定したTCP系の接続先を使うほうが手間がかからないこともあります。端末を使うユーザーにとっては、高度な設定項目が多いことよりも、復旧でき、仕組みが分かり、設定の出所が明確であることが大切です。

性能と電池消費：接続が速くてもダウンロードが速いとは限らない

「速度」を3つの指標に分けて考える

接続の使い心地は、接続確立までの待ち時間、最初のデータが届くまでの時間、継続転送時のスループットに分けて考えられます。小さなWebページの表示は、名前解決、ハンドシェイク、サーバーの応答に左右されます。大きなファイルのダウンロードは、回線容量、混雑、フロー制御の影響を強く受けます。遠隔操作などのインタラクティブな用途では、ジッターや短時間のパケットロスが重要です。すべての指標に共通する順位はありません。ダウンロードは速いのにWebページの初回表示が遅くても矛盾ではなく、単一の遅延値ですべてのアプリの使い心地を説明することもできません。

クライアントのURL Testは通常、指定されたテスト用URLにリクエストを送って測定します。結果はテスト対象、接続状態、タイムアウト設定、実装の細部によって変わります。純粋な地理的往復時間でも、帯域の保証でもありません。テスト対象の応答が遅ければ値が大きくなり、既存の接続を再利用すれば小さく見えることもあります。測定値と実際の通信速度の違いについては、ノード遅延テストの仕組みもご覧ください。

リソース使用量は接続経路全体で決まる

CPU負荷は暗号化だけでなく、データのコピー、仮想ネットワークスタック、ルール判定、データグラムのカプセル化、ログ処理からも生じます。メモリ使用量は同時接続数、キャッシュ、ルールデータ、画面プロセスにも左右されます。デスクトップのタスクマネージャーで見えるクライアント全体の使用量を、特定のプロトコルのコストとして扱うことはできません。比較時は画面とコアのプロセスを区別し、ルールの規模と通信の取り込み方法を揃えた上で、アイドル時、操作時、継続転送時の3つの状態を確認しましょう。

暗号化アルゴリズムがハードウェア命令を利用できるかどうかで、端末ごとの性能は変わります。QUICのユーザー空間での処理、追加のカプセル化、接続管理も負荷を増やす場合があります。一方、適切な接続再利用や輻輳制御で、待ち時間や重複処理を減らせることもあります。そのため、UDPプロトコルは必ず電池を多く消費する、あるいは特定のシンプルなプロトコルが常に省電力だと一概には言えません。低性能端末では、継続的に負荷をかけたときにCPU使用率が上限に達するか、発熱するか、スループットが伸びなくなるかを重点的に確認しましょう。

スマホの電池消費はバックグラウンド動作の影響が大きい

スマホでは、無線モジュールの起動、接続維持のための通信、バックグラウンドでの再試行、ネットワークの切り替えが、暗号化処理一回より電池消費に影響することがあります。接続維持の間隔が短すぎると少量のデータを頻繁に送信し、無線モジュールが長時間動作します。長すぎると中間機器がアイドル状態の接続情報を削除し、復帰時に接続を作り直すことがあります。適切な値はアクセス回線とアプリの要件によって異なります。一般のユーザーはまず標準設定を使い、明確な問題が起きた場合に調整してください。

速度測定を続けると、画面、CPU、無線通信が同時に動作します。その結果だけで普段の電池持ちを推定することはできません。画面の明るさ、電波状況、使うアプリを揃え、日常使用後のシステムの電池使用量を確認するほうが有効です。画面ロック中に異常な通信や再接続が起きていないかも見てください。特定の接続先で電池消費が明らかに増える場合は、失敗時の再試行、頻繁なネットワーク切り替え、過度に短い接続維持間隔を確認しましょう。プロトコルの種類だけを原因と決めつけないでください。

再現可能な比較方法を作る

同じサービス提供元の接続先から、経路が近い2つを選び、クライアント、ルール、テスト用アプリを固定します。各テストでは、起動直後のWebページ表示、継続通信、一時停止後の再開、ネットワーク切り替えを確認し、時間帯を変えて繰り返します。最高速度の数値だけでなく、大容量ファイルのダウンロード中に音声が途切れるか、画面ロック後に手動で再接続する必要があるかなど、具体的な現象を記録しましょう。2つの接続先でサーバーが異なる場合は、「この接続先は現在のネットワークに適している」と結論づけ、プロトコルの勝敗として扱わないでください。

最後に残すのは、繰り返し確認できる差だけです。一度のタイムアウトは、接続先のWebサイトや一時的なネットワーク変化が原因かもしれません。長期的な傾向を一度の結果で覆さないようにしましょう。日常利用では速度より安定性と復旧のしやすさを優先し、スマホではバックグラウンドでの信頼性と電池消費も考慮してください。接続の問題を調べる場合は、まずよくある質問でシステムプロキシ、TUN、設定の有効化状況を確認すると、関係のない要因を減らせます。

コアの系統：オリジナル版、Meta、mihomo

名称の関係と機能の範囲

オリジナル版Clashは、一般的なルール、プロキシグループ、設定ファイル、制御インターフェースの仕組みを確立し、多くのクライアントがその考え方を引き継いでいます。Clash.Metaは関連するオープンソースのエコシステムを基に、プロトコルやネットワーク機能を拡張しました。mihomoはこの系統の開発を引き継いでいます。過去の名称の経緯から、資料ではMetaとmihomoが併記されることもあります。具体的な機能を調べる際は、記事のタイトルではなく、実際に動作しているコアとそのドキュメントを確認してください。

オリジナル版の設定にある基本構造の多くは、後発のコアでも利用できます。たとえばルール一覧や一般的なプロキシグループなどです。一方、逆方向の互換性は保証されません。新しいプロトコル、DNSオプション、ネットワークスタックのパラメーターを含む設定を、機能の少ない古いコアで読み込むと、エラーになるか一部の項目が無視される場合があります。設定の互換性には方向と範囲があり、ファイルの拡張子が同じでも完全に共通とは限りません。「Clashに対応しているか」だけでなく、各設定項目の対応状況を確認しましょう。

GUIクライアントは別のプロトコルではない

Clash Nyanpasu、Clash Verge Rev、FlClashなどはクライアント製品名であり、画面、統合方法、コアの管理方式はそれぞれ異なります。Clash Plusはダウンロードセンターで最初におすすめする選択肢です。まず利用するプラットフォームと設定の提供元を基に適合性を確認し、特定のデスクトップ設定や操作方法が必要な場合は、他のクライアントと比較してください。どのクライアントでも、実際に動作するコアと設定の対応状況を確認する必要があります。クライアント名だけで対応プロトコルを判断しないでください。

一部のクライアントはコアを切り替えられますが、切り替えによって実行環境が変わり、単に実行ファイルを置き換えるだけでは済まない場合があります。設定の生成方法、起動パラメーター、権限、制御インターフェースとの互換性に影響することもあります。画面にClash Rustなどのコア名が表示されても、mihomoの設定項目すべてと同等という意味ではありません。クライアントが正式にサポートする組み合わせを確認し、既存のルール、サブスクリプション、通信の取り込み機能をテストしてください。名前が似ているだけで移行するのは避けましょう。

安定版コアとAlphaの選び方

Alphaは通常、開発中のビルドを指します。新機能や修正が早く含まれる一方、動作が変わる可能性もあります。高性能を保証するものではなく、目立つラベルだけを理由に常用するのはおすすめできません。一般のユーザーは、クライアントが推奨する安定版を優先してください。安定版にまだ含まれていない機能が必要な場合は、プロジェクトの説明を確認した上でテストしましょう。未確認の特定バージョン番号で対応状況を判断せず、現在の機能ドキュメントとリリースノートを確認してください。

更新前にサブスクリプションの取得元、クライアント設定、ローカルルールのコピーを保存し、旧コアに戻せることを確認します。更新後は、起動ログで設定が正常に読み込まれたかを確認し、Webページ、データグラムを使うアプリ、スリープ後の復帰をテストしてください。アップデートと同時に新しい警告が出た場合は、設定項目ごとに意味を確認します。設定の解析に成功しても、DNS、ルーティング、プロキシ選択の動作が以前の想定どおりとは限りません。既定の動作が変わった場合は、実際の動作確認が特に重要です。

制御インターフェースと権限も互換性の確認項目

クライアントはローカルの制御インターフェースを通じて、接続情報の取得、プロキシ切り替え、ログ表示を行うことがよくあります。インターフェースのアドレス、認証、ポートが合わないと、コアは起動しているのに画面では切断状態になったり、操作できなくなったりする場合があります。これは管理用の通信経路の問題であり、プロキシプロトコルの失敗とは限りません。制御インターフェースを信頼できないネットワークに公開しないでください。また、画面が状態を読み取れないからといって、すべてのリクエストが転送されていないと判断しないようにしましょう。プロセス、待ち受け状態、リクエストの経路をそれぞれ確認してください。

TUNには仮想インターフェースとシステム権限も必要です。コアがTUN機能に対応していても、現在のインストール方法で必要な権限が付与されているとは限りません。デスクトップOSのサービスモード、ネットワーク拡張、権限の確認画面は、クライアントの説明に従って設定してください。コア切り替え後にTUNだけが動かず、システムプロキシは使える場合は、まず権限とネットワークスタックを確認してからプロトコルを調べます。通信の取り込み、コアの機能、リモート接続を分けて検証すれば、クライアントを何度も変更して同じ問題に遭遇するのを防げます。

設定の移行は、「実際のコア → 対応する設定項目 → 通信を取り込む権限 → アプリでの動作確認」の順に確認します。画面が同じでも内部の動作は同じとは限らず、同じ系統のコアでもすべての拡張設定が相互に互換とは限りません。

サブスクリプションの互換性：URL形式から有効な設定まで

サブスクリプションURLはノード設定そのものではない

サブスクリプションURLは設定内容を取得するための入口です。返される内容は、完全なYAML、ノードリンクの一覧、エンコードされたテキスト、クライアント専用形式などさまざまです。ブラウザーでURLを開けても、現在のクライアントに適した形式とは限りません。ログイン画面、期限切れの通知、Webエラーが正常なHTTPレスポンスとして返ることもあります。読み込みに失敗したら、更新ボタンを繰り返し押すのではなく、まず返されたデータの種類を確認し、クライアントが必要とする形式と照らし合わせてください。

mihomoの完全な設定には通常、プロキシ設定、プロキシグループ、ルール、必要に応じてDNSなどの設定が含まれます。一方、単一のプロトコルリンクには、通常、1つの接続先の情報しかありません。クライアントにインポートや設定の組み立て機能があっても、どの製品も同じ形式に対応しているわけではありません。提供元が複数のサブスクリプションを用意している場合は、現在のコア向けと明記された形式を選びましょう。ダウンロードしたファイルの拡張子がYAMLだからといって、すべてのプロトコルや拡張項目が正しく変換されているとは限りません。

形式の確認後は設定の意味も照合する

YAMLにはインデント、リスト、文字列の構造に関するルールがあります。コピー時にタブが混入したり、インデントがずれたり、特殊文字が含まれたりすると、設定全体を読み込めない場合があります。一方、構文が正しくても参照先が正しいとは限りません。ルールが参照するプロキシグループが存在し、そのグループが参照する接続先名も一致している必要があります。サブスクリプションの更新で名前が変わると、ローカルの上書きルールに影響することがあります。調査時は、解析エラーだけでなく参照関係も確認してください。特定の行のスペルだけを確認しても十分ではありません。

以下の短い例では、直結とプロキシグループ参照の基本構造を示します。リモートサーバーの認証情報は含まれていません。ここでのProxyは任意に付けたプロキシグループ名であり、プロトコルの種類ではありません。このグループには現在DIRECTのみが含まれるため、リモートのプロキシ接続は確立されません。実際の設定では、動作確認済みの接続先をグループに追加し、ルールから参照してください。この命名関係を保つことで、ルールを1つずつ変更せずにクライアントから出口を切り替えられる理由が分かりやすくなります。

mode: rule
proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

変換で失われる可能性がある情報

ある形式のサブスクリプションを別の形式に変換すると、基本的なアドレスとポートは残りやすい一方、拡張セキュリティ項目、トランスポートのパラメーター、データグラムの設定、プロトコル固有の設定は差異が生じやすくなります。変換先の形式が対応していない項目を、変換で新たに補うことはできません。変換ツールが追加された項目を認識できない場合もあります。変換後に特定のプロトコルだけが失敗するなら、そのプロトコルに必要な項目を照合してください。すべての接続先を一度に置き換えるのは避けましょう。元のサブスクリプションが使える場合は、不要な変換を減らすのが安全です。

サブスクリプションURLにはアクセス用の認証情報や利用量の情報が含まれることがあります。変換サービスにURLを渡すと、そのURLと関連設定を第三者に処理させることになります。変換方法を選ぶときはデータの流れを把握し、出所の分からないページに個人用サブスクリプションを貼り付けないようにしましょう。問題を共有する際も、URL全体、ユーザーID、パスワードを削除してください。プロトコルの種類、設定項目名、エラー内容があれば、形式に非対応なのか、認証に失敗したのか、ネットワークがタイムアウトしたのかを判断できることがほとんどです。

ローカルの変更を更新で上書きされないようにする

リモートのサブスクリプションは更新時に内容が再生成されるため、ダウンロードしたファイルを直接編集しても、次回の更新で変更が消える場合があります。独自のルールやプロキシ設定を維持するには、クライアントが明示的に提供する上書き、マージ、ローカル設定の機能を使い、どの処理段階に適用されるか確認してください。マージの動作はクライアントによって異なり、一覧全体を置き換えるものもあれば、項目を追加するものもあります。「マージ」なら順序も維持されると思い込まないでください。特にルール一覧は、上から順に照合されるため、順序が実際の出口を変えます。

更新に失敗した場合は、最後に使えた設定を残した上で、URLの有効性、返される形式、YAMLの構造、項目の対応状況、ネットワーク接続の順に確認します。手順の全体像は、サブスクリプション更新失敗のトラブル対処をご覧ください。設定の読み込みに成功していてドメイン名へのアクセスだけに問題がある場合は、DNSとルールデータを確認します。GeoIP・GeoSiteデータベースの解説では、サブスクリプションの内容と外部のルールデータの問題を切り分ける方法を紹介しています。

最後に、インポートした設定が保存されただけではなく、クライアントで実際に有効になっていることを確認しましょう。有効な設定名、ログ、実際の接続で適用されたルールを確認し、インポート、読み込み、ルール判定、転送まで一連の動作を検証してください。

用途別の選び方：制約を整理してから接続先を比較する

デスクトップでの仕事と普段のブラウジング

デスクトップでの仕事では、安定性、スリープからの復帰、既存アプリとの互換性を優先しましょう。まずダウンロードセンターで最初におすすめするClash Plusのプラットフォーム対応を確認し、必要な画面の操作方法やコアの機能に応じてClash Nyanpasu、Clash Verge Rev、FlClashなどと比較してください。安定した接続先がすでにあるなら、プロトコル名を変えるためだけに移行する必要はありません。主な用途がWeb、メール、開発ツールなら、システムプロキシとコマンドライン環境の設定を揃えてください。「特定のプロトコルで開けない」という問題の多くは、アプリが同じ接続先を使っていないことが原因です。

ローカルサービス、ソースコード管理、その他の業務通信を分けたい場合は、プロトコルの違いよりルールの精度が使い心地に影響することがあります。まず安定した接続先を1つに固定し、LAN、直結、プロキシのルールを整理してから、トランスポート性能を比較しましょう。開発ツールは独自のプロキシ設定や証明書ストアを持つ場合があります。ブラウザーが動いても、ターミナルのコマンドが動くとは限りません。選定記録にはアプリ名と通信の取り込み方法を記載し、1つのブラウザーの結果でPC全体を判断しないようにしましょう。

モバイル回線、音声通話、継続ダウンロード

スマホで通勤中に使う場合は、電波状況の変化やネットワークの切り替えがよく起こります。一度の速度測定の最高値より、復旧の速さ、バックグラウンドでの安定性、電池消費を重視しましょう。まず設定項目が少なく、提供元が明確な接続先を使い、異なるトランスポートの接続先も予備に残します。音声通話やゲームでは、接続経路全体がUDP転送に対応しているか確認してください。Webページが開いたからといってテストを終えないようにしましょう。TUNを有効にしてアプリが改善した場合も、通信を取り込む範囲が変わったのか、リモートのプロトコルが自動で変わったのかを混同しないでください。

継続的なダウンロードや高スループットの作業では、Hysteria2やTUICも候補にできます。ただし、最初にUDPへ到達できるか、実際の同時利用で問題がないかを確認してください。大きなファイルをダウンロード中に他のアプリが明らかに遅くなる場合は、帯域の想定値、同時接続数、輻輳に関する設定を先に調整します。TCP系の接続先でも、安定した回線なら十分なスループットを得られることがあります。選択の根拠は、現在のサービスとネットワークでの実測結果にしてください。そのプロトコルを使える接続先が1つしかない場合、別のサーバーの結果と比べてプロトコルの優劣を判断することはできません。

低消費電力端末とサーバー環境

ルーター、小型PC、サーバーでは、CPUアーキテクチャ、メモリ、暗号化性能、同時接続数を特に確認しましょう。GUIクライアントは日常的な操作に適し、単体のmihomoコアは、サービスとして明確に管理したいユーザーに向いています。ダウンロードセンターのコア欄はこのような環境を対象としており、一般的なデスクトップユーザーにはGUIクライアントをおすすめします。インストール前にCPUアーキテクチャと実行環境を確認し、OS名だけでファイルを選ばないでください。同じLinuxでも、CPUやパッケージ管理方式が異なる場合があります。

リソースに制約のある端末では、まずルールを絞り、必要なログレベルを設定して、通常の負荷で安定するか確認します。その後でルールセットや追加機能を増やしてください。接続一覧を頻繁に更新すること、詳細ログを常時有効にすること、多数の接続を同時に維持することは、プロトコルの負荷比較に影響する場合があります。一定のスループットを超えるとCPUが高負荷の状態で続く場合は、端末と回線のどちらがボトルネックかを切り分けてください。プロトコルの変更だけでは解決しないこともあります。暗号化方式を端末に合わせたり、追加処理を減らしたりするほうが効果的な場合もあります。

元に戻せる手順で接続先を選ぶ

実際のテストは4段階で進めます。まずサブスクリプションとコアの互換性を確認し、次に接続先を1つずつ基本接続のテストにかけます。その後、普段使うアプリとネットワークの切り替えを試し、最後に通常の利用を続けた後のリソース使用量と電池消費を確認します。各段階で変更する項目は1つに絞り、使える状態の設定を残してください。問題が起きたら前の段階に戻り、新たに加えた要因との関連を確かめます。クライアント、コア、DNS、プロトコルを同時に変更するより、この順序で進めるほうが結論を明確にでき、問題も再現しやすくなります。

ドメイン名の解決だけに問題がある場合は、DNSの確認と設定方法をご覧ください。インポート、モード、接続確認を最初からやり直す場合は、使い方ガイドに戻ってください。最終的な選択では、次の3点を説明できることが大切です。現在のネットワークでその経路を使える理由、コアが設定を正しく解釈できる理由、日常の作業でより安定する理由。この3点を説明できるほうが、一般的なプロトコルランキングより役に立ちます。