技術ガイド：プロトコルとカーネル

1. プロトコル選びの4つの基準

プロトコル、通信方式、カーネル、UIはそれぞれ別の層

クライアント上のノード名は通常、プロバイダーが独自に付けています。「高速」「専用線」といった名前だけでは技術的な情報は分かりません。実際の接続には少なくとも4つの層があります。プロトコルはクライアントとサーバー間の認証や転送方法を定め、通信方式はTCP、UDPなどの経路を決めます。カーネルはプロトコルの実装や設定の解析、ルールの適用を担い、GUIはサブスクリプション管理、システムプロキシ、ログなどへの入口を提供します。同じUIでもカーネルを変えると認識できるノード形式が変わる場合があります。同じプロトコルでも、サーバーや回線が違えば使い勝手は大きく異なります。

まず確認すべきなのは、プロトコル名の新旧ではなく、クライアントとサーバーが正しく通信できるかどうかです。サーバー側のプロトコル、認証パラメーター、通信方式、安全設定に、クライアントの設定を合わせる必要があります。ノード形式がVLESSに対応していても、あらゆるVLESSの組み合わせが使えるとは限りません。UIに形式名が表示されても、実行中のカーネルがすべての項目を解釈できるとは限りません。アプリ名だけで判断するより、クライアントのカーネル情報と実際の設定を確認するほうが確実です。

接続時間と持続的な通信速度を分けて見る

Webページを開くときは、名前解決、サーバーへの接続、認証、接続先へのアクセス、最初のデータが届くまでの待ち時間が発生します。初回アクセスが遅い原因は、そのどの段階にもあり得ます。一方、大容量ファイルのダウンロードでは、持続的な転送性能、輻輳制御、サーバーの出口帯域、接続先の速度制限がより重要です。最初のデータは速く届いても、長時間にわたって速度を維持できないノードもあります。接続準備に少し時間がかかっても、ダウンロードが安定するノードもあります。こうした違いは矛盾ではなく、単一の遅延値では表せません。

モバイル回線では、ネットワークの切り替えや無線の省電力動作も影響します。Wi-Fiからモバイル回線に切り替えると、端末のローカルアドレスや出口アドレス、通信経路の品質が変わることがあります。接続を再確立する必要がある場合もあれば、通信方式によっては経路の移行を試みられる場合もあります。ただし、最終的にはカーネル、サーバー、中継ネットワークすべての対応次第です。プロトコルに機能があるということは、仕様上その機能を備えているというだけです。すべての環境で有効とは限らず、アプリのセッションが必ず継続するわけでもありません。

条件を満たさない選択肢から外す

実際の選定では、条件に合わない候補を除外していきます。UDPのアウトバウンド通信が安定しないネットワークでは、QUICベースのプロトコルだけに頼らないようにします。端末のカーネルが特定のセキュリティ設定に対応していない場合は、見慣れない項目を削除して無理にインポートしないでください。サーバーが1種類のプロトコルしか提供していないなら、クライアント側で別のプロトコルに変えることもできません。使える組み合わせを絞ってから、同じ時間帯、同じ端末、同じ接続先で比較しましょう。こうして得られるのは現在の環境における結果であり、条件を無視したプロトコルランキングではありません。

2. SSとVMessの設計上の違い

SS：シンプルなプロトコルと明確な暗号化パラメーター

Shadowsocks（SS）は、軽量な暗号化プロキシとして設計されました。基本的な設定項目は、サーバーアドレス、ポート、暗号化方式、パスワードです。クライアントはローカルアプリからのリクエストをプロトコルデータに変換し、サーバーが接続先への通信を確立します。一般的なAEAD方式では暗号化とメッセージ認証を組み合わせ、データの改ざんを検知できます。「方式」は自由に置き換えられる速度設定ではありません。クライアントとサーバーで方式が異なる、または認証情報が一致しない場合、接続は正しく確立できません。

SSにはその後、異なる仕様や拡張が登場し、新しい方式の中には鍵の要件が異なるものもあります。SSと書かれているからといって、古い設定のパスワード文字列を別の方式にそのまま流用できるとは限りません。一般的なパスワードを受け付ける方式もあれば、特定の長さや形式の鍵が必要な方式もあります。また、クライアントによってはプラグイン拡張に対応していても、別のクライアントには同じプラグインが実装されていない場合があります。インポートできるのにハンドシェイクが失敗し続ける場合は、暗号化方式、鍵の形式、プラグインのパラメーターを確認しましょう。ローカルの混合ポートを何度も変更する必要はありません。

