Clashのプロトコル・コア解説｜SS・VLESS・Hysteria2の選び方と設定互換性

コアの関係：Clash・Meta・mihomo

クライアント、コア、サーバーの役割

クライアントはユーザーが操作する画面で、設定のインポートやサブスクリプションの管理、プロキシグループの表示を行い、システムプロキシの設定や仮想ネットワークインターフェースの作成を要求します。コアは設定の解析、ルールの照合、名前解決、実際の接続を担当します。サーバーは接続先となるプロトコルの入口を提供するプログラムです。それぞれの役割は置き換えられません。クライアントの画面を変えても、接続先のプロトコルは自動で変わりません。サブスクリプションに記載された種類を別のプロトコル名に変更しても、サーバーがそのプロトコルに対応するわけではありません。互換性を確認する際は、クライアントが呼び出すコア、コアが実装するプロトコル、サーバーが要求する設定を照合してください。

Clashは、プロキシ、プロキシグループ、ルールをYAMLで記述する方式を確立し、その後のエコシステムにも多くのフィールドや概念が引き継がれました。オリジナルのプロジェクトはすでに開発を終了しています。また、オープンソース版と、かつて提供されていたPremium版の機能は完全に同じではありません。「Clash」と記載された古い解説を、すべて同一の技術仕様として扱わないようにしましょう。Metaはこのエコシステムでプロトコルやネットワーク機能を拡張するコアとして始まり、後にmihomoの名称で開発が続いています。Clash Meta時代の資料を参照する場合は、名称だけで新旧を判断せず、現在のmihomoの設定解説と照らし合わせてください。

名称を引き継いでいても、すべてのフィールドが双方向に互換とは限りません

mihomoは一般的な設定構造を多く引き継ぎつつ、プロトコル対応、DNSの動作、ルール機能を拡張しています。この互換性は主に古い設定を新しい実装へ移行しやすくするものです。新しい設定を古いコアで使えるとは限りません。VLESS、Hysteria2、特定のTLSオプションを含むサブスクリプションは、古いクライアントでは解析に失敗することがあります。インポートできても、特定のノードを使う段階でエラーになる場合もあります。画面に表示されるクライアントのバージョンとコアのバージョンは別々の情報です。問題を報告する際は、インストーラーの名前だけでなく、それぞれのバージョンを記録してください。

エコシステムの名称を確認するための一覧（機能の完全な比較表ではありません）
名称	主な位置づけ	確認するポイント
オリジナルのClash	旧来のコアと設定体系	該当するフォークと開発終了の状況
Clash Meta	mihomoの旧プロジェクト名	資料が対象とする実装時期
mihomo	開発が続くプロキシコア	現行コアが対応するフィールドとプロトコル
GUIクライアント	設定管理とシステム連携	実際に使われるコア、オーバーライド、権限管理

デスクトップで実際に適用されている設定を確認する

クライアントを選ぶ際は、まずClash Plusをおすすめします。ほかの画面も比較したい場合は、ダウンロードページでClash Verge RevやFlClashなどを確認できます。クライアントによって設定の管理方法が異なるため、どのプロジェクトにも同じコア切り替え機能があるとは限りません。「バージョン情報」「実行情報」「ログ」などの画面でコア名を確認し、実行中の設定にサブスクリプションの内容が含まれているかも調べてください。クライアントがサブスクリプション、全体オーバーライド、ローカルルールを統合してからコアに渡す場合もあります。元のファイルと適用後の設定が異なっていても、必ずしも異常ではありません。

移行前にローカル設定を書き出し、元のサブスクリプションの入手元も控えておきましょう。その後、動作確認済みの設定を使ってテストします。プロトコル、DNS、TUN、ルールセットを一度に移行すると、失敗したときに原因を特定しにくくなります。プロジェクトの系譜やGUIの役割分担については、Clashオープンソースプロジェクトの相関図もご覧ください。エコシステムを知る目的は、実際に接続を処理するコンポーネントを特定することです。プロジェクト名だけで互換性が保証されるわけではありません。

SSとVMess：軽量な転送と認証の仕組み

Shadowsocksの設計範囲

