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

02 · TCP FAMILIES

SS、VMess、Trojan、VLESS の設計上の選択

SS：構成がコンパクトで、暗号化方式への依存が明確

Shadowsocks は通常 SS と略されます。比較的軽量なプロトコル構造でプロキシトラフィックを運び、事前共有パスワードと指定した暗号化方式でデータを保護する設計です。現在のカーネルがサポートする AEAD 方式を使い、サーバーとクライアントの暗号化方式、パスワード、ポートを完全に一致させる必要があります。SS は項目が少なく、サブスクリプションのインポートやクライアント間の移行も比較的簡単です。ログに出る失敗原因も、ポート、パスワード、暗号化方式、ネットワーク到達性の順に切り分けやすいでしょう。

項目が少ないからといって、すべての SS ノードの挙動が同じとは限りません。サーバー実装、暗号化アルゴリズムのハードウェアアクセラレーション、UDP リレー、プラグインパラメータ、基盤ネットワークが結果に影響します。サブスクリプションによっては plugin と plugin-opts が付加され、追加の伝送層を利用します。現在のカーネルが指定プラグインに対応していなければ、server、port、cipher、password が正しくてもノードは使えません。リソースに制約のあるルーターでは SS が理解しやすい出発点になりやすいものの、暗号化の負荷は対象アーキテクチャで実測し、デスクトップ CPU の結果だけから推測しないでください。

VMess：認証、時刻、伝送オプションが多い

VMess は V2Ray エコシステムに由来し、設定にはユーザー識別子、alterId、暗号化オプション、ネットワーク伝送、TLS などの項目が含まれることがよくあります。過去の設定ではさまざまな alterId の値が見られますが、近年のサーバー構成ではより簡略化された組み合わせが一般的です。一方、クライアント側には古いサブスクリプションとの互換性のため解析項目が残っている場合があります。VMess の認証処理は時刻に敏感なため、端末の時刻が大きくずれていると認証に失敗することがあります。切り分けではアドレスとユーザー識別子だけでなく、システム時刻が正常に同期されているかも確認してください。

VMess の実際の複雑さは、複数の伝送方式を組み合わせられる点にあります。TCP、WebSocket、HTTP、gRPC では、パス、リバースプロキシ、サーバー設定の要件が異なります。WebSocket では path と Host、gRPC では service-name を確認します。TLS を有効にする場合は servername、証明書検証、ALPN も確認が必要です。サブスクリプション変換ツールが、あまり一般的でない伝送項目を落とすこともあります。その場合、ノード名や基本情報は正しいのにハンドシェイクだけが失敗します。変換前後の単一ノード設定を項目ごとに比較し、プロキシモードを何度も切り替えるのは避けてください。

Trojan：TLS を利用し、証明書パラメータが重要

Trojan は通常、標準 TLS 接続でデータを運び、認証の中心にパスワードを使います。設定は一見シンプルですが、TLS 関連の項目が接続可否を左右します。server は実際の接続先、servername または SNI は TLS ハンドシェイクで使うホスト名です。両者は同じ場合もあれば異なる場合もあります。ドメイン名で接続する場合は、DNS 解決、証明書の有効性、ホスト名の一致がすべて成立しなければなりません。サブスクリプションがドメイン名を IP に置き換えたのに正しい servername を保持していないと、TCP には到達できても TLS 検証に失敗することがあります。

証明書エラーを回避するために skip-cert-verify を直接有効にするユーザーもいますが、これはドメイン名、証明書チェーン、システム時刻の問題を隠してしまいます。まず端末の時刻を確認し、次に servername が証明書の名前と一致するかを確認し、その後でサーバーの証明書チェーンとネットワーク経路を確認するのが安全です。証明書検証に失敗した理由を明確に把握し、相応のリスクを受け入れられる場合に限って検証方針を変更してください。Trojan は WebSocket や gRPC などの伝送も利用できます。切り分けは VMess と同様に、まず TLS、次に path、Host、service-name、最後に UDP とポリシーグループの挙動を確認します。

