Clashを初めて起動したあと、画面が開いたからといってプロキシがすでに通信を引き受けているとは限りません。完全な接続には少なくとも、設定の読み込み、プロキシグループでのノード選択、OSまたはアプリからClashへの通信転送、指定した出口を通じたルールどおりの接続という4つの独立した段階があります。どれか1つでも完了していないと、「ノードは使えそうなのにWebページは直接接続のまま」「システムプロキシを有効にしたのにすべてのリクエストがタイムアウトする」といった状態になることがあります。

クライアントによってメニュー名は多少異なります。Clash Meta（mihomo）カーネルを採用したクライアントでは、通常、設定、プロキシ、接続、ログ、システムプロキシ、TUNが別々のページに分かれています。旧版のClashクライアントも、ほぼ同じ考え方で動作します。初回は通信の流れに沿って操作し、DNS、ルールモード、ポート、TUNの設定を一度に変更しないでください。まず検証可能な基本接続を確立し、その後で特定アプリの互換性を確認します。

1. 接続前にクライアントの状態を確認

クライアントを起動したら、まずカーネルが正常に動作しているか確認します。画面にはRunning、Started、Core Running、「サービス実行中」などの状態が表示されます。ページが表示されていても、カーネルがStopped、Error、または再起動を繰り返している場合、サブスクリプションの読み込みやノードテストで正しい結果を得られないことがあります。その場合は先にログを開き、設定の解析エラー、リッスンポートの競合、権限不足がないか確認してください。

システムの日付、時刻、タイムゾーンが正しいことも確認します。HTTPS接続では証明書の有効期間が検証されるため、端末の時刻が大きくずれていると、サブスクリプションの更新やノードとのハンドシェイクに失敗することがあります。ネットワークからサブスクリプションサービスへアクセスできることも必要です。いったんシステムプロキシを無効にし、ブラウザーで通常のWebサイトが開けるか確認してください。基盤ネットワークが接続されていなければ、ClashがWi-Fi、LANケーブル、モバイル通信の代わりに低レイヤーの接続を確立することはできません。

確認項目 正常な状態 異常時に優先して確認すること
カーネルの状態 継続して動作し、繰り返し終了しない 起動ログと設定エラーを確認
ローカルネットワーク プロキシを無効にすると通常のWebサイトへアクセスできる ゲートウェイ、認証ページ、DNSを確認
システム時刻 日付、時刻、タイムゾーンが正確 システム時刻の自動同期を有効化
リッスンポート HTTP、SOCKS、mixedポートが正常に待ち受けている ポートを使用している古いプロセスを終了

2. サブスクリプション設定を読み込んで有効化

Clashでは、YAML設定を使ってプロキシノード、プロキシグループ、ルール、DNS、実行パラメーターを定義します。サブスクリプションURLは通常、設定サービスが提供する更新先です。クライアントはまずそのURLへリクエストを送り、返された内容をローカル設定として保存します。URLをコピーするときは完全なクエリパラメーターを保持し、疑問符以降のtoken、デバイスパラメーター、エンコードされた内容を手動で削除しないでください。また、サブスクリプション管理ページのURLをサブスクリプションURLと取り違えないように注意します。

  1. 「設定」「Profiles」または「サブスクリプション」ページを開きます。
  2. URLからの読み込みを選択し、完全なサブスクリプションURLを入力欄に貼り付けます。
  3. ダウンロードまたは読み込みを実行し、クライアントに更新完了が表示されるまで待ちます。
  4. 設定一覧で読み込んだばかりの項目を選択し、現在のアクティブ設定にします。
  5. プロキシページに戻り、プロキシグループとグループ内のノードが表示されることを確認します。

「ダウンロード成功」と「設定が有効」は別の状態です。クライアントによっては、サブスクリプションを更新してもファイルを一覧に追加するだけで、現在の設定へ自動的に切り替わりません。プロキシページに古いノードが表示されている場合は、設定ページに戻り、選択マーク、アクティブ状態、最終更新時刻を確認してください。設定を有効にしたあとにYAML解析エラーが表示された場合は、具体的な行番号と項目を記録します。同じエラー内容は再ダウンロードで自動修復されないため、更新ボタンを何度も押さないでください。

