Clashの初回接続チェックリスト｜速度テストからプロキシ動作確認まで

1. サブスクリプションを読み込んだら、設定が有効か確認する

サブスクリプションの読み込みに成功しても、クライアントに設定内容が取り込まれただけです。ブラウザーの通信をプロキシ経由にするには、設定の有効化、プロキシグループでのノード選択、通信の取り込みが必要です。初回接続では、まずシステムプロキシでブラウザーのリクエストを確認し、問題の切り分けが難しくならないようTUNモードは一時的にオフにしておきましょう。

クライアントによって設定画面の名称は「設定」「サブスクリプション」「Profiles」など異なります。該当する画面を開き、「更新成功」という表示だけで判断せず、次の4項目を確認してください。

1. 現在の設定：読み込んだ項目が選択または有効になっていること。リストに保存されているだけでは不十分です。
2. 更新日時：手動で更新し、認証エラー、ダウンロードのタイムアウト、解析エラーがないことを確認します。
3. コアの状態：Clashまたはmihomoが起動しており、ログに設定の読み込み失敗やポート競合などのエラーがないことを確認します。
4. プロキシグループの内容：ノードまたは読み込み済みのプロバイダーが表示されていること。空のグループやDIRECTしか表示されない場合は要確認です。

設定に未対応の項目があると表示された場合は、まずサブスクリプションが要求するコアを確認してください。Clashとmihomoで対応する設定機能は完全には一致しません。システムプロキシを何度もオン・オフしても、設定構文やプロトコルの互換性の問題は解決しません。まずコアが設定を正常に読み込める状態にしてください。

2. プロキシグループでノードを選び、遅延をテストする

クライアントの「プロキシ」または「Proxies」画面を開き、既定のプロキシグループを探します。グループ名はサブスクリプションによって異なり、「ノード選び」の場合もあれば、別の名前の場合もあります。まずルールが最終的にどのグループを使うか確認してから、そのグループ内でノードを選択します。グループが別のプロキシグループを内包している場合は、最終的な出口が分かるまで階層をたどってください。

遅延の数値から分かること

クライアントの遅延テストは通常、ノード経由で指定のテストURLにアクセスするもので、単純なICMP Pingではありません。結果はテスト先、タイムアウト設定、DNS、テスト時の回線状況によって変わります。現在接続できるノードを絞り込む目安にはなりますが、ダウンロード速度を直接示すものではなく、すべてのサイトにアクセスできる保証にもなりません。

• まず2～3個のノードをテストします。できるだけ同じテスト先とタイムアウト条件を使ってください。
• 3回連続でテストし、安定性を確認します。1回だけの最小値でノードを決めないようにしましょう。
• 不要な通信量を抑えるため、まず通常のウェブサイトにアクセスできるか確認し、その後に大容量ファイルの速度を測定します。

たとえば、ある回線の結果が3回とも85、92、88ミリ秒だった一方、別の回線は45ミリ秒、タイムアウト、310ミリ秒だったとします。最低遅延は前者のほうが大きくても、ばらつきが小さいため、初回接続の確認には適しています。これは結果の見方を示す例であり、特定ノードの実測値ではありません。

タイムアウトと自動選択への対処

特定のノードだけがタイムアウトする場合は、同じグループの別ノードを試します。すべてタイムアウトする場合は、ローカルネットワーク、サブスクリプションの有効期限、システム時刻、コアのエラーを確認してください。テスト先自体にアクセスできず、一斉にタイムアウトすることもあるため、実際に利用するサイトでも確認しましょう。

url-testの自動テストグループを選択している場合、現在の出口はテスト結果によって決まります。fallbackグループは通常、利用可能かどうかと設定順に基づいて選択します。load-balanceグループでは、接続ごとに異なるノードが使われることがあります。初回の確認を再現しやすくするため、いったん手動選択グループでノードを固定し、確認が終わったら自動選択に戻すとよいでしょう。

3. ルールモードにして、システムプロキシを有効にする

デスクトップクライアントの初回確認には、ルールモードがおすすめです。設定内のrulesを上から順に照合し、リクエストはプロキシグループに送られる場合もあれば、DIRECTやREJECTに振り分けられる場合もあります。一方、システムプロキシは、OSのプロキシ設定に従うアプリのリクエストをローカルの待ち受けポートに送ります。役割が異なるため、それぞれ個別に確認が必要です。

