Clashプロトコルとカーネル技術リファレンス

1. まずプロトコルの選び方を整理する

プロトコル、トランスポート層、クライアントは別の層

Clashクライアントのプロキシ設定には通常、プロトコルの種類、サーバーアドレス、ポート、認証情報、トランスポート方式、各種拡張パラメーターが含まれます。画面に表示される「VLESS」「Trojan」「hysteria2」は最上位のプロトコル種別を示すだけで、実際の使用感を単独で決めるものではありません。同じプロトコルでも、安定した有線ネットワークと基地局を頻繁に切り替えるモバイル回線では結果が大きく異なります。同じサーバーでも、輻輳制御、TLS設定、下位トランスポートを変更すれば、接続時間やリソース消費は変わります。

クライアントは設定とカーネルを包む外側の入れ物です。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for AndroidなどのGUIクライアントは、サブスクリプション管理、システムプロキシ、TUNの切り替え、ログ表示を担当します。実際にプロトコルを解析して接続を確立するのはカーネルです。プロトコルを利用できるか判断するときは、クライアントが採用するカーネル、そのカーネルがプロトコルのフィールドを認識するか、サブスクリプション変換で必要なパラメーターが保持されるか、実行環境が必要なネットワーク機能を許可しているかを順番に確認してください。

接続速度だけで比較しない

選定では少なくとも、初回ハンドシェイクの往復回数、接続確立後のスループットの安定性、パケットロスからの復旧方法、端末を継続稼働させたときのリソース負荷の4点を確認します。TCP系プロトコルは理解しやすく、OSのネットワークスタックや家庭用ルーターの対応も成熟しています。QUICやUDPベースの方式は、高遅延やある程度のパケットロスに強い一方、再送、輻輳制御、接続状態を自前で管理するため、パラメーターの組み合わせとサーバー実装がより重要になります。

「接続が速い」という評価も、3つの段階に分けて考える必要があります。第1段階はDNS検索とサーバーアドレスの取得、第2段階はTCP、TLS、QUICセッションの確立、第3段階は対象サイトとのデータ交換です。名前解決が遅いのに問題をプロキシプロトコルのせいにすると、誤った結論になります。サーバーの負荷が高い場合、クライアント上のプロトコル名を変更してもスループットは改善しません。テストではサーバー、回線、時間帯、対象リソースをそろえ、変更する変数を1つだけにしてください。

制約を確認してから好みを考える

プロトコル選びは通常、6種類から自由に選ぶのではなく、現在のサーバーが提供していないもの、カーネルが対応していないもの、ネットワーク環境に合わないものを先に除外します。サブスクリプションがSSノードしか含まない場合、クライアント上でそれを直接Hysteria2に変換することはできません。VLESSの設定にサーバーが要求するRealityパラメーターがない場合も、種類フィールドだけを変更して接続することはできません。正しい手順は、まず完全な設定を確認し、利用可能な候補の中で比較することです。

多くのデスクトップユーザーにとっては、理論上の最大速度より安定性、設定の透明性、障害の切り分けやすさが重要です。モバイル回線を頻繁に使う場合は、ネットワーク切り替え後の復旧速度と電池消費を重視してください。クライアントを先にインストールする場合は、Clashダウンロードページから対応プラットフォームを選べます。デスクトップとモバイルのどちらでも、まずClash Plusを確認し、その他のクライアントはOSとインターフェースの好みに応じて選んでください。

2. 代表的な6種類のプロトコルを比較する

Shadowsocks：構成が簡潔で互換性が広い

Shadowsocksは通常SSと略されます。基本設定はサーバー、ポート、パスワード、暗号化方式で構成され、プロトコル自体が比較的シンプルなため、長年にわたり多くのクライアントとサーバー実装で利用されてきました。ClashユーザーにとってSSの主な利点は、設定項目が少なく、移行コストが低く、障害の範囲を特定しやすいことです。双方が同じ暗号化方式と認証情報を使う限り、基本接続で追加のトランスポート層ネゴシエーションが必要になることは通常ありません。

構成が簡潔でも、すべてのSS設定が完全に互換するわけではありません。一部のサーバーはプラグインや独自拡張を追加し、pluginとplugin-optsで追加のトランスポートを指定します。カーネルが該当プラグインに対応していない場合、基本的なSS機能は使えても、その設定は想定どおり接続できません。現在の設定ではAEAD暗号化方式が一般的です。古いアルゴリズム名が見つかった場合は、YAMLの大文字・小文字を何度も変えるのではなく、まずカーネルが受け付けるか確認してください。

VMess：項目が多く、過去の設定も多い