サブスクリプションが空の内容、HTMLページ、またはサポートされていない形式を返すと、invalid config、unexpected token、proxy group not found、proxies項目がないといったエラーが表示されることがあります。これは設定の読み込み段階で発生する問題であり、ノード速度とは関係ありません。ブラウザーでサブスクリプションURLを開いてサービスの応答を確認することはできますが、アクセス情報を含むサブスクリプションURLをチャットグループ、スクリーンショット、公開ログに載せないでください。

3. プロキシグループとノードを選択

設定が正常に読み込まれたら、「プロキシ」「Proxies」ページを開きます。ここは単純なノード一覧ではなく、複数のプロキシグループで構成されていることが一般的です。代表的なグループタイプには、手動選択のselect、自動測定のurl-test、障害時に切り替えるfallback、負荷分散を行うload-balanceがあります。ルールが参照するのはプロキシグループ名であり、実際に使用するノードはそのグループが決定します。そのため、関係のないグループでノードを選んでも、実際の出口が変わるとは限りません。

まず、主要な通信を担当するグループを探します。「ノード選択」「プロキシ」「PROXY」、または設定提供元が独自に付けた名前になっている場合があります。そのグループを開き、地域が明確でテスト可能なノードを選択してください。メイングループで別のプロキシグループが選択されている場合は、さらに下の階層へ進み、最終ノードを確認します。グループを連鎖させる構成自体は有効ですが、初回のトラブル対処では最終的にどのプロキシ項目へ到達するのかを把握する必要があります。

モードの選択も結果に影響します。

  • ルールモード（Rule）：上から順にルールを照合します。ドメインごとにプロキシ、直接接続、拒否のいずれかが適用されるため、日常利用のデフォルトに適しています。
  • グローバルモード（Global）：大半の対象接続をグローバルグループへまとめて渡します。ノードの出口を一時的に確認するのに便利ですが、システム上のすべての通信が必ず対象になるわけではありません。
  • ダイレクトモード（Direct）：Clashが受け取った通信をプロキシノードを経由させず、宛先へ直接接続します。リモートプロキシの出口を確認する用途には使えません。

初回の確認では、まずルールモードを使用します。テストサイトがどのルールに一致したか判断できない場合は、短時間だけグローバルモードへ切り替えて結果を比較してください。テスト後はルールモードに戻します。モードはClashが接続を受け取った後の処理方法を決め、システムプロキシやTUNは接続がClashへ届くかどうかを決めます。これら2つの設定は互いに代替できません。

4. 遅延テストを正しく理解する

ノードの横にある「速度テスト」は、通常HTTPプローブを実行します。カーネルがそのノード経由で設定されたテストURLへアクセスし、接続確立から応答取得までにかかった時間を記録します。80 ms、200 ms、Timeoutといった表示は、そのテストの結果を示すだけです。ダウンロード帯域幅と同じ意味ではなく、動画の安定性、混雑する時間帯の輻輳、パケットロス率、接続先サイトによる出口アドレスの制限まで完全に表すものでもありません。

テストでは、まず1つのプロキシグループに対してすべての遅延テストを実行し、同じ地域の利用可能なノードから、数値が低く結果が安定しているものを選びます。1回だけ最も低かった数値で決めないでください。連続テストで90 ms、95 ms、100 ms付近を推移するノードは、40 msと700 msの間を大きく変動するノードより、通常は安定した操作感を保ちやすい傾向があります。地域をまたぐノードでは物理的な距離が長くなるため、基本遅延が増えるのは正常です。

Timeoutは、テストの制限時間内に期待した応答を取得できなかったことを示します。ノードの停止、経路の遮断、テスト先に到達できない、TLSハンドシェイクの失敗、ローカルネットワークの変動などが原因として考えられます。すべてのノードが同時にタイムアウトする場合は、ノードを1つずつ故障と判断する前に、ローカルネットワーク、サブスクリプション設定、カーネルの状態、テストURLを確認してください。1つのノードだけが継続的にタイムアウトするなら、同じグループの別ノードへ切り替える方が効果的です。

5. システムプロキシまたはTUNを有効化

