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

1. プロトコル・通信方式・トラフィックの取り込みを分けて考える

クライアント上のノードは、単なるプロトコル名ではなく、複数の接続パラメーターで構成されています。プロトコルは認証やリクエストのカプセル化、データ交換の方法を定めます。通信方式はデータを運ぶ経路を決め、TLSなどのセキュリティ層がその経路を保護します。VPNやTUNは、スマホの通信をどのようにクライアントへ取り込むかを決めます。これらの階層を区別すれば、どちらもVLESSと表示された設定で互換性や接続状況が異なる理由を理解できます。

ノード名だけでは機能を判断できない

ノードには通常、サーバーアドレス、ポート、認証情報、暗号化方式のほか、通信方式に関する設定が含まれます。組み合わせによっては、サーバー名やパス、特定のハンドシェイク用パラメーターも必要です。画面に表示される名前は設定の提供元が付けたもので、自由に変更できます。名前だけで実際の種類を判断することはできません。詳細画面やエクスポートした設定を確認し、とくにtype、network、セキュリティ層の項目を見てください。「高速」などの名前やプロトコルの略称だけで判断しないようにしましょう。

プロキシプロトコルと通信方式は、自由に組み合わせられるわけではありません。あるコアがVLESSに対応していても、すべてのVLESS向け通信拡張に対応しているとは限りません。また、クライアントで共有リンクを読み込めても、リンク内の全パラメーターを反映できるとは限りません。クライアントの画面から設定できる機能が、コアの機能の一部に限られることもあります。互換性を判断するには、サーバー設定、コアのドキュメント、クライアントへのインポート結果をあわせて確認してください。どれか一つでも欠けると、誤った判断につながる可能性があります。

VPNアイコンだけでは接続先のプロトコルは分からない

スマホのステータスバーにVPNアイコンが表示されるのは、通常、クライアントがシステムの仮想ネットワークインターフェースを利用していることを示します。これは端末内で通信を取り込む仕組みであり、すべてのリモート接続が同じ従来型VPNプロトコルを使っているという意味ではありません。インターフェースに入った通信は、ルールに従ってSSやTrojanなどのプロキシ経由で送られる場合もあれば、接続先へ直接送られる場合もあります。デスクトップのシステムプロキシは、プロキシ設定に従うアプリだけが対象となるため、通信を取り込む範囲が異なります。

同様に、TUNを有効にしてもプロトコルの非互換性が自動的に解消されるわけではありません。ノードのパラメーターが間違っている場合、より多くの通信を取り込むと、影響を受けるアプリが増えるだけです。まずクライアントからサーバーへ接続できるか確認し、その後、アプリの通信がルールに入っているかを調べましょう。ログに対象アプリの接続記録がまったくない場合は、通信の取り込み範囲を確認してください。接続記録があり、ハンドシェイクに失敗している場合は、プロトコルのパラメーター、証明書、ネットワークの到達性を確認します。

接続経路に沿って問題を切り分ける

アクセスの流れは、ドメイン名の名前解決、端末内での通信の取り込み、ルール照合、プロキシグループによる経路選択、リモート側とのハンドシェイク、接続先へのリクエストに分けて考えられます。実際の処理では各段階が前後したり並行したりすることもありますが、確認の枠組みとして役立ちます。たとえば、直結では開けるサイトが開かない場合でも、すぐにプロトコルの問題とは限りません。ルールが別の出口を選んでいたり、DNSが到達できないアドレスを返していたりする可能性があります。設定を一度に一つだけ変更し、アクセス先と時刻を記録すれば、ログと症状を照らし合わせやすくなります。

2. SSとVMess：暗号化の仕組みと互換性の境界

Shadowsocksは一般にSSと略され、比較的シンプルなプロキシ転送と暗号化を重視して設計されています。VMessはV2Rayエコシステムで使われるプロトコルで、プロトコル層で認証とデータ保護を担い、さまざまな通信方式と組み合わせて利用されます。どちらも実装や設定方法が変化してきたため、「SS対応」「VMess対応」は確認の出発点にすぎません。実際に接続できるかどうかは、暗号化方式や認証設定、通信方式が一致しているかにも左右されます。

SSの設定はシンプルでも、必要な項目は省略できない