VLESS：プロトコル層の負担を減らし、安全性は伝送層に依存

VLESS も V2Ray 系に由来しますが、設計上は VMess と同じ暗号化機構をプロトコル層に持たず、通常は TLS などの安全な伝送で機密性と認証を確保します。ユーザー識別子で認証し、uuid、flow、network、tls、servername、および伝送方式に対応する追加項目を設定することが一般的です。プロトコル層の処理が直接的なため、柔軟な伝送の組み合わせが必要な構成でよく使われますが、「項目が少ない」ことは安全な伝送を省略できるという意味ではありません。

VLESS の互換性問題は拡張機能に集中します。flow、Reality、クライアントフィンガープリント、伝送の詳細、UDP の挙動について、各カーネルの対応時期は一致しません。mihomo は複数の VLESS 拡張に対応していますが、利用できる項目は現在のカーネル文書と実行ログを基準にしてください。サブスクリプションに未知の項目があると、パーサーが無視する場合もあれば、ノード全体を拒否する場合もあります。エラーにならず無視されるほうが、ノードがインポート済みに見えるため実行時まで気づきにくい点に注意が必要です。別のクライアントへ移行する前に、重要な拡張項目が変換で消えていないか確認してください。

proxies:
  - name: "SS baseline"
    type: ss
    server: example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

上の例は SS ノードの最小構成を示したもので、項目の関係を確認するためのものです。実際のアドレス、ポート、パスワード、暗号化方式はサーバー設定の値を使用してください。YAML はインデントに敏感です。リスト項目の下にあるフィールドは同じ階層を保つ必要があります。パスワードにコロン、シャープ記号、その他の特殊文字が含まれる場合は引用符で囲んでください。設定の読み込み失敗と接続失敗は別の問題です。前者では YAML 構文と項目名を確認し、後者ではネットワーク、認証、サーバー状態を確認します。

04 · PERFORMANCE

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

接続確立時間と継続的なスループットは別の指標

ウェブページの表示速度は、DNS、TCP または QUIC のハンドシェイク、TLS、サーバー処理、ページ内リソース数の影響を受けます。プロトコルのハンドシェイクが軽くても、短縮できるのはその一部だけです。DNS が遅い場合や、ページが複数のドメインへ接続する場合、単一接続の利点が体感速度に表れないこともあります。継続的なダウンロードでは、経路容量、輻輳制御、サーバー側の出口がより重要です。短時間接続のテストは複数の対象へ繰り返しアクセスし、キャッシュの影響を抑えてください。継続転送は十分な時間を確保し、速度の安定性、周期的なゼロ化、ネットワーク切り替え後の復旧を観察します。

多重化も慎重に理解する必要があります。複数の論理接続を少数の基盤接続にまとめると、重複したハンドシェイクを減らせますが、基盤接続が混雑または切断したときの影響範囲も広がります。TCP 上の多重化は、1本の TCP 接続におけるパケットロス回復の影響を受けます。QUIC のマルチストリーム設計はストリーム間のブロックを減らせますが、ユーザー空間で管理する状態は増えます。短いリクエストが大量にある場合は有効なことがありますが、少数の長時間・大容量接続では効果が明確でない場合もあります。デフォルトで有効・無効のどちらが正しいと決めつけず、アプリケーションの種類に応じてテストしてください。

CPU、メモリ、暗号化の負荷

SS のリソース消費は、暗号化方式、プロセッサの命令セット、同時接続数に左右されます。ハードウェアアクセラレーションに対応するデスクトップ CPU は一般的な AEAD アルゴリズムを効率よく処理できますが、低消費電力アーキテクチャでは別のアルゴリズムのほうが有利なこともあります。Trojan、VMess over TLS、VLESS over TLS はいずれも TLS 処理を必要とし、実際の負荷は WebSocket、gRPC、追加の多重化を使うかどうかでも変わります。Hysteria2 と TUIC は暗号化に加え、ユーザー空間で QUIC の確認応答、再送、輻輳、ストリーム状態を管理します。

