プロキシプロトコルとコアの解説

コアの系統と設定の境界

クライアント、コア、設定ファイル

GUIクライアントは、サービスのインストール、設定のインポート、プロキシグループの表示、システム権限の取得を担います。コアはルールの解析、出力接続の確立、DNS処理、データ転送を担います。画面にスイッチがあっても、実行中のコアが関連機能すべてに対応しているとは限りません。プロトコルが利用できるか判断するには、クライアントの説明、コアの識別情報、設定の読み込み結果を併せて確認します。アプリ名だけを比べると、画面上の機能とネットワーク機能を混同しがちです。

オリジナル版Clashは、ルール、プロキシ、プロキシグループなどの設定構造を確立し、多くのクライアントがそのフィールドを引き継いでいます。Meta系統ではこの仕組みを拡張してプロトコルやネットワーク機能を追加し、その後mihomoの名称で開発が続いています。資料でClash Metaとmihomoが指すのは、別々で互換性のない設定体系ではなく、同じ発展系統であることが一般的です。ただし、名称が変わっても過去の設定をすべてそのまま移行できるわけではありません。フィールドごとに確認が必要です。

互換性はフィールド名の類似だけでは判断できない

オリジナル版の基本ルールや一部のプロキシタイプは比較的移行しやすい一方、Metaで追加されたプロトコル、DNSオプション、トランスポート設定がオリジナル版でも使えるとは限りません。古いクライアントは旧バージョンのmihomoコアを同梱していることもあるため、「mihomoベース」は確認の第一歩にすぎません。未知のプロキシタイプ、暗号化方式、非対応のトランスポート設定が見つかったら、ノードのパスワードを何度も変えるのではなく、実際のコアの対応状況を確認してください。

互換性には、構文を読み込めるかと、意図した動作になるかの2つの段階があります。設定が読み込めたことは、パーサーが内容を受け付けたというだけです。クライアントがフィールドを上書きすれば、最終的な動作は異なる場合があります。たとえば、サブスクリプションにDNS設定があっても、クライアントが全体のDNS設定で上書きすることがあります。また、ファイルでTUNを無効にしていても、画面上の独立した設定で有効になる場合があります。2台のデバイスを比較するときは、ダウンロードした元ファイルだけでなく、最終的に適用された設定とログを確認してください。

アップグレード・移行時の確認手順

移行時はまず元の設定をコピーして保管し、動作確認済みの設定を1つだけインポートします。読み込みを確認したら、手動選択のプロキシグループで接続を検証し、その後ルールセット、自動選択、DNS、TUNを一つずつ戻します。こうすれば、プロトコルの非対応、設定参照の欠落、システムルーティングの問題を切り分けられます。上書き設定や複数のリモートリソースを一度に追加すると、どれか一つの失敗も「クライアントが使えない」と見えてしまい、原因を特定しにくくなります。

クライアントとコアには、パッケージ化や実行環境の依存関係もあります。実行ファイルをアプリのディレクトリに無造作に置き換えると、起動パラメーター、権限サービス、プロセス管理の前提を壊す可能性があります。まずはクライアントが提供する更新方法を使ってください。コアを手動管理する必要がある場合は、設定パス、作業ディレクトリ、ログの保存先を把握してから行います。サーバー上でコアを単独運用する方法と、デスクトップでGUIクライアントを使う方法は、保守の手順が異なります。操作をそのまま流用しないでください。

Clash Plus、Clash Verge Rev、FlClashを選ぶときは、まずOSの対応状況と設定管理の使い勝手を確認し、次に必要なプロトコルが現在のビルドで使えるかを調べます。アーカイブされたClash for WindowsやClashX Metaは、過去の設定の出所を確認する際には役立ちますが、古いガイドで使われているという理由だけで新しいデバイスの標準選択にする必要はありません。オープンソースライセンスも対象を分けて確認してください。mihomoコアがGPL-3.0を採用していても、周辺アプリすべてが同じライセンスとは限りません。

SSとVMess：暗号化とカプセル化

軽量な構造のShadowsocks

ShadowsocksはSSと略され、事前に共有した鍵と暗号化方式でプロキシ通信を運ぶ仕組みです。基本形では、さらにTLSで包む必要はありません。接続経路が比較的シンプルで、導入例やクライアントの対応も幅広くあります。ここでいう「軽量」はプロトコル構造を指し、どのSSノードでも他のプロトコルより速いという意味ではありません。サーバー回線が混雑していたり、デバイスの暗号化性能が低かったりすれば、ヘッダーが小さくてもボトルネックは解消されません。

