Clashのプロトコル、カーネル、サブスクリプション互換性に関する技術リファレンス

01 · Decision Model

まず制約を確認し、その後でプロトコル名を比較する

プロトコル、転送方式、クライアントは別々のレイヤー

Clashの設定でいう「ノードタイプ」は、通常プロキシプロトコルを指します。たとえば ss、vmess、trojan、vless、hysteria2、tuic などです。プロトコルは、クライアントとサーバーがセッションを確立し、認証し、接続先アドレスをカプセル化し、アプリのデータを転送する方法を定めます。ただし、これは下位の転送方式そのものではありません。VMessやVLESSはTCP、WebSocket、gRPCなどと組み合わせられます。Trojanは通常TLSと併用され、Hysteria2とTUICはQUICおよびUDPの転送能力を重要な基盤とします。サブスクリプション上では同じプロトコルに見えるノードでも、転送方式、TLSパラメータ、サーバー側の実装が異なれば、実際の挙動は大きく変わることがあります。

クライアントは、より外側にある操作画面です。Clash Plus、Clash Verge Rev、FlClash、Clash NyanpasuなどのGUIクライアントは、設定のインポート、プロキシグループの切り替え、システムプロキシの管理、接続情報の表示を担当します。ノードのフィールドを実際に解析して接続を確立するのは、内蔵または呼び出されるカーネルです。クライアントを選ぶときは、対応プラットフォームとカーネルの機能を同時に確認してください。ノードを選ぶときは、現在のカーネルがプロトコルのフィールドを認識できるかを確認します。GUIにノード名が表示されても、そのノードのすべてのオプションを下層で完全に処理できるとは限りません。特に新しいプロトコル拡張や転送パラメータでは注意が必要です。

4つの質問で候補を絞る

最初の制約は、サーバー側で何が提供されているかです。クライアント上でShadowsocksノードをVLESSに直接変更したり、type フィールドを書き換えるだけでプロトコルを変換したりはできません。プロトコルの両端では、同じ認証方式とカプセル化ルールを使う必要があるため、ノードタイプはまずサーバー側の設定で決まります。サブスクリプションが1種類のプロトコルしか提供していないなら、現在のカーネルが対応しているかを確認し、ノード、ポリシー、DNSを調整するのが適切です。クライアント上でプロトコル名を自由に書き換えるべきではありません。

2つ目の制約は、ネットワーク経路がUDPを安定してサポートしているかです。Hysteria2とTUICの主な転送方式はUDPとQUICを基盤としています。ローカルネットワーク、ルーター、サーバー側の入口でUDPの動作が不安定だと、ハンドシェイクのタイムアウト、速度の変動、頻繁な再接続が起きる可能性があります。その場合、ピーク速度ではTCP方式に及ばなくても、継続的な利用性はTCP方式のほうが高いことがあります。UDPの能力は、ウェブページが開くかどうかだけで判断せず、一定時間の接続確立、スリープからの復帰、大容量ファイルの転送、ネットワーク切り替え時の挙動を観察してください。

3つ目の制約は端末リソースです。デスクトップでは通常、同時接続数、ダウンロード速度、長時間稼働時の安定性が重視されます。スマートフォンやタブレットでは、無線モジュールのウェイクアップ、バックグラウンド動作、ネットワーク切り替え、バッテリー消費も考慮が必要です。ルーターや小型サーバーでは、CPU命令セット、メモリ、ファイルディスクリプター数が制限になる場合があります。暗号化アルゴリズム、ユーザー空間の輻輳制御、接続の多重化、ログレベルはいずれもリソース使用量を変えます。プロトコル名は判断材料にはなりますが、実測の代わりにはなりません。

4つ目の制約は、設定の移行性です。長期間使うサブスクリプションには、ルールセット、プロキシグループ、DNS、スクリプト、特定カーネル向けの拡張が含まれることがあります。別のクライアントへ移行するときに問題になりやすいのは、基本ノードよりもルールプロバイダー、TUNパラメータ、スニッフィング設定、新しいプロトコルフィールドです。複数の端末で設定を共有するなら、共通して対応するフィールドだけを使い、プラットフォーム固有の設定はクライアント側に置きましょう。すべてを1つの共通サブスクリプションに詰め込むべきではありません。

選定時は、まず安定した基準ノードを1つ残してから候補プロトコルを比較しましょう。基準には、継続的に接続でき、設定フィールドが少ないノードが適しています。その後、同じサーバー地域と近い回線条件を保ったまま、TCP系とQUIC系のノードを個別にテストするなど、変数を1つだけ変更します。サーバー、プロトコル、ポート、プロキシグループを同時に変更すると、結果の原因を特定できず、次にどこを調整すべきか判断しにくくなります。

02 · Established Protocols

ShadowsocksとVMess：成熟した基盤と組み合わせの柔軟性

Shadowsocksのシンプルな設計

ShadowsocksはSSと略されることが多く、事前共有パスワードと選択したAEAD暗号方式でクライアントとサーバー間のデータを保護し、軽量なプロトコルカプセル化でTCPまたはUDPトラフィックを転送します。設定項目は比較的まとまっており、一般的なノードではサーバーアドレス、ポート、パスワード、暗号化方式が必要です。ネゴシエーションの手順が少なく実装の境界も明確なため、さまざまなカーネルやクライアントで対応しやすく、サブスクリプション、DNS、プロキシグループが正常に動作するかを確認する基準プロトコルにも適しています。

「設定が簡単」だからといって、すべてのShadowsocksノードが同じとは限りません。暗号化方式はサーバー側と一致している必要があり、名称の表記もカーネルの対応リストに合っていなければなりません。現在の設定では通常AEAD方式が使われます。古いストリーム暗号方式は、実装方針やセキュリティ上の理由から、一部のクライアントで受け付けられない場合があります。サブスクリプションにプラグインフィールドが含まれる場合は、現在のカーネルがそのプラグインとパラメータに対応しているかも確認してください。基本的なSSノードをインポートできても、プラグイン付きの別ノードまで互換性があるとは限りません。