メモリ使用量は通常、プロトコル名だけでは決まりません。接続数、ルールの規模、DNS キャッシュ、TUN ルーティング、ログレベル、provider 数のほうが単一ノードの差より大きく影響する場合があります。ルーターでメモリ不足が起きた場合は、まず不要なルールセットを減らし、長すぎる provider の連鎖を短くし、詳細ログの継続出力を制限してからプロトコルを比較してください。デスクトップでは起動直後の数値だけでなく、長時間稼働後も増え続けていないか確認します。異常な増加があった場合は、設定構造と再現手順を保存するほうが、特定のプロトコルが「メモリを多く使う」と決めつけるより原因特定に役立ちます。

モバイル端末の電池消費はスリープ解除の頻度に左右される

スマートフォンの電池消費は暗号化計算だけでなく、無線モジュールと CPU が起動する頻度に大きく左右されます。頻繁なノードヘルスチェック、短すぎる DNS キャッシュ、継続的なログ出力、バックグラウンド速度測定、過剰なキープアライブはすべてスリープ解除を増やします。1回あたりの処理量が小さくても、長時間積み重なると待機時間に明確な影響が出ます。QUIC ベースのノードは NAT マッピングを維持するためにキープアライブを送ることがあり、TUN モードではより多くのシステムトラフィックを処理します。バックグラウンドアプリが多い端末では、これらの要因が重なります。

最適化は、まず全体の動作から見直し、その後にプロトコルを変更します。ヘルスチェック間隔は障害検知に必要な合理的な値に設定し、複数の provider が高頻度で同時に検査しないようにします。実際に使うポリシーグループだけを残し、デバッグ終了後は通常のログレベルに戻します。すべてのトラフィックを取り込む必要がない場合は、システムプロキシを優先します。LAN 接続の許可設定も実際の用途に合わせて確認してください。これらを調整してから、同じ時間帯に TCP と QUIC のノードを比較します。テスト中は画面輝度、アプリの活動、ネットワーク種別を近づけないと、システムスケジューリングの差がプロトコル差を隠してしまいます。

再現可能なテスト記録を作る

テスト表には少なくとも、端末、OS、クライアント、カーネル、ネットワーク種別、取り込み方式、DNS モード、ノードプロトコル、テスト時間帯を記録します。一度に変更する変数は1つだけにします。たとえば、ルールモードとシステムプロキシを固定して SS と Hysteria2 のノードだけを入れ替え、次のラウンドでノードを固定してシステムプロキシと TUN を比較します。各ラウンドでは成功率とエラー種別も記録してください。5回の接続で2回タイムアウトするなら、成功時の速度が高くても自動選択グループの唯一のノードには向きません。

モバイル端末の電池消費は、少なくとも日常利用の1サイクル全体で観察し、システムの電池画面でクライアントの前景・バックグラウンド活動も確認してください。数分の短時間実行では、待機中のキープアライブコストを判断できません。消費電力が異常な場合は、まず能動的なヘルスチェックをすべて停止し、詳細ログを無効にしてから1項目ずつ戻し、スリープ解除の原因を特定します。バックグラウンド動作と省電力設定の詳しい手順はClash のスマホで電池が早く減る場合の対策を参照してください。

06 · SUBSCRIPTIONS

サブスクリプション形式、設定互換性、項目の保持

ノードリンク、ノード一覧、完全な設定

