Clash初回接続ガイド：ノード選択・遅延テスト・プロキシ状態の確認

初回接続前に4つの工程を整理する

Clashクライアントをインストールしただけでは、通信がすでにプロキシ経由になったことにはなりません。完全な接続には通常、設定の読み込み、ポリシーグループでの出口選択、クライアントコアの起動、OSまたはアプリの通信をClashへ流す設定という、互いに独立した4つの工程があります。どれか1つでも完了していないと、「クライアントは起動しているのにWebページが変わらない」状態になることがあります。

サブスクリプションはノード、ポリシーグループ、ルールなどの設定を提供します。ノードは実際に利用するプロキシの出口、ルールはリクエストをどのポリシーグループへ渡すかを決めるものです。システムプロキシまたはTUNモードは、通信をClashへ送ります。初回利用ではこの順番で確認し、クライアントの再起動やノードの連続変更を繰り返さないようにしましょう。

クライアントによってメニュー名は多少異なります。たとえば「設定」がProfiles、「プロキシ」がProxies、「一般」がGeneralと表示される場合があります。Clash Meta（mihomo）コアを使うクライアントでは、DNS、TUN、ルール上書きなどの項目が追加されていることもありますが、初回接続で高度な設定をすぐ変更する必要はありません。まずはサブスクリプションの設定をそのまま使って最小限の接続を完成させると、問題の箇所を特定しやすくなります。

サブスクリプションを取り込み、設定が有効になっていることを確認する

サービス提供元からClashまたはClash Meta対応のサブスクリプションURLを取得したら、クライアントの設定ページを開き、URLからの取り込み機能で追加します。デスクトップクライアントでは通常、URLを貼り付けて設定をダウンロードできます。モバイル版では「URLから取り込む」や「設定を新規作成」などの名称になっている場合があります。サブスクリプションURLはアカウント設定情報にあたるため、公開ページに掲載せず、通常のノードURLと誤認して1つずつ追加しないでください。

取り込みに成功すると、設定一覧に新しい項目が表示されます。更新日時、設定名、ノード数などが表示されているか確認し、その設定を現在の使用対象に指定してください。一覧にダウンロードされただけで選択されていない場合、クライアントが内蔵の空設定、古い設定、または以前に取り込んだ別のサブスクリプションを使い続けることがあります。

サブスクリプションの取り込みに成功したか確認する方法

• 設定ページに該当する項目が表示され、手動更新時に形式の解析エラーが発生しない。
• プロキシページにポリシーグループとグループ内のノードが表示され、DIRECTとREJECTだけになっていない。
• ルールページにドメイン、IP、プロセス、またはフォールバックルールがあり、設定内容が空白ではない。
• クライアントログに、設定ファイルが見つからない、YAMLの解析に失敗した、ポートが使用中といったメッセージが連続して表示されていない。

設定をダウンロードできるのにプロキシページへノードが表示されない場合は、まずサブスクリプションの種類がClashに対応しているか確認します。サービスによっては汎用サブスクリプション、単一ノードURL、Clash設定を別々に提供しています。クライアントで必要なのは、Clashまたはmihomo対応と明記された取り込み口です。更新時にログインページ、権限エラー、期限切れの表示が返る場合は、先にサブスクリプションのアカウント状態を確認してください。クライアントを再インストールしても、リモート側で無効になったサブスクリプションは直りません。

設定の更新後、ポリシーグループの選択結果が保持される場合もあれば、新しい設定に合わせて再構築される場合もあります。ノード名やグループ構成が変わったときは、プロキシページを開いて現在の選択を確認し、サブスクリプションから削除された古いノードを参照し続けないようにしてください。

ルールモード・グローバルモード・ダイレクトモードを理解する

Clashの代表的な動作モードには、ルールモード、グローバルモード、ダイレクトモードがあります。初回接続ではルールモードを優先するのがおすすめです。設定内のルールに従ってリクエストの行き先が決まり、プロキシが必要な通信はプロキシポリシーグループへ渡され、ローカルネットワークや指定サイトは直接接続され、最後まで一致しないリクエストは末尾のフォールバックルールで処理されます。

