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

選定の基準を整理する：プロトコルだけで接続全体は決まらない

クライアントに表示されるプロトコル名は、接続方式の一部分を示すものです。通信は通常、アプリからシステムプロキシまたは仮想ネットワークインターフェースを経由し、ローカルのコアでドメイン名の処理とルール判定を行った後、選択した出力プロトコルでリモートサーバーへ送られます。どの段階で問題が起きても、ページが開かない、接続に時間がかかる、ダウンロードが中断するといった症状が現れます。こうした問題をすべてプロトコルのせいにすると、種類を次々に変えても、本当の原因が残ったままになりかねません。

クライアント・コア・プロトコル・トランスポートを区別する

クライアントは画面表示、設定管理、システムとの連携を担当します。コアは設定の解析、通信の振り分け、データの送受信を行います。プロトコルはクライアントとサーバー間の認証、カプセル化、トラフィック転送の方法を定めます。トランスポートはTCP、WebSocket、HTTP/2、QUICなどを使ってデータを運びます。TLSは特定の接続レイヤーで認証と暗号化を担います。それぞれ役割の異なるレイヤーです。「VLESS対応」と表示されていても、あらゆるVLESSのトランスポート構成に対応するとは限りません。画面に設定項目があっても、実際に動作するコアがその機能を備えているとは限りません。

ノードには、アドレス、ポート、認証情報、サーバー名、トランスポート設定も含まれます。同じプロトコル名でも、サーバー、回線、負荷状況はまったく異なる場合があります。SSとHysteria2のノードを1つずつ見ただけでは、後者のほうが速いとは判断できません。サーバーの設置場所、利用可能な帯域、クライアントからサーバーまでの経路は、カプセル化による負荷以上に体感を左右することがあります。まず利用環境の条件を確認し、次に実装方式を比較しましょう。プロトコルに「常に速い」「常に遅い」という評価をつけるべきではありません。

目的を明確にしてから性能を比べる

短いWebページの表示では、最初の名前解決やハンドシェイク、最初の応答が重要です。長時間のダウンロードでは、持続的なスループットと輻輳制御が重要になります。音声通話、会議、ゲームでは、ジッター、パケットロス、UDP転送が重視されます。スマートフォンの待機時には、接続維持や端末の起動回数が影響します。これらの要件は互いに相反することがあります。頻繁な接続確認や再接続は障害を早く検出できますが、無線モジュールの稼働が増える可能性があります。「最適なプロトコル」を選ぶ際は、「どのネットワーク、端末、負荷で使うのか」という条件も明確にしましょう。

セキュリティを比較する際も、どのレイヤーの話かを具体的にする必要があります。認証方式、暗号アルゴリズム、証明書の検証、認証情報の管理、サーバーの保守がセキュリティの範囲を構成します。新しいプロトコル名だからといって自動的に安全になるわけではなく、古いプロトコル名だけで具体的な設定の確認を省くこともできません。TLSを使う場合は、証明書チェーン、名前の一致、端末の時刻を確認してください。共有鍵を使う場合は、サブスクリプションURLや認証情報が漏れないように注意しましょう。暗号化通信で保護されるのは該当する通信経路であり、リモートサービスまで含めたエンドツーエンドの保護を意味するわけではありません。

以降の章では、この3つのレイヤーに沿って確認範囲を絞り込みます。まずコアが何を読み込めるかを確認し、次にプロトコルの設計上の違いを理解し、最後に実際の用途で検証します。結果を記録する際は、ネットワークの種類、クライアントとコアの情報、使用したトランスポート、発生した症状を最低限書き留めてください。次にネットワーク環境が変わったときも判断をやり直せるため、一度の偶然の結果を普遍的な結論として扱わずに済みます。対応クライアントをインストールする場合は、クライアントのダウンロードページでOSとアーキテクチャを選択してください。

コアの系譜：旧Clash、Meta、mihomo

Clashエコシステムは、1つのクライアントですべてをカバーするものではありません。旧Clashでは、設定、プロキシグループ、ルール、ローカル制御インターフェースなど、広く使われる構造が確立され、その後の派生プロジェクトでプロトコルやネットワーク機能が拡張されました。Clash.Metaはこの進化の過程で使われたプロジェクト名で、mihomoは同じ系統の後継名称です。資料でMetaとmihomoが出てきた場合、通常は同じ技術系譜を指しています。ただし、Metaと名前のついた過去のインストーラーが、現在のドキュメントに記載されたすべての機能に対応するとは限りません。

