Clash初回接続ガイド

まずサブスクリプション設定が有効か確認

サブスクリプションの読み込み成功、ノードの表示、プロキシ接続の確立は、それぞれ別の状態です。サブスクリプションにはノード、プロキシグループ、ルールが含まれています。クライアントで設定を読み込み、アプリの通信をコアに渡す必要があります。初回接続ではこの順番で確認し、Webページが開かないからといってサブスクリプションを何度も変更するのは避けましょう。

1. クライアントの「設定」または「Profiles」画面を開き、読み込んだサブスクリプションが選択済み、使用中、または有効になっていることを確認します。
2. 直近の更新結果を確認します。解析失敗、ダウンロード失敗、設定の読み込み失敗などが表示されている場合は、まずそのエラーを解消してください。リストに残っているノードが古い設定のものかもしれません。
3. 「プロキシ」または「Proxies」画面を開き、DIRECT と REJECT だけでなく、プロキシグループとその中のノードが表示されていることを確認します。
4. 「ログ」画面を開き、コアが繰り返し再起動していないか、ポート競合や未対応のプロトコル項目に関するエラーがないか確認します。

この記事では、デスクトップクライアントでよく見られる画面を例に説明します。「設定 → サブスクリプションを選択」「プロキシ → ルール」「接続」「ログ」は各機能の場所を示しています。クライアントによって名称や配置が異なる場合があります。Clash Meta（mihomo）コアを使うクライアントは、より多くのプロトコルや設定項目に対応できますが、現在のコアがサブスクリプションの内容を正しく解析できることが前提です。

ルールモードに切り替えて接続先を選ぶ

初回接続ではルールモードを使う

「プロキシ」画面でモードを切り替え、「ルール / Rule」を選択します。ルールモードでは、設定に記載された順序で通信を照合し、最初に一致したルールによって接続先のノードまたはプロキシグループが決まります。「グローバル / Global」では通常、コアに渡された通信がグローバルプロキシグループを使います。「直結 / Direct」は接続先に直接アクセスします。グローバルモードにしても、すべてのアプリの通信が自動的に取り込まれるわけではありません。まずアプリからコアへ通信を渡す必要があります。

初回はモード、ルール、DNSを同時に変更しないでください。まずサブスクリプションのルールをそのまま使い、同じ方法で再現できるアクセス確認を行ってから、必要に応じて特定サイトの振り分けを調整します。現在の設定に必要なルールがない場合は、すべてのサブスクリプションで振り分け動作が同じだと思い込まず、クライアントが使用している設定テンプレートを確認してください。

プロキシグループを開き、実際に選択されているノードを確認

1. プロキシ接続に使うメインのプロキシグループを探します。「プロキシ選択」「ノード選択」や、サブスクリプション独自の名前が付いている場合があります。
2. プロキシグループを開き、具体的なノードを選択します。DIRECT はプロキシノードではありません。選択すると直接接続になります。
3. 「自動選択」などのサブグループが選択されている場合は、そのグループで現在実際に使われているノードも確認します。
4. 特定のサービスに専用のプロキシグループを指定するルールがある場合は、そのサービス用グループの選択も確認してください。メインのプロキシグループを変更しても、そちらには反映されないことがあります。

たとえば、メインのプロキシグループでノードAを選んでいても、動画サービス向けのルールが別のグループを指定し、そのグループでノードBが選ばれていれば、動画サービスへの接続にはノードBが使われます。ノード名に含まれる地域名は目安です。実際のパブリックIPの出口は、接続ログとIPアドレスの確認で判断してください。

遅延テスト：まず接続できるか確認

ノードまたはプロキシグループの横にある「遅延テスト」「速度テスト」などのボタンを押し、テストが完了するまで待ちます。このテストでは通常、候補のプロキシ経由で指定URLにリクエストを送り、応答時間を記録します。ファイルを継続的にダウンロードして帯域幅を測定するものではありません。テストURL、タイムアウト時間、接続を再利用するかどうかによって結果は変わります。