リソース面では、Shadowsocksのプロトコル処理は一般にシンプルです。実際のCPU使用率は、暗号化方式、端末のハードウェアアクセラレーション、同時接続数、転送量によって決まります。一般的なデスクトップでは、日常のウェブ閲覧でプロトコル自体が主なボトルネックになることはほとんどありません。低消費電力のルーター、高速ダウンロード、多数の同時接続では、アルゴリズムの実装やシングルコア性能の違いが現れます。速度測定中にCPUが継続的にほぼ100%なら、プロキシグループを切り替えても速度は改善しにくいため、まず変数を減らして端末の処理能力を確認しましょう。

VMessの認証と転送方式の組み合わせ

VMessはV2Rayエコシステムに由来し、通常はUUIDをユーザー識別子として使い、複数の下位転送方式と組み合わせられます。サブスクリプションでは network、TLS、ホスト名、パス、サービス名などのフィールドを同時に含むことがよくあります。VMessの特徴は、単純な速度の優劣ではなく、設定の組み合わせが豊富な点です。同じVMessでも、TCP、WebSocket、gRPCでは、ハンドシェイク、接続の多重化、追加ヘッダーのコストが異なります。

VMessノードのトラブルシューティングでは、外側から内側へ確認します。まずサーバー、ポート、UUIDを確認し、次に暗号化またはセキュリティ関連のフィールド、最後に転送方式を確認します。WebSocketを使う場合はパスとHost、TLSを併用する場合はサーバー名、証明書検証、ALPNなどを確認します。gRPCではサービス名と多重化の挙動が重要です。サブスクリプション変換ツールがどれか1つでもフィールドを落とすと、ノードはクライアントに表示されてもハンドシェイクで接続に失敗することがあります。

VMessはシステム時刻の影響を受けやすいプロトコルです。端末の時刻に大きなずれがあると認証を完了できないことがあります。「同じサブスクリプションが1台では使えるのに、別の端末ではすべてタイムアウトする」場合、システム時刻とタイムゾーンは確認コストが低く、優先すべき項目です。自動時刻同期を戻した後は、設定を再読み込みするか関連する接続を再起動し、古い接続状態が判断に影響しないようにしてください。

どのように選ぶか

サーバーがSSとVMessの両方を提供し、回線条件も近い場合、SSは低複雑度の基準ノードに適しています。フィールドが少ないため、異なるカーネルへ移行したときも問題を特定しやすくなります。VMessは、既に成熟した構成があり、特定の転送方式を必要とする場合や、サブスクリプションの仕組みがそのパラメータを中心に構成されている場合に向いています。「フィールドが多いから高機能」「少ないから必ず速い」とは考えず、追加の転送レイヤーが明確な要件を満たすか、現在のカーネルが設定を正しく扱えるかで判断してください。

モバイルでは、1回の暗号化処理より接続数と再接続頻度のほうが使用感に影響することが多くあります。WebSocketやgRPCの組み合わせは、追加のハンドシェイクや接続管理を生む一方、適切な接続再利用によって接続の張り直しを減らすこともあります。短いリクエストが中心なら、初回リクエストとスリープからの復帰を観察してください。音声・動画やダウンロードが中心なら、10分以上の安定したスループットを確認します。単発の遅延値は、測定対象のある瞬間しか反映しません。

設定を移行する場合、SSの基本フィールドはClash系カーネル間で比較的移植しやすく、VMessの基本フィールドも成熟しています。ただし、転送拡張の名称やネスト構造は重点的に確認してください。変換サービス経由のサブスクリプションでは、元のサブスクリプションURLを保存し、変換前後で1つのノードについてサーバー、ポート、UUID、ネットワークタイプ、TLS、パス、ホスト名を比較することをおすすめします。ノードの表示名だけで変換の完全性を判断しないでください。

proxies:
  - name: "SS 基準ノード"
    type: ss
    server: server.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

上の例は、mihomo設定における基本的なShadowsocksノードのフィールド関係を示しています。サンプルのドメイン名とパスワードは、サーバーが提供する実際の情報に置き換えてください。udp: true は、カーネルがこのノードのUDPトラフィックを処理できるようにする設定にすぎず、サーバーとネットワーク経路にも対応能力が必要です。別のノードからパスワード、ポート、暗号化方式をコピーし、名前だけ変更しないでください。YAMLとして解析できても、プロトコル認証は完了しません。

03 · TLS-Oriented Choices

TrojanとVLESS：認証レイヤーと転送レイヤーの選択

Trojanの接続構造

Trojanは通常、パスワード認証とTLS接続を組み合わせます。クライアントはまずTLSハンドシェイクを完了し、その暗号化接続内でプロトコル認証情報と接続先アドレスを送信します。設定にはサーバー、ポート、パスワードに加えて、sni、証明書検証、ALPN、UDP対応などのフィールドが現れることがあります。ノード構造はそれほど複雑ではありませんが、TLS関連のパラメータはサーバー証明書と入口の設定に一致している必要があります。名称が1か所でも合わないと、ハンドシェイク失敗として現れることがあります。

SNIは、TLSハンドシェイクで接続先サーバー名を示すために使われます。サブスクリプションがサーバーアドレスとしてドメイン名を提供している場合、通常はカーネルがそれを利用できます。サーバーフィールドがIPアドレスで、証明書が特定のドメイン名向けに発行されている場合は、サーバー名を別途入力する必要があることがあります。証明書検証を無効にすれば、名前や証明書チェーンの問題を一時的に回避できる場合がありますが、接続の認証属性が変わるため、長期的なトラブルシューティングには適しません。サーバー証明書、システム時刻、SNI、サブスクリプションのフィールドが一致しているかを確認するのが安全です。

