Clashのプロトコルとコアの選び方

コアの系譜とクライアントの役割

Clash、Meta、mihomoの関係

Clashは、ノード、プロキシグループ、ルールをYAMLで記述する方式を広めました。アプリの通信を共通のルーティング処理に流し、ルールに応じて直接接続、プロキシ経由、または拒否を選択します。オリジナルのオープンソースプロジェクトはすでにアーカイブされており、過去のオープンソースコアとPremium版も、機能が完全に同じではありません。「Clash対応」と書かれた設定でも、名称の似たすべてのクライアントで読み込めるとは限らず、現在使われているすべてのプロトコルに対応するとも限りません。

Clash.Metaはこの設定体系を引き継ぎ、プロトコル、DNS、ルーティング機能を拡張しました。その後はmihomoの名称で開発が続いています。ネット上の解説にあるMeta、Clash Meta、mihomoは、同じコアの発展過程を指すことが多いものの、記事の公開時期によって説明されている挙動は異なります。新しいプロトコル、ルールのパラメーター、DNSの項目を使う際は、記事タイトルの名称だけで互換性を判断せず、現在動作しているコアが対応しているか確認してください。古い設定例は構造の理解には役立ちますが、最新の項目説明の代わりにはなりません。

クライアントは管理、コアは通信処理を担当

クライアントは管理画面であり、プロトコルのハンドシェイク、名前解決、ルール選択、通信の転送を実行するのはコアです。Clash Verge Revはデスクトップでの設定管理と接続確認に対応しています。FlClashやClash Meta for Androidなどのクライアントにも、それぞれ独自の操作方法やシステム連携があります。同じコアでも、画面上の設定名、設定のマージ順、権限の許可方法がクライアントによって異なる場合があります。クライアントが起動しても、サブスクリプション内のすべてのノードがコアに受け入れられたとは限りません。設定を読み込めても、各ノードで認証が成功するとは限りません。

複数のプラットフォームで使うクライアントを選ぶなら、まずおすすめのClash Plusを確認し、必要な機能に応じてほかのクライアントと比較しましょう。Clash Plusが複数のプラットフォームに対応していても、各プラットフォームの実装が同一とは限りません。また、製品名だけで使用コアを判断しないでください。デスクトップでルールの確認や上書き設定を管理したい場合は、Clash Verge Revも検討できます。利用可能なクライアントはダウンロードページで確認できます。Clash for WindowsとClashX Metaは開発が終了しているため、過去の情報を参照する際は、アーカイブ済みのクライアントと現在も進化しているプロトコル機能を区別してください。

まず実行中のコアを確認

クライアントの設定画面または概要画面を開き、コアの名称を確認します。画面にクライアントの情報しか表示されない場合は、起動ログにあるコアの識別情報を確認してください。StableとAlphaのチャンネルは区別が必要です。Alphaは新しい変更を検証するためのもので、接続性能を自動的に高める設定ではありません。普段使いでは安定した環境を優先し、特定の問題が修正済みである場合や、必要な機能を検証するときに限って別のチャンネルを試しましょう。切り替える前に設定のバックアップを取り、チャンネル変更とサブスクリプション更新を同時に行わないようにしてください。問題の原因を特定しにくくなることがあります。

移行時は、まず設定を正常に解析できるか、次にノードが接続できるか、最後にルールが意図どおり適用されるかを確認します。この3段階は、それぞれ項目への対応、プロトコルの相互運用性、ルーティングのロジックに対応します。YAMLの書式が共通していても、項目、初期値、拡張機能が完全に一致するわけではありません。古い設定がスクリプト、特定のルールプロバイダーの挙動、クライアント固有のプレースホルダーに依存している場合は、代替手段を一つずつ確認してください。解析を通すために未知の項目をまとめて削除すると、起動はしても動作が変わった設定が残るおそれがあります。

SSとVMess：基本的なカプセル化方式の違い

シンプルな構成のShadowsocks

Shadowsocksは一般にSSと呼ばれ、クライアントとサーバーで共有する鍵を使って暗号化プロキシを構築します。初期の設計では、プロトコルのオーバーヘッドを抑え、導入しやすい構成を重視しており、各接続を完全なTLSセッションで包むことは必須ではありません。一般的な設定項目はサーバーアドレス、ポート、暗号方式、パスワードです。項目が少なくても、自由に置き換えられるわけではありません。サーバー側の暗号方式に合わせてクライアント側も設定する必要があり、パスワードが同じでも方式が違えば正常に通信できません。

