プロトコル / コア / 設定の互換性

Clashのプロトコルとmihomoコアの解説

このページでは、プロトコルの違い、性能上の制約、設定の関係を整理し、クライアントで適切なノードタイプを選ぶための情報を提供します。初回インストール、サブスクリプションの追加、接続確認については、まず使い方ガイドをご覧ください。個別の設定項目やネットワークの問題は、以下の目次から該当する章をご確認ください。

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

Clashはエコシステムの名称であり、特定のインストールパッケージを指すものではありません。GUIクライアントはウィンドウ表示、サブスクリプション管理、システムプロキシの切り替え、権限の取得などを担当します。コアは設定の読み込み、ドメイン名の解決、ルールの照合、外部への接続を担います。この2つは別々のプロジェクトで開発されている場合があります。機能を判断するときは、アプリ名にClashが含まれるかだけでなく、実際に使用しているコアとリリースノートを確認してください。画面に項目があっても、現在のコアがその設定項目に対応しているとは限りません。

オリジナルのClash、Meta、mihomoの関係

オリジナルのClashは、YAML設定、プロキシグループ、ルールによる通信の振り分けという基本モデルを確立しました。過去には機能の異なるオープンソース版やPremiumコアも存在したため、「オリジナル版の対応機能」はどの派生版を指すのか区別する必要があります。Clash.Metaはこのエコシステムを基盤にプロトコルやネットワーク機能を拡張し、後にmihomoの名称で開発が続けられています。古い解説にあるMetaコアや、一部クライアントのMeta表記は、通常この系統を指します。ただし、名称が似ているだけでは実際の対応機能を確認したことにはなりません。

mihomoは、proxies、proxy-groups、rules、dnsなど、多くの基本的な設定構造を引き継ぎながら、VLESS、Hysteria2、TUICなどのプロトコルや関連パラメーターを追加しています。互換性があるのは主に基本構造であり、すべての派生版が双方向に互換するわけではありません。mihomoで読み込める設定でも、古いコアでは未対応のプロトコル、ルールタイプ、DNS項目などが原因で起動できないことがあります。該当機能を使ったときだけ問題が発生する場合もあります。

プロトコル・通信方式・トラフィックの入口を分けて考える

ノードのtypeはプロキシプロトコルを表します。TCP、WebSocket、gRPC、QUICは、使用する通信方式やその基盤を示します。TLSは接続先の認証と暗号化を担います。システムプロキシとTUNは、アプリの通信をコアに渡す経路です。TUNを有効にしてもSSノードがQUICに変わるわけではなく、Hysteria2に切り替えてもすべてのアプリが自動的にシステムプロキシを使うわけではありません。それぞれ異なる層の機能なので、トラブル時は個別に確認してください。

層主な役割主な確認項目
GUIクライアント設定管理とシステム連携サブスクリプションの追加、権限、起動方法
プロキシコアプロトコルの実装とルールの適用プロトコル対応、DNS、TUNの設定
サーバー認証と接続先への通信ポート、証明書、プロトコルの設定
設定ファイル上記の機能を関連付けるノード名、プロキシグループ、ルールの対象

クライアント選びはダウンロードセンターから始め、まずClash Plusの各プラットフォーム向けダウンロード先を確認してください。そのうえで、デスクトップとの連携や管理方法に応じて、Clash Verge RevやFlClashなども検討できます。同じClashエコシステムのクライアントだからといって、どれも同じファイルをそのまま読み込めるとは限りません。サブスクリプションを変換するものや、異なるコアに設定を渡すものもあります。また、プラットフォーム側の制約によりバックグラウンド通信が制限される場合もあります。

古い設定を移行するときは、元ファイルを保存し、最小限の機能で接続を確認してください。基本のノードが使えることを確かめてから、ルールプロバイダー、TUN、高度なDNS設定を有効にします。こうすれば、プロトコルの互換性とシステム連携の問題を切り分けやすくなります。起動手順の詳細はmihomoの使い方をご覧ください。このページの後半では、設定によって違いが生じる理由を説明します。

SS・VMess・Trojanの特徴と選び方

この3種類のプロトコルは同じサブスクリプションに含まれることがありますが、互いに置き換えて使うことはできません。サーバー側のプロトコルに合わせて、クライアント側でも対応する実装と認証情報を設定する必要があります。ノード名を変更してもプロトコルは変わりません。typeの値を別の名称に変えても、プロトコルを変換することはできません。主な違いは、暗号化と認証の仕組み、通信方式の組み合わせ、導入要件、過去の仕様との互換性です。速度の順位が固定されているわけではありません。