SSの主なパラメーターは、サーバーアドレス、ポート、パスワード、暗号化方式です。現在の設定では認証付き暗号方式がよく使われますが、方式によって鍵の扱いやデータのカプセル化は異なります。名前が似ていても、互いに置き換えられるわけではありません。サブスクリプションで新しいプロトコル拡張や特定のプラグインを使っている場合、古いコアでは読み込みが拒否されたり、基本的なノード情報だけ読み込めても接続できなかったりすることがあります。サーバー側で指定された組み合わせをそのまま使い、項目を独自に置き換えないでください。

暗号化方式の処理負荷は、端末のハードウェアによって変わります。特定の命令セットによる高速化に対応したチップは、あるアルゴリズムを効率よく処理できる一方、別のアルゴリズムのほうが適したプロセッサもあります。スマホの発熱は、無線の電波状況、通信量、バックグラウンドアプリ、画面の明るさにも左右されます。「アルゴリズム名が短いから省電力」とは限りません。また、性能を試すために暗号化方式をむやみに変更しないでください。クライアントとサーバーで設定が一致しなければ、通常は接続できません。

SSではUDP転送への対応も個別に確認が必要です。クライアントでUDPを許可していても、サーバー、ルーター、通信事業者のネットワークが該当するデータを通すとは限りません。主にTCPを使うウェブ閲覧では、UDPが使えないことに気付かない場合がありますが、ゲーム、音声通話、一部の名前解決では問題が表面化します。ウェブは使えるのにリアルタイムアプリだけが不安定な場合は、ノードのUDP対応とルールによる経路選択を確認してください。すぐにDNS全体を変更したり、同じサブスクリプションを何度も読み込み直したりする必要はありません。

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

VMessの一般的な設定では、ユーザー識別にUUIDを使い、セキュリティオプションや通信方式のパラメーターを含む場合があります。認証の仕組みには時刻が関係するため、端末の時計が大きくずれていると接続に失敗することがあります。その場合は、まずシステムの日時を自動設定にし、タイムゾーンと時刻が正しいことを確認してから、サーバー側の認証設定を調べてください。DNSを何度変更しても認証情報の不一致は解消できません。接続の階層に沿ったトラブル対処が、複数の設定を同時に変えるより効果的な理由の一つです。

VMess over TCPとVMess over WebSocketでは通信経路が異なります。WebSocketはリバースプロキシを経由する場合もあり、正しいパス、リクエストヘッダー、TLS設定が必要です。サーバーアドレスは基盤となる接続に使われ、TLSのサーバー名はハンドシェイクに使われます。WebSocketのHostはアプリケーション層のリクエストに属します。これらは同じ場合もあれば、異なる場合もあります。サブスクリプション内のドメイン名らしい項目をすべて同じ値に変更したり、別のノードから汎用に見える設定をコピーしたりしないでください。

古い設定を移行するときは、違いを維持する

古いVMess設定には、以前の認証方式や廃止された項目が含まれていることがあります。新しいコアで構文チェックに通っても、サーバー側でその組み合わせが受け付けられるとは限りません。まず設定の提供元から、現在のコアに対応した項目を入手し、読み込み前後の重要な項目を比較してください。変換ツールが一部のパラメーターを通知なく無視した場合、画面上にノード名が表示されても、後の接続段階で失敗することがあります。「インポート成功」を完全な互換性と同じ意味に捉えないでください。

古いサブスクリプションを残したまま試す場合は、普段使いの設定を上書きせず、別の設定で検証してください。一部のノードだけ失敗するなら、そのノードの暗号化方式と通信方式を比較します。すべてのノードが失敗するなら、認証情報の入手元、端末の時刻、設定全体の形式を確認しましょう。こうすれば、ノード固有の問題とクライアントの読み込み問題を切り分けやすくなり、再インストールの繰り返しも避けられます。

3. TrojanとVLESS：セキュリティ層と通信方式の組み合わせ

Trojanは一般に、TLS接続内にプロキシリクエストを載せ、実績のあるTLSの仕組みで通信を保護し、パスワードで認証します。一方、VLESSはプロトコル層を軽量に設計し、データ保護を外部のセキュリティ層に委ねることを重視しています。同じ種類のサブスクリプションに両方が含まれることはありますが、セキュリティ上の役割は異なります。プロトコル名だけでなく、TLS、REALITYなどの組み合わせ要件も確認してください。プロトコル名だけで必要なセキュリティ機能がすべて備わっていると考えてはいけません。

TrojanではTLSを正しく確立できるかが重要

