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

接続をひとつずつ確認する

初回は、設定を有効にしてルールモードに切り替え、ノードを手動選択し、システムプロキシを有効にしてWebページへアクセスする、という最小限の確認から始めましょう。複数のプロキシクライアントを同時に起動したり、最初からDNS・TUN・ルールを変更したりする必要はありません。一度に変更する条件をひとつに絞れば、問題の発生箇所を特定しやすくなります。

「設定」または「Profiles」ページでサブスクリプションをインポートし、その設定を選択します。インポートしただけでは有効になりません。プロキシページに戻り、プロキシグループが表示されていることを確認してください。
動作モードを「ルール / Rule」に切り替えます。初回確認ではサブスクリプション付属のルールを使い、独自の振り分けルールは追加しません。
対象のプロキシグループでノードをひとつ選び、遅延テストを実行します。DIRECT または REJECT ではないことを確認してください。
デスクトップでは「システムプロキシ」を有効にし、ブラウザーで対象サイトにアクセスしてから、「接続 / Connections」ページで該当リクエストを確認します。

プロキシグループで実際の出口ノードを選ぶ

「プロキシ / Proxies」を開いたら、ノードを見つけてすぐクリックするのではなく、ルールで実際に使われるプロキシグループを探します。サブスクリプションには「ノード選択」「自動選択」「海外サービス」など複数のグループが含まれる場合があります。これらの名前は設定の作成者が付けたもので、クライアント共通のメニューではありません。グループが別のグループを参照することもあるため、選択関係をたどって最終的なノードを確認しましょう。

よくある3種類のグループと選び方

グループの種類	動作	初回接続時のポイント
`select`	手動で選択したノードまたは下位グループを使用します。	再テストしやすいよう、まず特定のノードに固定します。
`url-test`	測定結果に基づいて出口を自動選択します。切り替えには許容値などの設定も影響します。	グループ名だけでなく、現在選択されているノードを確認します。
`fallback`	通常は設定順に、ヘルスチェックに成功した出口を選びます。	遅延が最も小さい順に並ぶとは限りません。

たとえば対象サイトが「海外サービス」に該当し、そのグループが「ノード選択」を参照し、「ノード選択」で「シンガポール A」を選んでいるなら、最終的な出口は「シンガポール A」です。関係のない別グループだけを変更しても、対象サイトの通信経路は変わりません。ノード名の地域表示はあくまでラベルです。実際の出口はリクエストを使って確認してください。

DIRECT はプロキシノードを経由せず、直接接続することを示します。ローカル向けや直結ルールでは適切ですが、プロキシ接続が確立している証明にはなりません。
REJECT はリクエストを拒否することを示します。誤って選ぶと接続に失敗するのは正常な動作です。
ノードが多い場合は、プロバイダーの表示で正常とされ、距離も比較的近い候補を2つ選びましょう。初回の切り分けで十数個のノードを次々に切り替えるのは避けてください。

遅延テストでわかること

プロキシグループの横にある測定または遅延ボタンをクリックし、テストが終わるまで待ちます。一般的なURL遅延テストでは、ノード経由で指定されたHTTPまたはHTTPSアドレスにアクセスし、応答までの時間を記録します。通常のICMP Pingやダウンロード速度の測定とは異なります。テストURL、接続の再利用、DNS、ノードの負荷などによって数値は変わります。

3回の結果で安定性を確認する

候補ノードをひとつ手動で選び、同じテスト先に対して約5秒間隔で3回測定します。結果を記録してから別のノードに切り替えます。以下は判断方法の例であり、本サイトによる特定ノードの実測値や速度保証ではありません。

候補ノード	3回の測定例	判断と対応
ノード A	82 / 91 / 87 ms	結果が安定しているため、まずWebアクセスの確認に使えます。
ノード B	45 / 680 ms / タイムアウト	最小値は低いものの、安定性には疑問が残ります。
ノード C	3回ともタイムアウト	ノードとテスト先をそれぞれ変えて確認します。

