Clash初回接続ガイド：ノード選択・遅延テスト・プロキシ状態の確認
購読のインポートから、ノード選択、モード確認、システムプロキシの有効化、アクセス結果の確認まで、Clashを初めて使う際の基本手順を解説します。
Clashクライアントを初めて起動したあと、画面が正常に表示されても、プロキシ経路が利用可能になったとは限りません。完全な接続確認には、設定の読み込み、プロキシグループの選択、ノードへの接続、動作モード、システム通信の入口、目的サイトへのアクセスという6つの工程があります。どれか1つでも反映されていないと、「ノードの遅延は表示されるのにウェブページが開かない」「クライアントは動作中なのに出口アドレスが変わらない」「一部のアプリは接続できるのにブラウザーだけ接続できない」といった症状が起こります。
最も確実なのは、複数のスイッチを続けて切り替えるのではなく、データの流れに沿って各段階を確認する方法です。まずクライアントが設定を正しく解析できることを確認し、次に利用可能なノードを選び、正しい通信入口を有効にして、最後にログと実際のアクセス結果を突き合わせます。以下の手順は一般的なデスクトップ版Clashクライアントに加え、Clash Meta（mihomo）コアを使うGUIクライアントにも対応しています。ボタン名は異なる場合がありますが、確認の考え方は同じです。
PROFILE INPUT
手順1：購読をインポートし、設定の読み込みを確認する
購読URLはノードそのものではなく、クライアントが設定内容を取得する入口です。サーバーからの応答には通常、プロキシノード、プロキシグループ、ルール、DNS設定、リモートルールセットへの参照が含まれます。インポート成功の判断基準は、一覧に購読が表示されることだけではありません。その項目が現在の設定として選択され、クライアントにYAML構文、フィールド型、リモートリソースのダウンロードエラーが表示されていないことも確認してください。
購読をインポートする標準手順
- 購読URL全体をコピーし、先頭が
https://になっていることを確認します。URLの前後にある空白まで一緒にコピーしないよう注意してください。 - Profiles、設定、または購読ページで「URLからインポート」を選択し、URLを貼り付けてダウンロードを実行します。
- 設定項目に名前、更新日時、または設定サイズが表示されるまで待ち、その項目をクリックして現在の設定に指定します。
- ログページを開き、解析失敗、無効なフィールド、リソースのダウンロード失敗、設定の読み込み失敗が継続して表示されていないことを確認します。
- プロキシページに戻り、プロキシグループとノードが表示されるか確認します。設定名が空白で、プロキシグループもまったく表示されない場合は、ノードテストに進まないでください。
クライアントによっては複数の設定を保存できますが、実行時に有効になるのは1つだけです。新しい購読をインポートしたのに古いノードが表示される場合、現在の設定が切り替わっていないか、新しい設定のインポート後に再読み込みされていない可能性があります。まず現在の設定名を控えてから、一度切り替えてみてください。初回確認の段階では複数のオーバーライドスクリプトを同時に有効にしないでください。オーバーライドの結果、プロキシグループ、DNS、ポートの項目が変わることがあります。
購読の問題とクライアントの問題を見分ける
| 現象 | 優先して確認する項目 | 次の手順 |
|---|---|---|
| インポート直後にネットワークエラーが表示される | 購読URLが完全か、現在のネットワークから購読先にアクセスできるか | URLをコピーし直し、プロキシを経由しないネットワークでもう一度試す |
| ダウンロードは成功するが解析失敗と表示される | 応答内容が有効なClash設定か | ログにある行番号とフィールド名を記録し、購読元を更新する |
| 設定は存在するがプロキシページが空白 | 現在の設定が選択されているか、設定内にプロキシグループが定義されているか | 新しい設定に切り替え、再読み込みを実行する |
| ノードが古い一覧のまま | 購読の更新日時と現在の設定名 | 手動で更新したあと、その設定を再選択する |
NODE SELECTION
手順2：ノードを選択し、遅延テストを正しく理解する
設定を読み込んだら、Proxiesまたはプロキシページを開きます。ページでは通常、「ノード選択」「自動選択」「フォールバック」や地域別のグループなど、プロキシグループ単位でノードが整理されています。ルールが最終的に参照するのはプロキシグループです。そのため、地域グループ内でノードを選択しただけで、上位のプロキシグループがそのグループを参照していなければ、実際の通信は別の出口を使う可能性があります。
まずプロキシグループの参照関係を確認する
初回テストでは、ルールが主に使用する手動選択グループを見つけ、具体的なノードを1つ直接選ぶことをおすすめします。メインの選択グループが「自動選択」を指している場合は、自動遅延テストグループが実際のノードを決めます。地域グループを指している場合は、その地域グループを開いて2段目の選択も確認します。関係は次のように考えると分かりやすいでしょう。
ルールに一致 → メインプロキシグループ → 地域グループまたは自動グループ → 具体的なプロキシノードクライアントに経路の詳細が表示される場合は、最終段に具体的なノード名が表示され、未選択のプロキシグループで止まっていないことを確認します。選択を変更すると通常はすぐ反映され、新しく作成される接続には新しいノードが使われますが、すでに確立された長時間接続は古い経路を使い続けることがあります。検証時は対象ウェブページのタブを閉じてから開き直し、必要に応じて古い接続を終了してください。
遅延値が示すもの
クライアントの遅延テストでは通常、指定されたテストURLへHTTPまたはHTTPSリクエストを送り、接続の確立や応答の取得にかかった時間を記録します。ノードに基本的な接続性があるかを素早く判断できますが、ICMP Pingと同じものではなく、すべての対象サイトの通信速度を示すものでもありません。テストサーバーの場所、TLSハンドシェイク、ノードの混雑、ローカルネットワークの揺らぎ、テストのタイムアウト時間などが結果に影響します。
- 具体的なミリ秒数が表示される：制限時間内にテストリクエストが完了し、ノードに基本的な到達性があります。
- タイムアウトと表示される：ノードに到達できない、テストアドレスが遮断されている、プロトコルパラメーターが無効、またはローカルネットワークで接続を確立できない可能性があります。
- 数値が時々大きくなる：まず2～3回連続してテストし、異常が続くか確認してください。1回の結果だけで判断しないようにします。
- 遅延は低いのにウェブページが開かない：ルール、DNS、システムプロキシ、対象サイトまでの経路を引き続き確認してください。遅延テストが成功しただけで、接続全体が検証できたとは限りません。
ノード選択では、単純に最も低い数値だけを追い求める必要はありません。初回の接続確認では、複数回のテストで応答があり、変動の小さいノードを優先してください。すべてのノードが同時にタイムアウトする場合は、購読パラメーターの無効化、ローカルネットワークの入口制限、Clashコアの未起動、テストアドレスの利用不能などが考えられます。すべてのノードが同時に個別故障している可能性は低いでしょう。
ROUTING MODE
手順3：Rule、Global、Directモードを確認する
Clashの動作モードは、接続に適用するプロキシ経路を決めます。一般的なモードにはRule、Global、Directがあります。初回はRuleモードを維持するのがおすすめです。設定内のルールを上から順に照合し、ローカルアドレスへの直接接続、指定した対象へのプロキシ、末尾ルールによるフォールバックを実現できるためです。実際の動作は現在の設定に依存するので、すべてのRule設定で同じ振り分けになるわけではありません。
ルールモード
ドメイン、IP、プロセス、ルールセットに基づいてプロキシグループを選択します。日常的な動作モードに適しており、初回接続の推奨基準でもあります。
グローバルモード
コアに入った接続をすべてグローバルプロキシグループに渡します。ルールによって対象が直接接続されたり、誤ったプロキシグループが選択されたりしていないかを短時間で確認するのに適しています。
ダイレクトモード
コアに入った通信を対象へ直接接続します。比較用の確認に使うモードで、選択したプロキシノードを経由しません。
Ruleモードで特定の対象にアクセスできず、Globalに切り替えると復旧する場合、問題は通常、ルールの一致結果、プロキシグループの選択、DNSの振り分けにあります。システムプロキシの入口が原因とは限りません。接続記録を開き、その対象がどのルールに一致し、どのプロキシグループに渡され、最終的にどのノードが使われたかを確認してください。テスト後はRuleに戻し、一時的な診断状態を常用設定と取り違えないようにします。
Directモードにも診断上の価値があります。Directでローカルの普段使いサイトも開けない場合は、システムプロキシのポート、コアの動作状態、ファイアウォールを先に確認します。Directは正常でプロキシモードだけ失敗する場合は、ノードとプロキシプロトコルのパラメーターを確認してください。モード切り替えはClashに入った後の処理方法を変えるだけで、システムプロキシやTUNのような通信の取り込み入口を代替するものではありません。
TRAFFIC ENTRY
手順4：システムプロキシを有効にし、アプリの通信をClashに通す
ノードテストはクライアントコアが自ら開始するため、システムプロキシが無効でも遅延値が表示されることがあります。ブラウザーやデスクトップアプリでClashを使うには、通信をローカルの待ち受けポートへ入れる必要があります。デスクトップクライアントには通常「システムプロキシ」スイッチがあり、OSのHTTPおよびHTTPSプロキシをClashのローカルポートへ向けます。
システムプロキシを有効にするための条件
- Clashコアが動作しており、ポートの競合や起動失敗が発生していない。
- システムプロキシが有効で、OSのプロキシアドレスが通常はローカルループバックアドレスを指している。
- ブラウザーやアプリがシステムプロキシ設定に従い、独自のプロキシ設定でシステム値を上書きしていない。
- ローカルファイアウォールが、クライアントプロセスによる対象ポートの待ち受けとアクセスを許可している。
- ポート設定とシステムプロキシに書き込まれたポートが一致し、ポート変更後にシステムプロキシを再適用している。
一般的な設定にはHTTPポート、SOCKSポート、mixed-portがあります。mixed-portは同じポートでHTTP接続とSOCKS接続を受け付けられますが、有効かどうかは設定とクライアントの実装によって異なります。他の端末のスクリーンショットを見てポートを入力せず、現在のクライアントのポート画面と実行ログを基準にしてください。
ブラウザーに独立したプロキシ管理拡張機能がインストールされていると、システムプロキシを迂回したり上書きしたりする場合があります。初回確認では入口を1つだけにします。ブラウザーにシステム設定を使わせるか、ブラウザーをClashのローカル待ち受けポートへ明示的に向けてください。両方を同時に変更すると、障害の原因を判断しにくくなります。システムプロキシを完全に無視するアプリもあります。その場合はアプリ内でSOCKS/HTTPプロキシを個別に設定するか、基本接続を確認してからTUNモードを使用します。
VERIFY OUTPUT
手順5：アクセス結果・接続記録・ログで検証する
プロキシの状態はスイッチの色だけで判断できません。信頼できる結論には少なくとも3つの手掛かりが必要です。対象ページが読み込めること、Clashの接続記録に対応するリクエストが表示されること、そのリクエストが想定したルールとノードを使っていることです。公開ネットワークの出口を確認する場合は、プロキシを有効にした状態と無効にした状態で信頼できるIP確認サービスへアクセスし、出口アドレスが変わるか比較します。
推奨する確認手順
- Ruleモードを維持し、メインプロキシグループで先ほどテストに成功したノードが選択されていることを確認します。
- システムプロキシを有効にし、ブラウザーで開いていた対象ページと古い接続を閉じます。
- 普段使っている国内サイトへアクセスし、システムプロキシの設定によってネットワーク全体が停止していないことを確認します。
- プロキシ経由が必要な対象へアクセスし、Connectionsまたは接続ページにドメインが表示されるか確認します。
- 接続の詳細を開き、ルール名、プロキシグループ、最終ノード、送受信データ、接続状態を確認します。
- ログにDNS解決失敗、接続拒否、ハンドシェイクのタイムアウト、ルーティング失敗がないか確認します。
接続記録は、通信がClashに入ったかを判断する直接的な証拠です。ブラウザーが対象へアクセスしているのに、接続一覧に対応するドメインやIPがまったく表示されない場合、問題はClashより前の段階で起きている可能性が高いです。システムプロキシが反映されていない、ブラウザーがプロキシを迂回している、アプリが独自のネットワークスタックを使っている、コアの待ち受けポートとシステム設定が一致していない、といった原因が考えられます。接続記録はあるもののタイムアウトする場合は、ノード、DNS、ルール、リモート経路を引き続き確認します。
出口アドレスが変わらない場合の判断方法
まず、テスト対象が実際にプロキシルールへ一致していることを確認します。Ruleモードでは一部のIP確認サイトが直接接続に設定されている場合があり、出口が変わらなくてもシステムプロキシが無効とは限りません。接続詳細で一致結果を確認するか、一時的にGlobalモードへ切り替えて比較します。Globalモードで出口が変わるなら、プロキシ経路は正常で、調整すべきなのはルールまたはプロキシグループです。Globalでも対応する接続記録がない場合は、通信入口の確認に戻ります。
ブラウザーのキャッシュ、接続の再利用、QUICにも注意してください。確立済みの接続はノードを切り替えてもすぐに再構築されない場合があり、ブラウザーのUDP/QUIC通信は通常のHTTPプロキシと異なる動作をすることがあります。最も簡単なのは、関連するタブを閉じ、古い接続が終了してから再アクセスすることです。速度テストをしながら複数のノードやモードを次々に切り替えないでください。ログと具体的な操作を対応づけにくくなります。
FAULT ISOLATION
初回接続に失敗した場合の段階別トラブル対処表
初回接続に失敗したら、「設定—コア—ノード—入口—ルール—DNS」の順に各層を確認します。毎回1つの設定だけを変更し、変更後に接続を再試行してください。どの層で復旧したのかを特定でき、一時的に使える組み合わせを偶然得ただけの状態を避けられます。
| 確認された現象 | 考えられる層 | 確認する操作 |
|---|---|---|
| クライアント起動後、プロキシページにノードがない | 設定と購読 | 現在の設定、更新結果、解析ログを確認する |
| すべてのノードテストがすぐに失敗する | コア、購読、またはローカルネットワーク | コアの動作状態、設定パラメーター、テストアドレスを確認する |
| ノードに遅延はあるが、ブラウザーの接続一覧が空 | システムプロキシの入口 | システムプロキシのスイッチ、待ち受けアドレス、ポートを確認する |
| 接続一覧に記録はあるが、対象がタイムアウトする | ノードまたはリモート経路 | 速度テストで安定していた別のノードに切り替え、接続を再構築する |
| Globalは使えるが、Ruleは使えない | ルールとプロキシグループ | 一致したルール、プロキシグループの参照関係、末尾のフォールバックを確認する |
| ドメインは失敗するが、IPへ直接アクセスすると応答がある | DNS | 解析ログ、DNSモード、上流DNSへの到達性を確認する |
| ブラウザーは使えるが、他のアプリがプロキシを経由しない | アプリのプロキシ対応 | アプリ内のプロキシ設定を確認し、その後でTUNを検討する |
DNSの問題を確認する方法
Clash Meta（mihomo）の設定では、fake-ip や redir-host などのDNS拡張モードが使われることがあります。これらは名前解決の経路やキャッシュ動作が異なりますが、初回のトラブル対処で確認すべき核心は同じです。ドメイン検索が想定したDNSモジュールに入り、上流サーバーへアクセスでき、ルール判定に必要なドメイン情報が失われていないことを確認してください。システムプロキシが利用可能だと確認できるまでは、複数の上流DNSを同時に変更しないでください。
ログにドメイン解決のタイムアウトが明確に表示される場合は、まず別のドメインをテストし、特定のドメインだけの異常か、すべての検索が失敗しているかを判断します。特定のドメインだけが失敗するなら、ルール、hostsの上書き、fake-IPのフィルター項目を確認します。すべてのドメインが失敗するなら、DNSの待ち受けポート、上流プロトコル、ネットワークの到達性、TUN使用時のDNS乗っ取り設定を確認してください。設定を更新したあとも、古い記録が判断に影響しないよう、クライアントのDNSキャッシュを消去するかコアを再起動します。
TUNモードを有効にするタイミング
システムプロキシでのブラウザーアクセス、ルールの一致、ノードの出口が正常だと確認できたのに、ゲーム、コマンドラインプログラム、システムプロキシに従わないアプリだけを取り込めない場合に、TUNを検討します。有効にする前に現在の利用可能な設定とポートを記録し、すぐに戻せるようにしてください。TUNでは通常、仮想ネットワークアダプター、ルーティングテーブル、DNSの引き継ぎ、管理者権限、厳格なルーティング設定が関係するため、システムプロキシより障害範囲が広くなります。
TUNを有効にしたら、まず仮想インターフェースが作成され、デフォルトルートがクライアントの想定どおりに変更されているか確認します。その後、アプリの接続がClashの接続記録に表示されるか確認してください。有効化後に端末全体のネットワークが切断された場合は、すぐにTUNを無効にして基本経路を復元します。MTU、DNS、ルート、ファイアウォールを同時に変更しないでください。基本プロキシが利用できていれば、TUNの問題は個別に切り分けられます。
FINAL CHECKLIST
初回接続の完了チェックリスト
以下の項目をすべて満たして、初回接続の基本手順が完了したと判断できます。その後、端末の用途に応じて自動選択、フォールバック、ルールセット、DNS、TUNを調整してください。最初の設定ですべての高度な機能を一度に有効にする必要はありません。
- 購読の更新に成功し、現在の実行設定として指定されている。
- プロキシページにプロキシグループと具体的なノードが表示される。
- 少なくとも1つのノードで複数回テストを行い、安定した結果が返る。
- メインプロキシグループが最終的にそのノードを指し、未設定の2段目グループを指していない。
- 動作モードがRuleになり、一時的な診断モードが元に戻っている。
- Clashコアが正常に動作し、ローカルの待ち受けポートに競合がない。
- システムプロキシが有効で、ブラウザーの通信が接続記録に表示される。
- 接続詳細に想定したルール、プロキシグループ、最終ノードが表示される。
- 対象ページへの接続を再確立でき、正常に読み込める。
- ログに解析、DNS、ハンドシェイクのエラーが継続して表示されない。
以上の確認が終わったら、現在の設定状態を保存し、クライアントのバージョン、コアの種類、設定名、利用可能なノードを記録しておきます。今後接続に異常が起きたときは、この基準に戻って再確認してください。設定を読み込めるか、ノードに到達できるか、通信がコアに入っているか、ルールが正しい出口を選んでいるかを順に確認します。クライアントを何度も再インストールするより、このように経路に沿って確認する方が、実際の障害箇所を特定しやすくなります。