Shadowsocks：シンプルな暗号化プロキシ

SSはShadowsocksの一般的な略称です。比較的シンプルなプロトコル構造でプロキシ接続を行い、一般的な設定項目はサーバー、ポート、暗号化方式、パスワードです。現在は、従来のAEAD方式とShadowsocks 2022系を区別する必要があります。鍵の要件、ハンドシェイクの設計、実装側の対応状況は同一ではありません。サーバー側で指定された方式にクライアントを合わせてください。どちらもSSだから互換性があるとは限りません。

SSの基本構造は比較的シンプルですが、「構造がシンプルだから、どの端末でも処理負荷が低い」とは限りません。AES系はハードウェアアクセラレーションに対応した端末で性能を発揮することがあり、ChaCha20系は対応するアクセラレーションのない端末に適する場合があります。実際の結果は実装、プロセッサー、通信量によって異なります。プラグインを使うSSノードには追加の通信要件があります。パスワードだけをコピーしてプラグインのモード、ホスト名、パスを設定しないと、認証情報に問題がないように見えても接続できないことがあります。

VMess：長い利用実績と多様な通信方式

VMessはV2Rayエコシステムで開発され、ユーザー識別、認証、データ転送を包括するプロトコルとして設計されています。複数の通信方式と組み合わせられるため、どちらもVMessのノードであっても、実際のハンドシェイク経路や接続負荷は異なる場合があります。トラブル時はUUID、暗号化オプション、通信方式、TLS、パスの各設定を確認してください。システム時刻が大きくずれていると認証に影響することもあります。プロキシグループを何度も切り替える前に、まずシステム時刻の同期を有効にしてください。

古い解説には、当時の互換性のために残された設定項目が含まれていることがあります。そのまま現在の一般的な推奨設定として扱わないでください。特に、古い設定の認証パラメーターを新しいサーバーへ機械的にコピーするのは避けましょう。VMessは既存の導入例やツールが豊富な点も利点です。既存のサーバーが安定して動作し、クライアントの対応も十分であれば、プロトコルを変えるだけの目的で移行するより、現状を維持する方が合理的な場合があります。アップグレードの必要性は、コアの対応状況、安全性の維持、接続の実測結果を踏まえて判断してください。ノード名の新旧だけで決める必要はありません。

Trojan：TLS接続を利用

Trojanは通常、TLS接続上で認証とプロキシ通信を行います。クライアントでは、パスワード、サーバーアドレス、証明書の検証情報を正しく設定する必要があります。接続先アドレス、SNI、証明書の対象ドメインは、構成によって異なる場合があります。サーバーの設定に合わせてください。証明書の期限切れ、信頼チェーンの不備、ホスト名の不一致はいずれもハンドシェイク失敗の原因になります。証明書検証を無効にしても問題を隠すだけなので、通常の接続方法として使わないでください。

Trojanの接続コストは、TLSハンドシェイク、セッション再開、ネットワークの往復時間によって変わります。「TLSを使うから必ず遅い」とは限りません。長時間のダウンロードと、短い接続を頻繁に行うウェブ閲覧では、接続コストの感じ方が異なります。WebSocketなどを組み合わせる場合は、パス、Host、サーバー側の転送ルールも一致させる必要があります。基本のTrojanと追加の通信方式を組み合わせたTrojanは、別々に検証してください。同じ比較に混ぜると、正しい結論を得られません。

3種類とも日常のウェブ閲覧に利用できますが、UDPに対応しているか、実際に有効になっているかを判断するには、プロトコルの実装、サーバー設定、クライアントの通信経路を確認する必要があります。ウェブページを開けても、成功したのは一部のTCPリクエストだけかもしれません。音声通話、ゲームなどのUDP通信も同じように処理されているとは限りません。QUIC系プロトコルを比較する際も、この点を踏まえてテストしてください。

VLESS・Hysteria2・TUICの特徴と利用条件

新しいプロトコルは、従来の接続方式が抱える特定の課題に対処するものですが、ネットワーク経路そのものの制約をなくすわけではありません。VLESSはシンプルな認証とデータ転送層を重視し、Hysteria2とTUICはQUICを基盤としています。これらが並べて語られるのは、新しいコアで幅広く対応されているためであり、同じ通信動作をするからではありません。追加する前に、プロトコルの世代と具体的な設定項目を確認してください。

VLESS：認証と安全な通信を分離

