Clashのプロトコルとmihomoコアの解説

1. プロトコルの選び方：クライアント、コア、通信方式を区別する

画面に表示されるプロトコル名が示すのは、接続の一部分です

プロキシ接続は通常、ローカルでの接続受付、ルール判定、プロキシプロトコル、基盤となる通信方式、接続先サーバーという複数の段階で構成されます。ブラウザーからのリクエストはまずローカルポートに渡され、コアがドメイン名やアドレスに基づいてプロキシグループを選び、選択されたノードを使ってサーバーに接続します。プロトコル名が示すのは、主にクライアントとサーバーの間で認証やデータのカプセル化、転送をどう行うかです。出口の帯域幅やサーバーの負荷、接続先サイトの応答速度を直接決めるものではありません。

クライアントはサブスクリプションの管理、画面上の設定、バックグラウンド動作、システムとの連携を担います。コアは設定の解析、接続の確立、DNS処理、ルールの適用を担当します。同じ名前のクライアントでも、常に同じコアを使うとは限らず、異なるクライアントが同じ系統のコアを使うこともあります。利用できるノードを判断するときは、画面の見た目だけでなく、クライアントに含まれるコア、関連する機能の設定場所、サーバー側の要件を確認してください。

プロトコル、通信方式、安全設定を分けて確認する

たとえば、VLESSはプロキシプロトコル、WebSocketは利用される場合がある通信のカプセル化方式、TLSは安全なセッションを確立する仕組みです。サーバー名は証明書の検証やハンドシェイク時の選択に使われます。それぞれ役割が異なります。サブスクリプションでは、これらの項目が1つのノード情報としてまとめられます。ノード名しか見ていないと、違いをすべてプロトコルのせいだと考えがちです。比較する前にノードの詳細を開き、プロトコル、通信方式、接続先ポート、安全設定を確認しましょう。

TCPは信頼性と順序を保証するデータストリームを提供します。UDPはデータグラムを送受信しますが、アプリケーションに代わって再送や順序を保証するものではありません。QUICはUDP上で動作し、プロトコル内部で安全な接続、信頼性のあるストリーム、輻輳制御を実現します。ノードがUDPを使うからといって、アプリの通信がすべて信頼性のない転送になるわけではありません。逆に、ノードとの接続にTCPを使っていても、アプリが送るUDPデータグラムの転送に対応しているとは限りません。両者は分けて確認する必要があります。

再現できる条件をそろえて比較する

適切に比較するには、端末、接続ネットワーク、接続先サービス、テスト時間帯をできるだけそろえます。2つのノードが異なる地域や回線にある場合、結果には経路全体の違いが反映され、プロトコルだけの差にはなりません。日常の選定で実験室のような測定は不要ですが、ページの初回表示、連続通信、音声通話、スリープからの復帰はそれぞれ確認しましょう。1つのテストボタンだけで、すべての使い勝手を判断しないことが大切です。

クライアントに表示される遅延は、多くの場合、指定されたURLへの1回のリクエストを測定したものです。名前解決、ハンドシェイク、サーバーの応答など、異なる段階が含まれることがあります。クライアントごとに測定方法が異なるため、数値をそのまま横並びで比較するのは適切ではありません。テストに成功しても、その時点で測定経路が使えたことしか分かりません。接続先アプリでは異なるドメイン名やプロトコル、独自のDNS処理が使われる場合があるため、実際にアプリを開いて確認してください。

このページで扱う設定の可否は、実際のコア実装によって決まります。サーバーが対応するプロトコルや設定項目はサブスクリプションの提供元が決めるもので、クライアント側だけでSSノードをTUICノードに変更することはできません。別のプロトコルが必要な場合は、サーバーが提供する該当ノードを取得してください。ローカル設定の種類だけを変更しても切り替わりません。以降の比較も、認証情報が正しく、サーバーが稼働し、設定が一致していることを前提とします。

2. ShadowsocksとVMess：軽量な転送とプロトコルの進化

Shadowsocksの特徴はプロトコル構成が比較的シンプルなことです

ShadowsocksはSSとも呼ばれ、暗号化プロキシの転送を目的に設計されています。一般的な設定にはサーバーアドレス、ポート、暗号化方式、パスワードが含まれます。直接利用する場合、各接続に汎用的なWeb通信のカプセル化層を追加する必要がなく、構成は比較的シンプルです。ただし、クライアント側で暗号化、認証、アドレスのカプセル化は必要です。「軽量」だから処理負荷がないわけではなく、どのネットワークでも速いとは限りません。

SSの暗号化方式は、自由に差し替えられる飾りの項目ではありません。従来のストリーム暗号、AEAD方式、新しいShadowsocks 2022系では、実装要件が異なります。方式によっては鍵の形式にも制限があります。ノードの詳細に特定の方式が表示されていても、古いコアで読み込めるとは限りません。暗号化方式が未対応というエラーが出た場合は、慣れた名前に勝手に変更せず、コアの対応状況と元のノード情報を確認してください。

