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

1. プロトコル、トランスポート、トラフィックの取り込み方

接続を構成する各層を理解する

Macクライアントに表示される接続先の名称には、複数の技術要素が関係しています。最も内側にあるのは、ブラウザーのウェブアクセスやターミナルからのコードリポジトリ接続など、アプリが発生させる通信です。クライアントはまず通信を取り込むかどうかを判断し、ルールに従ってポリシーグループを選択した後、接続先を通じてサーバーに要求を送ります。プロキシプロトコルは、クライアントとサーバー間の認証、接続先アドレスの指定、データの転送方法を定めます。一方、TCP、UDP、TLS、WebSocket、HTTP/2、QUICは、それぞれ異なる階層のトランスポートやセキュリティ技術です。これらを同じ階層の互換プロトコルとして扱うと、設定の追加やトラブルシューティングで判断を誤りやすくなります。

たとえばVLESSは複数のトランスポートと組み合わせられますが、サーバー側がWebSocketを使う場合、正しいアドレスとユーザーIDを入力するだけで、通常のTCPに自由に変更できるわけではありません。パス、リクエストヘッダー、TLSの有効化、サーバー名などが接続の確立に関係することがあります。画面に表示されるプロトコル名が示すのは、通常そのうちの一つの階層だけです。互換性を確認するには、プロトコル、トランスポート、セキュリティ設定、拡張オプションをまとめて確認してください。サブスクリプションにこれらの項目が含まれている場合は、元の値を維持し、複数のサーバー設定をネット上の手順を参考に混ぜないようにしましょう。

システムプロキシ、TUN、プロトコルはそれぞれ別の機能

システムプロキシは、macOSの設定に従うアプリに対し、接続をローカルプロキシポートへ送るよう指示します。TUNは仮想ネットワークインターフェースを作成し、ルーティングによって対象の通信を取り込みます。どちらも通信をクライアントに渡す方法を決めるもので、サーバーへの接続にSSとTrojanのどちらを使うかは決めません。同じ接続先をシステムプロキシ経由でもTUN経由でも利用できます。そのため、ターミナルから接続できないときにプロトコルを変更しても、問題が解決するとは限りません。そもそも要求がクライアントに届いていない可能性があります。まず接続ログを確認し、取り込み、ルール、接続先のどの段階に問題があるかを切り分けてください。

ルールモード、グローバルモード、ダイレクトモードもプロトコルではありません。ルールモードはドメインやアドレスなどの条件に応じて接続先を選択します。グローバルモードは取り込んだ通信を共通のポリシーに渡し、ダイレクトモードでは通常、通信を接続先へ直接送ります。グローバルモードを有効にしても、システムプロキシに従わないアプリが自動的に取り込まれるわけではありません。一方、TUNで通信を取り込んだ場合もルールによる振り分けができ、すべての要求をリモートサーバーに送る必要はありません。詳しい設定手順はmacOS TUN拡張モードの解説を参照し、権限とルーティングを確認してください。

セキュリティ機能と利用条件をあわせて確認する

暗号化、サーバー認証、設定情報の保護は、それぞれ異なる問題に対処します。TLSを使っているからといって証明書の検証を無効にしてよいわけではありません。ランダムな識別子を設定していても、サブスクリプションのURLを公開してよいわけではありません。プロトコルを選ぶ前に、サーバーの提供元、証明書の信頼性、サブスクリプションの入手経路を確認してください。プロキシサーバーには接続先や通信時刻などが見える場合がありますが、通信内容の保護はアプリ側のHTTPS暗号化も担っています。接続を一時的に成功させるために、証明書の検証を長期的に無効にしないでください。

以降の比較を読む際は、「プロトコルの仕様上できること」と「現在の実装が対応していること」を区別してください。UDP転送の仕様があるからといって、すべてのサーバー、プラグイン、サブスクリプション変換ツールが完全に対応しているとは限りません。クライアント画面のスイッチを有効にしても、サーバーにない機能が使えるようになるわけではありません。実際の選択では、利用中のコアの対応範囲、サーバーの要件、接続ログを確認してください。名称に技術用語が多く含まれているかどうかで判断しないことが大切です。

2. ShadowsocksとVMessの設計上の違い

Shadowsocks：暗号化転送を中心としたシンプルな構成

