Clashのプロトコルとコアの選び方

プロトコル・通信方式・コアの役割

クライアントの画面とプロトコルの実装は別

Clashで接続先を1つ選ぶとき、実際には複数の層が関係します。プロトコルは認証、接続先の指定、データのカプセル化方法を定めます。通信方式はTCPやWebSocketなどを使ってデータを届けます。TLSなどのセキュリティ層は、暗号化やサーバーの認証を担います。これらは1つの共有リンクにまとめられていることがよくありますが、同じものではありません。VLESSと表示されていても、TLSが有効とは限らず、通信方式も特定できません。

GUIクライアントはサブスクリプション管理、タスクトレイメニュー、システムプロキシ、設定編集を担当し、コアは接続の確立、ルール判定、DNS、データ転送を担います。画面にプロトコル名が表示されていても、同梱コアがその拡張機能すべてに対応しているとは限りません。コアがパラメーターを認識できても、設定エディターがその内容を完全に保存できるとは限りません。互換性を判断するには、クライアントの説明、実際に動作しているコア、コアに渡される最終的な設定を確認してください。インストーラーの名称だけでは判断できません。

オリジナルのClash、Meta、mihomoの関係

オリジナルのClashは、プロキシ設定、グループ、ルール、設定ファイルの基本的な使い方を確立しました。Clash.Metaはこのエコシステムを拡張してプロトコルやネットワーク機能を追加し、その後mihomoの名称を引き継いで開発が続いています。そのため、古い資料にあるMetaコアと現在のmihomoには明確なつながりがありますが、過去の設定がすべてそのまま使えるわけではありません。機能の追加時期、キー名の変更、既定の動作などは、実際に使用するコアのドキュメントで確認してください。

オリジナルのオープンソースコア、過去のPremium版、後発の派生コアは区別が必要です。古いチュートリアルにあるスクリプト、ルールプロバイダー、仮想NICの機能は、異なる派生版を対象としている場合があり、「Clashの設定」と書かれているだけで流用できるとは限りません。移行時はまずプロキシ設定とシンプルなグループを残し、DNS、ルールセット、TUNを段階的に戻してください。高度な項目を一度にすべて追加すると、構文エラーと動作の変化が重なり、原因を特定しにくくなります。

対応機能を確認してから画面を比較

Windowsを初めて使う方は、まずダウンロードページでおすすめしているClash Plusから始め、設定に応じてClash Verge Rev、FlClash、Clash Nyanpasuを比較するとよいでしょう。クライアントを選ぶ際は、サブスクリプションを追加できるか、必要なプロトコルが動作するか、システムプロキシやサービスモードを管理しやすいかを確認してください。同じリンクを読み込めるというだけで、DNS、オーバーライドの適用順、TUNの動作まで同じだと判断しないでください。

アーカイブ済みのクライアントは、より慎重に扱う必要があります。Clash for Windowsは開発が終了しています。旧環境の維持や過去の設定の確認には役立ちますが、新しいプロトコルの対応状況を判断する用途には向きません。コアの入れ替えも、どの環境でも使えるアップグレード方法ではありません。クライアントが特定の制御API、起動オプション、ディレクトリ構成に依存している場合があります。画面に明確なコア管理機能がない場合は、実行ファイルを直接上書きせず、サポートされている更新方法を使ってください。

SSとVMess：暗号化と接続の仕組み

SSのシンプルな構造と方式の互換性

Shadowsocksは通常SSと略され、比較的シンプルな暗号化プロキシとして設計されています。クライアントとサーバーでサーバーアドレス、ポート、暗号化方式、鍵情報を共有し、接続先へデータを転送します。すべての接続をWebリクエストに見せかける必要も、完全な証明書の仕組みを必須とする設計でもありません。そのため、設定が単純で双方の対応状況が明確な環境では管理しやすいプロトコルです。ただし、構造がシンプルでも任意の組み合わせで接続できるわけではありません。暗号化方式が一致しなければ、接続の初期段階で失敗します。