現在の環境では、旧式のストリーム暗号、AEAD暗号、Shadowsocks 2022系を区別してください。AEADは暗号化とメッセージ認証を組み合わせ、受信側がデータの改ざんを検証できるようにします。2022系では鍵やセッションの扱いも変更されています。既存ノードで自由に選べる「強化モード」ではありません。方式によっては指定の長さに合ったエンコード済みの鍵が必要で、一般的なパスワードで代用できません。サブスクリプションに記載された暗号方式が現在のコアでサポートされているかを確認し、サーバー側の設定と照合してください。入力欄を通すために、手作業で別の方式名に変更しないでください。

SSはTCPに対応し、双方が対応して有効にしている場合はUDPも転送できますが、処理経路は異なります。Webページは開くのに音声通話が失敗する場合、UDPが通信経路全体で使えていない可能性があります。プラグインは別の拡張レイヤーです。SSの構成によっては、追加プラグインで通信をカプセル化するため、クライアント側も同じプラグインとオプションに対応している必要があります。SSに対応していても、あらゆるプラグインの組み合わせが使えるとは限りません。ノード移行時にプラグインの項目が抜けると、アドレスとパスワードが正しく見えても、接続直後に切断されることがあります。

認証と通信方式を組み合わせるVMess

VMessはV2Rayのエコシステムに由来し、ユーザー識別、認証、データ転送を組み合わせて設計されています。識別情報にはUUIDがよく使われます。SSとの違いは、パスワードをUUIDに置き換えただけではなく、認証とカプセル化の方式も異なります。VMessは複数の通信方式と組み合わせられるため、どちらもVMessと表示されていても、一方はTCP直結、もう一方はWebSocketとTLSを使う場合があります。接続手順、証明書の要件、中継機器との互換性も変わるため、あるVMessノードでのテスト結果をすべてのノードに当てはめないでください。

VMessノードを確認する際は、識別情報、通信方式、TLSの有効・無効、パスやサービス名などの拡張項目をあわせて確認してください。VMessの認証は時刻にも関係するため、端末の時刻がずれていると認証に失敗することがあります。この種のエラーが出た場合は、まず時刻の自動設定を有効にしてからアカウント情報を確認しましょう。古い認証方式に関する設定が、過去の解説に残っていることもあります。新しい設定では通常、現在のAEAD方式が使われます。古い画面の再現だけを目的に過去の項目を追加したり、クライアントが項目を受け付けることを理由にサーバーもその方式を使っていると判断したりしないでください。

既存ノードから選ぶポイント

通常のWeb閲覧やファイル転送が目的で、サーバー側の条件が同程度なら、SSは設定を確認しやすく、原因となる要素も比較的少ない傾向があります。すでにVMessを使っていて、設定が揃い安定しているなら、プロトコル名が古いという理由だけで移行する必要はありません。暗号化にかかる負荷は端末のプロセッサーやアルゴリズムの実装にも左右されます。ハードウェアアクセラレーションに対応したデスクトップと、低消費電力のルーターでは、動作に大きな差が出ることがあります。設定項目の数だけで性能を推測したり、プロトコルの登場順を品質の順位とみなしたりしないでください。

実際に比較する際は、同じ端末、同じ接続ネットワーク、同程度のサーバー設置地域に揃えたうえで、接続の確立、継続的な転送、UDPを使うアプリをそれぞれ確認します。ノードの回線が異なる場合、プロトコルより回線の差が大きく影響することがあります。失敗が名前解決、認証、通信のどの段階で起きているかを記録すると、暗号方式を何度も切り替えるより原因を特定しやすくなります。設定が不明な場合はサブスクリプションの提供元に確認してください。試行錯誤の結果を元のサブスクリプション設定に上書きすると、次回更新で元に戻り、問題が再発したように見えることがあります。

TrojanとVLESS：認証と通信方式を分けて考える

TrojanはTLS接続内で認証する

Trojanの一般的な実装はTLSを使い、保護された接続内でプロキシ認証とリクエストを処理します。TLSは通信の暗号化とサーバー認証を担当し、Trojanはユーザーにプロキシを使う権限があるかを確認します。成熟したTLSの仕組みを利用しながら、比較的シンプルなプロキシリクエスト構造を保つ設計です。ノードには通常、サーバー、ポート、パスワード、サーバー名が含まれます。項目が少なく見えても、証明書、ドメイン名、サーバーの待ち受け設定が一致していないと、認証前に接続が失敗します。

サーバーアドレスとTLSのサーバー名は別のものです。アドレスは接続先を指定し、ドメイン名またはIPアドレスを使います。サーバー名は通常、SNIの送信と証明書名の検証に使われ、どのサイト設定を使うかをサーバーに伝えます。サブスクリプションで専用のサーバー名が指定されている場合は、その値を維持し、アドレス欄のIPアドレスに安易に置き換えないでください。証明書の期限切れ、証明書チェーンの不足、名前の不一致は、サーバー側または正しい設定箇所で修正してください。互換性を得るために検証を無効にするのは避けましょう。