ShadowsocksはSSとも呼ばれ、クライアントとサーバーの間に認証付き暗号化トンネルを確立して通信を転送する設計です。基本設定は通常、サーバーアドレス、ポート、暗号化方式、パスワードを中心とし、必要な項目が比較的まとまっています。サーバー情報が明確で、トランスポートの組み合わせを増やしたくない場合に向いています。初期のストリーム暗号方式と後発のAEAD方式には、安全性と互換性の違いがあります。「SS」と記載された接続情報がすべて同じ実装とは限りません。設定項目の少なさよりも、現在のコアとサーバーの両方が対応する方式を選ぶことが重要です。

従来のAEAD方式とShadowsocks 2022は、暗号化方式の名称を変更するだけでは相互接続できません。後者には鍵の形式や長さ、プロトコル処理に関する要件があり、クライアントとサーバーの設定を一致させる必要があります。サブスクリプションの追加後に鍵の長さが合わないと表示された場合は、鍵を切り詰めたり文字を補ったりせず、元の設定と方式を確認してください。一部のSS設定はプラグインにも依存します。プラグインは追加条件であり、すべてのクライアントで同じプログラムを実行できるわけではありません。MacのGUIが基本的なSS項目を読み込めても、外部プラグインの実行環境があるとは限りません。

SSは基本構成がシンプルですが、どのネットワークでも速いとは限りません。暗号化方式のハードウェアアクセラレーション対応、サーバー負荷、単一接続でのパケットロス、ローカルネットワークの品質によって結果は変わります。UDP転送にもサーバー側の対応とクライアント設定との一致が必要です。ウェブページは開けるのに音声通話やゲームが失敗する場合は、UDP対応、対象ルール、NATの挙動を個別に確認してください。TCPの要求が成功しただけで、接続全体が正常と判断しないようにしましょう。

VMess：認証と組み合わせ可能なトランスポート

VMessはV2Rayエコシステムで開発されたプロキシプロトコルで、ユーザー認証とデータ転送を中心に設計されています。接続先の設定では、ユーザーIDや暗号化オプションを指定するのが一般的です。複数のトランスポートと組み合わせられる一方、SSの基本構成よりも、各項目を一致させる必要があります。サーバーがTLSとWebSocketを使う場合は、ユーザーIDだけでなく、TLSのサーバー名、パス、必要なリクエストヘッダーも一致させてください。VMessプロトコルと外側のトランスポートはそれぞれ別の役割を担います。接続エラーを一括して「プロトコルの問題」とせず、各層を個別に確認しましょう。

古い解説には、以前の認証方式に関係する項目が記載されていることがあります。現在の設定では通常VMess AEADが使われ、旧式の組み合わせが最新のコアで受け付けられるとは限りません。古い画面写真に合わせて、廃止された項目を追加しないでください。システム時刻が大きくずれている場合も認証に影響することがあります。長期間オフラインだったMacでは、まずシステム設定の日付と時刻を確認しましょう。ログに認証失敗が記録されている場合は、時刻、ユーザーID、サーバー要件を確認します。証明書やトランスポートのハンドシェイクで止まっている場合は、該当する階層から対処してください。失敗したというだけでユーザーIDの誤りと決めつけないようにしましょう。

すでに安定したSSサーバーを利用していて、特殊なプラグインにも依存していないなら、別のプロトコルの設定項目が多いという理由だけで移行する必要はありません。VMessサーバーから保守された設定一式が提供されている場合も、まず元の設定を検証してから変更を検討しましょう。複雑な設定で得られる機能が必要なければ、設定する項目が増えるだけです。サーバーを変更できない一般ユーザーにとって大切なのは、自分でパラメーターを組み立てることではなく、サブスクリプションが現在のコアに適した形式で出力されているかを確認することです。比較用に、動作確認済みの接続先を一つ残しておきましょう。

3. Trojan、VLESS、TLS設定

Trojan：TLS接続内で認証を行う方式

Trojanは一般に、外側の安全な通信路としてTLSを使い、その中でパスワード認証とプロキシ要求を処理します。広く使われている証明書やTLSの仕組みを利用するため、設定項目はアドレス、ポート、パスワード、サーバー名にまとまって見えますが、実際の接続可否は証明書チェーン、ドメイン、サーバー構成に大きく左右されます。サーバーアドレスは接続先を特定し、TLSのサーバー名は認証などに使われます。両者が異なることもありますが、自由に入れ替えられるわけではありません。サブスクリプションにドメイン名が指定されている場合、IPアドレスに変更すると名前解決の結果が変わったり、証明書名の検証に失敗したりすることがあります。