SSの基本構造は比較的シンプルですが、実際の負荷は暗号化方式、CPU命令セットの対応状況、実装品質、トラフィック量によって変わります。TCPとUDPの転送は、それぞれクライアントとサーバー双方の対応が必要です。ノードがUDPに対応していても、すべてのアプリのUDPリクエストがそのノードを通るわけではありません。システムプロキシの設定が適用されるのは、通常、プロキシ設定に従うアプリだけです。それ以外の通信では、TUNやアプリ独自のSOCKS設定が必要な場合があります。音声通話やゲームの接続を調べるときは、通信の入口とノード側の出口の両方を確認してください。

VMess：認証機能を備えたプロキシプロトコル

VMessはV2Rayエコシステムで開発されたプロトコルで、ユーザー認証とリクエストのカプセル化を備え、複数の通信方式と組み合わせて使えます。一般的な設定にはUUID、暗号化オプション、通信方式、TLSの設定などが含まれます。これらはそれぞれ異なる層に属します。UUIDはユーザー識別に使われ、通信方式は接続の運び方を定め、TLSは該当する通信経路を安全に保護します。層ごとに考えると、同じVMessでもTCPで直接接続できるノードと、WebSocketのパスやHost情報まで必要なノードがある理由を理解できます。

VMessの認証では時刻が関係するため、システム時計が大きくずれていると接続に失敗することがあります。端末で時刻が正しく同期されているか確認し、サーバー側のログもチェックしてください。古い設定にはalterIdなどの項目が含まれる場合がありますが、現在一般的な構成と旧式の構成には違いがあります。互換性を推測して値をむやみに増減しないでください。まずはプロバイダーが現在のカーネル向けに提供する完全な設定を使い、古いサブスクリプションを移行する場合は認証方式を個別に確認しましょう。旧項目を汎用的な最適化パラメーターと考えるのは避けてください。

古いノードにも使い道はある

SSとVMessは長年使われており、既存の端末との互換性が、今も使い続ける理由になることがあります。選ぶときは登場時期だけで判断せず、サーバーが適切に保守されているか、暗号化設定が妥当か、回線が安定しているかを確認しましょう。既存のノードで要件を満たせているなら、明確な目的なしに別のプロトコルへ移行する必要はありません。特定の通信方式との互換性を解決したい、設定を統一したいなど、移行の理由を明確にしてください。ノード形式の名前を変えても回線容量は増えません。誤った変換ではプラグインや通信方式の設定を失うこともあります。

2種類のプロトコルに速度の決まった優劣はありません。比較するときはサーバーの場所、出口、接続先をできるだけそろえましょう。異なるプロバイダーを比較する場合、実際にはサーバーやネットワークの違いを比べていることがほとんどです。どのプロトコルでも遅い場合は、ネットワーク速度が遅いときの段階的なトラブル対処も参照し、ローカルの入口、ノードの負荷、回線品質を切り分けてください。複数の層に共通する障害を、特定のプロトコルの欠点と誤認するのを防げます。

3. TrojanとVLESSのセキュリティ層

Trojan：正しいTLS接続が前提

TrojanはTLS接続の内側でプロキシ転送を行い、パスワードで認証する設計です。成熟したTLSのセキュリティ機能を利用するため、クライアント側ではサーバーアドレス、ポート、パスワードだけでなく、サーバーの本人確認も正しく設定する必要があります。証明書の有効期限、ドメイン名との一致、証明書チェーンの完全性などが接続に影響します。パスワードが正しくても証明書の問題は解決しません。逆に、TLSハンドシェイクが成功してもプロキシ認証が通ったとは限りません。ログを見てどの段階で失敗したのかを切り分けましょう。