Trojanが他のプロトコルより速いとは限りません。新しい接続では基盤となる接続とTLSハンドシェイクが必要で、所要時間は往復時間、セッション再開、クライアントの接続再利用の挙動に左右されます。一般的なTrojanはTCPトンネルでプロキシ通信を運びます。UDP転送を使う場合も、クライアントとサーバーの両方で実装と設定が対応しているか確認が必要です。アプリがUDPを使っているからといって、外側の通信もUDPだとは限りません。プロトコル名が示すのはプロキシのレイヤーであり、実際のネットワーク性能は外側の通信方式にも左右されます。この違いを理解することが、ノード比較の重要なポイントです。

VLESSは軽量な認証と外側のセキュリティを分ける

VLESSはV2Ray関連のエコシステムに由来し、比較的シンプルな識別情報とリクエスト構造を採用しています。SSのような独立したデータ暗号化機能はなく、通常はTLSやREALITYなどの外側の仕組みで通信を保護します。「VLESSは暗号化がないから速い」と考えると、接続全体の構成を見落とします。実際のノードでは、認証、通信のカプセル化、暗号化ハンドシェイクなどが組み合わされている場合があります。設定のタイプ名だけで比べず、VLESSとTLS、特定の通信方式の組み合わせのように、構成全体を比較してください。

REALITYは、特定のサーバー構成と組み合わせて使うセキュリティ機構で、どのVLESSノードにも自由に追加できる項目ではありません。使用するには、正しい公開鍵、Short ID、サーバー名、関連するハンドシェイクのパラメーターが必要です。具体的な項目はクライアントの実装によって異なります。公開鍵の誤りとUUIDの誤りでは、失敗する段階が異なります。前者はセキュリティハンドシェイクに失敗する原因になり、後者は後続の認証で失敗することがあります。サブスクリプションに項目が足りなくても、別のノードの値をつなぎ合わせて補わないでください。すべてのパラメーターは同じサーバー設定から取得する必要があります。

VLESSのflowも、一般的な速度向上レベルではありません。サーバー側の設定に対応した通信処理方式を選ぶもので、適切なセキュリティレイヤーと通信条件が必要です。WebSocketのパスやgRPCのサービス名にも実際のルーティング上の意味があり、単なるメモではありません。特定の組み合わせにしか対応していないノードでは、通信方式を変更してもサーバー側の構成は自動では変わりません。変更前にサーバーが実際にどの接続方法を提供しているか確認してください。クライアントの選択欄を新しそうな名称に変更するだけでは、プロトコルが一致しなくなることがあります。

証明書と通信方式のエラーを分けて確認

TLSエラーが出た場合は、まずシステム時刻、証明書の有効性、サーバー名を確認し、端末の証明書環境に問題がないか調べます。TLS接続には成功しても、その後に切断される場合は、パスワード、UUID、パス、リクエストヘッダー、サービス名を確認しましょう。ログの「接続がリセットされました」という表示は、接続先または通信経路上の機器が接続を終了したことを示すだけで、パスワードの誤りを単独で証明するものではありません。失敗した段階を踏まえて判断し、必要ならサーバー管理者に該当する接続先のログを確認してもらいましょう。クライアントで無関係なセキュリティ設定を次々に切り替えるのは避けてください。

信頼できるTLS環境がすでにあり、設定がシンプルな構成を求める場合はTrojanを検討できます。VLESS向けの通信方式や通信処理機能が必要な場合は、要件に合ったVLESSノードを選びましょう。どちらも、サーバー側の設定が完全で信頼できることが前提です。サブスクリプションを読み込んで使う場合は、提供元が生成した設定を優先し、クライアントが構成全体に対応しているか確認してください。項目名を理解したい場合は用語集も参考になります。普段使いのためにノード全体を手作業で組み直す必要はありません。

Hysteria2とTUIC：QUICを使う通信経路

UDPをベースに通信を構築する理由

QUICはUDP上で接続管理、安全なハンドシェイク、信頼性のある転送、複数ストリーム機能を実現します。TCPのデータをそのままUDPパケットに置き換える方式ではありません。もともとトランスポート層が担っていた機能の一部を、ユーザー空間のプロトコル実装に移しています。複数のストリームを使えば、単一ストリームのパケットロスによる配信遅延が他のストリームに及ぶのを抑えられますが、輻輳制御や通信経路の容量は共有する場合があります。Hysteria2とTUICはQUICを利用したプロキシプロトコルです。特定のネットワーク環境で柔軟な通信を目指しており、すべての環境でTCPより優れることを保証するものではありません。