クライアントのSNIまたはサーバー名は、HTTP Hostとは異なる項目です。前者はTLSハンドシェイクに関わり、後者はHTTPリクエストで使われます。WebSocketなどを外側に組み合わせる構成では、両方が個別に登場することがあります。すべての項目に同じドメインを機械的に入力しても、互換性が確保されるとは限らず、元の設定構造が分かりにくくなる場合もあります。証明書エラーが出たら、システム時刻、証明書の有効期間、中間証明書チェーンを確認してから、サブスクリプションに記載されたサーバー名を照合してください。証明書検証を常にスキップすると、サーバーの身元を確認する重要な保護が失われます。

VLESS：軽量なプロトコルと外側のセキュリティ層

VLESSもV2Ray関連エコシステムのプロキシプロトコルで、比較的シンプルな構成を採用しています。SSと同じ意味でのデータ暗号化機能は内蔵しておらず、通常はTLSなど明示的に設定されたセキュリティ層で通信を保護します。そのため、「VLESSは軽量」を「セキュリティ設定を減らせば速くなる」と解釈しないでください。サーバーがTLSを要求する場合、クライアント側も設定を一致させる必要があります。信頼できる外側の保護がない接続は、ユーザーIDを使っているだけで暗号化済みとは見なせません。ユーザーIDは認証に使うもので、通信内容を秘匿する仕組みではありません。

VLESSは複数のトランスポートや拡張機能と組み合わせられますが、対応範囲はコアの実装によって異なります。Reality関連の設定、クライアントフィンガープリント、フロー制御にはそれぞれ固有の条件があり、ある構成向けの手順をすべてのVLESS接続に適用することはできません。特にフロー制御は、どの環境でも使える速度向上スイッチではありません。サーバー、トランスポート構成、クライアント実装のすべてが条件を満たして初めて機能します。サブスクリプションにない公開鍵や短いIDをクライアント側で勝手に生成しても、接続できるとは限りません。これらの値は対応するサーバー設定から取得してください。

証明書の問題とプロトコルの問題を分けて対処する

TLS接続の失敗は、認証が始まる前に発生することがあります。証明書の期限切れ、名前の不一致、システムの信頼チェーンの異常、ネットワーク機器による干渉などは、TrojanやTLSを使うVLESSの接続を妨げる可能性があります。これらは必ずしもプロキシプロトコル自体の問題ではありません。通常のHTTPSサイトをブラウザーで開いても異常が起きる場合は、まずMacの時刻とネットワーク環境を確認してください。特定の接続先だけが失敗する場合は、サーバー設定を確認しましょう。エラーの分類についてはHTTPS証明書エラーの原因と対処法もご覧ください。問題を回避するために、出所の分からないルート証明書をシステムにインストールしないでください。

速度については、TrojanとVLESSの実際の差より、外側のTLS、トランスポート方式、サーバーのネットワーク環境の影響が大きいこともよくあります。初回ハンドシェイク、接続の再利用、輻輳制御、接続先サイトの応答時間も主要な要因です。一度ウェブページを速く開けたからといって、常に特定のプロトコルが優れているとは言えません。Macでは、設定項目がそろい、証明書が信頼でき、コアが明確に対応している構成を選び、同じネットワークと接続先で比較するのが効果的です。保守のしやすさもコストの一部です。更新のたびに設定項目を手作業で補う必要があるなら、既存の安定した構成より長期的な信頼性が低くなることがあります。

4. Hysteria2、TUICとUDPネットワーク環境

QUICは異なるトランスポート基盤を提供する

Hysteria2とTUICはどちらもUDPベースのQUIC技術を利用しますが、同じプロトコルではありません。種類の名称だけを書き換えて相互に読み込めるわけでもありません。QUICはセキュリティハンドシェイク、信頼性のあるストリーム、輻輳制御などを組み合わせ、複数のストリームを一つの接続で共有できます。これにより、ストリーム間でTCP層のHead-of-Line Blockingが起きる影響を抑えられます。ただし、各ストリーム内では引き続き順序どおりにデータを届ける必要があり、ネットワークの混雑は全体の帯域にも影響します。QUICがパケットロスをなくすわけではなく、回復やスケジューリングの方法が異なるだけです。利点を得るには、ネットワークがUDPを許可し、実装側も適切に対応している必要があります。

