プロキシ接続中なのにWebサイトが開かない原因と対処法｜システムプロキシ・DNS・ルールの確認

1. クライアントの接続状態と実際の通信を切り分ける

Clash系クライアントに「接続済み」と表示されても、Mihomoコアが起動している、システムプロキシが有効になっている、AndroidのVPNインターフェースが確立している、といった状態を示すだけの場合があります。ブラウザーの通信がコアに届いていることや、現在のノードから目的のWebサイトへ接続できることを保証する表示ではありません。「アプリ → ローカルの接続口 → ルールとプロキシグループ → 出口ノード → 接続先サービス」の順に確認しましょう。

まず、次の3点を記録します。すべてのWebサイトに接続できないのか、一部だけ失敗するのか。ブラウザーだけなのか、ほかのアプリも失敗するのか。プロキシを無効にすると、直接接続できていたサイトは開けるのか。同じ完全なURLを使って繰り返しテストし、サイトごとに異なる接続条件を混同しないようにします。

確認された症状	優先して確認する項目	次に確認する情報
Webサイトを開いても新しい接続記録がない	システムプロキシ、アプリ個別のプロキシ、TUNによる通信の取り込み	ローカルプロキシを明示してテスト
ローカルポートへの接続がすぐ拒否される	コアの起動状態、待ち受けポート、ポートの競合	ポートを待ち受けているプロセス
ログにドメインの名前解決タイムアウトが記録される	DNSの上流サーバー、ノードのドメイン解決、DNSのルーティング	失敗したドメインと使用したDNSサーバー
通信がDIRECTまたはREJECTに振り分けられる	ルールの順序、ルールセット、プロキシグループ	実際に適用されたルール
プロキシノードを選択しているが、外向き通信がタイムアウトする	ノードのアドレス、認証情報、トランスポート設定、ネットワーク制限	ノードとネットワークを切り替えた場合の比較結果

2. システムプロキシの接続先がMihomoか確認する

システムプロキシは、システム設定に従うアプリにプロキシの接続先を知らせる機能であり、すべてのプログラムの通信を自動的に取り込むわけではありません。ブラウザー拡張機能、ターミナルツール、ゲーム、ほかのVPNソフトは独自のネットワーク設定を使う場合があります。まずブラウザーのプロキシ拡張機能とほかのプロキシクライアントを一時的に無効にし、接続口を1つだけにします。

システム設定とローカルアドレスを確認する

Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「手動プロキシセットアップ」のアドレスとポートを確認します。セットアップスクリプトを使っている場合は、ブラウザーの通信が引き続きそのスクリプトに制御されていないかも確認してください。
macOS：「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」を開き、Webプロキシ、安全なWebプロキシ、SOCKSプロキシの設定を確認します。メニュー名はmacOSのバージョンによって多少異なる場合があります。
Android：システムにVPNアイコンが表示されていても、それはVpnServiceのインターフェースが存在することを示すだけです。アプリごとのプロキシ設定でブラウザーが対象外になっていないかも確認してください。

以下では、127.0.0.1:7890をローカルの混合プロキシポートとして使用します。7890は例であり、すべてのクライアントで共通の値ではありません。現在有効な設定、またはクライアントのポート設定で実際の値を確認してください。external-controllerは制御用インターフェースであり、Webプロキシのポートとしては使用できません。

プロキシを明示してシステム設定を介さずにテストする

WindowsではPowerShellでcurl.exeを使い、古い環境で同名のコマンドエイリアスが使われることによる違いを避けます。macOSとLinuxでは、以下のcurl.exeをcurlに置き換えてください。対象URLの例はhttps://example.com/です。現在のネットワークからアクセスできない場合は、アクセス可能と確認済みのHTTPSアドレスに変更してください。

curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" -x http://127.0.0.1:7890 https://example.com/ -o NUL

macOSとLinuxでは、出力先のNULを/dev/nullに置き換えます。--noproxy ""を指定すると、環境に設定されたプロキシ除外リストが今回の明示的なプロキシテストに影響するのを防げます。タイムアウトの上限は10秒と20秒です。これはトラブルシューティング用の設定であり、ノード速度の測定値ではありません。