Shadowsocksは一般にSSと略され、比較的シンプルな暗号化プロキシ方式を採用しています。クライアントは接続先のアドレスをサーバーに伝えてデータを転送します。プロトコル自体に、HTTPページ一式や証明書の仕組みは必要ありません。設計の重点は、プロトコルの負荷を抑え、転送の役割を明確にすることです。ルーティング、サブスクリプション、GUIまでプロトコルに含めるものではありません。クライアントでSSノードを設定する際は、通常、サーバーアドレス、ポート、パスワード、暗号化方式が必要です。これら4項目はサーバー側と一致させてください。暗号化方式はプロトコルの設定項目であり、自由に調整できる性能モードではありません。

初期のSSではストリーム暗号方式が使われていました。その後のAEAD方式では機密性と完全性の保護が組み合わされ、Shadowsocks 2022では鍵やセッションの設計が変更されています。同じSSという表記でも、各方式を相互に置き換えられるとは限りません。特に、特定の長さやエンコード形式の鍵を要求する方式では、通常の文字列パスワードをそのまま入力できません。方式を選ぶ際は、互換性のために設定を安易に弱めず、双方が対応する現行方式を確認してください。プロセッサが対応するアクセラレーション機能も、方式ごとの実際のリソース負荷に影響します。

SSのTCP転送とUDP転送は、それぞれ対応状況を確認する必要があります。ブラウザーでウェブページを開けても、その経路で通信できることが分かるだけで、ゲーム、音声通話などのUDPアプリも使えるとは限りません。SSの設定によっては追加プラグインが必要です。プラグイン名、パラメーター、クライアントの対応状況も接続条件の一部です。基本的なSSノードは使えるのに、プラグイン付きのノードだけ失敗する場合は、サーバー全体の障害と判断する前に、プラグインの実装と設定を確認してください。プロトコル本体と追加のトランスポート層は分けて考えましょう。

VMessの認証情報とトランスポート設定

VMessはV2Rayエコシステムのプロトコルです。プロキシ要求に認証とデータ保護の仕組みを含み、複数のトランスポート方式と組み合わせられます。一般的な設定にはUUID、暗号化設定、TLSの有効・無効、WebSocketなどのトランスポートパラメーターがあります。VMessの旧設定には、過去の認証方式や後継のAEAD方式が含まれます。古いサブスクリプションをインポートする際は、サーバーとコアの対応範囲を確認してください。解説に古いフィールドが出てきても、現在のノードにそのまま流用しないでください。判断の基準はサーバー側の設定仕様です。クライアントによっては古い組み合わせに対応していないこともあります。

VMessではシステム時刻が正確である必要があります。端末の時計が実際の時刻から大きくずれていると、認証に失敗して通常の接続タイムアウトのように見えることがあります。トラブル時は、まず自動時刻合わせが正常か確認し、UUIDとトランスポート設定を照合してください。WebSocketを使う場合、パスやHostなどはサーバー指定のとおりに設定します。TLSを有効にしている場合は、証明書に対応する名前も確認してください。カプセル化を追加するたびに、合わせるべきパラメーターが増えます。サブスクリプションをインポートできただけでは、各パラメーターの動作確認が済んだとは限りません。

2種類のノードを比較する方法

同じサービス条件であれば、基本的なSSは比較的シンプルな接続経路になります。VMessの実際の負荷は、暗号化方式や外側のトランスポートにも左右されます。ただし、別々のサーバーを比較する場合は、距離、帯域、混雑、サービス側の制限のほうがカプセル化の違いより大きく影響することも少なくありません。安定したSSノードがあり、用途も満たせているなら、名前を変えるためだけに移行する必要はありません。VMessを使う場合は、サーバーが指定するパラメーター一式を選び、検証済みの接続経路も比較用に残しておきましょう。一般のユーザーにとっては、プロトコル名より、設定がそろっていて長期的に安定し、保守状況が明確であることのほうが重要です。

TrojanとVLESS：認証とTLSの役割

Trojan：TLSで接続を保護する

Trojanは、TLS接続内でプロキシ認証を行う設計です。パスワードでクライアントを識別し、TLSで通信の機密性と完全性を保護します。HTTPSサイトのアドレスをそのままプロキシとして使う方式でも、パスワードだけで接続できる方式でもありません。サーバーアドレス、待ち受けポート、パスワード、TLS名、証明書の信頼関係がすべて正しく設定されている必要があります。通常、クライアントはシステムまたはコアの信頼設定を使ってサーバー証明書を検証します。証明書の期限切れ、名前の不一致、端末の時刻異常があると、プロキシ認証より前のTLSハンドシェイクで失敗することがあります。