SSを設定するときは、暗号化方式をサーバーの設定と完全に一致させてください。従来のAEAD方式とShadowsocks 2022系は、方式名を変更するだけで相互に切り替えられるものではありません。後者は鍵の形式と長さに明確な要件があります。サーバーから提供された鍵は設定一式として保管し、指定のエンコード形式が求められるフィールドに一般的なパスワードを適当に入力しないでください。認証に失敗したら、ローカルのセキュリティ設定を弱めるのではなく、方式、鍵、ポートを確認します。

SSではTCPとUDPの転送可否をそれぞれ確認する必要があります。Webページが開けても、リアルタイム音声通話などのUDPアプリがそのノード経由で使えるとは限りません。サーバー、ファイアウォール、クライアントの出力設定がUDPに影響する場合があります。プラグインを使う設定では、クライアントとコアがそのプラグインやオプションに対応しているかも確認してください。プラグイン付きのSSは基本形とは接続条件が異なるため、テストではプラグインによるハンドシェイクやカプセル化のコストも個別に考慮します。

VMessの認証とトランスポートの組み合わせ

VMessはV2Rayのプロトコル体系に属し、ユーザー識別、セッション認証、データ転送をプロトコル内部で扱います。現在の設定では、サーバーが対応するAEAD方式を使用してください。古い資料にある過去の認証オプションをそのまま使うのは避けましょう。ユーザーID、暗号化設定、システム時刻が接続に影響することがあります。特に端末の時刻が大きくずれている場合は、まず時刻を修正してください。認証エラーをすべて回線品質の問題と決めつけても、何度速度を測っても誤ったIDは直りません。

VMessは複数のトランスポート方式と組み合わせられます。TCPを直接使う設定と、WebSocketなど対応するトランスポートを外側に使う設定では、ハンドシェイクの経路や中継設備の要件が異なります。WebSocketでは、パス、リクエストのホスト名、TLSのサーバー名がそれぞれ別の役割を持ちます。ある設定で偶然同じ値でも、同一のフィールドとは限りません。いずれかが欠けると、ポートには接続できてもプロキシ要求が失敗することがあります。

利用条件と比較方法

保守されていて設定内容が明確なSSサービスをすでに使っているなら、プロトコル名が古いという理由だけで乗り換える必要はありません。既存のサービスがVMessを採用し、特定のトランスポートに依存している場合も、まずクライアントとサーバーの設定を一致させてください。選ぶ際に確認すべきなのは、安定して接続できるか、UDPが必要か、設定を保守しやすいかです。プロトコル名を古い順・新しい順に並べて性能を評価することではありません。

この2種類を比較するときは、できるだけ同じデバイス、近い場所のサーバー、同じアプリのリクエストを使います。プロトコルまたはトランスポートの変数を一度に1つだけ変更し、初回接続、連続したブラウジング、長時間接続の状態をそれぞれ記録してください。設定ごとに異なる回線を使うと、測定結果には経路全体の差が表れ、SSとVMessの違いとは断定できません。1回の速度測定のスクリーンショットだけで、プロトコルの効率を結論づけないでください。

古いサブスクリプションを移行するときは、クライアント上で似た名前が別のラベルとして表示される場合にも注意してください。判断材料はノードの「高速」「専用回線」といった備考ではなく、最終設定にあるプロキシタイプとパラメーターです。特定のプロキシだけが失敗する場合は、手動で選択してログを確認します。プロキシグループが自動で別のプロキシに切り替わっていれば、Webページが開けても元のプロキシが復旧した証拠にはなりません。

TrojanとVLESS：TLSと認証

TrojanのTLSの基礎

TrojanはTLSを安全なトランスポートの基盤として使い、暗号化された接続内でプロキシ要求と認証情報を送ります。クライアントには通常、サーバーアドレス、ポート、パスワード、正しいサーバー名が必要です。TLSは通信を保護して接続先の身元を検証し、Trojanのパスワードはサービスの利用を認証します。両者は代わりにはなりません。そのため、パスワードが正しくても証明書の検証に失敗すれば、接続が正しく確立したとはいえません。

サーバー名は、TLSハンドシェイクでの名前交渉と証明書検証に使われます。接続先はドメイン名でもIPアドレスでも構いませんが、証明書に記載された名前は設定の想定と一致している必要があります。ドメインの名前解決結果が変わっても、証明書名を自由に変えてよいわけではありません。ログに証明書の期限切れ、名前の不一致、信頼チェーンの異常が出た場合は、システム時刻、サーバー証明書、設定を確認してください。証明書検証を無効にすることを常用の解決策にしないでください。