ノードを選択したら、アプリの通信をClashへ入れる必要があります。最も一般的な方法は「システムプロキシ」を有効にすることです。クライアントはOSのHTTPおよびHTTPSプロキシを、通常は127.0.0.1とローカルポートの組み合わせで指定します。システムプロキシ設定に従うブラウザーやデスクトップアプリはリクエストをClashへ送り、ルールによって直接接続かプロキシかが決まります。

システムプロキシですべてのプログラムをカバーできるわけではありません。ゲーム、コマンドラインツール、バックグラウンドサービス、独自のネットワーク処理を行うアプリはOSのプロキシを無視することがあります。また、UDP通信も通常のHTTPプロキシを通るとは限りません。このような場合はTUNモードを検討できます。TUNは仮想ネットワークインターフェースを作成し、カーネルがより広い範囲のIP通信を受け取れるようにします。通常は管理者権限が必要で、ファイアウォール、セキュリティソフト、ほかのVPN、仮想ネットワークアダプターの影響を受けることがあります。

初回接続では、まずシステムプロキシをテストすることをおすすめします。経路が単純で、問題が発生する箇所も少ないためです。ブラウザーでプロキシ接続を確認してから、必要に応じてTUNを有効にしてください。システムプロキシやルーティングテーブルを書き換えるクライアントを複数同時に実行すると、一方の設定が他方を上書きすることがあります。クライアントを切り替える前に、元のクライアントのシステムプロキシとTUNを無効にし、バックグラウンドプロセスも終了してください。

システムプロキシを使用するときは、OSのプロキシアドレスがクライアントの現在のポートと一致しているかも確認します。設定内のmixed-port、port、socks-portは用途が異なります。手動で入力する場合、SOCKSポートをHTTPポートとして指定しないでください。クライアントにシステムプロキシを自動管理させる方が、ポート変更時にも同期されるため安全です。

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

確認はスイッチの色だけで判断できません。出口の結果、接続記録、ルールの一致を同時に確認します。まず既知のノードを選択した状態にし、システムプロキシを有効にします。次にブラウザーのプライベートウィンドウを新しく開き、公開IPなどの出口情報を表示できるサービスへアクセスします。現在の出口地域またはアドレスを記録し、システムプロキシを無効にしてから再読み込みして比較します。2回の結果が期待どおりに変化すれば、ブラウザーの通信がプロキシ経路に入ったことを確認できます。

続いてクライアントの「接続」「Connections」ページを開き、新しいWebサイトへアクセスします。通常は、新しいドメイン、宛先アドレス、接続タイプ、送受信量、一致したルール、プロキシチェーンが表示されます。プロキシチェーンは「対象ポリシーグループ → 選択したノード」と表示されることもあれば、DIRECTと表示されることもあります。DIRECTが必ずしもエラーとは限りません。ルールモードでは、ローカルネットワーク、特定地域のサイト、設定で指定されたドメインが直接接続になる場合があります。

ログも判断材料になりますが、時系列に沿って読み取ってください。ブラウザーのリクエストは通常、DNS問い合わせ、ルール照合、TCPまたはUDP接続の確立、ノードへの接続、宛先へのアクセスという段階を経ます。ログにmatch、proxy、DIRECT、具体的なグループ名が表示されたら、直前にアクセスしたドメインと対応しているかを確認します。古いログのtimeoutだけで、現在のリクエストも失敗しているとは判断できません。トラブル対処の前にログを消去するか、テスト開始時刻を覚えておくと確認しやすくなります。

ドメイン名と直接IPアドレスへの接続も分けてテストしてください。Webページが開かず、接続記録にも新しい項目がない場合は、通信がClashへ入っていない可能性があります。接続項目はあるもののDNS失敗と表示される場合は、DNSモジュール、ネットワーク到達性、モード設定を確認します。正しいノードに接続しているのにタイムアウトする場合は、ノードの回線または対象サービスの問題である可能性が高くなります。ノードを十数個続けて切り替えるより、段階ごとに切り分ける方が迅速です。