Trojanの性能には、初回TLSハンドシェイクのコストと、接続確立後のデータ転送コストの2つがあります。短い接続が多い場合は、ハンドシェイクの繰り返しが最初のデータ到着時間に大きく影響します。接続を維持したり適切に再利用したりすれば、このコストは分散されます。TLS実装は広く最適化されており、現代のデスクトップやスマートフォンのプロセッサでもハードウェア・ソフトウェアの対応が成熟しています。そのため、「TLSが1層増える」だけで必ず遅いとは判断できません。回線遅延、サーバー負荷、アプリの接続方式のほうが重要な場合も多くあります。

VLESSは拡張機能を外側のレイヤーに委ねる

VLESSもV2Ray関連のエコシステムに由来しますが、プロトコルレイヤーはより軽量に設計されています。通常はUUIDでユーザーを識別し、暗号化とセキュリティ機能をTLS、REALITYなどの外側のレイヤーに委ねます。Clashユーザーにとって重要なのは type: vless だけではありません。ネットワーク転送、TLSの有効化、サーバー名、フロー制御フィールド、クライアントフィンガープリントなどの拡張も確認が必要です。プロトコル名よりも、組み合わせごとの互換範囲に注目してください。

VLESS over TCP、VLESS over WebSocket、VLESS over gRPCでは接続挙動が異なります。TCPはレイヤーが少なく、トラブルシューティングの経路も比較的短くなります。WebSocketではHTTPアップグレード、パス、ホストのフィールドが増え、gRPCではHTTP/2のセマンティクスとサービス名に依存します。さらにTLSなどのセキュリティレイヤーを重ねると、設定フィールドは増えていきます。サブスクリプション変換では、これらのフィールド間の対応関係を維持する必要があります。転送タイプをTCPに変更した後も、WebSocket専用のパスを残してカーネルの自動推測に期待することはできません。

VLESSの一部の拡張は、複数のプロジェクトで段階的に実装されています。mihomoは一般的なVLESSの組み合わせに対応していますが、旧版のClashオリジナルカーネルが同じ能力を持つとは限りません。古いGUIではYAMLを読み込めても、カーネル起動時に不明なプロキシタイプや不明なフィールドが報告される場合があります。そのため、VLESSを含むサブスクリプションには、継続的に保守され、mihomoの採用を明示しているクライアントが適しています。当サイトのダウンロードページでは、デスクトップ向けの候補としてClash PlusとClash Verge Revを確認できます。プラットフォーム別の入口はダウンロードページから選択してください。

認証に成功しても、すべての通信が正常とは限らない

TrojanやVLESSのノードが接続可能と表示されても、基本的な疎通確認が完了したことを示すだけで、TCP、UDP、IPv6、すべてのアプリプロトコルが検証済みとは限りません。テストでは、通常のウェブページ、長時間接続するアプリ、ドメイン名前解決、UDPが必要なアプリを最低限確認してください。一部のアプリだけが失敗する場合は、プロトコル自体が使えないと判断する前に、ルール、DNS、TUN、UDPの対応状況を調べます。

接続直後に切断される場合は、システム時刻、サーバーアドレスとポート、認証情報、TLSの有効化、SNI、証明書検証、転送タイプ、パスまたはサービス名の順に確認するのが一般的です。VLESSでは、flowなどの拡張フィールドがサーバー側で要求され、カーネルでも対応しているかを確認します。ログの「TLS handshake」「authentication」「unknown field」はそれぞれ異なるレイヤーを示します。ノードを何度も切り替えて元のエラーを隠すのではなく、キーワードから原因の層を特定してください。

選定の観点では、Trojanはサーバー側が標準TLSの入口を中心に構成され、パラメータが比較的固定されている場合に適しています。VLESSは、その転送方式とセキュリティレイヤーの組み合わせを活用し、クライアントのカーネルが関連拡張に明確に対応している場合に向いています。複数の端末でサブスクリプションを共有するなら、まず全端末のカーネル能力を一覧化し、共通して対応する組み合わせを選びましょう。デスクトップで使える新しい拡張が、古いモバイルクライアントやルータープラグインで完全に認識されるとは限りません。

04 · QUIC Transport

Hysteria2とTUIC：変動する経路向けのUDP方式

QUICとUDPを選ぶ理由

Hysteria2とTUICはいずれもQUICを重要な基盤とします。QUICはUDP上で動作し、ユーザー空間で暗号化接続、信頼性のある転送、複数ストリーム、輻輳制御を処理します。従来のTCP接続と比べ、一部のトランスポート層とセキュリティ層の往復を減らし、複数の論理ストリームが同じTCPの先頭ブロッキング状態を完全に共有することも避けられます。遅延の変動や一定のパケットロスがあり、高いスループットが必要な経路では、この設計がより多くの調整余地を提供します。

ただし、UDPは高性能を自動的に得るスイッチではありません。QUICも物理帯域、往復遅延、パケットロス、サーバーの出口、端末の処理能力に制限されます。一部のルーターでは長時間のUDPセッション保持時間が短く、ネットワークによってはUDPパケットのサイズや速度が制限されます。企業ネットワークで特定種類のUDP通信しか許可されない場合もあります。周期的に通信が途切れるなら、クライアントの測定先だけを変更するのではなく、NATセッション、MTU、経路品質、ネットワーク切り替えを確認してください。

Hysteria2の帯域幅と輻輳制御