一部のゲストネットワーク、企業の無線LAN、テザリングでは、UDPが制限されたり、速度を抑えられたり、短いタイムアウトが設定されたりすることがあります。TCP系の接続が成功しても、QUIC系の接続が正常に使えるとは限りません。Macでは、まず動作確認済みのTCP系設定を比較用に残し、UDP経路の状態を調べてください。スリープ解除後だけ接続できなくなる場合は、NATマッピングの期限切れやクライアントの再接続動作も考慮し、認証情報の誤りと決めつけないようにしましょう。同じプロトコルでも家庭のネットワークと公衆ネットワークで結果が異なるのは、ネットワーク環境の違いとして説明できます。

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

Hysteria2は高遅延やパケットロスなどを含む環境での通信を想定しており、輻輳制御の具体的な動作はクライアントとサーバーの設定によって異なります。一部の設定では上りと下りの帯域を指定しますが、これは送信方法に影響する値であり、サーバーが保証する実効速度ではありません。下りの値を大きくしてもダウンロードが速くなるわけではありません。実際のボトルネックを大きく上回る値を設定すると、キューの増加やパケットロス、同じネットワーク上にある他のアプリへの影響につながることがあります。安定して維持できる回線速度を目安にし、他人の設定値をそのまま使わず、サーバー側の指定に従ってください。

HysteriaとHysteria2にはプロトコル世代の違いがあり、設定の種類名を変更するだけでは移行できません。認証項目、難読化オプション、トランスポート設定もそれぞれ対応させる必要があります。インポーターが旧プロトコルとして認識した場合は、まずmihomo向けの設定を再取得してください。クライアントに設定が保存されたという表示は、テキストが受け付けられたことを示すだけで、サーバーとのハンドシェイク成功を意味しません。接続ログを確認し、UDP接続、TLS検証、プロトコル認証のどの段階で失敗しているかを特定しましょう。

TUICの多重化とUDP転送方式

TUICもQUICを基盤とし、プロキシ接続の多重化やTCP・UDP通信の転送に対応します。世代の異なる実装では互換性がない場合があるため、認証項目と転送オプションをサーバー側に合わせてください。UDPの転送方式によっては、信頼性、即時性、カプセル化の負荷の間でトレードオフがあります。信頼性の高い転送が常にリアルタイム用途に適するとは限りません。音声通話やゲームでは、期限を過ぎてから届くデータに価値がないことがありますが、ファイル転送では完全な受信が重視されます。まずサーバーが推奨する方式を維持し、実際のアプリで動作を確認してください。

この2種類のプロトコルは候補として検討するもので、あらゆる環境での標準設定ではありません。ネットワークのUDP品質が安定していて、長距離通信でパケットロスの影響が明らかな場合は、比較テストを行う価値があります。UDPの利用可否が不明なネットワークや、複数のオフィスネットワークを頻繁に切り替える環境では、TCP系の代替接続を残しておきましょう。特定のトランスポート方式にこだわって、ネットワークを切り替えるたびに設定し直すことにならないようにしてください。

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

「速さ」を観察できる3つの指標に分ける

接続速度は少なくとも、接続確立までの時間、継続的な転送スループット、応答の安定性に分けて考えられます。ウェブ閲覧では初回応答や多数の小さなリソースをすばやく読み込めるかが重要です。大容量ファイルのダウンロードでは継続的なスループットが重視され、リモートターミナルや会議では遅延の揺れや切断の少なさが重要になります。遅延テストの値が低い接続先が、すべての用途で速いとは限りません。クライアントの遅延テストは通常、指定先への要求にかかる時間を測定します。単純な物理的往復時間ではなく、DNS、ハンドシェイク、接続先の処理などの時間も含まれます。