この2種類のノードを使う前に、接続中のネットワークで必要なUDP通信が許可されているか確認してください。ネットワークによっては、UDPのタイムアウト、速度制限、転送ポリシーが異なります。Webページに直接アクセスできても、QUICプロキシが使えるとは限りません。ノードがハンドシェイクの段階で止まる場合は、認証情報より先にUDPの到達性、ポート、サーバーの待ち受け設定を確認します。問題をすべてパスワードのせいにすると、解決に時間がかかります。同じサーバーのTCPノードに接続できても、それは別の通信経路が使えることを示すだけで、UDPの接続先が正常である証拠にはなりません。

Hysteria2の帯域設定と輻輳制御

Hysteria2は、往復時間が長くパケットロスのあるネットワーク向けに、QUICを利用した通信方式を提供します。輻輳制御の挙動は帯域設定に関係し、サーバー側のポリシーにも左右されます。設定の上り・下りの値は、通信制御に使われる入力値であり、帯域を購入したり回線制限を解除したりするものではありません。実際の接続能力を大幅に上回る値を設定すると、キューイングやパケットロスが増え、ほかのアプリの応答も遅くなることがあります。まず実際のネットワーク性能とサーバー側の案内に合わせて設定し、再現可能な条件で結果を確認しましょう。

Hysteria2と旧版Hysteriaは互換性がありません。どちらもHysteriaという名称が含まれていても、タイプの項目を書き換えるだけで移行できるとは限りません。認証、難読化、ポート関連の設定は、クライアントとサーバー双方の実装に合わせて確認する必要があります。ポートホッピングを有効にする場合も、サーバーと中継機器の両方が指定範囲に対応していなければなりません。クライアントに複数のポートを入力しても、サーバー側の接続先は作られません。家庭用ルーターや通信事業者のセッション管理によって、同じノードでもネットワークごとに動作が異なる場合があります。

TUICの認証とUDP転送モード

TUICもQUICをベースとし、信頼性のあるストリーム転送とUDP転送を一つの接続体系にまとめています。プロトコルの世代によって認証パラメーターや動作が異なる場合があるため、サブスクリプションのタイプ、ユーザーID、パスワード、実装要件をまとめて照合してください。クライアントにTUICの選択肢があっても、過去の設定をすべて使えるとは限りません。特に古い共有リンクを新しいコアに読み込む場合は、理解できない認証項目を削除して試すより、提供元にプロトコルの世代と推奨クライアントを確認するほうが確実です。

TUICのUDP転送モードによって、データの運び方やパケットロスの扱いが変わります。ネイティブなデータグラム方式と、信頼性のあるストリーム経由の方式は、単に速度が違うだけではありません。前者はUDP本来のパケットロスの挙動に近く、後者では古いデータの再送が即時性に影響することがあります。輻輳制御のオプションも、実装が対応する範囲で使ってください。オンラインゲーム、音声通話、一般的なダウンロードでは、パケットロスや再送に対する許容度が異なります。別の回線の設定をそのまま選ぶのではなく、利用するアプリで確かめましょう。

QUICには接続を移行する機能などがありますが、プロトコルが機能を備えていても、クライアントがネットワーク切り替え時に常に通信を維持できるとは限りません。システムのネットワーク拡張、サーバー側のポリシー、アプリのタイムアウトによってセッションが切れることがあります。Wi-Fiとモバイル回線を頻繁に切り替える端末では、実際に切り替えを試すことも選定基準に加えましょう。Hysteria2やTUICを選ぶ場合も、安定したTCP系の予備ノードを一つ確保しておくと役立ちます。接続環境が変わったときに、まず通信を復旧し、その後UDP経路の制限を確認できます。

接続速度、スループット、リソース使用量

「速さ」を段階ごとに考える

ノードのテストで混同しやすいのは、接続にかかる時間、最初の応答、継続的なスループットです。接続時間には名前解決、基盤のハンドシェイク、認証が含まれます。最初の応答には接続先サービスの処理と応答経路も関係します。継続的なスループットは、輻輳制御、経路の容量、サーバーのリソースに左右されます。クライアントのURLテストは、特定の接続先とテスト方法における一部の処理しか反映しないことがほとんどです。数値が小さくてもダウンロードが速いとは限らず、動画、音声、長時間接続が安定するとも限りません。まず、改善したい使用感を明確にしましょう。

一般的なSSのカプセル化では、完全な外側のTLSハンドシェイクが必須ではありません。TrojanやVLESSのハンドシェイクは、セキュリティレイヤーと通信方式の組み合わせによって異なります。Hysteria2やTUICはQUICの接続機構を利用します。ハンドシェイクにはセッション再開や接続再利用も影響するため、同じノードへの2回目のアクセスが初回よりスムーズでも、ネットワークが急に改善したとは限りません。比較では、新規接続時と確立済み接続の使用感を分けてください。一方のノードを事前に接続済み、もう一方を起動直後の状態で比べて結論を出さないようにしましょう。