混同しやすい名前が2つあります。接続先アドレスはネットワーク上の接続先を決め、SNIは該当するTLSハンドシェイクでサーバーに接続先のホスト名を伝えます。両者は同じ場合も、サーバーの構成によって異なる場合もあります。IPアドレスで接続する場合でも、証明書の検証対象をそのIPアドレスに変更してよいとは限りません。サーバー側が指定するドメインパラメーターを使ってください。クライアントのsniや同等の設定項目は、本人確認とルーティングに関わる項目です。人気サイトのドメインを適当に入力すれば接続が改善する、というものではありません。

証明書の検証に失敗したら、まず端末の時刻、証明書のドメイン名、サーバー側の証明書チェーンを確認してください。検証を無効にしたまま使うと、クライアントがサーバーの本人確認を正しく行えなくなるため、通常の互換設定として使うべきではありません。サーバーが独自の証明書体系を使っている場合は、クライアントの対応方法に従って明確な信頼関係を設定しましょう。すべての検証エラーを無視するのは避けてください。トラブル対処のため一時的に検証設定を変える場合でも、影響を理解したうえで原因を確認し、最終的にはサーバー構成に合った安全な設定に戻してください。

VLESS：認証方式はシンプルだが、独立した暗号化機能はない

VLESSもV2Ray関連エコシステムで生まれたプロトコルで、シンプルなID認証とプロキシリクエストを重視しています。独自の暗号化機能を持つプロトコルとは異なり、VLESS単体では通信全体を保護できません。適切なセキュリティ層と組み合わせる必要があります。クライアントにtype: vlessと表示されても、それで確認は終わりではありません。TLSやREALITYなどのセキュリティ設定、通信方式、サーバーが要求するflowも確認してください。セキュリティ項目を削除すると、設定が使えなくなったり、想定された安全性が損なわれたりする可能性があります。

REALITYは対応するプロキシと組み合わせて使うセキュリティ機構であり、どんなノードでもVLESSに変換できるスイッチではありません。公開鍵、短いID、サーバー名などの設定は、サーバー側の構成と一致させる必要があります。公開鍵はクライアント側で生成して適当に入力する値ではなく、短いIDもノード名ではありません。flowは、クライアントとサーバー、通信方式の組み合わせが対応している場合にのみ使えます。設定例にこの項目があっても、ほかのVLESSノードにそのままコピーする必要はありません。

追加の通信層はメリットとコストを合わせて考える

WebSocket、HTTP系の通信方式、その他のカプセル化は、既存のサーバー構成に適応するために使われますが、無料で追加できる高速化機能ではありません。層を増やすと、リクエストヘッダーやハンドシェイク、中継プロキシによる制約が増えることがあります。一方で、既存のインフラを活用して接続性を改善できる場合もあります。選ぶ際は、実際のどの問題を解決するために使うのかを確認してください。直接接続がすでに安定しているなら、追加のカプセル化は役に立たないかもしれません。サーバーが特定の入口だけで提供されている場合は、パス、ホスト名、関連パラメーターをすべて保持し、層を減らすために勝手に削除しないでください。

これらのプロトコルは、TLSの構成が明確で、対応するエコシステムの機能が必要な場合に適しています。一般的なクライアントユーザーには、mihomo対応と明記された設定をプロバイダーから入手してインポートし、カーネルのログで全項目が認識されているか確認する方法が確実です。パラメーターの役割を理解していれば問題の特定に役立ちますが、ノードを一から手作業で再構築する必要はありません。設定を変更する場合は、記憶に頼って入力し直すより元の設定を保存しておくほうが安全です。

4. Hysteria2とTUICに必要なUDP環境

共通の基礎：QUICは通常のUDP転送とは異なる

Hysteria2とTUICは、どちらもQUICを使ってプロキシ通信を行います。QUICはUDPを基盤とし、安全なハンドシェイク、信頼性のあるストリーム、輻輳制御などの機能を備えています。「UDPに変えれば再送がなくなる」という意味ではありません。信頼性が必要なデータには確認応答や復旧処理が必要で、その処理をQUICの実装が担います。複数ストリームによって、単一のTCP接続で起きる一部の相互ブロッキングを減らせる場合があります。ただし、同一ストリーム内のデータ順序、共通経路の輻輳、サーバーの処理能力は引き続き性能を左右します。