「サブスクリプション」は、異なる3種類の内容を指すことがあります。1つ目は、ss、vmess、trojan、vless などのプロトコルリンクで構成されたノード一覧です。クライアントまたは変換サービスがリンクを解析し、Clash ノードに変換します。2つ目は、すでに変換済みの proxies 一覧で、ノードだけを含み、完全なルールや DNS は含みません。3つ目は、完全な Clash または mihomo 設定で、ノードに加えて proxy-groups、rules、rule-providers、dns、tun なども含みます。インポート前に種類を判断すれば、完全な設定をノード provider として扱ったり、サブスクリプション更新でローカルルールを上書きしたりするミスを防げます。

ノードリンクはツール間で渡しやすい一方、すべての拡張パラメータを統一して表現できるわけではありません。VLESS の flow、Reality 項目、Hysteria2 の帯域幅と難読化パラメータ、TUIC の認証と輻輳制御オプションは、リンク仕様、生成側、変換側の違いで失われることがあります。完全な YAML はより多くの項目を表現できますが、対象カーネルへの依存も明確になります。複数の mihomo クライアント間で複雑な設定を移行する場合は、共有リンクへ何度も変換するより YAML を保持するほうが信頼できます。

proxy-providers はソースを管理するもので、プロトコル変換ではない

proxy-providers を使うと、mihomo はファイルまたは URL からノード集合を読み込み、interval に従って更新できます。ノードのソースとメイン設定を分離し、複数のポリシーグループから同じ provider を参照する用途に適しています。provider の health-check はテストアドレスへ定期的にアクセスし、ノードの利用可能性を判断できますが、チェック頻度はネットワーク通信量とモバイル端末の電池消費に影響します。provider が読み込めるのは、対象カーネルが解析できる形式だけです。互換性のない形式がリモートから返された場合、provider に入れるだけで任意のプロトコルへ自動変換されるわけではありません。

proxy-providers:
  primary:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 1800
      url: "https://www.example.com/"

例にあるドメインは構造を示すためのものです。url は実際のサブスクリプションアドレスに置き換え、アクセス資格情報を含むリンクを公開しないでください。path はカーネルの作業ディレクトリ内のキャッシュファイルを指します。interval は更新間隔、health-check の interval はヘルスチェック間隔で、意味が異なります。テストアドレスは安定して応答が小さく、実際のネットワーク対象と比較しやすいものを選びます。複数の provider に短いチェック間隔を設定すると、クライアントはバックグラウンド接続を継続的に発生させるため、特にモバイル端末では頻度を抑えてください。

変換で最も失われやすいのは拡張項目

サブスクリプション変換は通常、ソース形式の解析、項目のマッピング、出力 YAML の生成という3段階で行われます。従来型の SS、VMess、Trojan は一般的な項目の対応付けが成熟していますが、プラグイン、gRPC、Reality、クライアントフィンガープリント、Hysteria2、TUIC の拡張項目は変換ツールの能力に左右されやすくなります。変換後は各プロトコルから少なくとも1つのノードを抽出し、server、port、uuid または password、network、tls、servername、alpn、flow、udp などの重要項目を比較してください。ノード数だけを比較してはいけません。数が同じでも項目が欠落していることがあります。

ノード名が管理に影響することもあります。変換器が重複排除のためノード名を変更すると、proxy-groups に古い名前を直接書いている場合、読み込み時にプロキシが見つからないエラーになります。providers でノード集合を参照すれば名前への依存を減らせますが、ルールの対象とポリシーグループ名は存在していなければなりません。完全な設定を移行するときは、まずすべてのルールが最後に指すポリシーグループを確認し、次にポリシーグループが参照するノードまたは provider を確認します。rules、proxy-groups、proxies の参照チェーンを順に追う形です。

YAML の構文が正しくても意味上のエラーは起こる

YAML 検査で見つけられるのは、インデント、重複構造、型の問題です。リモートアドレス、パスワード、SNI、ルール対象が正しいかまでは確認できません。よくある意味上のエラーには、ポートを文字列として記述したため一部のパーサーに拒否される、真偽値の表現が統一されていない、同名のポリシーグループが重複している、ルールが存在しないグループを指している、provider のパスに書き込み権限がない、サーバーが対応しない UDP をノードで有効にしている、といったものがあります。まずカーネルの設定検査を実行し、その後起動して、最初の provider 更新、DNS 初期化、ノードハンドシェイクのログを確認してください。