VLESSはV2Ray関連のエコシステムで開発され、VMessよりシンプルなプロトコル設計を採用しています。重要なのは、VLESS自体には、名称から想像されるような独立したデータ暗号化層がないことです。通常はTLSやREALITYなど、外部のセキュリティ機構で接続を保護します。UUIDで認証できても、通信経路の機密性が十分に確保されているとは限りません。サーバーが提供する通信方式全体を設定し、サーバーアドレスとUUIDだけで済ませないようにしてください。

VLESSの実際の性能は、通信方式の組み合わせによって大きく異なります。TCPによる直接接続、WebSocket、gRPCでは、接続の確立、プロキシ経路、中継サービスの対応状況などにそれぞれ要件があります。特定のflowを使用する構成もありますが、これは汎用の高速化スイッチではありません。サーバーと下位の通信方式に合った設定が必要です。REALITY関連の公開鍵、short ID、サーバー名にもそれぞれ意味があり、どれか1つを省略するとハンドシェイクに失敗することがあります。

Hysteria2：QUICと帯域の活用

Hysteria2はQUICを基盤とし、高遅延やパケットロスなどが発生するネットワーク環境も想定して設計されています。UDPで通信できる経路が必要で、信頼性の高いデータ転送、暗号化ハンドシェイク、輻輳制御などの仕組みを組み合わせています。初代Hysteriaとは、設定項目やプロトコルに互換性がありません。サブスクリプションでプロトコルの種類を明確に指定してください。ノード一覧にHysteriaと表示されていても、hysteria2タイプとサーバー側の対応状況を確認する必要があります。

帯域の設定は、実際の通信経路とサーバー側の方針に照らして判断してください。方式によっては、帯域の推定値がデータの送信動作に影響します。実際の回線速度を大きく上回る値を入力すると、スループットが無料で増えるのではなく、キューの蓄積やパケットロス、他の通信への影響につながる場合があります。サーバー側に速度制限があれば、クライアントの設定値を上げても制限は超えられません。まず提供元の案内に従って既定値を使うか、妥当な値を設定し、継続的な通信と並行したウェブ閲覧で安定性を確認してください。

TUIC：QUIC接続と多重化

TUICもQUICを利用し、多重化などの仕組みでプロキシ通信を行います。認証項目、プロトコルの世代、輻輳制御、UDP転送方式をサーバーに合わせる必要があります。TUICという名称だけで、異なる世代間の互換性があるとは判断できません。インポート時に古い共有リンクが変換された場合は、接続できなくなってからDNSを何度も切り替えるのではなく、生成されたノードタイプと認証項目を確認してください。

QUICでは1つの接続上で複数のストリームを使えます。あるストリームでデータが失われても、同じTCPバイトストリームのように、後続の全データが必ずブロックされるわけではありません。ただし、各ストリームは接続全体の輻輳制御とネットワーク経路を共有します。多重化は完全な分離を意味せず、同時通信ごとに独立した帯域を確保する機能でもありません。モバイル端末がネットワークを切り替えるときも、QUICが移行に対応しているだけで通信が必ず継続するとは限りません。プロキシの実装、サーバー側の設定、OSの動作も結果に影響します。

プロトコル主な前提条件優先して確認する項目
VLESS対応するセキュリティ層と通信方式UUID、TLSまたはREALITY、flow
Hysteria2利用可能なUDP・QUIC経路認証、証明書、帯域設定
TUIC利用可能なUDPと対応するプロトコル世代認証項目、輻輳制御、転送方式

現在のネットワークでUDP通信が不安定な場合、QUIC系ノードではハンドシェイクのタイムアウトや断続的な切断が起きることがあります。端末の性能不足と判断する前に、接続できることが分かっているTCP系の方式と比較してください。一方、実際にパケットロスがあり、UDP経路が安定している環境では、Hysteria2やTUICもテスト対象になります。ただし、結論は実際の用途での結果から出してください。1回の接続テストだけでは判断できません。

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

「どのプロトコルが速いか」は、初回接続にかかる時間、ウェブページの表示開始、継続ダウンロードの速度、バックグラウンド接続のリソース消費に分けて考える必要があります。これらの指標は一致しないことがあります。継続的なダウンロードは速くても、ハンドシェイクに時間がかかり、短いリクエストが遅く感じられるノードもあります。逆に、速度テストの結果は平均的でも、普段のウェブ閲覧では安定するノードもあります。プロトコル以外に、サーバーの負荷やネットワーク経路も大きく影響します。

ハンドシェイク・スループット・実際の使い心地を分けて考える