Trojanノードでは、サーバー、ポート、パスワードに加え、TLSのサーバー名と証明書の検証設定が正しいことを確認してください。接続先のアドレスにはドメイン名とIPアドレスのどちらも使えますが、接続先の本人確認に使う名前は、サーバー証明書やサーバー設定と一致している必要があります。証明書の期限切れ、証明書チェーンの不足、名前の不一致があると、認証前に接続が終了することがあります。その場合はハンドシェイク関連のログを確認し、接続モードを何度も変えるのではなく、時刻、名前、証明書の設定を先に確認しましょう。

証明書の検証を無効にすると、接続先の本人確認が弱まるため、恒久的な解決策には適しません。サブスクリプションで検証を省略するよう指定されている場合は、その設定理由と信頼できる範囲を確認してください。自分で運用するサーバーなら、証明書チェーンと名前の設定を修正しましょう。スマホでログインが必要なWi-Fiを使う場合は、まずネットワークへのログインを済ませてください。ログイン画面が最初のリクエストを遮断し、リモート側のTLS障害のように見えることがあります。正常に使えると確認済みの別ネットワークと比較すれば、端末側の接続とサーバー側の問題を切り分けやすくなります。

TrojanではTCPとTLSの組み合わせが一般的ですが、ほかの通信方式に対応する実装もあります。WebSocketやgRPCなどの追加レイヤーは、多くの場合リバースプロキシの構成に関係するもので、クライアント側だけで有効にしても最適化にはなりません。設定が必要な項目や中継箇所が増えるためです。通常のTCP構成で要件を満たせるなら、名前に含まれる要素を増やすためだけに通信方式を重ねる必要はありません。サーバーが特定のパスを必要とする場合は、指定どおり正確に設定してください。

VLESSの軽量設計には前提がある

VLESSのプロトコル層自体は汎用のデータ暗号化を行わないため、インポート後は外部のセキュリティ層を確認してください。UUIDがあるだけで接続が保護されていると判断してはいけません。一般的な設定ではTLS、または実装が対応するREALITYの組み合わせを使用します。組み合わせによって必要な項目は異なります。また、クライアントがVLESSに対応していても、関連するすべてのフロー制御やハンドシェイク方式に対応しているとは限りません。実際に使うコアの機能ドキュメントを確認し、とくにモバイル版の画面で必要な項目を保持できるか調べてください。

設定のflowは、双方の対応が必要なプロトコル関連の項目であり、汎用的な速度設定ではありません。別のノードのフロー制御値を流用すると、互換性が損なわれる場合があります。REALITY関連の公開鍵、短いID、サーバー名も、対象のサーバーから取得する必要があります。適当に組み合わせてはいけません。パラメーターがそろっていない場合は、元の情報を確認するか、提供元が対象クライアント向けに用意した互換性のあるサブスクリプションを使いましょう。値をランダムに変えて試すのは避けてください。

変更する価値があるかの判断

現在のTrojanノードが安定している場合、VLESSに変えてもウェブページの表示が速くなるとは限りません。逆に、プロトコルヘッダーが軽量でも、サーバーの混雑は解消できません。まず接続の確立しやすさ、長時間接続の安定性、ネットワーク切り替え後に再起動が必要かを比較し、その後に継続的な通信速度を確認しましょう。通勤中や画面ロックを繰り返す場面では、短時間のダウンロード速度のピークより、復旧の速さやバックグラウンドでの安定性が実用上重要です。

トラブル対処では、接続先に到達できない、TLSなどのセキュリティ層のハンドシェイクに失敗する、ユーザー認証に失敗する、接続先への転送に失敗する、の4種類に分けて考えられます。ログの表現はコアによって異なるため、決まったエラーメッセージだけを探すのではなく、どの段階で失敗したかを確認してください。一度にテストするノードは一つにし、プロキシグループを一時的に固定します。自動選択中に別の設定へ切り替わると、変更した設定とテスト対象が食い違う可能性があります。

4. Hysteria2とTUIC：QUICベースの通信方式を比較する

Hysteria2とTUICはどちらもQUIC関連技術を基盤とし、プロキシ用途に合わせて信頼性のあるストリームやデータグラムを扱います。QUICは通常UDP上で動作し、ユーザー空間で接続、暗号化、輻輳制御を処理します。「アプリのUDP通信をそのまま転送する」仕組みとは別です。接続先のウェブサイトがTCPを使用していても、プロキシ区間ではQUICを使うことがあります。まずスマホからサーバーまでのUDP経路が使えるか確認してください。