設定を確認するときは、まずcipherとpasswordを確認します。従来のAEAD方式とShadowsocks 2022シリーズでは鍵の扱いが異なります。後者は鍵の長さや形式に具体的な要件があるため、一般的な短いパスワードをそのまま入力できません。サーバーから提供された共有リンクに特殊文字が含まれる場合は、元のエンコードを保持してください。手作業で分解して貼り付けると、余分な空白、誤ったデコード、末尾の欠落などにより、ポートには接続できても通信を完了できないことがあります。

一部のSS設定ではプラグインも必要です。プラグインは追加の通信方式やカプセル化を担いますが、SSの中核プロトコルに必須の要素ではありません。コアが特定の暗号化方式に対応していても、共有リンクで使われているプラグインやオプションにも対応しているとは限りません。トラブル時はサーバー、暗号化方式、プラグイン名、プラグインのパラメーターを個別に確認してください。設定エラーを消すためだけにプラグイン項目を削除すると、問題が解析時からハンドシェイク時に先送りされるだけです。

VMessの認証と過去のオプション

VMessはV2Rayエコシステムに由来し、ユーザー識別子、リクエスト認証、データ暗号化の仕組みを組み合わせています。一般的な設定ではUUIDでユーザーを識別します。比較的シンプルなTCP接続でも、WebSocketやTLSなどとの組み合わせでも動作します。実際の負荷は構成全体によって変わります。TCPのみの設定とTLS・WebSocketを重ねた設定を比べても、その差をすべてVMessプロトコル自体に帰することはできません。

古い資料にはalterIdがよく登場します。これは過去の互換性に関わる項目で、古いチュートリアルを参考に適当に設定するものではありません。現在のAEAD方式では通常ゼロを使いますが、最終的にはサーバー側の指定に合わせてください。システム時刻も確認しましょう。時刻の許容範囲を使う認証方式は、時計が大きくずれていると失敗する場合があります。Windowsのスリープ復帰後、仮想マシンの一時停止後、手動で時刻を変更した後は、UUIDを何度も変えるより先にシステム時刻を同期してください。

通信パラメーターは、関連する項目をまとめて確認してください。WebSocketのパス、リクエストのHost、TLSのサーバー名は同じ場合も異なる場合もあり、それぞれ役割が異なります。パスを間違えると、明確な「プロトコル設定エラー」ではなく、通常のWebページが返されたり、接続のアップグレードが拒否されたりすることがあります。サーバーから提供された情報を基準にし、1つのドメインを見てすべての項目にコピーしないでください。また、ブラウザーでそのドメインを開けることは、プロキシのハンドシェイクが正常である証拠にはなりません。

2つのプロトコルの選び方

すでに安定して使えるSSの設定があり、用途がWebサイト、コードリポジトリ、日常のアプリであれば、ほかのプロトコルの名前が新しいという理由だけで移行する必要はありません。SSは項目が少なく、問題を特定しやすい一方、拡張プラグインや新しい暗号化方式を使うと互換性の条件が増えます。VMessは既存のV2Ray設定で使われることが多く、既存の環境や通信方式との組み合わせを活用できる反面、関連する複数の項目をまとめて管理する必要があります。

UDPは個別に検証してください。Webページが開けても、確認できるのは該当するTCP通信が使えることだけです。ゲームのボイスチャット、リアルタイム通信、その他のUDP通信が転送できるとは限りません。プロトコル実装、サーバー設定、設定ファイルのUDP有効化、アプリの通信が実際にクライアントを通っているかも確認しましょう。テスト条件は同じネットワーク、接続先、トラフィックの適用方法にそろえてください。そうしないと、プロトコルの能力とローカルのルーティングの違いを区別できません。

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

Trojanで正しいTLS設定が重要な理由

Trojanの一般的な構成では、TLS上でプロキシリクエストを送信し、安全な接続上でパスワード認証と宛先への転送を行います。TLSの機能を重要な基盤としているため、証明書検証は任意の追加設定ではありません。設定のサーバーアドレスにはIPアドレスを指定できても、証明書に対応する名称は通常ドメイン名です。接続先アドレスとTLSサーバー名の役割を理解し、すべての項目に同じ文字列を入力しようとしないでください。

