Clashのプロトコルと
mihomoカーネルの選び方

カーネルとの関係：画面と実行層を分けて考える

クライアント名だけでは対応プロトコルは分からない

まずクライアントのカーネル情報を確認し、設定を利用できるか判断します。GUIクライアントはサブスクリプションの登録、プロキシグループの選択、システムプロキシの切り替え、ログ表示などを担当します。プロキシカーネルは設定の解析、ルールの照合、接続の確立、名前解決を処理します。同じような画面でも配布パッケージによって組み込まれたカーネルが異なる場合があり、同じカーネルを複数の画面から利用することもできます。そのため、クライアント名にClashが含まれていても、Clashエコシステムの設定すべてに対応しているとは限りません。

オリジナルのClashは、一般的な設定構成の基礎を築きました。ノードをプロキシ一覧に登録し、プロキシグループで整理し、ルールで接続先の出口を決め、DNS設定で接続先の情報を解決します。オープンソース版のカーネルと、追加機能を提供していたPremiumブランチも区別が必要です。具体的なブランチやビルド範囲を示さず「オリジナル版に対応」とだけ記されたオンライン記事は、移行の判断材料として不十分です。実際に動作しているカーネルの説明と設定チェックの結果を基準にしましょう。

Metaからmihomoへの継承

Clash.Metaは、Clashエコシステムでプロトコルや機能を拡張したカーネルのブランチです。その後、プロジェクトはmihomoの名称で開発が続いています。古い資料にあるMetaの設定と現在のmihomoのドキュメントには明確なつながりがありますが、名称が似ていても、すべての時期の設定項目が同一とは限りません。新しいプロトコルや転送パラメーター、DNS関連の設定は順次追加されるため、古いクライアントに同梱されたカーネルでは認識できないことがあります。移行時は、設定が想定するカーネルと端末側のカーネルが対応しているか、両方を確認してください。

互換性は3つの層に分けて確認します。1つ目は構文の解析可否です。インデント、項目の型、ノードの種類などが正しいかを見ます。2つ目は機能の実装状況です。指定された転送方式、セキュリティ機能、仮想ネットワークアダプターの設定に対応しているかを確認します。3つ目は実行環境です。システム権限、ルーティング設定、ポートが利用可能かを調べます。設定を読み込めても、確認できたのは一部の条件だけです。すべてのノードでサーバー認証が完了したことや、すべてのアプリの通信がクライアントを経由していることまでは保証されません。

クライアントを乗り換えるときに引き継ぐ情報

クライアントを変更する前に、現在の設定の入手元、有効な設定名、プロキシグループの選択状況、必要な上書き設定を保存してください。設定を引き継げると思い込んでプログラムのフォルダー全体をコピーするのは避けましょう。画面のデータベース、サブスクリプションのキャッシュ、カーネル設定は別々に保存されている場合があります。新しいクライアントに設定をインポートしたら、ノード数が想定どおりか、プロキシグループの参照先がそろっているか、ルールが正常に読み込まれたかを確認します。古い設定で絶対パスを使っている場合は、ルールファイルや証明書の場所も指定し直してください。

OSに合ったインストーラーを選ぶには、まずClashダウンロードページでおすすめのClash Plusを確認し、同じOSに対応する他のクライアントと比較しましょう。選ぶ基準は画面のスクリーンショットではなく、OSの要件、実際のカーネル対応状況、メンテナンス状況です。古い手順を参考にする場合は設定の考え方だけを活用し、項目名を改めて確認してください。古いサンプルをそのまま使うために、開発が終了したクライアントへ戻すのは避けましょう。画面操作の違いを比較したい場合は、GUIクライアントの選び方もご覧ください。

SS：シンプルな構成と暗号化方式

Shadowsocksの設計の基本

ShadowsocksはSSとも呼ばれ、比較的シンプルな暗号化プロキシ経路を提供することを重視したプロトコルです。クライアントはアプリから接続を受け取り、宛先アドレスとデータをプロトコル形式でサーバーへ送信し、サーバーが宛先にアクセスします。完全なVPNではなく、ノードのプロトコル名だけで端末上のすべてのアプリの通信を自動的に経由させるものでもありません。アプリの通信をカーネルに通す方法は、システムプロキシ、アプリごとの設定、TUNなどによって異なります。通信の入口とノードのプロトコルを混同しないようにしましょう。

