Clashプロキシプロトコルとコア技術ガイド

1. プロトコル選びで確認するポイント

クライアント、コア、ノードの役割

クライアントは操作の窓口で、サブスクリプションの管理、システムプロキシの切り替え、設定の編集、ログの表示を担います。コアは設定の解析、ルールの照合、実際の接続を担当し、ノードはサーバーが提供する接続先です。画面にプロトコル名が表示されても、利用中の端末で完全に対応しているとは限りません。コアの実装、ビルド時のオプション、プラットフォームのネットワーク権限も確認が必要です。逆に、コアが対応している設定項目が、クライアントのGUI編集画面にまだ表示されていない場合もあります。

選ぶときは、新しそうな名前から考えるのではなく、現在利用できるサブスクリプションを基準にしましょう。サーバーが対応するプロトコル、UDP転送の可否、証明書のドメイン名が必要かを確認し、クライアントに設定をそのまま取り込めるか調べます。通常、ノードのプロトコルはローカルで自由に変更できません。設定のSSをTrojanに書き換えても、サーバーの待ち受け方式は変わらず、接続時に双方がデータを解釈できなくなるだけです。

プロトコル、トランスポート、セキュリティ層を混同しない

プロキシプロトコルは、宛先アドレスや認証情報、データの表し方を定めます。下位のトランスポートはTCPとUDPのどちらで通信するか、WebSocketやgRPCなどでカプセル化するかを決めます。TLSは安全な接続における認証と暗号化を担います。同じVLESSでも、トランスポートやセキュリティの組み合わせによって、実際のハンドシェイク回数、利用できるネットワーク、必要なパラメーターは異なります。比較する際は、一覧に表示された種類だけでなく、組み合わせ全体を記録しましょう。

ノードのプロトコルと、端末で通信を取り込む方法も区別しましょう。システムプロキシ、TUN、混合ポートは、端末からクライアントへ通信を渡す経路です。ルール、グローバル、ダイレクトは、通信の出口を選ぶ方式です。TUNを有効にしてもSSがQUICに変わるわけではなく、グローバルを選んでも、UDP非対応のサーバーがゲーム通信に対応するわけではありません。アプリがネットに接続できないときは、まず通信がコアに届いているか、次に出口が利用できるかを確認しましょう。

比較条件をそろえる

接続速度には少なくとも、サーバーアドレスの解決、プロキシ接続の確立、サーバーから目的のサービスへのアクセスという3段階があります。ノードの遅延テストで分かるのは、その一部にすぎず、テスト先、キャッシュ、接続の再利用にも左右されます。一覧の数値が小さくても、すべてのページ要素が速くなるとは限らず、動画の読み込みが減るとも限りません。サーバーの負荷、出口回線、接続先までの距離は、プロトコルのわずかな違いより大きく影響することがあります。

実際に比較するときは、端末、接続ネットワーク、接続先サイト、おおよその時間帯をそろえ、各条件で数回ずつ試します。初回表示、連続閲覧、ファイル転送、待機後の復帰をそれぞれ記録しましょう。無線の電波状況やサーバーの混雑を、プロトコルの差と誤認しないことが大切です。特にスマホでは、バックグラウンドから復帰した直後の初回通信に無線回線の起動が含まれる場合があります。ダウンロード中の挙動とは別に確認しましょう。

以降の比較では、この考え方に沿って解説します。すべてのプロトコルに一律の順位をつけるのではなく、利用中の端末で管理しやすく、設定がそろい、安定して動く組み合わせを見つけることが目的です。「どのプロトコルが速いか」を覚えるより、どの層で失敗したかを判断できるほうが役立ちます。ネットワークやクライアントを変えても、この考え方は応用できます。

2. SSとVMess：シンプルなデータ転送と構造化された認証

SSの成り立ちと実装上の注意点

Shadowsocksは一般にSSと略され、クライアントとサーバーで共有する鍵を使って通信を中継します。比較的シンプルな暗号化プロキシのデータ転送を重視した設計です。暗号方式がひとつに決まっているわけではなく、設定の暗号方式によって鍵、nonce、データの処理方法が変わります。SSを比較する際は暗号方式も確認しましょう。異なる方式や実装、ハードウェアの消費リソースを一緒に比べることはできません。