TLS接続時、クライアントは証明書チェーンが信頼されているか、有効期限が正しいか、名前が一致するかを確認します。いずれかに問題があると、その後のTrojan認証に進めない場合があります。証明書エラーが発生したら、まずドメイン名、システム時刻、サーバー側の証明書設定を確認してください。検証のスキップを恒久的に有効にすると、接続先の本人確認が弱まり、誤ったサーバーに接続している問題を見逃す可能性があります。一時的な切り分けと通常運用の設定は区別してください。

パスワードが正しくても、通信方式が一致しているとは限りません。直接TLSを使う構成もあれば、WebSocketなどを追加する構成もあります。実際の組み合わせに合わせてクライアントを設定してください。サーバーが直接TLSのみを受け付ける場合、ローカル設定にWebSocketのパスを追加しても、パスワードが正しいだけでは接続できません。サブスクリプションの追加後は、変換ツールがネットワーク種別を保持しているか、現在のコアが関連する拡張機能を認識できるかも確認しましょう。

VLESSの軽量な認証は、完全な暗号化を意味しない

VLESSもV2Ray関連のエコシステムに由来します。プロトコル自体の一部のオーバーヘッドを減らし、安全性の確保を外部の通信層に委ねる設計です。一般的にはUUIDでユーザーを識別し、TLSなど対応しているセキュリティ機構と組み合わせます。重要なのは、VLESSという名称だけでは通信が暗号化されていると保証されないことです。実際のセキュリティ層と通信パラメーターを確認し、クライアントに表示されたプロトコル名だけで接続の保護方式を判断しないでください。

VLESSの互換性問題は、特定のflow、通信方式、REALITY関連の項目など、拡張機能の組み合わせに集中しがちです。基本プロトコルに対応していても、すべての拡張機能や任意の組み合わせに対応するとは限りません。一部のフロー制御オプションは、特定の通信方式やセキュリティ構成でのみ使えます。他の環境で見つけた項目をそのまま追加すると、設定の解析には成功しても接続時に失敗する可能性があります。サーバーとの取り決めと、現在のコアの対応範囲を基準にしてください。

REALITYを「サーバー名を変えるだけ」と捉えることはできません。接続には公開鍵、ショートID、その他のネゴシエーション用パラメーターが関わり、クライアントとサーバーで一致している必要があります。公開鍵は正確に受け渡す設定情報であり、任意の文字列を生成して入力するものではありません。インポート内容が不完全な場合は、使用中のクライアントに合ったサブスクリプションを取得するか、元の設定を1項目ずつ確認してください。画面のエラーを消すために、不足項目へランダムな値を入力しないでください。

ドメインに関する各項目の役割

接続先サーバーアドレスはパケットの送信先を決めます。TLSのSNIはハンドシェイク時にホスト名を通知し、証明書の検証名はサーバーの身元を確認します。HTTP Hostはアプリケーション層のリクエスト情報です。シンプルな構成では同じ値が使われることもありますが、概念上は別の項目です。トラブル時は各値の出どころを明確にし、サーバーの要件に合っているか確認しましょう。すべてのドメインを「開けるサイト」の名前に置き換えるより確実です。

TrojanとVLESSのどちらを選ぶかは、まず既存サーバーの対応状況と設定の完全性で判断してください。サーバーが標準的なTrojanのTLS設定を提供し、証明書が適切に管理されているなら、一般的なTLSの手順で確認しやすいでしょう。サーバーがVLESSの特定の拡張機能を明示的に要求する場合は、その組み合わせへの対応を確認済みのクライアントとコアを選んでください。設定項目を減らすためにセキュリティ層を外したり、新機能を追うために安定した設定へ不要な拡張機能を追加したりしないでください。

Hysteria2とTUIC：QUICベースのプロトコルを比較

QUICの特徴と利用条件

QUICはUDP上で、安全な接続、多重化、輻輳制御などの機能を提供します。複数の論理ストリームが1つのTCP接続を共有する場合と比べ、QUICではあるストリームのデータ損失が、トランスポート層で別の独立したストリームを直接ブロックするのを防げます。ただし、同一ストリーム内のデータ損失は適切に処理する必要があります。パケットロスがなくなるわけでも、帯域制限を超える容量が生まれるわけでもありません。関連するプロトコルを検討する前に、ネットワーク上でUDP通信を継続できるか確認してください。