接続に使うサーバーアドレスと、TLS検証に使う名前が異なる設定も可能ですが、実際のサーバー構成に基づいている必要があります。サーバー欄は接続先を指定し、SNIは通常TLSハンドシェイクで接続先のサービスを示します。証明書検証では、接続相手が期待した相手かどうかを確認します。SNIを別のドメインに変えても、証明書の問題は解決しません。検証に失敗した場合は、正しい名前、証明書チェーン、端末の時計を確認してください。証明書検証のスキップを恒常的な設定にすると、サーバーの身元を確認する重要な機能が失われます。

VLESS：軽量な認証だけでは暗号化にならない

VLESSはV2Ray/Xray関連のエコシステムで生まれ、プロトコル層の認証と転送を簡素化した方式です。ユーザーの識別には一般にUUIDを使います。VLESS自体は外側のTLSと同等のコンテンツ暗号化を提供しないため、安全性を論じる際は接続全体の構成を明確にする必要があります。TLS、REALITYなどのトランスポート方式と組み合わせたVLESSは、「VLESS」という種類名だけの設定とは異なります。サービス提供元が指定するパラメーター一式をインポートしてください。「軽量」という表現を接続保護の省略と捉えないこと、特定の実装にある拡張機能がすべてのクライアントで使えると思い込まないことが大切です。

REALITYは特定の実装が提供するハンドシェイク方式で、通常の証明書方式の別表記ではありません。公開鍵、Short ID、サーバー名などの設定が必要な場合があり、サーバー側の値と一致させる必要があります。一部のVLESS構成では、Vision関連のモードなどflowの設定も関わります。flowは長く設定すればよいものではなく、すべてのトランスポートで有効にするものでもありません。サーバーから指定がない限り、別ノードの設定を流用しないでください。未対応フィールド、ハンドシェイク失敗、接続直後の切断が起きた場合は、UUIDだけでなく、コアの対応状況とパラメーター一式を優先して確認しましょう。

プロトコル名以外に合わせるべき接続条件
項目	Trojan	VLESS
一般的な認証情報	パスワード	UUID
接続の保護	通常はTLSを使用	TLS、REALITYなど外側の方式による
追加で確認する項目	証明書名、信頼チェーン、トランスポート方式	外側の方式、flow、トランスポート設定

トランスポートを重ねた場合の性能

TrojanもVLESSも、トランスポートの組み合わせによって性能に大きな差が出ることがあります。TCPとTLSで直接接続する構成と、WebSocketなどのアプリケーション層トランスポートをさらに重ねる構成では、ハンドシェイクやカプセル化の負荷が異なります。外側のサービスのアイドルタイムアウト、接続の再利用、中間ネットワーク機器も安定性に影響します。ノードを評価する際は、TrojanやVLESSという種類名だけでなく、プロトコル、TLSの有無、トランスポート方式など、構成全体を記録してください。サーバーの同時接続数制限やリソース配分がボトルネックになることもあります。

ウェブ閲覧やリモートワークが主な用途なら、証明書が有効で、設定がそろっており、繰り返し安定して接続できる構成を優先しましょう。VLESSはプロトコル層で二重暗号化しないからといって、Trojanより必ず速いとは限りません。TrojanがTLSを使うからといって、必ず電池を多く消費するとも限りません。実際の負荷は接続スタック全体で決まります。異常が起きたら、まずTLS検証を有効のままにしてエラーの種類を確認し、接続先アドレス、サーバー名、認証情報を個別に検証してください。セキュリティ設定を緩めて不一致を隠さないようにしましょう。

Hysteria2とTUIC：QUICベースのトランスポートを比較

QUICが変える通信レイヤー

Hysteria2とTUICはどちらもQUICを利用しますが、同じプロトコルの別名ではありません。QUICは通常UDP上で動作し、暗号化ハンドシェイク、信頼性のある転送、複数ストリームの管理を組み合わせます。独立した複数のストリームでは、あるストリームのデータが失われても、1本のTCPバイトストリームのようにほかのストリームの配信まで必ず止まるわけではありません。ただし、すべてのストリームが接続の輻輳状態や帯域を共有することはあります。「ヘッドオブラインブロッキングを減らす」ことは、「パケットロスの影響がない」という意味ではありません。UDPが到達できない環境では、QUICも接続を確立できません。