VMessはV2Rayエコシステムと密接に関係し、設定にはuuid、alterId、cipher、network、TLS、WebSocketなどのフィールドがよく登場します。かつて多くのサブスクリプション形式で採用されたため、古い設定やクライアント間の変換結果でも現在なお頻繁に見かけます。VMessの利点は成熟したエコシステムと豊富なトランスポートの組み合わせです。一方で設定階層が多く、どれか1つでもサーバーと一致しないとハンドシェイクに失敗することがあります。

VMessを扱うときは、プロトコルの認証情報とトランスポート情報を明確に分けて確認します。uuidは認証情報、networkは下位トランスポート、ws-optsやgrpc-optsは具体的なパスやHostフィールド、tlsとservernameはセキュアセッションに影響します。サブスクリプション変換でuuidとアドレスだけが残り、WebSocketのパスが失われると、生成された設定は一見完全でも実際には利用できません。alterIdは過去の設定でよく使われる項目であり、新しい設定で必要かどうかはサーバーの出力に従ってください。

Trojan：TLSを基盤とした明快な構成

Trojanの代表的な設定は、パスワード、TLSのサーバー名、任意のトランスポートパラメーターで構成されます。標準的なTLS機能でセキュアセッションを確立するため、多層的なVMess構成より設定を読み解きやすいのが特徴です。安定したTLS環境を用意できるサーバーでは、Trojanは保守しやすい選択肢になりやすいでしょう。クライアント側で多い問題はプロトコルそのものではなく、servername、証明書名、システム時刻、トランスポートパスの不一致です。

skip-cert-verifyをtrueにすると証明書検証エラーを回避できる場合がありますが、通常の修正方法として扱うべきではありません。まず端末の時刻、サーバー名、証明書チェーン、サブスクリプションのフィールドを確認してください。サーバーがWebSocketやgRPCを使う場合、Trojan設定にも対応するパラメーターが必要です。TLSが表示されているからといって、下位トランスポートが必ず通常のTCPとは限りません。

VLESS：認証とトランスポートをさらに分離

VLESSは軽量なプロトコル層を重視し、暗号化とトランスポートの安全性をTLSやRealityなど外部の仕組みに委ねる設計です。設定ではuuidでユーザーを識別しますが、実際に接続できるかはflow、network、servername、reality-optsなどの組み合わせに大きく左右されます。トランスポート構造を明確に制御したい環境に適している一方、サブスクリプションとカーネルがこれらの拡張フィールドを完全に理解している必要があります。

RealityはVLESSと組み合わせて使われる代表的な機能であり、VLESSから切り離して単独で指定する一般的な暗号化オプションではありません。通常、クライアントにはpublic-key、short-id、servernameなどの情報が必要です。サブスクリプション変換後にフィールド名が変わったり階層が失われたりすると、ログ上はハンドシェイク失敗としか見えないことがあります。トラブル時は元の共有リンク、変換後のYAML、カーネルログを照合し、問題が取得元、変換、実行のどの段階で発生したかを確認してください。

Hysteria2：変動する回線向けのQUIC方式

Hysteria2はQUICとUDPを基盤とし、高遅延、パケットロス、帯域幅の急変がある環境での転送効率を重視します。一部の不安定なネットワークで、従来のTCPにおける先頭行ブロッキングの影響を抑え、帯域幅、難読化、TLS関連パラメーターによって動作を調整できます。ただし、この利点を生かすにはクライアントとサーバー間のUDP経路が安定し、サーバーのパラメーターと証明書設定が正しいことが前提です。

Hysteria2は帯域幅の数値を大きくすればよいわけではありません。設定した上り・下り帯域幅は輻輳制御の判断に使われるため、実際の回線能力を大きく上回る値はキューイングやパケットロスを招き、低すぎる値は利用可能なスループットを制限します。一部のmihomo設定では帯域幅を省略し、より汎用的な輻輳制御を利用できます。サーバーが提供する設定に従い、速度テストのピーク値だけを根拠に勝手に増やさないでください。

TUIC：低遅延接続とモビリティを重視

TUICもQUICを基盤とし、一般的な設定にはuuid、password、輻輳制御アルゴリズム、UDPリレー方式、SNIが含まれます。接続確立、並列ストリーム、ネットワーク変化時の可用性を重視し、対応が良好なモバイル環境では自然な動作を示します。Hysteria2と同様に、TUICはUDPの品質と実装バージョンの組み合わせに左右されやすい方式です。

TUIC設定では、プロトコルのバージョンとフィールドの意味に注意してください。過去の実装間では認証情報の形式やリレー方式が異なる場合があり、「TUIC」という名前だけで相互接続できるとは限りません。サーバーが生成したサブスクリプションはできるだけそのまま読み込み、手動移行では現在のmihomo設定構文に従って項目ごとに対応付けます。ネットワークのUDP処理が不安定なら、TUICの理論上の利点が頻繁な再接続に変わることがあります。その場合は、成熟したTCP系プロトコルのほうが安定することもあります。

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