Hysteria2とTUICはどちらもQUICを利用しますが、名前を入れ替えて使える同一のプロトコルではありません。認証方式、UDP転送の仕組み、輻輳制御のオプション、各パラメーターが異なります。サーバーが一方を使っている場合、クライアント側でプロトコル種別だけ切り替えて、残りの項目をそのまま使うことはできません。旧世代Hysteriaの設定をHysteria2用とみなさないでください。プロトコルと設定には明確な違いがあります。

Hysteria2の帯域推定と送信動作

Hysteria2は、高遅延やパケットロスなどの複雑な通信環境での性能を重視し、帯域設定や輻輳制御に関する機能を備えています。設定の上り・下り帯域は、速度測定結果の表示ではなく、実際の送信制御に使われる場合があります。回線の実効速度を大幅に超える値を指定しても速くなるとは限らず、キューの滞留、パケットロス、操作時の遅延を招くことがあります。現在の実装の説明、サーバー側の制限、実際の回線性能に合わせて設定してください。

実装によっては、帯域設定やネゴシエーションの条件に応じて輻輳制御の動作が変わります。そのため「空欄なら必ず速い」「上限まで入力すれば必ず速い」のどちらも正しくありません。共有ネットワークでは、他のユーザーやアプリも上り回線のキューを使います。ダウンロード容量に余裕があっても、上りが埋まると確認応答や操作の遅延に影響します。テストでは大容量ファイルの一時的な最高速度だけでなく、Webページの応答、音声の安定性、継続的な転送も確認してください。

ポートホッピング、難読化などのオプション機能を使うには、サーバー側の対応も必要です。有効にしても、ローカルのファイアウォール、ネットワーク機器、サーバーのルールで対象のUDPポート範囲が許可されていないと、接続が一度は確立しても切断されることがあります。これらの機能は、性能問題を一般的に解決する設定ではありません。基本接続が安定するまでは、サーバーで利用できることを確認したシンプルな設定を使い、追加オプションは1つずつ戻してください。

TUICの接続多重化とUDP処理

TUICもQUICを使ったプロキシ通信を重視しており、一般的な設定にはUUID、パスワード、輻輳制御、UDPリレー方式が含まれます。世代の異なるプロトコル同士で互換性が保証されているわけではありません。サブスクリプション変換で種類の名前だけが残り、認証情報が失われると、インポートに成功しても接続できません。UDPリレー方式によってパケットの運び方が変わるため、クライアントとサーバーの双方が同じ動作に対応しているか確認してください。インターネット上の特定の方式名を、あらゆる環境での正解とみなさないでください。

0-RTT関連のオプションは、条件が整えば再接続時の待ち時間を短縮できますが、初回接続を常に速くする機能ではありません。セッション再開やセキュリティ上の選択、サーバー側の対応が関係します。プロトコルライブラリが機能を備えていても、アプリがあらゆる状況で利用するとは限りません。日常的な用途では、低遅延オプションを片端から有効にするより、証明書の安定性、正しい認証、適切なアイドルタイムアウトを先に確認しましょう。

UDPに強い制限があるネットワークでは、Hysteria2とTUICのどちらも唯一の接続手段として適さない場合があります。検証済みのTCP系設定を比較用に残しておくと、サーバーの問題と接続ネットワークの制限を切り分けやすくなります。Wi-Fiとモバイルネットワークを切り替えたら、あらためて確認してください。UDPのアイドル時のマッピング、パスMTU、輻輳状況はネットワークごとに異なる場合があります。オフィスでのテスト結果を、そのまま移動中の環境に当てはめないでください。

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

「速さ」を比較できる指標に分ける

接続速度には、少なくとも3つの異なる観点があります。新しい接続が確立するまでの時間、操作に対する応答時間、長時間の転送で得られるスループットです。ハンドシェイクの待ち時間が短くなっても、大容量ファイルのダウンロード速度が上がるとは限りません。継続的な転送に向いた設定でも、小さなリクエストの応答が遅くなる場合があります。クライアントに表示されるレイテンシは、特定の測定先と方法による結果です。すべてのアプリの往復時間と同じではなく、Webページの読み込み完了時間を直接示すものでもありません。