これらのプロトコルを使うには、クライアントからサーバーまでのUDP経路が利用できる必要があります。DNSのUDP通信が許可されていても、任意の宛先ポートで継続的なQUIC接続が許可されているとは限りません。ゲストネットワーク、ファイアウォール、通信事業者のネットワーク、サーバーのセキュリティグループなどが接続に影響します。TCPノードは使えるのに、QUICノード2種類がどちらもタイムアウトする場合は、認証パスワードをすぐに変更せず、UDPのアウトバウンド通信、サーバーの待ち受け、ポートマッピングを確認してください。NATマッピングの有効時間も、長時間アイドル状態の後の再接続に影響します。

Hysteria2：複雑なネットワークに対応する送信制御

Hysteria2は、高遅延やパケットロスなどの複雑なネットワーク環境を想定して設計されています。QUICでプロキシ通信を行い、輻輳制御や帯域設定の機能を備えています。設定には認証情報、TLS名、サーバー構成に応じた難読化や帯域の項目が含まれる場合があります。初代HysteriaとHysteria2は、名前を変えただけの同じプロトコルではありません。種類の項目だけを書き換えても相互接続できるとは限りません。サブスクリプション変換ツールが正しい世代を認識し、現在のカーネルに必要な項目を保持する必要があります。

帯域のパラメーターは特に誤用されやすい項目です。表示上の目標速度ではなく、送信動作の判断に使われる場合があります。上りや下りの帯域を実際の回線容量を大きく上回る値にすると、キューイングやパケットロス、ほかのアプリとの競合が増えることがあります。低すぎる値では通信速度を制限する可能性があります。サーバー構成で使われている輻輳制御方式に応じて項目の意味を確認し、安定した回線での測定結果を基に設定してください。サーバー側のネゴシエーションやポリシーによって動作が制限されることもあります。クライアントに大きな値を入力しても、サーバーの出口帯域は増えません。

TUIC：マルチストリームと輻輳制御には双方の対応が必要

TUICもQUIC上でプロキシ接続を実装しており、ストリームの多重化やUDP転送などのニーズに対応します。一般的な設定にはUUID、パスワード、サーバー名、輻輳制御関連のオプションが含まれます。プロトコルの世代や実装によって互換性の範囲が異なるため、TUICと書かれているだけで相互接続できるとは限りません。サーバーが指定するプロトコル世代と認証方式を使い、輻輳制御の名称が現在のカーネルに受け入れられることも確認してください。未知のオプションが無視される場合もあれば、エラーになる場合もあります。実際の読み込みログを確認しましょう。

一部の実装は、接続の再確立時の待ち時間を短縮するため、0-RTTデータやセッション再開に対応しています。ただし、新規接続、再開接続、無効なセッションでは経路が異なります。再開時のメリットを、すべてのリクエストに当てはめることはできません。0-RTTデータにはリプレイ攻撃のリスクやサーバー側のポリシーも関係するため、有効にする場合は実装のドキュメントに従ってください。一般ユーザーは、プロバイダーが指定するデフォルトの組み合わせを維持して繰り返しアクセスをテストするほうが、ハンドシェイク時間だけを追い求めるより有益です。

Hysteria2やTUICは、UDP経路が良好な環境では候補になりますが、検証していない環境で唯一の接続手段にするのは避けましょう。安定したTCP系の候補も残しておくと、プロトコルの問題とネットワーク制限を切り分けやすくなります。また、モバイル回線の切り替え後も常に接続が継続するとは限りません。接続ID、経路移行の仕組み、サーバーのポリシー、クライアントのライフサイクルが結果を左右するため、切り替え後に実際に復旧するか確認してください。

5. 接続速度、リソース、スマホの電池消費

単一の速度測定値ではなく、段階ごとにテストする

ノードの遅延測定では通常、特定のアドレスにリクエストを送り、その所要時間を表示します。クライアントによって接続先、接続の再利用方法、タイムアウトのルールが異なるため、画面上の数値を単純に比較できるとは限りません。測定リクエストが成功したことから分かるのは、その時点で該当の経路が特定のテストを完了したということだけです。動画、コードリポジトリ、リアルタイム通話でも同じ性能が得られるとは限りません。接続先の場所、名前解決の結果、接続方式が違えば、実際の通信経路も異なることがあります。