Trojanにも異なるトランスポートの組み合わせや実装拡張があり、ノードにTrojanと表示されているだけで、すべてのフィールドが同じとは限りません。基本的なTLS接続と、追加のトランスポートでカプセル化した接続では、パス、ホスト名、中継サービスの要件が異なる場合があります。設定をインポートしてハンドシェイクだけ成功し、リクエストを送れない場合は、サーバーのトランスポート方式と、サブスクリプション変換時に関連オプションが保持されたかを確認してください。

VLESSは安全性を外側の仕組みに委ねる

VLESSは認証とリクエストのカプセル化を簡素化する設計で、単独では独立した暗号化トランスポートと同等の保護を提供しません。通常はTLSやREALITYなどと組み合わせて使用します。ここでいう「簡素化」は、通信の安全性を無視してよいという意味ではありません。クライアントのユーザーIDは認証要素の一つにすぎず、外側のセキュリティ方式、トランスポート、サーバー設定をすべて一致させる必要があります。別の設定からユーザーIDだけをコピーしても、通常は接続できません。

REALITYと一般的なTLS設定では検証条件が異なり、公開鍵、Short ID、サーバー名などのパラメーターが関係します。これらはサービス提供者から取得する必要があり、ドメイン名やユーザーIDから推測することはできません。VLESS設定によっては特定のフロー制御方式も使われます。フロー制御フィールドは外側のセキュリティ方式やトランスポートの組み合わせに依存します。すべてのトランスポートに同じ値を設定できるわけではなく、むやみに追加するとサーバーとクライアントの解釈が食い違います。

追加のハンドシェイクをどう考えるか

TLSでは通常、接続確立時の通信や処理が増えますが、TLSを使うプロトコルがあらゆる状況で遅くなるわけではありません。接続の再利用、セッション再開、サーバーの処理能力、リクエスト数によって実際の体感は変わります。逆に、カプセル化の層が少なくても、初回ページ表示が速いとは限りません。DNS名前解決、アプリ自身の接続、接続先の応答により多くの時間がかかる場合もあります。設定項目の数ではなく、リクエスト経路全体で遅延を考えましょう。

普段使いでは、サーバー側の設定が明確なTrojanを提供されていて、デバイスの証明書環境が整っていれば、TLSのエラー種類に沿って比較的切り分けやすいでしょう。VLESSをすでに使っている場合は、現在のコアがセキュリティ方式とトランスポート設定に対応しているかを重点的に確認します。環境を問わず優先される一方のプロトコルはありません。名称上の軽さや新しさより、安定した構成、明確な設定情報、継続的に更新できるクライアントが重要です。

デスクトップでは使えてモバイルでは使えない場合、すぐにスマートフォンの性能のせいにせず、最終的な設定を比較してください。モバイルでのサブスクリプション変換時にセキュリティ拡張が失われたり、システム時刻や証明書環境が異なったりする場合があります。両方で同じ対応済みの設定を使い、自動切り替えの影響を止め、同じプロキシが選択されていることを確認します。その後、名前解決、ハンドシェイク、認証、リクエスト転送の順に調べれば、プロトコルの差とプラットフォームの差を切り分けられます。

Hysteria2とTUIC：QUICトランスポート

UDPとQUICを使う理由

Hysteria2とTUICはいずれもUDPベースのQUICをプロキシ通信に利用しますが、別々のプロトコルであり、認証フィールドを共用してそのまま置き換えることはできません。QUICは信頼性のある転送、輻輳制御、安全なハンドシェイクなどをユーザー空間で実装し、1つの接続で複数のストリームを扱えます。トランスポート層で順序どおりに配信することによるストリーム間の一部のブロッキングは軽減されますが、各ストリーム内では引き続きパケット損失やデータ順序への対応が必要です。

この構造は、往復遅延が大きい経路やパケットロスのある経路で有利になる場合があります。ただし、ネットワーク上でUDPを安定して通せることが前提です。経路でUDPが制限されていたり、NATマッピングが不安定だったり、対象の通信に厳しい帯域制限があったりすると、接続に失敗するか、TCPより不安定になる可能性があります。QUICだから速いと決めつけず、まず基本的な到達性を確認し、長時間の転送で損失回復や帯域共有の公平性を観察してください。

Hysteria2の帯域幅と輻輳制御