同じ系統でも機能がすべて同じとは限らない

旧Clashのオープンソース実装と、当時のその他の実装を混同しないでください。過去の記事では、ルールプロバイダー、仮想ネットワークインターフェース、スクリプトなどの機能が、ひとまとめに「旧Clash対応」と書かれている場合がありますが、実際には特定の実装だけで利用できた可能性があります。旧Clashの上流プロジェクトはすでにメンテナンスを終了しています。古い設定を新しいコアで読み込める場合はありますが、新機能が旧コアに追加されることは通常ありません。記事を読むときは、タイトルにClashとあるかだけでなく、具体的な設定項目と実装についての説明を確認してください。

mihomoは一般的なYAML設定の枠組みを引き継ぎつつ、VLESS、Hysteria2、TUIC、DNS、スニッフィング、TUNなどの関連機能を追加・強化しています。ただし、「対応」の範囲は使用するビルドやバージョンによって異なります。同じプロトコルでも、特定のトランスポート、認証方式、拡張フィールドへの対応は、基本機能より後に追加されることがあります。サードパーティ製クライアントには、コアが固定されているもの、コアを切り替えられるもの、独自の設定生成レイヤーを持つものがあります。サイトの説明、コアのドキュメント、クライアントの画面を照らし合わせて確認してください。

クライアントで実際に動作しているコアを確認する

まずクライアントの「バージョン情報」「コア管理」または実行ログを開き、実際に動作しているコアの名前とビルド情報を確認します。次に、設定がそのまま読み込まれるのか、サブスクリプション変換やオーバーライド、マージを経てからコアに渡されるのかを確認してください。画面上でインポートに成功しても、管理レイヤーがファイルを受け取ったことしかわかりません。起動ログに解析エラーがなければ、生成された設定が少なくとも基本的な読み込みを通過したと確認できます。最後に実際の接続を行い、選択した出力が認証とデータ転送を完了できるか確認してください。

アップグレード前に、動作する設定のコピーを保存し、システムプロキシ、TUN、DNS、待ち受けポートの状態を記録してください。クライアント、コア、サブスクリプションテンプレートを一度に置き換えると、問題の原因を特定しにくくなります。元の接続方式を維持したまま、まず1つのレイヤーだけ更新し、動作を確認してから新しい項目を追加するのが安全です。クライアントが起動時に設定を再生成する場合は、すぐに上書きされる実行用ファイルではなく、クライアントが用意するオーバーライドの設定箇所を編集してください。

GUIクライアントを選ぶ場合、当サイトではClash Plusを第一候補としておすすめしています。プラットフォームや操作習慣に応じて、ダウンロードページに掲載しているClash Verge RevやFlClashなども比較できます。おすすめの順番にかかわらず、機能の確認は欠かせません。アプリ名にClashが含まれているからといって、mihomoを使っているとは限りません。アーカイブ版のClash for WindowsやClashX Metaは以前の環境を理解する参考にはなりますが、新しいプロトコルへの対応状況を判断する基準には適しません。画面の違いはクライアント選びのガイドで確認し、機能の判断は必ず実際に動作しているコアを基準にしてください。

SSとVMess：シンプルなカプセル化と構造化された認証

Shadowsocksは一般にSSと略され、比較的シンプルな暗号化プロキシの仕組みとして発展してきました。クライアントが接続先を指定し、アプリのデータを所定の暗号化・転送処理に渡します。複雑な設定を組み立てるよりも、限られたプロトコル構造で確実に転送することを重視しています。VMessはV2Rayエコシステムで開発され、独自の認証とデータカプセル化の仕組みを備え、さまざまなトランスポートと組み合わせて使われます。どちらも広く実装されていますが、実績があるからといって設定値の一致確認を省けるわけではありません。

SS：略称より暗号方式と実装を確認する

SSノードでは、少なくともサーバーアドレス、ポート、パスワード、暗号方式が必要です。初期のストリーム暗号、後に広く使われるようになったAEAD方式、Shadowsocks 2022系は、互換性のある同一の設定として自由に使い回せるものではありません。AEADは暗号化に加えて完全性も保護します。方式ごとに鍵導出、パケット構造、実装要件が異なります。クライアントとサーバーの両方が対応する方式を使用してください。「接続できるか試す」ために暗号方式の名前を適当に変更してはいけません。