測定結果には、ローカル回線、サーバーの負荷、接続先の応答、経路、暗号化の実装、通信のカプセル化などが影響します。プロトコルを比較する場合は、できるだけ同じ端末、同じ接続ネットワーク、近い場所のサーバー、同じ接続先にそろえてください。異なる地域や帯域のサーバーにつながる2つの設定を比べた場合、その差はまず通信経路全体の違いを反映します。条件がそろっていないときは、性能の順位をつけるより「現在の環境ではこちらが適している」と記録するほうが正確です。

CPUとメモリの負荷はプロトコル名だけでは決まらない

暗号化アルゴリズムがプロセッサの命令セットを利用できるかどうかで、実際のCPU負荷は変わります。ユーザー空間のネットワークスタック、TUN、ルールセットの規模、接続数もリソース使用量に影響します。Windowsのタスクマネージャーに表示されるクライアントのプロセスには、画面の処理しか含まれない場合があります。転送を担うコアが別プロセスで動作していることもあるため、関連するプロセス全体を確認してください。画面側の負荷が低いからといって、プロキシ経路全体のリソース消費もわずかだとは限りません。

接続を再利用すると、接続確立やハンドシェイクの繰り返しを減らせますが、接続のライフサイクル管理が複雑になります。短いリクエストが大量にある場合には有効でも、少数の長時間接続では効果が目立たないことがあります。ルールプロバイダーの更新、サブスクリプションの再読み込み、接続ログ、頻繁な速度測定もバックグラウンド処理を発生させます。負荷が高い場合は、まず連続した速度測定と詳細ログを停止し、アイドル時と通信中の状態を観察してください。すべてのバックグラウンド処理を動かしたまま、負荷を特定のプロトコルだけのせいにしないでください。

スマートフォンの電池消費はスリープ解除とネットワーク状態に左右される

モバイル端末では演算負荷だけでなく、無線モジュールが起動している時間や通信状態を維持する時間も考慮が必要です。頻繁なキープアライブ、短い間隔のヘルスチェック、繰り返される再接続は、無線モジュールの稼働時間を延ばす可能性があります。TCPかQUICかだけで、どちらが省電力か決まるわけではありません。電波が弱く再送が続く接続は、電波が安定した別のプロトコルより電力を多く消費する場合があります。バックグラウンドアプリの数、省電力設定、ネットワークの切り替えも結果に影響します。

実際に比べるときは、読書、動画、音声通話などのタスクを決め、画面の明るさとネットワーク条件をそろえて、電池残量、温度、通信切断の有無を繰り返し確認してください。通常の使用に測定用の通信が混ざらないよう、大量の自動速度測定は事前に停止しましょう。待機中の電池消費が大きい場合は、キープアライブの間隔、ヘルスチェックの頻度、再接続のログを先に確認してください。大量通信のときだけ発熱する場合は、スループット、CPU、暗号化の実装を調べ、待機中の消費と負荷時の消費を区別してください。

日常利用では、最高速度を追い続けるより、十分な速度と安定性を重視しましょう。ノートPCでは電源接続時とバッテリー駆動時を、スマートフォンではWi-Fiとモバイル回線を分けて確認してください。測定条件と結果をあわせて記録し、元に戻せる設定を残しましょう。クライアントの測定項目について詳しくは、ノードの遅延測定と確認手順を参照してください。測定に失敗しても、すべての通信が使えないと決めつけないようにしましょう。

設定ファイル、サブスクリプション形式、パラメーターの互換性

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

サブスクリプションURLはコンテンツを取得する入口にすぎません。返される内容はClashの完全なYAML、エンコードされた共有リンクの一覧、特定アプリ専用の設定形式など、さまざまです。拡張子やWebページのタイトルだけでは形式を正確に判断できません。クライアントの認識結果とサービス提供元の説明を確認してください。完全な設定には通常、プロキシ設定、グループ、ルールが含まれます。ノード一覧だけの場合は、ほかの構造を補うためにクライアントのテンプレートが必要です。インポート後の動作も両者で異なります。