プロキシ経由でアプリのTCP通信を転送する場合、アプリから見れば引き続き信頼性のある接続として扱われます。外側の転送はプロトコルが担います。一方、アプリ自体のUDPデータグラムは別の転送方式になることがあります。TCPとUDPでは信頼性の要件が異なります。プロキシがUDP上で動くからといって、すべてのアプリのデータが信頼性のない転送に変わるわけではありません。逆に、すべてのデータグラムがTCPと同じ保証を得るわけでもありません。音声通話、ゲーム、ファイル転送の動作を判断する際は、アプリの通信種別とプロキシの実際の処理方法をそれぞれ確認してください。

Hysteria2：帯域設定と輻輳時の動作

Hysteria2は高スループットや複雑なネットワーク環境を想定し、帯域推定や輻輳制御に関する仕組みを備えています。設定にある上り・下りの帯域値は、購入済み帯域の証明でも、値を大きくすれば速くなる設定でもありません。これらの値は実装側の送信速度の判断に影響し、実際の動作はサーバー側の方針やネゴシエーションの結果にも左右されます。実際より高く見積もると、キューの増大やパケットロス、ほかのアプリとの帯域競合につながることがあります。低く見積もると、利用可能なスループットを制限する可能性があります。サービス提供元から指定があり、単位も明記されている場合に限り、これらの値を変更してください。

Hysteriaの世代の違いにも注意が必要です。Hysteriaと表示された旧ノードはHysteria2と同じではなく、名前を変更するだけではプロトコルや認証方式、設定を移行できません。環境によっては追加の難読化やポート関連の設定も必要です。これらもサーバーの指定に合わせてください。クライアントがHysteria2に対応していても、サブスクリプションに含まれるすべての拡張項目を使えるとは限りません。トラブル時はまずプロトコルの世代を確認し、次にUDP経路、認証情報、TLS名を照合します。複雑なオプションをすべて有効にして試すのは避けてください。

TUIC：接続の再利用と転送方式

TUICもQUICでプロキシ接続を行い、接続の再利用やUDP転送などを重視しています。一般的な設定にはUUID、パスワード、輻輳制御アルゴリズム、UDP転送モードが含まれます。プロトコルの改訂版や実装によって互換性の範囲は異なるため、種類名が一致していても引き続き確認が必要です。オプションによっては、QUIC経由のデータグラムの送信方法が変わり、負荷、パケットロスへの対処、経路の要件に影響します。これらはサーバーとクライアントで合意する動作です。相手側の設定を無視して自由に切り替える最適化ボタンではありません。

QUICのパケットヘッダー、暗号化、ユーザー空間での転送処理にもリソースを消費します。高スループットの環境では、古い端末でCPU使用率が上がることがあります。無線ネットワークを切り替えた際に接続を維持できるかは、プロトコルの実装、アドレスの変化、サーバー側の方針にも左右されます。QUICに接続移行の機能があるからといって、スマートフォンのネットワーク切り替え後もすべてのセッションが切れないとは限りません。再認証が必要なアプリが新しい接続を開始することもあり、これはプロキシがセッションを維持するかどうかとは別の層の問題です。

Hysteria2やTUICを選ぶ前提は、サーバーが対応していること、コアに互換性があること、現在のネットワークがUDPに適していることです。大容量ファイルや複数ストリームの処理では、実際に使う時間帯に繰り返し比較してください。電池消費が気になるモバイル端末では、温度やバックグラウンド動作、ネットワーク切り替え後の復旧状況も確認しましょう。比較用にTCP系のノードを残すと問題を特定しやすくなります。ただし、独立した候補設定として用意してください。QUICノードの種類名だけをTCPに変更して接続を試すのは避けましょう。

接続速度、リソース使用量、モバイルの電池消費

「速さ」を4つの段階に分けて確認

ウェブページをクリックして内容が表示されるまでには、少なくとも名前解決、接続確立、最初の応答、その後の転送という4つの段階があります。ノードの遅延テストで測定できるのはその一部にすぎず、テストURL、接続の再利用、キャッシュにも左右されます。ハンドシェイクが短くてもダウンロードが速いとは限りません。帯域が大きくても、小さなページが早く表示されるとは限りません。プロトコルを比較する前に、初回表示が遅いのか、ダウンロードが続くほど遅くなるのか、ときどき切断されるのかを特定してください。症状ごとにボトルネックは異なります。1つの測定値だけでまとめると、結論を誤りやすくなります。