ハードウェアアクセラレーションに対応した端末では、一部のAES実装が効率的に動作することがあります。一方、別のプロセッサではChaCha20系のほうが適している場合もあります。OS、暗号ライブラリ、プロセッサの機能によって結果は変わるため、暗号方式の一覧をそのまま性能ランキングとして扱うことはできません。暗号方式に非対応というエラーが出た場合は、システムプロキシを変更する前に、コアの機能とサブスクリプションの内容を確認してください。システムプロキシはアプリをローカルプロキシに接続する仕組みであり、未実装の暗号方式を追加するものではありません。

SSではTCPとUDPを扱えますが、クライアントの設定、サーバーの実装、ネットワーク経路のすべてが、該当する転送を許可している必要があります。一部の拡張ではプラグインを使ってトランスポート層の機能を追加します。プラグイン名、オプション、サーバー側の設定も一致していなければなりません。SSリンクをインポートできても、インポートツールがプラグインの項目まで正しく保持しているとは限りません。通常のSSは使えるのにプラグインとの組み合わせで失敗する場合は、暗号化だけを疑うのではなく、変換処理とプラグインの対応範囲を確認してください。

VMess：認証、時刻、外側のトランスポート

VMessは通常、UUID形式のユーザー識別子を使い、従来の認証方式と比較的新しいAEAD認証方式があります。古いチュートリアルにある互換設定は、古い実装だけを対象としている場合があります。過去の設定を現在のノードにそのままコピーしたり、経験だけを頼りに認証関連の値を変更したりしないでください。端末の時刻が大きくずれていると認証判定に影響する場合があります。複数端末のうち1台だけ接続できないときは、自動時刻設定を確認してから、ユーザー識別子、トランスポート、TLS関連の設定を確認しましょう。

VMessでWebSocketなどの外側のトランスポートを使う場合、パス、リクエストのホスト名、TLSのサーバー名などの設定項目にはそれぞれ異なる役割があります。WebSocketのパスはサーバー側のルーティングに、HTTPのホスト名はアプリケーション層のリクエストに、TLSの名前は接続時の相手先確認に使われます。これらが常に同じとは限りません。サブスクリプション変換で項目の1つが欠落すると、ハンドシェイクに失敗したり、通常のWebサイトからの応答が返ったりすることがあります。この種の問題は、サーバーから提供された接続情報に照らして、各レイヤーを順に確認してください。

SSまたはVMessのサービスが安定して動作している場合は、プロトコル名を新しくするためだけに移行するのではなく、互換性を保ち、UDPの要件を確認し、変換時の情報欠落を防ぐことを優先しましょう。SSはシンプルなため、基本的な接続問題を切り分けやすい傾向があります。VMessは多様なトランスポートと組み合わせられる一方、より詳細な設定の記録が必要です。最終的な性能はどちらもサーバーの構成や回線に左右されます。同じアプリの操作で、起動直後、連続通信中、ネットワーク切り替え後の復旧をそれぞれ確認してから、変更するか判断してください。

TrojanとVLESS：TLSとレイヤー設計

TrojanとVLESSは、最新のTLS接続方式に対応するクライアントでよく見かけますが、名前だけを変えた同じプロトコルではありません。TrojanはTLS接続内の認証とプロキシ転送を中心に構成され、認証情報としてパスワードを使うことが一般的です。VLESSはV2Ray関連のエコシステムに由来し、軽量なプロトコル構造と外部レイヤーの組み合わせを重視し、通常はユーザー識別子としてUUIDを使用します。理解するには、「プロトコル自体の役割」と「外側の接続が担う役割」を分けて考えることが重要です。

Trojan：まずTLS、次に転送を確認する

一般的なTrojan接続では、まずTLSチャネルを確立し、その中で認証して接続先のトラフィックを転送します。そのため、証明書の検証、サーバー名、システム時刻が接続の成否に直結します。接続先のアドレスにはドメイン名だけでなくIPアドレスも指定できます。ただし、IPアドレスで接続するからといって、証明書もそのIPアドレスで検証する必要があるとは限りません。クライアントで期待するサーバー名を明示的に指定できる場合があります。その名前は実際のサーバー設定と一致させてください。正常に見えるWebサイトのドメイン名を適当に入力してはいけません。