自動テストでは、https://www.gstatic.com/generate_204 など、204を返すアドレスがよく使われます。ただし、そのアドレスに接続できても、動画再生・ログイン・ファイルのダウンロードが正常とは限りません。逆に、特定のネットワークでテスト先がブロックされると、使用可能なノードでもタイムアウトすることがあります。実際のサイトにもアクセスして確認し、ひとつの数値だけで判断しないでください。

システムプロキシを有効にしてリクエストがコアに届くか確認する

WindowsまたはmacOSでは、まずクライアントの「システムプロキシ」スイッチを使ってブラウザーの通信を確認します。通常はシステムプロキシの接続先をローカルの待ち受けポートに設定しますが、すべてのアプリの通信を強制的に取り込むわけではありません。ブラウザー拡張機能、アプリ独自のプロキシ設定、一部のコマンドラインプログラムはシステムプロキシを使用しない場合があります。

ポートを確認してからプロキシを明示したリクエストを送る

「設定」ページで「ポート」「混合ポート」または「Mixed Port」を探します。7890 はよくある例で、すべてのクライアントで固定されている値ではありません。以下は設定項目の意味を確認するための例です。現在の実行設定と照らし合わせるだけにとどめ、サブスクリプションファイルを直接上書きしないでください。

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

現在の混合ポートが実際に 7890 であることを確認してから、Windows PowerShellで次のコマンドを実行します。macOSまたはLinuxでは curl.exe を curl に置き換えてください。ポート番号が異なる場合は、コマンド内の数字も変更します。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --head https://example.com/

このコマンドはローカルのHTTPプロキシを明示的に指定するため、アプリがシステムプロキシ設定を読み取っているかどうかを切り分けるのに役立ちます。混合ポートはHTTPプロキシのリクエストに対応しています。
127.0.0.1 を指す Failed to connect が表示された場合は、まずコアが起動しているか、ポート番号が正しいかを確認してください。
対象サーバーからHTTPレスポンスが返れば、少なくとも該当する通信は完了しています。403 が返っても、すぐにローカルポートの障害と判断しないでください。
プロキシを明示したリクエストは成功するのにブラウザーで失敗する場合は、サブスクリプションをすぐ変更するのではなく、システムプロキシのスイッチ、ブラウザー独自のプロキシ設定、拡張機能を確認しましょう。

リクエストがコアに届いた後は、現在のルールに従って処理されます。直結ルールに該当すれば DIRECT で接続されることもあります。そのため、コマンドの成功で確認できるのは入口が使えることだけです。選択したノードを実際に経由したかどうかは、接続記録で確認してください。待ち受けポートについてはインストールガイドのポート設定も参照できます。

接続記録でルールとノードを確認する

「接続 / Connections」を開いてドメインで絞り込み、対象のWebページを再読み込みします。初回確認では、プロキシ経由になることがわかっている一般的なWebページを使いましょう。既存の長時間接続があるチャットアプリだけを確認するのは避けてください。接続記録がすぐ消える場合は「ログ / Logs」も開き、ログレベルを info にして新しいリクエストを確認します。

各リクエストで確認する4項目

宛先ドメインまたはアドレス：バックグラウンド更新や別のタブではなく、今開いたサイトの記録であることを確認します。
一致したルール：ドメインルール、アドレスルール、末尾のフォールバックルールのどれが適用されたか確認します。通常、ルールは上から順に評価され、最初に一致した項目で処理が決まります。
プロキシグループの経路：グループ名をたどり、最終的なノードを確認します。結果が DIRECT の場合、そのリクエストはプロキシノードを経由していません。
通信量の変化：再読み込み後にアップロード・ダウンロードのカウントが増えることを確認します。接続が確立した記録だけで、応答データが流れていない場合は、ページが正常に利用できる証明にはなりません。

表示された出口IPが想定と異なる場合は、同じブラウザーで信頼できるIP確認サービスにアクセスし、そのリクエストのプロキシ経路も同時に確認してください。IP確認サイト自体にもルールが適用され、直結になる場合があります。表示結果が示すのはそのリクエストの出口だけで、すべてのアプリが同じ経路を使うとは限りません。