ハンドシェイク回数が初回接続コストの一部を決める

初回接続の所要時間は、DNS、トランスポート層のハンドシェイク、セキュアハンドシェイク、プロトコル認証で決まります。通常のTCP環境ではSSの構造は短いものの、対象への接続には完全なネットワーク往復が必要です。Trojan、TLSを有効にしたVMessやVLESSではTLS処理を完了する必要がありますが、セッション再開を有効にすると2回目以降の接続が初回より大幅に速くなる場合があります。Hysteria2とTUICはQUICによってセキュリティとトランスポートのネゴシエーションを統合し、1つのセッションで複数のストリームを処理できます。短時間の接続が多い用途に適しますが、初回確立はUDP経路の品質に左右されます。

ブラウザーでWebページを開くときは、既存のHTTP/2やHTTP/3接続を再利用することが多いため、ユーザーが感じる「一瞬で開く」速さはプロキシのハンドシェイク速度と完全には一致しません。比較する際は、古い接続を閉じるかセッションが失効するまで待ち、初回アクセスと連続アクセスを分けて観察してください。Clashのログにはプロキシ選択やエラー段階が表示されますが、通常のinfoレベルでは各プロトコル内部の処理時間までは正確に示されません。プロキシグループの遅延テスト値をそのままWebページの読み込み速度と解釈しないでください。通常は指定されたテスト先への1回の接続結果にすぎません。

スループットは暗号化だけでなく回線で決まる

現在の端末は一般的なAEADやTLS暗号化に対してソフトウェアまたはハードウェアの最適化が進んでおり、暗号化計算だけがデスクトップの主要なボトルネックになることは多くありません。サーバーのCPU、単コア性能、ネットワーク出口、パケットロス、経路MTUのほうがスループットを制限しやすい要因です。SSのプロトコルオーバーヘッドは比較的予測しやすく、VMess、VLESS、Trojanの追加負荷はトランスポート層によって変わります。WebSocketはカプセル化を追加し、gRPCはHTTP/2に依存し、QUIC系プロトコルはユーザー空間でより多くのトランスポート処理を行います。

リソースの少ないルーターでは、より慎重な判断が必要です。QUICは暗号化、再送、輻輳ウィンドウ、複数ストリームの状態を管理するため、TCP処理の大部分をOSカーネルに任せる場合より、低性能CPUで多くのCPUを消費することがあります。一方、回線のパケットロスが明確な場合は、QUICがストリーム間の先頭行ブロッキングを避けて待ち時間を減らす効果が計算コストを上回ることもあります。空きメモリや一瞬のCPUピークだけで判断せず、数分間の実通信を行った後に温度、負荷、速度の安定性を確認してください。

モバイルの電池消費はウェイクアップ頻度と適用範囲で決まる

スマートフォンの電池消費の差は、プロトコル名そのものより、無線モジュールのウェイクアップ、バックグラウンド維持、ネットワーク切り替え時の再接続、TUNの処理範囲から生じることが多いです。小さなパケットを継続的に送る接続は、無線モデムを頻繁に起動させます。詳細ログ、短い間隔のヘルスチェック、過度に頻繁な自動速度テストもバックグラウンド処理を増やします。Hysteria2やTUICは不安定な回線からの復旧で待ち時間を減らせる場合がありますが、UDP経路が不安定で再試行を繰り返すと、同じように電池を消費します。

システムプロキシは、プロキシ設定に従うアプリだけに影響するため、適用範囲は比較的限定されます。TUNモードはより多くの通信を引き受け、DNS、ルーティング、システムプロキシを自発的に使わないアプリも処理するため、一般に負荷が大きくなります。Androidではシステムのバックグラウンド制限とVPNサービスのライフサイクル、iOSではNetwork Extensionの動作方式も考慮が必要です。プロトコルごとの電池消費を比較するときは、プロキシモード、ルールセット、ヘルスチェック間隔、使用アプリをそろえてください。

再現可能なローカルテストを行う

有効なテストは、同じ端末、同じネットワーク、近い時間帯で実施します。まず自動選択のプロキシグループを無効にし、1つの設定に固定します。初回アクセス、連続アクセス、長時間転送、ネットワーク切り替え後の復旧を記録し、その後、同じサーバーが提供する別のプロトコルに変更します。サーバーが同一でない場合、結果が示すのは回線全体の違いであり、特定のプロトコルが速いことの証明にはなりません。

