SS、VMess、Trojan、VLESS、Hysteria2、TUIC：接続方式、サブスクリプションの互換性と実際の利用条件。
プロトコル名だけでは、接続の全体像はわかりません。クライアントが設定を読み込めるか、サーバーの構成、接続するネットワークでUDPが使えるか、スマートフォンが頻繁にネットワークを切り替えるかによって、実際の動作は変わります。このページでは、こうした条件を踏まえた選び方と、設定前の比較や導入後の確認に役立つ情報をまとめます。
初めて使う場合は、まずクイックスタートガイドを読み、インストール、サブスクリプションの追加、接続確認を済ませてから、このページでプロトコルの詳細を確認してください。クライアントはダウンロードページからClash Plusを選べます。FlClashなどの機能は、実際に搭載されているカーネルや設定画面でご確認ください。
プロキシ接続は2つの区間に分けて考えられます。アプリがリクエストをローカルのクライアントに渡し、クライアントが選択したリモートノードを経由して転送します。システムプロキシやTUN仮想インターフェースは前者、SSやVMess、Trojanなどのノードプロトコルは後者にあたります。そのため、TUNを有効にしてもSSが別のプロトコルに変わるわけではなく、ルールモードを切り替えてもノードの暗号化方式は変わりません。それぞれの区間が正常に動作して初めて、アプリのリクエストが想定した経路で宛先に届きます。
システムプロキシは通常、OSの設定を通じて、ローカルのHTTPまたはSOCKS接続先を使うようアプリに通知します。ただし、その設定に従うかどうかはアプリ次第です。TUNは仮想ネットワークインターフェースでIPパケットを受け取り、クライアントが処理します。ゲーム、コマンドラインツール、ブラウザーでは、通信を取り込む方法が異なることがあります。ブラウザーだけ使えてほかのアプリが使えない場合は、リモートのプロトコルを疑う前に、ローカルでどの範囲の通信を取り込んでいるか確認しましょう。
プロトコル層は認証やカプセル化、転送の動作を担い、トランスポート層はそれらのデータをサーバーまで運びます。VMessやVLESSなどは、TCPの直接接続やWebSocketの併用など、複数のトランスポート方式を組み合わせられます。TLSは接続先の認証と通信の暗号化を担います。ノード名に含まれる略称は異なる階層を指すことが多いため、名前の一部だけを見て2つの設定が同じだとは判断できません。
WebSocketとTLSを使うノードを例にすると、接続にはドメイン名の解決、TCP接続、TLSハンドシェイク、WebSocketへのアップグレード、プロキシ認証などが関わります。サーバーにリバースプロキシも設定されている場合は、パスやリクエストヘッダーも一致させる必要があります。パスが1つ欠けただけでも接続に失敗することがありますが、それだけでプロトコル自体に互換性がないとは限りません。トラブル対処では接続の階層に沿って、まずドメイン名とポートを確認し、次にセキュリティ層、トランスポート層、認証情報を調べます。
| 階層 | 主な設定項目 | 主な役割 |
|---|---|---|
| ローカルでの通信取り込み | システムプロキシ、TUN | どのアプリの通信をクライアントに渡すか |
| 通信の振り分け | ルール、グローバル、直接接続 | リクエストに適用するポリシーや出口 |
| プロキシプロトコル | SS、Trojan、TUICなど | 認証とプロキシデータのカプセル化 |
| トランスポート | TCP、WebSocket、QUIC | ハンドシェイク、輻輳制御、ネットワークへの適応 |
ルールモードでは、設定されたルールを上から順に照合し、一致した場合に直接接続、拒否、特定のノード、またはグループを選びます。グローバルモードでは全リクエストをグローバルポリシーに渡しますが、実際に使える出口を選ぶ必要があります。直接接続モードは主にローカルネットワークとの比較に使います。あるサイトがグローバルモードでは開けるのにルールモードでは開けない場合、すぐにプロトコルを変えるのではなく、一致したルールとポリシーグループを確認してください。
DNSはルールの判定や接続の確立にも関わります。ドメイン名で照合するルールもあれば、宛先IPアドレスや地域データベースを必要とするルールもあります。クライアントがドメイン名を保持するか、Fake-IPを使うか、DNSリクエストがどの出口を通るかによって、判定結果が変わることがあります。DNS設定はプロトコルの機能と関連しますが、プロトコルの優劣とは別の問題です。DNS、ノード、モードを同時に変更すると、原因を再現しにくくなります。
まずクライアントで対象の設定が選択されていることを確認し、プロキシ画面でノードの種類とポリシーグループの選択を確認します。次に接続画面やログで、宛先、一致したルール、出力先の名前を確認してください。リクエストが実際にクライアントへ渡り、想定したノードが選択されて初めて、プロトコル間のテストが意味を持ちます。ルールの優先順位については、カスタムルールの書き方と照合順序もご覧ください。
Shadowsocksは一般にSSと呼ばれ、暗号化SOCKSプロキシとして発展してきた、比較的シンプルな接続方式です。クライアントはパスワードや鍵と暗号化方式を使ってデータを処理し、サーバーがカプセル化を解除して宛先にアクセスします。SS自体は包括的な設定管理システムではなく、ルールによる振り分けも行いません。サブスクリプション、ポリシーグループ、画面設定はプロトコルの上にクライアントが提供する機能です。そのため、SSに対応したアプリでも、完全なClash設定を直接読み込めるとは限りません。
現在のSS環境ではAEAD暗号化方式がよく使われますが、古いストリーム暗号方式とは安全性が異なります。SS 2022では鍵やセッションの処理にも異なる要件があるため、名前だけ違う選択肢として扱うことはできません。サーバーで指定された方式をクライアントがサポートし、正しく使う必要があります。速度向上を狙ってcipherを書き換えると、双方で正しく復号できなくなる可能性があります。
暗号化方式の処理負荷は、デバイスのハードウェアによって異なります。ハードウェアアクセラレーションに対応したデスクトップCPUと省電力スマートフォンでは、適したアルゴリズムが違う場合があります。AES系の処理効率は命令セットの対応状況や実装に左右され、別のデバイスではChaCha20系が適していることもあります。決まったサブスクリプションを使う場合、ユーザーが暗号化方式を個別に選べないことがほとんどです。まずサーバーの設定とクライアントカーネルの対応状況を確認してください。
SSはUDPを転送できますが、サーバー側で該当する転送が有効であること、ローカルアプリのUDP通信がクライアントに渡ること、経路上のネットワークで該当する通信が許可されることが必要です。ノードのUDPオプションを有効にしても、クライアントがその機能を試すだけで、経路全体の疎通が保証されるわけではありません。ウェブ閲覧はTCPで問題ないのにリアルタイム音声が使えない場合は、アプリの通信が取り込まれているか、ノードがUDPに対応しているか、出口で宛先ポートが制限されていないかを確認してください。
SSノードの中には追加プラグインが必要なものもあります。プラグインによってトランスポート方式やハンドシェイクが変わるため、クライアント、カーネル、プラグインの実装がすべて対応している必要があります。読み込み後に未知のプラグイン名やパラメーターが表示されても、項目を削除して接続を試すのは避けてください。削除するとサーバーが想定する接続方式が変わるおそれがあります。サブスクリプションの提供元に対象クライアントの形式を確認するか、その構成に明確に対応したクライアントを選びましょう。
VMessはV2Rayエコシステムから発展し、ユーザーIDと独自の認証方式でプロキシリクエストを処理します。現在の構成ではAEAD認証が一般的ですが、古い設定には以前の認証に関する項目が残っている場合があります。ユーザーIDと暗号化オプションはサーバー側の設定に合わせる必要があります。別のノードのIDに置き換えたり、項目が存在するだけでサーバーが旧式の認証を使っていると判断したりしないでください。
VMessは時刻の影響を受けやすく、端末の時計がずれていると認証に失敗することがあります。ドメイン名を解決でき、ポートにも到達できそうなのに認証エラーが続く場合は、まずOSの自動時刻設定を有効にしてから、認証情報とサーバーの状態を確認してください。証明書エラーは別の階層の問題なので、ログを見て切り分けます。時刻が原因の認証エラーは、ノードのポートを繰り返し変更しても解決しません。
VMessはTCPやWebSocketなどのトランスポートに、TLSを組み合わせて利用できます。実際の負荷はプロトコル認証だけでなく、トランスポート、暗号化、中継層の構成にも左右されます。TCPで直接接続するVMessノードと、リバースプロキシを経由するWebSocketノードでは、接続の手順が大きく異なることがあります。比較テストでは、これらの条件も記録し、すべてのVMessノードを同じ性能として扱わないようにしましょう。
一般的なウェブ閲覧や日常的なファイル転送では、どちらも十分に使える場合があります。SSは比較的シンプルな構成で、VMessは認証とトランスポートの組み合わせをより細かく確認する必要があります。読み込み後に一部のノードだけ使えない場合は、暗号化方式、プラグイン、トランスポートのどれかに失敗が集中していないか確認してから、カーネルの更新や提供元への設定変更依頼を検討してください。むやみにノードごとに試すより、共通の原因を見つけやすくなります。
Trojanでは、TLS接続上でプロキシリクエストを転送する構成が一般的です。プロトコル内のパスワードでユーザーを認証します。TLSは通信経路の暗号化とサーバー認証を担い、プロキシプロトコルは宛先と認証情報の転送を担います。複数の暗号化方式をプロトコル内で選ぶのではなく、成熟したTLSの仕組みを利用する設計です。実際に使う際は、パスワードだけで接続できると考えず、証明書、ドメイン名、トランスポートの設定も確認してください。
サーバーアドレスとTLSで使う名前は、必ずしも同じではありません。サーバーアドレスは接続先の入口を指定し、SNIはTLSハンドシェイクで接続先の名前を示します。証明書の検証名は、接続先の本人確認に使われます。クライアントによっては後者2つを1つの項目にまとめたり、設定から自動的に導出したりします。サーバーアドレスにIPアドレスを使う場合も、正しいサービス名の指定が必要なことがあります。3者の関係は、サーバーの構成情報に基づいて確認してください。
証明書エラーが出た場合は、端末の時刻、証明書の有効期間、証明書に含まれるドメイン名、設定上の名前を確認してください。証明書検証を無効にするとサーバーの本人確認が弱まるため、恒久的な対処には適しません。以前は使えていて、サブスクリプションの更新後に失敗した場合は、検証を緩めるのではなく、更新前後のサービス名を比較しましょう。詳しくはプロキシ接続時のHTTPS証明書エラーについてをご覧ください。
VLESSもV2Ray関連のエコシステムから生まれ、その後Xrayなどの実装で発展しました。一般的なVLESS構成では、ユーザー認証と外部のセキュリティ層を分けており、プロトコル自体はシンプルです。従来の設定でよく見られるencryption: noneは、該当するプロトコル設定でデータ暗号化を行わないという意味です。接続全体が平文になるとは限りません。実際の安全性はTLS、REALITY、または明示的にサポートされた組み合わせによって決まります。
REALITYのパラメーター体系は、一般的な証明書を使うTLSとは異なります。クライアントでは通常、公開鍵、短いID、サービス名などを確認する必要があります。公開鍵は検証に使うもので、サーバーの秘密鍵のように秘匿するものではありません。一般ユーザーは信頼できるサブスクリプションから必要な項目をまとめて取得し、異なるノードの設定を自分で組み合わせないでください。名前の似た項目でも、別のプロトコルやカーネルでそのまま使えるとは限りません。
VLESSの設定には、Vision関連の値など、flowが指定されることもあります。flowは自由に設定できる速度向上用のスイッチではなく、サーバー、トランスポート方式、カーネルの実装すべてが対応している必要があります。非対応のトランスポートにflowを追加すると、拒否されたり接続に異常が起きたりすることがあります。設定の読み込みに成功しても、解析上のチェックを一部通過しただけです。実際のハンドシェイクとアクセス結果を確認してください。
| 項目 | 役割 | よくある誤解 |
|---|---|---|
| サーバーアドレス | 接続先の入口を指定 | 入口のIPアドレスを証明書のドメイン名として扱う |
| SNI／サービス名 | ハンドシェイクと名前の検証に使用 | 関係のないサイト名に変更する |
| ALPN | 上位プロトコルをネゴシエート | 項目を多く設定するほど互換性が高いと考える |
| flow | 特定のプロトコル処理を選択 | カーネルとトランスポートの組み合わせによる制限を見落とす |
WebSocketは既存のWebサービス構成に適応できる場合がありますが、アップグレードリクエスト、パス、リクエストヘッダーなどの設定が加わります。gRPC系のトランスポートには、異なるサービス名や接続動作があります。これらはデプロイや通信経路の要件に対応するもので、速度向上の手段とは限りません。サーバー側で1つの構成しか提供されていない場合、クライアントもそれに合わせる必要があります。プロトコルを選ぶ際は、接続先の実際の機能を考慮しましょう。
TrojanもVLESSも日常利用に適した接続を実現できますが、常に成り立つ性能の序列はありません。既存の証明書環境を維持する構成ではTrojanのパラメーターを把握しやすく、特定のVLESS構成が必要な場合は、カーネルの対応状況とサブスクリプションの項目がそろっているかを優先して確認します。クライアントでノードを選ぶときは、まずセキュリティ設定が有効か確認し、そのうえで回線、安定性、リソース消費を比較しましょう。プロトコル名だけにこだわるより確実です。
QUICはUDPをベースとし、セキュアなハンドシェイク、信頼性のあるストリーム、多重化、輻輳制御などの仕組みをトランスポート層に統合しています。セキュアな接続の確立にはTLS 1.3が使われます。Hysteria2とTUICはどちらもQUICを活用しますが、異なるプロキシプロトコルであり、認証情報やパラメーターに互換性はありません。ノードにQUICベースと書かれていても、接続の基盤が近いというだけで、設定の種類を別のプロトコルに変更できるわけではありません。
多重化では、1つの接続を複数の論理ストリームで共有します。複数のストリームが1本のTCP接続を共有する場合と比べ、QUICでは、あるストリームのデータ不足がトランスポート層でほかの独立したストリームの配送を妨げる、ヘッドオブラインブロッキングの影響を抑えられます。ただし、各ストリームは帯域と輻輳の制約を共有するため、大きなパケットロスが起きれば全体に影響します。多重化されていても、すべてのリクエストが専用の空いた回線を使えるわけではありません。
UDPを使うには、接続元のネットワークでノードのポートまでUDPが届く必要があります。公衆無線LANや企業ネットワーク、モバイル回線の一部ではUDPが制限されていたり、UDPのマッピング保持時間が短かったりします。その場合、TCPノードではウェブを閲覧できるのにQUICノードではハンドシェイクがタイムアウトすることがあり、これは切り分けの手がかりになります。同じサブスクリプションを何度も読み込むより、まずUDPの到達性を確認し、その後でプロトコルのパラメーターを調整しましょう。
Hysteria2は、高遅延やパケットロスを含むネットワーク環境を想定したQUICベースのプロキシ通信をサポートします。構成によっては、帯域の目安、輻輳制御方式、追加の難読化パラメーターが関わります。帯域の値は契約プランの速度やサーバーのネットワークカードの公称速度ではなく、現在の回線で実際に利用できる上下の帯域を踏まえて設定します。過大な値を指定すると、キューやパケットロスが増え、共有ネットワーク上でほかの通信と競合するおそれがあります。
帯域をクライアントとサーバーがどのようにネゴシエートするか、クライアント側で値を指定できるか、省略時にどう動くかは、実装やサーバーの方針によって異なります。一般ユーザーは、まず提供元が設定した値を維持してください。自分で調整する場合は、上りと下りを一度に変更せず、1項目ずつ試し、継続通信時の遅延やほかのアプリの応答も記録します。ダウンロードの瞬間的な最高速度だけを見ていると、ネットワーク全体で輻輳が起きていることを見落とす可能性があります。
Hysteriaの初代とHysteria2は、プロトコル名を書き換えるだけでは互換性がありません。プロトコルや設定が異なるため、変換ツールが変換先の形式に正しく対応していないと、認証情報などの重要なパラメーターが失われることがあります。対応していないノード種別が表示されたら、無理に古い種別を使って読み込みチェックを回避せず、該当プロトコルに明確に対応したカーネルに更新するか、目的の形式を取得してください。
TUICはQUICを使ってプロキシ通信を行い、TCP転送とUDP転送を扱います。実装によって、輻輳制御、UDP転送方式、接続の維持などの設定項目があります。プロキシ内のTCP通信が、トランスポート層でもTCPになるとは限りません。クライアントは信頼性のあるストリームとしてQUIC接続内で転送することがあります。UDP通信については、選択した転送方式を踏まえて信頼性やパケットロスの挙動を確認してください。
TUICではプロトコルの世代と認証項目も一致させる必要があります。設定にユーザーIDとパスワードが含まれていても、似た項目を使う別のノードへそのまま移行できるとは限りません。カーネルが対応するプロトコル世代、データグラム方式、項目名などが互換性に影響します。読み込み後に認証エラーが出た場合は、ユーザー名があるかどうかだけで判断せず、ノード提供元に対象カーネルを確認してください。
QUICにはコネクション移行に関する仕組みがありますが、クライアントやプロトコルの実装、ネットワークの切り替え方によって、それが実際に利用されるかは異なります。Wi-Fiとモバイルデータを切り替えた後にアプリが再接続することもあり、バックグラウンドでのスリープによって接続が切れる場合もあります。Hysteria2やTUICは、テストして使う選択肢として有効ですが、パケットロス、回線切り替え、電波の弱さを一度に解決するものではありません。選ぶ際は、長時間使用したときの電池消費や発熱も比較しましょう。
クライアントに表示される遅延は、特定の方法で行った1回の測定値であり、プロキシ接続を確立してテスト用の宛先にリクエストする処理を含む場合があります。プロトコル固有の遅延ではなく、サーバーへのICMP往復時間とも限りません。クライアントや測定先が異なる結果をそのまま比較することもできません。ノードの応答が速くても、特定のサイトへのアクセスでは、宛先までの距離、出口の混雑、DNSの影響を受けることがあります。
短時間の接続では、名前解決とハンドシェイクのコストが表れやすくなります。初めてウェブページを開くときに複数の接続を確立する場合、TLS、WebSocketへのアップグレード、認証などにかかる時間も影響します。一方、確立済みの長時間接続では既存の経路を再利用し、接続確立の一部を省けることがあります。新しいプロトコルをテストするときは、初回アクセスと連続アクセスを分けてください。キャッシュや接続の再利用によって、後から試したノードが有利に見えることがあります。
継続的なスループットは、出口の帯域、輻輳制御、パケットロス、暗号化の効率、サーバー負荷など別の条件に左右されます。小さなファイルがすぐにダウンロードできても、長時間の転送が安定するとは限りません。逆に、大きなファイルの速度が高くても、対話的な通信の遅延が小さいとは限りません。アップロードで回線を使い切ると、キューの影響でウェブ閲覧や音声も遅くなることがあります。速度の数値だけではなく、実際の使い方に合わせて選びましょう。
暗号化と復号、データのコピー、接続数、ルール照合、DNSキャッシュ、ログ出力などは、すべてリソースを消費します。QUICはユーザー空間で多くのトランスポート処理を実装することが多く、TCPの一部の処理はOSのネットワークスタックが担います。ただし、最終的な負荷は実装の品質、OSの最適化、通信量によって変わります。ユーザー空間かカーネル空間かだけで、あらゆるデバイスに共通するCPU性能の順位を決めることはできません。
モバイル端末では、無線通信モジュールが動作し続ける時間も電池消費に大きく影響します。定期的なハートビート、頻繁な疎通確認、多数の短時間接続、接続失敗後の再試行は、端末を起動する回数を増やすことがあります。電波が弱いと再送や無線通信の消費電力によって差がさらに広がります。そのため、同じ設定でも自宅のWi-Fiと通勤中のモバイル回線では、電池の減り方が大きく異なる場合があります。デスクトップでの測定結果からスマートフォンの使用感を推測しないでください。
TUNを有効にすると通信の取り込み範囲が広がり、より多くのバックグラウンド通信がクライアントを経由することがあります。電池の消費が増えた場合、TUN自体の処理コストだけでなく、以前は取り込まれていなかったアプリがプロキシ通信を始めた可能性もあります。比較時は、バックグラウンドアプリ、通信の取り込みモード、DNS設定を統一してください。そうしないと、ノードのプロトコルを変えていなくても、テストする通信の内容が変わってしまいます。
| タスク | 確認する項目 | そろえる条件 |
|---|---|---|
| ウェブページを初めて開く | ハンドシェイク、最初の応答、失敗率 | 宛先、キャッシュの状態、DNS |
| ファイルの継続転送 | 安定したスループット、操作への応答 | ファイルの配信元、時間帯、並行する処理 |
| 音声通話やオンライン会議 | 切断、ジッター、UDPの利用可否 | アプリ、通信の取り込み方式、接続ネットワーク |
| スマートフォンのバックグラウンド待機 | 電池消費、起動回数、再接続の記録 | 電波状況、画面、バックグラウンドアプリ |
まずネットワークとクライアント設定を固定し、大容量ファイルの同期を一時停止してから、各ノードで同じ操作を行います。Aをすべて測定してから時間を空けてBを測るのではなく、交互に試すと時間帯による負荷の差を抑えられます。各回で新規接続と継続接続の両方を確認し、エラーの種類も記録してください。2つのノードで出口が異なる場合、結果から言えるのはその2つの経路の違いだけであり、プロトコル全般の差には当てはまりません。
電池のテストでは、日常的な使用時間に近い長さで測定し、OSのバッテリー使用状況でバックグラウンドの動作も確認します。デバッグログは短時間の原因調査に使い、正常に動作することを確認したら通常のログレベルに戻してください。頻度の高いヘルスチェックも必要に応じて調整します。省電力のために接続維持の間隔をむやみに長くすると、ネットワークによってはマッピングが早く破棄され、かえって再接続が増えることがあります。
最終的には、失敗率が低く、日常的なタスクへの応答が安定し、端末の温度も許容範囲に収まる組み合わせを選びましょう。あるプロトコルの最高速度が高くても、発熱やネットワーク切り替え時の接続失敗が続くなら、スマートフォンには適さない場合があります。設定を変える前に元の状態を保存し、一度に1項目だけ変更してください。ノードが繰り返しタイムアウトする場合は、ノードのタイムアウト・接続不可を解決する手順もご覧ください。
GUIクライアントは設定画面、OSとの連携、サブスクリプション管理、トレイ、画面操作を担います。カーネルは設定の解析、プロキシ接続、DNS、ルールの処理を担います。FlClashはmihomoカーネルをベースにクライアント機能を提供しますが、カーネルの機能が画面上のスイッチとして利用できるかどうかは、クライアントの実装にも左右されます。ダウンロードページに掲載されたクライアントは、見た目や名前だけで機能が同じだと判断しないでください。
同じクライアントでも、アップデートによってカーネルや設定処理の方法が変わることがあります。互換性を調べる際は、まず「バージョン情報」「設定」「ログ」などで実際のカーネル名とビルド情報を確認し、目的の機能に対応しているかを調べます。「Clashクライアントを使っている」というだけでは、VLESS、Hysteria2、特定のDNS項目が使えるか判断できません。クライアント、カーネル、設定の入手元をそれぞれ確認してください。
オリジナルのClashは、一般的なYAML設定構造とルールによる振り分け方式を確立しました。Clash.Metaはそのエコシステムから派生した拡張ブランチで、その後mihomoというカーネル名で開発が続いています。古いドキュメントやサブスクリプションの選択肢、クライアントの説明には、現在もMetaという名前が使われることがあります。歴史的なブランチを指す場合もあれば、互換性のある対象を示すラベルの場合もあります。ラベルだけで具体的な機能を判断することはできません。
mihomoでは、プロトコル、DNS、ルール、ネットワークの取り込み機能などが追加・拡張されています。基本的な設定構造は多くの場合Clash形式に近いものの、拡張項目がオリジナル版や別のブランチで読み込めるとは限りません。オリジナルプロジェクトはすでにメンテナンスが終了しており、古いクライアントのパーサーが、サブスクリプションにClash対応と書かれているだけで後から追加されたノード種別を理解することもありません。新しい機能を使うには、対応するカーネルが必要です。
| 対象 | 主な位置づけ | 利用上の制限 |
|---|---|---|
| Clashオリジナル版 | 基本的な設定とルールのエコシステム | 後から追加されたプロトコルは対応するとは限らない |
| Clash.Meta | 拡張ブランチの旧称 | 個々の実装とビルドを確認する必要がある |
| mihomo | 継続して開発されているプロキシカーネル | 設定項目はビルド、プラットフォーム、実装によって制限される |
| GUIクライアント | OSとの連携と設定管理 | 画面上の機能がカーネルの全機能を網羅するとは限らない |
互換性は少なくとも4つの段階で考える必要があります。ファイルの構文を解析できるか、ノード種別を認識できるか、拡張オプションが機能するか、OS上で必要なネットワーク操作が許可されているかです。構文チェックに通ってもサーバー側の設定が違えば接続に失敗することがあります。ノードが正常でもTUNの権限が不足している場合もあります。すべてを「設定の互換性がない」とまとめると、本当に調整が必要な部分が見えなくなります。
サブスクリプションを読み込む際、クライアントがローカル設定を統合したり、DNSを上書きしたり、ルールを追加したりすることがあります。そのため、ディスク上の元のサブスクリプションとカーネルが実際に使う最終設定は異なる場合があります。トラブル対処では、ダウンロードしたYAMLだけでなく、クライアントが提供する実行時の設定やログを優先して確認してください。統合時に競合する場合は、最小限のローカル設定を残して比較し、複数の上書きが互いに影響しないようにします。
OSごとの違いにも注意が必要です。デスクトップOSのプロキシ切り替え、仮想ネットワークインターフェース、権限の仕組みは、モバイル端末のネットワーク拡張やVPNサービスのインターフェースとは異なります。設定を複数のOSに読み込めても、OS側の設定をそのまま流用できるとは限りません。iOSではダウンロードページからClash Plusを確認できますが、クライアントが実際にサポートする読み込み形式とネットワーク機能に従ってください。デスクトップ版mihomoの設定項目すべてがモバイル端末に必要なわけではありません。
未知のノード種別、未対応の設定項目、既知の不具合がある場合は、クライアントやカーネルのアップデートが有効です。更新前に設定、上書き内容、必要な項目を保存してください。更新後は、まず動作が確認できているノードをテストし、それから複雑なルールを戻します。クライアントにカーネルの切り替え機能がある場合は、公式にサポートされた方法に従い、別のプラットフォーム用バイナリに置き換えないでください。
新規インストールでは、まずClash Plusを選び、利用するプロトコルへの対応状況を確認してください。FlClashやClash Verge Revなどが必要な場合は、プラットフォームと機能に応じて選びます。Clash for WindowsとClashX Metaは開発が終了したアーカイブ版です。古い環境を理解する目的には適していますが、拡張され続けるプロトコルへの対応を標準で期待するのは避けましょう。選ぶ際に重要なのは、名称がいつから使われているかではなく、現在必要なプロトコルとOS連携に対応しているかです。
サブスクリプションは、クライアントが設定を取得するための入口です。サーバーはパスのパラメーター、リクエストヘッダー、クライアント識別情報に応じて、異なる形式を返すことがあります。そのため、ブラウザーでダウンロードした内容とクライアントが取得した内容が異なる場合もあります。一般的な形式には、単一ノードの共有リンク、エンコードされたノード一覧、Clash形式のYAML、ほかのカーネル向けJSON設定などがあります。ファイルの拡張子を変えるだけで相互に変換することはできません。
単一の共有リンクには通常、アドレス、ポート、認証情報、一部のトランスポート設定など、1つのノードの情報が含まれます。ノード一覧には複数の接続先をまとめられますが、ルールによる振り分け設定が含まれないことがあります。完全なClash設定には、proxies、proxy-groups、rules、dnsなどのセクションが含まれる場合があります。クライアントに複数の読み込み方法がある場合は、内容の種類に合ったものを選んでください。ノードの共有リンクを完全な設定専用のリモート設定欄に貼り付けると、解析エラーが発生することがあります。
proxy-providersを使ってリモートのノード一覧を参照し、ノードの更新とルールの管理を分ける設定もあります。この場合、メイン設定は短くできますが、参照先にアクセスできることと、形式が適合していることが必要です。メイン設定の読み込みに成功してもポリシーグループにノードが表示されない場合は、providerの更新状況、参照名、絞り込み条件を確認してください。メインファイルを再ダウンロードするだけでは解決しないことがあります。
サブスクリプション変換ツールは、元の形式の項目を変換先カーネルの項目に対応づけます。アドレスと認証情報は比較的引き継ぎやすい一方、トランスポートのパス、TLS名、ALPN、flow、REALITYのパラメーター、UDP関連のオプションは、形式やツールの対応状況によって失われることがあります。変換後もノード一覧が表示されているからといって、接続の意味まで保たれているとは限りません。対象のプロトコルとカーネルに明確に対応する出力形式を選びましょう。
変換ツールで、非対応カーネルにプロトコルの実装を追加することはできません。また、元の設定にない情報から正しいパラメーターを確実に推定することもできません。必要な項目が元の設定にない場合は、提供元から完全な設定を取得してください。オンライン変換では、サブスクリプションへのアクセス情報を第三者に渡すことになり、認証情報が漏れるおそれもあります。提供元が生成する対象形式を優先するか、リスクを理解したうえで信頼できるローカル変換方法を利用してください。
YAMLはインデントと構造に注意が必要です。リスト、マッピング、文字列の階層をそろえ、特殊文字を含む値は適切に引用符で囲みます。ブラウザーにログイン画面、エラーページ、空のレスポンスが表示されても設定ファイルではないため、インデントの調整では直せません。ファイルの先頭で解析エラーが出た場合は、まずダウンロードした内容の種類と冒頭の数行を確認し、サーバーに拒否されたのかURLが無効なのかを判断してください。
以下はルールの例であり、サブスクリプション全体の設定ではありません。例のドメインへの通信を直接接続し、それ以外のリクエストをPROXYという既存のポリシーグループに渡します。使う前に、現在の設定にそのグループがあることを確認してください。ルールは記載順に照合され、末尾のMATCHがそれまでに一致しなかったリクエストを処理します。その後に通常のルールを追加しても、期待した結果にならないことがあります。
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXYGeoIPとGeoSiteは、対応するルールデータにも依存します。設定の構文が正しくても、データファイルがない、または更新に失敗している場合、ルールが想定どおりに動作しないことがあります。ノードのサブスクリプション更新とルールデータベースの更新は別の処理です。データファイルの用途や更新方法は、GeoIP・GeoSiteデータベースの使い方をご覧ください。
自動更新によって、リモート設定に直接加えた変更が上書きされることもあります。長期的に維持するルールには、クライアントが明示的に提供するローカル上書き機能やマージ機能を使い、追加される順序を確認してください。ファイルの直接編集は、更新動作を管理できる場合に限って行います。更新後に問題が再発する場合は、更新日時だけでなく、元のサブスクリプション、上書き後の設定、最終的に実行される設定を比較してください。
操作手順はサブスクリプションの追加ガイド、取得先と安全上の注意はサブスクリプションの入手先についてをご確認ください。自動更新だけ失敗し、手動追加は正常な場合は、サブスクリプション更新の失敗と間隔設定も参考に、応答内容、アクセス経路、形式の互換性を順に確認してください。
自宅や職場の固定回線で、ウェブ閲覧、文書作成、コード管理などが中心なら、まず安定して動作している、証明書と設定がそろったノードを選びます。SS、VMess、Trojan、VLESSはいずれも使える可能性がありますが、使用感にはプロトコル名より出口の品質が大きく影響することがあります。ネットワークでUDPが明確に制限されている場合は、まずTCP系の候補を残してください。QUICを試すためにDNS、ルール、OSの通信取り込み方式まで同時に変更する必要はありません。
長距離通信やパケットロスが発生する環境では、Hysteria2やTUICも比較対象にできますが、まずUDPが到達するか確認してください。継続的にダウンロードする場合は、アップロード、ウェブ閲覧、会議に同時に影響が出ていないかも確認し、回線を使い切ったときの結果だけで全体の使用感を判断しないようにします。音声通話やゲームなどのリアルタイム通信では、ウェブの疎通確認だけを見るより、アプリのUDP通信が実際に目的のノードを経由しているかを確認することが重要です。
モバイル端末では、再接続の確実性、発熱、バックグラウンドでの動作、回線切り替え後の復旧を優先して確認します。メインノードと異なるトランスポート方式の予備ノードを1つずつ用意しておくと、接続条件が変わったときの中断を抑えられます。自動選択グループには適切な測定先と間隔を設定してください。測定に成功しても、その測定先への接続が使えることを示すだけで、すべてのアプリで使えるとは限りません。出口を頻繁に切り替えると、確立済みのセッションが再接続になる場合もあります。
| 用途 | まず確認 | 次に比較 |
|---|---|---|
| 日常のウェブ閲覧とオフィス作業 | ルール、DNS、出口の安定性 | 初回アクセスと連続アクセスの動作 |
| リアルタイム音声と会議 | UDPの取り込みと転送能力 | ジッター、中断、回線切り替え後の復旧 |
| ファイルの継続転送 | 利用可能な帯域と回線の混雑 | 長時間のスループットと操作時の遅延 |
| モバイルデータと待機中の動作 | 電波状況、再接続、バックグラウンド通信 | 端末の温度、電池消費、予備経路 |
手順1：設定が読み込まれているか確認します。クライアントの設定画面で対象の設定を選び、解析エラーやマージエラーがないことを確認してから、プロキシ画面で候補ノードとポリシーグループを確認してください。ノードが表示されない場合は、ネットワークをテストする前に、サブスクリプションの内容、絞り込みルール、カーネルの対応状況を調べます。新規インストールでは、ダウンロードページからClash Plusまたは使用中のOSに合ったクライアントを選び、ガイドに沿って基本設定を追加してください。
手順2：リクエストがクライアントに渡っているか確認します。接続を開始し、用途に応じてシステムプロキシまたはTUNを使ってから、宛先にアクセスして接続画面を確認してください。記録がない場合は、アプリがシステムプロキシに従うか、仮想ネットワークインターフェースの権限があるか、ほかのネットワークソフトと取り込みが競合していないかを調べます。記録がある場合は、一致したルール、ポリシーグループ、最終的に選ばれたノードを確認し、直接接続やグループ内の別ノードを誤ってテストしていないか確かめてください。
手順3：ログを見ながらリモート接続の失敗箇所を特定します。名前解決に失敗した場合はDNS、ハンドシェイクがタイムアウトする場合は接続先アドレス、ポート、トランスポートの到達性を確認します。証明書エラーでは時刻と名前、認証エラーでは認証情報を調べ、特定プロトコルのノードがすべて失敗する場合はカーネルの対応状況とネットワーク条件を確認します。ログの表現は実装によって異なるため、エラーの文言だけで原因を決めず、発生した段階やほかのノードとの比較も踏まえて判断してください。
手順4：正常に動作することを確認してから、日常的な通信を試します。同じアプリを使ってウェブ閲覧、ファイル転送、会議などを行い、長時間使用や回線切り替え時の動作も評価してください。新しい設定が安定するまでは元の設定を残し、戻すときはノード名だけでなく設定全体を復元します。複数の項目を変更した場合は、いくつかに分けて元に戻し、その都度確認してください。そうすることで、偶然に復旧しただけなのに特定項目の効果だと思い込むのを防げます。
記録に機密情報を含める必要はありません。接続ネットワーク、クライアントとカーネル、プロトコルとトランスポートの組み合わせ、通信の取り込み方式、テスト内容、エラーが発生した段階を記録してください。相談するときは、関連するログから個人情報や認証情報を隠して共有し、サブスクリプション全体はアップロードしないでください。同じ問題の判断やクライアント更新後の再テストに役立ち、ノードを手当たり次第に変更するところからやり直さずに済みます。
プロトコルは接続方式を定め、カーネルは実装できる機能を決め、サブスクリプションは必要な設定値を提供し、クライアントはそれらをOSに接続します。この順序で確認すれば、形式エラー、回線の問題、端末の制約を分けて対処できます。設定を選んだらクイックスタートガイドで接続と確認の手順を見直してください。掲載されていない画面やインストールの問題はよくある質問とトラブル対処を参照し、すべての問題をプロトコルのせいにしないようにしましょう。