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

プロトコル選びで確認する4つの層

クライアント、コア、プロトコル、ネットワーク経路

Clash関連の用語は、それぞれ異なるレイヤーを指します。クライアントはウィンドウ表示、サブスクリプション管理、システムプロキシ、権限の要求を担当します。コアは接続の確立、ルールの照合、DNSの処理を担います。プロトコルはクライアントとサーバー間の認証、データのカプセル化、通信方式を定めます。実際にデータが通る経路を決めるのはネットワークです。クライアントを選んだからといって、プロトコルまで決まるわけではありません。mihomo対応のGUIクライアントをインストールした後も、サブスクリプションに含まれるノードの種類とサーバー側の設定を確認する必要があります。

この4つの層では、それぞれ別の問題が起こり得ます。設定をインポートできても、ファイルが管理画面に取り込まれたことを示すだけで、コアがすべての項目に対応しているとは限りません。ノードに接続済みと表示されても、確認用の通信が成功しただけで、動画やダウンロード、リアルタイム通話に適しているとは限りません。同じプロトコル名のノードでも、サーバーや出口、トランスポート層、帯域制御が異なる場合があります。プロトコルを比較する際は、サーバーの場所、テスト対象、実施時間をできるだけそろえましょう。そろえないと、プロトコルではなくネットワーク経路の違いを比較することになります。

ランキングではなく、制約条件から考える

まず、端末のOS、クライアントのコア、サーバー側のプロトコル、現在のネットワークで利用できる通信方式を確認します。社内ネットワークではTCPが使えてもUDPが制限されることがあります。モバイル回線では基地局の切り替え後にIPアドレスが変わる場合があり、古い端末では暗号処理の性能が不足することもあります。サーバーが1種類のプロトコルしか提供していない場合、クライアントで種類の項目を変えても別のプロトコルにはなりません。プロトコルはクライアントとサーバーで一致させ、ポート、認証情報、通信オプションもそろえる必要があります。

次に、主な用途を明確にします。Web閲覧では最初の応答と短時間の接続コスト、大容量ファイルの転送では持続的なスループット、音声通話やゲームでは遅延の変動、パケットロス、UDP転送の可否が重要です。リモートデスクトップでは操作の応答性と接続復旧の両方が問われます。長時間のダウンロードで安定する設定が、電波の弱い環境での通話にも適しているとは限りません。特定のテスト向けに調整すると、バックグラウンド通信やスマートフォンの電池消費が増える場合もあります。

セキュリティと接続品質は分けて判断する

暗号化と認証は、接続先が信頼できるか、通信内容をどう保護するかを示します。一方、速度テストで分かるのは、現在の経路でどの程度の通信品質が得られるかです。両者は置き換えられません。証明書を使う設定では、証明書チェーンとサーバー名を確認してください。事前共有の認証情報を使う場合は、信頼できる入手元の情報を使用します。速度が出るからといって認証確認を長期間無効にしたり、新しいプロトコル名だけを根拠に安全性が高いと判断したりしないでください。

このガイドでは、固定の速度ランキングは提示しません。プロトコルのオーバーヘッドは、CPU、暗号化の実装、経路のMTU、パケットロス、サーバー負荷などに左右されます。各候補ノードについて、現在のコアが十分に対応しているか、現在のネットワークで下位の通信方式が使えるか、実際の用途で改善があるかを記録してください。いずれかを確認できない場合は、動作確認済みの設定を維持し、複数の項目を同時に変えないようにしましょう。

SSとVMess：独立した暗号化プロキシの設計上の違い

軽量な構成のShadowsocks

Shadowsocksは一般にSSと呼ばれ、比較的シンプルなプロキシ方式を採用しています。クライアントはローカル接続を受け付け、宛先アドレスと通信データをカプセル化してサーバーへ送り、サーバーが接続先への通信を確立します。すべての環境でWeb通信や証明書の仕組みを必要とするわけではなく、基本設定はサーバー、ポート、暗号化方式、認証情報が中心です。この構造は複数のプラットフォームで実装しやすく、必須項目を絞ってトラブルを調べられます。ただし、すべてのSSノードが同じ仕様とは限りません。

SSの暗号化方式は自由に置き換えられません。以前からあるストリーム暗号方式、一般的なAEAD方式、後発のShadowsocks 2022方式では、鍵の形式や実装要件が異なります。サーバー側の方式にクライアントを合わせる必要があります。方式によっては、任意のパスワードではなく、所定の長さと形式の鍵が必要です。インポートエラーが起きたら、まず方式名と鍵の形式を確認してください。サーバーのポートを変えるだけでは解決しないことがあります。