SSの設定では、通常、サーバーアドレス、ポート、暗号化方式、パスワードを指定します。項目が比較的分かりやすいため、既存のサービスを日常的に利用する際によく使われます。ここでいう「軽量」は、プロトコルの構造や導入の複雑さを指し、あらゆる端末で高性能であることを保証するものではありません。実際の使い心地は、サーバーの負荷、回線の品質、暗号化の実装、端末のプロセッサーにも左右されます。同じノードでもネットワークが違えば、プロトコル間の差より大きな違いが出ることがあります。

まず方式を確認し、次に認証情報を確認

暗号化方式はプロトコル互換性を左右する重要な設定です。好みで選ぶ項目ではありません。従来のストリーム暗号、新しい認証付き暗号、Shadowsocks 2022系では形式が異なり、クライアントはサーバー指定の方式に対応している必要があります。パスワードが正しいからといって、より一般的に見える別の方式へ変更しないでください。認証付き暗号では、メッセージが改ざんされていないかも検証します。方式や鍵が一致しないと、認証失敗、即時切断、タイムアウトが続くなどの症状が現れ、「パスワードが違います」と明確に表示されない場合があります。

方式によって鍵の要件も異なります。通常のパスワードを使う設定もあれば、指定の形式と長さで鍵を入力する方式もあります。サブスクリプションに生成済みの値がある場合は、そのまま使用してください。エンコードされた文字列を自分でデコードして入力したり、末尾の文字を削除したりしないでください。手入力では全角記号、コピー時に入った空白や改行にも注意が必要です。ログを他の人に見せて調査を依頼する場合は、暗号化方式とエラーの種類だけを残し、パスワードやサーバーアドレスなどの機密情報は隠してください。

プラグインとUDPは別々に確認

一部のSSノードでは、追加の転送機能を提供するプラグインを使います。設定にプラグイン名を入力するだけで必ず動くわけではありません。カーネルが該当する実装に対応している必要があり、クライアントによって利用できるパラメーターも異なります。元のサービスでプラグインが必要なのに設定を削除すると転送形式が変わるため、正しい簡略化にはなりません。反対に、サーバー側でプラグインが有効でないのにクライアントで追加しても接続できません。インポート後にノードが消えた場合は、変換時にプラグインの種類やオプションが失われていないか確認しましょう。

UDPを利用できるかどうかは、クライアント、ノード設定、サーバー、ネットワーク経路のすべてが対応しているかで決まります。Web閲覧ではまずTCP接続の状態が分かりますが、それだけで音声通話、ゲームなどUDPを使うアプリも動作すると判断することはできません。アプリによっては独自に名前解決を行ったり、直接接続したりして、現在の通信経路を通らないこともあります。テストでは、まずアプリの通信がカーネルに届いていることを確認し、次に想定したノードが選ばれているかを見ます。SSのパスワードを何度も変えるだけでなく、サーバーのUDP転送設定や端末のファイアウォールも確認してください。

安定して使えるSSサービスがすでにあるなら、新しいプロトコルが登場したという理由だけで、日常のWeb閲覧や一般的なアプリのために移行する必要はありません。まずノードのメンテナンス状況、ネットワーク品質、現在のカーネルの対応範囲を確認しましょう。プロセッサー使用率を比較する場合は、同じ端末と似た回線、同じタスクで計測してください。ハードウェアアクセラレーション対応のPCで特定の暗号化方式が良好でも、別のスマートフォンで電池消費が少ないとは限りません。プロトコルは接続全体を構成する要素の一つであり、速度を表す独立したラベルではありません。

VMessとVLESS：認証・転送・セキュリティ層

VMessが解決する課題

VMessは、ユーザー認証、データ保護、プロキシリクエストの表現を含むプロトコルとして、そのエコシステムで設計されました。一般的な設定にはユーザーID、暗号化オプション、下位の転送方式に関する項目があります。歴史の中で実装が変化してきたため、古い設定にある項目が現在のサービスでも使えるとは限りません。特に古い資料に記載された追加IDを、経験だけを頼りにすべてのノードへコピーしないでください。古い手順を固定のレシピとして扱わず、クライアントとサーバーで同じ方式を使うようにしましょう。

VMessの接続トラブルでは、システム時刻を早めに確認しましょう。認証には時刻に関わる仕組みが使われるため、端末の時刻が大きくずれていると認証に失敗することがあります。ネットワークモードをむやみに切り替える前に、自動時刻設定を有効にし、ユーザーIDとサーバー側の設定を確認してください。ユーザーIDはノードの表示名ではありません。画面上のメモを変更しても認証情報は変わりません。サブスクリプション更新後にサービス提供元が認証情報を変更した場合は、ノード名だけを編集するのではなく、有効な設定を再読み込みしてください。