初回の接続では、TCP、TLS、QUICのいずれもハンドシェイクに往復時間がかかることがあります。ただし、実際の負荷はセッション再開、既存接続の再利用、実装方針によって変わります。固定のハンドシェイク回数だけで、すべてのノードに順位をつけないでください。接続先サーバーの応答時間、DNS問い合わせ先、接続を再利用するかどうかも使い心地に影響します。初回だけ遅く、その後は正常なら、初回の名前解決とハンドシェイクを分けて確認しましょう。転送を続けると遅くなる場合は、輻輳、サーバーの速度制限、端末の処理能力を優先して調べてください。

条件をそろえて公平に比較する

なるべく近い地域、同程度のサービス条件、同じテスト先を選び、同じ端末とネットワークで交互にテストしてください。プロトコルとトランスポートの組み合わせを毎回記録し、プロキシグループの選択を固定したうえで、ルールによって片方のアクセスだけが直接接続されていないことも確認します。ノード、DNS、TUNの状態を同時に変更したり、片方だけバックグラウンドでダウンロードしている状態で比較したりしないでください。テスト順を入れ替えると、先のテストでは回線が空いていたのに、後のテストでは混雑していたといった時間差を、プロトコルの違いと誤認しにくくなります。

性能の症状と優先して確認する箇所
症状	まず確認する項目	すぐに結論づけないこと
最初の表示が遅い	DNS、ハンドシェイク、コールド接続	プロトコル全体のスループット不足
大容量ファイルの転送が遅い	帯域、輻輳、CPU、サーバー側の制限	ノードの遅延測定だけで決まる
画面ロック後に電池消費が増える	接続維持、バックグラウンド要求、再接続、ログ	特定のプロトコルが必ず最も電池を消費する

モバイルの電池消費は通信の「起動」も影響する

スマートフォンの電池は暗号化処理だけでなく、無線通信、バックグラウンドでの起動、繰り返しの再接続でも消費されます。短い間隔で接続を維持すれば切れにくくなる一方、無線通信がアクティブな時間が長くなることがあります。間隔が長すぎると、ルーターや通信事業者のネットワークがアイドル状態のマッピングを削除し、その後の再ハンドシェイクにつながる場合があります。適切な設定は接続環境によって異なります。ネット上で紹介されている極端に短い接続維持間隔を、すべてのプロトコルに一律で適用しないでください。画面ロック後の数分間の電池残量だけで、長期的な傾向を判断するのも避けましょう。

システムプロキシとTUNでは対象となる通信範囲も異なるため、電池消費の測定結果が変わることがあります。システムプロキシが影響するのは、主にその設定に従うアプリです。TUNはさらに多くの通信を取り込み、処理するDNS問い合わせや接続イベントも増える場合があります。同じノードでTUNに切り替えて電池消費が増えても、プロトコルの性能が急に低下したとは限りません。処理対象が増えた可能性があります。デバッグ用ログ、頻繁なプロキシグループの自動テスト、短い間隔でのサブスクリプション更新も、余分な動作を増やします。比較前に設定をそろえ、十分な時間をかけて観察してください。

デスクトップではコアプロセスのCPU使用率、メモリ、接続動作をあわせて確認できます。モバイルではシステムの電池使用量、発熱、バックグラウンド動作の制限を参考にしてください。短時間の転送量の増加でCPU使用率が上がっても、継続的な異常とは限りません。メモリのキャッシュが増えても、必ずしもメモリリークではありません。同じ負荷をかけたときに、繰り返し同じ傾向が見られるかが重要です。最終的な選択では、普段使うアプリの応答と安定性を重視しましょう。測定は問題の特定に役立て、環境から切り離した速度ランキングや電池消費ランキングを作るために使わないでください。

サブスクリプション形式と設定の互換性：インポートから適用まで

ノード一覧と完全な設定ファイルを区別する

サブスクリプションURLはコンテンツを取得するためのアドレスであり、形式そのものではありません。同じURLでも、パラメーターやクライアントを示す情報によって返される内容が異なる場合があります。Clash YAMLには通常、プロキシ、プロキシグループ、ルールが含まれます。ノードの共有リンクには1つの接続情報だけが含まれることがあり、Base64のリストは複数の共有リンクをまとめてエンコードしたものが一般的です。ファイルの拡張子やウェブページのダウンロードボタンの表示だけでは、実際の形式を保証できません。インポート前に提供元が明記する対応形式を確認してください。解析エラーが出たら、URLの文字を手当たり次第に変えるのではなく、内容の種類を確認しましょう。

