トラブル対処 読了時間：約12分

Clashは接続済みなのにWebサイトが開けない？システムプロキシからDNSまでの確認リスト

システムプロキシ、ポート競合、プロキシグループ、ルール、DNS、Fake-IPの順に確認し、接続済みでもネットにつながらない原因を特定します。

1. まず「接続済み」がどの段階を指すか確認する

ClashのGUIクライアントでコアが起動している、システムプロキシが有効になっている、あるいはノードの遅延時間が表示されているからといって、ブラウザーがそのノード経由でアクセスできているとは限りません。Webリクエストは、アプリのプロキシ設定、ローカルの待ち受けポート、ルールとプロキシグループ、ノード接続、ドメイン名の名前解決、接続先サイトを経由します。どこか一つでも問題があれば、「クライアントは正常なのにページが読み込み中のまま」という状態になります。

使用中のクライアント名、コアの種類、現在の設定、モード、ローカルプロキシポートを控えておきましょう。Clash、Clash Meta（現名称はmihomo）、各GUIクライアントではメニュー名が異なる場合があります。以下に出てくる「プロキシ」「接続」「ログ」などの項目名は、実際の画面に合わせて読み替えてください。システム設定の場所は、使用しているOSに応じて確認します。

  1. 現在の設定をバックアップし、システムプロキシとTUNの元の状態を記録します。
  2. 問題を安定して再現できるWebサイトを一つ選び、設定を一度に一つだけ変更して再試行します。
  3. ほかのプロキシ、VPN、ブラウザーのプロキシ拡張機能を使用中の場合は、複数のプログラムがシステム設定を変更しないよう、まずほかのツールを終了します。
  4. ClashのシステムプロキシとTUNを一時的に無効にし、通常のWebサイトへ直接接続できるかテストします。テスト後は元の状態に戻してください。

2. システムプロキシの接続先ポートを確認する

システムプロキシは、この設定に従うアプリに対して、リクエストをどのローカルアドレスへ送るかを指定するものです。端末全体の通信を制御する機能ではなく、コマンドラインツール、ゲーム、独立したアプリがすべてプロキシを使うとは限りません。ブラウザー独自のプロキシ拡張機能がある場合、システム設定より拡張機能の設定が優先されることもあります。

WindowsとmacOSでの確認場所

現在の設定で混合プロキシポートが7890の場合、通常、端末のシステムプロキシアドレスは127.0.0.1、ポートは7890です。ここで示したポートは例なので、クライアントに実際に表示されている待ち受けポートと一致させてください。HTTPプロキシはCONNECTでHTTPS通信も転送できます。WebサイトがHTTPSだからといって、システムプロキシのアドレスをリモートノードのアドレスに変更しないでください。

# ローカルプロキシ項目の例。サブスクリプション設定全体ではありません
mixed-port: 7890
allow-lan: false
mode: rule

mixed-portはHTTPとSOCKSの両方のプロキシ接続を受け付けます。portとsocks-portを別々に設定している場合は、それぞれを区別してください。SOCKS専用ポートをシステムHTTPプロキシに指定することはできません。変更後はクライアントで設定を再読み込みし、画面に表示される実際のポートを確認してください。GUIクライアント側の上書き設定とファイルの内容が食い違う場合があります。

3. ポートと明示的なプロキシ接続で原因を絞り込む

システムプロキシの設定が正しく見えても、ローカルポートが待ち受けていなければブラウザーは接続できません。クライアントのログを開き、起動失敗、設定の解析エラー、address already in use、bindエラーを確認してください。ポートが使用中の場合は、使用しているプロセスを特定します。見覚えのないシステムプロセスを強制終了しないでください。

7890番ポートが待ち受け中か確認する

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOSまたはlsofをインストール済みのLinux
lsof -nP -iTCP:7890 -sTCP:LISTEN

Windowsでは、確認したプロセスIDをGet-Process -Idに渡してプロセス名を確認できます。macOSとLinuxでは、通常、出力にプロセス名も表示されます。待ち受けが見つからない場合は、コアが実際に起動しているか、ポートが変更されていないか、待ち受けアドレスに127.0.0.1が含まれているかを確認してください。同じ端末でクライアントを2つ起動している場合は、使っていない方を終了します。

システム設定を介さず、プロキシを直接指定する

Windowsではcurl.exeを使い、旧バージョンのPowerShellでcurlが別名として動作する場合の違いを避けます。macOSとLinuxでは、以下のコマンドのcurl.exeをcurlに置き換えてください。まずは接続確認先としてexample.comを使い、その後、実際にアクセスできないWebサイトのURLに置き換えて比較します。

# ローカルのHTTP混合プロキシポートを明示して接続
curl.exe --noproxy "" -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