Hysteria2はHysteriaシリーズの後継プロトコルで、設定には通常、サーバー、ポート、パスワード、TLSサーバー名、任意の帯域幅や偽装関連パラメータが含まれます。QUICと輻輳制御を活用し、複雑な経路でも転送効率を維持することを重視します。クライアントの上り・下り帯域幅設定は、通信事業者のプラン速度を表示する項目ではなく、輻輳制御アルゴリズムへの重要な入力です。実際に利用できる能力を大幅に上回る値を入力すると、送信が速くなりすぎてキューとパケットロスが増え、かえって安定性が低下することがあります。

帯域幅パラメータは、一時的なピーク値ではなく、長時間利用できる水準に基づいて設定します。まずは任意の値を記入せず、サーバーの推奨値またはカーネルのデフォルト動作を使う方法があります。手動設定が必要なら、安定した時間帯に複数回測定して保守的な範囲を決め、上りと下りを別々に観察してください。モバイル回線では上り性能の変動が大きいことが多く、上りを過大評価すると確認パケットやインタラクティブ通信に影響します。変更後は、ウェブページの初回応答、大容量ダウンロード、動画のシーク、端末のスリープ復帰をテストし、短時間の速度だけで判断しないでください。

Hysteria2はTLS関連の仕組みでサーバーを検証するため、システム時刻とサーバー名が重要です。サブスクリプションにSNIが指定されている場合は、元の値を維持してください。ノードがIPアドレスで接続する場合も、証明書に対応するドメイン名を削除してはいけません。証明書エラーが出たら、サブスクリプションの提供元に戻ってフィールドを確認します。偽装パスワードなどの拡張もサーバー側との一致が必要で、クライアント側だけで有効にしても接続は成立しません。

TUICのセッションと同時接続の特徴

TUICもQUICを基盤とし、ノードにはサーバー、ポート、UUID、パスワード、サーバー名、輻輳制御アルゴリズム、UDP転送モードなどのフィールドがよく使われます。低遅延での接続確立、多重化、UDPトラフィックの転送を重視した設計です。TUICの世代によってフィールドは完全には共通していないため、サブスクリプションの提供元、サーバー実装、クライアントカーネルで互換性のある形式を使う必要があります。tuic タイプを見つけても、別ノードのUUIDをコピーするだけでなく、認証フィールドとバージョンの意味を確認してください。

輻輳制御アルゴリズムは、確認応答、遅延、パケットロスに応じて送信速度を調整する方法を決めます。アルゴリズム名だけで環境を無視した優劣はありません。積極的な方式は帯域が十分なときにスループットをすばやく高められる一方、共有ネットワークやバッファが深い経路ではキューを増やす可能性があります。保守的な方式は安定しやすい反面、ピークに達するまで時間がかかることがあります。サブスクリプションにサーバーの推奨値があるなら、まずはそのまま使いましょう。再現性のある問題を繰り返し確認できた場合に限り、このフィールドだけを変更します。

TUICとHysteria2は、特に同時接続が多い場合、継続的な転送中、頻繁なキープアライブ中に、スマートフォンの無線モジュールをより活発な送受信状態に保つ可能性があります。一方、プロトコルが転送をすばやく完了してアイドル状態に移行できれば、全体の消費電力が下がることもあります。そのため、「UDPベース」という理由だけで消費電力の大小を判断できません。同じ画面輝度、同じアプリタスク、近い電波強度で、一定時間の利用サイクルを比較し、バックグラウンドでの再接続回数も観察してください。

信頼できるフォールバックを用意する

サブスクリプションにQUIC系とTCP系のノードが両方ある場合は、プロキシグループに両方の候補を残せます。ネットワークがUDPに対応している場合はHysteria2またはTUICを実測で優先し、ハンドシェイクのタイムアウト、ネットワーク切り替え後の復帰失敗、ルーター負荷の増大が起きた場合は、SS、TrojanなどのTCP転送ノードへ戻します。フォールバックはプロトコルを格下げする評価ではなく、接続方式を現在の経路に合わせるためのものです。

QUIC系ノードを調査するときは、まずクライアント内の不要な同時速度測定を停止し、テスト自体が帯域を使い切らないようにします。続いて、システム時刻、UDPの可用性、サーバーアドレスとポート、認証情報、SNI、証明書を確認し、MTUやパケットサイズに関する現象を調べます。少量の通信は正常なのに大容量通信で停止する場合は、経路MTU、輻輳制御、ルーターのUDP状態テーブルを重点的に確認します。最初からハンドシェイクできない場合は、UDP経路、ポート、認証、TLSパラメータの問題である可能性が高くなります。

05 · Performance

接続速度、リソース使用量、モバイルのバッテリー

「速度」を4つの指標に分ける

プロトコル比較でいう速度には、少なくとも接続確立時間、初回応答時間、安定したスループット、障害復旧時間が含まれます。接続確立時間はDNS、TCPまたはQUICハンドシェイク、TLS、認証の影響を受けます。初回応答時間には、サーバーが接続先へアクセスする時間も含まれます。安定したスループットは、帯域、輻輳制御、パケットロスからの復旧、端末の処理能力で決まります。復旧時間は、ネットワークや経路が変化した後にセッションをすばやく再確立できるかを示します。遅延値を1つだけ記録すると、これらの違いが説明できない結果に圧縮されます。

Clashクライアントの遅延テストは、指定URLへプローブを送信する仕組みです。完全に到達できないノードを除外したり、明らかな異常を見つけたりするには役立ちますが、実際のアプリ利用と同じではありません。測定先の位置、接続の再利用、DNSの結果、キャッシュが数値に影響します。ノード選定では、まず遅延テストで候補を絞り、その後に実際のアプリで継続的に検証します。2つのノードの測定結果が近いなら、わずかな数値差を追い続けるより、長時間接続の安定性と失敗率を重視してください。