クライアントでTLSハンドシェイクエラーが発生した場合は、まず証明書の有効期限切れ、名前の不一致、証明書チェーンの欠落、端末の時刻のずれ、ポート上でTLSサービスが動作していない状態を切り分けます。認証失敗は別のレイヤーで発生します。証明書の検証に成功していても、パスワードが一致しなければプロキシとしては使えません。すべての問題を「ノード障害」とまとめると、診断に役立つ情報を失います。ログにハンドシェイク段階の問題が示されている場合は、まずその段階を修正し、DNS、プロキシグループ、ルールの順序を同時に変更しないでください。

TrojanではUDP転送が可能な場合もありますが、UDPのカプセル化方式、サーバー側の有効化、クライアントの実装をそれぞれ確認する必要があります。外側が信頼性の高い接続だからといって、リアルタイムアプリの性能が必ず向上するわけではありません。下層のTCPでパケットロスが起きると、後続データが再送を待つことがあります。一般的なWeb閲覧や多くのアプリでは、カプセル化の層数より、既存環境との互換性や接続の安定性を優先するほうがよい場合が少なくありません。リアルタイム通信では、ジッターや復旧動作も確認してください。

VLESS：軽量なプロトコルでもセキュリティ設定は必要

VLESSの基本プロトコル自体は、従来型の独立したコンテンツ暗号化を提供しません。実際に使用する際は、TLSやREALITYなど、サーバー構成に合ったセキュリティ機構を利用してください。さまざまなトランスポートと組み合わせられますが、プロトコル名が示すのは認証と転送の枠組みの一部にすぎません。設定に従来型の暗号方式の項目がないからといって、接続全体が暗号化されていないとは限りません。同様に、VLESSという名前だけで外側の接続が適切に保護されているとも判断できません。組み合わせ全体を確認してください。

REALITYは特定の接続セキュリティ方式であり、自由に置き換えられる汎用TLSスイッチではありません。公開鍵、ショートID、サーバー名、関連する動作をサーバー設定と一致させる必要があります。Visionは特定のフロー制御の組み合わせに属し、適用可能なプロトコル、トランスポート、実装に条件があります。速度向上を期待して、任意のWebSocket接続にコピーしてはいけません。サブスクリプションにこれらの拡張が含まれている場合は、VLESSという文字列を認識できるかだけでなく、実際のクライアントコアと変換ツールの両方が対応しているかを確認してください。

証明書が適切に管理されているTrojanサービスは、引き続き安定した候補として利用できます。特定のVLESS構成が必要な場合は、まずサーバー情報が揃っていることを確認し、その構成に対応したコアを選んでください。どちらも、高度な設定項目を手当たり次第に切り替えて問題を解決する方法には向きません。エラーに関係する項目を一度に1つだけ変更し、元のサブスクリプションを保存したうえで、変更前後のログの段階を記録してください。そうすれば、プロトコルの選択が適切でないのか、インポートや変換で設定が欠落したのかを切り分けられます。

Hysteria2とTUIC：QUICのメリットと注意点

Hysteria2とTUICはいずれもQUICを使ってプロキシ接続を構成しますが、別々のプロトコルであり、サーバー側とクライアント側で互換性はありません。QUICは通常UDP上で動作し、暗号化ハンドシェイク、信頼性のあるストリーム、接続管理の機能を組み合わせます。QUICを通るすべてのアプリ通信が、信頼性のないUDPになるわけではありません。アプリのTCPデータは信頼性のあるストリームに割り当てられ、アプリのUDPデータはデータグラムなど、プロトコルが定める別の方法で運ばれる場合があります。具体的な動作は実装と設定によって異なります。

QUICを基盤にする理由

従来の多重化では、複数の論理ストリームが1つのTCP接続を共有すると、下層のパケットロスによって全ストリームが待たされる場合があります。QUICは信頼性のある転送状態をストリームごとに管理し、こうしたストリーム間のヘッドオブラインブロッキングの影響を抑えられます。また、接続IDなどの仕組みで経路の変化を管理できます。ただし、同じ接続内ではネットワーク容量や輻輳状態が共有され、パケットロス自体がなくなるわけではありません。サーバーの負荷、接続ネットワークのポリシー、実装品質によっては、プロトコル構造によるメリットが相殺されることもあります。