初回のリクエストでは、ドメイン名の解決、サーバーへの接続、TLSまたはQUICのハンドシェイク、プロキシ認証、接続先への接続が発生する場合があります。接続の再利用やセッション再開により、2回目以降の負荷が軽減されることもあります。そのため、起動直後のテストと接続確立後のテストを混同しないでください。一方のクライアントでは接続がバックグラウンドで確立済みで、もう一方では起動直後の場合、最初のページ表示時間を比べても公平ではありません。テスト前に、接続を切るか、キャッシュを使うか、他の通信を並行して行うかを決めてください。

遅延テストの結果は通常、指定したURLに現在のプロキシグループでアクセスしたときの状況を示すだけです。動画、コードリポジトリ、大容量ファイル、リアルタイムアプリの性能をすべて表すものではありません。継続的な通信速度は、サーバーの回線、接続先の制限、輻輳制御、ローカル回線の帯域に左右されます。プロトコルだけを比べるつもりでも、ノードの地域や通信事業者が違えば、実際には経路の違いを比較している可能性があります。

プロセッサーとメモリの負荷要因

暗号化方式、ユーザー空間のネットワークスタック、データのコピー、接続数は、いずれもプロセッサーに負荷をかけます。QUICでは暗号化や通信処理をユーザー空間で行うことが多く、TCP系の方式とはリソースの使用状況が異なります。ただし、それだけで必ず電池消費が増えるとは言えません。実装の最適化、ハードウェア性能、通信量、パケットロスや再送によって結果は変わります。すでに回線の上限近くまで通信しているなら、CPU使用率の上昇は単に転送量が増えた結果かもしれません。

メモリ使用量はプロトコルだけで決まるものではありません。大きなルールセット、DNSキャッシュ、接続追跡、ログバッファ、GUIなども影響します。2つのクライアントを比べる際は、同じ設定、同じルールセット、近い接続数を使ってください。アイドル時の使用量が少なくても、多数の接続時にも省リソースとは限りません。使用量が増えた原因を調べるときは、GUIのプロセス、コアのプロセス、システムのネットワークサービスを分けて確認し、すべてをプロトコルのせいにしないようにしてください。

モバイル端末の電池消費とバックグラウンド動作

モバイル通信では、無線モジュールの動作状態が電池消費に大きく影響します。頻繁なハートビート、切断後の再接続、バックグラウンドでの接続テスト、短い間隔でのサブスクリプション更新などは、無線モジュールを長時間動作させることがあります。1回の通信量が少なくても、省電力になるとは限りません。頻繁に接続し直すより安定した接続を維持する方がよい場合もありますが、短すぎるキープアライブ間隔は端末の復帰回数を増やします。まずクライアントとサーバーの推奨設定を使い、システムの電池使用状況を見ながら調整してください。極端な設定例をそのまま流用するのは避けましょう。

スリープ、低電力モード、バックグラウンド実行の権限も測定結果に影響します。画面が消えると、OSがバックグラウンド処理を制限する場合があります。前面に戻したときの一時的な再接続は、必ずしもプロトコルの問題ではありません。iOSのネットワーク拡張とAndroidのVPNサービスでは、動作のライフサイクルも異なります。電池消費を比較する際は、Wi-Fiかモバイル回線か、画面の状態、通信時間、データ量を記録し、条件をそろえてからプロトコルを切り替えてください。

デスクトップではコアのログとシステムのリソースモニターを同時に確認し、モバイル端末ではOSの電池使用状況を参考にしてください。プロトコルを切り替えてスループットが上がった場合は、使用中の瞬間的な負荷だけでなく、同じタスクを終えるまでの総電力も比較します。初回接続の確認手順はノードの選び方、遅延測定、プロキシ有効化の確認をご覧ください。ここで紹介する手順は、プロトコルの比較にも役立ちます。

DNS・Fake-IP・ルール照合の関係

DNSはドメイン名からIPアドレスを取得し、ルールはリクエストをどのプロキシグループに渡すかを決めます。この2つは互いに影響します。ノードのハンドシェイクが成功してもウェブサイトにアクセスできない場合、原因は接続先ドメインの名前解決、ルールの一致、アプリのキャッシュにあるかもしれません。まず「プロキシサーバーのアドレスを解決する場合」と「通信先ドメインを解決する場合」を区別してください。前者はノードへ接続できるかに影響し、後者は通信やルールによる振り分けに関わります。それぞれ異なる経路で名前解決する場合があります。