mihomoの設定では、proxiesに接続情報を記述し、proxy-groupsでプロキシグループを構成し、rulesで通信に使うポリシーを指定します。ノード一覧だけを受け取った場合、クライアントがプロキシグループを自動生成することもあれば、ユーザーが完全な設定を補う必要があることもあります。インポートに成功しても、ノードだけがあり使えるルールがない状態は、プロトコル非対応とは別の問題です。形式ごとの具体的なインポート手順は、サブスクリプションリンクとローカルYAMLファイルのインポート方法をご覧ください。設定の生成をプロトコルの自動変換と混同しないようにしましょう。

形式を変換しても、足りない情報は補えない

変換ツールは既存のフィールドを並べ替えられますが、欠落したパスワード、TLS名、サーバー固有のパラメーターを推測できません。また、未対応のプロトコルを古いコアで使えるようにすることもできません。共有形式によっては、複雑なトランスポート設定をすべて表現できないことがあります。変換後に正しいYAMLができたように見えても、重要なフィールドが失われている可能性があります。提供元がmihomo専用のサブスクリプションも用意している場合は、まずその形式を使い、クライアントで追加処理が行われていないか確認してください。サブスクリプションURLを扱うツールはアクセス認証情報にも触れるため、利用前にデータの処理場所や保存方法を確認しましょう。

YAMLのインデント、フィールドの型、参照関係も互換性に関わります。ポートは通常数値で指定し、真偽値にはtrueまたはfalseを使います。名称を参照する場合は、参照先のオブジェクトと一致していなければなりません。プロキシグループをProxyと定義したのに、ルールで別の綴りを指定すると、対象のポリシーが見つかりません。YAMLのパーサーが構文を読み取れても、コアの設定スキーマに合っているとは限りません。構文エラー、設定の意味上の誤り、実行時の接続エラーを順番に切り分けましょう。すべての問題にクライアントの再インストールで対処しないでください。

# ローカルの入口とルーティング設定例。Proxyプロキシグループは完全な設定ファイルで定義してください
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - DOMAIN-SUFFIX,github.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

上記は完全な設定に組み込むための例であり、サーバーの認証情報は含みません。mixed-portはHTTPとSOCKSで共用するローカルの待ち受けポートを設定します。allow-lan: falseは、このプロキシをLANに公開しない設定です。mode: ruleはルールに従ってリクエストを振り分けます。log-level: infoは通常の動作確認に使います。ポートは実際の環境に合わせて変更できます。これらの値がすべてのクライアントの初期設定とは限りません。ルールは上から順に照合され、最初に一致したルールのポリシーが使われます。末尾のMATCHが、ほかのルールに一致しないリクエストを処理します。

サブスクリプションの更新、オーバーライド、設定の移行

サブスクリプションから生成されたファイルを直接編集すると、次回の更新で変更が上書きされることがあります。クライアントにオーバーライド、拡張、マージの機能がある場合は、そちらを優先し、更新後も適用されることを確認してください。配列を置き換えるか追加するかはクライアントによって異なります。MATCHの後ろにルールを追加しても、期待どおりに動作しないことがほとんどです。挿入位置については、カスタムルールの構文と優先順位をご覧ください。移行時は、まずノードと基本的なプロキシグループを残して動作確認を行い、その後DNS、ルールセット、ほかの拡張を戻していきます。エディター内のテキストだけでなく、実行中の設定を項目ごとに確認してください。

用途に合わせてプロトコルとクライアントを選ぶ

日常のウェブ閲覧、仕事、長時間のダウンロード

日常のウェブ閲覧やリモートワークでは、接続が安定して確立されること、証明書が正常に検証されること、普段使うサービスに継続してアクセスできることを重視しましょう。現在のSS、Trojan、VLESSの設定でこれらを満たしているなら、新しいプロトコル名に変えるためだけに移行する必要はありません。仕事用のアプリは長時間接続を維持する場合があります。また、組織のネットワークポリシーによって利用が制限されることもあります。まず許可されている利用方法を確認してください。リモートデスクトップや共同作業ツールが切断される場合は、ウェブページの遅延を一度測るだけでなく、アイドルタイムアウトやネットワーク切り替えを確認しましょう。