公平に比較するには、変数を管理する必要があります。同じプロバイダー、同じ地域、近い時間帯、同じ接続先を選び、バックグラウンド更新とクラウド同期を停止し、各候補を一度ウォームアップしてください。各テストを複数回繰り返し、最速の結果だけでなく中央値と最悪時の結果を記録します。プロトコルノードが異なるサーバーにある場合、主な差はプロトコル設計ではなく回線や負荷に由来する可能性があります。

CPU、メモリ、同時接続

Shadowsocksの基本カプセル化は軽量です。VMess、Trojan、VLESSの具体的なコストは外側の転送方式とTLSに左右され、Hysteria2とTUICではユーザー空間でQUIC、暗号化、パケットロスからの復旧、輻輳制御を処理します。この順序は処理構造を示すだけで、固定的なリソースランキングに直接置き換えられません。成熟した実装、ハードウェアアクセラレーション、パケットサイズ、接続数で結果は変わります。低速なウェブ閲覧では差が小さくても、高速転送や数千接続ではシングルコアのボトルネックが現れることがあります。

メモリ使用量は通常、接続テーブル、DNSキャッシュ、ルールセット、ログ、TUN状態に応じて増加します。大規模なルールセットや複雑なDNS設定が、ノードプロトコル自体より多くのメモリを消費することもあります。クライアントをしばらく動かした後もリソース使用量が増え続けるなら、アクティブ接続が解放されていないのか、ログレベルが高すぎるのか、ルールプロバイダーの更新なのか、カーネルの異常なのかを切り分けます。プロトコルノードを切り替えるだけでは、ルールやログによるリソース問題は解決しません。

ルーターや小型サーバーでは、同時接続数とアーキテクチャをより重視する必要があります。Mihomoカーネルは端末のCPUアーキテクチャに適合していなければなりません。高スループットのQUICは、性能の低いCPUで早く処理上限に達する可能性があります。その場合は、同時測定数を減らし、処理コストの低いノードを選び、ログを減らし、ソフトウェア割り込みやNAT処理がボトルネックになっていないか確認します。当サイトのダウンロードページのLinux・カーネル欄では、デスクトップGUIとサーバー・ルーター向けのカーネルファイルを区別しています。一般的なデスクトップユーザーが独立したカーネルを手動管理する必要は通常ありません。

モバイルの消費電力は動作サイクルで決まる

スマートフォンの消費電力は、クライアントプロセスの瞬間的なCPU使用率だけでは判断できません。プロキシ接続は、無線モジュールのウェイクアップ、バックグラウンドのキープアライブ、DNSリクエスト、接続リトライ、システムVPNインターフェースに影響します。電波が弱いと送信電力と再送コストが上がります。プロトコルが頻繁に再接続すると、1回あたりの処理が軽くても、全体の消費電力は増える可能性があります。逆に、セッションを安定して維持し、データ転送をすばやく完了できる方式は、より早くアイドル状態に移行できることがあります。

モバイルのバッテリー消費を比較するときは、画面輝度、ネットワークタイプ、アプリタスク、テスト時間を固定します。ウェブ閲覧とメッセージを混ぜた30分の利用、同じサイズのファイル転送、画面ロック後のバックグラウンド通知と復帰という3種類のタスクを個別に実行するとよいでしょう。システムの電池残量の変化、端末温度、切断回数を記録します。短時間の速度測定ではバックグラウンドの挙動を確認できません。一日中の混合利用ではカメラ、位置情報、画面操作の影響を受けやすいため、段階的なテストのほうが原因を特定しやすくなります。

TUNモードはより多くのアプリ通信をカバーし、カーネルがルーティングとDNS処理に継続的に関与します。システムプロキシはプロキシ設定に従うアプリだけに影響するため、対象となるリソース範囲は比較的限定されます。プロトコルを比較するときは、プロキシモードを統一してください。そうしないと、プロトコル差ではなくTUNとシステムプロキシの差を測ることになります。AndroidとiOSではバックグラウンド管理の仕組みが異なるため、同じクライアントの結果をそのまま比較することもできません。

最終的な選択は、安定した範囲を基準にします。ときどき非常に高いピーク速度が出ても頻繁に停止するノードは、会議、同期、長時間接続のアプリには向きません。ピーク速度は少し低くても連続転送を維持できるノードのほうが、通常はデフォルトのポリシーに適しています。前者をダウンロードや大容量通信のプロキシグループに、後者を日常利用のデフォルトグループに入れ、ルールで通信を分けることで、プロトコルの特性を用途に合わせて活用できます。

06 · Kernel Family

オリジナルClash、Meta、mihomoの系譜

オリジナルClashが築いた設定モデル

オリジナルClashは、現在も広く使われる設定モデルを築きました。プロキシノードは proxies、プロキシグループは proxy-groups、ルールは rules に順番どおり記述し、システムプロキシ、透過プロキシなどの入口から通信を受け取ります。ルールに一致した接続は、プロキシグループまたは指定した出口へ渡されます。多くのサブスクリプションやチュートリアルが今もこの基本用語を使っているため、オリジナルの設定構造を理解する価値はあります。

オリジナルプロジェクトの保守状況は変化しており、対応プロトコルや拡張機能が現在のmihomoエコシステムを代表するわけではありません。基本的な互換レイヤーを理解する用途には使えますが、新しいノードタイプの対応基準と考えるべきではありません。Hysteria2、TUIC、VLESS拡張、複雑なDNS、ルールプロバイダーのオプションを含む設定には、通常mihomo系カーネルが必要です。オリジナルカーネルを固定的に内蔵する古いクライアントでは、これらのフィールドを認識できないことがあります。

Clash.Metaの拡張プロトコルとネットワーク機能