テストは3種類に分けましょう。短時間の接続では、ページの初回データが届くまでの時間と失敗回数を確認します。継続的なダウンロードでは速度を維持できるかを測定し、インタラクティブなアプリではジッター、再接続、バックグラウンドからの復帰を確認します。どのテストも、最も良かった結果だけを残すのではなく、繰り返し実施してください。比較時は端末、ネットワーク、サーバーの地域、接続先をできるだけそろえ、ほかの大容量通信を停止して、接続を再利用しているかも記録します。サーバー側の条件をそろえられない場合は、プロトコルの実装だけでなく、ノード全体を比較していると明記してください。

CPU、メモリ、接続数は互いに影響する

暗号化、データのコピー、プロトコルのカプセル化、輻輳制御はいずれもCPU時間を消費します。ハードウェアアクセラレーションへの対応、カーネルのビルド方法、OSのネットワークスタックによって負荷は変わるため、同じプロトコルでも端末によって性能の順位が変わることがあります。メモリ使用量はルールセットの規模、DNSキャッシュ、接続数、ログバッファーにも左右されます。クライアントのリソース使用量が多くても、すぐにノードのプロトコルが原因と決めつけないでください。大量のルールプロバイダーを読み込んでいないか、並行ダウンロードが多くないか、UIが接続一覧を頻繁に更新していないかを確認しましょう。

接続の再利用で一部の接続処理を減らせますが、リソースや障害の影響範囲を共有することにもなります。複数のリクエストが1つの接続を共有すると、輻輳が起きたときに複数の通信へ同時に影響する場合があります。再利用しない場合は、ハンドシェイクや接続数が増えることがあります。特にプロトコル自体がマルチストリームに対応している場合、多重化を重ねても改善するとは限りません。具体的なメリットが説明でき、カーネルとサーバーの対応も確認できない限り、デフォルト設定を使いましょう。遅延を減らせそうなオプションをすべて同時に有効にするのは避けてください。

電池持ちは瞬間的なピークではなく、1日の使い方で判断する

モバイル端末の電池消費は、暗号化処理だけでなく、無線モジュールが起動する回数や通信を続ける時間にも左右されます。頻繁なヘルスチェック、短すぎるKeep-Alive間隔、失敗を繰り返す再接続、バックグラウンドでのサブスクリプション更新、詳細ログの記録などは電池消費を増やすことがあります。ダウンロード中のCPU使用率が低いプロトコルでも、待機中の消費電力が少ないとは限りません。UDPのNATマッピングが短いネットワークでは、クライアントが接続を維持または再確立し続け、1日の総消費電力がかえって増えることがあります。使用中と待機中を分けて確認してください。

TUNを使うと、ルーティング条件に合う通信をより多くカーネルに通すことがあります。有効化の前後で電池消費が変わっても、プロトコルの効率ではなく、処理対象が増えたことが原因かもしれません。システムプロキシが扱うのはシステム設定に従うアプリだけで、TUNとは処理量が同じとは限りません。電池消費を比較するときは、通信の取り込みモード、ルール、バックグラウンドアプリをそろえ、似た利用時間帯で測定してください。OSがクライアントのバックグラウンド動作を制限していないかも確認しましょう。クライアントがOSに停止されて接続が切れた結果「省電力」になっても、最適化に成功したとは言えません。

6種類のプロトコルに一律の「省電力ランク」や「速度評価」を付けるのはおすすめしません。こうしたラベルでは、端末、回線、設定の違いを考慮できないためです。役立つのは条件付きの結論です。現在のスマホ、ネットワーク、固定した通信の取り込みモードで、どのノードが用途を満たし、バックグラウンドでも安定するかを確認しましょう。一度に変更するのは1つの項目だけにし、性能が悪化したら前の状態に戻せるようにしてください。カーネル、プロトコル、DNS設定をまとめて変更する必要はありません。

6. オリジナル版、Meta、mihomoの関係

カーネルの進化と設定の系譜

オリジナル版Clashでは、ルールによる振り分け、プロキシグループ、設定ファイル、制御APIなど、広く使われる仕組みが確立されました。Clash.Metaは関連するコードと設定体系を基にプロトコルや機能を拡張し、後にmihomoという名前で開発が続いています。古い資料で「Metaカーネル」と「mihomo」が同じ系譜の異なる段階を指していることはよくありますが、すべての時期で機能が同じという意味ではありません。互換性を確認する際は、歴史的な名称だけでなく、実行中の実装と具体的な設定項目を確認してください。