QUICで変わること

従来のTCPバイトストリームは順番にデータを届けるため、パケットが一つ失われると、同じ接続の後続データが再送を待つことがあります。QUICは異なるストリーム間の相互ブロックを軽減できますが、単一の信頼性のあるストリーム内では順序を保つ必要があり、帯域や輻輳の制約も受けます。パケット損失をなくす仕組みではなく、物理回線の容量を超えることもできません。ネットワーク状況が良好な場合、ユーザー空間での追加処理が、成熟したTCP実装より省リソースとは限りません。実際のアクセス状況で判断してください。

QUICには接続の移行に関する仕組みがありますが、スマホがWi-Fiからモバイルネットワークに切り替わったときにスムーズに復帰できるかは、プロトコルの実装、クライアントのライフサイクル、ネットワークアドレスの変化、サーバー側の方針にも左右されます。基盤技術の機能が、すべてのクライアントで保証されるわけではありません。切り替えをテストするときは、ステータスバーのVPNアイコンが表示され続けるかだけでなく、既存のセッションが復旧するか、新しいリクエストを開始できるかを確認してください。

Hysteria2の帯域パラメーターは控えめに設定する

Hysteria2は、損失や変動の大きい経路を想定した通信方式を備えています。帯域の推定値を使って送信を制御する場合、設定した上下方向の数値は送信動作に影響するもので、ユーザーに表示する速度測定結果ではありません。実際に利用できる帯域を大きく上回る値を設定すると、キューの増加やパケット損失、ほかのアプリへの影響につながる可能性があります。クライアントとサーバーのネゴシエーション方法を理解したうえで、控えめな値から検証してください。別の輻輳制御方式を使う場合も、同じ設定の経験をそのまま当てはめないでください。

サーバー側で送信動作が制限されることがあり、サブスクリプションに適切な値がすでに設定されている場合もあります。モバイル通信プランの公称速度は、現在の無線環境やリモートまでの経路で安定して使える通信速度と同じではありません。動画が途切れやすくなり、システムのネットワークキューが増えたり、ほかのアプリが明らかに遅くなったりした場合、帯域の値をさらに引き上げるのは通常適切ではありません。まず目標値を下げ、テストの負荷を減らし、電波状況やサーバーのリソースがボトルネックになっていないか確認してください。

TUICの多重化とデータグラムの選択

TUICはQUICのストリームとデータグラム機能を使ってプロキシリクエストを転送します。認証情報と輻輳制御の設定は、クライアントとサーバーで一致している必要があります。実装によっては、UDP転送方式、接続のキープアライブ、0-RTT関連のオプションを利用できます。0-RTTは、確立済みの信頼状態と実装側の方針に依存し、リプレイ攻撃に関する安全性の考慮も必要です。初回接続のたびにハンドシェイクを省略できるわけではありません。「速くなる」ことを期待して、表示されている設定をすべて有効にしないでください。

信頼性のある通信と信頼性のないデータグラムには、それぞれ異なる用途があります。音声通話やゲームでは、古くなったデータを再送しても意味がない場合があります。一方、完全なデータ配信が必要なリクエストでは、対応する層が信頼性を確保する必要があります。サブスクリプションのUDPモードは、サーバーの機能とアプリの要件に合っていなければなりません。リアルタイムアプリだけに問題がある場合は、ブラウザーが正常だからといってQUIC経路全体に問題がないと判断せず、データグラムの経路やMTUなどを確認してください。

プロトコルの世代が変わると、認証方式や設定構造も異なる場合があります。HysteriaとHysteria2は表示名を変えるだけでは置き換えられません。TUICも、世代に応じた対応が必要です。インポート前に、提供元がどの実装と形式を指しているか確認してください。画面に重要な設定項目が見当たらない場合は、似た名前のノードを次々に試すより、実際の設定やコアのエラーを確認するほうが効果的です。

5. 接続速度・リソース使用量・スマホの電池消費