スループットの上限は、プロトコル以外の要因で決まることが多い

ダウンロードの上限は、端末の無線信号、サーバーの回線、接続先サイト、端末のプロセッサー、中継ネットワークなどが原因になることがあります。パケットロスの多い経路では輻輳制御が結果に大きく影響し、往復時間が短く安定した経路では、追加のカプセル化や実装の効率が見えやすくなります。特定のプロトコルで一度出たピーク値を、一般的な性能とみなさないでください。ノードを切り替えたときにサーバーの地域や通信事業者の回線も変わっていると、プロトコルの影響だけを判断できません。そのテスト条件では、現在のノードの組み合わせが適していたとしか言えません。

多重化は接続を確立し直すコストを減らせますが、複数の通信が互いに及ぼす影響も変わります。複数の論理接続を一つの外側の接続にまとめると、ハンドシェイクの回数が減る一方で、キューイングや障害の影響が集中することがあります。改善するかどうかは外側のプロトコルと実装次第です。サーバー側の対応なしに多重化を有効にしたり、クライアントごとに同じ名前の設定を同一の仕組みとみなしたりしないでください。Web閲覧、マルチメディア、ファイル転送でそれぞれ確認するほうが、設定の説明にある「最適化」という言葉だけを見るより有効です。

プロセッサー、メモリ、バックグラウンド処理

リソースを消費するのは暗号化だけではありません。ユーザー空間でのプロトコル処理、パケットのカプセル化、ルール検索、DNSキャッシュ、ログ記録、接続状況の集計もリソースを使います。低消費電力の端末では、ハードウェアアクセラレーションへの対応やコアの実装効率が、プロトコルの項目数より重要な場合があります。ルーターでは、同時接続数やメモリ容量も考慮が必要です。デスクトップでは問題なく動く設定でも、小型端末に移すとプロセッサーの負荷が高まり、スループットが下がることがあります。サーバー回線が遅くなったとは限りません。

リソースを確認するときは、負荷条件を揃えてください。まずアイドル時のバックグラウンド動作を記録し、次に一定数のアプリを起動してから、継続的な通信をテストします。デバッグログは記録や整形の負荷を増やすため、トラブル対処が終わったら通常のログレベルに戻してください。通信が終わっても接続数が増え続ける場合は、アプリの再試行、DNSの失敗、ルールの循環などを確認し、すぐにプロトコルのメモリ使用量だと決めつけないでください。キャッシュや接続のライフサイクルによって一時的にリソースが増えることもあり、短時間のスクリーンショットだけでは長期的なメモリリークを判断できません。

プロキシグループも測定結果に影響します。url-testは通常、指定した接続テストの結果に応じてノードを自動選択します。fallbackは優先順に利用可能なノードを選び、load-balanceは複数のノードに接続を振り分ける場合があります。特定のプロトコルをテストするときは、プロキシグループがバックグラウンドで出口を切り替えないよう、ノードを固定してください。各方式の違いはプロキシグループの種類を詳しく解説をご覧ください。プロキシグループが選択するのはノードであり、ノード自体のプロトコル実装は変わりません。

最終的な結論は、「この端末では、現在のWi-Fi環境でこのノードのほうが安定する」のように、条件を明記してまとめましょう。「特定のプロトコルが常に最速」とは言えません。ネットワークや端末が変わったら、過去の結果を再検証してください。すべてのプロトコルで同じ接続先に失敗する場合は、接続先のサービス自体、DNS、ルーティングルールも確認が必要です。問題の段階を切り分ければ、プロトコル名を追いかけてクライアントを変更しても、接続を妨げている根本原因が解決しないという事態を避けられます。

モバイルの電池消費とシステムの通信処理

電池消費は一連の処理全体で決まる

モバイル端末の電池消費は、画面、無線通信、プロセッサー、バックグラウンド処理、プロキシの動作など、複数の要因で決まります。プロトコルの暗号化は、その一部にすぎません。モバイル回線で送受信を続けたり、端末が頻繁に起動したりすると、無線通信が高い稼働状態を保ちやすくなります。電波が弱い、再送が繰り返される、アプリが何度も接続を試みるといった状況も、電池消費を増やします。そのため、SS、Trojan、QUIC系プロトコルに決まった電池消費の順位を付けることはできません。同じプロトコルでも、Wi-Fiとモバイル回線、あるいは同じ場所でも電波状況によって結果が異なります。