一般的なAEAD方式は、暗号化と完全性保護を組み合わせており、現代のSSの基本的な仕組みを理解するのに適しています。新しい方式の系列には、それぞれ固有の鍵形式や実装要件があります。サブスクリプションにSSと表示されていても、すべてのSS方式に対応しているとは限りません。追加後に暗号方式が認識されない場合は、まずコアの対応状況と鍵の形式を確認しましょう。適当な方式名に変更しても解決しません。サーバー側も同じ設定にする必要があります。

プラグインを使わない一般的な構成では、SSの接続手順は比較的シンプルで、外側にTLSのハンドシェイクを重ねる必要がありません。接続準備の一部を省ける場合はありますが、常に速度が優れるとは限りません。プラグインが必要な設定では、クライアントとコアの両方がその形式に対応している必要があります。スマホとデスクトップで利用できるプラグインが異なる場合もあります。サーバー、ポート、パスワードをコピーしても、プラグインの設定を忘れると認証前に接続が切れることがあります。

VMessの設定項目が多い理由

VMessはV2Rayエコシステムで生まれたプロトコルで、プロキシデータに認証などの仕組みを取り入れ、複数のトランスポートと組み合わせられます。一般的な設定項目には、ユーザーID、暗号化オプション、トランスポートに必要なパスやホスト情報などがあります。柔軟な構成ができる一方、トラブル時にパスワード欄だけを確認しても不十分です。現代的な認証方式を使うサーバーでは、古いガイドにある過去の設定を使うと、インポートできても接続が確立しないことがあります。

VMessの認証には時刻が関係します。端末のシステム時刻が大きくずれていると、アドレスとユーザーIDが正しくても認証に失敗することがあります。複数のVMessノードが同時に使えず、ほかのプロトコルは正常な場合は、まず自動時刻合わせを確認し、次にコアのログで認証関連の情報を調べましょう。いきなりクライアント全体を再インストールする必要はありません。古い設定に追加のID項目がある場合は、古い画面写真を参考に自分で追加せず、サービス提供元の最新案内に従ってください。

TCP、UDP、外側のカプセル化の違い

SSもVMessも、プロトコル名だけでUDPが使えるとは判断できません。サーバー側で必要な転送が有効か、クライアントからアプリの通信がコアに渡されているか、経路上のネットワークが通信を許可しているかも確認が必要です。ウェブページが開けても、音声通話、ゲーム、オンライン会議の通信まで通るとは限りません。テストには対象の通信方式に依存するアプリを使い、ログも確認しましょう。ウェブの疎通テストだけでは不十分です。

VMessをWebSocketなどのトランスポートで包むと、それに応じたカプセル化処理と接続準備が増えます。内側のデータを信頼性の高いTCP接続に載せる場合、パケットロスが起きると、先行データの復旧まで後続データが待たされることがあります。接続の再利用で小さな通信の負荷を減らせるかは、サーバーと実装次第です。また複数の通信が同じ接続を共有すると、混雑や障害の影響も共有する可能性があるため、再利用を常に有効にすればよいとは限りません。

ウェブ閲覧、ドキュメントの同期、中規模のファイル転送では、設定が明確なSSをシンプルな基準として試せます。すでに必要なVMessサービスがある場合は、認証と外側のトランスポートの互換性を確認しましょう。どちらを選ぶかは、プロトコル自体の名前よりサービス品質と設定の確実性に左右されます。どちらかがすべての端末で必ず省メモリ、省電力というわけではありません。

3. TrojanとVLESS：TLSとトランスポートの組み合わせ

Trojanは安全な接続の中で認証する

一般的なTrojanの接続では、まずTLSで安全な接続を確立し、その中でプロキシの認証とデータ転送を行います。成熟したセキュアなトランスポートを使って暗号化とサーバー認証を処理し、プロキシプロトコル自体は比較的シンプルです。クライアントの設定では、サーバー、ポート、パスワードに加え、証明書の検証に使う名前も確認してください。接続先をIPアドレスにしていても、証明書はドメイン名に対して発行されていることがあり、両者は同じ項目とは限りません。