4. トランスポート層、TLS、重要な設定パラメーター

networkフィールドが変更するのは搬送方式

VMess、VLESS、Trojanでは、networkフィールドでtcp、ws、grpcなどの搬送方式を選ぶことがよくあります。プロトコルは認証とデータ形式を担当し、networkはそのデータを下位接続へどう格納するかを決めます。WebSocket設定には通常、パスとHostが必要です。gRPCには通常service-nameが必要で、通常のTCPにも追加のヘッダーオプションが存在する場合があります。サーバーが使う方式に対して、クライアント側も各項目を正確に合わせる必要があります。ポートが443だからといって、特定のトランスポートだと判断してはいけません。

WebSocketは一般的なWebサービスの構成と組み合わせやすい一方、各フレームに追加のカプセル化が発生します。gRPCはHTTP/2を基盤とし、多重化に適していますが、中間ネットワーク機器とサーバー側のリバースプロキシが正しく対応していなければなりません。通常のTCPは経路が直接的で、障害の切り分けも簡単です。選択は既存サーバーの出力に従ってください。一般的なサブスクリプション利用者が手動でnetworkを変更しても、性能が自然に向上することは通常なく、クライアントとサーバーの設定が一致しなくなるだけです。

servername、Host、サーバーアドレスにはそれぞれ役割がある

serverフィールドはクライアントが接続するホストまたはIPを決めます。servernameはTLSのSNIや証明書名の検証に使われ、WebSocketのHostはHTTPリクエストヘッダーに属します。3つが同じ場合もあれば、異なる場合もあります。サブスクリプション変換器がこれらを統合すると、TCP接続は確立しているのにTLSや上位リクエストだけが失敗することがあります。トラブル時は、ログにDNS、connect、certificate、handshake、timeoutのどれが現れているかを確認し、該当する層を特定してください。

端末の時刻もTLS検証の一部です。システム時計が大きくずれていると、Trojan、VLESS TLS、Hysteria2、TUICで証明書の有効期限に関するエラーが発生することがあります。この場合、プロトコルを変更したりサブスクリプションを何度も更新したりしても意味はありません。まず自動時刻合わせを復旧してください。Reality設定では、public-key、short-id、servername、fingerprintも同時に確認します。これらは1つのセットであり、どれかが欠けるとハンドシェイク段階で終了することがあります。

UDP、MTU、フラグメントの問題

Hysteria2とTUICはUDPに依存し、他のプロトコルでもUDPアプリケーション通信を転送する場合があります。UDPパケットが家庭用ルーター、モバイルネットワーク、トンネルを通過すると、利用可能なMTUが物理NICの公称値を下回ることがあります。大きすぎるパケットを正しく分割できないと、小さなリクエストは通るのに大容量通信が止まる、または一部のサイトだけ使えて別の接続がタイムアウトするといった現象が起きます。TUNモードではクライアントのMTU設定が仮想インターフェースのパケットサイズにも影響しますが、具体的な症状がないまま無闇に下げないでください。

妥当な切り分け手順は、まずサブスクリプションの初期値を維持し、TCP系通信が正常か確認してからUDPプロトコルの設定を調べることです。QUIC接続が継続的にタイムアウトする場合は、同じサービス提供元のTCP系設定に切り替えて比較します。TCPは正常で、すべてのUDP方式だけが失敗するなら、まずローカルネットワーク、ルーター、サーバーのUDPポートを確認してください。クライアントのskip-cert-verifyだけを変更しても、UDP経路の問題は解決しません。

読みやすいmihomo設定

以下の例はフィールドの階層を示すもので、実際に接続できるサービスを表すものではありません。ドメインと認証情報はドキュメント用の例です。実際に使う場合は、サーバーが生成した完全な設定を使用してください。YAMLを手書きするときはスペースでインデントし、タブは使わないでください。

proxies:
  - name: "SS サンプル"
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "Trojan サンプル"
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: service.example.com
    udp: true

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "SS サンプル"
      - "Trojan サンプル"

rules:
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

設定をYAMLとして解析できることは、構文が正しいことを示すだけで、サーバーのパラメーターが正しいとは限りません。インポート後はクライアントのログを確認してください。unsupported proxy typeが表示される場合は、カーネルがその種類を認識していません。フィールド解析エラーの場合は、キー名または階層に互換性がありません。設定は読み込めるのに接続がタイムアウトする場合は、アドレス、ポート、トランスポート、ネットワーク経路を確認します。YAMLの基本用語については、Clash用語集も参照してください。

5. Clash原版、Meta、mihomoのカーネル関係

カーネルが設定ファイルを実行できるかを決める