VLESSで簡略化された役割

VLESSは、プロトコル自体の認証や転送の構造をシンプルにし、データの機密性を外部のセキュリティ層に委ねる設計です。VMessの別の暗号化方式ではなく、ノードの種類だけを変更して入れ替えられる形式でもありません。一般的な構成ではTLSやREALITYなどを組み合わせます。クライアントはサーバーが実際に使用する組み合わせに対応している必要があります。名称に「軽量」の意味があるからといって、セキュリティ層を無効にしても同じデータ保護が得られると考えないでください。

REALITY、TLS、転送方式、flowはそれぞれ別の設定項目です。ある組み合わせで接続できたとしても、別の記事に書かれた値に任意の項目を差し替えられるわけではありません。サーバーが要求する公開鍵、short ID、サーバー名、フロー制御の設定は、元の情報に従って入力してください。不明な場合は設定の提供元に確認しましょう。特に、Webサイトの証明書に含まれる公開鍵と、サーバーが指定したREALITYの公開鍵を混同しないでください。入手元と役割は異なり、誤った値を入力するとセキュリティハンドシェイクで失敗することがあります。

ノード設定を3つの層に分けて読む

この種の設定は「プロキシプロトコル—転送方式—セキュリティ機能」の3層に分けると理解しやすくなります。プロキシプロトコルは認証とリクエストの形式を決めます。転送方式は、通常の接続、WebSocketなど、対応する方式のどれでデータを運ぶかを決めます。セキュリティ機能は証明書の検証と暗号化ハンドシェイクを担います。3層の組み合わせはサーバーの実際の構成によって決まります。サブスクリプション変換でノードの種類とユーザーIDだけが残り、パス、サービス名、サーバー名が欠落していると、画面上はインポートに成功していても接続できないことがあります。

WebSocketリクエストのHostと、TLSハンドシェイクで使うサーバー名も区別しましょう。両者は同じ場合もあれば、サーバー側のリバースプロキシ構成によって異なる場合もあります。ドメインが2つ表示されていても、勝手に統合しないでください。パスも通常はそのまま保持する必要があります。大文字・小文字、先頭のスラッシュ、クエリ部分がサーバー側のルーティングに影響する場合があります。アドレスへ直接接続し、証明書がドメイン名に対して発行されている場合は、サーバー名の設定が特に重要です。長期利用を前提に証明書検証を省略してよいという意味ではありません。

プロトコルを選ぶときは、まず設定の提供元がどのような組み合わせを指定しているか確認し、次に端末のカーネルで実現できるかを見ます。既存のVMessノードが安定しているなら、VLESSの項目数が少ないという理由だけで移行する必要はありません。新しい設定を作る場合も、名称だけで速度を判断しないでください。初回接続の時間は転送方式とセキュリティハンドシェイクの両方に左右され、接続の再利用、サーバーの実装、ネットワークの往復時間によって結果が変わります。プロトコル名を切り替え続けるのではなく、ログで失敗した段階から調べましょう。

Trojan：TLSを軸に接続を確認

TLS経由のプロキシリクエストを理解する

TrojanはTLS接続の中でプロキシリクエストをやり取りし、パスワード認証と比較的シンプルなリクエスト形式で転送する設計です。外側のセキュリティ通信路と、内側のプロキシ認証を分けて考えましょう。まず外側で接続先サーバーの本人確認を行い、暗号化通信を確立します。次に内側でプロキシの認証情報と宛先リクエストを検証します。パスワードが正しくても証明書が一致しなければ、認証前に接続が失敗することがあります。証明書の検証に成功しても、プロキシのパスワード、転送権限、宛先へのアクセスが正常とは限りません。

一般的な設定項目は、サーバー、ポート、パスワード、サーバー名です。構成によっては転送方式の設定もありますが、Trojanという名称だけで、すべての実装が同じ拡張機能に対応しているとは限りません。サーバーが指定した形式を使いましょう。ノードを手動で追加する場合は、まず基本項目を入力して接続を確認し、本当に必要な追加設定を加えてください。異なるノードの例から設定を継ぎはぎして、サーバーに存在しない組み合わせを作らないようにしましょう。

サーバーアドレスと証明書名は別の項目