SSは、実装とサーバー設定が対応していればTCP通信を処理でき、UDPを転送することもできます。TCPとUDPではネットワーク上の到達性が異なる場合があります。Webページは表示できるのに通話ができない場合は、UDPの対応状況と許可設定を確認しましょう。プラグインで通信方式を拡張するノードもあり、その場合は追加の依存関係が生じます。ノード情報にはプラグイン名とオプションも含めてください。サーバー、ポート、パスワードだけをコピーすると、接続方式を決める重要な情報が抜けることがあります。

VMessは認証方式と通信方式を合わせて確認する

VMessはV2Rayエコシステムで使われるプロトコルで、ID認証とプロキシデータのカプセル化を行い、さまざまな通信方式と組み合わせられます。認証や安全機構の変更を含めて進化してきたため、同じVMessでも古い設定同士が常に互換性を持つとは限りません。ノードを確認する際は、ユーザーIDだけでなく、通信方式、TLSの有無、パス、リクエストのHostなども確認しましょう。共有リンクの長い文字列だけで、設定全体が分かるわけではありません。

古いVMess設定には、以前の認証手順に関係する項目が含まれていることがあります。現在の設定では一般にAEAD認証方式が使われますが、過去の項目の解釈は実装によって異なる場合があります。移行時に古い解説記事の固定パラメーターをそのまま使ったり、エラーを消すために項目をむやみに追加・削除したりしないでください。端末の時刻が大きくずれていると、認証や証明書の判定にも影響することがあります。アカウント設定を何度も変更する前に、日付、時刻、自動時刻合わせを確認しましょう。

VMessの実際の性能は、外側の通信方式に左右されることがよくあります。TCPを直接使う設定と、WebSocket、TLSなどの中間層を経由する設定では、ハンドシェイク、ヘッダーのカプセル化、接続の再利用方法が異なる場合があります。通信方式の層が異なるノード同士は、プロトコル名が同じでも初回リクエストの時間や連続通信の結果に差が出ます。「VMessノードが遅い」で終わらせず、名前解決、接続、認証、アプリのリクエストのどの段階が遅いかを切り分けましょう。

クライアントで継続利用できるかを確認する

読み込み後、ノードがコアによって除外されていないことを確認し、プロキシグループで選択して、通常のWebページと実際に使うサービスの両方をテストします。クライアントにノードが表示されても接続できない場合は、ログで最初に出たエラーを確認してください。暗号化方式の非対応、認証失敗、接続タイムアウトはそれぞれ別の原因です。1つ目は互換性、2つ目は認証情報や時刻、3つ目はアドレス、ポート、現在のネットワークを重点的に確認します。

安定して使えているSSまたはVMessサービスがあるなら、別のプロトコル名が新しいという理由だけで移行する必要はありません。移行を検討するのは、現在のコアの保守が終了した、必要な通信方式に対応していない、または今の組み合わせで再現性のある問題がある場合です。デスクトップでのWeb閲覧や一般的なダウンロードでは、使い慣れた設定を維持できます。リアルタイム通話ではUDP転送への対応を別途確認し、Webページが表示できるかどうかだけで判断しないでください。

この2種類のプロトコルは、移行時の比較基準にもなります。クライアントを変更したら、まず設定が明確で、以前に動作していたノードを1つ読み込み、ローカル接続とルールの経路が正常であることを確認してから、新しいプロトコルを試します。すべての種類のノードが同時に失敗する場合は、個々のノードを別々に変更するのではなく、設定が有効か、プロキシグループが正しく選択されているか、システムプロキシが機能しているかを優先して確認しましょう。クライアントの接続問題をプロトコルの問題と誤認しにくくなります。

3. TrojanとVLESS：認証、TLS、外側の通信方式

TrojanではTLSセッションが重要な基盤になります

一般的なTrojan実装では、TLS上でプロキシ通信を行い、安全なセッション内でパスワード認証とリクエスト転送を処理します。通常、設定にはサーバー、ポート、パスワード、サーバー名が含まれます。実績のあるTLSの仕組みを利用して通信を保護するため、証明書チェーンの信頼性、名前の一致、端末時刻の正確さが接続に重要です。パスワードが正しいと確認できても、ハンドシェイクの問題は除外できません。

サーバーアドレスとTLSサーバー名は、それぞれ異なる役割を持つ場合があります。前者は接続先を決め、後者は通常、サーバー証明書の選択やクライアント側の名前検証に使われます。アドレスで接続し、ドメイン名で検証する構成もあるため、サブスクリプションでは該当項目を保持する必要があります。移行時にサーバー名が失われると、クライアントが別の名前で証明書を検証し、以前のクライアントでは接続できたのに、新しいクライアントではハンドシェイクに失敗することがあります。こうした差を、プロトコルの速度の問題だと決めつけないでください。