接続を維持する場合と、何度も再接続する場合ではコストが異なります。長時間の接続は認証の繰り返しを減らせますが、ハートビートの間隔が短すぎるとバックグラウンドの通信が増えます。長すぎると中継機器がセッションを破棄し、次回アクセス時に再接続が必要になることがあります。QUIC、TCP、各プロキシ実装では、接続維持の仕組みが異なります。別のクライアントのハートビート間隔をそのまま流用しないでください。普段はサーバーとクライアントの適切な初期値を使い、アイドル時の切断やバックグラウンドでの頻繁な起動が実際に確認できた場合に、該当する設定を調整しましょう。

システムプロキシですべての通信を処理できるわけではない

デスクトップのシステムプロキシが影響するのは、主にその設定に従うアプリです。すべてのUDP通信や独自のネットワークスタックを使う通信が自動的に経由するわけではありません。TUNモードは仮想ネットワークインターフェースで通信を受け取り、コアに渡すため、より広い範囲をカバーできますが、ルーティング、DNS、権限などの条件が増えます。どちらも通信の入口となる方式であり、プロキシプロトコルではありません。システムプロキシからTUNに切り替えても、VMessが別のプロトコルに変わったり、サーバーのパスワードの誤りが直ったりするわけではありません。プロキシのルール処理にどの通信が入るかが変わるだけです。

Androidクライアントは通常、システムのVPNインターフェースで端末の通信を受け取ります。バックグラウンドでの接続維持は、メーカー独自のバッテリー制御、バックグラウンド権限、アプリのスリープ状態にも左右されます。画面をロックすると切断される場合は、まずシステムがクライアントのバックグラウンド動作を制限していないか確認してください。その後、特定ノードのアイドル接続が回収されただけではないかを調べます。バックグラウンド動作を許可すると接続が維持されやすくなりますが、端末が稼働状態を保つ時間も増えることがあります。一度に変更するのは一項目にし、実際に待機させて効果を確認してください。すべての電池制限を解除する必要はありません。

iOSクライアントはシステムのネットワーク拡張機能を使って動作し、メモリやバックグラウンドの挙動はシステムによって管理されます。クライアントを選ぶ際は、まずおすすめのClash Plusを確認し、サブスクリプションへの対応状況と端末の使い方に合わせて選びましょう。インストール先はiOSクライアントをご覧ください。デスクトップのコア切り替え手順、プロセス管理の方法、ローカルファイルのパスをそのままモバイル端末に当てはめないでください。システムがネットワーク拡張機能を終了した場合、アプリに切断と表示された場合、ノードのハンドシェイクに失敗した場合は、それぞれ異なる問題です。システムの状態とクライアントのログを分けて確認してください。

プロキシの自動テストやログも電池を消費する

プロキシグループの定期テストはリクエストを自動送信します。設定内にヘルスチェックが多くあると、Webを閲覧していなくても端末が通信を続けることがあります。テスト間隔を短くしても通信が安定するとは限らず、端末の起動回数やリクエストが増える場合もあります。実際に必要な接続先と周期だけを設定し、バックグラウンドのチェックと、すべてのノードを手動で一括テストする操作を区別してください。サブスクリプションやルールデータの更新にも適切な間隔を設定し、すぐに更新したいからといってモバイル回線で大きなファイルを何度も取得しないようにしましょう。

ルールによる振り分けを使えば、プロキシが不要な通信を直接接続し、余計なカプセル化を避けられます。ただし、正しいルールが設定されていることが前提です。グローバルプロキシで多くの通信をノード経由にしても、すべてのアプリの動作が改善するとは限りません。直接接続モードでも、クライアントのバックグラウンド処理が完全になくなるわけではありません。アプリごとの除外設定、LANへの接続、DNSのルーティングを調整し、通信と名前解決が別々の利用できない経路に流れないようにしましょう。プロキシを有効にしたときだけ特定のアプリに問題が出る場合は、まず通信がコアに届いているかを確認し、次に適用されたルールを確認してください。

モバイルでクライアントを選ぶときは、まずサブスクリプションとの互換性を確保し、次にバックグラウンド接続とネットワーク切り替え後の復帰を確認し、最後に電池消費を調べましょう。音声通話やゲームをよく使う場合は、Web閲覧だけでなくUDP通信も検証してください。現在のモバイル回線でTCP系ノードが安定しているなら、「新しいプロトコル」という理由だけでQUICに切り替える必要はありません。逆に、電波の弱い環境でQUICノードのほうが使いやすい場合は、電池消費の表示だけで候補から外さず、継続的な使用感をもとに判断してください。

サブスクリプション形式と設定の互換性

リンク、ノード一覧、完全な設定ファイル