「グローバルモード」にしても、システムの全通信が自動的にプロキシ経由になるわけではありません。コアに入っていない接続は、グローバルモードに切り替えてもプロキシされません。ブラウザーのプロキシ拡張機能、アプリ独自のプロキシ設定、システムプロキシが互いに優先設定を上書きすることもあります。切り分けの際は、まず追加のプロキシ拡張機能をオフにしてください。

ローカルアドレスと待ち受けポートを確認する

クライアントの設定でHTTPポートまたは混合ポートを確認します。一般的な例は127.0.0.1:7890ですが、実際の値は現在の設定に従ってください。mixed-portはHTTPとSOCKSのプロキシリクエストを受け付けます。external-controllerは制御用インターフェースであり、ブラウザーのプロキシポートとしては使えません。

• Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」で、クライアントが設定したアドレスとポートを確認します。初回はクライアントのシステムプロキシ切り替え機能を使うのがおすすめです。
• macOS：「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」で、現在有効なプロキシ設定を確認します。OSのバージョンによって、メニュー名が多少異なる場合があります。

同じ端末で使うだけなら、「接続成功」のためにLANアクセスを許可したり、制御インターフェースを公開したりする必要はありません。待ち受けポートが競合している場合は、そのポートを使用している別のプロキシアプリを終了してから、現在のクライアントを再起動してください。

4. 接続ログでルールと使用ノードを確認する

システムプロキシを有効にしたら、クライアントの「接続」または「Connections」画面を開き、ブラウザーで新しいタブを開いて確認対象のサイトにアクセスします。総通信量の変化ではなく、直前に発生したリクエストを探してください。短時間で終了する接続もあるため、必要に応じてログ画面も確認します。

1. 接続先：ドメイン名または接続先アドレスが、アクセスしたサイトと一致しているか確認します。
2. 適用ルール：ドメインルール、ルールセット、地域ルール、末尾のMATCHのどれに一致したか確認します。
3. ポリシーチェーン：表示がDIRECTなのか、想定したプロキシグループと最終ノードなのか確認します。
4. 通信状況：送受信データが発生しているか、接続失敗やタイムアウトが続いていないか確認します。

リクエストがDIRECTに一致している場合、その通信はコアに入ったものの、直接接続に振り分けられています。システムプロキシが機能していないという意味ではありません。反対に、関連する接続記録がまったくない場合は、アプリがシステムプロキシに従っているか、ページがキャッシュから表示されていないか、クライアントが一部の接続を非表示にしていないかを確認してください。mihomoの設定でログレベルが低く設定されていたり、該当ログが非表示になっていたりすることもあるため、画面に記録がないことだけで結論を出さないでください。

対象リクエストは確認できるのに想定外のノードを通る場合は、プロキシグループの入れ子、負荷分散の使用、クライアントが前回の選択を復元していないかを確認してください。ルール、DNS、TUNの設定を同時に変更するより、一時的にノードを固定するほうが原因を特定しやすくなります。

5. 外部IPを照合し、プロキシが機能しているか確認する

接続ログからは「リクエストがどの経路を通ったか」が分かり、外部IPからは「外部サービスにどのアドレスが見えているか」を確認できます。両方を照合するのが確実です。まずシステムプロキシとTUNをオフにして直接接続時のIPを記録し、次にシステムプロキシをオンにしてノードを固定し、同じIP確認サービスで再度調べます。テスト中はほかのVPNを同時に使わないでください。直接接続の基準値も、別のトンネルを経由している可能性があります。

ルールモードでは、IP確認サービスへの通信自体が直接接続に設定されていることがあります。外部IPが変わらない場合は、まずそのリクエストに適用されたルールを確認してください。ルールの影響を切り分けるには、一時的にグローバルモードにして、グローバルの接続先を対象ノードに設定します。確認後はルールモードに戻してください。

コマンドラインでローカルプロキシとシステム経由を切り分ける

ここでは混合ポート7890を例にします。1つ目のコマンドはプロキシを明示的に経由せず、2つ目はローカルHTTPプロキシへの接続を明示します。実行前にTUNをオフにし、ほかのVPNがルーティングを制御していないことを確認してください。ポートはクライアントの実際の待ち受けポートに置き換えます。問い合わせ先には、リクエストとその送信元アドレスが通知されます。

# macOS / Linux：直接接続のリクエスト
curl --noproxy "*" --max-time 15 https://api.ipify.org

# macOS / Linux：ローカルプロキシを明示して接続
curl --noproxy "" --proxy http://127.0.0.1:7890 --max-time 15 https://api.ipify.org