コマンドは成功するのにブラウザーでは失敗する場合は、システムプロキシ、ブラウザー拡張機能、独自プロキシ設定、接続キャッシュを優先して確認してください。
127.0.0.1に接続できないと表示される場合は、まずローカルポートを確認してください。すぐにDNSを変更する必要はありません。
CONNECTが成功した後にTLSやリモート接続のエラーが出る場合、少なくともプロキシの接続口までは到達しています。引き続き外向きの通信経路を確認してください。

3. ポート競合とコアの起動失敗

クライアントのウィンドウが開いていても、コアが設定を正常に読み込めたとは限りません。コアのログを確認し、address already in use、設定の解析失敗、ルールセットの読み込みエラー、権限エラーがないか調べてください。ローカルポートを古いプロセスが使用している場合、ブラウザーが別のプロキシプログラムに接続している可能性もあります。

ポートを待ち受けているプロセスを確認する

Windows PowerShellではTCPの待ち受けポートを調べ、表示されたプロセスIDからプログラムを確認できます。以下のコマンドは情報を照会するだけで、プロセスを終了しません。

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

Get-Process -Id 1234

1234は説明用のプロセスIDです。2つ目のコマンドを実行する前に、1つ目のコマンドで実際に返されたOwningProcessの値に置き換えてください。macOSではlsof -nP -iTCP:7890 -sTCP:LISTEN、Linuxではss -lntp 'sport = :7890'を実行します。ほかのユーザーのプロセス情報を確認するには、適切な権限が必要な場合があります。

システムプロキシを有効な設定に合わせる

# ローカル混合プロキシの例。関連する項目の説明用
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

この例は完全なサブスクリプション設定ではありません。ノードやルールの設定をこの内容で上書きしないでください。ポートを7891に変更した場合は、システムプロキシとテストコマンドのポートも合わせて変更します。クライアントによっては、上書き設定や設定のマージによって最終的なファイルが生成されるため、サブスクリプションの原文だけでなく「実際に有効な設定」を確認してください。ループバックアドレスを使えばローカルの接続口に限定でき、ローカルのインターネット接続を直すためにLANアクセスを有効にする必要もありません。

4. DNSのトラブル対処：接続先ドメインとノードのドメインを切り分ける

「DNSエラー」には少なくとも2つの可能性があります。接続先Webサイトのドメインを解決できない場合と、プロキシサーバー自体のドメインを解決できない場合です。後者では、各サイトのDNS応答が正常でも複数のサイトが同時にタイムアウトすることがあります。ログを確認するときは、単にtimeoutと表示されているかだけでなく、エラーが発生した具体的なドメインを記録してください。

まずシステムの名前解決を確認し、次にコアのログを見る

nslookup example.com

nslookupは通常、システムで選択されているDNSサーバーに問い合わせます。TUNによる通信の取り込みやネットワークリダイレクトが有効な場合、問い合わせがそちらに処理されることもあります。その結果だけでMihomoのすべてのDNS問い合わせ経路を判断することはできません。ブラウザーのセキュアDNS、システムの暗号化DNS、コア内蔵のDNSも、それぞれ異なる経路を使う場合があります。

DNSが有効か確認：有効な設定でdns.enableが有効になっているか、また使用するnameserverに現在のネットワークから到達できるかを確認します。
暗号化DNSの依存関係を確認：DoHまたはDoTの上流サーバーにドメイン名を指定している場合、名前解決に使えるブートストラップ経路が必要です。default-nameserverはDNSサーバーのドメイン名を解決するために使用できます。上流サーバーのアドレスとの依存関係も確認してください。
プロキシノードの名前解決を確認：proxy-server-nameserverはプロキシノードのドメイン名を解決するための設定です。設定している場合は、指定したDNSサーバーが利用できるか確認してください。ノードとの接続を確立する前から、同じノード経由の名前解決に依存しないようにします。
ルールとの依存関係を確認：respect-rulesなど、DNS通信にもルーティングルールを適用する設定を使う場合は、関連するプロキシと直接接続用のDNSサーバーも確認してください。名前解決とプロキシの間で循環依存が発生しないようにします。