グローバルモードでは、Clashに入った通信の大部分をグローバルポリシーグループへ渡します。特定のノードが出口として使えるかを短時間で確認するのに適していますが、OS上の「すべてのアプリが必ず制御される」ことを意味しません。通信がクライアントへ入るかどうかは、システムプロキシ、TUNモード、アプリ自身の通信方式にも左右されます。

ダイレクトモードでは、通常、通信がプロキシの出口を経由しません。プロキシノードの影響を一時的に切り分ける用途には向いていますが、初回接続の最終状態には適しません。クライアントが正常に動作しているのに外部接続の結果が常に直接接続と同じ場合は、モードがDIRECTのままになっていないか、現在のポリシーグループでDIRECTが選ばれていないかを確認してください。

ポリシーグループとノードを選択する

プロキシページを開くと、通常は複数のポリシーグループが表示されます。ノード選択、自動速度測定、フォールバック、ストリーミング、最終出口などを示す名前が一般的です。グループ名はサブスクリプションの設定によって決まり、クライアントごとに完全には一致しません。初回接続では、主要なプロキシ通信を担う選択グループを見つけ、そのグループが現在、具体的なノード、別のポリシーグループ、DIRECTのどれを参照しているか確認します。

グループ内に「自動選択」またはURL-Testタイプのポリシーグループがある場合、設定されたテストURLと間隔に従って可用性を測定し、候補ノードから適切なものを選びます。Fallbackタイプは障害時の切り替えを重視し、通常は利用可能な先頭のノードを使います。Selectタイプはユーザーによる手動指定が必要です。画面に遅延値が表示されても、すべてのポリシーグループが自動でノードを切り替えるとは限りません。Selectグループでは手動選択が優先されます。

初回のノード選択で役立つ基準

1. まず到達性を確認します。遅延テストを安定して完了できるノードは、非常に低い値がたまに出ても頻繁にタイムアウトするノードより優先されます。
2. 次に遅延を確認します。一般に遅延が小さいほどWebページの応答や操作性に有利ですが、ダウンロード帯域を直接示すものではありません。
3. 利用目的を考慮します。サイトによっては出口の地域、IPの種類、アカウントの地域に条件があるため、実際のアクセス先に合わせて選択してください。
4. 一度に変更しすぎないでください。初回確認では明確なノードを1つだけ選び、接続に成功してから他の経路と比較します。

ポリシーグループは相互に参照できます。たとえば「ノード選択」グループに「自動選択」が含まれ、ルールがリクエストを「ノード選択」へ渡すことがあります。この場合、実際の出口は複数の選択を経て決まります。選択しても変化がないときは、ポリシーグループの参照関係を順にたどり、最終的に具体的なノードを指しているか確認してください。DIRECTや利用できない子グループのままではいけません。

遅延テストの結果を正しく理解する

クライアントの遅延テストは、通常のICMP Pingとは異なります。Clashはノードを経由して指定されたテストURLへHTTPまたはHTTPSリクエストを送り、接続の確立から応答取得までにかかった時間を記録します。そのため結果は、ローカルネットワーク、プロキシプロトコルのハンドシェイク、ノードの負荷、テストサイト、経路品質の影響を受けます。OSのコマンドラインからサーバーへpingが通っても、プロキシプロトコルで接続できることを直接証明するものではありません。

全ノードのテストを実行したら、まず1周終わるまで待ち、同じノードの結果が複数回安定しているか確認します。数十ミリ秒や数百ミリ秒という値は、特定のネットワーク環境で測定された結果であり、すべての地域に共通する合格ラインはありません。単発の数値より連続した結果が重要です。正常値から頻繁にタイムアウトへ変わるノードは、実際の閲覧でも初回表示が遅れたり接続が切れたりしやすくなります。

すべてのノードが同時にタイムアウトする場合は、全ノードが一斉に停止したと判断する前に、共通する条件を疑ってください。ローカルネットワークから外部テストURLへアクセスできるか、システム時刻が正確か、サブスクリプションを直前に更新していないか、DNSに異常がないか、ファイアウォールがクライアントコアの通信を妨げていないかを確認します。会社、学校、公共のネットワークでは特定のプロトコルやポートが制限されることもあるため、スマートフォンのテザリングで比較テストするのも有効です。

