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

接続前に:基本の3項目を確認

サブスクリプションの導入が完了しても、それはノードリストがクライアントに取り込まれただけの状態です。実際に通信をプロキシ経由にするには、次の3つの条件が同時に成立している必要があります。コアが起動していること、システムプロキシがオンになっていること、プロキシモードが正しく設定されていること。

1. コアが起動していること。Clash系クライアントのコア(Clash、Clash Meta、mihomo)は起動時にローカルでポートをリスンします。多くのクライアントの既定の混合ポートは 7890、Clash Verge Rev では既定で 7897 です。実際の値はクライアントの設定画面で確認してください。設定ファイル内の対応するフィールドは以下の通りです。

mixed-port: 7890
allow-lan: false
mode: rule

2. システムプロキシがオンになっていること。クライアントのメイン画面には「システムプロキシ」のスイッチがあります。オンにすると、OSがHTTP/HTTPS通信をローカルポートへ転送するようになり、ブラウザや大半のデスクトップアプリは個別設定なしで自動的にプロキシ経由になります。
3. プロキシモードが正しいこと。Clash には3つのモードがあります:ルール(Rule)、グローバル(Global)、ダイレクト(Direct)。通常はルールモードを選び、日本国内向けの通信は直接接続、ルールに合致する通信のみプロキシを経由させます。グローバルモードは全通信をプロキシ経由にするため一時的な検証に向いており、ダイレクトモードはプロキシ転送を無効化した状態と同じです。

ノードを選ぶ:まずプロキシグループを理解する

プロキシ(Proxies)パネルを開くと、表示されるのは長いノード一覧ではなく、いくつかのプロキシグループであることが多いです。サブスクリプションの作成者がノードを用途別にグループ化しており、実際のノードはグループ内に格納されています。よく使われるグループタイプは3種類です。

• 手動選択(select):既定のタイプです。グループを開いてノードを1つクリックすると、そのグループの通信は選択したノードを経由します。クリックしない限り現在の選択が維持されます。
• 自動選択(url-test):クライアントが定期的にグループ内ノードの遅延を測定し、その時点で最も遅延が低いノードへ自動切り替えします。ノードを手動管理したくない場合に向いています。
• フェイルオーバー(fallback):ノードリストの順番に可用性を順次チェックし、先頭のノードが利用できなくなると次のノードへ自動的に切り替わります。

手動でノードを選ぶ際は、次の3つの基準で絞り込むとよいでしょう。

1. まず地理的位置を確認する。日本国内の回線環境では、香港・日本・シンガポール・台湾のノードは欧米ノードより概して遅延が低い傾向にあります。日常的な閲覧には近場のノードを選び、特定地域のサービスへアクセスする際だけ一時的に切り替えるのがおすすめです。
2. 次に回線種別を確認する。ノード名に IPLC・IEPL・専用線といった表記があるものは通常より安定した中継経路を意味することが多く、倍率が明記されたノード(例:×1.5)はプラン容量の消耗が早いため残量に注意が必要です。
3. 混雑したノードは避ける。同一地域に複数ノードがある場合、夜間の混雑時間帯には番号の大きいノードを優先すると、混雑度の差が読み込み速度に直結して表れます。

遅延テスト:数値が示す意味