プロトコルを比較する際は、Mac、ネットワーク、接続先、テスト時間をそろえ、できるだけ同じ場所にあるサーバーと近いリソース条件を選んでください。異なるサーバーから取得した設定を比較する場合、測定されるのはプロトコルだけの差ではなく、通信経路全体の差です。連続してテストすると、キャッシュ、接続の再利用、サーバー負荷の変化も結果に影響します。初回表示、再アクセス、継続転送をそれぞれ記録しても、一度だけ出た最良の値を安定した性能と見なさないでください。日常の作業中にタイムアウトや再接続、目立った停止が繰り返されるかどうかのほうが、実用上は重要です。

CPU、メモリ、ネットワーク処理は単純に順位付けできない

CPU負荷は暗号化・復号、プロトコル解析、データコピー、ネットワークスタックの処理によって発生します。AppleシリコンとIntelではアルゴリズムごとのハードウェアアクセラレーションの効果が異なり、クライアントのビルド方法も結果に影響します。TUNでは仮想インターフェースと通信処理が追加されます。DNS、ルール判定、接続ログ、詳細ログもリソースを使用します。そのため、TUNを有効にした後の電池消費の変化をすべてプロトコルのせいにすることはできません。また、異なるGUIクライアントのメモリ使用量をそのまま比較して、背後のプロトコル効率を判断することもできません。

macOSの「アクティビティモニタ」では、クライアントと関連するコアプロセスのCPU、メモリ、エネルギー使用量をあわせて確認できます。テスト中は同じ作業を続け、一方で大容量ダウンロードを行い、もう一方でアイドル状態にするといった比較は避けてください。メモリ使用量が増え続ける場合は、プロトコルのメモリリークと決めつける前に、接続数、ログ量、サブスクリプションの規模を確認します。高速転送時だけCPU使用率が上がるなら、通常の処理負荷である可能性があります。アイドル時も高負荷が続く場合は、再接続の繰り返し、DNSリクエストの異常、ルーティングループを調べ、症状に応じてヘルプセンターも確認してください。

モバイル端末の電池は無線の起動と接続状態にも左右される

モバイル端末の電池は暗号化処理だけで消費されるわけではありません。携帯電話の無線モジュールが動作する時間、キープアライブの頻度、バックグラウンドでの再接続、電波強度、NATタイムアウトなどが、より大きな割合を占めることもあります。長時間接続を維持すればハンドシェイクの繰り返しを減らせますが、キープアライブが多すぎると無線の起動回数が増える場合があります。UDPベースの方式も、ネットワークによって安定することもあれば、セッションの再確立が頻繁に必要になることもあります。SS、Trojan、QUICなどの名称だけで一律の省電力ランキングを作ることはできません。MacのCPUテスト結果をそのままスマートフォンに当てはめないでください。

Macがスマートフォンのテザリングで接続している場合は、テザリング端末も独立した電力消費要因として考慮しましょう。大容量通信では、Macのネットワーク処理負荷とスマートフォンの無線負荷が同時に高まることがあります。日常利用の設定を選ぶなら、帯域を最大化するテストだけでなく、よく使う作業やスリープからの復帰も確認してください。不要な速度テスト、頻繁すぎるポリシーグループのチェック、デバッグログを減らすほうが、プロトコルを変更するより効果的な場合もあります。チェック間隔もむやみに短くしないでください。障害を早く検出できる一方で、バックグラウンド通信が増えます。実際の切り替え頻度に応じて調整しましょう。

用途ごとに異なるポリシーグループを使う設計も可能です。ウェブ閲覧、開発ツール、リアルタイムアプリに同じ接続先が適しているとは限りませんが、グループを分ける目的は明確にし、検証のためにルールを細分化しすぎないようにしましょう。まず安定した基準を作り、具体的な問題に対して候補を一つずつ追加します。プロトコル、DNS、TUN、ポリシーグループを同時に変更するより、信頼できる結果を得やすくなります。

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

コアは設定を実行し、GUIクライアントは管理を担う

Clashエコシステムのコアは、設定の解析、ルールの照合、ネットワーク接続の処理を担います。GUIクライアントは、メニューバー、サブスクリプション管理、システムプロキシ、権限設定、設定画面を提供します。両者には関係がありますが、同じものではありません。Clash Plus、Clash Verge Rev、FlClashなどはユーザーが選ぶクライアントであり、実際に使えるプロトコルは、組み込まれている、または呼び出されるコアによって決まります。クライアントの画面が更新されても、すべてのプロトコル実装が同時に更新されるとは限りません。ダウンロードと選び方はインストーラーページで確認してください。初めて設定する場合はClash Plusから始めるのがおすすめです。