オリジナル版の設定で使われる基本的な概念の多くは、mihomoにも引き継がれています。たとえばproxies、proxy-groups、rulesなどです。設定の連続性は高いものの、双方向の互換性が保証されるわけではありません。オリジナル版にないプロトコル、ルール形式、DNSオプションを含む新しい設定を、YAMLファイルだからという理由だけでオリジナル版が解釈できるとは限りません。移行では名称よりも方向が重要です。基本設定から拡張実装への移行と、拡張設定を旧実装に戻す作業は別のものです。

クライアントは管理レイヤーであり、カーネルと同じものではない

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuなどのクライアントは、それぞれ異なるUIや連携機能を備えています。ダウンロードページでは、まずClash Plusを掲載しています。GUIからサブスクリプション管理や基本設定を行いたい場合に適しています。ほかのクライアントはプラットフォームや必要な機能に応じて選んでください。システムプロキシ、サービスモード、TUNの権限、設定の上書きなどは、クライアントとカーネルが連携して動作します。UIに高度な項目が表示されないからといってカーネルが未対応とは限りません。UIにボタンがあっても、OS側の権限が満たされているとは限りません。

クライアントによっては、独自の実行用設定を生成することもあります。ユーザーがインポートしたサブスクリプションの原文に対し、カーネルの起動時に使われるファイルはポートの追加、ルールの統合、上書き設定などを反映したものかもしれません。トラブル対処では、どのファイルを確認しているのか把握する必要があります。生成ファイルを直接編集しても、次回の設定切り替えや再起動で上書きされることがあります。サブスクリプションの原文を変更しても、その後の更新で変更が失われる可能性があります。クライアントが提供する永続的な上書き機能を使い、実際の実行設定に変更が反映されているか確認してください。

設定移行と権限の確認は分けて行う

移行前に現在の設定、プロキシグループの選択、上書き設定を保存し、新しいクライアントにはコピーをインポートしてください。まず複雑な上書き設定を無効にして基本設定を検証し、プロトコルが認識されるか、プロキシグループの参照先が存在するか、ルールプロバイダーを取得できるか確認します。基本的な接続ができたら、DNS、TUN、カスタムルールを1つずつ戻してください。こうすれば、複数の層を同時に変えた設定から原因を探すのではなく、問題がどの段階で起きたか特定できます。

基本のプロキシ接続は使えるのにTUNが動かない場合は、プロトコルをすぐ変更せず、権限、ドライバー、ルーティング、システムサービスを確認してください。システムプロキシを有効にした後、ターミナルだけ接続できない場合は、ターミナルがシステムプロキシを参照しているか確認しましょう。詳しくはブラウザーとターミナルを分けて確認する方法を参照してください。これらは受信側やアプリ層の問題であり、サーバーがSSかTrojanかとは通常別の障害です。

7. サブスクリプション形式と設定の互換性

同じ「サブスクリプション」でも、受け取る内容はさまざま

サブスクリプションは配布方法であり、単一のファイル仕様ではありません。リンクから返される内容は、Clash形式の完全なYAML、ノードだけの一覧、エンコードされた共有リンクのリスト、またはWebページのエラーメッセージなどさまざまです。完全な設定には通常、プロキシグループ、ルール、DNSなどが含まれます。ノード一覧だけの場合は、クライアントやテンプレートでほかの項目を補う必要があります。「リンクを開ける」からといって、実行可能な設定が返されたとは限りません。インポートに失敗したら、まずレスポンスの種類と構造を確認し、その後でクライアントの対応状況を判断してください。

SS、VMess、Trojan、VLESSなどの共有リンクは、それぞれパラメーターの表現方法が異なり、エンコードやエスケープの方法も同じではありません。YAMLに変換する際は、認証、通信方式、セキュリティ、拡張項目を保持する必要があります。変換ツールがプロトコル名を認識しても、新しいパラメーターを知らない場合、見た目は整っていても必要な項目が欠けることがあります。特にREALITY、flow、プラグイン、QUIC関連の設定は、変換が成功しただけで保持されていると判断しないでください。