SNIはTLSハンドシェイクで、アクセスしたいホスト名をサーバーに伝えるために使います。クライアント側でも、実装と設定に応じて証明書の識別情報を確認します。入力を間違えると、別のサイトが選ばれたり、証明書エラーになったりします。サービス提供元が専用のサーバー名を指定している場合は、そのまま正確に設定してください。接続先にドメイン名が含まれているからといって省略できるとは限りません。証明書の期限切れ、端末時刻のずれ、信頼チェーンの不足も、プロキシ認証前に接続を止める原因になるため、それぞれ確認しましょう。

VLESSは軽量でも、暗号化を単独で提供するわけではない

VLESSもV2Rayエコシステムで生まれたプロトコルで、比較的シンプルな構造を重視し、一般に外側のセキュリティ機構で通信を保護します。ユーザーIDはプロトコル上の認証情報ですが、それだけであらゆる暗号化が有効になるわけではありません。設定の暗号化欄が空欄、または特定の無効値になっていても、TLSなど外側の設定を見ずに接続全体が暗号化されていないと断定できません。逆に、VLESSという名前だけで安全性が保証されるわけでもありません。

VLESSの実際の構成には、TCP、WebSocket、gRPCと、TLSやREALITYなどのセキュリティ設定が関わる場合があります。それぞれ役割が異なり、VLESSに対応していても、すべての組み合わせを使えるとは限りません。REALITYでは公開鍵、short ID、サーバー名などの設定が必要で、flowのオプションにも組み合わせ上の制約があります。画面に設定を保存できても、そのプラットフォームのコアが実行できるとは限りません。実際のログと開発・保守元の機能説明で確認しましょう。

同じプロトコルでも接続負荷が異なる理由

通常のTCP＋TLSでは、接続の準備に基礎となる接続とセキュリティハンドシェイクが必要です。さらにWebSocketを加えると、通常はアップグレード処理も行います。gRPCはHTTP/2などの仕組みに依存し、独自のストリーム管理や実装上の特性があります。接続の再利用、セッション再開、既存接続がまだ有効かどうかによっても、その後のリクエストにかかるコストは変わります。初回だけ遅く、続けてアクセスすると正常な場合は、継続的な帯域不足ではなく、接続準備に時間がかかっている可能性があります。

短い接続を頻繁に作る通信では、ハンドシェイク、名前解決、スケジューリングの割合が高くなりがちです。継続的なダウンロードでは、回線容量や輻輳制御の違いが表れやすくなります。サーバーが複数の構成を提供している場合は、まず設定項目が少なく、クライアントが明確に対応する方式を基準にし、外側のカプセル化による効果を比較しましょう。なじみのあるトランスポート名だからといって、サービス提供元が指定したパス、サービス名、ホスト情報を削除しないでください。サーバー側のルーティングに使われている可能性があります。

証明書エラーが出た場合は、検証を恒久的に無効化するのではなく、名前、時刻、サーバー証明書を修正しましょう。検証を無効にするとサーバーの本人確認が弱まり、設定ミスが一時的に動作しているように見えてしまいます。初心者には複雑な構成を手入力するより、必要な項目がそろったサブスクリプションの利用が確実です。どの項目が保持されるか詳しく知りたい場合は、このページのサブスクリプションの互換性をご覧ください。

4. Hysteria2とTUIC：QUICを使う方式の違い

QUICは接続を運ぶ仕組みを変える

QUICはUDP上で安全な接続、信頼性のあるストリーム、輻輳制御などを実現します。信頼性の確保をアプリに任せるだけの仕組みではなく、UDPを使うからといってTCPより必ず速いわけでもありません。一部のパケットロスでは、別々のデータストリームが互いを待つ状況を減らせますが、同じストリーム内では順序どおりの配信が必要です。すべてのストリームが回線容量を共有する点も変わりません。無線の電波状況、出口の混雑、サーバーの負荷は、QUICに変えても解消しません。

Hysteria2とTUICはどちらもQUIC関連の機能を利用しますが、互換性のある同一プロトコルではありません。認証、転送方式、設定項目、輻輳制御の選択肢が異なるため、サーバーとクライアントの設定を一致させる必要があります。古いHysteriaの設定は、種類名だけを書き換えてHysteria2として使うことはできません。インポート時に未対応の種類が表示されたら、まずプロトコルの世代とコアの対応範囲を確認し、その後に項目の対応付けを調べましょう。