Clashエコシステムでは、「クライアント」と「カーネル」が混同されがちです。原版Clashは早期に確立された設定構文とルールモデルを持つ中核実装で、プロキシグループ、ルール分岐、DNS、外部制御インターフェースなどの基本機能を提供します。GUIクライアントはこれらをもとに設定管理とシステム統合を追加します。その後登場したClash.Metaは、原版の多くの構文との互換性を保ちながら、プロトコル、DNS、ルールセット、TUN機能を拡張しました。mihomoは、この拡張カーネルで現在広く使われているプロジェクト名です。

そのため、「Meta設定」と「mihomo設定」は多くの日常的な場面で同じ進化系統を指しますが、過去のドキュメント、サブスクリプション生成器、クライアント画面にはClash.Metaという表記が残っている場合があります。互換性を判断するときは名前だけでなく、クライアントが実際に使っているカーネルの説明と実行ログを確認してください。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Androidなどの現代的なクライアントは通常mihomoエコシステムを中心に機能を提供しますが、プラットフォームごとにカーネルの更新頻度や公開されるオプションは完全には一致しません。

原版との互換性は基礎であり、逆方向の互換性を意味しない

基本的なSS、VMess、Trojan、プロキシグループ、従来型ルールの多くは、原版設定からmihomoへ移行できます。しかし逆方向は成り立ちません。VLESS、Hysteria2、TUIC、GEOSITE、新しいrule-providers、拡張DNSフィールドを含むmihomo設定は、古い原版カーネルでは読み込みを拒否されたり、認識できないフィールドを無視されたりすることがあります。設定ファイルがYAMLに見えるからといって、Clashという名前のプログラムならすべて実行できるわけではありません。

互換性の問題は大きく3種類に分けられます。1つ目はプロキシ種別が未対応で、ログがtypeを指すことが多いケースです。2つ目はフィールド構造の変化で、一部のTLS、Reality、QUICパラメーターにネストしたオブジェクトが必要になるケースです。3つ目は挙動の違いで、同じフィールドを解析できても、DNS、ルール、インターフェースのバインドにおける既定動作が異なるケースです。移行時はまず最小構成を解析できる状態にし、その後DNS、TUN、ルールセット、スクリプト機能を段階的に戻してください。複雑なファイル全体を一度に読み込むと、原因を特定しにくくなります。

GUIはカーネルの差異を自動修正しない

GUIクライアントは複雑なフィールドを隠したり、スイッチを提供したり、エラーを表示したりできますが、カーネルが認識しないプロトコルを実行させることはできません。インポート時にサブスクリプションを変換するクライアントもあれば、元のYAMLをそのままカーネルに渡すクライアントもあります。前者ではフィールドが失われる可能性があり、後者では構文エラーが直接表示されることがあります。同じサブスクリプションの結果がクライアントごとに異なる場合は、画面名だけでなく、双方が使うカーネル系統、インポート後の実際の設定、ログを比較してください。

Clash for WindowsとClashX Metaは、すでにメンテナンスが終了したアーカイブ済みクライアントです。過去のエコシステムを理解する用途には使えますが、新しいプロトコルの互換性を検証する基準には適しません。VLESS、Hysteria2、TUIC、または新しいgeodata機能が必要な場合は、現在もmihomo系統を採用しているクライアントを選んでください。各プラットフォームで利用できるソフトウェアとメンテナンス状況はダウンロードページにまとめています。

カーネル更新前に戻せる設定を保存する

カーネルの更新でプロトコル機能が追加されることもあれば、不正な設定の解析が厳格になることもあります。アップグレード前に、現在動作している設定とクライアント設定を保存してください。特にカスタムDNS、rule-providers、TUNルート、外部制御インターフェースは必ず保管します。更新後はまず設定が正常に読み込まれるか、次にプロキシグループが完全か、最後にDNSとルールの適用を確認します。問題が新しいカーネルでのみ発生するなら、既知の動作環境に一時的に戻してログを比較してください。サブスクリプション、ルール、システムネットワーク設定を同時に変更してはいけません。

6. サブスクリプション形式、共有リンク、変換互換性

サブスクリプションは配布方式であり、プロキシプロトコルではない

ユーザーは「サブスクリプション形式」と「プロトコル形式」を一緒に議論しがちです。実際には、サブスクリプションはノード、プロキシグループ、ルールをまとめて記述し、ノード内部にSS、VMess、Trojan、VLESS、Hysteria2、TUICが含まれます。1つのサブスクリプションに1種類だけ含まれることも、複数のプロトコルが混在することもあります。同じプロトコルでも、共有リンク、汎用JSON、Clash YAML、サーバー専用レスポンスなど、さまざまな形で配布できます。