証明書の検証に失敗したら、まずノードが指定する名前、サーバー証明書、システムの信頼設定を確認してください。証明書検証のスキップを通常の対処方法にしてはいけません。検証を省略すると安全性が損なわれ、設定ミスを見逃すおそれもあります。サーバーが独自の信頼設定を必要とする場合は、そのサービスの明確な手順に従い、関係のないノードから設定をコピーしないでください。ログに表示される名前の不一致、証明書の期限切れ、接続タイムアウトもそれぞれ分けて対処します。

VLESSの軽量な認証だけでは、通信全体の安全性は確保できません

VLESSは主にユーザーの識別とプロキシデータのカプセル化を担い、それだけで完全な暗号化通信を実現するものではありません。実際の環境ではTLS、REALITYなどの外側の仕組みと組み合わせることが多く、具体的な構成はサーバー側で決まります。ユーザーID、通信方式、関連する安全設定を確認してください。VLESSという名前だけで特定の保護方式が使われていると判断したり、あらゆるVLESS設定を同じ古いコアが認識できると思ったりするのは正確ではありません。

VLESSの設定にはflowが含まれる場合があり、REALITYとの組み合わせでは公開鍵、short ID、サーバー名も関係することがあります。これらは任意のメモではなく、異なるサーバー間で使い回せるものでもありません。利用できるflowは組み合わせによって異なります。設定の読み込みを通すためにサブスクリプションの項目を削除すると、読み込みは成功しても実際の認証に失敗する可能性があります。確認すべきなのは、プロトコル名だけでなく構成全体が対応しているかどうかです。

WebSocketやgRPCなどの通信方式も、接続の確立方法やデータのカプセル化を変えます。パス、リクエストのHost、サービス名がサーバー側のルーティングと一致しなければ、サーバーに接続できても該当サービスに到達できないことがあります。この場合の症状は、パスワードの誤りとは異なります。サーバーへの到達性、TLSなどの安全なハンドシェイク、通信経路の設定、プロキシ認証の順に確認しましょう。複数の層を同時に変更するのは避けてください。

接続の再利用とUDP対応は、プロトコル名だけでは判断できません

一般的な実装ではTrojanのUDP転送は信頼性のあるバイトストリーム上でカプセル化されます。VLESSでのUDP転送方法も、具体的な設定と実装によって異なります。アプリで通話できるかどうかは、プロトコルの仕様だけでなく、クライアントの転送方法とサーバーの対応状況にも左右されます。信頼性のあるストリーム上でデータグラムを送ると、パケットロス後の再送で待ち行列が生じる場合があります。ただし、リアルタイム用途で常に使えないわけではなく、実際のネットワークで確認が必要です。

接続を再利用すると複数のリクエストで基盤となる接続を共有でき、接続確立を繰り返すコストを抑えられます。一方、障害や輻輳の影響も共有される場合があります。特定の再利用設定にすべてのサーバーが対応しているとは限らず、有効にすれば必ず速くなるわけでもありません。既存のサブスクリプションでは、まず提供元の設定を維持しましょう。再利用の効果を比較するなら、同じノードと用途で1つの設定だけを変更し、短いリクエスト、長時間接続、復帰時の動作を確認してください。

用途を選ぶ際、TrojanはTLS対応サーバーがあり、設定項目の関係が明確な場合に適しています。VLESSでは外側の構成とコアの対応状況をより丁寧に確認する必要があります。サーバーの条件を無視して、どちらが常に優れているとは言えません。クライアントが設定を解析できたと表示しても、実際のリクエストを検証してください。項目の追加が必要な場合は、似たノードの情報を寄せ集めず、サブスクリプションの提供元に元の設定を確認しましょう。

4. Hysteria2とTUIC：QUICの利点と制約

QUICが変えるのは通信の仕組みです

Hysteria2とTUICはどちらもQUICを利用したプロキシ通信です。QUICはUDP上で動作し、安全なハンドシェイク、ストリーム管理、輻輳制御を内部で処理します。複数の通信を1本のTCPデータストリームに単純にまとめる方式と比べ、ストリーム間で順序どおりのデータ到着を待つことによる一部の遅延を抑えられます。ただし、複数のストリームは回線容量や輻輳状態を共有します。各リクエストが独立した帯域幅を持つわけではありません。

あるストリームでデータが失われても、他のストリームは順序どおりの到着を待たずに済む場合があります。これがQUICの多重ストリームを理解する重要なポイントです。一方、ネットワーク全体の輻輳、サーバー出口の飽和、無線回線の品質低下が起きれば、すべてのストリームが影響を受ける可能性があります。QUICがパケットロスをなくすわけではなく、独自の確認応答、再送、輻輳制御で経路の変化に対処します。そのため、連続通信の利点は経路の状況と合わせて考え、プロトコル名だけで順位を付けないでください。

QUICは基盤としてUDPを使うため、現在のネットワークで該当するデータグラムを双方向に送受信できる必要があります。通常のWebサイトには接続できても、特定のUDP通信を制限するネットワークがあります。その場合、Hysteria2やTUICで接続を確立できなかったり、アイドル状態の後に復帰できなかったりすることがあります。まず、動作が確認済みのTCP系ノードと比較し、別のネットワークでも試してください。タイムアウト値をむやみに増やしても、エラー表示が遅くなるだけで、ネットワークの到達性は変わりません。