Fake-IPはドメインと接続の対応関係を保持する

Fake-IPモードでは、アプリに対応付け用の仮想アドレスを返し、コアがそのアドレスとドメイン名の対応関係を保持します。その後の接続時には、対応表に基づいて処理します。ドメイン名の情報を維持し、接続先IPだけで通信の種類を推測する状況を減らすのに役立ちます。接続先の実際のアドレスを書き換えたり、ウェブサイトをローカルに移したりする機能ではありません。仮想アドレスはコアが接続を識別するための中間的な目印です。

Fake-IPで使うアドレスプールは、一般に専用のテスト用アドレス範囲から割り当てられ、通常のインターネット上のサービスアドレスではありません。アプリが名前解決の結果を長時間キャッシュしたり、ネットワークを切り替えた後も古い対応関係を使ったりすると、接続に問題が生じることがあります。まず対象のアプリを再起動し、アプリ側のDNSキャッシュを消去してから接続し直してください。ブラウザーの閲覧履歴やページキャッシュを消すだけでは不十分です。OSやアプリがそれぞれアドレス情報を保持している場合があります。

互換性の例外と名前解決の経路

一部のLAN機器の検出、実際のIPアドレスを必要とするアプリ、特定のネットワーク機器では、仮想アドレスをそのまま受け取ると問題が起きることがあります。その場合は、fake-ip-filterで対象ドメインを例外にできますが、除外項目を増やしすぎないでください。多数のドメインを一括で除外すると、対応付けを前提とした振り分け経路が変わり、問題の再現も難しくなります。実際に確認できた例外だけを追加し、どの問題を解決したのか記録してください。

以下は設定の構造を示す例であり、完全な設定ファイルではありません。DNSサービスはローカルのループバックアドレスだけで待ち受け、リゾルバーには明示的に暗号化DNSのアドレスを指定しています。アプリの問い合わせをこの設定に通すには、クライアントでシステムDNSを引き継ぐか、TUNのDNSハイジャックなどを使って問い合わせを誘導する必要があります。enable: trueと記述するだけで、すべてのアプリの名前解決経路が自動的に変わるわけではありません。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query

ルールの順序とTUNの適用範囲

通常、ルールは上から順に評価され、最初に一致したルールのポリシーが適用されます。ドメインルール、ルールセット、GEOIP、最後のMATCHの順序によって、リクエストの処理結果が変わります。先に範囲の広いルールに一致すると、後にある詳細なルールは実行されません。実IPアドレスへの名前解決が必要なルールもあれば、ドメイン名だけで判定できるルールもあります。そのため、ルールの順序を変えると、適用先だけでなく名前解決の回数や外部への接続経路も変わることがあります。

TUNは仮想ネットワークインターフェースを通じて対象の通信を処理し、アプリの通信をコアに渡せる範囲を広げます。ただし、すべてのDNSリクエストが想定どおり処理されるとは限りません。ブラウザー内蔵の暗号化DNS、アプリ独自のリゾルバー、ネットワーク上の別インターフェースなどを個別に確認してください。プロトコルの暗号化が保護するのは、そのプロトコルで接続する通信です。それだけでシステム全体の名前解決経路が統一されているとは判断できません。スイッチの状態だけでなく、実際の問い合わせと接続の記録を確認してください。

Fake-IPから実IPアドレスを返す方式に切り替えたら、影響を受けるアプリを再テストし、古いキャッシュにも注意してください。名前解決の経路を調べるにはDNS漏れテストとFake-IPの設定をご覧ください。ルールの照合順を調整する場合はカスタムルールの設定をご確認ください。DNSとルールを分けて検証すれば、振り分けの問題を特定のプロトコルの不安定さと誤認せずに済みます。

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

サブスクリプションURLは設定を取得するための入口であり、取得できる内容が統一された形式とは限りません。完全なClash YAMLを返すもの、ノード一覧だけを返すもの、複数行の共有リンクを返すもの、別のコア向けにJSONを出力するものがあります。クライアントにURLを登録できても、返された内容を正しく解釈できるとは限りません。インポートに失敗したら、ノードの期限切れやネットワークの異常を疑う前に、返された内容の形式と対応するコアを確認してください。

完全な設定・ノードサブスクリプション・共有リンク