Hysteria2は、条件のよくないネットワークでの転送効率を重視して設計されています。設定には帯域幅のヒント、認証、TLS、任意の難読化が含まれる場合があります。帯域幅の値は速度を上げるスイッチでも、購入プランの公称速度でもありません。ローカルの上り・下り速度と経路の実効性能を踏まえて判断してください。過大な値を設定すると、キューやパケットロスが増え、同じネットワークを使う他のアプリにも影響する可能性があります。サーバー側で利用可能な転送方式が制限されていることもあります。

帯域幅パラメーターを設定する前に、使用中の実装における単位と既定動作の説明を確認してください。画面の入力値をコアのフィールドへ変換する方法は、クライアントによって異なる場合があります。まずサービス提供者の妥当な設定を使い、必要があれば条件を絞って調整します。難読化用パスワードと認証用パスワードは役割が異なり、互いに使い回せません。難読化を有効にする場合は、サーバー側にも対応する設定が必要です。HysteriaとHysteria2は別世代のプロトコルであり、名前が似ていても設定をそのまま流用できるとは限りません。

TUICのセッションと転送設定

TUICもQUICベースで、一般的な設定にはユーザーID、パスワード、TLSのサーバー名、アプリケーション層プロトコルのネゴシエーションが含まれます。輻輳制御、UDP転送モード、接続維持の設定は、リソース消費や互換性に影響しますが、サーバーの対応が前提です。特に、別のコア用の設定フィールドをmihomoへそのままコピーしないでください。同じ概念でも実装によって名前、既定値、対応範囲が異なる場合があるため、使用先の形式に合わせて変換する必要があります。

モバイルネットワークと接続の移行

QUICには接続移行を支援する仕組みがありますが、Wi-Fiとモバイル通信の切り替え後もプロキシ接続を途切れずに維持できるかは、クライアントの実装、サーバー設定、OSにも左右されます。プロトコルの機能が、そのままアプリの利用体験を保証するわけではありません。ネットワーク切り替え後に一時的な切断が起きたら、再ハンドシェイクの有無、古い接続の終了、アプリによる再試行を確認してください。継続性が重要な作業では、1回のダウンロード測定より実際のネットワーク切り替えテストが大切です。

外側のトランスポートにUDPを使っていても、その中のすべての通信が信頼性のない転送になるわけではありません。ブラウザーの信頼性のあるバイトストリームは引き続き完全な配信が必要です。一方、プロキシ経由で業務UDPを運ぶ場合は、別の転送方式になることがあります。デバッグでは外側のトランスポートと内側の通信を分けて考えてください。外側のUDPが通らなければQUIC接続全体に影響しますが、特定の通信だけが失敗する場合は、サーバー権限、宛先の制限、ルール選択なども原因になり得ます。

モバイルで長時間使う予定なら、待機中、バックグラウンド、電波が弱い状態でもテストしてください。頻繁なキープアライブはNATマッピングを維持できる一方、デバイスの復帰や無線通信の稼働時間を増やす可能性があります。接続を早く切りすぎると再接続が増えます。すべてのデバイスに適した固定パラメーターはありません。比較用に検証済みのTCP系出力を1つ残しておけば、ネットワークが変わったときにUDP経路の問題かどうかをすぐに判断できます。

接続速度、リソース、モバイルのバッテリー消費

速度は段階ごとに分けて考える

「速さ」には少なくとも、名前解決、初回接続、リクエスト応答、継続的なスループットの4つの要素があります。クライアントに表示される遅延テストは、通常、指定した方法で1回の測定を行うもので、すべてのWebサイトの読み込み時間と同じではありません。小さなファイルの閲覧では往復遅延とハンドシェイクが、大容量のダウンロードでは帯域、パケットロスからの回復、輻輳がより大きく影響します。2つのプロキシで優れる指標が異なることもあるため、1つの数値だけですべての用途を決めるのは適切ではありません。

リソース使用量もプロトコル名だけで決まるものではありません。暗号化の実装、ハードウェア命令への対応、同時接続数、パケットサイズ、ログレベルによってCPU負荷は変わります。短時間の接続が大量にある場合、ハンドシェイクや状態管理に処理時間が取られます。大容量通信を続けると、暗号化、データコピー、ネットワークスタックのコストが表れやすくなります。同じプロトコルでもPCと低消費電力のスマートフォンで結果が異なるのは、プロトコル設計だけでなく、デバイスや実装の違いも影響しています。

バッテリー消費の主な要因