共有リンクを1つ認識できても、すべての高度なパラメーターを復元できるとは限りません。変換ツールが通信方式の拡張、UDPモード、クライアントフィンガープリント、セキュリティ層の項目を省略することがあります。変換先の形式に対応する項目自体がない場合もあります。「インポート後に名前は表示されるのに接続できない」ときは、同じサブスクリプションを何度も更新するのではなく、重要な項目がそろっているか確認してください。アカウントへのアクセス権を含むサブスクリプションURLは、不用意に公開せず、信頼できないオンライン変換ツールに送信しないでください。

YAMLの構文と設定の意味を分けて確認

YAMLではインデントが階層を決めます。スペースを使い、タブが混ざらないようにしてください。コロン、シャープ記号、特殊文字を含む値は、構造やコメントとして解釈されないよう適切な引用符で囲めます。構文エラーがないことは、ファイルを読み込めるという意味にすぎません。プロキシグループ名が存在するか、ルールの宛先が正しいか、プロトコルのパラメーターが有効かは別途確認が必要です。存在しないグループをルールが参照していると、読み込み時にエラーになる場合も、想定したルーティングが行われない場合もあります。

以下はmihomoで読み込める、ローカルのリスニング、グループ、ルール構成を確認するための最小限のダイレクト接続設定です。外部プロキシへの接続は含まれません。外部プロキシ機能を提供する設定ではなく、プロトコルの性能測定にも使えません。独立したテスト設定を使う前に、現在のファイルをバックアップしてください。クライアントがポートやDNS設定を自動的に統合する場合は、編集画面の内容だけで判断せず、画面上で最終的に適用された設定も確認しましょう。

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

proxy-groups:
  - name: ROUTE
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,ROUTE

ここでのmixed-portは、アプリがローカルのクライアントに接続するための入口であり、リモートサーバーのポートではありません。allow-lan: falseはLANからのアクセスを制限するため、ローカルでの確認に適しています。MATCHはフォールバックルールで、先行ルールに一致しなかった接続を指定先へ送ります。設定を移行するときにローカルの混合ポートとサーバーのポートを混同しやすいため、チェックリストでは別々に記録してください。

オーバーライド、プロバイダー、ルールの順序

GUIクライアントは、サブスクリプションにグローバルオーバーライド、スクリプト処理、設定の統合を適用する場合があります。そのため、ダウンロードした元のファイルとコアが使うファイルは、必ずしも同じではありません。サブスクリプションのキャッシュを手作業で編集しても、次回の更新で上書きされる可能性があります。クライアントが対応している場所にオーバーライドを保存し、適用順を確認するのが確実です。プロトコルの認証情報やサーバー設定に関わる項目を、共通テンプレートで意図せず上書きしないよう注意してください。

proxy-providersとrule-providersは、それぞれプロキシの一覧とルールの一覧を管理します。どちらもリモートからファイルを取得できますが、内容の構造と参照方法が異なるため、相互に置き換えることはできません。ルールは通常、記述された順番に判定されます。広い範囲に一致するルールを先に置くと、後続の細かいルールが適用されない場合があります。移行後は、プロキシの数が近いかだけでなく、グループ名、プロバイダーの参照先、フォールバック先も確認してください。

サブスクリプションの更新に失敗した場合は、アクセス失敗、認証切れ、応答内容の異常、形式の非対応を切り分けてください。詳しくはサブスクリプションの更新失敗と自動更新の設定を参照してください。再インポートが必要な場合は、サブスクリプションの追加ガイドを確認しましょう。まず独立した設定で検証してからルールやオーバーライドを移行すると、形式の問題と既存環境の問題が重なるのを防げます。

用途に合わせたプロトコルとクライアントの選び方

Web閲覧、開発ツール、日常業務

ブラウザー、ドキュメントサイト、一般的な開発サービスでは、まず安定したTCP接続が必要です。すでに利用しているSS、Trojan、VMess、VLESSの設定で問題がないなら、プロトコル名を理由に移行するのではなく、接続の安定性、証明書の管理、サブスクリプションの更新を確認してください。Windowsで初めてクライアントを選ぶ場合は、Clash Plusから始めましょう。インストール方法はWindowsクライアント一覧で確認でき、使い方に応じてほかの対応クライアントと比較できます。