完全な設定には、通常ポート、DNS、ノード、プロキシグループ、ルールが含まれ、読み込むだけで独立した接続環境を構成できます。ノードサブスクリプションが提供するのは主に接続情報で、プロキシグループやルールの設定には別途設定ファイルが必要です。単独の共有リンクは、通常1つのノードを記述するもので、通信の振り分けルールまでは定義しません。ノード一覧を完全な設定として起動すると、プロキシグループが不足することがあります。設定ファイル全体をプロキシプロバイダーとして読み込もうとすると、形式エラーが起きる場合があります。

mihomoでは、proxy-providersでプロキシの取得元を管理し、rule-providersでルールの取得元を管理します。両者は置き換えて使えません。プロキシグループからプロキシの取得元を明示的に参照し、ルールから該当するルールセットを参照する必要があります。ダウンロードが成功しただけでは、内容が正しく参照されているとは限りません。更新後に画面へノードが表示されない場合は、プロバイダーの解析、プロキシグループからの参照、名称の完全一致を確認してください。

変換だけでは設定の意味まで引き継げない

形式によって表現できる設定項目は異なります。変換ツールがサーバーや認証情報などの基本項目を引き継いでも、通信方式、REALITYの設定、UDPモード、特定プロトコルの項目が欠落することがあります。変換後の設定が構文チェックを通っても、元のノードと同じ動作になるとは限りません。新しいプロトコルでは、元の情報と設定項目を照らし合わせ、プロトコルタイプ、証明書関連の設定、パス、認証方式が既定値に置き換わっていないか確認してください。

サブスクリプションサービスは、リクエストの内容によって返す形式を切り替えることがあります。そのため、ブラウザーで表示した内容とクライアントが取得する内容は異なる場合があります。こうしたときは、URLのパラメーターを適当に組み合わせるのではなく、提供元が明示しているClashまたはmihomo向けのURLを使用してください。ログイン画面、エラーページ、その他のHTMLが返されると、クライアントはYAMLの解析エラーを報告することがあります。問題は取得した内容にあるため、ローカル設定のインデントを変更しても解決しません。

取得した内容一般的な用途互換性の確認項目
完全なClash YAML設定ファイルとして読み込むプロトコル、設定項目、ポリシー名
プロキシプロバイダー用YAMLproxy-providersから参照ノードの構造とプロバイダーの参照
単独の共有リンクノードを追加または変換変換後に設定項目がそろっているか
別のコア向けJSON対応するコアで読み込む拡張子を変えるだけでは使えない

設定の上書きと自動更新

クライアントでは、サブスクリプションの内容に加えて、ローカルの上書き設定、マージスクリプト、共通設定が適用される場合があります。元ファイルに書かれたDNSの値が、実行時には画面上の設定で書き換えられていることもあります。原因を調べるときは、サブスクリプションの内容、クライアントが生成した実行設定、コアのログを区別してください。自動ダウンロードされたファイルを直接編集すると、次回の更新で変更が上書きされる可能性もあります。長期的に使うルールは、クライアントが正式にサポートする上書き設定やカスタム設定欄に記述してください。

サブスクリプションの更新間隔は、内容の変更頻度とモバイル端末でのバックグラウンド動作を考慮して決めてください。頻繁に更新しても信頼性が上がるとは限りません。取得先に問題があると、通信やログが増えることがあります。更新に失敗した場合は、直近で使えていた設定を残し、エラーの原因を確認してください。すぐにファイルをすべて削除する必要はありません。サブスクリプションURLにはアカウント情報が含まれることがよくあります。画面の共有や問い合わせ時は、URL全体、認証情報、個人用ノードの情報を隠し、他人にアクセス権を渡さないようにしてください。

サブスクリプションの初回追加と更新方法はサブスクリプションURLの追加をご覧ください。古い設定からmihomoへ移行する場合は、新しい設定項目を作成し、元の項目も比較用に残したうえで、上書きルールを少しずつ戻すことをおすすめします。手動変更が自動更新で上書きされるのを防ぎ、どの層で互換性の問題が生じたかを見つけやすくなります。

端末と用途に合わせたプロトコル選び

まず「どの通信を取り込みたいか」を考え、次に「サーバーへの接続にどのプロトコルを使うか」を決めます。クライアントのプラットフォーム、権限、サーバーの構成、ネットワーク経路はその前提となります。サーバーが特定のプロトコルしか提供していないなら、別のタイプを画面から試すのではなく、その方式にクライアントが完全に対応しているか確認してください。選択肢が複数ある場合に限り、接続の確立、パケットロスへの対応、電池消費、管理のしやすさを比較します。

デスクトップでのウェブ閲覧と開発ツール