「プロトコルの速度」は、少なくとも初回接続にかかる時間、リクエストへの応答、継続的な通信速度、障害からの復旧という4つの観点で考える必要があります。ウェブページの表示が遅い原因はDNSやハンドシェイクかもしれません。ファイルのダウンロードが遅い場合は、輻輳やサーバーの速度制限が考えられます。ゲームの遅延は、ジッターやパケット損失が原因かもしれません。これらを一つの遅延値にまとめると、実際のボトルネックを見落とします。スマホでの測定は、端末の温度、バッテリーモード、無線方式の変化にも左右されます。一度だけ短時間測定して、長期的な選択を決めるのは適切ではありません。

遅延テストだけでは実際のアクセス状況は分からない

クライアントの遅延テストは、通常、指定したアドレスにリクエストを送って測定します。名前解決やハンドシェイク、接続の再利用が測定に含まれるかは、実装や既存の接続状態によって異なります。単純なネットワーク往復時間とは限らず、すべての接続先での状況を表すものでもありません。テスト先が異なるノード同士の結果は、直接比較に向きません。測定方法を理解したうえで、ノードの遅延測定とアクセス確認の手順を参考に、普段使う接続先でも確認してください。

比較するときは、できるだけ同じ場所、同じネットワーク、近い時間帯で、プロキシグループの選択を固定してください。まず少数のウェブページで初回の応答を確認し、次に正規の安定したダウンロード先で継続的な転送を調べます。最後に画面ロック後の復帰とネットワーク切り替えをテストしましょう。複数の速度測定を同時に実行すると、帯域を奪い合ってキューの状態も変わるため避けてください。一時的な最高速度より、まれに停止するか、再接続後に復旧するか、バックグラウンドで通信が途切れるかなどの状況を記録するほうが役立ちます。

CPU、メモリ、電池消費は別々の指標

暗号化と復号、データのコピー、ユーザー空間のネットワークスタック、ルール照合は、いずれも計算リソースを使います。メモリ使用量は、アクティブな接続数、ルールセット、DNSキャッシュ、ログバッファーにも左右されます。基本的なデータ形式が小さいプロトコルでも、設定全体のメモリ使用量が必ず少なくなるわけではありません。大量の接続を維持したり、大きなルールセットを読み込んだりする影響は、プロトコルヘッダーの違いより大きい場合があります。プロトコルに固定のリソース順位を付けるのではなく、同じタスクで設定全体の動作を比較してください。

スマホの電池消費は、プロセッサーと無線モジュールの両方に左右されます。アプリのCPU使用率が低くても、キープアライブ、ヘルスチェック、サブスクリプションの更新頻度が高すぎると、無線通信が何度もアクティブになることがあります。電波が弱い状態で再送が増えると、さらに電力を消費します。待機中に電池が減る場合は、まずシステムの電池使用状況とバックグラウンド動作を確認し、クライアント、前面で使うアプリ、無線電波の影響を切り分けてから、チェック頻度を調整してください。ノードの種類だけで原因を決めつけないようにしましょう。

バックグラウンドの安定性とチェック頻度のバランス

プロキシグループの自動選択には、通常ヘルスチェックが必要です。チェック頻度を上げると変化を早く検知できますが、追加リクエストや接続維持の負荷も増えます。同じノードを複数のグループで繰り返しチェックすると、負荷が積み重なります。頻繁な自動切り替えが本当に必要かを確認し、必要に応じて間隔を長くするか、対象を絞りましょう。接続が安定しているスマホでは、控えめな設定のほうが電池の消費を予測しやすくなります。

Androidでは、必要に応じて使用中のクライアントのバックグラウンド制限を調整できますが、すべてのアプリでバッテリー管理を無効にする必要はありません。iOSのネットワーク拡張は、システムのライフサイクルやリソースの制約を受けるため、デスクトップの常駐プロセスと同じようには扱えません。端末が発熱したり、システムのメモリが不足したりする場合は、クライアントを変更する前に、同時テスト、詳細ログ、不要なルールを減らしてください。性能改善の目的は日常利用の安定性であり、高度な設定をすべて有効にすることではありません。

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

Clashは、初期のプロキシコアを指す場合もあれば、その設定方式に対応するクライアントエコシステム全体を指す場合もあります。Metaは関連する基盤から発展したフォークの名称で、mihomoはその後に使われるようになったコアの名称です。これらには継承関係がありますが、すべての機能が前後のバージョンで完全に互換というわけではありません。クライアントで使える設定を判断するには、アプリ名にClashが含まれているかではなく、実際に搭載されているコアとその機能を確認してください。

実行を担うコアと、操作・連携を担うクライアント