ノードリストの測定ボタン(雷アイコンや「遅延テスト」という表記)を押すと、1回のHTTP遅延テストが実行されます。クライアントがそのノードを経由して固定のアドレス(多くは http://www.gstatic.com/generate_204)へリクエストを送り、送信から応答受信までのミリ秒数を記録します。結果は各ノード名の横に表示されます。

遅延の数値で判断する際は、次の2点を覚えておいてください。

• 遅延は速度と同じではない。遅延は応答の速さを示す指標で、実際のダウンロード速度を決めるのは帯域幅です。200msのノードでも帯域が十分であれば快適に使えますし、50msのノードでも速度制限を受けている場合があります。遅延テストはあくまで初期絞り込み用で、まずタイムアウトや高遅延のノードを除外するために使いましょう。
• グループ全体がタイムアウトする場合はローカル側の問題が多い。全ノードが同時にタイムアウトする場合は、まずローカルのネットワークからテスト先アドレスへ直接アクセスできるか確認し、次にサブスクリプションが期限切れになっていないかを確認してください。ノードを1つずつ疑う前に、この2点をチェックするのが先です。

プロキシが実際に機能しているか確認する

接続後は、以下の3つの方法のいずれかで交差確認を行いましょう。複数の方法で確認できればより確実です。

方法1:出口IPを確認する

ブラウザで ip.sb または ipinfo.io を開き、表示されるIPアドレスの所在地がノードの所在地域と一致しているか確認します。確認前にページを強制リロードし、キャッシュされた古い結果を読み込まないようにしましょう。

方法2:接続パネルを確認する

クライアントの「接続(Connections)」ページには現在アクティブな接続が一覧表示され、各行に接続先アドレス、適用されたルール、経由したプロキシチェーンが表示されます。適当なウェブページを開いてパネルに対応する記録が現れれば、通信が実際にClashのコアを経由していることが確認できます。

方法3:コマンドラインで直接検証する(任意)

ターミナルでプロキシアドレスを明示的に指定してリクエストを送信すれば、システムプロキシの設定を経由せずにコア自体を直接検証できます。

curl -x http://127.0.0.1:7890 https://api.ipify.org

返ってきたIPアドレスがノードの地域と一致していれば、プロキシ経路は正常に機能しています。ポート番号はクライアントが実際にリスンしているものに合わせ、異なる場合は自分の設定に置き換えてください。

確認結果が依然としてローカルのIPアドレスのままの場合は、次の順で確認してください:システムプロキシのスイッチがオンになっているか → モードが誤ってダイレクトになっていないか → ブラウザに独立したプロキシ拡張機能が入っていてシステム設定を上書きしていないか → 使用中のアプリがそもそもシステムプロキシを読み取らない仕様になっていないか。

システムプロキシに従わないアプリへの対処:TUNモード

一部のアプリ——多くのゲーム、一部のコマンドラインツール、個別のデスクトップソフト——はシステムプロキシの設定を読み取らず、通信がClashを経由せず直接接続されてしまいます。こうしたケースではTUNモードの有効化が解決策になります。コアがシステム上に仮想ネットワークアダプタを作成し、ネットワーク層でマシン全体の通信を引き受けるため、アプリ側の対応なしに振り分け対象へ組み込まれます。

初回接続でよくあるトラブルの早見表

• スイッチはすべてオンなのにブラウザが直接接続になる場合:ブラウザに入っているプロキシ系拡張機能(SwitchyOmegaなど)を確認してください。これらはシステムプロキシを上書きします。拡張機能を無効化するか、拡張機能側のモードを「システムプロキシを使用」に戻してください。
• すべてのノードがタイムアウトする場合:まずサブスクリプションの最終更新日時を確認してください。期限切れのサブスクリプションはノードの大半が無効になっているため、更新後に再測定します。それでも全てタイムアウトする場合は、設定画面で遅延テストの宛先アドレスを現在のネットワークからアクセス可能なものに変更して再測定してください。
• 接続はできるが速度が遅い場合:近場かつ低遅延のノードに切り替え、夜間の混雑時間帯を避けてください。また、グローバルモードが有効になっていて国内向け通信まで海外経由になっていないかも確認しましょう。
• プロキシを同一LAN上の他のデバイスと共有したい場合:クライアントで allow-lan を有効にし、他のデバイス側にはこのマシンのLAN内IPアドレスとポート番号をプロキシアドレスとして設定してください。

ここまでで、初回接続の一連の流れは完了です。コアとシステムプロキシの状態確認、地理的位置と遅延によるノード選択、IPアドレス確認による動作検証。この後のサブスクリプション更新やルール調整は日常的なメンテナンスにあたり、大半はクライアントが自動で処理してくれます。