Hysteria2：帯域幅の設定とサーバー側の制約を確認する

Hysteria2はプロキシ通信向けに認証、TCPストリーム、UDP転送を提供し、輻輳制御に関する仕組みも備えています。実際の帯域幅は実装、通信経路、サーバーのポリシー、制御方式によって変わります。設定にあるアップロードやダウンロードの帯域幅は、契約プランの総容量と同じではなく、値を大きくすればよいわけでもありません。現実とかけ離れた数値は、待ち行列やパケットロス、他のアプリとの帯域競合を増やすおそれがあります。

設定によっては専用の難読化オプションがあり、クライアントとサーバーで値を一致させる必要があります。パスワード、難読化設定、TLS名、証明書の信頼設定はそれぞれ別の層です。いずれか1つでも一致しなければ接続に失敗することがあります。Hysteriaは世代が異なると互換性がない場合もあり、設定の種類名を書き換えるだけでは接続できません。提供元にHysteria2と明記されている場合は、対応するコアを使い、古いプロトコルの解説に従って変更せず、元の認証項目を保持してください。

通常、すべての高度な設定を自分で調整する必要はありません。まずサブスクリプションの提供元の設定で接続し、再現可能な現象に応じて変更を検討してください。大容量ダウンロード中に他のリクエストが明らかに遅くなるなら、帯域幅の設定を変える前に回線の飽和やサーバーの速度制限を確認します。ハンドシェイクが完了しない場合は、ネットワークと認証を確認しましょう。認証エラーの解消に通信量の設定を使っても、確認項目が増えるだけです。

TUIC：プロトコルの世代とデータグラムの転送方式を合わせる

TUICもQUICをベースに、プロキシ接続とデータ転送を行います。認証、輻輳制御、接続維持、UDP転送に関する設定が用意されています。プロトコルの世代や実装によって互換性の境界があるため、TUICという名前だけで相互接続できるとは判断できません。クライアントのコアがサーバー側で実際に使われている形式に対応し、サブスクリプション変換ツールが必要なIDや認証情報を正しく出力する必要があります。

UDPの転送モードによって、データグラムのカプセル化方法や信頼性の扱いが変わります。QUICデータグラムを使う方法と、信頼性のあるストリームを利用する方法では、それぞれ異なる利点と制約があります。アプリのパケットサイズ、パケットロスへの許容度、ネットワーク経路も結果に影響します。サーバーがどちらか一方にしか対応していない場合、クライアント側で任意に切り替えることはできません。リアルタイムアプリに問題がある場合は、Webサイトのテストだけで判断せず、サーバーの仕様を確認してから転送モードを調べてください。

QUICは接続移行などの仕組みをサポートしますが、無線ネットワークを切り替えた後も通信を維持できるかどうかは、クライアントの実装、接続ID、サーバーのポリシー、システムのネットワークインターフェースの変化にも左右されます。Wi-Fiからモバイル回線に切り替えても、すべてのアプリが中断しないとは限りません。会議やリモート接続では、ネットワーク切り替えやスリープからの復帰を実際に試してください。アプリが自動再接続できない場合は、アプリ側の復帰機能も確認しましょう。

Hysteria2やTUICを選ぶ際は、対応するサーバーを利用でき、現在のネットワークでUDPが使え、実際の用途でもその経路が適切に動作することを出発点にしてください。古いノードの速度を上げるためのスイッチではなく、サーバー容量や良好なネットワーク経路の代わりにもなりません。特定のネットワークだけで頻繁に使えない場合は、クライアント設定の破損と決めつけず、経路との互換性の問題として考えましょう。

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

初回接続と連続通信を分けて測定する

ページを初めて開くときは、ドメイン名の解決、接続の確立、安全なハンドシェイク、プロキシ認証、接続先サービスの応答が順に発生する場合があります。プロトコルのハンドシェイクは、その一段階にすぎません。キャッシュの利用、既存接続の再利用、アプリによる先行接続によって、2回目のアクセスが大幅に速くなることもあります。ノードを比較する際は、初回と連続利用を分けて観察し、すでに再利用された接続と新規接続を直接比較しないでください。

連続通信では、ボトルネックとなる帯域幅、輻輳制御、パケットロス、サーバーのリソースがより大きく影響します。ダウンロード速度が徐々に上がるのは、プロトコルの切り替えに成功したからとは限りません。利用できる送信ウィンドウが拡大している可能性もあります。速度が不安定なら、無線干渉、接続先との競合、接続先サイトの制限が原因かもしれません。切り分けるには、近い時間帯に同じ接続先へアクセスし、他の端末が回線を使っていないかも確認します。異なるサイトからのダウンロード結果でプロトコルを比較しないでください。