SSはTCPを利用でき、クライアントとサーバー、ネットワークが対応していればUDPも転送できます。クライアントのUDP設定は、ローカルで転送を許可する条件にすぎません。サーバー、サブスクリプション、通信経路も対応している必要があります。Webは正常なのにゲームや通話で問題が起きる場合は、それらの通信がプロキシを通っているか、サーバーが必要な機能を提供しているか、現在のネットワークがUDPを制限していないか確認してください。Webの疎通確認だけではUDP転送の可否は分かりません。

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

VMessはV2Rayのエコシステムから生まれたプロトコルで、ユーザー識別子を認証に使用し、独自の暗号化とカプセル化の仕組みを備えています。実際のノードではTCPやWebSocketなどのトランスポートを組み合わせ、TLSも併用する場合があります。比較時は組み合わせ全体を明記してください。単に「VMessのほうが速い」とは判断できません。直接接続する場合と追加のゲートウェイを経由する場合では、ハンドシェイクの回数やカプセル化の負荷、中継機器の対応状況が大きく異なることがあります。

VMessのトラブルシューティングでは、時刻の同期も確認してください。認証方式には端末の時刻が影響するため、システム時刻がずれていると認証に失敗することがあります。画面にはタイムアウトや接続切断とだけ表示される場合もあります。まずOSの時刻を自動同期し、その後でユーザー識別子とサーバーログを確認してください。古いサブスクリプションには過去の互換設定が含まれていることがあります。項目の意味はコアの実装によって異なるため、古い解説の値をそのまま流用しないでください。

WebSocketのパス、リクエストのホスト名、TLSのサーバー名は、それぞれ異なる情報です。パスはアプリケーション層のハンドシェイク、リクエストのホスト名はHTTPルーティング、TLSのサーバー名はハンドシェイクと証明書検証に使われます。値が同じ場合もありますが、常に一致させるという決まりはありません。サーバーがリバースプロキシを経由する構成では、パスの指定漏れやリクエストヘッダーの誤りにより、サーバーには接続できてもプロキシセッションを確立できないことがあります。これはルールによる振り分けの問題ではありません。

選択と運用で押さえるポイント

TCPが使えることを確認済みのネットワークや、リソースの限られた端末では、構成が比較的シンプルなSSを基準にできます。VMessを適切に運用できているなら、名前が古いという理由だけで急いで移行する必要はありません。確認すべきなのは、サーバーの保守状況、暗号化設定、クライアントの対応、日常の用途での動作です。特定の環境に合わせてトランスポートのカプセル化を追加することはできますが、そろえる項目が増えるだけで、速度が自動的に向上するわけではありません。

SSの設定にプラグイン項目がある場合は、クライアントが該当するプラグインとモードに対応しているか個別に確認してください。基本的なSSに対応していても、すべてのプラグインが使えるとは限りません。ノード変換ツールがプラグイン設定を落とすこともあります。VMessにもトランスポートの組み合わせによる互換性の制約があります。元のリンクと設定の入手元を保存し、変換後の項目を一つずつ照合するほうが、動作モードを何度も切り替えるより効果的です。インポート時の問題は、よくある質問のインストール・設定方法も確認してください。

TrojanとVLESS：認証、TLS、トランスポートの役割

Trojan：TLSにセキュアな通信を任せる

Trojanの一般的な構成では、外側のセキュアな通信にTLSを使い、その中でプロキシの認証とデータ転送を行います。別の業務用暗号化方式の一覧を管理する必要はなく、設定ではパスワード、証明書、サーバー名、サーバーの待ち受け設定が重要になります。設定が簡単になるのは、TLSが通信を保護し、プロキシプロトコルが宛先と認証を扱うという役割分担によるものです。実際の安全性は、証明書の検証とサーバー設定が正しいかどうかに左右されます。

接続先アドレスと証明書の名前が異なることもあります。たとえば、あるアドレスを使ってサーバーに接続し、サーバー証明書はドメイン名に対して発行されている場合、TLSのサーバー名を正しく指定し、証明書がその名前に一致することを確認する必要があります。SNIはハンドシェイクでサーバー名を伝える仕組みです。証明書検証は相手の身元と信頼チェーンを確認します。関連はありますが、同じものではありません。もっともらしいドメイン名を入力しても、誤った証明書が信頼できるようになるわけではありません。