サブスクリプションURLは内容を取得するためのアドレスであり、内容の形式そのものではありません。サーバーはリクエスト方法に応じて、ノードの共有リンク、エンコードされたリンク一覧、Clash形式のYAML、または別のクライアント専用形式を返すことがあります。あるアプリで読み込めるURLでも、別のアプリに同じ内容が返るとは限りません。読み込みに失敗した場合は、まず提供元が現在のクライアント向けのURLを用意しているか確認し、返された内容が正常な設定かを確認してください。ログイン画面、エラーメッセージ、通信量の有効期限案内が、サブスクリプションの内容としてダウンロードされている場合もあります。

ノード共有リンクは単一のノードを表し、ノード一覧は選択可能なサーバーをまとめたものです。完全な設定には、プロキシグループ、ルール、DNS、待ち受け設定なども含まれることがあります。この3つは同じものではありません。ノードだけを読み込む場合、クライアント側でルーティング設定を生成または補完することがあります。完全な設定を読み込むと、既存の設定が上書きされる場合があります。変換サービスで表記形式を変えても、接続先コアにプロトコルの機能が追加されるわけではありません。対象のコアが通信方式の組み合わせに対応していない場合、変換後のYAMLが正しくてもノードは動作しないことがあります。

変換時に失われやすい設定項目

基本的なアドレスやポートは引き継がれやすい一方、複雑な設定は変換時に失われることがあります。TLSのサーバー名、WebSocketのリクエストヘッダー、gRPCのサービス名、REALITYのパラメーター、通信処理方式、UDP関連の設定などがその例です。「元のクライアントでは使えるのに、変換後は使えない」場合は、表示名だけではなく、同じノードの機密情報を伏せた設定内容を比べてください。変換ツールによっては未知の項目を削除したり、対象コアが認識しない場所に書き込んだりすることがあります。どちらの場合も、読み込みは成功したように見えても接続できないことがあります。

サブスクリプションを第三者の変換サービスに渡す場合は、アクセス情報の漏えいにも注意してください。サブスクリプションURLにアカウントを識別できるパスやパラメーターが含まれていると、リンクをアップロードした相手が同じ内容を取得できることがあります。まず提供元が直接配布する対応形式を使うか、信頼できる環境で変換してください。人に相談するときは、URL内の認証情報やノードのパスワード、UUIDなどの識別情報を削除し、トラブル対処に必要な設定の構造だけを残しましょう。ノード名やサーバーのドメイン名から利用状況が分かることもあるため、必要に応じて伏せてください。

サブスクリプションの内容とローカルの上書き設定を区別

クライアントはサブスクリプションの内容に、ローカルの上書き設定、全体設定、設定の拡張を組み合わせ、コアに渡す実行設定を生成することがあります。サブスクリプションのキャッシュを直接編集すると、次回の更新で変更が上書きされることがよくあります。DNS、ルール、プロキシグループなどを継続して変更する場合は、クライアントが正式に対応する上書き機能を使い、マージ方法も確認してください。リストが追加される場合もあれば、全体が置き換わる場合もあります。特にルールは上から順に適用されるため、最後のフォールバックルールより後に追加した項目は適用されないことがあります。テキストに存在するだけで有効だと判断しないでください。

以下はルールの順序を理解するためのmihomo設定例で、ノード定義は含みません。指定したドメインをドメインサフィックスルールで処理し、プライベートIPアドレスは直接接続し、最後にフォールバックのルールを適用します。ここでのPROXYは、完全な設定内に実在するノードまたはプロキシグループが必要です。no-resolveは、このアドレスルールのために追加の名前解決を行わないようにする設定です。設定全体のDNS機能を無効にするものでも、どの段階でも名前解決が起きないと保証するものでもありません。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,private,DIRECT,no-resolve
  - MATCH,PROXY

YAMLではインデントとデータ型が重要です。階層のインデントにはスペースを使い、タブを混ぜないようにしてください。特殊文字を含む値は正しく引用し、項目名もコアの仕様に合わせる必要があります。解析エラーには該当箇所付近の行番号が表示されることがありますが、原因が一つ前の行にある場合もあります。たとえば、引用符の閉じ忘れやリスト記号の不足です。まず構文を修正してからネットワークをテストし、設定が読み込まれていない状態でノードを何度も切り替えないようにしましょう。クライアントが古い実行設定を保持していると、画面上では接続できているように見えても、新しい設定が適用されていないことがあります。

設定を更新する前に、復元できるコピーを保存してください。更新後は、まず正常に解析できることを確認し、次にプロキシグループの参照先と重要なルールを調べます。すべてのノードが同時に消えた場合は、サブスクリプションの内容とフィルター設定から確認してください。一種類のプロトコルだけでエラーが出るなら、そのプロトコルの項目とコアの対応状況を調べます。ノードに接続できても通信が想定外の経路に進む場合は、適用されたルールと上書き設定を確認してください。形式、プロトコル、ルーティングを3つのレイヤーに分けて調べるほうが、すべての異常を「サブスクリプションの失効」とまとめるより正確です。提供元に問い合わせる際の確認の往復も減らせます。