長時間のダウンロードでは、持続的なスループット、パケットロスからの復旧、サーバー側の制限を確認してください。UDP経路が正常なら、Hysteria2やTUICを比較候補にできますが、常に最良とは限りません。回線の帯域が限られている場合、どのプロトコルでも実際の接続能力を超えることはできません。送信設定が過度に強いと、同じネットワークのビデオ会議やほかの端末に影響することもあります。比較時はダウンロードだけでなく、ほかのアプリの応答も観察し、短時間の最高速度ではなく、全体の作業負荷を満たせる設定を選んでください。

音声通話、ゲーム、モバイル回線

リアルタイムアプリはジッター、パケットロス、瞬間的な停止の影響を受けやすく、平均スループットが主な指標とは限りません。まずアプリの通信が実際にプロキシを経由していることと、ノードおよびコアが必要なUDP転送に対応していることを確認してください。システムプロキシ設定に従わないアプリもあるため、システムプロキシを有効にするだけでは通信をすべて取り込めません。TUNが必要な場合は、権限とルーティングを確認してください。プロキシがUDPを転送できても、出口サーバー、接続先サービス、中間ネットワークがその通信を許可するとは限りません。接続記録で接続先と出口を照合しましょう。

スマートフォンがWi-Fiとモバイル回線を頻繁に切り替える場合は、復旧までの時間、バックグラウンドでの再接続、画面ロック中の動作を確認してください。固定回線で優れたQUICノードでも、別の接続環境ではUDP経路の影響を受ける可能性があります。一般的なTCP系ノードでも、サーバーのアイドルタイムアウトにより接続を頻繁に作り直すことがあります。デスクトップの結果をそのままスマートフォンに当てはめず、通勤中など実際のモバイル環境で評価しましょう。電池消費が気になる場合は、まず不要なバックグラウンドの接続確認を減らし、そのうえでプロトコルの違いを比較してください。

設定の対応状況を基準にクライアントを選ぶ

初めてインストールする場合は、まずClash Plusを確認し、OSや操作習慣に合わせてほかのクライアントと比較してください。Windowsのダウンロードページでは、Clash Verge Rev、FlClash、Clash Nyanpasuも紹介しています。Clash for Windowsは開発終了と記載されています。macOSではClash Plus、Clash Verge Rev、FlClashを比較できます。ClashX Metaは開発終了後のアーカイブプロジェクトです。旧プロジェクトで一部のサブスクリプションを読み込めても、新しいプロトコル拡張を扱うのに適しているとは限りません。古い画面のスクリーンショットから、現在のコアの対応状況を推測しないでください。

Androidではダウンロードページの掲載順を参考に、Clash Plus、Clash Meta for Android、FlClash、Surfboardを比較し、使いたいプロトコルとサブスクリプション形式に個別に対応しているか確認してください。どのクライアントも設定構文が完全に同じとは限りません。iOSではClash Plusをおすすめします。公式サイトはclashplus.ioです。LinuxではClash Verge RevとFlClashを比較できます。一般的なデスクトップユーザーはまずGUIクライアントを選び、プロセス、サービス、権限を自分で管理する必要がある場合に限り、mihomoコアを直接導入するとよいでしょう。

選ぶ順序を決めておきましょう。まず端末が対応するもの、次にサーバーが提供するもの、接続ネットワークで利用できるものを確認し、最後に性能を比較します。候補ごとにパラメーター一式の説明と、接続に成功した記録を残してください。後から説明できないノード名だけが残るのを防げます。複数の候補を使う場合は、まず手動選択でテストする出口を固定し、その後で自動選択を段階的に有効にします。自動選択によって実際の出口が分からなくなると、改善がプロトコル、サーバー、プロキシグループの切り替えのどれによるものか判断できません。具体的な操作手順は使い方ガイド、用語は用語集をご覧ください。

検証とトラブル対処：エラーが起きたレイヤーから原因を探す

まずリクエストがクライアントに届いているか確認する

トラブル時は、プロトコルを変える前にローカルの接続入口から確認しましょう。コアが動作していて、設定の読み込みに成功しているか確認し、システムプロキシが指定するアドレスとポートを照合します。アプリがシステムプロキシに従わない場合は、TUNが必要か、必要な権限があるかを確認してください。接続先が明確なテストを行い、接続記録でドメイン名、一致したルール、出口のプロキシグループを確認します。記録がまったくない場合は、アプリのプロキシ設定、除外リスト、ルーティングの取り込みを優先して調べます。記録があるのにDIRECTで接続される場合は、リモートノードのパスワードではなく、モードやルールを確認しましょう。

