事前確認：クライアントと設定の入手先を確認

このガイドでは、クライアントのインストールが完了していることを前提に説明します。まず通常どおりアプリを開き、設定画面またはバージョン情報でクライアント名とコアの種類を確認してください。クライアントは画面やサブスク管理、システム設定を担当し、コアは設定の解析、ルールの照合、接続の確立を担います。アプリが開いたことだけでは、コアが有効な設定を読み込んだことや、ほかのアプリの通信がプロキシに流れていることは確認できません。

サービス提供元から発行された有効なサブスクリプションURL、または完全なローカルYAML設定を用意します。クライアント自体に利用可能なリモートプロキシサービスは付属していません。クライアントだけでノードや有効な設定がなければ、リモートプロキシには接続できません。サブスクリプションURLにはアカウント情報が含まれることがあるため、信頼できるクライアント以外には貼り付けず、スクリーンショットや公開ログ、オンライン変換サイトに載せないでください。

初回の操作では、まずネットワーク通信を取り込んでいるほかのプロキシやVPNツールを終了し、テスト経路をシンプルにします。システムプロキシを手動で変更したことがある場合は、終了後に戻せるよう元の設定を記録してください。その後はクライアントの画面を表示したまま、以下の手順を順番に進めます。原因の切り分けが難しくなるため、DNS、TUN、ルーティング、ルールを同時に変更しないでください。

Clash Metaとmihomoの表記の違い

Clash Metaはこのコア系列の旧名称で、プロジェクト名は後にmihomoへ変更されました。そのため、一部のクライアントにはMetaという表記が残っています。旧名称が表示されても、別のクライアントをインストールする必要はありません。現在のアプリが実際に使用しているコアと、対応する設定項目を確認してください。サブスクにVLESSやHysteria2などが含まれ、読み込み時に未対応プロトコルと表示される場合は、接続ボタンを何度も押すのではなく、まずコアの互換性を確認します。プロトコルとコアの関係はプロトコルリファレンスをご覧ください。

手順1：サブスクを追加して設定を有効にする

クライアントのサイドバーまたは下部ナビゲーションから「サブスクリプション」「設定」「Profiles」のいずれかを開きます。「追加」「インポート」またはプラス記号の項目を選び、接続元にリモートURLを指定して、サブスクリプションURLを最後まで貼り付けます。URLは通常 https:// で始まります。コピー時はクエリパラメーターを残し、チャットアプリの説明文、改行、前後の空白を取り除いてください。名前は「普段使い」など、見分けやすいものにできます。名前はクライアント上の表示だけに使われ、サブスクの内容には影響しません。

ダウンロード、保存、インポートなどのボタンを押し、設定カードに成功状態が表示されるまで待ちます。「URLを保存」と「設定を更新」が別の操作になっているクライアントでは、ノードとプロキシグループが実際に取得されるまで更新も実行してください。設定名が一覧に表示されただけで次へ進まないようにします。URLだけ保存され、通信に失敗しても空のカードが残るクライアントがあります。詳細を開いて解析エラーがないこと、プロキシ画面にサービス提供元のプロキシグループが表示されていることを確認してください。

続いて設定カードを選び、現在使用する設定として有効にします。現在の設定は、枠のハイライトやチェックマーク、「有効」ボタンなどで示されます。クライアントによっては、選択するとコアがすぐに再読み込みされます。プロキシ画面にプロキシグループとノード一覧が表示されれば、追加と有効化が完了です。複数の設定を保存している場合は、ハイライトされているものが追加した設定か確認してください。新しいサブスクを更新しても、古い設定が動作し続けることがあります。

ローカルの .yaml または .yml ファイルを入手した場合は、「ファイルからインポート」を使います。ファイル名をリモートURLの入力欄に貼り付けないでください。ss:// や vmess:// で始まる文字列は、通常は単一ノードの共有リンクであり、プロキシグループ、ルール、DNSを含む完全なClash設定とは異なります。その形式にクライアントが明示的に対応している場合に限り、専用のノード追加機能を使用してください。

サブスクの更新と読み込みエラー

サブスクの追加後、設定の編集画面で自動更新の間隔を設定できます。更新間隔は設定を再取得するタイミングを決めるもので、サーバー側のノードが常に利用できることを保証するものではありません。手動で更新した後は成功メッセージを確認し、プロキシグループに戻って以前の選択が維持されているか確認してください。ダウンロードに失敗した場合は、URLの失効、アカウントの状態、現在のネットワークからサブスクURLにアクセスできるか、ダウンロード後の解析失敗かを切り分けます。原因によって対処方法が異なります。

解析に失敗した場合は、エラーに表示された項目名、プロトコル名、行番号を確認し、設定をまとめて削除しないでください。完全なサブスクは、通常、提供元に修正を依頼するか、mihomoに対応した形式を提供元の案内に従って選びます。サブスクの有効期限切れや更新後にノードが消えた場合は、よくある質問で引き続き確認してください。唯一使える設定を失わないよう、まず直前の有効な設定を残しておきます。