モバイルでのバッテリー消費は、CPUと無線ネットワークの状態の両方に左右されます。電波が弱い、頻繁に復帰する、短い間隔でハートビートを送る、接続を何度も再確立する、複数のアプリがバックグラウンドで通信するといった状況は、無線通信を稼働状態に保つ要因になります。プロキシの通信量が少なくても、小さなパケットを頻繁に送り続ければ消費電力が増えることがあります。逆に、瞬間的なCPU負荷が高くても転送時間が短縮されれば、総消費電力は高くならない場合があります。そのため、「CPU使用率が低い」ことをそのまま「省電力」とは判断できません。

TUN、DNS、ルールセット、プロキシグループのプローブも、クライアント全体のコストに含まれます。数十個のプロキシを短い間隔で自動測定すると、接続の維持にかかる負担がプロトコル自体のコストに加わります。モバイルでは、まず不要な測定頻度やバックグラウンドタスクを減らしてからプロトコルを比較すると、より有意義です。調査のため一時的にログの詳細度を上げた場合は、問題を再現したあとに通常のレベルへ戻してください。大量のログ書き込みや画面更新を、プロトコル固有のコストとして数えないようにします。

再現性のある比較テストを行う

テストでは、デバイス、場所、接続ネットワーク、接続先、利用内容を固定し、できるだけ近い時間帯に2つの設定を交互に試します。まず軽いリクエスト、次に継続的な転送、最後に実際のアプリをテストしてください。変更する変数は毎回1つにします。たとえば、プロトコルだけを変更するか、DNS方式だけを変更します。比較中にTUNを有効化し、ルールセットを入れ替え、省電力モードまで調整してしまうと、体感が改善しても何が効いたのか分からなくなります。

バッテリー消費を比べる際も、画面の明るさ、電波強度、バックグラウンドアプリを近い条件にし、ある程度長い実使用時間で観察してください。アプリのインストール直後の初回起動、システムのインデックス作成、一斉同期などは、短期的な変動を引き起こすことがあります。OSのバッテリー統計は傾向を把握する助けにはなりますが、プロトコルごとの絶対的な消費電力を直接算出できるものではありません。バックグラウンドでクライアントの接続が繰り返し終了される場合は、キープアライブを調整する前に、バックグラウンド権限と省電力制限を確認してください。

自動選択は通信品質の評価ではない

自動測定を行うプロキシグループは、特定の測定先とルールに基づいてプロキシを選びます。測定先に接続できても、実際のサービスが使えるとは限りません。切り替え間隔が短すぎると、近い測定結果で選択が頻繁に変わり、長時間接続を妨げるほか、測定リクエストも増えます。原因調査中は手動選択に切り替えて、接続の実際の状態を確認してください。安定したら自動選択に戻し、実用的な許容差と間隔を設定して、効果のない切り替えを抑えます。

Web閲覧は問題ないのに動画が止まる場合は、まず対象の接続が実際にどの出力を使ったかを確認し、継続的なスループット不足、サーバー側の制限、アプリのキャッシュ問題を切り分けます。ダウンロードは速いのにページ表示が遅い場合は、名前解決と短時間接続のハンドシェイクを調べます。ネットワーク切り替え時だけ失敗する場合は、接続の再確立とシステムルートの復旧を確認してください。症状ごとに分けて調べれば、プロトコル比較の目的が明確になります。プロトコル名を次々と変えるだけでは、本当のボトルネックを見逃しがちです。

初回接続の確認手順は、ノード選択、遅延測定、プロキシの動作確認も参考にしてください。結論は実際に試した条件の範囲に限られます。あるデバイスとネットワークで適したプロトコルが、すべてのプラットフォームでも同じように優れているとは限りません。長く使ううえでは、安定して再現でき、管理しやすく、アプリの要件を満たすことが信頼できる選択基準です。

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

サブスクリプションは取得方法であり、統一形式ではない

サブスクリプションURLは、リモートのコンテンツを取得するためのアドレスです。返される内容は、完全なYAML設定、ノードリンクの一覧、特定クライアント向けの形式など、さまざまです。ブラウザーでURLを開けるのはリクエストに応答があったことを示すだけで、内容がmihomoに適しているとは限りません。ログイン画面、期限切れの案内、別の構造のデータが返されると、クライアントで解析に失敗する場合があります。確認する際はコンテンツの種類とエラー概要を見てください。認証情報を含むURL全体を公開して送らないでください。

完全な設定には、通常、プロキシ、プロキシグループ、ルールが含まれ、リモートのルールセットやプロキシプロバイダーを参照する場合もあります。ノード一覧は主に出力接続を記述するもので、トラフィックの振り分け方法までは指定しないことがあります。インポート後にノードだけが表示され、想定したプロキシグループがない場合は、ノードが失われたのではなく、サブスクリプション形式が異なる可能性があります。proxy-providersを使う場合、メイン設定からプロバイダーを正しく参照する必要があります。リモートの内容を取得できても、プロキシグループがその中のプロキシを使っているとは限りません。