オリジナルClashは、接続先、ポリシーグループ、ルールなどを含む、広く使われるYAML設定の基礎を築きました。オリジナルのオープンソースコアと、過去の別配布版を同じものとして扱うことはできません。各派生版の機能は完全には一致しません。Clash Metaは関連エコシステムを基盤にプロトコルやネットワーク機能を拡張し、後にmihomoの名称が使われるようになりました。サブスクリプションや解説にMetaと記載されている場合、多くはこの系譜を示しており、別途「Metaプラグイン」をインストールする必要があるという意味ではありません。名称の変遷は情報の背景を理解する手がかりになりますが、実際の機能確認に代わるものではありません。

基本構造が似ていても、すべての項目が相互に互換とは限らない

mihomoは多くのClash設定構造を引き継ぎながら、プロトコルの種類、ルール機能、ネットワーク設定を追加しています。オリジナルのコアが新しい接続方式を認識できない場合、それは機能の対応範囲によるもので、必ずしもYAMLのインデントが間違っているわけではありません。反対に、古い設定を新しいコアへ移す際も、項目の廃止、デフォルト動作の変更、検証の厳格化が影響することがあります。設定を読み込めたら終わりではありません。ルールが意図どおりに適用されるか、DNSが正しく動くか、ポリシーグループの参照先が有効か、TUNが対象アプリの通信を実際に取り込んでいるかも確認してください。

移行する前に、現在動作している設定とクライアント設定を保存してください。次に、新しいクライアントが読み込むものが元のサブスクリプション、統合後の設定、エクスポートした実行用設定のどれかを確認します。これらは同じとは限りません。GUIクライアントがコアの起動前にポート、DNS、コントロールインターフェース、TUNの設定を書き換えることもあります。古い実行用ファイルをそのままコピーすると、新しい環境に適さない設定まで持ち込む場合があります。まずクライアントの標準ネットワーク設定でサブスクリプションを追加し、基本接続を確認してから、カスタムルールや上書き設定を一つずつ戻してください。複数の原因を同時に持ち込まないことが大切です。

小さな設定で構文とデフォルト値を確認する

以下はmihomo設定の汎用項目例で、モード、ポート、ログレベルを理解するためのものです。リモート接続先は含まれていないため、単独ではプロキシ接続を確立できません。統合する前に、設定全体に同じトップレベルキーがないか確認し、重複定義を避けてください。混合ポートはローカルのHTTPとSOCKSの両方の入口を提供します。ポート番号は現在のクライアントの実際の待ち受け設定に合わせてください。これはリモートサーバーのポートではなく、すべてのクライアントが同じ値をデフォルトで使う保証もありません。

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

ログに不明なプロトコルの種類が表示されたら、まずコアがその種類に対応しているか、サブスクリプションが正しい形式で出力されているかを確認してください。ポリシーや接続先が見つからない場合は、参照関係とサブスクリプションのフィルター設定を確認します。設定が動作してもルールが適用されない場合は、ルールの順序とクライアントの上書き設定を確認してください。詳しい違いはmihomoとオリジナルClashの機能比較をご覧ください。すべてのエラーを「コアが古い」と決めつけたり、バックアップなしで設定ファイル全体を何度も置き換えたりしないでください。

Appleシリコン用とIntel用のインストーラーの違いは、プログラムのアーキテクチャに合わせるためのもので、プロトコルの違いではありません。Macのアーキテクチャに適したビルドを選ぶことで、不要な変換処理を避けられますが、プロトコルが利用できるかどうかは引き続きコアの実装に依存します。ClashX Metaなどのアーカイブ版クライアントは既存環境の参考にはなりますが、長期利用ではメンテナンス状況とmacOSとの互換性も考慮してください。外観だけでなく、保守が継続され、コアの状態を確認しやすいクライアントを選ぶと、設定上の問題にも対処しやすくなります。

7. Clash YAML、ノード一覧、サブスクリプション変換

サブスクリプションURLだけでは内容の形式は分からない