Fake-IPから別の名前解決モードに切り替えた後も、アプリが古いアドレスを保持していることがあります。Windowsではipconfig /flushdnsを実行してシステムのキャッシュを消去し、ブラウザーを完全に終了してから再起動してください。システムのキャッシュを消去しても、ブラウザー独自のキャッシュ、DoHのキャッシュ、確立済みの接続が同時に消えるとは限りません。リクエストを新たに実行し、ログと照らし合わせてください。

DNSモード、すべての上流サーバー、TUNの設定を一度に変更しないでください。まず利用できると確認済みの名前解決経路を確保し、その後に設定を1項目ずつ戻します。設定項目の意味はDNS設定ガイドも参照してください。

5. ルールとプロキシグループ：モードだけでなく実際の出口を確認する

Mihomoのルールモードでは、ルールが上から順に評価されます。通常、最初に一致したルールで通信先が決まり、末尾のMATCHがそれ以前のルールに一致しなかった通信を処理します。対象ドメインが上位のルールによってDIRECTに振り分けられると、後続のプロキシルールで再び経路を変更することはできません。

接続の詳細で次の4項目を確認する

対象のドメインとポートが、直前にテストしたWebサイトと一致しているか。HTTPSは通常、TCPの443を使います。
一致したルールの種類と内容。特にドメインルール、ルールセット、フォールバックルールを確認します。
適用されたプロキシグループと、そのグループで最終的に選ばれたノードまたはDIRECT。
失敗した段階が、名前解決、接続、プロキシハンドシェイク、TLSのどれか。

まずクライアントの接続一覧を消去するか、テスト時刻を記録してから対象のWebサイトを開きます。古い接続の再利用で判断しにくい場合は、該当する接続を閉じて再試行してください。プロキシグループ名は選択の入口にすぎず、グループ内に別のグループが含まれる場合もあります。最終的な出口まで追跡しましょう。

全般モードは短時間の比較にだけ使う

一時的に全般モードへ切り替え、ノードを明示的に選択します。同じ接続先が全般モードでは開けてルールモードでは失敗する場合は、ルールの順序とプロキシグループの選択を重点的に確認してください。両方のモードで失敗する場合は、ノードとネットワークを確認します。全般モードでも、利用できないノードは直らず、コアに届いていないアプリの通信が自動的に取り込まれるわけでもありません。

ルールセットのダウンロード失敗が、設定の読み込みや通信の振り分けに影響することもあります。rule-providersの更新ログとローカルキャッシュの状態を確認してください。Webサイトを一時的に開くためにルール一式を削除するのではなく、まず実際に適用されたルールを特定し、必要な順序や方針だけを変更します。調査後は元のルールモードに戻してください。

6. ノードの利用可否：遅延の数値だけではWebサイトに接続できるとは限らない

遅延テストは、指定したテストURL、時刻、現在のネットワークにおける1回の応答を示します。遅延が表示されても、別のドメイン、動画サービス、UDP通信が利用できるとは限りません。ノード一覧に表示されていても、サブスクリプションに記載されたアドレス、ポート、認証情報が現在も有効とは限りません。

ネットワークはそのままノードを変更：ブラウザー、対象URL、プロキシモードを変えず、ノードだけを切り替えます。別のノードですぐに復旧する場合は、元のノードやサーバーの状態を優先して確認してください。
ノードはそのままネットワークを変更：Wi-Fiからスマートフォンのテザリングに切り替え、同じ接続先にアクセスします。結果が異なる場合は、接続先ネットワークのDNS、ファイアウォール、ルーティングをさらに確認してください。
サブスクリプションの更新日時を確認：更新が成功し、古いキャッシュを使い続けていないことを確認します。更新後は、クライアントの上書き設定がノード関連の設定を上書きしていないかも確認してください。
プロトコルの設定を確認：手動設定の場合は、サーバーアドレス、ポート、認証情報、TLSのサーバー名、トランスポート設定を確認します。必要な項目はプロトコルによって異なるため、別のプロトコル用の設定をそのまま組み合わせないでください。

connection refusedは、接続先ポートで待ち受けていない場合や、明示的に拒否された場合によく発生します。i/o timeoutは応答待ちのタイムアウトを示しますが、このログだけでサーバーの障害か途中のネットワークでのパケット損失かは判断できません。証明書エラーが発生した場合は、システム時刻、接続先ドメイン、TLS設定を確認してください。ハンドシェイクエラーを隠すために、証明書の検証を恒久的に無効化しないでください。