一般的なウェブ閲覧やドキュメントの利用には、設定が整い証明書が正しいTCP系の方式から試すとよいでしょう。SS、VMess、Trojan、VLESSはいずれも選択肢になり得ます。重要なのは、通信経路が安定し、ルールが明確であることです。開発ツール、パッケージマネージャー、ターミナルのアプリは、デスクトップのシステムプロキシを使わない場合があります。HTTP/SOCKSプロキシや環境変数を個別に設定する必要があることもあります。ブラウザーでは接続できてもコマンドラインで失敗する場合は、すぐにノードのプロトコルを変えず、まず通信の入口を確認してください。

WindowsとmacOSでは、まずClash Plusを試し、使い方に応じてClash Verge RevやFlClashも比較できます。WindowsではClash Nyanpasuも選択肢です。アーカイブ版のClash for WindowsとClashX Metaは開発が終了しています。古い解説の画面に見覚えがあるからという理由だけで、新規インストールの標準として選ぶのではなく、過去の互換性情報として扱ってください。各プラットフォームのダウンロード先とインストール方法はクライアント一覧で確認できます。

モバイル端末での日常利用

モバイル端末では、バックグラウンド動作、ネットワークの切り替え、電池消費を考慮してください。AndroidではClash Plus、Clash Meta for Android、FlClash、Surfboardの設定対応を確認できます。iOSではまずClash Plusを確認し、公式サイトclashplus.ioで製品情報をご覧ください。サブスクリプションの解釈方法はアプリによって異なる場合があります。移行の際は、ノード数だけでなく、プロキシグループとルールも確認し直してください。

モバイル回線とWi-Fiを頻繁に切り替える場合は、前面での速度測定だけでなく、画面消灯後の復帰、ネットワーク切り替え、バックグラウンドでの待機も確認してください。QUIC系の方式はUDP経路が安定している場合に試す価値がありますが、標準の省電力方式ではありません。端末によっては、安定したTCP系接続の方が適する場合もあります。必要のない頻繁な接続テストを無効にし、プロトコル名だけで判断せず、OSの電池使用状況を確認してください。

パケットロスの多い環境・リアルタイム通信・リソースの限られた端末

パケットロスが多い経路では、Hysteria2やTUICを現在のTCP系方式と比較できます。サーバーの場所と通信の対象をできるだけそろえ、ウェブページの応答、継続的なデータ転送、並行する通信を確認してください。転送速度を上げた結果、音声通話の品質が低下する場合は、端末内のキューや帯域の競合が考えられます。まず輻輳と速度の設定を確認してください。ゲームや音声通話などのUDP通信では、サーバーが転送に対応しているか、ルールが正しく適用されているか、接続先まで通信できるかも確認が必要です。

サーバー、ルーター、省電力端末では、プロセッサー性能、メモリ、長期運用の保守が特に重要です。mihomoコアを直接使えますが、サービス、権限、ログ、設定の更新は自分で管理する必要があります。アーキテクチャを合わせてください。デスクトップ用のインストールパッケージをルーターのコアとして使うことはできません。LinuxデスクトップではClash Verge RevやFlClashを検討すると、システムとの連携を手作業で設定する負担を減らせます。対応アーキテクチャはダウンロードセンターのコア一覧をご覧ください。

用途優先条件確認するポイント
ウェブ閲覧と開発安定した経路、完全な設定アプリがプロキシを使っているか
モバイル端末の待機バックグラウンド権限、適切なキープアライブ画面消灯後の復帰と電池使用状況
パケットロスのある経路UDPが利用可能ならQUICを比較継続的な通信と並行する操作
サーバーとルーターアーキテクチャの適合、リソース管理サービスの管理と長期的な安定性

システムプロキシとTUNは通信を取り込む方式の選択であり、プロトコルの優劣とは別の問題です。アプリのリクエストがコアに渡らなければ、どんなに優れたノードを使っても接続には使われません。2つの入口を比較する場合はTUNモードとシステムプロキシの違いをご覧ください。まず通信が正しい経路に入っていることを確認し、実際のタスクの結果でプロトコルを選ぶ方が、単一の速度測定にこだわるより確実です。

接続確認と段階的なトラブル対処

トラブル時は、設定を読み込めるか、アプリの通信がコアに入っているか、どのプロキシグループが選ばれたか、ノードのハンドシェイクが成功したか、接続先へのリクエストが完了したかの順に確認します。一度に変更する項目は1つにし、元のエラー情報と使用できていた設定を保存してください。DNS、プロトコル、ルール、TUNを同時に何度も切り替えると、たまたま復旧しただけなのに解決したように見えることがあります。根本原因が分からず、次に同じ問題が起きたときに再現して対処することも難しくなります。