変換でプロトコルの意味が失われることがある

設定ファイルの拡張子をYAMLに変えるだけでは、異なるエコシステム間の設定は変換できません。ユーザー認証、トランスポート経路、TLSのサーバー名、フロー制御、プロトコル拡張を一つずつ対応付ける必要があり、変換先のコアもそれらの機能に対応していなければなりません。基本的なプロトコルしか認識しない変換ツールでは、サーバーアドレスを残したまま追加フィールドを破棄し、「ノードはあるが接続できない」状態になることがあります。新しいプロトコルや複雑なトランスポートの組み合わせは、特に変換元の設定と変換結果を確認してください。

完全な設定と部分的な上書き設定の優先順位も重要です。サブスクリプションの更新でリモートファイルが置き換わる場合があり、キャッシュ内容を直接編集しても変更が維持されないことがあります。ルールを追加する場合は、クライアントの上書き・マージ機能を優先し、サブスクリプション更新後も適用されることを確認してください。全体の上書き、個別設定の上書き、コアの既定値が同時に存在するなら、最終的な優先順位を把握します。更新のたびに異なる設定でテストする事態を避けましょう。

自動更新を有効にする前に構造を確認する

初めてインポートしたら、まず設定の名前と取得元を確認し、次にプロキシタイプ、プロキシグループの参照、ルールが揃っているかを調べます。プロキシを手動選択して接続を検証してから、更新間隔と自動選択を設定してください。更新に失敗する場合は、アドレスの名前解決、リクエスト接続、応答内容、設定の解析という4段階に分けて調べます。古い設定で接続できるなら、再インポートのために唯一使える設定や診断情報を削除せず、先に保管してください。

更新経路が現在のプロキシに依存している場合もあります。たとえば、リモートプロバイダーの取得にあるプロキシグループを使い、そのグループがまだ更新されていないプロキシ一覧に依存していると、起動時に依存関係の問題が起きることがあります。リソースを初めて読み込むときに利用できる出力と、使用可能なキャッシュの有無を確認してください。画面の更新ボタンが回り続けているからといって、コアの故障だと決めつけないでください。メインのサブスクリプション、プロキシプロバイダー、ルールプロバイダーのどれが失敗したかによって対処は異なります。

以下の例は基本的な実行オプションのみを示しています。有効な出力、プロキシグループ、ルールを含む設定に追加して使用してください。完全なサブスクリプションではなく、リモートプロキシを作成するものでもありません。デバッグ時は、実行モードとログレベルを明示しておくと、画面の設定とファイル内容の食い違いを減らせます。クライアントがこれらのフィールドを上書きする場合は、最終的に適用された設定が基準です。

mode: rule
log-level: info
allow-lan: false
ipv6: false

複数設定の管理と復元

複数の設定を使うと、異なる取得元やテスト方法を分けて管理できますが、一度に有効にするのは内容が明確な1つにしてください。プロキシグループの前回の選択状態がクライアントに保存される場合があるため、設定を切り替えても想定したプロキシが自動選択されるとは限りません。テストのたびに、現在の設定、モード、選択中の出力を確認してください。プロトコルを移行する場合は、用途が分かる名前を付けると、すべてのノードを混在させるより比較や復元が簡単になります。

更新に成功したあとも、実際の動作を確認してください。新しいルールでアプリの出力先が変わったり、ノード名の変更で既存のプロキシ選択が無効になったり、リモートリソースの参照先が変わったりすることがあります。復元可能なコピーを保管し、クライアントで過去の設定に戻せるか確認してください。ファイル、リンク、更新の関係はProfileと複数設定の管理を、よくある更新エラーはFAQをご覧ください。

DNS、TUN、トラフィックの入口

プロキシ出力を設定しても、アプリの通信が入るとは限らない

プロキシプロトコルが扱うのはクライアントからサーバーまでの通信方法で、システムプロキシとTUNが扱うのはアプリの通信をクライアントに取り込む方法です。これは別のレイヤーです。システムプロキシは、アプリがOSのプロキシ設定に従うことを前提とするため、無視するアプリもあります。TUNは仮想ネットワークインターフェースとルーティングを使い、より広い範囲の通信を取り込みます。アプリが直接接続している場合も、ノードのプロトコルが非対応なのではなく、そのアプリの通信がコアを通っていない可能性があります。