Hysteria2の帯域設定は速度測定の結果ではない

Hysteria2は、高遅延またはパケットロスのある回線向けのトランスポートを提供します。一般的な実装では、設定された帯域の想定値を送信制御に利用でき、輻輳制御の挙動も異なります。サブスクリプションの上り・下りの数値は、通常、設定目標や参考値であり、クライアントが測定した利用可能速度ではありません。サーバー側で動作が制限されることもあるため、画面の帯域値を実際の速度保証と解釈しないでください。

想定帯域を実際の回線能力より大幅に高く設定すると、キューやパケットロスが増え、同時に使う通話やウェブ閲覧に影響することがあります。特に家庭内で回線を共有している場合、単独のダウンロード速度が上がっても、全体の使い勝手が良くなるとは限りません。クライアントに関連設定がある場合は、まずサービス提供元の値を維持しましょう。変更する際は回線速度、上りのボトルネック、ほかの端末の利用状況を踏まえて少しずつ試し、高負荷時にウェブページがすぐ応答するか記録してください。

TUICでも実装と認証を確認する

TUICはQUIC接続上でプロキシ転送を行い、複数の通信を運べるほか、UDP転送の仕組みも備えています。プロトコルの世代や実装によって認証方式と設定項目が異なるため、古い共有リンクを根拠に新しいコアでも取り込めると判断することはできません。クライアントにTUICと表示されていても、サーバーが求める認証情報、サーバー名、輻輳制御のオプションを確認しましょう。アドレスだけ入力して初期値に任せるのは避けてください。

輻輳制御は、受け取った情報に応じて送信量を調整する仕組みで、積極的なほど優れているわけではありません。アルゴリズムごとにパケットロス、キュー、公平性への考え方が異なり、実装もメンテナンスに伴って変わります。条件をそろえたテストなしに、特定の方式で常に一定割合の速度向上が得られるとは言えません。サーバーとクライアントの双方が明確に対応するオプションを選び、継続的な通信だけでなく、同じネットワーク上のほかのアプリが影響を受けていないかも確認しましょう。

利用にはUDPで接続できることが前提

一部のゲストWi-Fi、企業ネットワーク、モバイル回線ではUDPが制限されていたり、長時間の通信に異なる制限が設けられていたりします。そのためTCPベースのノードは使えても、QUIC系ノードがタイムアウトすることがあります。それだけで認証情報の誤りとは判断できません。同じ端末で別のネットワークに切り替えて再テストし、ログが名前解決、ハンドシェイク、認証のどの段階で止まるかを確認しましょう。サーバーと設定を変えていないなら、ネットワークを切り替えた後の違いが重要な手がかりになります。

QUICは接続の移行に対応する場合がありますが、スマホがWi-Fiからモバイル回線へ切り替えた後にスムーズに復帰できるかは、クライアント、OS、ネットワークのアドレス変換、サーバーの実装に左右されます。通信が途切れない保証はありません。ゲームで使う場合は、ゲーム通信が取り込まれているか、ノードが該当するUDP転送を許可しているかも確認しましょう。ゲームデータを運べることと、ゲームの往復遅延が必ず下がることは別です。

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

性能を4つの観点に分ける

初回表示の速さは、名前解決、ハンドシェイク、接続先の応答に左右されます。継続的な転送速度は、回線容量、パケットロス、サーバーの出口回線に大きく依存します。操作への反応はリクエストがすぐ完了するか、復帰性能は画面消灯、ネットワーク切り替え、待機の後にどれだけ早く再利用できるかを見る指標です。これらは同じ結果になるとは限りません。連続ダウンロードが速いノードが、頻繁に発生する短いリクエストにも向いているとは限りません。初回表示が遅くても、その後の長時間通信には影響しない場合があります。

プロトコルが影響するのは、これらの一部に限られます。現代の端末には暗号処理を高速化する機能が搭載されていることがあり、暗号方式とプロセッサの実装によってCPU負荷は変わります。カプセル化の層数、パケットの頻度、接続の再利用方法も処理負荷に影響します。デスクトップPCでの使用量を省電力スマホに当てはめたり、別々のサーバーで行った2回のダウンロードからプロトコルのリソース順位を導いたりすることはできません。メモリ使用量には接続数、ルール、キャッシュも関係します。