コアは通常、ノード接続、ルール処理、DNS、プロキシグループなどを担当します。グラフィカルクライアントは、サブスクリプション管理、権限の要求、設定画面、バックグラウンドサービス、システム通信の取り込みを担います。プロジェクトによって両者の境界は異なりますが、この区別は問題の切り分けに役立ちます。同じコアを異なるクライアントに組み込んでも、設定のインポート、上書きの順序、システムルートは変わる可能性があります。画面にある設定スイッチが、すべてのプラットフォームで同じように動作するとも限りません。

オリジナルのClashの基本設定形式は、多くのサブスクリプション形式に影響を与えました。ただし、公開されたオープンソース実装、過去に存在した別の配布形態、その後のフォークは区別する必要があります。mihomoはプロトコルやルールなどの機能を拡張し、それに伴って独自の項目も追加されています。新しいプロトコルや拡張構文を含む設定は、古いコアや機能の異なるコアでは読み込みを拒否される可能性があります。YAML形式の見た目が同じでも、意味や機能まで互換とは限りません。

クライアント選びでは実際の対応機能を確認する

当サイトのインストール案内ではClash Plusを最初に紹介しています。まずは端末のプラットフォームから利用できるインストール方法を確認してください。特定のプロトコル、ルール拡張、システム通信の取り込み機能が必要な場合は、各プラットフォームの説明を確認しましょう。あるプラットフォームの機能を、別のプラットフォームでも使えると考えてはいけません。デスクトップではClash Verge Rev、FlClash、Clash Nyanpasuを比較できます。AndroidではClash Meta for Android、FlClash、Surfboardを確認できます。対応する設定やプロトコルの範囲は、それぞれ個別に確認してください。

Surfboardは独自の設定形式を使うため、プロキシを管理できるという理由だけで、Clash YAML全体を同等の入力として扱うことはできません。Clash for WindowsとClashX Metaは、メンテナンスが終了したアーカイブ済みの選択肢です。過去の設定を確認したり古い端末から移行したりする用途には使えますが、現在のプロトコル対応状況を推測する材料にはなりません。iOSのインストール方法や機能は、対象アプリの説明を確認してください。Android向けのコアファイルをiOSクライアントに直接インストールすることはできません。

具体的な選び方はクライアント選びのガイドを参照してください。インストーラーと各プラットフォームへのリンクはダウンロードページにまとめています。クライアントでコア情報を確認できる場合は、コア名とビルド情報を記録し、設定内のプロトコルとあわせてトラブル対処に役立ててください。アプリ名しか分からず、コア情報が提供されていない場合、高度な設定項目が使えない理由を判断するのは困難です。

コアとアプリは別々に更新後の動作を確認する

アプリと同時にコアを更新するクライアントもあれば、個別に切り替えられるクライアントもあります。更新前に、現在のサブスクリプションの入手元、ローカルの上書き設定、必要な設定を保存し、元に戻せることを確認してください。自動生成された実行用ファイルだけをバックアップするのは避けましょう。クライアントによって書き換えられたポート、パス、システム設定が混在している可能性があり、別の端末でそのまま再利用できない場合があります。更新後はまず読み込みログを確認し、ノード、DNS、ルール、バックグラウンド動作を検証してください。

更新後に起動時の問題が発生した場合は、まず最小限の読み込み可能な設定に戻し、構文の非互換性とシステム権限の衝突を切り分けてください。プロジェクトの系譜について詳しく知りたい場合は、Clash、Meta、mihomoの関係を解説した記事を参照してください。名称の変遷を理解する目的は機能の由来を確認することであり、特定のフォーク名を性能や信頼性の保証として扱うことではありません。

7. サブスクリプション形式・項目の保持・ルールの互換性

サブスクリプションURLから取得する内容は、YAML形式の完全な設定ファイル、ノード一覧、共有リンクの集合、または特定のクライアント向け形式などさまざまです。完全な設定には、ノードのほか、プロキシグループ、ルール、DNS、リモートルールの取得元が含まれる場合があります。ノード一覧に含まれるのは通常、出口の情報だけです。インポート後にノードが表示されても、完全な振り分け設定を取得できたとは限りません。まずサブスクリプションの種類を確認し、ルールをサブスクリプション側で管理するか、ローカル設定からノードを参照するかを決めてください。

構文を解析できても、設定の意味が互換とは限らない