クライアントがサブスクリプションを更新するときは通常、ダウンロード、識別、変換、設定への書き込み、カーネル読み込みの5段階を経ます。ダウンロード失敗はネットワークまたは認証のエラー、識別失敗は内容の種類が想定と異なること、変換失敗は拡張フィールドが失われた可能性、書き込み失敗はファイル権限、読み込み失敗はYAMLまたはカーネル互換性の問題を示します。この5段階を分けて考えると、「更新に失敗しました」と表示されただけでプロトコルを何度も変更する必要がなくなります。

Clash YAMLは完全な構造を表現できる

Clash YAMLでは、proxies、proxy-groups、rules、dns、rule-providersなどを同時に記述でき、クライアントが直接読み込む完全な設定として適しています。構造が明確で、確認や組み合わせがしやすいことが利点です。一方、カーネルによって対応フィールドの集合が異なる点には注意が必要です。mihomo向けに生成されたYAMLを古いカーネルへ読み込むと、未対応のプロキシ種別やルール機能が原因で失敗する場合があります。

proxiesだけを含むサブスクリプションが、理想的なプロキシグループを自動生成するとは限りません。一部のクライアントには上書きやグローバル拡張機能があり、リモートノードをローカルテンプレートに統合できます。この場合は、ノード名の重複、プロキシグループの参照が残っているか、更新後にローカル変更が上書きされないかを確認してください。ルールを長期的にカスタマイズするなら、更新のたびに置き換えられるサブスクリプションファイルを直接編集せず、リモートノードとローカルルールを分けて管理するのが一般的です。

共有リンクは単一ノードの移行に便利だが、エンコードの制約がある

ss://、vmess://、trojan://、vless://、hysteria2://、tuic://などのリンクは、1つの設定を渡すのに便利です。クライアントはリンクを読み込み、クエリパラメーターを内部設定へ対応付けます。単純なSSやTrojanリンクは比較的そのまま扱えますが、WebSocket、gRPC、Reality、ALPN、フィンガープリント、輻輳制御パラメーターを含む場合は、リンク解析器がすべてのパラメーターを認識する必要があります。

リンクが認識されてノード一覧に表示されても、すべてのフィールドが保持されたとは限りません。インポート後は生成された設定または詳細画面を開き、server、port、uuidまたはpassword、network、servername、パス、拡張パラメーターを確認してください。別のエコシステムから取得したリンクでは、パラメーター名の変換が必要になることがあります。「認識できないパラメーター」を削除してインポート成功を目指さないでください。削除したフィールドが、サーバーのハンドシェイクに必要な情報である可能性があります。

更新失敗とプロトコル利用不可は分けて対処する

サブスクリプションURLをダウンロードできない場合、クライアントはまだプロトコル設定に触れてすらいません。この段階では、リンクが完全か、有効期限、アクセス方式、クライアントのリクエスト動作を確認してください。サブスクリプションの更新は成功したのに特定のノードだけが失敗する場合に、プロトコルフィールドを分析します。新しいノードがすべて読み込めないなら、形式またはカーネルの問題である可能性が高く、1つのノードだけがタイムアウトするなら、そのサーバー、ポート、設定パラメーターの問題である可能性が高いでしょう。

自動更新によって手動変更が上書きされることもあります。プロキシグループを変更する場合は、クライアントが提供する上書き、拡張設定、ローカル設定機能を優先し、リモートサブスクリプションの原本を保存してください。リンクの期限切れ、リクエスト方式、自動更新間隔については、Clashサブスクリプション更新失敗の主な原因と自動更新間隔の設定も参照してください。

7. プロトコル以外に影響するDNS、ルール、TUN

接続失敗はプロトコル選択前に起きることがある

クライアントがプロキシ接続を確立する前に、サーバーのドメイン名を解決する必要がある場合があります。DNSでアドレスを取得できなければ、どのプロトコルでも失敗します。ログのlookup、resolve、no such hostは通常、名前解決段階の問題を示します。connect timeoutはアドレスを取得済みでもネットワーク接続を完了できないこと、handshakeやcertificateのエラーはプロトコルやセキュリティ層に近い問題を示します。エラーが発生した段階に応じて対処するほうが、ノードを何度も切り替えるより効果的です。

ClashのDNSモジュールは対象ドメインの名前解決も担当し、fake-ipまたはredir-hostモードを使うことがあります。fake-ipはまず仮想アドレスを返し、カーネルがドメインを復元してルールに照合します。TUNと精密なドメイン分岐に適しています。redir-hostは実際の名前解決結果を返す方式に近いものです。両者はアプリ互換性、キャッシュ、ルールの動作に違いがありますが、リモートノードがSS、VLESS、TUICのどれであるかを変えるものではありません。