設定とローカルの通信経路を確認

コアが起動しない場合は、最初に表示された解析エラーと該当する設定項目を確認してください。YAMLのインデント、未対応のタイプ、存在しないプロキシグループの参照などが起動を妨げることがあります。最後に表示された「起動に失敗しました」だけを見て判断しないでください。mihomoコアを単独で使う場合は、次のコマンドでファイルを確認できます。GUIクライアントには通常、設定チェックやログの表示機能があります。実行中の設定ファイルはクライアントの管理ディレクトリにあり、最初に読み込んだファイルと異なる場合があります。

mihomo -t -f config.yaml

構文チェックに通ったら、アプリのプロキシポートとコアが実際に待ち受けているポートが一致するか確認してください。設定のmixed-portがローカルの7890であれば、次のコマンドでHTTPプロキシを明示的に経由してリクエストできます。これは指定した経路を確認するだけであり、すべてのアプリと用途の通信がコアに取り込まれていることを証明するものではありません。ローカルポートが異なる場合は実際の設定に合わせてください。コマンドには制御用ポートやDNSポートを指定しないでください。

curl --proxy http://127.0.0.1:7890 -I https://example.com

ルールの適用とノードのハンドシェイクを確認

ログに該当するリクエストがない場合は、アプリのプロキシ設定、TUNの権限、ルーティングを優先して確認してください。リクエストは記録されているのにDIRECTが選ばれている場合は、認証情報を変更するのではなく、ルールの順序とプロキシグループを確認します。プロキシグループが自動選択の場合は、バックグラウンドで選択ノードが変わって混乱しないよう、テスト時に実際に選ばれたノードを記録してください。再現テストでは、使えると分かっているノードを一時的に選択できますが、テスト後は元の設定に戻してください。

ハンドシェイクの失敗はエラーの種類に応じて対処します。認証エラーではパスワード、UUID、プロトコルタイプを確認します。証明書エラーではシステム時刻、サーバー名、信頼チェーンを確認します。接続タイムアウトではサーバーアドレス、ポート、ネットワークへの到達性を確認します。QUIC系ノードではUDP経路も調べてください。「接続が閉じられました」のような曖昧なログが出た場合は、サーバー構成と通信方式の設定も確認が必要です。ログの一文だけで、プロトコルが使えないと判断しないでください。

接続先の問題とネットワークスタックの問題を切り分ける

ノードの接続テストは成功するのに特定のウェブサイトだけ開けない場合は、そのドメインのDNS応答、適用ルール、接続先サービスの状態を比較してください。ウェブページはすべて開けるのにリアルタイムアプリだけ失敗する場合は、UDPへの対応、アプリ独自の接続方式、ルールを確認します。大きなリクエストや継続的な通信だけが失敗する場合は、経路のMTU、パケットロス、同時接続の制限も調べてください。これらは比較テストが必要です。タイムアウトを見ただけでMTUを変更したり、証明書検証を無効にしたりしないでください。

TUNを有効にすると失敗し、HTTPプロキシを明示したリクエストは成功する場合、少なくとも一部のプロトコル経路は動作しています。権限、ルーティング、DNSのハイジャック、他のネットワークソフトとの競合を確認してください。WindowsのUWPアプリではループバック接続の制限が関係することもあります。詳しくはUWPのループバック接続の問題をご覧ください。同じ通信を取り込むツールを複数同時に動かすと、入口の競合によって断続的な失敗が起こる場合があります。

修正後は、エラーログが消えたかだけでなく、実際の用途で確認してください。ウェブ閲覧、元々失敗していたアプリ、バックグラウンド復帰、ネットワークの切り替えを順に試し、ルールが想定どおり適用されていることを確かめます。原因調査のために一時的にフィルターを緩めた、モードを切り替えた、自動更新を無効にした場合は、各項目を元に戻してください。一時設定を残すと、次回の更新やトラブル対処が複雑になり、必要な通信の振り分けが変わる可能性があります。

このページでは、接続経路を説明できること、設定の取得元を追跡できること、機能の範囲が明確であることを、最終的な判断基準としています。初回接続については引き続き使い方ガイドをご覧ください。よくある問題はFAQで確認できます。プロトコル選びは、名称を一度選んで終わるものではありません。コアの対応状況、サーバーの設定、実際のネットワーク環境を踏まえ、検証できる組み合わせを選ぶことが大切です。