YAMLのインデント、項目の型、リスト構造によって、ファイルを解析できるかどうかが決まります。プロトコルの対応状況、プロキシグループの参照先、ルールの動作によって、設定どおりに実行できるかどうかが決まります。たとえば、存在しないグループをルールが参照している場合や、現在のコアが未対応の種類をノードが使っている場合、正しいYAMLであっても正常に接続できません。ログの構文エラー、項目のエラー、実行時エラーはそれぞれ異なる段階の問題です。後から発生した連鎖的なエラーを一つずつ独立した障害として扱わず、最初に起きた問題から解決してください。

形式変換はプロトコル変換ではありません。変換ツールで項目名を変更したり、ノードを並べ替えたり、ルールを生成したりすることはできますが、コアにプロトコルの実装を追加したり、不足している認証パラメーターを補ったりすることはできません。元の形式で表現できないフロー制御、セキュリティ層、データグラムの設定は、変換後に省略される可能性があります。複雑なノードでは変換前後の重要項目を比較してください。保持されたか確認できない場合は、複数回変換を重ねるのではなく、対象クライアント向けに調整された設定を提供元に依頼しましょう。

ルールの順序と名前の参照先をあわせて確認する

Clash形式のルールは通常、上から順に照合され、最初に一致したルールで出口が決まります。範囲の広いルールを早い位置に置くと、それ以降の詳細なルールに到達しないことがあります。以下はルールの一部であり、完全な設定ではありません。カスタムプロキシグループは参照しておらず、順序を理解するための例です。直結の例も、すべてのユーザーに同じ振り分け方針が適しているという意味ではありません。実際に使う場合は、対象サービスと用途に合わせて調整し、更新時にクライアントがローカルの変更を上書きしないことを確認してください。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

DOMAIN-SUFFIXはドメインの末尾で照合します。GEOIPは対応する地理情報データと名前解決の条件に依存し、MATCHは最後の受け皿として使います。プロキシを経由させる場合は、実際に存在するプロキシグループ名をアクションに指定してください。別の設定からグループ名をそのままコピーしないようにしましょう。IPルールでは、ドメイン名の解決が行われるか、追加の名前解決を避ける設定が使われているかも確認してください。これを把握していないと、ドメインルールが動作していないと誤解することがあります。

ルールの書き方について詳しくは、カスタムルールとスマホでの上書き設定のコツを参照してください。ローカルの追加ルールは、クライアントが対応する上書き機能や統合機能に配置すると、リモートのサブスクリプションを直接編集するより管理しやすくなります。クライアントによって、既存の設定を置き換える、追加する、専用スクリプトで処理するなど、統合方法が異なります。同じ名前のリストが自動で統合されるとは限らず、編集画面上の位置だけで最終的な順序を判断することもできません。

更新の失敗と取得内容の変化は分けて対処する

更新が失敗する原因には、URLの無効化、認証の期限切れ、ダウンロード経路への到達不能、応答形式の誤りなどがあります。リクエストが成功しても、内容が有効とは限りません。ログイン画面、案内ページ、空の応答が設定ファイルとして保存されることもあります。まず更新ログと取得した内容の種類を確認し、必要であれば更新リクエストの出口を変更するか判断してください。アクセス権のあるサブスクリプションURLを公開の問い合わせ欄に貼ったり、信頼できない変換サービスにアップロードしたりしないでください。

端末を移行する場合は、リモートの設定元とローカルルールを分けてエクスポートし、認証情報は隠してください。新しい端末だけで問題が起きるなら、同じ最小構成でコアの機能を比較しましょう。複数の端末で同時に失敗する場合は、サブスクリプションの提供元とサーバーの状態を確認してください。問題の範囲を一つの階層に絞るほうが、すべてのデータを削除するより既存の振り分け設定を保ちやすくなります。

8. DNSの経路・用途別の選び方・確認手順

DNSはドメイン名からIPアドレスを取得し、ドメインルールの判定に必要な情報にも影響します。プロキシプロトコルそのものではありませんが、設定に問題があると、ノードは使えるのに一部のアプリだけ開けないことがあります。DNS漏れを調べるには、まずどの問い合わせをどの経路に通す想定なのかを明確にし、実際の動作が一致しているか確認してください。暗号化通信で名前解決することと、プロキシ経由で問い合わせることは別の問題です。暗号化DNSを有効にしても、リクエストがローカルネットワークから直接送られる場合があります。