サーバーアドレスは接続先を決め、TLSのサーバー名はハンドシェイクと証明書名の照合に使われます。サーバーアドレスにドメイン名を使う場合は、両者が同じことが多い一方、固定のIPアドレスで接続しても証明書に対応する名前を別途指定する場合があります。サーバー名にアドレスを入力しても、証明書が自動的に一致するわけではありません。証明書名のエラーが出たら、サービス提供元が指定する名前と証明書の対象範囲を確認してください。検証を無効にして問題を解決済みとみなすのは避けましょう。

証明書の確認では、有効期間、信頼チェーン、端末の時刻も重要です。スマートフォンの日付が誤っていると、有効な証明書でもまだ有効でない、または期限切れと表示されることがあります。サーバーが中間証明書を送信していない場合は、端末によって結果が異なることもあります。PCでは接続できてスマートフォンで失敗しても、スマートフォンのカーネルがTrojanに対応していないとは限りません。まず両方の時刻、システムの信頼ストア、エラーログを比較しましょう。サービス元がプライベート証明書を使っている場合は、対応する方法で信頼済み証明書やサポート対象の証明書ピンニングを設定し、検証の恒常的な省略は避けてください。

ハンドシェイクの段階から原因を絞る

ログに接続タイムアウトが出た場合は、まずアドレスの名前解決、ポートへの到達性、サービスの状態を確認します。TLSハンドシェイクや証明書のエラーが出たら、セキュリティ層を調べます。ハンドシェイク後すぐに切断される場合は、パスワード、プロトコル形式、サーバー側の権限を確認しましょう。エラーの種類だけで原因が確定するわけではありません。途中のネットワーク機器が切断している可能性もありますが、複数の設定を一度に変更するより、段階ごとに範囲を絞る方が確実です。毎回一つだけ変更し、変更前後のログの時刻を記録してください。

Trojanでは通常、アプリのデータはTLSを通りますが、接続先WebサイトのHTTPSは別の層です。プロキシ経路の証明書はプロキシサーバーが提示し、Webサイトの証明書は接続先サイトが提示します。ブラウザーにWebサイトの証明書エラーが表示された場合は、接続先へのアクセス自体に問題がないか確認してください。クライアントのログにプロキシ証明書のエラーがある場合は、ノードのセキュリティ設定を見直します。2つの層を分けて考えることで、ブラウザー設定を誤って変更したり、関係のない調査担当者にノードのパスワードを送ったりするのを防げます。

速度について、TLSだから必ず遅くなるわけでも、必ず速くなるわけでもありません。初回接続はネットワークの往復時間、証明書の処理、転送設定に影響されます。通信を続ける際は、帯域幅、輻輳、サーバーのリソースがより大きく影響します。TLSを適切に運用すれば、成熟した証明書管理や運用手順を活用しやすくなりますが、証明書の更新も必要です。選ぶ際はプロトコル名の長さではなく、サービスが継続的に保守されているか、設定がそろっているか、端末で証明書を正しく検証できるかを確認しましょう。

信頼できるTrojanの設定があるなら、日常利用の候補として、Web閲覧、長時間接続、必要なUDPアプリを実際に試してください。テストボタンの結果だけで、すべての用途で利用できると判断しないようにしましょう。テストボタンの接続先や方法は、アプリの実際の通信と異なります。Webページを開けても、バックグラウンド通知、音声通話、すべての名前解決経路が正常とは限りません。

Hysteria2とTUIC：QUICの特性と選び方

まずUDP経路が利用できるか確認

Hysteria2とTUICはいずれもQUICを重要な基盤として使いますが、別々のプロトコルです。認証、データの形式、設定項目は互換ではありません。QUICは通常UDP上で動作し、セキュリティハンドシェイク、ストリーム管理、輻輳制御などを組み合わせます。複数のデータストリームを一つの接続上で扱い、特定のトランスポート層のブロッキング問題を軽減できる場合があります。しかし、ネットワークでUDPが制限されていたり、ポートマッピングが不安定だったり、パケットロスが続いたりする場合、プロトコルだけで利用できない経路を作り出すことはできません。

QUICのマルチストリーム機能があっても、ネットワークのパケットロスの影響がなくなるわけではありません。各ストリームのデータはプロトコルに従って再送などの回復処理が必要です。複数のストリームも限られた帯域幅や輻輳状態を共有します。無線信号が弱い、サーバーの出口が混雑している、経路の容量が足りないといった状況では、実効速度は低下します。現在のネットワークでUDPが到達可能か、長時間安定するか、利用するアプリに利点があるかを確認しましょう。説明にある「多重化」だけを根拠に、すべての用途で速くなると判断しないでください。

Hysteria2の帯域幅と認証設定