UDPで通信できることは、これらのプロトコルを使うための条件の1つです。DNSなど少量のUDPは許可されていても、ほかのポートや長時間のUDPセッションが制限されるネットワークがあります。NATマッピングの保持時間が短い機器では、バックグラウンドで待機した後に経路が失われやすくなります。接続がタイムアウトする場合は、TLS名を何度も変更するのではなく、サーバーの待ち受け、ファイアウォール、UDP転送、ポートのポリシーを確認してください。同じ端末が別のネットワークに切り替えると復旧するなら、それはネットワーク経路の手がかりであり、認証情報が突然正しくなったわけではありません。

Hysteria2：帯域幅の設定は速度を上げる魔法ではない

Hysteria2は、遅延が大きくパケットロスのある経路でのデータ転送を重視して設計されており、帯域幅の推定や輻輳制御に関する機能を備えています。クライアントのアップロード・ダウンロード帯域幅の設定は、送信動作やネゴシエーションに影響します。具体的な意味は、使用中の実装のドキュメントで確認してください。実際の接続能力を大幅に超える値を設定すると、キューの増加やパケットロスを招き、ほかのアプリにも影響することがあります。理論上の最大速度ではなく、安定して維持できる実効速度を基準に設定してください。

Hysteriaの初代とHysteria2は、名前を変えただけで互換性があるわけではありません。認証方式、設定項目、プロトコルの動作に違いがあるため、サブスクリプションツールが該当する種類に明確に対応している必要があります。サーバーで追加の難読化パラメーターが必要な場合は、クライアント側でも一致する方式と情報を指定してください。指定がない場合、根拠なく追加する必要はありません。ネットワークによってはパケットサイズに敏感なこともあります。連続通信が中断する場合は、輻輳制御の問題と決めつけず、ログとネットワークテストを踏まえて経路MTUも確認してください。

TUIC：接続管理とアプリの要件を合わせて考える

TUICもQUICを基盤にプロキシと転送の仕組みを構成し、一般的な設定にはユーザー識別子、パスワード、輻輳制御、UDP転送方式が含まれます。プロトコルの世代と実装の対応範囲を一致させる必要があります。種類がTUICと表示されていることだけを確認しても不十分です。接続の再利用でチャネル確立の負荷を抑えられる一方、複数のアプリが同じ接続状態に集約されます。サーバーの再起動や経路障害が起きると、複数のアプリに同時に影響することがあります。接続開始時だけでなく、長時間使用した場合の動作も確認してください。

QUICには経路移行に関する仕組みがありますが、Wi-Fiとモバイルデータの切り替え後も、すべてのクライアントで既存のセッションが維持されるとは限りません。OSのネットワーク権限、仮想ネットワークインターフェースの動作、クライアントの処理、サーバー設定がそれぞれ関係します。「モバイルネットワークに強い」を「ネットワークを切り替えても切断しない」と解釈しないでください。アプリが速やかに復旧するか、再接続を繰り返すか、バックグラウンドから復帰した後に無効な接続状態を使い続けないかを確認しましょう。

Hysteria2とTUICを候補に加える理由は、現在の経路や用途で、それぞれのトランスポート機構が役立つ可能性があるからです。「新しいプロトコルなら必ず速い」からではありません。同じネットワークで、短時間のWeb閲覧、連続ダウンロード、リアルタイムアプリ、待機後の復旧をそれぞれ確認してください。ダウンロード性能が上がっても、スマートフォンのバックグラウンド再接続が増えるなら、主な用途に合わせて判断しましょう。状況から切り離した速度の結論より、テスト条件の記録のほうが役立ちます。

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

プロトコルの性能は、少なくとも接続確立、最初の応答、持続的なスループット、障害からの復旧という4つの観点から評価できます。クライアントの接続テストで測定するのは、通常その一部だけです。特定の宛先にリクエストを送り、所要時間を測る方法では、DNSキャッシュ、接続の再利用、テスト先、サーバーの応答が結果を左右するため、動画、会議、ダウンロードの性能を直接示すものではありません。比較する前にテストの内容を確認し、実際の用途と関係があるかを見極めてください。

ハンドシェイクと連続通信を分けて考える