ログインページや特定のWebサイトだけで失敗する場合は、サイトが返すHTTPステータスコードも確認してください。403、429、アカウント制限は、「ローカルのプロキシポートが起動していない」問題とは別です。応答が接続先サービスから返されたことを確認してから、出口IPの方針やサイト側の制限を検討してください。

7. TUN、アプリ別プロキシ、ブラウザーのプロトコルを追加で確認する

HTTPプロキシを明示したテストは正常なのに、TUNを有効にするとアクセスできない場合、切り分けに役立つ手がかりになります。TUNは仮想ネットワークアダプター、ルーティング、権限に依存します。tun.auto-route、インターフェース検出、DNSのリダイレクトを有効にしている場合は、ほかのVPN、仮想マシンのネットワーク、セキュリティソフトとの競合も確認してください。

デスクトップではまずTUN経由の通信を切り分ける

現在のTUNとシステムプロキシの状態を記録し、TUNを一時的に無効にします。
先ほどのプロキシを明示したコマンドだけを使い、同じURLをテストして、ローカルの接続口とノードまでの通信を確認します。
プロキシを明示したテストが正常ならTUNを再び有効にし、起動ログで権限、ネットワークアダプターの作成、ルートの追加結果を確認します。
クライアントを終了しても直接接続できない場合は、残っているシステムプロキシ、ほかのVPN、ルートを確認してください。システムのルーティングテーブルをむやみに削除しないでください。

Androidで対象アプリが通信を取り込まれているか確認する

Androidでは通常、一般アプリのVPNサービスを同時に有効にできるのは1つです。別のVPN、広告ブロック用VPN、仕事用プロファイルのネットワークツールに切り替えると、元のクライアントが置き換わることがあります。アプリ別の設定では、「選択したアプリのみをプロキシする」と「選択したアプリを除外する」は意味が逆です。ブラウザーが意図したリストに入っているか確認してください。画面ロック後にだけ失敗する場合は、ルールを書き換える前にバックグラウンド制限とバッテリー最適化を確認します。

ブラウザーだけで失敗する場合はHTTP/3を確認する

HTTP/3はQUICを使用し、通常はUDPの443で通信します。HTTPプロキシを明示したコマンドが成功しても、ブラウザーのQUIC通信経路が正常とは限りません。ブラウザーだけに明確な問題がある場合は、HTTP/3を一時的に無効にして比較できます。その変更で結果が変わる場合に限り、UDPの外向き通信、ノードの対応状況、TUNによる通信の取り込みを確認してください。すべてのWebサイトの問題に対する恒久的な対処として、プロトコルを無効にしないでください。

8. 設定を元に戻し、問題報告に必要な情報をまとめる

問題が発生しているレイヤーを特定したら、テストのために一時変更した全般モード、DNSの上流サーバー、ブラウザーのプロトコル設定を1項目ずつ元に戻し、実際に解決に必要だった変更だけを残します。直接接続できるサイト、プロキシが必要なサイト、もともと失敗していた接続先をもう一度テストしてください。最後に、クライアントを終了した状態でもシステムが想定どおりにネットワークへ接続できることを確認します。

問題を報告する場合は、「接続済み」と表示された画面のスクリーンショットだけでなく、以下の情報を添えると原因を特定しやすくなります。再現前後に必要な範囲だけログを抜き出し、サブスクリプションの認証情報、ノードのパスワード、制御インターフェースのトークンを公開しないようにしてください。

OSのバージョン、クライアントのバージョン、実際に使用しているMihomoコアのバージョン、クライアントの上書き設定の有無。
システムプロキシまたはTUNの有効状態、ローカルの待ち受けアドレスとポート、アプリ別プロキシの設定。
問題が発生した時刻、対象ドメイン、使用中のネットワーク、すべての接続先で失敗するかどうか。
プロキシを明示したコマンドの実行結果、実際に一致したルール、最終的なプロキシグループとノード。
ノードの切り替え、ネットワークの切り替え、TUNの無効化のうち、どの操作で結果が変わったか。