一部のノードだけがタイムアウトする場合は、同じグループ内で安定して結果を返すノードを選び、確認を続けます。遅延テストに成功しても、目的のWebサイトが必ず利用できるとは限りません。対象サイトに地域制限があったり、ルールによって別のポリシーグループへ送られたりするためです。最終判断には接続ログと実際のリクエストを組み合わせます。

コアを起動してシステムプロキシを有効にする

設定とノードの準備ができたら、Clashコアが起動していることを確認します。画面を開くと自動でコアが動くクライアントもあれば、「サービス」「実行」またはメイン接続スイッチを有効にする必要があるクライアントもあります。コアが起動していない場合、システムにプロキシアドレスが設定されていても、ローカルの待ち受けポートが存在しないため通信できないことがあります。

デスクトップOSの「システムプロキシ」は通常、OSのHTTPおよびHTTPSプロキシ設定をClashのローカル待ち受けアドレスへ向けます。システムプロキシ設定に従うブラウザーやアプリは、リクエストをClashへ渡します。ただし、独自のプロキシ設定を使うアプリ、直接接続するプログラム、独自のネットワークスタックを実装したソフトは、自動的にシステムプロキシへ従うとは限りません。

初回接続でシステムプロキシとTUNを同時に有効にする必要はありません。まずシステムプロキシでブラウザーの通信を確認すると、経路が分かりやすく、必要な権限も少なくなります。基本的なプロキシ接続を確認した後、システムプロキシに従わないアプリ、UDP通信、その他のシステム通信も取り込みたい場合に、クライアントの説明に従ってTUNモードを有効にしてください。

TUNモードとシステムプロキシの違い

TUNモードは仮想ネットワークインターフェースとシステムルーティングを使って通信を受け取るため、通常はシステムプロキシより広い範囲をカバーします。mihomoコアを使うクライアントには、自動ルート、DNSハイジャック、厳格ルーティングなどの設定が用意されている場合があります。TUNの有効化には管理者権限、ネットワーク拡張の許可、VPN権限などが必要になることがあり、他のVPN、仮想NIC、企業向けセキュリティソフトと競合する可能性もあります。

初回利用時に複数の取り込み方式を同時に有効にすると、原因の切り分けが難しくなります。システムプロキシでブラウザーが正常に接続できるなら、まずその結果を記録してからTUNを単独でテストします。切り替える前に他のVPNを停止し、失敗した場合はクライアントログを確認してください。ステータスバーのアイコンだけで有効な転送が確立したと判断してはいけません。

3段階の確認でプロキシ状態を検証する

接続確認では、クライアントのボタンの色だけを見てはいけません。信頼性の高い方法は、クライアントログ、実際のWebページへのアクセス、出口情報の順に確認することです。3つの結果を照合することで、「コアが起動した」「リクエストがClashへ入った」「リクエストが目的のノードを経由して完了した」という状態を区別できます。

第1段階：接続記録を確認する

クライアントの接続またはログページを開き、ブラウザーでWebページを更新します。正常であれば、新しいドメイン、宛先アドレス、適用されたルール、ポリシーの経路が記録されます。ログには、リクエストがどのルールに一致し、どのポリシーグループを経由して具体的なノードへ向かったかが表示されることがあります。記録がDIRECTでも、現在のルールに従って直接接続されたことを示すだけで、必ずしも故障ではありません。

ブラウザーを更新しても新しい接続記録がまったく表示されない場合、通常は通信がまだClashへ入っていません。システムプロキシが有効か、ブラウザーが独自プロキシを使っていないか、クライアントの待ち受けポートが正常か、OSのプロキシ設定を別のプログラムが書き換えていないかを確認します。

第2段階：通常のWebページへアクセスする

現在のネットワーク環境で結果が明確なWebページを1つ選んでテストします。まずページが開くことを確認し、画像、スクリプト、APIリクエストまで正常に読み込まれるか観察します。トップページを開くだけでは、すべての接続を確認できません。ページのリソースが複数のドメインに分散し、異なるルールで処理されることがあるためです。本文は表示されるのに画像や動画が失敗する場合は、接続記録で該当リソースのドメインがどの経路へ送られたかを確認します。