ルールが使用するプロキシグループを決める

ルールは上から順に照合され、該当するとそれ以降のルールには進みません。DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、GEOSITE、MATCHは通信先を決めるもので、ノードのプロトコルを変更するものではありません。ある通信が常にDIRECTへ送られるなら、プロキシグループでHysteria2を選んでいても、その通信はHysteria2を経由しません。トラブル時は、ルールの適用記録とプロキシグループの選択を同時に確認してください。

GEOIPはIP地理データベース、GEOSITEはドメイン分類データに依存します。データベースが古いとルール結果が期待と異なることがありますが、プロキシ種別が未対応になるわけではありません。mihomoではgeodata、MMDB、ルールプロバイダーなどの仕組みを利用できます。ファイルの取得元と更新方法は統一してください。関連するメンテナンス方法はGeoIP・GeoSiteデータベースの更新方法を参照してください。

rules:
  - DOMAIN-SUFFIX,github.com,ノード選択
  - DOMAIN-KEYWORD,google,ノード選択
  - GEOSITE,category-ads-all,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

この順序では、まず明示的なドメインと広告分類を処理し、次にIPの地理ルールを処理し、最後にMATCHで受けます。MATCHを先頭に置くと、後続のルールは一度も実行されません。ルールのポリシー名はproxy-groups内の名前と、大文字・小文字やスペースを含めて完全に一致させる必要があります。プロキシグループが存在しないノードを参照すると、カーネルが設定を拒否することも、利用できないグループを残すこともあります。具体的な結果は設定構造によって異なります。

TUNは適用範囲を変えると同時に、切り分けの層も増やす

システムプロキシは、アプリがOSのプロキシ設定を自発的に読み取ることを前提とします。ブラウザーは通常対応していますが、ターミナルプログラムや一部のゲームは従わない場合があります。TUNは仮想ネットワークインターフェースを作り、ルーティング層からより多くの通信を引き受けます。そのため対応アプリが増える一方、ルーティング、DNSのリダイレクト、MTU、システム権限などの変数も加わります。システムプロキシでは正常なプロトコルがTUNで異常になる場合も、すぐにプロトコル非互換と判断せず、通信がTUNに入っているか、DNSが正しく引き継がれているか、対象がバイパスされていないかを確認してください。

モバイル端末では通常、OSのVPNインターフェースを使って同様の機能を実現します。OSはスリープ、Wi-Fiとモバイル回線の切り替え、省電力モードの開始後にインターフェースを再構築することがあります。TUICとHysteria2のQUICセッションはネットワーク変化に対応できる設計余地を持ちますが、クライアント、OS、サーバーがすべて対応していなければなりません。実際の動作は端末上で確認する必要があります。頻繁に切断される場合は、まずOSがバックグラウンドサービスを終了していないか確認し、その後プロトコルログを調べてください。

ログを使って段階的な切り分け順序を作る

推奨手順は、設定が正常に読み込まれたことを確認し、対象プロキシグループにプロキシ設定が表示されることを確認し、サーバーのドメインを解決し、TCPまたはUDPポートへの接続を確立し、TLS、Reality、プロトコル認証を確認し、ルールが対象通信をそのグループへ送ることを確認し、最後にシステムプロキシまたはTUNが対象アプリをカバーしているか確認することです。各段階で1つの問いだけに答えると、原因の範囲を大きく絞れます。

ブラウザーでは使えるのにターミナルでは使えない場合、通常はターミナルがシステムプロキシの環境変数を読み取っていないのであり、プロトコルがブラウザー専用という意味ではありません。TUNを有効にするとすべてのアプリで名前解決できなくなる場合は、DNSとTUN設定を確認してください。その他のよくあるエラーはFAQ・トラブルシューティングで現象別に確認できます。ブラウザーとターミナルの違いを調べる手順はシステムプロキシが機能しない場合の確認方法を参照してください。

8. 端末とネットワーク環境に応じてプロトコルを選ぶ

デスクトップの日常利用：安定性と保守性を優先

WindowsとmacOSのデスクトップ端末は比較的リソースに余裕があり、プロトコルの計算コストが最初に問題になることは通常ありません。サーバーが安定したSS、Trojan、TLS付きVLESSを提供しているなら、設定が完全で長期的に安定するものを優先してください。短い接続が多く、遅延が高く、UDP経路が安定している場合に、Hysteria2やTUICを比較します。デスクトップではテストしやすいため、TCP系の設定を1つ、比較用と障害時の切り替え先として残しておくと安心です。