ローカルの接続入口を個別に確認する場合は、curlをインストールしたターミナルで次の短いコマンドを実行できます。ポートは実際に動作している設定に合わせてください。混合ポートを変更した場合は、コマンド側も合わせて変更します。レスポンスが返れば、そのリクエストが完了したことは分かりますが、出口の確認には接続記録も必要です。このコマンドは一般公開のウェブページをリクエスト先として使います。すべてのアプリの通信方式を検証できるものではなく、UDPを使うアプリの個別確認にも代用できません。

curl -I --proxy http://127.0.0.1:7890 https://example.com/

名前解決、ハンドシェイク、認証のエラーを切り分ける

ドメイン名の解決に失敗した場合は、プロキシサーバーのドメイン名と、最終的な接続先のどちらで失敗しているかを確認してください。前者で失敗すると、リモート接続を一切確立できません。後者の問題は、特定のウェブサイトだけに影響することがあります。サーバーアドレスをIPアドレスに置き換えると、TLSで使う名前の処理が変わる場合があります。一時的な比較であっても、サーバー指定の名前設定は維持してください。接続タイムアウトは、制限時間内に何らかの段階を完了できなかったことを意味するのが一般的で、パスワードの誤りとは限りません。ログに詳しい原因が記録されていない場合は、別の利用可能なノードやネットワーク環境でも確認しましょう。

TLSエラーでは、まずシステム時刻、証明書の有効期限、サーバー名、信頼チェーンを確認します。認証エラーが出たら、パスワード、UUID、鍵の形式、サーバーがそのアカウントを許可しているかを調べてください。VMessでは時刻のずれ、VLESSではflowと外側の方式、Hysteria2とTUICではプロトコルの世代、UDP経路、認証フィールドを確認します。エラーを消すために、証明書検証を無効にし、DNSを変更し、トランスポート方式も同時に変えるのは避けてください。特定した変数を1つずつ変更すれば、結果を正しく判断できます。

接続できてもアプリに問題がある場合は中間の経路を確認する

小さなウェブページは開けるのに、大容量データの転送が止まる場合は、経路MTU、パケットロス、サーバー側の制限、端末のリソースを確認してください。QUICにはデータグラム経路に関する要件があり、ネットワーク機器や制限された経路が接続や転送の問題を引き起こすことがあります。ただし、検証せずに一律のMTU値を設定しないでください。特定のアプリだけ失敗する場合は、独自のDNSやプロキシ設定を使っていないか、システムプロキシの影響を受けない方式で接続していないかを確認します。特定のドメインだけで問題が起きる場合は、ルールとDNSの結果を照合してください。それだけでプロトコル全体の障害とは判断できません。

サブスクリプションの更新失敗は設定を取得する経路の問題であり、動作中のノードの接続経路とは限りません。ブラウザーからサブスクリプションURLにアクセスできても、クライアントの更新時に同じプロキシや証明書の信頼環境が使われるとは限りません。サブスクリプションの更新失敗と自動更新の設定を参考に、タイムアウト、証明書、形式のエラーを個別に確認してください。サブスクリプションURL全体を公開しないでください。パスやクエリパラメーターにアカウントの認証情報が含まれている場合があります。スクリーンショットやログでは必ず伏せてください。ノードのパスワード、UUIDなどの認証情報も、公開の問い合わせに記載しないでください。

再現可能な結果を記録してから移行を判断する

問題を適切に記録するには、OS、クライアント名、実際に動作するコア、プロトコルとトランスポートの組み合わせ、エラーが発生した段階、実施済みの単一変数テストを含めてください。必要な場合はログレベルを一時的に上げて問題を再現し、その後は通常の設定に戻して、過剰なログが長期間残らないようにします。新しい設定だけ失敗して古い設定が正常なら、フィールドと対応範囲を比較してください。すべてのノードが同時に失敗する場合は、まず端末のネットワークとローカルの接続入口を確認しましょう。一般的な問題についてはヘルプセンターもご覧ください。コアの機能不足やプロジェクトの開発終了が明確になってから移行を計画するほうが、何度も再インストールするより安定した結果につながります。