Windows PowerShellでは、一部の環境でcurlが別のコマンドとして解釈されるのを避けるため、curl.exeを明示することをおすすめします。プロキシを明示してテストする前に、現在のターミナルのNO_PROXY環境変数を一時的に削除してから実行してください。

Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue
curl.exe --proxy http://127.0.0.1:7890 --max-time 15 https://api.ipify.org

プロキシを明示したコマンドが成功すれば、ローカルポートと該当するリクエスト経路が使えることを確認できます。ただし、それだけではシステムプロキシが正しく設定されている証明にはなりません。ブラウザーに戻り、ブラウザーのリクエストが実際にコアに入っていることをログで確認してください。

出口地域を示すデータベースは更新が遅れることがあり、ノード名と実際の出口都市が一致するとも限りません。IPv4とIPv6で結果が異なる場合もあります。国旗アイコンだけで判断せず、確認時刻、アドレスの種類、適用されたポリシー、出口アドレスを記録してください。IPが同じでも、ルールとポリシーチェーンを合わせて確認し、共有出口やアドレスファミリーの違いによる現象を接続障害と誤認しないようにしましょう。

6. ブラウザーは使えるのに他のアプリがつながらない場合はTUNを確認する

システムプロキシは通信を透過的に取り込む機能ではありません。一部のゲーム、コマンドラインツール、独自のネットワークスタックを持つアプリはシステムプロキシを参照しません。また、通常のHTTPシステムプロキシだけでUDP通信を取り込めるとは限りません。まずアプリがHTTPまたはSOCKSプロキシを個別に設定できるか確認し、そのうえでクライアントのTUNモードを使うか検討してください。

TUNは仮想ネットワークインターフェースとルーティング設定を使って、条件に合う通信をコアに送ります。デスクトップでは管理者権限、サービスモード、ネットワーク拡張の許可が必要な場合があります。Androidクライアントでは通常、システムのVPNインターフェースを利用します。必要な権限や設定場所はクライアントとOSによって異なるため、別のプラットフォームのメニューをそのまま参考にしないでください。

• まずシステムプロキシ経由の通信が正常に動作することを確認してから、TUNを個別にテストします。ノードの問題とルーティングの問題を同時に調べるのを避けられます。
• ほかのVPN、仮想マシンのネットワーク、企業ネットワークのポリシーとの競合を確認します。
• 有効にした後、対象アプリの接続記録を改めて確認します。「TUNが起動した」だけで、プロキシ接続成功と判断しないでください。
• LAN内のデバイスに接続できなくなった場合は、ファイアウォールをすぐに無効にするのではなく、ルート除外と直接接続のルールを確認してください。

IPアドレスには接続できるのにドメイン名を解決できない場合は、DNS設定とコアの名前解決ログを確認してください。システムプロキシ経由の名前解決、TUNでのDNSリダイレクト、fake-ipのマッピングはそれぞれ異なる仕組みです。初回確認ではDNS設定一式を安易にコピーせず、動作中の設定を保ったまま、どのドメインのどの名前解決リクエストが失敗したかを調べましょう。

7. よくある失敗と確認手順

一度に変更する項目は、ノード、モード、ポート、接続方式のいずれか1つにしてください。変更前後の状態を記録すると、効果のあった対処を特定しやすくなります。証明書エラーが発生した場合は、システム時刻と対象サイトの証明書情報を確認してください。初回接続のテストでTLS検証を無効にしないでください。

8. 初回接続が完了した後のチェックリスト

• 現在のサブスクリプションが有効で、コアに継続的なエラーが出ていない。
• 既定のプロキシグループと最終ノードを把握している。速度テストの数値だけに頼らない。
• システムプロキシのアドレスと実際の待ち受けポートが一致している。
• 対象リクエストが接続ログに記録され、想定したポリシーに一致している。
• 外部IPとログの判断が一致し、直接接続ルールとプロキシルールを区別できている。
• 普段使うルールモードに戻し、一時的なテスト変更を元に戻している。
• クライアントを終了する前にシステムプロキシをオフにするか、クライアントがシステム設定を正しく復元できることを確認している。

これらの条件を満たせば、サブスクリプションの読み込みから実際のアクセスまで一通り確認できています。その後、特定のサイトやアプリだけに問題が起きた場合は、まず個別のルール、名前解決、接続ログを確認しましょう。クライアントを再インストールするところから始める必要はありません。基本操作はシステムプロキシの設定方法を、詳しいトラブルシューティングは接続確認のドキュメントを参照してください。