Trojanの接続に失敗した場合、まずTCP接続の失敗、TLSハンドシェイクの失敗、プロキシ認証の失敗を切り分けます。TCP接続の問題ではアドレス、ポート、経路を確認します。TLSの問題ではシステム時刻、証明書の有効期限、名前の一致、信頼チェーンを確認してください。認証で失敗している場合は、パスワードとサーバー側の認証設定を重点的に調べます。複数の失敗がクライアント上では一律にタイムアウトと表示されることもあるため、ログで失敗した段階を確認し、TLS設定を一度に変更しないようにしましょう。

VLESS：軽量なプロトコルに独立した暗号化層があるとは限らない

VLESSもV2Ray関連のエコシステムから生まれたプロトコルです。プロトコル自体の負担を減らし、組み合わせるトランスポートのセキュリティ機能に保護を任せる設計です。ユーザー識別子を設定すれば自動的に十分な暗号化が得られる、という意味ではありません。TLSやREALITYなどを組み合わせる構成が一般的ですが、利用可否はクライアントのコアとトランスポートの組み合わせによって異なります。サブスクリプションにセキュリティ層の項目がない場合は、初期動作を推測せず、設定の提供元に確認してください。

REALITYの設定は一般的な証明書ベースのTLSとは異なり、通常は公開鍵、short ID、サーバー名などの対応する項目が必要です。ユーザー識別子が正しくても、これらの項目が一致しなければ接続できません。VLESSの構成によっては、サーバー側が特定のVisionフロー制御を要求することもあります。これはクライアントとサーバー間のネゴシエーションや実装上の制約であり、汎用的な高速化スイッチではありません。サーバーの要件に従って設定し、関連項目をすべてのノードにコピーしないでください。

同じVLESSでも、異なるトランスポートを使用する場合があります。クライアントが基本的なVLESSに対応していても、サーバー側のすべてのトランスポート、セキュリティ層、フロー制御の組み合わせに対応するとは限りません。共有リンクで拡張項目をすべて表現できるとも限りません。互換性を確認するには、使用中のコアのドキュメントで組み合わせの制限を調べ、実際に生成された設定を確認してください。クライアント名やプロトコルの対応一覧だけでは、すべての制約を把握できません。

証明書の検証と接続の再利用

証明書検証を無効にすると、サーバーの身元を確認する能力が低下します。長期的な解決策として使わないでください。自己署名証明書を使う環境では、クライアントの機能に応じて信頼できる証明書や適切な本人確認条件を設定します。公的な証明書を使う場合は、サーバー名と証明書チェーンを修正してください。特定の端末だけで失敗する場合は、システム時刻、信頼ストア、セキュリティソフトが通信に介入していないかも確認します。同じノードでも端末によって挙動が違うのは、プロトコルではなくローカル環境が原因のことがあります。

接続の再利用では、複数の論理リクエストで下位の接続を共有し、接続確立の繰り返しを減らせます。一方で、輻輳の競合や障害の影響範囲が変わる場合があります。共有接続が詰まると、複数のリクエストに影響することがあります。サーバーが該当する再利用方式に対応していない場合、断続的な切断が起きることもあります。TrojanやVLESSを選ぶときは、まずサーバーが明示的に対応している最小限の設定で接続を確認し、その後で再利用、トランスポートのカプセル化、フロー制御を検討しましょう。最初から多くのオプションを追加するより、問題を特定しやすくなります。

Hysteria2とTUIC：QUICベースの接続モデル

QUICで変わるレイヤー

QUICは通常UDP上で動作し、暗号化ハンドシェイク、信頼性のある転送、複数のストリームといった機能を備えています。下位の通信にUDPを使うからといって、アプリケーションデータまで信頼性のない方式で届くわけではありません。Webページやファイルの内容は、信頼性のあるストリームで転送できます。複数の論理ストリームが1本のTCPバイトストリームを共有する場合と比べ、QUICはストリーム間の順序待ちによるブロックを抑えられます。ただし共有接続は同じ経路の輻輳と利用可能な帯域の影響を受け、物理ネットワークの容量を超えることはできません。

Hysteria2とTUICはいずれもQUICを利用しますが、同じプロトコルの別名ではなく、認証項目も互換ではありません。サーバーがHysteria2で待ち受けている場合、クライアントもHysteria2としてセッションを確立する必要があります。TUICも、プロトコルの世代に対応した実装が必要です。クライアント画面に「QUIC対応」と表示されていても、QUICベースのあらゆるプロキシサービスに接続できるとは限りません。ノードの種類と実装の対応範囲を確認してください。

Hysteria2の帯域推定と輻輳制御