表中の数値は結果の見方を説明するための例であり、当サイトで測定したデータではありません。数秒間隔で2～3回テストし、1回だけのタイムアウトと連続してすべて失敗する場合を分けて考えましょう。1つのノードだけ失敗する場合は、まず別のノードを試してください。すべてのノードで同時に失敗する場合は、ローカルネットワーク、システム時刻、サブスクリプションの有効期限、コアのログを確認します。

システムプロキシを有効にしてブラウザーの通信をコアに渡す

WindowsやmacOSのデスクトップ環境では、初回の確認にシステムプロキシを使い、TUNはまだ有効にしない方法がおすすめです。クライアントの「設定 → システムプロキシ」またはホーム画面の「システムプロキシ」スイッチを有効にし、「設定 → ポート」で実際の待ち受けポートを確認します。混合ポートの例として 7890 がよく使われますが、サブスクリプションやクライアントの初期設定、手動変更によって異なります。現在の画面に表示されている値を確認してください。

• Windows：システムの「設定 → ネットワークとインターネット → プロキシ」を開き、プロキシ設定がクライアントと一致していることを確認します。手動プロキシでは、アドレス 127.0.0.1、ポート 7890 がよく使われます。クライアントが自動構成スクリプトを使っている場合は、該当するスクリプト設定を確認してください。手動プロキシのスイッチだけでは判断できません。
• macOS：「システム設定 → ネットワーク → 現在のネットワークサービス → 詳細 → プロキシ」を開き、クライアントが管理するHTTP、HTTPS、またはSOCKSプロキシの設定とポートを確認します。
• ブラウザー：まずシステムプロキシに従うブラウザーでテストします。Firefoxでは「設定 → 一般 → ネットワーク設定 → 接続設定」を開き、「システムのプロキシ設定を利用する」を選択できます。プロキシ拡張機能やブラウザー独自のプロキシ設定が、システム設定より優先される場合があります。

ほかのプロキシ、VPN、ネットワーク診断ツールを同時に使っている場合は、今回の確認中は通信を取り込む機能を停止してください。トラブルシューティングのためにシステムのファイアウォール全体を無効にする必要はありません。クライアント終了後にWebページがまったく開かなくなった場合は、停止したローカルポートをシステムプロキシが参照したままになっていないか、まず確認してください。

AndroidとTUNの違い

Androidクライアントでは通常、システムVPNの許可を使って通信を取り込みます。初回接続時には、システムに表示される権限確認を承認してください。これはデスクトップでHTTPプロキシを設定する方法とは異なります。アプリごとのプロキシ設定や除外アプリのリストによって、テスト対象のブラウザーが取り込まれるかどうかも変わります。デスクトップのTUNは仮想ネットワークインターフェース、ルーティング、権限に関わるため、基本的な接続確認が済んでから、システムプロキシに従わないアプリをテストするときに検討してください。

接続ログでルールとノードを確認

クライアントの「接続 / Connections」を開き、ブラウザーで新しいHTTPSページにアクセスします。できれば新しいタブを開いてください。キャッシュされたページ、既存の長時間接続、バックグラウンドのリクエストが判断を妨げることがあります。アクセスした時刻を記録し、接続一覧から該当するドメインまたは宛先アドレスを探します。

1. 宛先を確認：記録がクライアント自身の遅延テストではなく、いまアクセスしたサイトに対応していることを確認します。
2. ルールを確認：一致したルールの種類と内容を確認します。例：DOMAIN-SUFFIX または最後に適用される MATCH。画面に表示される情報はクライアントによって異なります。
3. プロキシ経路を確認：接続が想定したプロキシグループを使い、最終的に具体的なプロキシノードへ接続していることを確認します。DIRECT や REJECT になっていないかも確認してください。
4. 接続状態を確認：データが送受信されているか、すぐにエラーや切断が発生していないかを確認し、ページが正常に開くかどうかも合わせて判断します。