接続の再利用はハンドシェイクの繰り返しを減らしますが、複数の通信が障害の影響範囲を共有することがあります。大きなダウンロードと複数の短いリクエストが同じ通信を使うと、待ち行列やスケジューリングが操作の応答性に影響する場合があります。マルチストリーム対応プロトコルが一部の待ち時間を改善しても、共有する出口の容量は超えられません。日常業務では、短時間の最大速度より、ページの応答が安定していることやセッションが正常に復帰することのほうが重要です。大きなファイルのダウンロードだけでなく、実際の作業内容をテストしましょう。

暗号化の処理負荷と端末の実装がリソース使用量を左右する

CPU使用率は、暗号化アルゴリズム、ハードウェアアクセラレーション、コアの実装、データ転送量、接続数などによって変わります。同じプロトコルでも、デスクトップ向けCPUと省電力端末では結果が異なる場合があります。追加のカプセル化、データのコピー、ユーザー空間のプロトコルスタック、詳細ログもリソースを消費します。端末の違いを無視して「最も省リソースなプロトコル」を決めることはできません。あるPCでの結果をスマートフォンやルーターにそのまま当てはめないでください。

メモリ使用量には、接続状態、キャッシュ、ルールセット、DNSデータ、クライアント画面なども含まれます。TUNを有効にするとアプリの通信がコアに入る経路が変わり、リソース使用量にも影響する場合がありますが、TUN自体がノードのプロトコルを別の種類に変更するわけではありません。クライアントを変更した後に電池消費が増えた場合は、通信の取り込み範囲、バックグラウンド動作、ログレベル、サブスクリプションの更新頻度を個別に確認してから、プロトコル実装の影響を判断しましょう。

省電力端末では、必要のない全ノードの長時間テストを避けてください。大量のノードを自動チェックしたり、サブスクリプションを頻繁に更新したり、ヘルスチェックを短い間隔で実行したりすると、ネットワークの起動回数が増えます。1回あたりのデータ量が少なくても、無線モジュールが常に動作状態になると待機時の電池消費に影響します。実際に使うプロキシグループだけに検査対象を絞り、必要に合った間隔を設定するほうが、プロトコル名を何度も切り替えるより結果を把握しやすくなります。

モバイル端末では待機とネットワーク切り替えの両方をテストする

スマートフォンの無線モジュールは、動作状態によって電力消費が異なります。接続の維持やパケット受信時の起動は、無線モジュールが動作する時間に影響します。接続維持の間隔が短すぎると電池消費が増え、長すぎると中間のネットワーク機器がアイドル状態の接続情報を削除することがあります。接続の復帰と待機時の消費のバランスを取る必要があり、すべての通信事業者に適した固定間隔はありません。サブスクリプションの初期値でも問題が続く場合は、画面消灯の時間、ネットワークの種類、復帰時の症状を記録してから調整してください。

システムのバックグラウンド制御でクライアントが一時停止されたり、バッテリー最適化でネットワーク通信が制限されたりする場合があります。その場合は、どのプロトコルでも画面ロック後に異常が起こりえます。まず、接続維持に必要なシステム権限がクライアントに付与されているか、別のVPNアプリが通信を処理していないかを確認してください。画面を表示した状態で再現を確認してから、画面を消して試します。バックグラウンドでのみ失敗するなら、ノードの暗号化方式やポートではなく、システムのライフサイクルを重点的に調べましょう。

端末、ネットワーク、ノードの構成、テスト内容、問題が発生した段階を簡潔に記録しておくと便利です。機密情報を記録する必要はありません。各テストで変更する設定は1つだけにし、近い条件で繰り返してください。ある構成は通信速度が高くても発熱が続き、別の構成は用途を満たして待機からの復帰も安定するなら、後者を優先しましょう。目的は具体的な要件を満たすことであり、すべてのプロトコルに永久不変の順位を付けることではありません。

6. Clash、Clash Meta、mihomoのコアの関係

似た設定形式を使っていても、機能が完全に同じとは限りません

オリジナルのClashでは、プロキシ項目、プロキシグループ、ルール、DNSなどを含む一般的なYAML設定形式が確立されました。Clash Metaは関連するエコシステムでプロトコルや機能を拡張し、mihomoはその後の開発を引き継いでいます。名称の違いから、互いに無関係な3つのクライアントだと思われることがありますが、ここで主に扱うのはコアの系統です。GUIクライアントはその上に設定管理やシステム連携の機能を提供します。

過去のClash Premiumと、オリジナルのオープンソースコアも区別する必要があります。古い解説記事がPremium固有の機能を前提としていても、Clashと名の付くすべてのアプリに同じ機能があるとは限りません。移行時は古いクライアントの画面にある設定項目をすべてそのまま移すのではなく、現在実際に動作しているコアの名称と機能を確認してください。TUN、ルールセット、DNSの対応状況や初期動作は、移行先のコアとクライアントの連携方法に応じて調べましょう。