Hysteria2は、パケットロスや複雑な経路での通信を想定し、帯域設定に関わる輻輳制御の選択肢を提供します。設定するアップロード帯域とダウンロード帯域は、通常、クライアント側で想定する通信能力を示します。サーバーのネットワークカードの公称速度をそのまま設定しないでください。実際に使える帯域を過大評価すると、キューの増加や回線の競合、パケットロスにつながり、Web操作や同じネットワーク上のほかの端末に影響することがあります。過小に設定すると、持続的な転送速度が制限される可能性があります。

サーバー側で帯域を制限したり、ネゴシエーションの結果に影響を与えたりすることもあります。クライアントに入力した値だけでは、実際の動作を判断できません。まずは管理者が推奨する設定を使い、持続的なダウンロードと操作時の応答をあわせて確認してください。任意の難読化設定は、両端で値を一致させる必要がある場合があります。これらは証明書の検証や認証の代わりにはなりません。設定変更後にハンドシェイクがまったくできなくなったら、まず該当するオプションを元に戻してください。帯域不足と決めつけないようにしましょう。

TUICのストリーム、データグラム、接続維持

TUICもQUIC上でプロキシセッションを運びます。設定にはユーザー識別子、パスワード、輻輳制御、UDPの転送方式、接続維持の項目などが含まれる場合があります。TCPのプロキシストリームとUDP通信では処理方式が異なります。信頼性を重視する転送とデータグラム方式のどちらを選ぶかは、アプリが即時性と完全性のどちらを求めるかで判断します。リアルタイム通話では古くなったデータを速やかに破棄できることが重視されます。一方、ファイルは順序どおり確実に届く必要があるため、どちらも漠然と「安定性」でまとめることはできません。

キープアライブとアイドルタイムアウトは、通信がない間に接続をどう維持するかを決めます。モバイルネットワークのアドレス変換装置はUDPのマッピングを早く破棄することがあり、適切なキープアライブによって次のデータが届きやすくなる場合があります。一方、頻度を上げすぎると無線の再起動やバックグラウンド通信が増えます。ネットワーク切り替え後に接続を継続できるかどうかは、実装、サーバー、経路にも左右されます。QUICの接続移行機能が、どのクライアントでもセッションの継続を保証するわけではありません。

UDPの経路が常に使えるとは限らない

現在のネットワークでUDPが大きく制限されている場合、これら2種類のプロトコルはTCPベースの方式より接続しにくいことがあります。再試行回数を増やしても、下位のネットワークで通信できない問題は解決しません。また、カプセル化によるパケットサイズにも注意してください。追加のプロキシ層やトンネル、アクセスネットワークによって、経路で利用できる転送単位が小さくなり、小さなリクエストは通るのに大容量通信が止まることがあります。ログと別のネットワークで段階的に確認し、すべての端末のシステム設定をむやみに下げないでください。

比較する場合は、動作確認済みのTCP設定を基準として用意し、同じネットワークでWeb閲覧、継続的な転送、アイドル後の復帰をそれぞれ試します。QUICベースの方式は、パケットロスのある経路で適する場合もあれば、ネットワーク事業者の速度制限を受ける場合もあります。一度だけの最高速度ではなく、実際の用途で再現性のある改善が得られるかを基準にしてください。設定変更時は、サーバーの処理能力や共有ネットワーク上のほかのアプリへの影響も考慮します。

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

速度テストを複数の段階に分ける

体感上の待ち時間には、名前解決、下位接続、プロトコルのハンドシェイク、接続先サイトの応答、コンテンツ転送が含まれます。ノードの遅延テストが測定するのは通常その一部で、各Webサイトの初回表示時間と同じではありません。疎通確認への応答が速いノードでも、接続先サイトまでの経路が悪ければダウンロードが遅くなることがあります。プロトコルの違いを調べるときは、初回アクセス、再アクセス、長時間の接続を分けて記録してください。キャッシュや接続の再利用による変化を、プロトコルの優位性と誤認しないためです。

持続的なスループットは、送信ウィンドウ、輻輳制御、往復遅延、パケットロスの影響を受けます。帯域の広い経路でも往復遅延が大きいと、回線容量を使い切るには十分な量のデータを転送中の状態に保つ必要があります。パケットロスが起きた後の回復速度も制御方式によって異なります。ただし、積極的に送信すれば常に良いわけではありません。アクセス回線のキューが埋まり、操作時の遅延が大きくなる可能性があります。ダウンロード速度を確認する際は、普段使うWebページを同時に開いたり、音声通話を試したりして、ほかの用途に影響していないかも確認してください。