Hysteria2はQUICベースのプロキシ転送向けです。認証、TLSのサーバー名、サーバーで使われている追加機能を確認する必要があります。表示名を変えるだけで初代Hysteriaと互換になるわけではありません。構成によっては帯域幅に関する設定で送信動作を調整したり、条件に応じて輻輳制御方式を選択したりします。クライアントに入力する帯域幅は速度測定の結果ではなく、値を大きくしても回線の物理的な帯域が増えるわけではありません。現在の実装とサーバー側の制約を踏まえて設定してください。

帯域幅の推定値に依存する送信方式を使う場合は、実際の回線に合った値を設定してください。高く見積もりすぎると、他の通信を圧迫してパケットロスが増えることがあり、低すぎると利用可能なスループットが制限されます。回線契約の公称値を、現在のWi-Fiで継続的に利用できる速度と同一視しないでください。MbpsとMB/sの取り違えにも注意が必要です。サーバーで難読化やポート関連のオプションが有効なら、クライアント側も一致させます。情報が足りない場合は、元の設定の提供元に確認してください。

TUICの転送設定とモバイルネットワーク

TUICもQUICを使ってプロキシ接続を構成します。一般的な設定には、ユーザーID、パスワード、輻輳制御、UDP転送に関する項目が含まれます。プロトコルのバージョンによって違いがあるため、古いクライアントがあるTUIC実装に対応していても、現在のすべてのサービスに接続できるとは限りません。インポートに失敗したら、まずカーネルが対応するバージョンと設定項目を確認し、ユーザーIDを何度も書き換えるのは避けましょう。サーバーが指定するアプリケーション層のプロトコルネゴシエーション設定も保持してください。他のノードの設定をそのままコピーしてはいけません。

設定によっては、0-RTTなどの早期データや高速再接続に関するオプションがあります。これらは既存のセッション状態と双方の実装に依存します。新しい接続のたびに同じ処理を省けるわけではなく、リプレイ攻撃のリスクなど安全面の制約もあります。通常は信頼できる設定の初期値を保ち、テストボタンの一度きりの結果を求めて安易に有効化しないでください。スマートフォンがWi-Fiとモバイルデータを切り替えると、アドレス、ポートマッピング、システムのネットワーク状態が変わります。接続が正常に復旧するかは実際に確認する必要があり、QUICという名称だけから判断することはできません。

この種のノードを使う場合は、動作を確認済みの別の転送方式も比較用に残しておくとよいでしょう。同じネットワークでTCP系ノードは正常なのにQUIC系だけ失敗し続けるなら、グローバルDNSをすぐ変更するのではなく、UDP経路とサーバーの待ち受け状態を確認します。大容量通信だけに問題がある場合は、経路のMTU、パケットロス、送信設定、端末のリソースを調べてください。再現可能な条件で確認できた違いだけを選択の判断材料にしましょう。一度だけ速かった、遅かったという結果では、プロトコルの優劣は証明できません。

速度と電池消費：タスクごとにリソース負荷を確認

「速さ」を段階ごとに分けて考える

まず改善したいのが、ページの初回表示、連続ダウンロード、ネットワーク切り替え後の復旧のどれかを決めます。アプリのリクエストは、名前解決、接続確立、セキュリティハンドシェイク、プロキシ認証、宛先からの応答など複数の段階を経ます。速度測定ボタンがその一部しか測らず、以前の接続状態を再利用する場合もあります。最初のリクエストが速くても、継続通信のスループットが高いとは限りません。ダウンロードが速くても、対話型アプリの応答待ちが短いとは限りません。実際のタスクに沿って比較しましょう。

SS、VMess、Trojan、VLESS、Hysteria2、TUICを速度順に並べる、信頼できる一般的な順位はありません。サーバーやネットワーク経路が異なる2つの回線を比べた結果は、主に回線の違いを示すものであり、プロトコルの違いを示すものではありません。同じサーバーでも、待ち受けポート、転送方式、輻輳制御、サーバー負荷によって結果が変わります。プロトコル間の違いを評価するには、ハードウェア、ネットワーク、サーバーのリソース、接続先をできるだけ固定し、比較対象の一項目だけを変えてください。

CPU、メモリ、接続数を合わせて確認