mihomoは使い慣れた設定構成を多く引き継ぎ、プロトコルやネットワーク機能を拡張しています。ただし、古い構造を扱えるからといって、過去のすべての項目、独自拡張、誤った記述まで互換性があるわけではありません。古い設定には、寛容な解析に依存したものや、初期動作が変わった機能を使うものがあります。移行先のコアで設定を検証してから、段階的に動作を確認してください。不明な項目の警告が表示されたら、無視しても機能すると考えず、その項目がどこから来たのかを調べましょう。

クライアント画面に表示される設定が、実際に動作する設定とは限りません

GUIクライアントは、リモートサブスクリプション、ローカル設定、オーバーライド、実行時のポート設定を統合してからコアに渡すことがあります。ユーザーが編集したファイルは、設定の一部にすぎません。よくある例として、サブスクリプションにはあるポートが記載されていても、実際にはクライアントの設定にある別のポートが使われることがあります。これはコアの互換性ではなく、クライアント側の設定が優先されている可能性があります。調査時は実行中の設定やクライアントの設定プレビューを確認し、最終的に有効な値を把握してください。

設定の統合時にルールの順序が変わると、通信の行き先も変わることがあります。プロキシ項目が認識されても、すべてのリクエストがその項目に届くとは限りません。先に評価されるルールが、直接接続や別のグループを選択している場合があります。移行後にWeb通信の出口が変わったら、プロトコルを変更する前に、適用されたルールとグループを確認してください。DNSやルーティングも個別に確認が必要です。名前解決の結果や通信の取り込み経路が変わると、ノードの設定が同じでもアクセス動作が異なることがあります。

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

上記はローカルの接続受付と動作モードの項目だけを示したもので、プロキシサーバーを含む完全な設定ではありません。混合ポートは、対応するプロキシ方式を使うアプリからの接続を受け付けます。ルールモードでは、用途に合ったルールも設定してください。これらをサブスクリプションに記述しても、クライアント画面の設定で上書きされる場合があるため、実際の動作状態を確認しましょう。システムプロキシが自動で有効になるわけでも、ターミナルの環境変数が自動設定されるわけでもありません。

すべてのフォルダーを一度にコピーせず、層ごとに復元する

まず、サブスクリプションのURL、ローカルのYAML、オーバーライド、引き継ぐ必要がある選択記録をバックアップします。次に新しいクライアントへ設定を1つインポートし、ノードとプロキシグループを確認してから、DNS、システムプロキシ、TUNを検証しましょう。クライアントのデータフォルダーには、キャッシュやデータベース、旧アプリ固有の状態が含まれる場合があります。フォルダー全体をコピーすれば移行が完了するとは限りません。実行時のキャッシュをすべて残すより、設定の元ファイルを保管するほうが役立つことが多いです。

クライアント選びでは、まずダウンロードページにあるClash Plusを検討し、その後、OSや設定の使い方に応じてClash Verge Rev、FlClashなどを比較できます。現在の環境を維持する必要がある場合は、複数のクライアントが同時にシステムプロキシを変更したり、TUNを同時に有効化したりしないようにしてください。古いクライアントは過去の設定を理解するのに役立ちますが、画面に慣れているという理由だけで、メンテナンス状況や新しいプロトコルへの対応を見落とさないでください。

移行後に特定の種類のノードだけ失敗する場合は、そのプロトコルで追加・変更された項目を優先して確認します。すべてのノードが正常なのにアプリがプロキシを経由しない場合は、システムへの接続方法を確認してください。ルールモードだけに問題がある場合は、ルールの参照先とグループ名を調べます。層ごとに分類すれば、効果のない試行を減らせます。コアの系統や設定の違いについては、オリジナル、Meta、mihomoのコア比較も参考にして、概念上の関係を実際の動作ログと照らし合わせてください。

プロトコルの対応状況は、クライアントに含まれるコアの更新頻度にも左右されます。クライアント本体とコアの更新は必ずしも同時ではありません。画面に設定項目があっても、現在の実行ファイルがすべての選択肢に対応しているとは限りません。実際に動作しているコアの情報を確認して記録しましょう。ただし、新しい名称を追いかけて頻繁に入れ替える必要はありません。必要な機能を確かめてから、クライアントが提供する方法で更新してください。

7. サブスクリプション形式とYAML：ダウンロードできても読み込めるとは限らない

取得した内容がどの種類かを見分ける

サブスクリプションURLはコンテンツを取得するための入口であり、常に同じ形式のデータが返るとは限りません。一般的な形式には、完全なClash YAML、プロキシ項目だけを含むプロバイダーファイル、共有リンクの一覧やエンコードされたリストがあります。完全な設定にはルールやプロキシグループを定義できますが、プロキシプロバイダーの主な役割はノード一覧を読み込むことです。用途が異なるため、ダウンロードできたテキストを何でも同じインポート画面に読み込めるわけではありません。