# アプリケーション層プロキシを使用しない場合の比較
curl.exe --noproxy "*" -I --connect-timeout 10 --max-time 20 https://example.com/
結果次に確認する項目
127.0.0.1にすぐ接続できないポート、待ち受けアドレス、コアの稼働状態を確認します。
明示的なプロキシ接続は成功するが、ブラウザーでは失敗するシステムプロキシ、ブラウザー拡張機能、ブラウザー独自のDNS設定を確認します。
ローカル接続は成功するが、その後のハンドシェイクがタイムアウトするノード接続ログ、プロキシグループ、ドメイン名の名前解決結果を確認します。
接続先サイトからHTTPレスポンスを受信するアプリケーション層のレスポンスを受信しています。403や405などのステータスは、サイト側のアクセス制限も考慮して判断してください。

注意：--noproxy "*"が回避するのはアプリケーション層のプロキシだけです。TUNが有効なままの場合、リクエストは仮想ネットワークインターフェースに取り込まれる可能性があり、本当の直接接続との比較にはなりません。HEADリクエストを受け付けないサイトもあります。405が返る場合は-Iを外し、通常のGETでテストしてください。

4. 遅延時間だけで判断せず、プロキシグループを確認する

ノードの遅延テストは、通常、特定のテスト先への接続を確認するものです。テストに成功しても、すべてのWebサイトにアクセスできるとは限りません。サブスクリプションの更新成功が示すのは、設定のダウンロードと解析ができたことだけです。ノードが利用可能であること、アカウントの通信量が残っていること、接続先サイトがその出口からのアクセスを許可していることまでは保証されません。

  1. クライアントの「プロキシ」または「プロキシグループ」画面を開き、対象の通信で実際に使われるグループを確認します。
  2. そのグループで最終的に選択されているのが、具体的なノード、別のプロキシグループ、DIRECT、REJECTのどれかを確認します。
  3. 利用できることが分かっているノードを手動で選択し、Webページへの接続をやり直します。遅延テストを一度実行しただけで確認を終えないでください。
  4. プロキシグループが多段構成の場合は、最終的な選択先まで順に確認します。外側では「プロキシ」と表示されていても、内側で直接接続に切り替わっている場合があります。

比較のため、短時間だけグローバルモードに切り替え、グローバルプロキシグループで実際に使用するノードが選択されていることを確認します。グローバルモードでは接続でき、ルールモードでは失敗する場合は、ルールとグループを優先して確認してください。両方で失敗する場合は、ノードのハンドシェイク、ネットワークの遮断、DNSを引き続き確認します。テスト後は元のモードに戻し、グローバルモードを恒久的な解決策にしないでください。

5. 接続ログで適用されたルールを確認する

ルールモードでは通常、設定の記述順に照合され、最初に一致したルールに対応するプロキシポリシーが適用されます。広範囲に一致するルールが前方にあると、後ろにあるドメインルールが適用されないことがあります。ルール名だけで結果を判断せず、「接続」または「ログ」でテスト対象のドメイン、適用されたルール、使用したポリシー、最終的なノードを確認してください。

# ルール順の例。Proxyは設定に存在するプロキシポリシー名にしてください
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

上記は照合順序の説明用であり、すべてのサブスクリプションに使えるルールテンプレートではありません。MATCHはフォールバックルールなので、優先して照合するルールより後ろに置きます。元の設定でルールセットを使用している場合は、該当するルールセットが正常に読み込まれているか、対応するプロキシポリシーが存在するかも確認してください。

ルール項目の意味は設定項目の説明を参照してください。サブスクリプションから生成されたファイルを変更する場合は、まずクライアントがサポートする上書き・マージ機能を利用します。キャッシュファイルを直接編集すると、次回のサブスクリプション更新時に変更が上書きされることがあります。

6. 端末のDNS、コアのDNS、Fake-IPを区別する

DNSの問題への対処は、「別のサーバーに変更する」だけではありません。システムの名前解決、ブラウザーのセキュアDNS、コアのDNS、プロキシサーバーのアドレス解決では、異なる経路が使われる場合があります。まずログでlookupの失敗、DNSリクエストのタイムアウト、リモートIPへの接続タイムアウト、TLSハンドシェイクの失敗を区別し、どの段階を変更するか判断してください。

システムで名前解決できても、コアで正常に解決できるとは限らない

nslookup example.comを実行すると、システムの既定DNS経路での結果を確認できます。ただし、ブラウザーでセキュアDNSが有効になっている場合や、プロキシコアが独自に名前解決する場合は、この経路が使われるとは限りません。mihomoのnameserverにDoHアドレスを指定している場合は、DoHサービスに到達できるか、ホスト名の初期名前解決が完了するか、DNSリクエストの経路が設定どおりかも確認してください。

たとえば上流サーバーにhttps://dns.example.com/dns-queryを指定しても、ネットワークに到達できない問題が自動的に解決するわけではありません。この形式は構文例にすぎず、例示されたドメインを利用可能なDNSサービスとして使わないでください。ノードアドレスがドメイン名の場合は、ノードのドメイン名を解決できているかも確認します。ノード接続前に、そのノードを使ってDNSサービスへアクセスしようとする循環依存を避けてください。

198.18のアドレスはFake-IPの正常な結果である可能性がある