YAMLとして解析できても、設定の意味が正しいとは限らない

YAMLではインデント、リスト、マッピングに明確なルールがあります。インデントにはスペースを使い、特殊文字を含む文字列は適切な形式の引用符で囲んでください。解析に成功したことから分かるのは、ファイル構造が正しいということだけです。プロキシグループが存在しないノードを参照している、ルールが存在しないポリシーを指定しているなどの問題があれば、実行に失敗する可能性があります。ノード名の重複も選択時の混乱につながります。複雑なサブスクリプションでは、構文エラー、設定項目の誤り、参照エラー、実行時のネットワーク障害を分けて調べてください。すべてを「更新失敗」の一言でまとめないようにしましょう。

以下の例は、mihomoにおけるローカルの受信設定とルールの最小限の関係を示すもので、リモートのプロキシサーバーは含みません。混合ポートでHTTPとSOCKSのリクエストを受け付け、LANからのアクセスは無効にし、一致する通信はすべてDIRECTで接続します。設定の構造を理解するための例であり、既存のサブスクリプションに含まれるリモートノードの設定を置き換えるものではありません。実際にプロキシを使うには、実在するノードと対応するプロキシグループを追加し、ルールが正しいグループ名を参照するようにしてください。

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

ローカルのポートとリモートノードのポートは、別々の接続先です。mixed-portを変更したら、プロキシを手動設定しているアプリのポートも変更してください。リモートサーバーのポートは、サーバー側の待ち受け設定と一致させる必要があります。サブスクリプションに含まれるallow-lanは、ノードの性能を決める項目ではありません。端末へのLANアクセスを許可するかどうかを指定します。プロキシを共有する場合は、待ち受け範囲、ファイアウォール、認証を理解してください。スマホから接続するためだけに、すべてのネットワークインターフェースを外部へ公開しないでください。

リモートプロバイダー、上書き設定、更新の違い

proxy-providersはノード一覧を取得し、rule-providersはルール一覧を取得するための設定です。用途が異なるため、特定のノード形式だけを受け付けるプロバイダーに、完全なクライアント用サブスクリプションをそのまま指定してはいけません。更新に失敗する原因は、DNS、接続経路、サーバー認証、レスポンス内容、ローカルのファイル権限などさまざまです。ログでは、ダウンロード段階の失敗か、ダウンロード後の解析失敗かを確認してください。前者はネットワークやレスポンスを調べ、後者は形式とカーネルの設定項目への対応を確認します。

サブスクリプションの自動更新では、配布元の内容が再取得されるため、その中のルールをローカルで直接編集しても変更が保持されないことがあります。個人設定はクライアントが対応する上書き機能やマージ機能に置き、適用順序も確認しておくと安心です。設定一覧を全体置換するのか追加するのか、同名項目をどう扱うのかは、クライアントによって異なります。変更後は実行設定を確認し、既存のプロキシグループが意図せず削除されていないか、ルールがすべて最後のマッチに置き換わっていないか確認してください。

初回のインポートや更新方法はサブスクリプションの追加手順を参照してください。互換性の問題が起きた場合は、まずプロバイダーからmihomo向けと明記された形式を入手し、元の内容と実行設定の違いを確認します。ファイルの拡張子だけを変えたり、ノード形式の名前だけを書き換えたり、エンコードとデコードを繰り返したりしても、失われたプロトコル設定は復元できません。

8. 用途に応じた選び方と検証

デスクトップ、モバイル、サーバーで条件を分けて考える

デスクトップで普段使いする場合は、互換性とメンテナンス性を優先しましょう。安定して使えているSS、VMess、Trojanのノードがあれば、プロトコルを変えることだけを目的に移行する必要はありません。VLESSの特定の組み合わせが必要な場合は、mihomoとサーバー側の設定が一致しているか確認してください。クライアントは、ダウンロードページで最初に紹介されているClash Plusから試すか、用途に応じてClash Verge Rev、FlClashなどを選べます。デスクトップ端末は比較的リソースに余裕がありますが、システムプロキシ、ブラウザー拡張、ターミナルの環境変数は別々に動作する場合があります。それぞれ確認してください。