用途別の選び方とトラブル対処

保守しやすいクライアントと完全な設定を選ぶ

一般ユーザーにとってまず重要なのは、必要な設定が揃い、更新方法が明確で、端末上で安定して動作するクライアントです。まずおすすめのClash Plusを確認し、デスクトップでの管理、モバイルでのバックグラウンド動作、Linuxの利用など、目的に応じてほかのクライアントを選びましょう。Clash Verge Revはデスクトップで設定や接続を確認したいユーザーに向いています。FlClashは複数のプラットフォームに対応し、Clash Meta for AndroidはAndroid向けの選択肢です。Surfboardは、読み込める形式と機能を個別に確認してください。ダウンロードページに同じく掲載されていても、すべてのClash YAML拡張に対応するとは限りません。

サーバーやルーターで使う場合はmihomoコアを直接動かせますが、サービスの起動、ファイル権限、ルーティング、設定更新を自分で管理する必要があります。デスクトップでは、通信の用途と関係のないプロセス管理に時間をかけずに済む、画面付きのクライアントが向いています。インストール前にOSとプロセッサーのアーキテクチャを確認し、インストール後にコアの対応状況を確かめてください。クライアントの選択とプロトコルの選択は別の問題です。前者は管理画面とシステム連携の使い勝手を決め、後者はノードの通信方式を決めます。すでに使っているプロトコルに対応した環境であれば、プロトコルを切り替えるために環境全体を再インストールする必要はありません。

用途に合わせて確認項目を選ぶ

日常のWeb閲覧やオフィス作業では、最初の応答、接続の安定性、ルールの正確さを優先してください。安定して使えているSS、VMess、Trojan、VLESSのノードはいずれも利用できます。大容量のファイル転送では、継続的なスループット、プロセッサーの負荷、ほかの通信がキューイングの影響を受けるかを確認します。往復時間が長い、またはパケットロスがある経路では、UDPが安定していることを前提にHysteria2やTUICを検討できます。会議、音声通話、ゲームでは、ブラウザーのページが開くかどうかだけでなく、実際のアプリの通信を検証してください。

LAN内の機器に頻繁にアクセスする環境では、プライベートIPアドレス、LAN内のドメイン名、仮想ネットワークアダプターのルーティングも確認してください。TUNを使う場合は、プリンター、共有フォルダー、ローカルサービスにこれまでどおりアクセスできるかをテストします。リモートワーク用のソフトウェアでは、独自のプロキシ設定や証明書が必要なことがあります。アプリのドキュメントに従って設定してください。こうした互換性の問題は通信の取り込み方法やルーティングに関係することが多く、ノードのプロトコルを変えれば解決するとは限りません。プロトコルをむやみに切り替えると接続の動作が一時的に変わるだけで、ルーティングの競合が残ることがあります。

失敗した段階から原因を絞り込む

まず端末側から確認します。現在の設定が有効か、コアが動作中か、アプリの通信がプロキシの入口に届いているかを確認してください。次に、DNSが想定したアドレスを返しているか、サーバーのポートに到達できるかを調べ、その後にセキュリティハンドシェイクと認証を確認します。最後に接続先との通信とルールの適用状況を調べましょう。コアに届いた通信だけが、ログや接続画面にルーティング状況を表示できます。アプリの通信がまったく表示されない場合は、ノードのパスワードを変更するのではなく、システムプロキシ、アプリの設定、TUNによる通信の取り込みを確認してください。

同じサブスクリプション内のすべてのノードが同時に失敗する場合は、端末のネットワーク、設定の読み込み、サブスクリプションの状態、共通のDNS設定を優先して確認します。特定のノードだけ失敗する場合は、サーバーとノードの設定を確認してください。特定の種類のプロトコルだけ失敗するなら、コアの対応状況と通信経路を確認します。ノードに接続できても一部のサイトだけ開かない場合は、接続先のDNS、ルール、サーバーの出口を調べましょう。この順序で切り分ければ、範囲を絞り込み、複数の設定を同時に変更せずに済みます。端末側の問題はよくある質問、初回の確認方法はシステムプロキシの設定をご覧ください。

提供元に問い合わせる際は、端末のOS、クライアント、コア名、プロトコルの種類、失敗した段階を伝え、機密情報を伏せた関連ログを添えてください。「使えない」だけではなく、エラーの原文を記載すると原因を特定しやすくなります。ただし、サブスクリプション全体や認証情報は送らないでください。ノードのタイムアウトについては、手前から順に確認するトラブル対処ガイドも参考になります。プロトコルを比較している場合は、テスト時のネットワークとノードを固定していたかも記録すると、同じ条件で再現しやすくなります。