CPU負荷は通信処理全体から生じる

リソース負荷の原因は暗号化だけではありません。ユーザー空間のネットワーク処理、データのコピー、トランスポートのカプセル化、接続の再利用、ルール照合、ログ出力もCPU時間を消費します。特定の暗号アルゴリズムに対するハードウェア支援はCPUによって異なるため、デスクトップPCでの測定結果をスマートフォンやルーターにそのまま当てはめることはできません。低消費電力の端末で負荷が高止まりする場合は、システムプロキシとTUN、最小限の設定と全機能を有効にした設定をそれぞれ比較し、ボトルネックを確認します。

メモリ使用量は、接続数、ルールの数、サブスクリプションの規模、キャッシュ、GUIのプロセスにも左右されます。クライアント2つの合計メモリだけを比べても、コアの効率差は判断できない場合があります。一方では多くのルールを読み込み、もう一方では接続パネルを開いていないかもしれません。ルールと通信内容をそろえ、GUIとコアのプロセスを分けて確認してください。特にルーターではメモリの余裕が重要です。メモリ不足によるプロセス終了が、プロトコルの切断と誤認されることがあります。

スマートフォンの電池消費と無線の再起動

スマートフォンの電池は暗号化だけでなく、無線接続の維持、バックグラウンドでの起動、再接続、通信の確認にも使われます。すべてのノードを頻繁に確認したり、キープアライブの間隔を短くしたり、詳細ログを出し続けたりすると、アイドル状態を保ちにくくなります。プロトコル名だけから、一定の電池消費ランキングを決めることはできません。同じ端末、同じネットワーク、同程度の通信量で比べる必要があります。画面の明るさや電波強度もできるだけそろえてください。

モバイルOSでは、通常VPNやネットワーク拡張の仕組みを使って通信を取り込みます。具体的な方式はプラットフォームとクライアントによって異なります。クライアントにTUNと表示されていても、デスクトップ環境と同じ実装とは限りません。OSの省電力機能がバックグラウンドの動作を一時停止し、復帰後にセッションを再確立することもあります。画面ロック後だけ問題が起き、前面では正常な場合は、プロトコルを変える前にバックグラウンド動作の権限とネットワーク復帰時の挙動を確認してください。キープアライブの間隔をむやみに短くすると、問題を見えにくくする一方で、日常の電池消費が増えることがあります。

再現可能な比較記録を作る

一度に変更する要素は1つだけにします。ノードの地域と接続先サイトをそろえ、TUNの有効・無効を固定し、自動ノードチェックを停止してから、短いリクエスト、大容量ファイル、アイドル後の復帰を個別に確認してください。ダウンロード中にサブスクリプションを更新したり、DNSや輻輳制御の設定を同時に変えたりすると、結果の原因を特定できません。最高速度のスクリーンショットだけでなく、発生時刻、ネットワークの種類、エラーが起きた段階、実際のタスクでの挙動を記録しましょう。

特定のアプリだけに問題がある場合は、ルールによる振り分けと名前解決の経路も確認します。Fake-IPはドメイン名を保持するためのアドレス割り当て方式であり、速度を向上させるプロトコルではありません。TUNは通信を取り込む範囲を広げますが、すべての接続が速くなるわけではありません。有効化後に挙動が変わった場合、以前は直接接続していた通信がプロキシ経由になっただけの可能性もあります。接続ログで適用されたルールと出口を確認してから、ネットが遅いときの3段階チェックを参考に、ノード、経路、端末の順に調べてください。

オリジナル版Clash、Clash Meta、mihomo

プロジェクトの変遷と機能の由来

オリジナル版Clashは、YAMLでプロキシ、プロキシグループ、ルールを記述する使い方を広め、多くのGUIクライアントがこの設定モデルを引き継いでいます。オリジナルのプロジェクトは開発が終了しており、既存のインストール環境が動作することはあっても、新しいプロトコルや互換性の修正が今後も提供されるとは限りません。古いクライアントが一般的な設定を読み込めても、後から追加されたプロトコル項目を扱えるとは限りません。未知の種類に遭遇したら、まず実際に接続を処理しているコアを確認してください。ウィンドウのタイトルだけでは判断できません。