クライアントはまずClash Plusから試し、その後、画面やプラットフォームの要件に応じてClash Verge Rev、FlClash、Clash Nyanpasuを比較するとよいでしょう。クライアント選びとプロトコル選びは分けて考えてください。GUIを変更すれば設定管理は改善するかもしれませんが、両者が近いmihomoカーネルを使っているなら、同じ不正な設定はやはり失敗します。クライアントを移行するときは、元のサブスクリプションURLと必要なローカル上書きを書き出し、画面のキャッシュファイルだけをコピーしないでください。

モバイル回線：切り替え後の復旧とバックグラウンド動作を確認

AndroidとiOSでは、Wi-Fi、モバイル回線、スリープ状態の間を頻繁に切り替えます。この環境では、接続復旧までの時間、バックグラウンドサービスがOSに維持されるか、UDP経路が安定しているか、1日を通した電池の変化を重点的に確認してください。条件が合えばTUICとHysteria2は不安定な回線でも滑らかな使用感を提供できますが、現在の通信事業者ネットワークでUDP品質が不安定なら、Trojan、VLESS TLS、SSのほうが信頼できる場合があります。

モバイル端末では、連続した速度テストだけでプロトコルを選ばないでください。高頻度のテスト自体がネットワークとプロセッサを起こし、普段使うアプリの長期的な使用感も表しません。候補のプロトコルを同じルールとTUN設定で、それぞれ通常の作業時間いっぱい使い、ネットワーク切り替え後の復旧、音声・動画の連続性、電池消費を記録するほうが実用的です。1回だけ高いピーク速度が出ても、頻繁な切断を覆す根拠にはなりません。

家庭用ルーターと小型端末：まずCPUとメモリを確認

ルーターは複数端末の接続、DNS、ルール照合を同時に処理する必要があります。性能の低いCPUでは、簡単なSSや成熟したTCP/TLS方式のほうが安定した負荷を維持しやすいでしょう。Hysteria2とTUICは高遅延の回線を改善できる場合がありますが、QUICのユーザー空間トランスポートと暗号化によってCPU使用率が上がることがあります。選ぶ前に、1台のPCで1回速度テストをするのではなく、実際の同時接続数で状態を確認してください。

ルールセットの規模もリソースに影響します。大量のGEOSITE分類、リモートrule-providers、詳細ログは、プロキシプロトコルより多くのメモリを消費する場合があります。端末が頻繁に再起動したりカーネルが終了したりするなら、まず設定を小さくします。プロキシグループ1つ、少数のルール、ノード1つだけを残して安定性を確認し、その後に項目を1つずつ戻してください。mihomoカーネルパッケージはコマンドラインとサービス管理に慣れたユーザー向けです。一般的なデスクトップユーザーには、GUIクライアントのほうがエラーを確認しやすいでしょう。

高遅延またはパケットロスのある回線：QUIC方式を検討する

従来のTCPではパケットロス後に速度が大きく低下し、UDPは安定して通る場合、Hysteria2とTUICを試す価値があります。ただし、どちらもすべてのネットワークで自動的に速くなるわけではありません。Hysteria2は帯域幅と輻輳動作を回線に合わせる必要があり、TUICはサーバーとクライアントの実装バージョン、認証情報、リレー方式が一致していなければなりません。テストでは同じサーバーのTCP系設定と比較し、回線の違いをできるだけ排除してください。

小さなデータは通るのに大容量転送が止まる場合は、MTU、UDPのフラグメント、ルーターの状態を確認します。初回は使えるのに数分後に切断される場合は、セッションタイムアウト、NATマッピング、バックグラウンド制限を確認します。一度も接続が確立しない場合は、UDPポート、TLS名、認証フィールドを確認してください。現象を分類してからパラメーターを調整し、帯域幅、MTU、SNI、証明書検証を同時に変更しないでください。

最終判断チェックリスト

プロトコルを決める前に、次の6点を順番に確認します。サーバーが実際にその種類を提供していること、クライアントが対応するmihomoカーネルを採用していること、サブスクリプションが認証・トランスポート・セキュリティの各フィールドを完全に保持していること、現在のネットワークが必要なTCPまたはUDP経路を許可していること、端末のリソースで継続運用できること、同じ条件での実測結果が安定していることです。6項目がすべて成立して初めて、再現性のある選択だと判断できます。

判断できない場合は、サーバーが明確に推奨し、設定が完全な項目を優先し、高度なパラメーターは変更しないでください。まずインポート、プロキシグループの選択、接続、確認という基本手順を完了し、その後で本ページの方法を使って比較テストを行います。初回接続の操作手順はノード選択、遅延測定、プロキシ動作の確認も参考にしてください。プロトコルに環境を離れた恒久的な順位はありません。安定し、診断しやすく、現在の端末に適していることが、より価値のある結論です。