第3段階：出口情報を照合する

信頼できるIP情報ページで現在の出口アドレスと地域を確認し、システムプロキシを無効にしたときの結果と比較します。出口が変化し、ログにも選択したノードを経由したことが表示されて初めて、そのブラウザーリクエストがプロキシ転送を完了したと判断できます。出口が変わらない場合は、現在のポリシーでDIRECTが選択されていないか、確認サイトがダイレクト接続ルールに一致していないか、ブラウザーにシステムプロキシを迂回する機能がないかを確認してください。

1. 現在のノードを変更せず、システムプロキシを有効にしてテストページを更新します。
2. 接続一覧から、テストページに対応するドメインのリクエストを特定します。
3. ポリシーの経路が最終的に目的のノードへ到達し、DIRECTになっていないことを確認します。
4. 出口情報を記録し、システムプロキシを無効にして比較テストを1回行います。
5. テスト完了後、必要な取り込み方式を再び有効にし、クライアントの状態を確認します。

初回接続に失敗したときの基本的なトラブルシューティング手順

トラブルシューティングでは、一度に1つの条件だけを変更し、設定層からシステム層へ段階的に確認します。再インストール、サブスクリプション変更、DNS変更を同時に行うと、単純な問題でも比較できる結果が失われます。次の手順は、デスクトップとモバイルの多くのクライアントで利用できます。

「システムプロキシを有効にするとすべてのWebページにアクセスできない」場合は、まずシステムプロキシを無効にしてローカルネットワークを復旧し、コアが動作しているか、ローカルポートが使用中でないかを確認します。ログに待ち受けの失敗が表示される場合、別のプロキシクライアントが同じポートを使っている可能性があります。他のプロキシやVPNを完全に終了してからClashを再起動するほうが、複数のポートを無計画に変更するより原因を特定しやすくなります。

「遅延テストは正常なのにWebページが開かない」場合は、実際のリクエストログを重点的に確認します。テストURLと目的のWebページは別サイトなので、異なるルールに一致したり、異なるDNS結果を使ったりする可能性があります。ブラウザーでHTTP/3、独自DNS、拡張機能のプロキシ設定が有効になっていないかも確認してください。一時的にシステムプロキシに従う別のブラウザーで比較できますが、ノードと動作モードを同時に変更しないでください。

「一部のサイトは正常だが、一部は失敗する」場合、基本的な接続は成立しており、問題はルール、ポリシーグループ、DNS、または対象サイトの制限にある可能性が高いです。失敗したドメインの接続記録を見つけ、どのルールに一致し、どのポリシーグループへ渡されたかを確認してから、そのグループの実際の出口を調べます。ルールモードでは上から順に照合され、先に一致したルールが処理方法を決めます。末尾のMATCHは通常、フォールバックを担います。

接続成功後に行う基本設定

初回確認が完了したら、自動更新、スタートアップ、ポリシーの保存を設定できます。サブスクリプションの更新頻度は高くしすぎず、サービス提供元とクライアントの初期周期に従うのが無難です。設定を更新した後は、ノード名、ポリシーグループの構成、ルールに変更がないか確認し、重要なポリシーグループを再確認してください。

スタートアップを有効にする場合は、「クライアントを自動で開く」「コアを自動実行する」「システムプロキシを自動で有効にする」を区別する必要があります。これらは別々の項目になっている場合があります。共有PCやネットワークを頻繁に切り替える端末では、システムプロキシを手動で有効にする運用のほうが適しています。クライアントコアの起動前に、無効なシステムプロキシ設定が残るのを防げます。

日常利用では、安定したノードを1つ基準として残しておくと便利です。ネットワークに異常があるときは、まず基準ノードをテストしてから他のノードと比較します。これにより、単一経路の不調なのか、ローカルネットワーク、サブスクリプション、クライアント全体の問題なのかを判断できます。より広範囲の通信を取り込む必要がある場合は、TUN、DNS、ルーティング項目を1つずつ設定し、変更のたびに「接続記録—Webアクセス—出口情報」の3段階で再確認してください。