Clash.Metaは従来の設定モデルに、プロトコル、転送、DNS、TUN、スニッフィング、ルール関連の機能を追加しました。一般的なClash設定の移行経路をできるだけ維持しながら、新しいノードタイプとフィールドを導入しています。ユーザーにとって最も直接的な変化は、同じサブスクリプションにより多彩なプロトコルの組み合わせを含められ、クライアント側でも透過プロキシとDNSをより細かく制御できる点です。

拡張機能に対応していても、すべてのオリジナル設定が完全に同じ結果になるとは限りません。DNSのデフォルト値、ルールセットの動作、TUNスタック、スニッフィング、接続処理は、設定や実装の更新によって変わる可能性があります。移行時はまず元の設定を保存し、カーネルの設定チェック機能で構文を確認してから、ノード、プロキシグループ、ルール、DNS、TUNの順に検証します。すべての拡張を一度に有効にすると、問題の原因を特定しにくくなります。

mihomoが現在の名称

mihomoはClash.Metaの後継プロジェクトで使われている名称です。実際の資料では「Meta core」「Clash.Meta」「mihomo」が同時に登場することがあります。これらはプロジェクトの歴史やクライアント画面での異なる呼び方を反映しており、互いに無関係な3つのカーネルという意味ではありません。現在のクライアントがmihomoの使用を明記している場合、通常はMeta系のプロトコルと設定機能を引き継いでいることを示します。ただし、対応範囲はクライアントに同梱されたカーネルと設定説明を確認してください。

GUIクライアントとカーネルの更新ペースは異なる場合があります。クライアント画面に新しい設定項目が追加されても、対応するパラメータを下層のカーネルが提供していなければ動作しません。逆に、カーネルが対応する新しいフィールドが、GUIの操作項目として実装されていないこともあります。多くの場合、サブスクリプションのノードはカーネルが直接読み取るため、重要なのは製品名にClashが含まれるかではなく、クライアントが実際にどのカーネルを呼び出しているかです。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuなどの位置付けと対応プラットフォームはクライアント比較ページで確認できます。

設定の互換性はレイヤーごとに判断する

第1層はYAML構文の互換性です。インデント、リスト、キーと値の構造が正しくなければ、設定は解析できません。第2層はフィールドの認識で、カーネルが type、転送、拡張フィールドの意味を理解する必要があります。第3層は意味上の互換性です。フィールドが存在していても、デフォルト値や組み合わせの制約が同じとは限りません。第4層は実行環境の互換性で、TUN権限、システムプロキシインターフェース、ネットワーク拡張、ファイアウォールルールなどが含まれます。構文チェックだけで、後半3層が正常だとは証明できません。

基本的なSS、VMess、Trojanノードと一般的なプロキシグループは、比較的移行しやすい構成です。一方、VLESS、Hysteria2、TUIC、REALITY、複雑なDNS、TUNオプションはmihomoの能力により強く依存します。複数のクライアントで同じ設定を使うなら、共通して対応するノード、プロキシグループ、ルールだけを置いた共通基盤を用意し、デスクトップ、モバイル、ルーター向けにはローカル設定を追加してください。すべてのプラットフォーム向けオプションを1つのYAMLに詰め込むより、保守しやすくなります。

Clash for Windowsから移行するときは、GUI設定と設定ファイルの内容も分けて考える必要があります。ウィンドウの挙動、自動起動、システムプロキシのポート、更新設定はアプリのローカルに保存され、サブスクリプションには引き継がれないことがあります。ノード、プロキシグループ、ルールは通常設定から読み込まれます。アプリのフォルダーをそのままコピーするのではなく、Clash for Windows終了後の移行方法を参考に項目ごとに整理してください。

mihomo -t -f config.yaml

上のコマンドは、独立したmihomoカーネルで設定ファイルをチェックするためのものです。クライアントによってはカーネルがアプリ内部に組み込まれているため、ユーザーがコマンドを直接実行する必要はありません。ダウンロードページで提供している独立カーネルを使う場合は、ターミナルでファイルのあるディレクトリに移動し、config.yaml を実際の設定パスに置き換えてください。チェックに成功しても、構文と認識済みフィールドを読み込めたことを示すだけです。起動後にポート、DNS、ルール、ノード接続をテストする必要があります。

07 · Subscription

サブスクリプション形式、フィールド変換、互換性の境界

サブスクリプションURLは統一ファイル形式を意味しない

ユーザーは通常、リモートアドレスをまとめて「サブスクリプション」と呼びます。しかし、そのURLが返す内容はClash YAML、URIリスト、Base64でラップされたテキスト、特定クライアント向けのJSONなどさまざまです。クライアントに直接インポートできるかどうかは、返却形式を認識できるか、または変換機能を内蔵しているかで決まります。HTTPリクエストが成功しただけでは、ノードフィールドが正しく解析されたことにはなりません。

Clash YAMLは通常、ポート、DNS、ノード、プロキシグループ、ルール、ルールプロバイダーを一度に記述でき、完全な設定の配布に適しています。URIリストは個々のノードに重点を置き、各プロトコルが独自のリンク構造を使います。複雑な転送フィールドはクエリパラメータで表現されることがあります。クライアントがURIリストをClash設定に変換するときは、ノードオブジェクトを生成してプロキシグループに追加する必要があります。変換器が新しいフィールドを理解していないと、ノードの欠落、パラメータの消失、タイプの簡略化が起きる可能性があります。

インポート後に4つの層を確認する

第1に、設定が正常に更新されたかを確認し、更新日時と取得元の名称を記録します。更新に失敗したら、古い設定をすぐに削除せず、HTTPステータス、証明書、ネットワーク、URLの有効性を確認してください。第2に、ノード数とタイプを確認し、SS、VMess、Trojan、VLESS、Hysteria2、TUICなど想定したタイプが存在するかを見ます。第3に、サーバー名、TLS、転送パス、UUID、パスワード、UDPオプションを中心にフィールドを抽出確認します。第4に、プロキシグループが参照するノード名が残っているかを確認します。インポート済みでも、選択可能なグループに入っていない場合があるためです。