CPU負荷には、暗号化、データのコピー、プロトコル解析、輻輳制御、通信の振り分けなど複数の処理が関わります。特定の暗号方式がハードウェアアクセラレーションに対応しているかどうかで、方式同士の相対的な性能も変わります。メモリ使用量は接続数、バッファー、ルールの数、DNSキャッシュにも左右されます。クライアント全体のメモリ使用量を、特定のノードプロトコルだけの負荷と見なすことはできません。詳細ログの表示、頻繁な速度測定、画面の継続的な更新もリソースを使います。比較時はこれらの条件をそろえましょう。

接続の再利用によって、一部のハンドシェイクを減らせる場合がありますが、常に効果があるとは限りません。複数の通信が同じ接続を共有すると、スケジューリングや輻輳の影響も互いに受けます。プロトコル自体にマルチストリーム機能がある場合、さらに別の多重化を加える必要がないこともあります。対応状況や適切な設定は、現在のカーネルとサーバーの組み合わせによります。まずは通常の初期値を使い、短時間接続の負荷が多いと分かってから条件をそろえて比較しましょう。「高速化」オプションを一度にすべて有効にしないでください。

スマートフォンの電池消費はまずバックグラウンド動作を確認

モバイル端末の電池消費は暗号化の複雑さだけで決まりません。モバイル回線の無線機能の起動、長時間の通信維持、キープアライブの頻度、頻繁な再接続、バックグラウンドアプリの通信も大きな要因です。ノードがアイドル状態でも電池が減る場合は、アプリが通信し続けていないか、接続が何度も切れていないか、サブスクリプション更新や死活監視の頻度が高すぎないかを確認しましょう。QUICを使っているから電池を多く消費する、設定項目が少ないから必ず省電力になる、と決めつけないでください。

電池消費を比較するときは、画面の明るさ、ネットワークの種類、アプリのタスク、観察時間をできるだけそろえ、待機時と継続通信時を分けて測ります。システムの電池使用量では、仮想ネットワークアダプターの転送処理がクライアントに計上されることがあります。そのため、クライアントの使用割合が増えても、端末全体の消費電力が同じ割合で増えたとは限りません。逆に、システムがバックグラウンド動作を停止すると、省電力に見えてもアプリが切断されることがあります。アプリ単体の割合だけでなく、必要な通信が継続して使えるかも合わせて判断してください。

簡単な記録を端末に残しておきましょう。端末、ネットワークの種類、選択したノード、通信の取り込み方式、テスト内容、異常の有無を記録します。まず日常のWeb閲覧や必要なアプリで確認し、次に長時間の通信やネットワーク切り替え後の復旧を試します。何度か繰り返して一貫した傾向があるかを見れば十分で、総合スコアを作る必要はありません。テスト中に端末が熱くなったら、大容量通信を止めて通常の温度に戻してから比較してください。熱による性能低下が起きると、その後の結果が変わり、プロトコルの差ではなく温度の差を測ることになります。

通信の入口も個別に管理しましょう。システムプロキシは、通常、システムプロキシ設定に従うアプリの通信にのみ影響します。TUNはルーティング条件に合う通信をネットワーク層で取り込みますが、除外設定やプラットフォーム上の制約があります。TUNを有効にして通信の対象範囲が広がると、リソースの変化がノードのプロトコルによるものとは限りません。違いを確認するには、TUNモードとシステムプロキシの違いをご覧ください。最終的には、特定のテスト結果だけを追うのではなく、実際の用途を安定して完了できる方法を選びましょう。

サブスクリプションの互換性：形式が正しくても機能がそろうとは限らない

まず取得したデータの種類を確認

サブスクリプションURLは設定を取得するための入口であり、返される内容が一種類とは限りません。Clashの完全な設定、プロキシノードのみの一覧、エンコードされた共有リンクの一覧、別のカーネル向けの設定などがあります。完全な設定には通常、プロキシ、プロキシグループ、ルール、DNS設定が含まれます。ノード一覧には接続情報が記載されますが、そのまま有効にできるルーティングルールが含まれているとは限りません。インポートする前に、クライアントの入力欄が完全な設定、ノードのサブスクリプション、プロキシ一覧のどれを求めているか確認し、異なる階層のデータを同じ場所に入れないようにしましょう。

共有リンクだけで構成を完全に表現できるとは限りません。プロトコルの項目をクエリ部分で渡すリンクの場合、変換ツールが項目を認識できず無視することがあります。また、リンクで使われている仕様が一部のクライアントでしか実装されていない場合もあります。インポート後にノード名が正しく表示されても、セキュリティ機能、転送パス、プラグインの設定が保持されたとは限りません。複雑なノードは元の説明と照合して重要な項目を確認してください。必要な情報が欠けている場合は、同じデータを繰り返し変換するのではなく、使用するカーネル向けのネイティブ設定を入手しましょう。