モバイル端末では、バックグラウンドからの復帰やネットワーク切り替え後の動作を優先して確認します。まず検証済みの安定したノードを1つ確保し、現在のモバイル回線でHysteria2やTUICが有効か比較してください。プロトコル、速度測定の頻度、TUNモードを同時に変更すると、電池消費の変化を判断しにくくなります。Androidでは端末のアーキテクチャに合うクライアントをダウンロードページから選べます。iOSはクライアントの配布方法やOSのネットワーク拡張の仕組みが異なるため、Clash Plusを使う場合は実際に対応しているインポート形式と機能を確認してください。デスクトップ版mihomoの設定をすべてそのまま適用できるとは限りません。

サーバーやルーターでは、アーキテクチャ、常時稼働、外部への公開範囲を重視します。カーネルを選ぶ前に、CPUアーキテクチャ、OS、実行環境を確認し、専用の実行ディレクトリと永続化の設定を用意してください。外部制御APIを信頼できないネットワークに直接公開してはいけません。ローカルのプロキシポート、制御API、リモートサーバーの待ち受けポートは分けて管理します。GUIのない環境への導入は、LinuxのGUIクライアントとコマンドラインサービスの導入を参照してください。まず保守しやすいサービスを構築してから、複雑なルール設定を検討しましょう。

リクエストの経路に沿ってトラブルを切り分ける

まずローカル環境を確認します。カーネルが起動しているか、ポートがほかのアプリに使われていないかを確認し、アプリのリクエストが実際にプロキシへ届いているか調べてください。接続一覧に該当するリクエストがない場合は、システムプロキシ、アプリの設定、TUNのルーティングを確認します。リクエストはあるのに違うノードが選ばれている場合は、モード、ルール、プロキシグループを確認してください。正しいノードが選ばれても接続できない場合に、認証、TLS、リモート接続を調べます。この順序なら、受信側の問題をプロトコル非互換と誤認したり、ルールが適用されていない状態で速度測定を繰り返したりするのを防げます。

DNSの問題も分けて確認してください。サーバーのドメインを名前解決できないと、プロキシ接続を確立できません。接続先サイトの名前解決に問題がある場合は、一部のサイトだけ開けないことがあります。偽IPを使うDNSモードでは、アプリが受け取るIPアドレスが接続先サイトの実アドレスではない場合があります。カーネルログも確認し、システムの名前解決結果だけで判断しないでください。DNSを変更した後はキャッシュや既存の接続も考慮し、新しいリクエストが変更後の経路を使っていることを確認してから効果を評価します。

HTTPプロキシの入口を確認するには、ローカル端末から以下のコマンドでテストサイトにアクセスできます。混合ポートを明示的に指定するため、ターミナルがシステムプロキシを参照していないのか、カーネルが転送できないのかを切り分けるのに役立ちます。このコマンドで確認できるのは1回のHTTPリクエストだけで、UDP、ほかのアプリ、すべての振り分けルールを検証するものではありません。ポートを変更した場合はコマンド内のポートも合わせて変更してください。テスト先に接続できない可能性がある場合は、別の正常な接続先でも確認しましょう。

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

設定を増やすより、元に戻せる選択を残す

最終的な設定には、主に使うノード、必要な予備ノード、内容を把握できる振り分けルールを用意します。重要な設定を一度に複数変更せず、変更前の設定を保存してください。改善が確認できたら、似た時間帯や利用条件で再テストしましょう。一度だけ速かったからといって、長期利用に適しているとは言えません。失敗が多い候補は、まずネットワーク条件や設定の違いを調べてから使い続けるか判断します。リソースを消費する高頻度の自動テストに入れたままにする必要はありません。

本ページの選び方をひとことで表すと、まず通信の両端で互換性を確保し、その後、実際の用途に応じてコストを比較することです。候補を選んだら、接続確認の手順に沿ってアプリからアクセスできるか確認してください。システムプロキシを参照しないアプリも通信対象にする場合は、TUNモードの仕組みと権限の確認ポイントを参照してください。プロトコルが定めるのはクライアントとサーバー間の通信方法です。ローカルの接続入口、DNS、ルール、OSの権限の代わりにはなりません。