ノードの表示名は、信頼できる一意の識別子ではありません。サブスクリプションの更新で名前が変わったり、地域の接頭辞が追加されたり、並び順が変更されたりすると、古い名前を手書きで参照しているプロキシグループはノードを見つけられなくなります。正規表現による絞り込みやプロキシプロバイダーを使う場合も、新しいノードを意図せず除外しない式になっているか確認してください。長期的に固定したい場合は、一覧の位置ではなく、明確なプロキシグループと自動選択条件を使うことをおすすめします。

サブスクリプション変換で最も失われやすいのは、ネストされた転送パラメータです。VMessやVLESSのWebSocketパス、Host、gRPCサービス名、TrojanのSNI、Hysteria2の認証とTLSパラメータ、TUICの輻輳制御と認証フィールドは保持する必要があります。変換後に基本ノードは使えるのに特定のタイプだけがすべて失敗する場合は、グローバルDNSを変更する前に、そのタイプの元フィールドと生成されたYAMLを比較してください。

設定のマージでは上書きルールを明確にする

一部のクライアントでは、リモートサブスクリプションにローカル上書きを重ねて、カスタムルールの追加、DNSの変更、プロキシグループの作成などができます。マージの仕組みには、キーによる上書き、リスト追加、スクリプト処理、テンプレート生成などがあり、適用順序もクライアントごとに異なります。上書き前に「リモートの値がローカルを上書きするのか」「ローカルの値が最後に有効になるのか」を確認してください。特に rules や proxy-groups のようなリストは注意が必要です。追加順を誤ると、フォールバックルールが先に一致し、後続のルールが実行されなくなることがあります。

ルールは上から順に照合され、一致すると後続の確認を停止します。ローカル設定で MATCH または同等のフォールバックルールを先頭に置くと、リモートルールが正常にマージされても機能しません。プロキシグループでは、名前が一意で参照関係が完全であることを確認します。循環参照は設定エラーの原因になります。DNSの上書きはノードサーバーの名前解決経路にも影響するため、nameserver、fake-ip、プロキシサーバーの名前解決設定を変更した後は、ノードのドメイン名も正常に解決できるか確認してください。

サブスクリプションの安全管理と保守習慣

サブスクリプションURLには、アカウントや設定を識別するランダムなパスが含まれることが多く、機密情報として扱う必要があります。公開ページ、スクリーンショット、ログに掲載しないでください。トラブルシューティングではノードタイプとマスク済みのフィールドだけを示し、完全なURL、パスワード、UUIDは隠します。他人に確認を依頼する場合は、まず設定を複製して認証情報を置き換え、使用中の元ファイルを直接編集しないようにしてください。

サブスクリプションを更新する前に、直近で利用できた設定を保存しておくと、「リモート内容の変化」と「ローカルクライアントの変化」を切り分けやすくなります。更新後にすべてのノードが消えた場合は、古い設定に戻して確認します。古い設定も失敗するなら、ネットワーク、システム時刻、サーバーの状態を調べてください。クライアントのアップグレードとサブスクリプション更新は、できるだけ同時に行わないことをおすすめします。問題が起きたとき、変化の原因がカーネルなのかリモート設定なのか分からなくなるためです。

複数の端末で同じサブスクリプションを使う場合は、ノード情報とプラットフォーム設定を分離するのがおすすめです。サブスクリプションにはノードと共通ポリシーを置き、ローカルクライアントにはシステムプロキシ、TUN権限、起動動作、プラットフォーム固有のDNSを任せます。iOS、Android、Windows、macOS、Linuxではシステムインターフェースが異なります。特定プラットフォームのパス、ネットワークインターフェース名、権限フィールドを共通設定に入れると、移植性が低下します。プラットフォーム向けのクライアントを選ぶ場合は、ダウンロードページから対応タブへ進んでください。Clash Plusを全プラットフォーム向けの第一候補とし、他のクライアントはOSと設定要件に応じて選びます。

インポート、更新、プロキシグループの参照に問題が残る場合は、よくある質問でインストール設定とトラブルシューティングの分類から確認を続けてください。設定構造をセクションごとに読み解く必要がある場合は、Clash設定ファイルの構造解説を参照し、ポート、ノード、プロキシグループ、ルールの参照関係を理解してから、クライアント固有の上書きを確認します。

08 · Scenario Guide

端末と利用シーンに合わせてプロトコルを選ぶ

デスクトップの日常利用：安定した基準を優先

WindowsとmacOSのデスクトップでは、まず長期的に安定したデフォルトのプロキシグループを作るのが適しています。サーバーがShadowsocks、Trojan、成熟したVMessノードを提供しているなら、フィールドが明確で接続が安定するものから始めます。VLESS、Hysteria2、TUICは、対応状況を確認したうえで候補に加えてください。デフォルトグループにすべてのノードを入れる必要はありません。数が多すぎると選択コストが増え、自動テストでも接続の確立が頻繁に発生します。プロトコルや用途ごとにグループを分け、上位グループから選ぶ構成が便利です。

クライアントは、全プラットフォーム対応のClash Plusを第一候補にできます。Clash Verge Revは、デスクトップでルール、サブスクリプション、mihomo設定を管理したいユーザーに適しています。古いクライアントから移行する場合は、すぐにアプリ設定をすべてコピーせず、まずサブスクリプションと基本ルールをインポートします。システムプロキシのポート、DNS、ノードの利用可能性を確認してから、必要に応じてTUNを有効にしてください。こうすれば、システム権限の問題とプロトコル接続の問題を切り分けられます。