接続先のドメインとノードのドメインの名前解決を区別する

クライアントは、ユーザーがアクセスするドメインだけでなく、プロキシサーバーのドメイン名も解決する場合があります。ノードのドメインを解決するために、まだ確立していないプロキシ接続に依存すると、循環が起きることがあります。この問題を避けるため、独立したリゾルバーやノード専用の名前解決設定を使う構成もあります。DNSを変更する前に、現在のコアにおける項目の意味を確認してください。別のコアにある同名の設定を機械的に適用しないでください。エラーでサーバー名の名前解決失敗が最初に記録されている場合は、まずこの基本経路を復旧させましょう。

Fake-IPは合成アドレスを割り当て、後続の接続でもドメインとの対応関係を保持できるようにします。もう一つの方式では、名前解決で実際のアドレスを返します。Fake-IPがウェブサイトの実際のアドレスを変更するわけではなく、すべての迂回問い合わせを自動的に防ぐわけでもありません。LAN内機器の検出、一部のゲーム、独自にDNSを処理するアプリでは例外設定が必要になることがあります。例外は該当するドメインと症状に合わせて追加し、すべてのドメインを除外して本来必要なドメインとの対応付けを失わないようにしてください。

IPv6もあわせて確認してください。IPv4のプロキシ経路だけを設定し、システムやアプリがIPv6を直接使い続けると、想定と異なるアクセスになる可能性があります。デュアルスタックのルーティング、クライアントが通信を取り込む範囲、DNSの応答方針を確認したうえで、特定の環境で一方のスタックを制限するか判断してください。IPv6の無効化は切り分けには使えますが、すべてのスマホに共通する最適化策ではありません。また、通信の取り込みルールが不完全な問題を隠すことにもなります。

用途に合わせた構成を選ぶ

日常のウェブ閲覧やメッセージでは、サーバーのパラメーターがそろっており、初回接続が安定し、バックグラウンドから正常に復帰できる設定を優先しましょう。SS、VMess、Trojan、VLESSのいずれでも要件を満たせる場合があります。使えている構成を、プロトコルの新旧だけを理由に変更する必要はありません。モバイルワークでは、ビデオ会議、ファイル転送、画面ロック後の復帰も追加でテストしてください。LAN内の機器にアクセスする場合は、直結ルールとローカルの名前解決を個別に確認し、プリンターやストレージへのリクエストがリモート側へ送られないようにしましょう。

音声通話やゲームなどのリアルタイム通信では、UDP対応、ジッター、ネットワーク切り替え時の動作を確認してください。ウェブのテスト結果だけでは比較できません。変動の大きい回線ではHysteria2やTUICを比較できますが、まずUDP経路が使えることを確認し、TCP系の出口も予備として残しましょう。大容量ファイルの転送では、継続的な速度、端末の温度、ほかのアプリへの影響を確認してください。速度のピークを追い求めて帯域の推定値を高くしすぎないようにしましょう。電池を節約したい場合は、プロトコルを何度も変えるより、不要な再接続や重複したチェックを減らすほうが直接的です。

変更は最小限にして検証する

次の順序で問題を切り分けてください。ネットワークに正常にログインでき、基本的なサービスへアクセスできることを確認します。次にノードのアドレスを解決でき、ハンドシェイクのパラメーターが一致していることを確認してください。プロキシグループを固定して一つの接続先をテストし、接続ログでどのルールに一致したかを調べます。最後にDNS、IPv6、システム通信の取り込み範囲を確認します。各手順の前後で結果を記録し、コア、サブスクリプション、ネットワークを同時に変更しないでください。特定のアプリだけに問題がある場合は、独自の名前解決、特殊な通信方式、ブラウザーとは異なる接続方法を使っていないか確認しましょう。

DNSの経路を検証するときは、クライアントの接続記録、名前解決のログ、想定する出口をあわせて判断してください。ブラウザーに表示されるDNS事業者名は手がかりにすぎず、すべてのアプリの問い合わせが想定どおりだと証明するものではありません。詳細ログを一時的に有効にした場合は、確認後に通常のログレベルへ戻してください。記録を共有する前に、サブスクリプションURL、認証情報、個人のアクセス履歴を削除しましょう。問題が解決した後は、画面ロック、ネットワーク切り替え、バックグラウンドでの動作も再確認し、前面でのブラウザー利用だけが直った状態で終わらないようにしてください。