コマンドラインツールは、必ずしもシステムプロキシに従いません。ブラウザーではアクセスできてもターミナルで失敗する場合、ターミナルにプロキシ環境変数が設定されていないか、ツール独自のプロキシオプションしか認識しない可能性があります。この場合、リモート側のプロトコルを変更しても解決しません。まずアプリの通信がどのようにクライアントへ届くか確認し、明示的なプロキシ設定かTUNを選んでください。開発環境では、コンテナ、仮想マシン、ホストでループバックアドレスが異なります。コンテナ内のlocalhostが自動的にWindowsホストを指すわけではありません。

リアルタイム通信、ゲーム、複雑なネットワーク

音声通話やリアルタイム操作では、平均レイテンシだけでなく、ジッター、パケットロス、通信の連続性が重要です。アプリがTCPでログインし、UDPで音声を送受信する場合もあります。そのため「ログインできるのに音が聞こえない」と「まったく接続できない」では、問題のある経路が異なります。プロトコルが必要なUDP転送に対応し、通信を適用する方法がアプリのトラフィックをカバーしているか確認してください。システムプロキシを迂回して直接接続するアプリもあるため、接続一覧とルールの適用状況を確認しましょう。

高遅延やパケットロスのある回線では、Hysteria2やTUICも候補に加え、比較用にTCP系の接続を残してください。現在のネットワークでQUIC接続を安定して確立できないなら、輻輳制御のパラメーターを調整しても効果は限られます。一方、UDPが利用できて長時間の動作も安定しているなら、従来の経験則だけを理由に候補から外す必要はありません。結論は具体的な接続環境に合わせ、ネットワークを切り替えたときは選び直せるようにしてください。

複数端末と長期運用

スマートフォンとデスクトップでサブスクリプションを共有する場合は、デスクトップで使える拡張機能がスマートフォンでも使えると考えず、すべてのクライアントに共通する対応機能を基準にしてください。AndroidではClash Plus、Clash Meta for Android、FlClash、Surfboardを用途に応じて比較できます。iOSではダウンロードページからClash Plusのストアページを開けます。クライアント名が異なっていてもプロトコルが使えないとは限りませんが、設定形式、ネットワーク拡張、バックグラウンドでの動作は個別に確認が必要です。

macOSではチップのアーキテクチャに合わせてインストーラーを選び、LinuxではGUIクライアントとコアを直接実行する構成を区別してください。デスクトップではClash Verge RevとFlClashを比較できます。サーバー環境では、設定ディレクトリ、権限、プロセスのサービス管理を明確にすることが重要です。詳しくはLinuxへのmihomo導入とsystemdサービスの設定を参照してください。システムサービスが正常に動いていても、デスクトップアプリが自動的にプロキシを使うとは限りません。

長期運用では、検証済みの基本設定と簡潔な変更履歴を残しておくと便利です。クライアントの更新、コアの交換、サブスクリプションの移行、TUNの有効化は、できるだけ別々に行ってください。各段階でブラウザー、ターミナル、必要なUDPアプリが正常に動作することを確認してから次に進みましょう。問題が再発したときに、プロトコル、ルール、システム設定が同時に変わった状態から原因を探すのではなく、明確な状態に戻せます。

プロトコル接続エラーを段階別に確認

失敗した段階を特定してから設定を変更

トラブル対処は、失敗が明確なリクエストを1つ選ぶところから始めます。アプリ、接続先、使用した設定、発生時刻を記録し、対応するログを確認してください。設定の読み込み失敗、サーバーへの接続失敗、ハンドシェイクや認証の失敗、アプリのリクエストタイムアウトは、それぞれ異なる段階の問題です。タイムアウトだけを見てすぐにプロトコルを変えたり、設定の読み込みに成功しただけでサーバーも正常だと判断したりしないでください。最初に現れた有効なエラーを探しましょう。その後に大量に記録される再試行ログは、同じ原因の繰り返しであることがよくあります。