サブスクリプションリンクは設定データを取得する入口です。取得される内容は、完全なClash YAML、接続先一覧だけのYAML、エンコードされた共有リンク集、sing-box JSONなどの場合があります。URLの拡張子やリンク名だけでは形式を判断できません。サービスによっては、リクエストのパラメーターやクライアントの識別情報に応じて異なる内容を返すこともあります。追加に失敗したら、ダウンロード、内容の解析、実行時の検証のどの段階でエラーが起きたかを確認してください。ダウンロードは成功してもHTMLが返された場合、ログインページ、エラーページ、アクセス案内などの可能性があります。YAMLの構文エラーとは限りません。

完全な設定には通常、接続先、ポリシーグループ、ルール、その他の実行設定が含まれます。ノード一覧には接続に必要な項目だけが含まれる場合があります。クライアントが一覧を読み込めても、すべてのユーザーに適した振り分けルールまで含まれているとは限りません。不足項目を独自テンプレートで補うクライアントもあれば、ユーザーによる明示的な指定が必要なクライアントもあります。追加後に接続先は表示されるのに、期待したポリシーグループがない場合は、サーバーパスワードを入力し直すのではなく、サブスクリプションの種類とテンプレートを確認してください。設定の網羅性と接続先の数は別の問題です。

エンコード、変換、統合の違い

Base64はエンコード方式であり、暗号化でもプロキシプロトコルでもありません。エンコードされたデータには、SS、VMess、Trojanなどの共有リンクが含まれることがあり、各リンクに個別の設定項目が記載されています。テキストをデコードしても元の表現が戻るだけで、ルールやDNS、ポリシーグループが自動生成されるわけではありません。共有リンクの規格によって表現できるパラメーターも異なり、新しい拡張項目が古いパーサーで読み込めない場合があります。あるクライアントで追加できたリンクが、すべてのクライアントでまったく同じように解釈されるとは限りません。

サブスクリプション変換ツールは、あるデータ形式を別の形式に変換し、テンプレートの適用、名前の変更、フィルタリングなどを行うことがあります。変換先の形式に対応項目がない場合、特定のトランスポート拡張、フィンガープリント設定、ポリシーグループの動作、DNSルーティングの意味などが失われることがあります。sing-box JSONとClash YAMLは括弧やインデントが異なるだけではなく、トップレベルの構造や動作モデルも一部異なります。ファイルの拡張子を変更したり、項目名を逐語的に置き換えたりしても、信頼できる設定にはなりません。変換後は実際に使うコアで検証してください。

プライバシーと更新時の上書きを事前に確認する

サブスクリプションには接続に使える認証情報が含まれていることが多く、URL自体にアクセス用の認証情報が含まれる場合もあります。完全なURLを公開スクリーンショットやオンラインの相談先、信頼性を確認できない変換サービスに貼り付けないでください。外部の変換サービスを使うと、第三者がサブスクリプションの内容を扱う可能性があります。提供元からmihomoまたはClash Meta向けの形式が用意されている場合は、中間変換を減らすためにその形式を優先してください。技術的な相談では、エラーの種類、プロトコル、認証情報を伏せた設定構造だけを共有すれば十分です。パスワード、ユーザーID、サブスクリプションURL全体を公開する必要はありません。

設定の保守には更新方法も関係します。サブスクリプションが生成したファイルを直接編集すると、次回の更新で変更が上書きされることがあります。ローカルルールの保存には、クライアントの上書き、統合、拡張機能を使うほうが適しています。ただし、クライアントごとに統合の順序は異なり、リストを追加すると重複や順番の変化が起こる場合もあります。どの項目をサブスクリプションが管理し、どの項目をクライアントが管理するかを確認してから、変更する場所を決めてください。特にルール一覧では、前方の広い条件に一致すると、後方の細かいルールが適用されなくなることがあります。

更新後に一部の接続先だけが表示されなくなった場合は、フィルター条件、名前変更のルール、プロトコル対応を確認してください。すべて表示されない場合は、返された内容とダウンロード状態を確認します。更新に成功しても動作が変わった場合は、テンプレートや上書き設定も同時に変わっていないか調べましょう。認証情報を含むファイルを共有用の同期フォルダーに何種類も保存するのではなく、個人情報を除いた項目一覧を前後比較用に残す方法が安全です。よく使われる3形式の変換上の注意点はサブスクリプションリンクの形式と変換で確認し、変換が必要か判断してください。