同様に、TUNを有効にしてもすべての通信が必ずリモートプロキシを使うわけではありません。コアに入った後もルール判定が行われ、直接接続のルールに一致したリクエストは直結します。確認時は入口、ルール、出力を分けて調べてください。まず接続ログを探し、次に一致したルールとプロキシグループを確認し、最後に具体的なプロキシを調べます。対象アプリの接続記録がまったくない場合は、リモートプロトコルの認証設定を変えるのではなく、入口と権限の問題から対処してください。

Fake-IPと実際のアドレス解決

Fake-IPモードは、ドメイン名に仮想アドレスを返し、ドメインと接続の対応関係を保つことで、コアが後から通信を処理する際に宛先の名前を把握できるようにします。これはリモートプロキシサーバーではなく、出力ルールを自動的に変えるものでもありません。redir-hostは実際の解決結果を返す方式に近く、ドメインの識別、キャッシュ、アプリとの互換性に与える影響は異なります。名称だけで決めず、アプリの動作と現在のルール要件に合わせて選んでください。

デバイス検出、LANサービス、特定のアプリなどでは実際の名前解決結果が必要になる場合があり、その場合はfake-ip-filterで対象を個別に除外できます。すべてのドメインを除外すると、Fake-IPを使う本来の目的が損なわれるため避けてください。モードを変更したあとも、OS、ブラウザー、アプリに古いキャッシュが残ることがあります。実際の状況に応じてキャッシュを消去するか、関連アプリを再起動し、新旧の解決結果が混在して誤判断につながらないようにします。

名前解決の経路と起動時の依存関係

プロキシサーバーへの接続にもDNSが必要な場合があります。サーバーアドレスの名前解決に、まだ確立していないプロキシを先に通す必要があると、起動時に依存関係の問題が発生します。暗号化DNSの上流サーバー名、プロキシノードのドメイン名、通常の通信先ドメイン名は、それぞれ別の設定で処理されることもあります。調査時は、どのレイヤーのドメイン名で失敗したかを特定し、該当する名前解決経路を確認してください。すべてのDNS問題を1つのDNSスイッチのせいにしないでください。

IPv6も独立して確認すべき項目です。OSがIPv6を優先していても、プロキシの入口、ルール、接続先が十分に対応していない場合、一部のサイトで待ち時間やフォールバックが発生することがあります。IPv6関連の設定を無効にすると問題の切り分けに役立つことはありますが、すべての環境で恒久的な解決策になるわけではありません。実際に使われるアドレスファミリーをテストできるよう、OSのアドレス、ルート、DNS応答、プロキシサーバーの対応状況が揃っているかを確認してください。

ルールの順序とプラットフォームによる違い

ルールは通常、上から順番に評価され、最初に一致した項目の方針が適用されます。ノードをテストするときは、より上の直接接続ルールにリクエストが先に一致していないか確認してください。プロセス、ドメイン、アドレスに関するルールは、それぞれ必要とする情報が異なります。プラットフォームによっては取得できるプロセス情報も限られます。ドメインがまだ識別されていない、名前解決経路が変わった、接続がキャッシュされているといった状況では、観察結果が想定と異なる場合があります。ルールを2つ入れ替えただけで問題が解決したと決めつけないでください。

デスクトップでTUNを有効にするには、サービス権限、仮想ネットワークインターフェース、ルーティングの設定が必要な場合があります。モバイルでは通常、OSのVPN権限を取得する必要があり、バックグラウンド管理の影響も受けます。複数のネットワークツールを同時に動かすと、システムプロキシ、DNS、デフォルトルートを取り合うこともあります。テスト時は通信を取り込むツールを一時的に1つだけにし、既存の設定を記録したうえで一つずつ戻してください。Windowsストアアプリ特有のループバック問題は、UWPループバックの免除方法を参照してください。

こうした入口や名前解決の要因があると、プロトコルを切り替えた後に一時的に直ったように見えることがあります。切り替え操作によって接続が再確立されたり、キャッシュが更新されたり、ネットワークスタックが再起動されたりした可能性があり、プロトコル自体がDNSを修復したとは限りません。信頼できる結論を得るには、プロトコルを変えずに関連設定だけを個別に再読み込みし、同じ変化を再現できるか観察してください。レイヤーを分けて考えることで、ノード、ルール、名前解決、システム権限のどこを変更すべきか判断できます。

用途別の選び方と段階的なトラブル対処

条件から候補を絞り込む