スマホの電池消費は、暗号化方式ひとつでは決まらない

スマホでモバイル回線を使うと、無線回線を低電力状態から復帰させたり、アクティブ状態に保ったりするために電力を消費します。頻繁なハートビート、小さなデータの送受信、接続失敗後の再試行、バックグラウンドアプリの通信が続くと、通信モジュールが長時間動作します。あるプロトコルの1回あたりの処理が軽くても、端末全体の電池消費が必ず減るとは限りません。接続が何度も切れて再接続する設定では、ハンドシェイクと無線の再起動にかかる合計コストがかえって増える場合があります。利用時間全体で確認しましょう。

TUNはより広い範囲の通信を取り込むため、これまでプロキシを通っていなかったバックグラウンド通信も処理されることがあります。そのため、有効化の前後で電池消費が変わっても、出口プロトコルの負荷が増えたとは限りません。ルールの量、ログレベル、接続のスニッフィング、DNSリクエスト、自動テストも追加の処理を発生させます。電池消費を調べるときは通信の取り込み方式を固定し、不要な高頻度テストや詳細ログを長時間有効にする設定を止めてから、ノードのプロトコルを比較してください。そうしないと複数の要因が混ざります。

キープアライブ、接続の再利用、アイドルタイムアウトをまとめて確認

キープアライブの頻度を上げると、中間ネットワークのアドレス変換状態を維持し、待機後の再接続を減らせる場合があります。一方で、バックグラウンドでの復帰が増えることもあります。間隔が長すぎると、次のリクエストまでに接続状態が失効し、接続を確立し直す必要が生じます。適切な値はネットワーク機器、通信環境、サーバー側のタイムアウトによって異なり、すべてのスマホに共通する固定値はありません。サービス提供元の設定がある場合は、まず現象を記録し、関連項目を一度にひとつだけ変更しましょう。

接続の再利用で接続準備を一部省けますが、複数の通信が同じ接続の輻輳、障害、アイドル処理の影響を受ける場合があります。連続通信で減らせるハンドシェイクが、あらゆる場面で共有による影響を補えるとは限りません。特に操作性が重要な通信と大容量ダウンロードを同時に行う場合は、ウェブページの応答が目立って遅くならないか確認しましょう。サーバー側の機能に詳しくない場合、複数の接続再利用機能をむやみに重ねるのは避けてください。まずサブスクリプションの初期設定で安定した基準を作ってから比較しましょう。

電池消費を比べる際は、使用時間と画面の明るさをできるだけそろえましょう。OSのバッテリー統計を確認するときは、ネットワークサービスの消費電力がどう計上されるかにも注意が必要です。端末の発熱、OSの更新、バックグラウンド同期も結果に影響します。異常があれば、すべてのプロトコルをすぐに変更するのではなく、再試行の繰り返し、バックグラウンドの大量通信、接続のループを探しましょう。設定と状況を記録したうえで、よくある質問を参考にひとつずつ原因を絞り込めます。

6. オリジナル版、Meta、mihomoのコアの関係

「Clash」はエコシステムを指す場合と、特定のコアを指す場合がある

オリジナル版Clashは、広く使われているルール、プロキシグループ、YAML設定の慣習を築きました。その後、さまざまなフォークや派生実装、GUIクライアントが登場しています。名前にClashが含まれるソフトでも、同じコアが動いているとは限りません。オリジナルプロジェクトはすでにメンテナンスを終了しており、古いクライアントに同梱されたコアの機能が、サブスクリプションの更新で自動的に増えることもありません。この点を理解すると、同じファイルが一方の端末では動き、別の端末では未知のプロトコルや項目として表示される理由が分かります。

Clash Metaはこのエコシステムで機能を拡張したフォークの名称で、mihomoはそのコアプロジェクトを引き継いだ後継の名称です。ユーザー間では両方の名前が使われますが、同じ、または似た名前だからといって、過去のすべてのビルドが同一とは限りません。新しいプロトコルやセキュリティの組み合わせ、ネットワーク機能を使う場合は、現在のクライアントが実際に利用しているコアを確認しましょう。過去のガイドにあるMeta専用オプションも、現行のドキュメントで引き続き使えるか確認が必要です。

設定の互換性は3つの段階で確認する