Fake-IPモードでは、DNSが198.18.0.0/16の範囲のアドレスを返すのは一般的な設定動作です。これらのアドレスはコア内でのマッピングに使われ、Webサイトの実際のグローバルIPアドレスではありません。これだけでDNSの汚染を示すわけではありません。重要なのは、その後の接続が同じコアによって処理され、対応するドメイン名のマッピングを見つけられるかどうかです。

# Windows：システムDNSキャッシュをクリア
ipconfig /flushdns

# macOS：システムの名前解決キャッシュをクリア。2つ目のコマンドには管理者権限が必要
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

キャッシュをクリアしても、上流サーバーの設定ミスは直らず、ブラウザー独自のキャッシュも消えるとは限りません。DNSを変更するたびにコア設定を再読み込みし、新しいテスト接続を作成してください。上流サーバー、Fake-IPモード、すべての振り分けルールを同時に変更すると、アクセスが復旧しても原因を特定しにくくなります。

7. システムプロキシは使えるのにTUNが使えない場合は、ルーティングを確認する

TUNは仮想ネットワークインターフェースを通じて対象の通信を取り込みます。システムHTTPプロキシとは入口が異なります。最も有効な比較方法は、TUNを無効にしてシステムプロキシだけでブラウザーをテストし、接続できることを確認してからTUNを有効にし、違いを確認することです。AndroidのVPNインターフェースとデスクトップのTUNには関連がありますが、権限やルーティングの管理はプラットフォームごとに異なるため、共通のメニュー手順はありません。

  1. 権限とサービスを確認：クライアントにサービスのインストール、VPN権限、ネットワーク拡張機能の許可を求める表示がないか確認します。権限がなければ、スイッチが有効に見えてもルートが正常に構築されているとは限りません。
  2. ほかのVPNを除外：別のVPN、セキュリティソフト、仮想ネットワークインターフェースがデフォルトルートやDNSを変更している可能性があります。条件を管理しながら一つずつ終了し、結果を比較してください。
  3. DNSの取り込みを確認：設定のDNS待ち受けとdns-hijackが、現在のコアとプラットフォームでサポートされる範囲に合っているか確認します。すべてのDNS通信が取り込まれると決めつけないでください。
  4. IPv6を確認：失敗した接続がIPv6を使っている場合は、現在のルート、ノード、設定がその経路に対応しているか確認します。コアのIPv6名前解決オプションを無効にしても、アプリが既存のIPv6アドレスを使うのを必ず防げるわけではありません。

MTUの変更やファイアウォールの無効化を最初に試さないでください。小さなリクエストは成功するのに大きなデータ転送が止まり、ルートとノードが正常だと確認できている場合に限り、MTU、Path MTU Discovery、UDP転送を追加で確認します。ファイアウォールを調べる際は、システムの保護機能を長時間無効にするのではなく、まずクライアントの通信許可ルールを確認してください。

8. 結果を記録し、失敗した段階から原因を絞り込む

ここまでの確認で問題を特定できない場合は、「何度も再インストールした」という情報より、失敗したリクエストの内容を整理する方が役立ちます。テスト時刻、対象ドメイン、システムプロキシのポート、モード、プロキシグループ、適用されたルール、ログに最初に現れた関連エラーを記録してください。特定のサイトだけが失敗する場合は、サイトのメンテナンス、アカウント制限、接続元アドレスへの制限も考慮します。

エラーまたは現象優先して確認する項目
connection refusedエラーに記載された接続先アドレスを確認し、ローカルポートが待ち受けていないのか、リモートサービスに接続を拒否されたのかを区別します。
lookup failedまたはDNS timeout名前解決の対象がWebサイト、ノードのドメイン名、DNS上流サーバーのどれかを確認し、該当する名前解決経路にアクセスできるか調べます。
TLSまたは証明書エラーシステム時刻、証明書のホスト名、ノードのパラメーター、ネットワークにログイン認証ページがあるかを確認します。
ブラウザーだけで失敗するプロキシ拡張機能、独自のセキュアDNS、キャッシュ、ブラウザーの設定。
TUNだけで失敗する権限、仮想ネットワークインターフェース、ルート、DNSの取り込み、ほかのVPNとの競合。

証明書エラーは、システム時刻、設定、信頼チェーンを確認して対処してください。証明書検証のスキップを通常の解決策にしないでください。ログレベルを一時的に上げる場合は、問題を一度だけ再現した後、通常のレベルに戻します。共有する前に、サブスクリプションURL、アクセストークン、ノードのパスワードなどの個人情報を削除してください。

最終的に確認したいのは3点です。ブラウザーのリクエストがコアに届いているか、コアが想定したルールとノードを選択しているか、DNSとリモート接続がそれぞれどの段階で成功または失敗しているか。この順に確認すれば、「接続済みなのにネットにつながらない」という問題を具体的な原因に絞り込めます。システムプロキシ、ノード、DNSをやみくもに何度も変更する必要はありません。

Clashをダウンロード