デスクトップでの日常的なブラウジングでは、設定が揃っていて安定し、保守しやすい出力を優先してください。すでに使えるSS、VMess、Trojanのサービスがあるなら、新しい名称を追うだけのために移行する必要はありません。特定のVLESSセキュリティ構成が必要な場合は、現在のコアとサブスクリプションの変換経路が対応しているかを先に確認します。GUIクライアントはClash Plusから検討し、OSの対応状況、設定管理、実際に必要な機能に応じて、ダウンロードページに掲載された他のクライアントと比較してください。

通勤中にモバイルで使う場合は、ネットワーク切り替え、バックグラウンド動作、バッテリー消費を併せて考えます。普段使うWi-Fiとモバイル通信の両方で安定して接続できる設定を選び、待機中や再接続時の動作を確認してください。現在のネットワークでUDPが不安定なら、Hysteria2やTUICだけを唯一の候補にするのは避けましょう。遅延やパケットロスが大きく、UDPが安定している場合は、比較対象に加えるとよいでしょう。短時間の測定だけでなく、普段の移動経路で実際に使うアプリを試して判断してください。

大容量ファイルの転送では、継続的なスループット、サーバー側の上限、ネットワーク共有時の影響を確認します。リアルタイム音声通話では、ジッター、パケットロス、業務UDPが実際に使えるかがより重要です。サーバーやルーターでは、CPUアーキテクチャ、メモリー、ログの保存、サービスの自動起動も考慮する必要があり、mihomoコアを直接管理する方が適していることが多いでしょう。デスクトップGUIクライアントの便利なオプションが、単独運用のコアにもあるとは限りません。導入前に、誰が設定を生成し、サービスを復旧するのかを明確にしてください。

接続段階に沿って障害範囲を絞り込む

最初に設定が読み込まれているか確認します。未知のフィールド、誤ったプロキシタイプ、存在しないプロキシグループ参照が見つかった場合は、まず設定構造を修正してください。この段階ではまだネットワーク接続に進んでいません。次に、サーバーアドレスを名前解決できるか、接続先ポートに該当するトランスポートで到達できるかを確認します。TCPポートへの接続に成功しても、UDPが使えるとは限らず、TLS、プロトコル認証、実際のプロキシリクエストが成功した証拠にもなりません。さらに先の段階まで確認が必要です。

第3段階では、安全なハンドシェイクと認証を確認します。証明書エラーでは時刻、名前、信頼チェーンを、認証エラーではパスワード、ユーザーID、鍵の形式、プロトコルの世代を調べます。第4段階では実際の通信転送を確認します。リクエストに適用されたルール、プロキシグループ、最終的な出力を見て、すべての接続先で失敗するのか、特定の接続先だけなのかを切り分けてください。一部の通信だけに問題がある場合は、DNS、アドレスファミリー、サーバー権限、対象アプリの特性を検討します。すべての設定を最初から入れ替える必要はありません。

最小構成で再現し、復元手段を確保する

調査中は、復元できる設定を1つ、手動選択のプロキシグループを1つ、対象を明確にした接続先を1つ使い、自動選択や複雑な上書き設定は一時的に減らしてください。変更内容と結果を記録すれば、失敗したときに前の状態へ戻せます。デバッグログは原因となった段階の特定に役立ちますが、共有前にサブスクリプションURL、認証情報、機密性の高い接続先を削除してください。公開する際は、クライアント名、コアの識別情報、OS、プロトコルタイプ、エラーの種類があれば、初期判断に役立ちます。

2種類のプロトコルが同じタイミングで遅くなった場合は、まずローカルのネットワーク、サーバーの状態、共通の依存先を確認します。一方だけが失敗する場合は、そのプロトコル固有のトランスポート要件と認証要件を比較してください。同じ設定が別のデバイスで正常に動作するなら、まず端末の時刻、証明書、権限、最終的に適用された設定を調べます。接続ネットワークを変えて復旧した場合は、元の経路の条件を重点的に確認してください。こうした交差検証は、サブスクリプションを何度も更新するより原因を説明しやすくします。

調整後は、Webページを1つ開くだけで検証を終わらせないでください。普段使うアプリ、業務UDP、スリープからの復帰、ネットワーク切り替えを再確認し、システムプロキシやTUNを無効にした後もネットワークが想定どおりの状態に戻るか確認します。最後に、適切なログレベル、更新間隔、自動選択を設定し、テスト用の設定を削除してください。長期的な運用で目指すのは、設定項目を増やすことではなく、各設定の目的を説明でき、問題発生時にどのレイヤーから調べるべきか分かる状態です。