新しい接続では、ドメイン名の解決、下層の接続確立、TLSまたはQUICのハンドシェイク、プロトコル認証、接続先との通信開始が必要になる場合があります。既存の接続を再利用すると、その一部を省略できます。そのため、テストを連続で実行して良い結果が出ても、アプリの初回起動時に同じ性能が得られるとは限りません。TLSセッション再開やQUICの早期データ機能にも利用条件とセキュリティ上の制限があります。接続確立を短縮するために、すべてのオプションをむやみに有効にしないでください。まず信頼できるデフォルト設定を維持し、明確なボトルネックが見つかった場合に調整しましょう。

持続的なスループットは、輻輳制御、受信ウィンドウ、経路の容量、通信する両端の処理能力によって決まります。暗号化はCPUを消費しますが、速度低下の原因が常に暗号化とは限りません。端末のCPU負荷が低いのにアプリの待ち時間が長い場合は、リモート側の帯域、キューの増加、接続先サイトの応答が原因かもしれません。一方、低消費電力のルーターでCPUが高負荷になっている場合は、アルゴリズムの実装や同時接続数が制限要因になることがあります。リソースを確認する際は、画面を表示するプロセスだけでなく、実際に通信を処理するコアを含め、クライアント関連のプロセス全体を確認してください。

消費電力は無線通信とバックグラウンド動作で増えることが多い

スマートフォンの消費電力は、暗号処理だけで決まるわけではありません。無線モジュールの稼働維持、頻繁なハートビート、接続確認、DNSリクエスト、再試行、バックグラウンドでのログ書き込みも電力を消費します。TUNやシステムVPNで多くのアプリの通信を引き受けると、通信量や消費電力がクライアント名義で集計されることがありますが、クライアントがすべての通信を自ら生成したという意味ではありません。バッテリー統計、フォアグラウンドとバックグラウンドでの動作、アプリの実際の利用状況を合わせて確認し、電池使用量の順位だけでプロトコルの良し悪しを判断しないでください。

ハートビートの間隔を短くすると接続障害を早く検出できますが、端末が起動する回数も増える可能性があります。間隔を長くするとバックグラウンドの動作は減る一方、復旧までの時間が延びることがあります。適切な値はNAT、サーバー、OSのバックグラウンド管理に左右されるため、ネットワークを問わず同じ値を使い回さないでください。プロキシグループの自動ヘルスチェック、サブスクリプションの更新、ルールデータベースの更新もネットワーク通信を発生させます。待機時の電池持ちを改善したい場合は、複数のクライアントがシステムプロキシや仮想ネットワークインターフェースを奪い合わないようにし、まず実用性のない高頻度タスクを減らしてください。

一度のランキング測定ではなく、再現可能な条件で比較する

端末、ネットワーク、接続先サイト、アプリの操作を固定し、ダウンロードしながら応答速度を比較しないでください。まず起動直後の動作を個別に確認し、次に連続使用し、最後に待機後とネットワーク切り替え後の復旧をテストします。各回で変更する項目は1つだけにしてください。サーバーの地域、プロトコル、クライアントを同時に変更すると、差の原因をプロトコルに絞れません。時間帯を変えて繰り返し確認し、問題が毎回起きるかどうかを記録します。サーバーや回線の条件を揃えられない場合は、2つの接続を比較した結果として記録し、2種類のプロトコルに共通する結論として扱わないでください。

クライアントのテスト機能の使い方を確認する場合は、まず使い方ガイドを参照し、ログから実際に選択された出力を確認してください。プロトコルごとに決まったメモリー使用量、消費電力、速度の数値を当てはめないでください。実装、ハードウェア、通信負荷によって結果は変わります。選択に役立つのは、現在の端末でどの組み合わせなら安定して作業できるか、どの操作で問題が起きるか、その性能を得るためにどの程度リソースを使うかという記録です。

サブスクリプション形式：インポートできても動作するとは限らない

サブスクリプションは固定のファイル形式ではなく、設定を配布・更新する方法です。同じURLでも、完全なClash YAML、プロキシプロバイダー用データ、エンコードされた共有リンクの一覧、別のエコシステムで使われるJSONなど、さまざまな形式が返される場合があります。拡張子やURLの見た目だけでは、返される形式を判断できません。サーバーがリクエストに応じて内容を変えることもあります。インポートする前に、提供元が案内する対象クライアントと形式を確認し、それに合った方法を選んでください。

完全な設定・ノード一覧・共有リンク