ノードを切り替えたら、新しいリクエストを発生させて再確認します。既存のTCP接続やブラウザーの接続プールでは、以前の経路が使われ続けることがあります。一部のクライアントには「接続を閉じる」機能がありますが、実行すると通信中の処理が中断されます。ファイルのダウンロード中や会議通話中は操作しないでください。ルールの照合についてはルールによる振り分けの使い方もご覧ください。

システムプロキシとTUNの使い分け

ブラウザーがシステムプロキシ経由で通信できることを確認してから、TUNモードが必要か検討しましょう。TUNは仮想ネットワークインターフェースを使い、ルーティング条件に一致する通信を取り込みます。システムプロキシを使わないアプリに適していますが、クライアント側で権限・ルーティング・DNSなどの設定が必要です。ノードを高速化するスイッチではなく、使えなくなったサブスクリプションを復旧する機能でもありません。

デスクトップブラウザーでのアクセス：権限やルーティングの影響を抑えるため、まずシステムプロキシを使います。
ゲームや独自のネットワークプログラム：まずプロキシに対応しているか確認します。通信を取り込む必要がある場合にTUNを有効にし、サービスモードや管理者権限に関する表示も確認してください。
Androidクライアント：通常はシステムVPNの許可を受けて通信を取り込みます。デスクトップのシステムプロキシ手順をそのまま適用しないでください。他のVPNアプリと同じ接続口を奪い合う場合があります。

TUNを有効にした後も、接続記録を改めて確認してください。障害によってはUDPやドメイン名前解決だけに影響することがあります。Webページを開けるからといって、すべてのプロトコルが正常とは限りません。初回の切り分けでは別のVPNを同時に使わないことをおすすめします。業務環境で企業VPNが必要な場合は、組織のネットワーク要件と通信の振り分け方法を先に確認してください。

症状から初回接続の失敗原因を調べる

症状	まず確認する項目	次に試すこと
プロキシページにノードが表示されない	設定が有効か、サブスクリプションの読み込みに成功しているか。	設定ページに戻って項目を選び、更新エラーや読み込みエラーを確認します。
すべてのノードが測定でタイムアウトする	ローカルネットワーク、サブスクリプションの状態、テスト先への接続性。	まず直接接続できることを確認し、ノードを2つ選んで実際のWebページをテストします。
遅延テストは正常だがWebページを開けない	システムプロキシの入口、ルール、対象サービス側の制限。	プロキシを明示したコマンドでテストし、接続記録でプロキシ経路を確認します。
ブラウザーのリクエストが接続ページに表示されない	ブラウザーがプロキシを迂回していないか、別のローカルプロキシを使っていないか。	ブラウザー独自の設定を確認し、システムプロキシのポート番号も照合します。
リクエストは表示されるが直結になっている	一致したルールとグループ内の選択。	デフォルトのノードグループを切り替えるだけでなく、実際に適用されたグループを確認します。
特定のWebサイトだけ開けない	サイトの稼働状況、アカウントの地域設定、ノード出口の制限。	ほかの条件は変えず、ノードをひとつだけ切り替えて比較します。

エラーが発生したら、発生時刻、対象ドメイン、現在のモード、ノード名、エラーの原文を記録してください。ログを共有する前に、サブスクリプションURL、トークン、パスワード、個人のアクセス履歴を削除します。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、公開の掲示板に投稿したり、オンライン変換サービスに安易に渡したりしないでください。

初回接続の完了条件

設定が有効で、候補ノードのテストに成功し、実際のリクエストがコアに届き、想定したプロキシグループのルールに一致し、最終経路に選択したノードが含まれ、対象ページが正常に表示されること。ホーム画面の「接続済み」表示より、これらの確認のほうが確かな判断材料になります。その後、必要に応じて自動選択、サブスクリプションの更新、アプリごとの振り分けを設定しましょう。以降の変更も同じ手順で確認できます。