第1段階は構文を読み込めるかです。インデント、リスト、項目の型がYAMLの解析要件に合っているかを確認します。第2段階はコアが項目を認識するかです。たとえば、特定のプロトコルやDNSオプションに対応しているかを見ます。第3段階は実行環境が実際の処理を行えるかです。仮想NICの作成、ポートの待ち受け、証明書の読み込みなどが該当します。インポートに成功しても、確認できたのは通常その前の段階までです。ネットワーク権限がそろっていることや、すべてのノードの疎通確認が済んでいることを意味しません。

新しいコアでも一般的な設定の慣習が多く引き継がれていますが、互換性があるからといって、古いファイルが必ずそのまま動くわけではありません。廃止された項目、初期動作の変更、ルール用リソースの形式、実験的なオプションなどが違いを生むことがあります。反対に、新しい設定を古いコアに渡しても、未対応機能が自動的に無効化されるとは限りません。エラーが出たら「設定エラー」とだけ記録せず、該当する項目のパスを残しましょう。構文の問題か機能の問題かを特定しやすくなります。

GUIが元の設定を上書きする場合がある

クライアントは、ポート、システムプロキシ、DNS、TUNを管理するため、設定の上書き、パッチ適用、マージを行うことがよくあります。ユーザーが編集したサブスクリプションのファイルが、そのままコアに渡されるとは限りません。たとえば、ファイルの混合ポートを変更しても、再起動後に元の値へ戻る場合は、GUIの設定が起動時にその項目を上書きしている可能性があります。サブスクリプション更新で置き換わるキャッシュファイルを何度も編集するのではなく、クライアントが提供する実行中設定やマージ後のプレビューを確認しましょう。

移行する際は、まず元の設定をエクスポートし、ローカルで上書きした内容を記録してから、新しいクライアントにコピーをインポートしましょう。まずTUNを無効にし、ルールモードと動作確認済みのノード1つで基本接続を確かめます。その後、DNS、ルール用リソース、仮想NICをひとつずつ戻します。問題が出たときに、どの手順で差が生じたか分かりやすくなります。クライアント、コア、サブスクリプション、通信の取り込み方式を一度に置き換えると作業は早くても、元に戻すこともトラブルの切り分けも大幅に難しくなります。

プラットフォームと権限にも制約がある

Windowsのサービス権限、macOSのネットワーク許可、Linuxのネットワーク管理とファイアウォール、AndroidのVPNサービス用インターフェースが、実際の通信の取り込みに影響することがあります。iOSのクライアントも、OSのインターフェースと各アプリの実装に従う必要があります。同じ名前のソフトでも、デスクトップ版と完全に同じコア機能を持つとは限りません。クライアント選びでは、プラットフォームごとの説明とインポート機能を確認し、デスクトップ版の画面をスマホ版の対応保証と見なさないようにしましょう。

古いクライアントが起動直後に終了しても、すぐにサブスクリプションのプロトコルが新しすぎると決めつけないでください。ポートの競合、権限、設定の構文、実行環境が原因で起動に失敗することもあります。まず起動時クラッシュのトラブル対処リストを参考にログを確認し、コアの更新、設定の移行、システム設定の調整を判断しましょう。

7. YAML、Base64、SIP008の互換性

サブスクリプションは設定の配布形式であり、接続プロトコルではない

サブスクリプションのURLは設定を配布するためのもので、ノードのほか、プロキシグループ、ルール、リモートリソースが含まれる場合もあります。ダウンロード方法と、ノードがSS、Trojan、TUICのどれを使うかに直接の対応関係はありません。同じサービスでも、クライアントごとに名前が似た複数の出力形式を用意している場合があります。あとから変換するより、現在のクライアントまたはmihomoの設定形式に対応すると明記されたURLを選ぶほうが、元の意味を保ちやすくなります。

Clash形式のYAMLは、完全な設定ファイルの場合もあれば、ノードのリソースだけの場合もあります。完全な設定には、通常、プロキシ一覧、プロキシグループ、ルールなどのトップレベル項目が含まれます。ノード用リソースには、メイン設定から参照するノードに必要な部分だけが含まれている場合があります。リソース用URLを完全な設定としてインポートすると、クライアントに必要なプロキシグループが不足することがあります。反対に、ノードリソースだけを読み込む入口に完全な設定を渡すと、構造が不正だと表示されることがあります。