手順2：ルールモードと接続先ノードを選ぶ

設定を有効にしたら、「概要」「プロキシ」または「モード」画面を開き、動作モードを「ルール / Rule」にします。ルールモードでは、設定内のルールの順序に従って接続先が決まります。一部の接続は直接接続し、一部はプロキシグループを経由し、明示的に拒否された接続はブロックされます。この操作で決まるのは、すでにコアに届いた接続の処理方法です。通信をコアに取り込むには、次の手順でシステムプロキシなどを有効にする必要があります。

次にメインのプロキシグループを開きます。グループ名はサブスクの作成者によって異なり、「ノード選択」「プロキシ」などさまざまです。すべてのクライアントで共通する名称を探す必要はありません。グループを展開し、利用可能と分かっているノードを一つ選びます。接続性や遅延のテスト機能があれば、選択前に実行しても構いません。テスト結果は指定された宛先への疎通を示すもので、数値が表示されても、すべてのサイトやアプリが使えるとは限りません。

プロキシグループが別のグループを参照している場合もあります。メインのグループで「自動選択」を選ぶと、実際の出口はそのサブグループで決まることがあります。「手動選択」の場合は、該当するサブグループを開いてノードを指定してください。最終的に DIRECT が選ばれている場合、そのグループはリモートプロキシを経由せず直接接続します。初回の確認では、経路を特定しやすいノードを一つ固定し、正常に動作した後で自動選択に戻すと、切り分けが簡単です。

ルール・グローバル・直接接続の使い分け

「グローバル / Global」では、コアに届いた接続がグローバルポリシーに従います。クライアントを経由しないアプリの通信まで自動で取り込むわけではありません。「直結 / Direct」では、コアに届いた接続が宛先へ直接アクセスします。通常の利用では、まずルールモードのままにしてください。特定の宛先に問題がある場合は、比較のため一時的にグローバルへ切り替えます。グローバルでは正常でルールモードでは異常になる場合に、適用ルールとプロキシグループの選択を確認します。比較後はルールモードに戻し、テスト用の設定をそのままにしないようにしてください。

カスタムルールは追加場所を確認

初回接続時に、すぐルールを追加する必要はありません。特定のドメインの経路を指定する場合は、まずクライアントで「オーバーライド」「拡張設定」「ルール編集」などの項目を探し、変更が現在の設定だけに適用されるのか、すべての設定に適用されるのかを確認します。ダウンロードしたサブスクを直接編集すると、次回の更新で変更が上書きされることがあります。クライアントが対応する永続的な変更方法を優先し、保存後に最終的な設定内容を確認してください。

ルールは通常、上から順に照合され、最初に一致したルールのポリシーが適用されます。ルールを追加する場合は、対象を広くカバーするルールより前に置き、指定するポリシー名が実際に存在することを確認してください。たとえば DOMAIN-SUFFIX,example.com,DIRECT は、そのドメインとサブドメインを直接接続させる記述です。これは構文例であり、実際の設定に追加する必要はありません。より複雑なルールセットやDNSとの関係はプロトコル・コアのリファレンスで確認できます。まずは次の基本的な接続確認を行いましょう。

手順3：コアを起動して通信を取り込む

クライアントの概要画面に戻り、コアが起動中で、設定の読み込み失敗やポート使用中のエラーが繰り返し表示されていないことを確認します。アプリを開くとコアが自動で起動するクライアントもあれば、「起動」やメインの接続ボタンを押す必要があるものもあります。設定画面でローカルプロキシの待ち受けアドレスとポートを確認できます。実際の値は現在の設定に従い、すべてのクライアントで同じポートが使われるとは限りません。設定が有効と表示されていても、コアの起動に失敗している場合は、ノードを切り替えても待ち受けの問題は解決しません。

デスクトップでは先にシステムプロキシを使う

デスクトップ版クライアントで「システムプロキシ」を有効にし、システムプロキシ設定に従うブラウザーから新しいリクエストを送ります。通常、クライアントはシステムのHTTPプロキシをローカルの待ち受けポートに向けます。ブラウザーにプロキシを個別制御する拡張機能がある場合は、システム設定が上書きされないよう、まずその拡張機能を一時停止してください。開いたままのページでは接続が切り替わったか確認できません。ページを更新するか、新しいテストページを開いてください。

一部のコマンドラインツール、ゲーム、アプリはシステムプロキシ設定を参照しません。そのため、ブラウザーが使えても、それらの通信が直接接続される場合があります。必ずしもノードの障害とは限りません。まずアプリ独自のプロキシ設定があるか確認し、なければTUNの利用を検討します。アプリごとの通信範囲についてはTUNモードとシステムプロキシの違いをご覧ください。初回起動時にすべてのネットワーク機能を同時に有効にする必要はありません。

モバイルではシステム接続の許可を確認