完全なサブスクリプションをサービス提供者が管理している場合、ローカルで変更しても次回更新時に上書きされることがあります。長期的に残したいルールは、リモートキャッシュファイルを直接編集せず、クライアントが対応するオーバーライド、マージ、ローカル設定の層に置いてください。オーバーライド機能の名称と対応範囲はクライアントごとに異なるため、移行前にローカルルールをエクスポートします。Clash Plus などのクライアントは設定管理を簡単にできますが、リモートサブスクリプション、生成後の実行設定、ローカルオーバーライドの3層は区別する必要があります。切り分けでは、実際に有効なのがどの設定かを確認してください。

08 · MIGRATION

プロトコルテスト、設定移行、障害の切り分け

移行前に復元可能な最小設定を作る

旧クライアントから Clash Plus、Clash Verge Rev、FlClash、その他の mihomo クライアントへ移行するときは、まず旧クライアントで動作する設定を残し、すぐに削除しないでください。新しいクライアントにはノード1つ、または provider 1つだけを追加し、DIRECT、単一プロキシ、MATCH で構成した最小限のルールを作ります。コアの起動、DNS、システムプロキシが正常であることを確認してから、完全なポリシーグループ、ルールセット、TUN を追加します。これにより、クライアントのインストール問題、カーネル互換性問題、複雑な設定問題を分離できます。

オリジナル版 Clash の設定を mihomo へ移行する場合、多くの基本項目は引き続き使えますが、DNS と TUN のデフォルト動作は確認してください。逆方向へ移行する場合は、VLESS、Hysteria2、TUIC などオリジナル版が対応しないノードと Meta 拡張ルールを削除する必要があります。ポリシーグループの参照も同時に更新しなければ、対象が存在せず設定に失敗します。大量変更を行う前に必ずファイルをコピーし、カーネルの検査コマンドで構文を確認してから、実行中の設定を置き換えてください。

段階ごとにログを読む

起動段階のログは「設定を読み込めるか」を示します。YAML 解析、未知の項目、provider ファイル、待ち受けポート、TUN 権限を重点的に確認します。更新段階のログは「リモート内容を取得して解析できるか」を示します。サブスクリプションリクエスト、返却形式、キャッシュパス、ノード数を確認します。接続段階のログは「対象トラフィックがルールに一致し、ハンドシェイクを完了できるか」を示します。ルール対象、ノード名、DNS、タイムアウト、TLS、認証情報を確認してください。異なる段階を混同すると、サブスクリプション更新に成功したからノードのハンドシェイクも成功するといった誤判断につながります。

一般的な dial tcp timeout は、規定時間内に TCP 接続が完了しなかったことを示します。アドレスに到達できない、ポートが遮断されている、DNS の結果が異常、サーバーが待ち受けていないなどの原因が考えられます。connection refused は対象が明確に接続を拒否したことを示すため、まずポートとサービス状態を確認します。TLS エラーではシステム時刻、servername、証明書を確認し、authentication failed ではパスワード、UUID、認証文字列を確認します。QUIC ノードが継続的にタイムアウトする場合は、まずネットワークを変更して UDP 経路を判断し、その後プロトコルパラメータを確認してください。ログの文面と切り分け順序はClash の実行ログの読み方で詳しく説明しています。

ポート、システムプロキシ、TUN を層ごとに確認する