Base64が示すのはエンコード方式だけ

複数の共有リンクをまとめたテキストをBase64でエンコードして配布するサブスクリプションは多くあります。Base64は単なるエンコード方式で、暗号化を行うものではなく、ノードのプロトコルも定めません。デコード後にはSS、VMess、Trojanなどのリンクが混在していることがあり、クライアントはそれぞれの構文を解析する必要があります。完全なルール設定ほど多くの情報を表現できないため、インポート後にノードは表示されても、元のグループやルールがない場合があります。必ずしもダウンロードエラーとは限りません。

SIP008はShadowsocksのサーバー情報を表すJSON形式です。複数のSSサーバーと関連項目を記述できますが、6種類のプロトコルに共通するサブスクリプション形式ではありません。JSON形式だからといって、VMessの共有リンクでよく使われるJSON構造と同じものとは限りません。拡張子やブラウザーで表示できるかではなく、実際の構造と用途を確認してください。サブスクリプションURLの末尾から、返される形式が分かるとは限りません。

変換で失われやすいのは、項目だけでなく意味

変換ツールは複数の共有リンクを、対象クライアントが読み込めるノード一覧にまとめられます。しかし、元データにないルール、プロキシグループ、ヘルスチェックを復元することはできません。複雑なトランスポート項目が変換先の形式に対応していない場合、無視、簡略化、エラーのいずれかになる可能性があります。名前の似た項目でも設定可能な値が同じとは限りません。変換後のファイルを解析できても、元の設定と同じ接続動作になるとは限りません。

サブスクリプションには接続認証情報が含まれることがあり、URL自体にアクセス用の認証情報が含まれる場合もあります。実際のURLを出所不明の変換サービスに送らないでください。公開の場で相談するときも、パスワード、ユーザーID、アドレス内の機密情報を削除しましょう。サービス提供元の公式出力か、信頼できるローカル処理を優先してください。形式の違いを詳しく知りたい場合は、サブスクリプション形式と相互変換の解説をご覧ください。

ローカルルールとサブスクリプション更新を分けて管理する

サブスクリプションからダウンロードしたファイルにローカルルールを直接追加すると、次回の更新で上書きされることがあります。クライアントに用意された上書き・マージ機能を使い、項目が置き換えられるのか、リストに追加されるのかを確認するほうが安全です。ルールは通常、上から順に照合されます。末尾に追加しても必ず有効になるとは限りません。前にフォールバックルールがあると、新しいルールが適用されない場合があります。プロキシグループの参照名も、実際のノード名やグループ名と一致させましょう。

mode: rule
mixed-port: 7890
allow-lan: false
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

上記はダイレクト接続だけを行う最小限の設定例で、YAMLのインデントとルールの順序を示すものです。プロキシノードは含まれていません。混合ポートは端末内のアプリ向けで、LANからのアクセスは無効にしています。ドメインのルールを先に照合し、最後の行でそれ以外の通信を処理します。使用中のサブスクリプションにそのまま上書きしないでください。プロキシ経由にするには、利用可能なノードとプロキシグループを用意してから、ルールの宛先を実在する名前に変更する必要があります。行の文字列を変えるだけでは使えません。

サブスクリプションの更新後にノードが消えた場合は、まず応答が想定どおりの形式かを確認し、次にインポート先、解析ログ、ローカルのフィルター条件を調べましょう。クライアントによっては名前でノードを絞り込んだり、前回選択したプロキシグループへの参照を保持したりします。「返された内容の問題」「項目の非互換」「フィルター後に空になった状態」を分けて調べるほうが、更新を何度も実行するより効果的です。元に戻せる設定のコピーを誤って削除することも防げます。

8. 利用シーンに合わせて選び、ログで確認する

日常の閲覧、モバイル利用、継続的なデータ転送

ウェブ閲覧、仕事、ドキュメント同期が中心なら、まずサブスクリプション内で設定がそろい、安定して接続できるノードを選びましょう。利用可能なSS、Trojan、VMessがあれば、プロトコル名だけを理由に設定全体を作り直す必要はありません。現在のプラットフォームに合ったClash Plusなどをインストールし、クイックスタートガイドに沿って追加した後、ルールが適用されているか確認します。ルールによって一部の通信がダイレクト接続に送られる場合、ノードを切り替えてもその通信に影響しないのは正常な動作です。