8. 用途別の選び方と段階的な検証

安定した基準を作ってから、他のプロトコルを試す

一般的なウェブ閲覧やオフィスでの利用では、サーバー情報がそろっていて、現在のネットワークから安定して接続でき、クライアントが明確に対応している接続先を優先してください。成熟したSS、Trojan、VMess、正しく設定されたVLESSはいずれも候補になります。すべてを特定のプロトコルへ置き換える必要はありません。現在の設定が普段使うネットワークで安定しているなら、移行は具体的な問題を解決するために行いましょう。たとえば、特定のトランスポートが制限される、証明書の保守が難しい、アプリにUDPが必要といったケースです。名称の新旧だけで判断せず、既存の設定を残して新しい方式と比較できるようにしてください。

開発ツールを使う場合は、まず通信の入口を確認してください。ブラウザーは使えてもターミナルから接続できないときは、ツールがシステムプロキシを参照しているかを確認し、必要に応じてツール独自のプロキシ設定や環境変数を指定してから、TUNの利用を検討しましょう。最初にプロトコルを変更して速度テストを繰り返しても、要求がクライアントに届いていなければ解決しません。macOSのターミナルで次のコマンドを実行すると、現在のシステムプロキシ情報を確認できます。このコマンドはリモートプロトコルを検証するものではなく、コマンドラインツールがその設定に従うことを保証するものでもありません。実際の待ち受けポートはクライアントの設定画面で確認してください。

scutil --proxy

リアルタイム会議、音声通話、ゲームでは、UDP転送、遅延の揺れ、切断後の復帰を重視しましょう。まずアプリの通信が取り込まれているかを確認し、その後ルールの適用状況と接続先のUDP対応を調べます。Hysteria2やTUICも候補になりますが、ネットワークがUDPを許可し、サーバー設定が一致する場合に比較する価値があります。家庭、オフィス、ゲストネットワークを頻繁に切り替えるMacでは、TCP系の代替接続を残しておくほうが実用的です。ポリシーグループのヘルスチェックで分かるのはテスト対象への接続状況であり、すべてのアプリが使えるという保証ではありません。

一つの作業を決めて検証を完了させる

設定を変更するたびに、同じ接続先と同じ操作で確認してください。まずクライアントで設定の読み込みが成功していることを確認し、次に対象のアプリを開いて接続ログが記録されるかを見ます。ログがない場合は、システムプロキシ、TUNの権限、アプリ独自の設定を確認してください。ログがあるのに誤ったポリシーを通る場合は、ルールの順序とドメインの名前解決を調べます。ポリシーが正しいのにハンドシェイクに失敗する場合は、プロトコル、認証、証明書、ネットワーク経路を確認しましょう。こうして「インターネットに接続できない」という問題を段階ごとに切り分ければ、DNS、ポート、プロトコルを同時に変更せずに済みます。

復旧方法と代替接続も選定の一部

Macを閉じてから再び開くと、クライアントがインターフェース、ルート、接続を復旧する必要が生じることがあります。スリープ解除後だけ失敗する場合は、まずネットワークが復旧したことを確認してください。そのうえで、動作確認済みの接続先に切り替えるか、クライアントの接続を再確立し、ログを確認します。繰り返し失敗する場合は、サービスの権限、ネットワーク拡張機能、ほかのVPNが同時にルートを変更していないかを調べましょう。複数の通信取り込みツールを同時に動かすと、ループや優先順位の競合が起きることがあります。プロトコルの変更だけでは解決できません。クライアントを終了した後は、システムプロキシが停止済みのローカルポートを参照したままになっていないかも確認してください。

最終的には、現在のコアが対応していること、サーバー設定がそろっていること、普段のネットワークから接続できること、実際の作業で安定することの4点で候補を絞りましょう。条件を満たしたうえで、性能と電池消費を比較してください。新しい構成の維持に多くの手作業が必要なら、その保守コストも選定に含める必要があります。初回のインストールはクイックスタートに沿って進めてください。具体的な症状はヘルプセンターで確認できます。見慣れない用語は用語集で調べてください。このプロトコルガイドは判断の枠組みを示すもので、最終的には実際のMac、現在のネットワーク、利用するアプリで再現できる結果を基準にしてください。