Clash MetaはClashを基盤に発展した拡張コアの系統で、後にmihomoという名称で開発が続けられています。ユーザーが使う「Meta」という呼び方、設定ファイルの拡張機能、現在のmihomoのドキュメントは、同じ発展の流れを指すことがよくあります。ただし、古いインストーラーには以前の実装が残っている場合があります。名称からプロジェクトの由来は分かりますが、「Meta」と書かれたすべてのクライアントが同じ機能を持つわけではありません。クライアントが示すコアの情報とメンテナンス状況を確認してください。

mihomoはプロトコル、ルール、DNS、通信の取り込みなどの機能を拡張し、複数のデスクトップ・モバイルクライアントの接続基盤として使われています。GUIは通常、サブスクリプションのダウンロード、設定の上書き、権限管理などを担います。そのため、機能が両者に分かれている場合があります。コアが項目を読み取れてもGUIに設定スイッチがないこともあれば、GUIにスイッチがあっても現在のコアが該当する記述方式に対応していないこともあります。調べるときは、GUIとコアのドキュメントを分けて確認してください。

設定の基本構造が共通でも、すべての項目に対応するとは限らない

3つの間で共通して使えることが多いのは、プロキシ一覧、プロキシグループ、ルールなどの基本構造です。一方、拡張プロトコル、ルールの動作、DNSの項目が完全に後方互換であるとは限りません。新しい設定を古いコアに渡すと、読み込みに失敗したり一部の項目が無視されたりすることがあります。古い設定を新しいコアに渡した場合も、項目の制約が厳しくなったことで問題が表面化する可能性があります。読み込みに成功したら終わりではありません。ルールの適用先、ドメインの名前解決結果、UDP通信も確認してください。

クライアントの選び方と旧環境からの移行

初めて選ぶ場合は、ダウンロードページでおすすめされているClash Plusから試し、OSごとの対応範囲と設定方法を確認してください。デスクトップではClash Verge Rev、FlClash、Clash Nyanpasuも比較できます。モバイル端末では、ダウンロードページでClash Meta for Android、FlClash、Surfboardの対応形式を確認してください。すべてのクライアントで同じ設定構文を使えるとは限りません。サブスクリプションURLを読み込めるからといって、設定ファイル全体をそのまま共有できるとは限りません。

Clash for WindowsとClashX Metaは、ダウンロード一覧では開発終了済みのアーカイブ版として扱われています。移行前に、元のサブスクリプションURL、個人用ルール、上書き設定、必要なローカル設定を保存してください。古いフォルダーをそのまま上書きしないでください。新しいクライアントにサブスクリプションをインポートしたら、システムプロキシ、TUNの権限、自動起動、ポートをそれぞれ確認します。古い環境にあるスクリプトをそのままコピーして実行せず、どの設定項目を変更するものかを先に確認してください。

コアの切り替えは、クライアントが明示的に対応している場合に限って行ってください。異なるコアのパッケージは、特定の制御インターフェース、起動引数、権限管理方式に依存することがあります。ファイルを手動で置き換えると、画面上の状態と実際の動作が一致しなくなる可能性があります。切り替えを確認するには、実行中のプロセスと起動ログに表示されるコアの情報を確認し、設定の読み込み結果も調べてください。設定メニューに項目が表示されているだけでは不十分です。古いプロセスが残って、以前のポートを使用している場合もあります。

移行時のトラブルシューティングは2段階に分けます。まず最小限のサブスクリプション設定で接続し、その後でルールと上書き設定を一つずつ戻してください。問題が発生したときに、プロトコルの互換性と個別設定のどちらが原因か判断しやすくなります。プロジェクトの関係については3世代のコアの機能と互換性を比較をご覧ください。古いデスクトップ環境から移行する場合は、Clash for Windowsからの移行手順を参考にし、クライアントの管理機能の問題とプロトコルのテストを混同しないようにしましょう。

サブスクリプションの形式、項目の保持、設定のマージ

サブスクリプションURLの返却形式は一つではない

サブスクリプションは設定を更新するための入口であり、返却される内容は完全なClash YAML、ノード一覧、エンコードされた共有リンクの集まり、ほかのクライアント向け設定などさまざまです。同じURLでも、リクエスト方法によって異なる形式が返ることがあります。「URLを開ける」ことは「現在のクライアントで解析できる」ことを意味しません。まず提供元が対象としているクライアントを確認し、インポート時のメッセージを確認してください。Webページ、ログイン画面、エラーテキストが返る場合は、YAMLのインデントを変えるのではなく、アクセス権や認証の問題を解決します。