mixed-port は HTTP と SOCKS の入口を同時に提供するためによく使われます。システムプロキシを有効にしたら、OS がクライアントの実際の待ち受けアドレスとポートを指している必要があります。ポートが別のプログラムに使われていると、カーネルが起動に失敗することがあります。画面上のスイッチがオンでも、待ち受けが成功しているとは限りません。まず他のプロキシツールを終了し、ログの待ち受けエラーを確認してください。LAN 共有には allow-lan、ファイアウォール、正しい待ち受けアドレスも必要で、別の端末に自分の端末のアドレスだけを入力すればよいわけではありません。

TUN モードはより低い取り込み層に位置し、システム権限、仮想ネットワークアダプター、または対応するネットワーク拡張を必要とします。有効にしてネットワークが使えなくなった場合は、まず TUN を無効にしてシステムプロキシの基準へ戻します。システムプロキシが正常なら、ノード、サブスクリプション、基本 DNS はおおむね使えるため、問題は TUN 権限、ルーティング、DNS 乗っ取りにある可能性が高くなります。その後 TUN を再度有効にし、自動ルート、インターフェース選択、プライベートアドレスの除外、DNS モードを1項目ずつ確認します。TUN の障害中にプロトコルノードまで変更すると、有効な比較対象を失うので避けてください。

プロトコルの置き換えは単一変数の順序で行う

VMess から VLESS、または Trojan から Hysteria2 に切り替える場合は、対象サービス、クライアント、ルール、DNS、取り込み方式をできるだけ同じに保ちます。まず新しいノードを手動選択グループで単独接続し、その後に自動テストやフォールバックグループへ追加します。ウェブ閲覧、継続ダウンロード、UDP アプリ、ネットワーク切り替え後の復旧という4種類の動作をテストし、エラーを記録してください。新しいプロトコルが特定の用途だけで優れているなら、全体のデフォルトを一度に置き換えるのではなく、専用ポリシーグループを作ります。

複雑なプロトコルのチューニングは層ごとに行います。1回目はサブスクリプションのデフォルトパラメータ、2回目は伝送関連の項目だけ、3回目で多重化、帯域幅、輻輳制御を検討し、最後に TUN と DNS を扱います。各段階で前の状態へ戻せるようにしてください。調整後に性能が低下したら、設定を追加し続けるのではなく、直前の変更を取り消します。復元可能性は本番設定の重要な性質であり、カーネルの更新、クライアントの切り替え、ネットワーク変更時の明確な退路になります。

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

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

この断片は、切り分けに使う基本構造を示しています。ルールモード、混合ポート、LAN 許可、通常のログレベル、3つのルールを含みます。実際の設定では、PROXY という名前のポリシーグループまたはプロキシも定義する必要があります。ルールは順番に一致するため、明確なドメインは、より一般的な GEOIP と MATCH より前に置いてください。ログに対象が DIRECT に一致したと出ているなら、プロキシプロトコルのハンドシェイクを調べ続けるのではなく、まずルールの対象を修正します。

最終的な選定記録を作る

テスト完了後、各デフォルトノードについて、プロトコル、伝送、TLS ホスト名、適用ネットワーク、UDP 対応の有無、対応する provider、フォールバックノードを記録します。パスワードなどの機密情報を保存する必要はなく、切り分けに必要な構造情報だけを残します。モバイル端末では TUN の有効状態、ヘルスチェック間隔、バックグラウンド制限も記録します。ルーターではカーネルアーキテクチャ、サービスの起動方法、ルールセットのソースを記録してください。次回クライアントやカーネルを更新した後も同じ記録で再テストすれば、感覚だけで選び直すより信頼性が高くなります。

最終設定ですべてのプロトコルを網羅する必要は通常ありません。安定した TCP ノードを1～2個、検証済みの QUIC ノードを1個残し、明確なポリシーグループで整理すれば、多くのデスクトップ・モバイル環境に対応できます。ノード数が多すぎると、ヘルスチェック、名前管理、障害の切り分けコストが増えます。このプロトコルガイドの目的は、すべての技術を同時に有効にすることではなく、それぞれの方式が解決する問題、必要な条件、失敗時のフォールバックを理解することです。