接続一覧に該当する記録がない場合は、ノードを変更する前に、ブラウザーのプロキシ設定、除外リスト、ポートを確認してください。記録が DIRECT に一致した場合、通信はコアに届いていますが、ルールによって直接接続に振り分けられています。REJECT に一致した場合は、その通信を遮断したルールを特定してください。

さらに詳しく調べるには、ログレベルを一時的に info に設定します。それでも情報が足りない場合は、短時間だけ debug を使い、問題を一度再現したら元に戻してください。ログにアクセス先のドメインが含まれることがあります。共有する前に個人情報を削除してください。IPルール、ドメインルール、DNSマッピングではログの表示形式が異なる場合があります。記録にドメインではなくIPアドレスが表示されるだけで、DNS異常と判断しないでください。

パブリックIPを調べて出口を照合

同じテスト用ブラウザーでパブリックIP確認サービスにアクセスします。たとえば、アドレスバーに https://api.ipify.org と入力します。まずクライアントでこのリクエストに適用されたルールとプロキシ経路を確認し、その後にページに表示されたアドレスを確認してください。対象のプロキシを経由したことを確認できた場合に限り、この結果からプロキシの出口を判断できます。

• 想定した出口が表示される：IP確認リクエストが選択したノードを通り、そのノードのパブリックIPが返され、対象のページも正常に開く場合、ブラウザーのこの接続経路は有効だと判断できます。
• ローカルのIPが表示される：まずIP確認リクエストが直接接続になっていないか調べてください。ルールモードでは一部のサイトが直接接続されます。IPが一度変わらなかっただけで、プロキシ全体が無効だとは限りません。
• ノード名の地域と異なる：IP位置情報データベースの更新が遅れていたり、サービスの入口と出口が異なっていたりする場合があります。地域ラベルは市区町村単位の経路を証明するものではありません。

直接接続時の基準値が必要な場合は、まず現在の設定を記録します。このクライアントのシステムプロキシとTUNを一時的に無効にし、ほかのVPNが通信を取り込んでいないことを確認してから、もう一度IPを調べてください。確認後は元の設定に戻します。通信の取り込みを無効にしたまま、プロキシが必要なサービスへアクセスしないでください。また、異なるプロキシ設定を使っている可能性があるため、別々のブラウザーの結果だけを比較するのも避けてください。

任意：コマンドラインでローカルプロキシポートを確認

以下はWindowsのコマンドプロンプトまたはPowerShellで使える例です。HTTPまたは混合ポートの実際の待ち受けポートを 7890 と仮定しています。別のポートを使っている場合は置き換えてください。SOCKS専用ポートには、このHTTPプロキシ用の指定をそのまま使えません。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

macOSやLinuxでは、curl.exe を curl に置き換えます。このコマンドはローカルプロキシを明示的に指定し、今回のリクエストではプロキシの除外リストを空にします。ブラウザーのシステムプロキシ設定には依存しません。コマンドは成功するのにブラウザーで失敗する場合は、まずブラウザーの設定を確認してください。127.0.0.1:7890 に接続できないと表示される場合は、ポート、コアの稼働状態、待ち受けアドレスを確認します。TLSエラーを隠すために、証明書検証を無効にするオプションを追加しないでください。

初回接続の結果と次の確認項目

初回確認が終わったら、現在の設定名、ルールモード、メインのプロキシグループ、実際のポート、アクセスに成功した時刻を簡潔に記録しておきます。その後ルールを変更したりTUNを有効にしたりする場合は、一度に変更する項目を1つにし、同じサイトで再テストしてください。どの変更が結果に影響したか確認しやすくなります。

最終確認では、アプリのリクエストがコアに届くこと、ルールによって想定したノードに転送されること、接続先へのリクエストが実際に完了することの3点を確認します。スイッチの点灯、遅延の数値、IP確認のいずれか1つだけでは、接続経路全体を確認できません。設定を見直す場合は、使い方ガイドでサブスクリプションとシステムプロキシの設定を確認してください。サブスクリプションの更新に問題がある場合は、ヘルプセンターのサブスクリプション更新ガイドをご覧ください。