完全な設定には、プロキシ、プロキシグループ、ルール、DNSが含まれる場合があります。ノード用サブスクリプションは接続先だけを記述し、ルールや振り分けをローカル設定に任せることがあります。この2つを混同すると、ルールが突然消えたり、プロキシグループが参照先のノードを見つけられなくなったりします。インポート時にクライアントがテンプレートを自動生成するため、問題が見えにくくなる場合もあります。別のクライアントへ移した後で初めて問題が分かることもあります。設定を読む際は、まず最上位の構造を判別し、その後でプロトコルの項目を確認してください。ノード名だけを検索しても十分ではありません。

変換で記述形式は変えられても、不明な情報を補うことはできない

形式変換ツールは通常、既知の項目を別の構文に対応づけますが、元データに存在しない公開鍵、証明書名、プラグイン設定、トランスポートのパスを復元することはできません。変換先が対応していない機能の項目が削除される場合もあります。変換後は、プロトコルの種類、アドレス、ポート、認証情報、TLS、トランスポートの設定がそろっているかを確認してください。特にHysteria2、TUIC、拡張構成を含むVLESSのノードは注意が必要です。

共有リンクは単一のノードを渡すのに便利ですが、完全な設定にはルールの順序、プロキシグループの依存関係、ローカルでの名前解決の動作も含まれます。ノードの共有リンクを別のクライアントにインポートしても、元のネットワーク設定まで移行できるとは限りません。Surfboardなどのクライアントには独自の設定要件があります。Clash YAMLの拡張子だけを変えても使えません。形式が合わない場合は、変換を重ねて不確実性を増やすのではなく、対象クライアントに適したサブスクリプションを提供元に依頼してください。

リモート更新とローカルのルールを分ける

サブスクリプションを更新すると、通常はリモート管理の内容が置き換わります。ダウンロードしたファイルのノードやルールを直接編集すると、次回の更新で変更が失われることがあります。ノードの取得元はサブスクリプションに任せ、個人用ルール、DNS、プロキシグループはローカルの上書き設定で管理する方法が有効です。ただし、マージの順序はクライアントによって異なります。ローカルの項目でリモートの値を上書きする場合もあれば、リストに追加したり置き換えたりする場合もあります。操作前にマージの仕様を確認し、最終的にコアへ渡される設定も確認してください。

以下の例は、解析可能な最小限のルール構造だけを示したもので、リモートノードは含みません。最上位の項目の関係を説明するための例であり、既存のサブスクリプションを置き換えるものではありません。実際に使う際は、プロキシグループの名前が実在するノードまたは組み込みのポリシーを参照している必要があります。ルールは上から順に判定されるため、広い範囲を指定するルールを先に置くと、後続の細かい条件が適用されないことがあります。変更後はクライアントの設定チェックを実行し、接続ログで想定したルールが適用されているか確認してください。

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: デフォルトポリシー
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,デフォルトポリシー

DNS設定も互換性の確認対象

Fake-IPは仮想アドレスを使ってドメイン情報を保持する仕組みで、ルールや通信の取り込みと組み合わせて使います。ノードのプロトコルではありません。サブスクリプションのインポート後にDNSモードも変更すると、プロキシノードが同じでもアプリの挙動が変わることがあります。名前解決のリクエストをどこが受け取るか、OSやアプリ独自の暗号化DNSが使われていないか、想定した通信範囲が取り込まれているかを確認してください。DNSのスイッチを1つ見るだけでは、通信経路全体は分かりません。

設定のマージに関する問題を調べるときは、元の内容と最終的な設定を保存し、サブスクリプションの認証情報を隠してから関連項目を比較してください。サブスクリプションURLを不明な変換サービスにアップロードしたり、公開ログに認証情報を残したりしないでください。ドメイン名に関する問題は、DNSリクエストの経路とFake-IPの設定方法を参考にしてください。設定は一度に1グループだけ変更し、結果を確認してから次に進むことで、更新、マージ、名前解決の問題が重なるのを防げます。

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

デスクトップでのWeb閲覧、開発、大容量転送

日常的なWeb閲覧や開発ツールでは、まずサーバーの管理状況が明確で、クライアントが十分に対応している設定を使いましょう。複雑なトランスポートの組み合わせから始める必要はありません。ブラウザーは通常、システムプロキシの設定に従うため、通信経路を確認しやすい傾向があります。一方、コマンドラインツールや独立したランタイムには、個別のプロキシ設定が必要なことがあります。ターミナルからはアクセスできないのにWebブラウザーでは正常な場合、すぐにプロトコルを変えず、対象のプログラムがプロキシを使用しているか確認してください。コンテナー、仮想マシン、リモート開発環境にも独自のネットワーク設定があることがあります。