モバイル版ではホーム画面の接続スイッチをタップします。初回起動時は、システムの案内に従ってVPN構成の作成またはVPN接続を許可してください。許可後にクライアントへ戻り、接続済みになっていることと、システムのネットワーク状態にVPN表示があることを確認します。この表示で分かるのはシステムトンネルが確立したことだけで、ノードの利用可否までは確認できません。別のVPNが動作中の場合は先に切断し、現在のクライアントで接続し直してください。

より多くのアプリを対象にする場合はTUNを有効にする

TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。デスクトップ版クライアントでは、サービスモードのインストール、管理者権限の付与、システム拡張の許可が必要な場合があります。使用中のクライアントの案内に従ってください。有効にした後は、ログに仮想ネットワークインターフェースの作成や待ち受けの成功が表示されているか確認します。権限不足やインターフェース作成エラーが出た場合は、まずTUNを無効にし、確認済みのシステムプロキシ経路に戻してから、トラブルシューティングで該当するエラーを調べてください。

TUNやVPNによる通信取り込み方式を複数同時に動かさないでください。初回の切り分けでは、DNSとルートの除外リストを同時に変更することも避けます。システムプロキシとTUNを併用する必要があるかどうかは、クライアントの実装やアプリによって異なります。クライアントのドキュメントを確認し、検証時は経路を把握しやすい方式を一つだけ使ってください。設定、ノード、通信の取り込み方法が決まったら、次は結果を確認します。いったん追加のパラメーター変更は控えてください。

手順4：アクセス・ルール・実際の出口を確認

まず、普段から安定してアクセスできるHTTPSページを開き、通信の取り込みによって基本的なネットワーク接続が切れていないことを確認します。次に、現在の設定でプロキシを経由するはずの宛先へアクセスします。ブラウザーにキャッシュされた内容を見るだけでなく、新しい接続を発生させてください。テスト中にモードやノードを切り替えた場合、既存の接続が以前の出口を使い続けることがあります。対象ページを閉じて開き直し、必要な場合に限り、クライアント内で該当する既存接続だけを削除してください。

次にクライアントの「接続 / Connections」画面を開き、アクセスした対象ドメインで絞り込んでリクエストが表示されるか確認します。該当する記録がまったくない場合は、すぐにリモートノードを変更するのではなく、ブラウザーのプロキシ設定、アプリ独自の設定、TUNの対象範囲を先に確認してください。記録があれば、適用ルール、プロキシグループの経路、最終的な出口を確認します。これらの情報から、通信がコアに届いた後にどの経路を通ったかが分かります。

プロキシを経由するはずの宛先が、意図せず DIRECT に一致していないことを確認します。プロキシグループに一致した場合は、経路を展開し、最終的に想定したノードが選ばれているかも確認してください。宛先が直接接続されても、必ずしも異常とは限りません。サブスクのルールによる想定どおりの設定である可能性があります。接続一覧のすべてにプロキシ名が表示されるかではなく、想定した経路と実際の記録が一致するかを判断基準にしてください。

出口の確認とDNSの確認は分けて行う

信頼できる出口IP確認ページを補助として利用し、プロキシ有効時の結果を直接接続時の状態と比較します。同時に、その確認リクエストがクライアントに記録されているかも確認してください。出口がサービス提供元の案内と異なる場合は、ノードの実際の出口、確認サービスのデータベース、プロキシ経路をあわせて判断し、地域名だけで結論を出さないようにします。サブスクリプションURLやアカウント情報を、いわゆるワンクリック診断サイトに送信しないでください。

ページが開けたことや出口が変わったことだけでは、すべてのアプリのDNSリクエストが想定どおりの経路を通るとは限りません。使い始めはアクセスとルール適用を確認します。DNSの設定が必要な場合は、Fake-IPとDNSの処理方法を確認してください。特定のドメインだけで問題が起きる場合は、対象、適用ルール、エラーの種類を記録し、よくある質問の手順に沿って原因を絞り込みます。

完了後に再現できる状態を記録する

ページにアクセスでき、接続記録も想定どおりになったら、設定名、モード、プロキシグループの選択、通信の取り込み方法を記録しておきます。設定全体を公開する必要はありません。次に通常の終了手順を試します。まずシステムプロキシを無効にするか接続を切断し、その後クライアントを終了して、通常のネットワークにアクセスできることを確認してください。プロセスだけを終了してシステムプロキシがローカルポートを指したままの場合、待ち受けサービスが停止してブラウザーにエラーが出ることがあります。クライアントを再起動してシステムプロキシを無効にするか、事前に記録したシステム設定に戻してください。

最後に必要に応じて、OS起動時の自動起動と設定の自動更新を有効にし、次回の再起動後に動作をもう一度確認します。自動起動で保証されるのはアプリが開くことだけで、サブスクの読み込み、コアの起動、TUNの権限準備まで保証されるわけではありません。設定が有効であること、モードが明確であること、通信がコアに届くこと、実際の経路を確認できること。この4つの順序を保ってください。今後問題が起きた場合も、想定と違い始めた最初の手順から確認すると、スイッチをいくつも切り替えるより原因を特定しやすくなります。

Clashのサブスク追加と接続ガイド