プロキシ一覧と完全な設定を区別する

mihomoではプロキシプロバイダーを使って外部からノードを読み込み、プロキシグループから参照できます。プロバイダーの内容と完全な設定では外側の構造が異なり、相互に置き換えることはできません。次の例はローカルプロバイダーの参照方法を示すだけです。既存の設定と統合し、指定したパスに有効なプロキシ一覧ファイルを配置する必要があります。サーバー情報や認証情報は含まれていないため、この例だけでノードを接続することはできません。ファイルパスは、現在のクライアントがアクセスできる作業ディレクトリにしてください。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

proxy-groups:
  - name: Proxy
    type: select
    use:
      - local-nodes

設定のチェックに通った後は、プロキシグループがそのプロバイダーを実際に参照しているか確認します。ノードのインポートに成功してもグループに表示されない場合は、参照の設定漏れやフィルター条件によって除外されている可能性があります。原因が必ずしもプロトコルにあるとは限りません。完全な設定でルールが参照するプロキシグループ名は、実際に存在している必要があります。大文字・小文字や文字列も一致させてください。「Proxy」という名前のグループを日本語名に変更したのに、ルールで古い名前を使い続けていると参照エラーになることがあります。名前を変更する前に、すべての参照箇所を検索しましょう。

変換と上書き設定に潜むリスク

サブスクリプション変換でできるのは、存在する情報を組み直すことだけです。欠けている証明書名、公開鍵、プラグインのパスワードを推測したり、古いカーネルに新しいプロトコルへの対応を追加したりすることはできません。変換サービスがサブスクリプションURLやノードの認証情報を取得する可能性もあるため、信頼できる方法を使い、不明なサイトに個人用のサブスクリプションを貼り付けないでください。他の人に調査を依頼する場合は、機密情報を除いた設定の一部とエラーの種類を共有します。サブスクリプションURL全体を公開したり、認証情報が写ったスクリーンショットを公開の場に投稿したりしないでください。

クライアントの上書き設定は、通常、待ち受けポート、ルールの追加、DNS設定などのローカル設定を保持するために使います。ただし、設定の適用順序や配列の処理方法はクライアントによって異なります。リスト全体を置き換える場合、名前をもとに統合する場合、スクリプトで最終設定を生成する場合があります。サブスクリプション更新後にノードは正常でもルールが動かない場合は、元のサブスクリプションだけでなく、実際に適用された設定を確認してください。切り分けでは不要な上書き設定を一度無効にし、元の設定が使えることを確認してから、変更を一つずつ戻しましょう。

YAMLではインデントとデータ型に決まりがあります。リスト項目には正しいハイフンが必要で、階層はスペースで表します。特殊文字を含む文字列は適切に引用してください。パスワードが数値や真偽値のように見える場合も、誤った型として解析されないように注意が必要です。半角のコロンを全角に置き換えたり、見た目をそろえるためにタブを混ぜたりしないでください。編集後はクライアントの設定チェックやプレビューを使ってから有効化しましょう。構文エラーとネットワークエラーは発生する段階が異なるため、分けて調査してください。

最後に更新の反映範囲を確認しましょう。更新の取得に成功しても、それだけでは返された内容が有効か、カーネルに読み込まれたか、現在の設定が新しい結果へ切り替わったかは分かりません。更新に失敗したとき、直近の有効な設定を保持しておけば利用を続けられますが、画面に古いキャッシュのノードが表示されることもあります。初回インポート、権限、ポートの競合については初回起動後の初期設定で起きやすい問題も確認してください。Fake-IPのローカル設定については、入門ガイドのFake-IP解説をご覧ください。

用途別の選び方：必要条件を満たしてから使い心地を比較

既存サービスと端末の対応状況から候補を絞る

プロトコルの優劣を先に決めるのではなく、利用可能な条件から選びます。サービス提供元が実際に提供するノードの種類、端末で使えるクライアント、カーネルが対応するプロトコルの組み合わせ、現在のネットワークで必要な転送方式を整理しましょう。条件を一つでも満たせない場合は、設定変更を繰り返しても適切に動かない可能性があります。一般のユーザーはダウンロードページからおすすめのClash Plusを選び、OSの要件に沿ってインストールしたうえで、実際のカーネルと設定の対応状況を確認できます。プロトコルの解説は判断の参考であり、クライアントの最新の対応情報に代わるものではありません。