設定の読み込み段階では、未対応のプロトコルやキー、インデント、グループ名の参照を確認します。特定の種類に対応していないと表示された場合は、クライアントの名称だけで判断せず、実際に動作しているコアを確認してください。ネットワーク接続段階では、サーバーの名前解決、アドレス、ポートを調べます。Windowsでは次のコマンドを使ってTCPポートに接続できるか確認できます。ドメイン名とポートはサーバーから提供された実際の情報に置き換えてください。例にあるドメインは、ドキュメント用のものです。

Test-NetConnection -ComputerName example.com -Port 443

このコマンドではプロキシの認証も、Hysteria2やTUICに必要なUDP通信も確認できません。TCPポートに接続できても、確認できるのは該当するTCP接続が基本的に到達可能ということだけです。QUIC系の接続は、コアのログとサーバー側の記録をあわせて判断してください。同じ番号のTCPポートに接続できたからといって、UDPも許可されているとは限りません。ファイアウォールやネットワーク機器が、2種類の通信を別々に扱うことがあります。

ハンドシェイク、DNS、ルールを個別に確認

ハンドシェイクまで進んだら、プロトコルに応じて認証情報、暗号化方式、TLSの名前、通信パスを確認します。証明書エラーでは時刻と名前、認証エラーではUUIDやパスワード、HTTPアップグレードのエラーではネットワーク種別、Host、パスを確認してください。ログに最終原因が直接表示されない場合もありますが、問題の範囲を絞り込む手がかりになります。詳細ログを有効にした場合は、調査後に適切なレベルへ戻してください。ログを共有する前に、サブスクリプションURLや接続情報などの機密情報を削除しましょう。

接続が確立してもアクセスできない場合は、DNSとルールを確認してください。名前解決をローカルシステム、コア、リモートのどこで行うかによって、結果や経路が異なる場合があります。あるルールが接続先を直接接続へ振り分けると、利用可能なプロキシ設定が使われません。範囲の広い別のルールが先に適用される場合もあります。クライアントの接続一覧で、接続先、適用されたルール、出口のグループを確認してください。現在選択されているグループ名だけでは判断できません。

グローバルモードはルールの影響を一時的に切り分ける方法にはなりますが、プロトコル認証、サーバーの障害、アプリの通信がクライアントを通っていない問題は解決できません。検証後は元の振り分け方式に戻し、テスト設定を使い続けないようにしてください。一部のドメインだけで失敗する場合は、名前解決とルールを確認するほうが有効です。すべての設定が突然失敗した場合は、正しく動いていたプロトコル項目を1つずつ変更する前に、システムのネットワーク、サブスクリプションの有効性、サーバーの状態を確認しましょう。

ローカルポートとTUNで確認する範囲

ブラウザーにローカルプロキシへ接続できないと表示されたら、まずコアが動作しているか、待ち受けポートとシステムプロキシの設定が一致しているか確認してください。ポートの競合はリモート側のプロトコルとは無関係です。対処方法は7890番ポートの使用状況を調べる方法を参照し、変更後はポート設定も確認してください。使用中のプロセスを確認せずに終了すると、ほかのソフトに影響する場合があります。用途を調べてから、旧クライアントを終了するかポートを変更するか判断しましょう。

TUNを有効にした後に問題が起きた場合は、サービスの権限、仮想NIC、ルーティング、DNSの適用を別の層として確認してください。まずTUNを無効にし、ローカルプロキシを明示的に指定して同じリモート接続を試します。明示的なプロキシで正常なら、次にシステムへの適用方法を確認してください。手順はTUNモードとサービスモードのガイドを参照できます。Windows Storeアプリではループバックの制限が関係する場合もあり、それだけでプロトコルの非互換と判断することはできません。

最後に、再現可能な記録を残してください。クライアントとコアの名称、プロトコルと通信方式の組み合わせ、失敗した段階、特定のネットワークだけで起きるかどうか、確認済みの比較結果を記録します。推測を並べるより、事実を残すほうが次の対応に役立ちます。クライアントを選び直す場合はダウンロードページへ、基本操作の順序を確認する場合は入門ガイドへ戻ってください。まず最もシンプルな接続経路を動作させてから、複雑な設定を1つずつ戻しましょう。