完全なClash YAMLには、通常、待ち受け、DNS、プロキシ、プロキシグループ、ルールなどが含まれます。一方、プロキシプロバイダー用のファイルはノード一覧だけを提供することが多く、メイン設定からプロバイダーとして参照して使います。同じYAML形式でも、後者を完全な設定としてそのまま実行できるわけではありません。共有リンクには1つの接続に必要な設定が記録され、Base64形式の一覧には複数のリンクがまとめられている場合があります。Base64はデータの表現方法であり、暗号化でも、任意のプロトコルをClash設定に変換するツールでもありません。

インポートに失敗した場合は、まずどの段階で問題が起きているかを判断してください。URLの取得失敗、想定外の形式での応答、ファイル構造の解析エラー、コアが対応していない特定ノードのいずれかを切り分けます。URLの応答がログイン画面やエラーページ、空の内容であれば、YAMLのインデントを調整しても解決しません。YAMLを読み込めても未知のプロキシ種類というエラーが出る場合は、コアの対応状況を確認してください。設定は動作するのに特定の接続だけ失敗するなら、その接続の認証、トランスポート、サーバーの状態を確認します。サブスクリプション全体を最初からやり直す必要はありません。

変換ツールは認識できる項目しか保持しないことがある

変換ツールは、元の形式にある項目を変換先の形式へ対応づけます。新しいプロトコル拡張、プラグインのオプション、REALITYの設定、フロー制御、UDPの転送方式、特定のTLS設定などは、古いツールでは対応する項目がない場合があります。出力ファイルの構文が正しくても、設定の意味まで完全に保たれているとは限りません。元のクライアントでは使えるのに変換後は動かない場合は、ノード名やサーバーアドレスだけでなく、接続に関わる重要な項目を照らし合わせてください。名前が同じでも、ラベルが残っていることしかわかりません。

サブスクリプションURLにはアクセス権限が含まれている場合が多く、第三者の変換サービスに渡すことは、設定を取得する権限を相手に与えることに等しいと考えてください。提供元が明確に対応を案内している形式や、ローカルでの変換を優先し、実際のサブスクリプションURLを公開の質問欄、スクリーンショット、ログに貼り付けないでください。サポートを依頼する際は、完全なURL、ユーザー識別子、パスワードなどの認証情報を削除したうえで、エラーの種類、項目名、機密情報を含まない設定の構造を残してください。アクセス権限を守りながら、原因の特定に必要な情報を共有できます。

更新とオーバーライドの役割を分ける

リモートサブスクリプションを更新すると、手動で変更したノード、ルール、プロキシグループが置き換わることがあります。長期的に維持したい設定は、クライアントが対応するオーバーライド、マージ、独立したメイン設定の仕組みに保存してください。具体的な設定箇所はクライアントの説明を確認しましょう。マージ時に一覧が置き換えられるのか、項目が追加されるのかを理解してください。特にルールの順序とプロキシグループの参照に注意が必要です。ルールを追加してもMATCHより後に置かれると、ファイル上に表示されていても一致する機会がありません。構文の詳細はカスタムルールと照合順序の解説を参照してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

上記のYAMLは単独で動作する基本的な例で、リモートプロキシは含まず、サブスクリプションのノードにも通信を送りません。「コアが起動できない」問題と「リモート接続を確立できない」問題を切り分けるのに役立ちますが、ローカルポートが使用中でないことも確認する必要があります。例が起動しても、基本設定と待ち受けが動作したことしかわかりません。サブスクリプション形式、プロキシ認証、リモートサービスの利用可能性を証明するものではありません。形式の違いとインポート手順については、サブスクリプションURLのインポートと形式の解説も参照してください。

用途別に選ぶ：候補の比較から検証手順まで

最終的な選択は、恒久的なランキングではなく、複数の条件を組み合わせて判断します。現在のクライアントとコアが何に対応し、サーバーが何を提供し、ネットワークで何が許可され、主に使うアプリが何を必要としているかを確認してください。まず非対応の組み合わせを除外し、利用できる候補を比較するほうが、高度な設定を何度も変えるより効率的です。一般ユーザーにとっては、安定してインポートでき、正しく動作を確認でき、問題から復旧しやすい構成が、理論上複雑な構成より適していることも少なくありません。

デスクトップでの作業と一般的なWeb閲覧