完全な設定では通常、proxiesでローカルノードを定義するか、proxy-providersで外部ノードを読み込み、proxy-groupsで選択方法を構成し、最後にrulesでリクエストの行き先を決めます。プロバイダーファイルにはproxiesの一覧だけが含まれ、動作に必要な他の項目がない場合があります。プロバイダーファイルを完全な設定として有効にすると、利用可能なグループがなかったり、ルールが不足したりすることがあります。これはノードのパスワードが無効になったという意味ではありません。

共有リンクは別の形式で、項目がエンコードされていたり、プロトコルごとに異なる形式が使われたりします。サブスクリプション変換では、リンクから情報を解析し、移行先のコアの構文に変換する必要があります。YAMLが出力できても、パス、サーバー名、UDPモード、安全設定がすべて保持されたとは限りません。複雑な通信方式を使う場合は、中間変換で情報を失わないよう、サブスクリプションの提供元が明示している移行先コア向けの形式を優先してください。

プロバイダーの参照には依存関係全体の設定が必要です

proxy-providers:
  my-sub:
    type: http
    url: "https://example.com/sub?token=xxxx"
    path: ./providers/my-sub.yaml
    interval: 86400

proxy-groups:
  - name: PROXY
    type: select
    use:
      - my-sub

rules:
  - MATCH,PROXY

この例では、プロバイダー、プロキシグループ、最終ルールの参照関係を示しています。例にあるドメイン名とトークンはダミーであり、ノードを取得することはできません。実際に使用するには、プロキシプロバイダー形式を返す正規の提供元に置き換えてください。intervalの単位は秒で、更新予定の間隔を示します。接続タイムアウトではありません。pathはローカルキャッシュの保存先を指定しますが、実際の場所はクライアントの実行ディレクトリや権限によって異なります。どのOSでも同じ場所に保存されるとは限りません。

ここでのMATCHは、条件に一致したリクエストをPROXYに送ります。あらゆる用途に適した振り分け設定ではありません。実際の設定で直接接続とプロキシを使い分ける場合は、最終的な一致ルールより前に該当ルールを追加してください。プロバイダー名、プロキシグループのuseに指定する名前、ルールの送信先グループ名は一致させる必要があります。表示名だけを変更して参照先を直さないと、読み込みに失敗したり、ルールが対象を見つけられなかったりします。ノードのプロトコルとは関係ありません。

取得時のエラーと接続時のエラーを分けて確認する

サブスクリプションの更新に失敗したら、まず正しい応答を取得できたかを確認します。URLの無効化、認証失敗、ログインページやエラー説明の返却などによって、設定以外の内容がクライアントに渡る場合があります。アカウントへのアクセス権を持つクエリパラメーターが含まれていることがあるため、サブスクリプションの完全なURLを公開の質問ページに貼り付けないでください。ログを共有する際は、トークン、アカウント情報、専用アドレスを伏せ、エラーの種類、応答内容の種類、必要最小限の設定構造だけを残します。

テキストを正常に取得できたら、YAMLの構文と設定の意味を確認します。インデントにはスペースを使い、同じ階層の項目はそろえてください。特殊文字を含む値は、構文に応じて引用符で囲むとよいでしょう。構文エラーがないことは、構造を解析できることを示すだけです。コアがプロトコルの種類を認識できるか、必須項目がそろっているか、プロキシグループの参照先が存在するかも確認してください。特定のプロトコルが非対応という警告が出た場合は、関係のないインデントを何度も変更せず、コアの対応状況を調べます。

設定の読み込みに成功しても、一部のノードだけ接続に失敗することがあります。その場合は、サーバーへの到達性、認証、通信方式の設定を確認してください。反対に、サブスクリプションの更新に失敗しても、キャッシュ済みのノードがすぐに使えなくなるとは限りません。既存の設定で動作が続く場合もあります。更新時刻、現在有効な設定、実際の接続状況をそれぞれ記録し、更新エラーをすべてのアクセス障害の原因だと決めつけないようにしましょう。

オーバーライドにも制約があります。リスト全体を置き換える場合と、ルールを1つ追加する場合では結果が異なります。クライアントごとに設定の統合方法も異なる可能性があります。設定の提供元を変更したら、最終的に動作する設定、特にグループ名とルールの位置を確認してください。リモートサブスクリプション、ローカルファイル、複数の設定を管理する方法については、Clash Profileと複数設定の管理もご覧ください。更新による変更を、コアが設定を勝手に書き換えたと誤解せずに済みます。

8. 用途に合わせてプロトコルを選び、動作を確認する

デスクトップでの閲覧とモバイル利用では、優先すべき点が異なります

デスクトップでの普段使いでは、利用可能なサービスの中から、安定していて設定項目がそろい、クライアントも対応しているノードを選びましょう。SS、VMess、Trojan、VLESSはいずれも用途を満たす可能性があります。重要なのは、実際の経路と通信方式の組み合わせです。再現できる問題がなければ、特定のプロトコルを使うためだけに設定全体を変更する必要はありません。クライアントのインストール先としてClash Plusを検討し、他のクライアントはダウンロードページでOSに合わせて比較できます。プロトコルは、クライアントの対応範囲内で選んでください。