オフィス作業、会議、インスタントメッセージでは、ピーク速度より継続性が重要です。長時間接続が安定し、ネットワーク復旧にも強いノードを選びます。大容量ファイルのダウンロードや同期は専用のプロキシグループに分け、スループットが高い一方でリソース使用量が増える可能性のあるHysteria2、TUIC、その他のノードを選べるようにします。アプリごとにルールで割り当てるほうが、グローバルノードを頻繁に手動で切り替えるより制御しやすくなります。

スマートフォンとタブレット：ネットワーク切り替えとバックグラウンド復帰を優先

モバイルで最初にテストすべきなのは、Wi-Fiとモバイル回線の切り替え、画面ロック後の復帰、弱い電波での再接続、システムVPNの安定性です。固定Wi-Fiで高速でも、ネットワーク切り替え後に手動再接続が必要なら、デフォルトのモバイルノードには向きません。SSやTrojanなどの成熟した組み合わせを基準にし、Hysteria2やTUICは、実際のモバイル回線で安定して動作し、スループットや復旧性能が求められる用途に使います。

バッテリー比較は、少なくとも1つの完全な利用サイクルを対象にし、プロキシモードを統一してください。ノードの測定間隔が短すぎる、プロキシグループの自動テストが頻繁すぎる、ログを継続的に書き込む、大量のバックグラウンド通信がある、といった条件は消費電力を大きく見せます。まず自動テストの頻度を下げ、不要なデバッグログを停止してからプロトコルを比較します。そうしないと、結論はノードタイプではなくクライアント設定を反映してしまいます。

iOSとAndroidではバックグラウンド処理が異なり、クライアントで利用できる機能も違います。デスクトップ向けYAMLのTUN、ネットワークインターフェース、スクリプトパラメータをすべてモバイルにコピーしないでください。サブスクリプションにはノードと共通して対応するポリシーだけを残し、プラットフォームの権限とDNSはモバイルクライアント側で管理します。iOSユーザーはダウンロードページからClash PlusのApp Store入口を選べます。Androidでは、画面の使いやすさと設定互換性に応じて、Clash Plus、Clash Meta for Android、FlClash、Surfboardを比較できます。

ルーターと常時稼働デバイス：リソースと保守性を優先

ルーター、ホームサーバー、小型Linuxデバイスでは、まずCPUアーキテクチャ、メモリ、ストレージ、システムサービスの管理方式を確認します。独立したmihomoカーネルは、コマンドライン、設定ファイル、サービスログに慣れたユーザーに適しています。一般的なデスクトップユーザーにはGUIクライアントが向いています。低消費電力の端末では、GUIの有無よりもルールセットの規模、同時接続数、DNSキャッシュのほうがリソース使用量に大きく影響することがあります。

プロトコルは、端末が継続的に処理できるスループットを上限として選びます。Hysteria2やTUICは、経路条件が合えば良好な転送性能を示す可能性がありますが、ユーザー空間でのQUIC処理がCPUを消費します。端末の処理能力が不足している場合は、SSなどの軽量な組み合わせのほうが安定することがあります。転送中のCPUシングルコア使用率、ソフトウェア割り込み、メモリを確認し、ボトルネックが端末、回線、サーバーのどこにあるかを特定してください。

常時稼働する端末では、フォールバック設定がより重要です。検証済みの基本YAMLを保存し、実験的なプロトコルは別のプロキシグループに入れます。カーネルを更新する前に設定チェックを実行し、更新後はDNS、ノード、ルール、LANアクセスの順に確認します。カーネル、サブスクリプション、ルールセット、システムネットワークコンポーネントを同時に更新しないでください。変更を分けると時間はかかりますが、障害の特定時間を大幅に短縮できます。

繰り返し実行できる判断プロセス

第1に、サブスクリプションが実際に提供するプロトコルと、現在のクライアントカーネルを一覧にします。クライアント上でノードを推測したり変換したりしないでください。第2に、ネットワーク経路でグループ化します。TCP系ノードを基本候補とし、Hysteria2とTUICはUDPの検証が必要な候補に分類します。第3に、TLS、SNI、UUID、パスワード、転送パス、サービス名など、必要なフィールドが揃っているか確認します。第4に、固定した接続先で接続確立、継続的なスループット、ネットワーク切り替え後の復旧、リソース使用量を測定します。

第5に、端末に合わせてデフォルトノードを選びます。デスクトップでは安定性と長時間稼働、モバイルではバックグラウンド復帰とバッテリー、ルーターではリソース上限とサービス管理を優先します。第6に、明確な強みがあるものの用途が限定されるノードは、ダウンロード、ストリーミング、大容量同期などの専用プロキシグループに入れます。第7に、現在利用できる設定とテスト条件を記録し、サブスクリプションやカーネルが変わった後に再比較できるようにします。

結果の差が小さい場合は、フィールドが分かりやすく、複数の端末で使え、保守コストが低い方式を選びます。プロトコル選定の目的は、理論上最も複雑な組み合わせを探すことではありません。現在のサーバー、ネットワーク、端末の条件で、説明可能で、復旧しやすく、移行しやすい接続を得ることです。安定して動作し、問題を簡単に切り分けられる設定は、多数の特定拡張に依存する設定よりも、長期的な基準として適しています。

選定が終わったら、Clash Verge Revチュートリアルに戻り、手順に沿ってサブスクリプションをインポートし、ルールモードを選択して接続を確認できます。ルールの順序をさらに調整する場合は、Clashのトラフィック分岐設定とプロキシグループ実践を参照してください。クライアントが設定エラーを報告し続ける場合は、元のログに記録された最初のエラーを保存し、よくある質問ページで設定解析、接続確立、DNS、システムプロキシの4方向から確認します。