デスクトップでWeb閲覧、文書作成、コードリポジトリの利用が中心なら、まず動作が安定していると確認済みのSS、VMess、Trojan、または対応済みのVLESS構成を使い、初回の応答、長時間接続、スリープ復帰後の動作を確認しましょう。これらが特定の性能ランクを保証するわけではなく、一般的に利用できる候補ということです。ネットワークでUDPが制限されている場合は、TCPを使う経路を優先して残してください。ダウンロード量が多い場合もピーク速度だけで判断せず、ダウンロード中にほかのアプリの動作が明らかに遅くならないかを確認し、キューの問題を接続先サーバーの異常と混同しないようにしてください。

新規にインストールする場合は、当サイトで第一候補としておすすめしているClash Plusから始め、プラットフォームや管理方法に応じてほかのクライアントも確認してください。クライアントを変更する前に、必要なローカル設定を書き出し、サブスクリプションを安全に保管します。すべてのアプリでTUN、DNS、設定のマージ方法が同じだと思い込まないでください。現在の設定が動作している場合は、移行時に出力プロトコルとルールを変えず、クライアントとの連携による違いだけを確認しましょう。インストール先はダウンロードページ、初回のシステムプロキシとポートの確認は初期設定チェックリストを参照してください。

モバイルでの作業、リアルタイムアプリ、不安定なネットワーク

スマートフォンで接続ネットワークを切り替える場合は、バックグラウンドからの復帰、消費電力、権限の安定性も確認してください。Hysteria2とTUICはUDPが使えるネットワークで候補になりますが、ネットワーク切り替え後と待機後の動作を実際に検証し、TCP方式も利用できる代替手段として残しましょう。リアルタイムアプリでは、通信が本当にプロキシを経由しているかも確認してください。システムプロキシはすべてのUDPアプリに適用されるとは限りません。TUNは通信を引き受けるための仕組みにすぎず、OSの権限、ルーティング、DNS処理の影響を受けるため、プロトコル認証を自動的に修正するものではありません。

ルーターやサーバーで使う場合は、アーキテクチャ、利用可能なメモリー、サービス管理、ネットワークスタックの制約を先に確認してください。デスクトップ用インストーラーを流用するのではなく、ダウンロードページのmihomoコアの項目を利用します。多数の接続確認、高詳細度のログ、複雑なルール照合を同時に有効にした状態で生じたリソース負荷を、プロトコル性能の問題と判断しないようにしてください。家庭内LANで使う場合は、待ち受け範囲とアクセス制御も明確にします。1台の端末を接続するためだけに、すべてのインターフェースを公開する設定は、別途慎重に検討すべきです。

プロトコルを手当たり次第に変えず、障害の段階ごとに切り分ける

まず起動を確認します。解析エラーがある場合は、インデント、設定項目、コアの対応状況を確認してください。次に通信の引き受けを確認します。アプリがシステムプロキシまたはTUNを使っているか、ルールが想定したプロキシグループに一致しているかを確認しましょう。続いて接続を調べ、名前解決、ポートへの到達性、TLS、認証、接続先への転送を切り分けます。最後に継続動作を確認し、待機、ネットワーク切り替え、同時通信、ダウンロードのどれが切断のきっかけになるかを観察してください。各段階で動作確認済みの比較用経路を1つ残しておけば、変更によって実際に改善したか判断できます。

mihomo -t -f config.yaml

このコマンドは、mihomoをインストール済みで、ターミナルから実行できる環境で使えます。ファイル名はローカルにある設定ファイルに合わせてください。構文チェックに合格しても、リモート接続が利用できるとは限りません。GUIクライアントが別の実行用設定を生成する場合や、内蔵メニューからのチェックを必要とする場合もあります。チェック対象が実際に使われるファイルと同じか、先に確認してください。GeoIPやGeoSiteのデータ読み込みに問題がある場合は、データベース更新とルールの利用方法を参照してください。ドメイン名の割り当てに関する問題は、Fake-IPモードの解説を確認しましょう。

プロトコルの選択に、環境を問わず当てはまる正解はありません。しかし、問題を調べる手順は安定させられます。まず機能の対応状況を確認し、次に設定項目を照合し、最後に実際の用途で動作を検証します。問題が起きたら、直近で動作していた設定に戻してください。この手順に慣れておけば、サーバー、クライアント、ネットワークのいずれを変更しても、プロトコル名から当てずっぽうに試すのではなく、どの接続部分を確認すべきか判断できます。