スマホを使うときに画面を消すことが多い、通勤中にネットワークを切り替える、モバイルデータを使うといった場合は、復帰の速さとバックグラウンドでの再試行も比較しましょう。同じ接続条件でTCP系ノードとQUIC系ノードを試し、待機後にタイムアウトが頻発するか確認できます。接続を維持するために、最初からすべてのキープアライブ間隔を短くする必要はありません。長時間バックグラウンドにした後だけ使えなくなる場合は、省電力設定やVPNサービスの状態も確認し、OSによる一時停止をプロトコルの切断と誤認しないようにしましょう。

継続的な通信やリモート操作でパケットロスが気になる場合は、UDPが利用でき、サーバー設定もそろっていることを確認したうえで、Hysteria2やTUICを試せます。比較用にTCP系ノードを残し、一般のウェブページも同時に開いて応答を確認しましょう。大容量のダウンロードで上り・下りを使い切り、ほかの通信が遅くなる場合は、送信量の想定をさらに増やすのではなく、帯域の設定と輻輳を確認してください。サーバーの出口回線に余裕がなければ、ローカルのプロトコルを変えても容量は増えません。

ゲーム、LAN共有、ルーターでの利用

ゲームやリアルタイムの音声・映像通信では、まずUDP転送と通信の取り込み範囲を確認しましょう。システムプロキシではすべてのアプリの通信を取り込めないことがあり、必要に応じてTUNを検討します。TUNがシステムのネットワークスタックに接続される仕組みや、DNSの処理については、システムプロキシとTUNの仕組みの違いおよび仮想NICによる通信の取り込みガイドをご覧ください。取り込みが成功してもサーバーまでの経路によって結果は変わるため、すべてのゲームで遅延が改善するとは限りません。

スマホやテレビからPCのプロキシを共有する場合は、「端末からPCまでのローカルプロキシ方式」と「PCからノードまでの出口プロトコル」を区別しましょう。混合ポートはHTTPとSOCKS5を同時に受け付けられますが、端末側がそのプロキシ設定に対応しているかも確認が必要です。LANからの接続を許可する場合は、利用範囲を制限し、ファイアウォールを確認してください。手順は混合ポートとLAN共有の設定をご覧ください。ルーターで使う場合は、プロセッサ、メモリ、接続数、ルールの規模も考慮しましょう。

接続の流れに沿ってトラブルを切り分ける

最初に、アプリのリクエストが接続一覧やログに表示されているか確認します。何も記録されていなければ、アプリのプロキシ設定、システムプロキシの状態、TUNによる取り込みを調べましょう。記録がある場合は、適用されたルールとプロキシグループを確認し、意図しない出口に送られていないかを見ます。次にサーバー名の名前解決が成功しているか確認してください。特に、まだ確立されていないプロキシ経路にDNSが依存している場合は注意が必要です。まず名前解決を解決してからノード認証を検討しましょう。そうしなければ、後続のテストは実際には行われていません。

次に、基礎となる接続とセキュリティハンドシェイクを確認します。接続タイムアウトではアドレス、ポート、ネットワークの到達性を調べます。証明書エラーでは時刻、名前、証明書チェーンを確認し、認証エラーではパスワード、ユーザーID、プロトコルの世代を調べます。最後に、接続先サービスへのアクセスとUDP転送を確認しましょう。すべてのエラーをDNSの問題にまとめたり、証明書検証を無効にしたり、グローバルなダイレクト接続で問題を覆い隠したりしないでください。原因特定に必要な手がかりを失うことになります。

最適な構成を永久にひとつに決める必要はありません。家庭のネットワーク、モバイル回線、ゲストWi-Fiで優先するノードを変えても、ルール構成とフォールバック方法はできるだけ分かりやすく保ちましょう。一度だけのテストで最小だった数値より、安定して再現できる結果を重視してください。クライアントを変更する場合は、ダウンロードページでプラットフォームとメンテナンス状況を確認しましょう。基本操作の疑問はよくある質問へ、プロトコルやコアの違いはこのページの目次から引き続きご覧ください。