大容量ファイルをダウンロードするときは、開始直後の最高速度だけでなく、継続的なスループットと復旧能力を確認します。TCPの設定で安定している場合は、比較の基準として維持してください。経路でパケットロスが目立ち、UDPも利用できる場合は、Hysteria2やTUICと比較できます。テスト中は操作への応答や端末の負荷も確認してください。帯域パラメーターを調整して速度が上がった場合は、ほかの通信に影響がないことも確認します。短時間だけ回線を使い切る設定が、あらゆる用途に最適とは限りません。

モバイルでの移動中とリアルタイムアプリ

スマートフォンで移動中に使うと、ネットワークの切り替えや電波状態の変化、バックグラウンドでの休止が頻繁に起こります。画面ロック後の復帰、Wi-Fiからモバイル回線への切り替え、長時間アイドル状態だった後の最初のリクエストを優先して試してください。接続移行を支援する下位の仕組みが役立つ場合もありますが、クライアントとサーバーで実際に有効になっているかを確認する必要があります。固定ネットワークでは速くても、切り替えのたびに手動で再接続が必要なら、現在のモバイル利用には適さない可能性があります。

ゲームや通話では、UDP転送、適用されるルール、通信の出口を確認してください。ノードが利用可能と表示されても、リアルタイム通信がそのノードを使っているとは限りません。アプリによっては認証、メディア、更新のサーバーに同時接続し、それぞれ異なるルールが適用される場合があります。まず該当する接続を確認してから、プロトコルを変更する必要があるか判断してください。リモートデスクトップでは、画面更新、キーボードやマウスの応答、短時間のパケットロス後の復旧も重要です。ファイルのダウンロード速度だけで判断しないでください。

サーバー、ルーター、制限のあるネットワーク

サーバーやルーターでは、mihomoコアを直接管理する方法が適していることが多い一方、プロセス、権限、設定の更新、ログのローテーションを自分で管理する必要があります。リソースが限られている場合は、ルールの数や接続チェックの頻度を抑え、デバッグログがストレージを長期間使い続けないようにしてください。リモートで変更する前に、復旧用の管理経路を確保し、設定を検証してからサービスを再読み込みします。デスクトップクライアントが生成した設定をルーターへ移す場合は、ファイルパス、待ち受けアドレス、権限の違いも確認してください。

オフィスやゲスト用ネットワークでUDPが制限されている場合は、QUICを繰り返し試すのではなく、利用可能なTCP設定を先に確認してください。追加のプロキシやゲートウェイを経由する場合は、多重カプセル化や名前解決経路の違いがないかも確認します。特定のネットワークだけでノードに接続できない場合は、別のネットワークで再試行してから端末の設定を調べてください。反対に、すべてのネットワークで同じ認証段階に失敗する場合は、認証情報、証明書、プロトコルの項目を優先して確認します。

共通の受け入れ確認と切り戻し手順

初回の確認では、まず設定を読み込めるかを調べ、次に基本接続を確立し、その後でルール、DNS、対象アプリを確認します。各段階で、コアがどのプロトコルを認識したか、リクエストにどのポリシーが適用されたか、出口が想定どおりかを明確に記録してください。失敗した場合は、最後に正常動作した設定に戻します。コア、サブスクリプションの提供元、ネットワークモードを同時に変更しないでください。クライアントの異常終了とプロトコルのハンドシェイク失敗も分けて調べます。異常終了については起動時のクラッシュとログの確認方法を参考にしてください。

1. サーバー側のプロトコルとクライアントのコアを照合し、認証、トランスポート、セキュリティ層の設定を確認する。
2. 利用できることが分かっているネットワークで一般的なWebページに接続し、実際に適用されたルールを確認する。
3. 継続的なデータ転送、リアルタイムアプリ、アイドル後の復帰を個別に試し、失敗した段階を記録する。
4. 変更する項目は1つに絞り、同じタスクを再度実行して、設定を維持するか元に戻すか判断する。

最終的には、普段使う設定と、動作を確認した代替設定を1つずつ用意してください。代替設定では異なる下位の通信経路を使うのが望ましく、両方が同じ障害経路に依存するのを避けられます。ただし、認証情報と設定の入手元はどちらも信頼できる必要があります。クライアントをインストールする場合は、ダウンロードページからOSに合ったものを選び、まずはClash Plusをお試しください。具体的な手順は使い方ガイド、一般的なトラブルはよくある質問をご覧ください。プロトコルは接続方式であり、あらゆるネットワークでの結果を保証するものではありません。