デスクトップで日常のWeb閲覧や仕事をするなら、設定項目がそろい、安定して保守され、実際の用途で動作を確認できたノードを選びましょう。すでに利用しているSS、Trojan、VMess、VLESSのノードで要件を満たせるなら、プロトコル名が新しくなったからといって設定全体を作り直す必要はありません。コマンドラインや特定のアプリがプロキシを経由しないことが問題なら、ノードの種類を変更する前に通信の入口とルーティングを確認してください。アプリの通信がカーネルに届いていなければ、サーバー側のプロトコルを変えても通信経路は変わりません。

スマートフォン、長時間通信、制限のあるネットワークを分けて考える

ネットワークを頻繁に切り替えるスマートフォンでは、静止状態での初回接続だけを測るのではなく、復旧のしやすさ、バックグラウンドでの維持、電池消費を確認しましょう。省電力設定でクライアントが停止されたり、ネットワーク切り替え後に仮想ネットワークアダプターやルーティングが再構築されたりすることがあります。まず必要な権限を許可し、OSの説明に沿ってバックグラウンド動作を設定してからノードを比較してください。画面ロック後だけ切断され、ログに明確なプロトコルエラーがない場合は、まずOSのバックグラウンド制御を確認します。ネットワークを切り替えるたびに認証に失敗するなら、セッションの復旧とサーバーの状態を確認してください。

継続的なダウンロード、大規模な同期、長時間の通信では、必要な条件を満たすHysteria2やTUICを、既存のTCP系方式と比較できます。前提は、UDP経路が安定し、送信設定が回線容量に合っていることです。会社、学校、ゲスト用のネットワークでは、指定されたプロキシを通じて接続する必要がある場合があります。特定の方式で直接外部へ接続できるとは限らないため、ネットワークの利用ルールに従い、許可された方法を使ってください。ネットワークのポリシーによる接続不可を、プロトコルの「性能が低い」と誤って評価しないようにしましょう。

決まった手順で切り分け、設定全体を一度に変更しない

トラブル発生時は、まず設定の入手元が有効か、サブスクリプションの更新結果が読み込まれているかを確認し、次にシステム時刻とネットワークの基本的な接続を調べます。その後、名前解決、接続確立、セキュリティハンドシェイク、プロキシ認証のどの段階で失敗しているかログで確認してください。特定のノードだけで問題が起きるなら、そのノードの設定とサーバーの状態を優先して照合します。すべてのノードで同時に起きる場合は、端末側の通信の入口、DNS、ポート、ネットワーク経路を確認しましょう。問題の範囲を正しく絞ることは、高度な設定を一つずつ試すより効果的です。

接続は確立するのに特定のWebサイトだけ使えない場合は、ルールの適用状況、接続先の名前解決、アプリ側の設定を確認します。Webページは表示できてもゲームや音声通話に問題がある場合は、UDP対応、通信の取り込み範囲、ファイアウォールを確認してください。TUNを有効にした後でLANにアクセスできなくなった場合は、ルーティングの除外設定とローカルアドレスの処理を調べ、ノードのパスワードはすぐに変更しないでください。症状と変更した項目をその都度記録し、結果を確認してから次に進みましょう。詳しい切り分け手順は、ノードのタイムアウト・速度測定失敗のトラブル対処チェックリストをご覧ください。

サーバーやルーターでは、端末のアーキテクチャ、利用可能なメモリ、サービスの起動権限、ストレージへの書き込みも考慮が必要です。カーネルをインストールできても、多数の接続を処理するのに適しているとは限りません。ログの出力量が多すぎたり、死活監視を頻繁に行ったりすると、小型端末への負荷が増えることがあります。一般的なPCやスマートフォンではGUIクライアントで設定を管理し、無人で常時稼働させる場合にカーネルパッケージを使いましょう。デスクトップクライアントが生成したシステムパスをそのままルーターに移さず、プロバイダーファイル、キャッシュディレクトリ、証明書ファイルが読み込めるか確認してください。

最後に、復元可能な基準設定を一つ保存し、有効なノード、必要なセキュリティ設定、通信の入口を記録しましょう。日常のタスクで安定して再現できる改善だけを長期設定に反映してください。正しい認証情報、信頼できるサービス、適切なネットワーク環境に代わるプロトコルはありません。このページは設定項目と仕組みを確認する参考資料として使い、初めて設定する場合は設定入門ガイドに戻ってください。インストーラーを変更するときは、ダウンロードページでOSに合ったものを選び、クライアント、カーネル、サブスクリプション全体を同時に変更して比較できなくなるのを避けましょう。