再現可能な確認手順

  1. 遅延テストに応答するノードを1つ選択します。
  2. 現在のモードがルールまたはグローバルであり、ダイレクトではないことを確認します。
  3. システムプロキシを有効にし、TUNは一時的に無効のままにします。
  4. 接続記録とログを消去するか、現在時刻を目印として記録します。
  5. ブラウザーの新しいウィンドウで、出口確認ページと通常のHTTPSサイトへアクセスします。
  6. 接続記録にあるドメイン、ルール、ポリシーグループ、最終ノードを確認します。
  7. システムプロキシを無効にして再度テストし、出口と接続記録が変化することを確認します。

7. ステータス表示とよくあるトラブルを確認

ConnectedまたはRunning：通常はカーネル、サービス、または特定の接続が動作中であることを示すだけです。対象サイトへアクセスできることや、現在の出口がプロキシ経由であることを保証しません。接続記録と併せて確認してください。

Timeout：制限時間内にテストまたは接続が完了しなかったことを示します。まず、すべてのノードで起きているのか、1つのノードだけなのかを確認し、DNS、ノードとのハンドシェイク、対象からの応答のどの段階で止まったかを切り分けます。すべてのノードが同時にタイムアウトする場合は、通常、ローカルネットワークとカーネルを確認する必要があります。

Connection refused：対象アドレスが接続を明示的に拒否しています。拒否された先が127.0.0.1上のローカルポートなら、カーネルが待ち受けていない、またはシステムプロキシのポート指定が間違っている可能性があります。リモートノードで発生している場合は、ノードサービスが指定ポートで動作していない可能性があります。

DNS lookup failed：ドメイン名の解決で利用可能な結果を取得できませんでした。端末上で別のDNSツールが動作していないか、TUNのDNSリダイレクトが正常か、設定内のnameserverへ到達できるかを確認します。基本接続を確認する前に、複数の暗号化DNSやカスタムhostsルールを同時に追加しないでください。

TLS handshake failed：端末時刻、証明書検証、SNI、経路の切断、リモートサービスの状態などが関係している可能性があります。まず時刻を正しく合わせ、同じグループの別ノードで比較します。すべてのノードが1つの対象だけで失敗する場合は、設定全体を変更する前に対象サービスの制限も考慮してください。

Webページは開くがアプリは接続できない：ブラウザーは通常システムプロキシに従いますが、対象アプリはその設定を無視したりUDPを使用したりすることがあります。まず接続ページにアプリのリクエストが表示されるか確認します。記録がまったくない場合は、TUN、アプリ内プロキシ、プロセス単位のルーティング設定を検討してください。

8. 初回接続チェックリスト

  • クライアントのカーネルが継続して動作し、ログに設定解析エラーがない。
  • サブスクリプションをダウンロードし、現在のアクティブ設定にしている。
  • プロキシページにポリシーグループとノードが表示される。
  • 主要なポリシーグループで、無効な項目ではなく実際のノードを選択している。
  • ノードの遅延テストに応答があり、連続結果に異常な変動がない。
  • 現在のモードがDirectではなく、ルールモードで一致したポリシーを確認できる。
  • システムプロキシが有効で、OSのプロキシポートとクライアントのリッスンポートが一致している。
  • ブラウザーでアクセスすると、接続ページに該当する新しい記録が表示される。
  • 記録に期待したルール、ポリシーグループ、最終ノードが表示される。
  • 出口確認の結果が、システムプロキシを無効にしたときと期待どおりに異なる。

以上を確認できれば、初回接続に必要な基本経路は確立しています。その後、特定のプログラムだけがネットワークに接続できない場合は、アプリがシステムプロキシに従うか、UDPを使用しているか、TUNが必要か、対象ドメインがどのルールに一致したかに絞って確認します。すべてのアプリが同時に使えない場合は、設定、カーネル、リッスンポート、ローカルネットワークという4つの基本要素に戻って確認してください。

安定して利用するために重要なのは、最低遅延を追い続けることではありません。設定が有効で、ノードへ到達でき、通信の入口が明確で、ルールの結果を確認できる状態を保つことです。接続記録から「リクエストがClashへ入ったか、どのルールに一致したか、最終的にどのノードを通ったか」を答えられれば、初回接続で起きる問題の多くは具体的な段階まで切り分けられます。