モバイル端末では、画面ロック後の復帰、Wi-Fiなどの無線ネットワークの切り替え、バックグラウンド制限も確認しましょう。連続通信で良好なQUIC系ノードでも、特定のネットワークではUDPの到達性に問題が出る場合があります。TCP系ノードでも、アイドル状態の接続が破棄されて再接続が必要になることがあります。スマートフォン向けの設定は、画面を表示した状態でのアクセスだけでなく、普段の待機動作も満たす必要があります。クライアントを起動した直後のテスト1回だけで判断しないでください。

音声通話、会議、ゲームでは、ファイルのダウンロード速度だけでなく、アプリのデータグラム転送、ジッター、パケットロスを確認します。まずアプリの通信がプロキシに取り込まれているかを確認し、次にノードが必要なUDP転送に対応しているかを調べます。アプリによっては複数の接続先を同時に使うため、ログインできても音声や映像が正常とは限りません。双方向の音声通話やセッションを実際に試し、継続利用やネットワーク切り替え後の復帰も確認してください。

サーバーや省電力端末では、まず実行環境の制約を確認する

サーバーやルーターではコアを直接実行することが多く、起動サービス、設定ファイルの場所、権限、待ち受け範囲を自分で設定する必要があります。GUIクライアントとは必要な作業が異なります。画面を1つ減らすためだけに導入方法を変えるのはおすすめできません。端末の処理能力に限りがある場合は、不要な全ノード検査や複雑な通信取り込みを減らしてから、プロトコルの負荷を比較します。トラフィックの入口を正しく処理できないコアでは、プロトコルに対応していてもネットワーク全体を自動でプロキシすることはできません。

LAN内で共有すると、アクセス制御の範囲も広がります。他の端末から接続させる場合は、待ち受けアドレス、ファイアウォール、認証方式を確認してください。自分の端末で使えるからといって、LAN内の他の端末でも使えるとは限りません。プロトコルの選択が解決するのは、クライアントから接続先サーバーまでの区間です。LAN内の端末からローカルプロキシポートまでの経路は別に確認する必要があります。他の端末だけインターネットに接続できない場合は、まずローカルの接続受付を調べ、すぐに接続先のプロトコルを変更しないでください。

決められた順序で確認し、問題のある層を特定する

手順1：設定が読み込まれ、プロキシグループに対象ノードがあり、選択されていることを確認します。手順2：ログを確認し、設定解析エラー、接続タイムアウト、認証失敗、安全なハンドシェイクの失敗のどれかを特定します。手順3：アプリの通信が実際にクライアントを経由しているか、接続一覧やルール適用の記録で確認します。ブラウザーは使えてもターミナルだけ動かない場合は、接続方法を調べ、ブラウザーとターミナルのシステムプロキシのトラブル対処を参考にしてください。

手順4：条件を変えて比較します。同じノードでネットワークを変える、同じネットワークで通信方式を変える、または互換性を確認した別のクライアントで同じ設定を使います。一度に変更する条件は1つだけにし、結果を記録してください。UDPを基盤とするプロトコルだけが失敗する場合は、現在のネットワーク経路を優先して確認します。特定の安全設定の組み合わせが常に失敗する場合は、その設定項目を確認してください。すべてのプロトコルで接続テストに成功してもアプリが動かない場合は、ルール、DNS、アプリ独自のプロキシ設定を重点的に確認します。

DNSの問題はプロトコルの問題と誤認されやすいものです。接続先のドメイン名を正しく解決できない、到達できないアドレスが返される、DNSリクエストが想定した経路を通らないといった場合、接続に失敗することがあります。クライアントのFake-IP方式と実際のアドレスを使う方式によって、一部アプリの動作が変わる可能性もあります。記録を取らずにDNSモード、TUN、ノードのプロトコルを同時に切り替えないでください。まずドメイン名が解決できるかを確認し、その後の接続先を調べましょう。

最後に、動作を確認した基準設定と必要なバックアップを保管してください。プロトコルやオーバーライドルールを変更したら、同じテスト内容で再確認し、サブスクリプション更新後も設定が読み込めることを確認します。変更しても改善しなかった場合は、設定を重ねて増やすのではなく、基準の状態に戻してください。手順に沿って設定するにはクイックスタートへ、エラーの症状から対処方法を探すにはヘルプセンターへ進んでください。プロトコル解説の目的は問題の範囲を絞り、選択のポイントを説明することであり、あらゆるネットワークに同じ設定を当てはめることではありません。

信頼できる選定結果は、「現在の端末と接続ネットワークで、特定のアプリを使う場合、このノードは安定して接続でき、正常に復帰する」のように具体的な条件で示せます。その条件なら再テストでき、環境が変わったときにも見直せます。特定のプロトコルが最速、省電力、または誰にでも最適だと言い切ると、実装の違いを見落とし、次のトラブル対処にも役立ちません。境界のない順位表を覚えるより、条件と確認手順を残すほうが有用です。