ERR_CONNECTION_RESET とは？原因と解決方法

ERR_CONNECTION_RESET とは？

ERR_CONNECTION_RESET は、ウェブサイトへの接続がいったん確立された後に強制的に切断されたときに、Chrome、Edge、Brave などの Chromium 系ブラウザが表示するエラーです。画面には「このサイトにアクセスできません。接続がリセットされました。」と表示されます。Chromium 内部ではネットエラー -101 にあたり、ソースコードには「接続がリセットされた（TCP RST に相当）」と1行で説明されています。

TCP リセット（RST）は、ネットワークにおける「電話を切るボタン」です。通常の接続は、データを届け終えた後に FIN パケットで丁寧に終了します。リセットは別れの挨拶なしに接続を即座に終わらせ、読み込み途中だったものはすべて破棄されます。ブラウザはサーバーへの到達までは成功しています。DNS は機能し、接続も確立されました。その後、経路上の何かが接続を断ち切ったのです。

その「何か」を特定することが、この問題のすべてです。あなた自身のコンピューター（ウイルス対策ソフト、VPN、壊れたネットワークスタック）、ルーターや ISP、サイトの手前にあるファイアウォール、あるいはウェブサーバーのプロセスそのものの可能性があります。以下の解決策は、どれが原因かを突き止められるよう、手早いものから順に並べています。

他のブラウザではこのエラーはどう表示されるか

表示される文言はブラウザごとに異なりますが、いずれも同じ TCP リセットを報告しています。

Firefox で「安全な接続ができませんでした」というページに PR_CONNECT_RESET_ERROR が表示される場合は、HTTPS ハンドシェイクの途中でリセットが起きています。原因はこのガイドの内容と大きく重なり、特にウイルス対策ソフトの HTTPS スキャンとネットワークのフィルタリングが該当します。

ERR_CONNECTION_RESET の原因

どのリセットにも送信者がいます。誰が送ったのかがわかれば、誰が直せるのかもわかります。

最初の5つはあなたの側の原因で、たいてい数分で解決できます。最後の2つはウェブサイト側の原因です。キャッシュをいくら削除しても効果はなく、管理者が解決するのを待つしかありません。

ステップ1：原因はあなたか、ウェブサイトか？

設定を変更する前に、まずこの確認に60秒だけ使ってください。このガイドの前半と後半のどちらがあなたに当てはまるかがわかります。

• 別のネットワークで試す。 スマートフォンの Wi-Fi をオフにして、同じページをモバイルデータ通信で開きます。表示されるなら、リセットはあなたのデバイスか、自宅・職場のネットワークで発生しています。

• 別のサイトで試す。 すべての HTTPS サイトでリセットされるなら、VPN、プロキシ、ウイルス対策ソフトを疑いましょう。1つのサイトだけなら、フィルタリングかそのサイトのサーバーを疑います。

• 外部からサーバーをテストする。 DNS Robot のポートチェッカーは、当社のサーバーからサイトのポート 443 に接続します。こちらからはポートが open なのにあなたの環境ではリセットされる場合、問題はあなたとサイトの間にあります。

• 経路を追跡する。 トレースルートを使うと、DNS Robot からサーバーまでの各ネットワークホップが表示されるので、サーバーが停止しているのか経路が壊れているのかを見分けられます。

解決策1：再読み込みし、シークレットウィンドウで試す

1回限りのリセットはよくあることです。ルーターの再起動、デプロイ中のサーバー再起動、Wi-Fi の切り替えなどが原因です。数秒待ってから Ctrl + R（Mac は Cmd + R）を押してください。

それでも繰り返し発生する場合は、シークレットウィンドウ（Ctrl + Shift + N、Mac は Cmd + Shift + N）でページを開きます。シークレットモードは拡張機能も保存済みの Cookie も使わずに動作します。そこで表示されるなら、原因は拡張機能か破損した Cookie です。拡張機能を1つずつ無効にするか、アドレスバー左端のアイコン → サイトの設定 → データを削除 でそのサイトのデータを削除してください。

解決策2：VPN をオフにしてプロキシ設定を確認する

VPN とプロキシはすべての接続の中間に位置しています。そのサーバーが過負荷になっている、ブロックされている、あるいはアイドルタイマーが短すぎると、接続をリセットします。VPN を完全に切断し（サーバーを切り替えるだけでは不十分です）、再読み込みしてください。

• Windows 11： 設定 → ネットワークとインターネット → プロキシ。設定を自動的に検出する はオンのままにし、「手動プロキシ セットアップ」の セットアップ（または 編集）をクリックして プロキシ サーバーを使う をオフにします。

• macOS： システム設定 → ネットワーク → Wi-Fi または Ethernet を選択 → 詳細… → プロキシ。意図して設定したもの以外のプロキシはすべてオフにします。

• Chrome 自体はシステムのプロキシを使用するため、ブラウザ側で別途変更するものはありません。

# Windows にはシステムサービス用の別のプロキシ（WinHTTP）もあります。
# 管理者権限のコマンド プロンプトまたは PowerShell で実行：
netsh winhttp show proxy
netsh winhttp reset proxy

解決策3：ウイルス対策の HTTPS スキャンやファイアウォールを一時停止する

多くのウイルス対策スイートは、HTTPS 通信を復号して検査します。この機能は HTTPS スキャン、ウェブシールド、SSL/TLS プロトコルフィルタリング、暗号化された接続のスキャン などの名前で呼ばれます。スキャナーがサイトの証明書やプロトコルを処理できないと、通信を通す代わりに接続をリセットします。

テストするには、ウイルス対策ソフト全体ではなく HTTPS スキャンのオプションだけをオフにして再読み込みします。ページが表示されたら、そのサイトだけスキャン対象から外す（ほとんどの製品は除外設定に対応しています）か、ウイルス対策ソフトを更新してください。サードパーティ製のファイアウォールも同じ動作をすることがあるので、一時停止した状態でもテストしましょう。

解決策4：Windows のネットワークスタック（Winsock）をリセットする

Windows は Winsock と呼ばれるネットワークコンポーネントのカタログを保持しています。VPN クライアント、古いウイルス対策製品、一部のマルウェアがここにエントリを追加し、カタログが破損するとすべてのサイトでリセットが発生します。Winsock と TCP/IP スタックをリセットすると、どちらも既定の状態に戻ります。管理者としてコマンド プロンプトを開き、次を実行してください：

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

:: 実行後は PC を再起動してください。Winsock のリセットは再起動後に反映されます。

Windows 11 にはワンクリックで実行できる方法もあります：設定 → ネットワークとインターネット → ネットワークの詳細設定 → ネットワーク リセット。すべてのネットワークアダプターを削除・再インストールして PC を再起動するため、その後 Wi-Fi への再接続と VPN の再インストールが必要になります。

解決策5：DNS をフラッシュし、別の DNS リゾルバーを試す

DNS 自体がリセットを送ることはありません。しかし一部の ISP や職場のリゾルバーは、ブロック対象のドメインを、接続をリセットするフィルタリングサーバーに向けています。また、キャッシュされた古いアドレスのせいで、すでにそのサイトをホストしていないサーバーに接続してしまうこともあります。まずキャッシュをフラッシュしましょう。各システム用のコマンドは DNS フラッシュのガイド にまとめています：

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Chrome 自身のキャッシュ：chrome://net-internals/#dns を開いて "Clear host cache" をクリック

次に、あなたのネットワークが返す結果を中立的な回答と比べます。DNS Robot の DNS Lookup でドメインを調べてください。そこに表示される IP アドレスが、あなたのコンピューターで解決される IP（nslookup example.com）と異なる場合、リゾルバーがあなたを別の場所へ誘導しています。Cloudflare（1.1.1.1）や Google（8.8.8.8）などのパブリックリゾルバーに切り替えましょう。DNS スピードテスト を使えば、あなたの場所からどれが最速かがわかります。

解決策6：大きなページだけ失敗するなら MTU を下げる

よくあるパターンとして、シンプルなページは表示されるのに、大きなページ、ファイルのダウンロード、ログインでリセットされることがあります。これは MTU の問題を示しています。経路上のある区間にとってパケットが大きすぎ（VPN、PPPoE 接続、一部のモバイルホットスポットでよく起こります）、本来その問題を通知すべき機器が黙ってパケットを破棄するため、接続が止まった後に失敗するのです。

断片化せずに通過できる最大のパケットサイズを調べます。データ 1472 バイト＋ヘッダー 28 バイトが、標準の MTU 1500 に相当します：

:: Windows：-f = 断片化しない、-l = ペイロードサイズ
ping example.com -f -l 1472
:: "Packet needs to be fragmented but DF set" = 大きすぎる。応答が返るまで値を下げる。

:: 次に MTU =（通過した最大サイズ + 28）を設定。例：1400
netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Wi-Fi" mtu=1400 store=persistent

# macOS：-D = 断片化しない、-s = ペイロードサイズ
ping -D -s 1472 example.com

解決策7：Chrome のソケットプールをフラッシュし、Chrome をリセットする

Chrome はページを速く読み込むために、開いている接続を再利用します。ネットワークを切り替えたり VPN が切断されたりして、プールされた接続の1つが古くなると、Chrome がそれを再び使おうとしてリセットされることがあります。chrome://net-internals/#sockets を開いて Flush socket pools をクリックし、再読み込みしてください。

Firefox では問題ないのに Chrome でだけ失敗し続けますか？ chrome://settings/reset → 設定を元の既定値に戻す（Restore settings to their original defaults）に進みます。拡張機能が無効になり一時データが削除されますが、ブックマーク、履歴、保存したパスワードは残ります。

Android と iPhone で ERR_CONNECTION_RESET を解決する

スマートフォンでも同じ理由でこのエラーが発生します。さらに1つ、Android のプライベート DNS 設定がフィルタリング用または到達不能なサーバーを指している、という原因が加わります。

• Android（プライベート DNS）： 設定 → ネットワークとインターネット → プライベート DNS → 自動 に設定します（Samsung の場合：設定 → 接続 → その他の接続設定 → プライベート DNS）。各オプションの意味は Android のプライベート DNS ガイド で解説しています。

• Android（ネットワーク設定のリセット）： 設定 → システム → リセット オプション → Bluetooth と Wi-Fi をリセット を実行し、モバイルデータ通信にも影響がある場合は モバイル ネットワーク設定をリセット も実行します（Samsung の場合：設定 → 一般管理 → リセット → Wi-Fi と Bluetooth の設定をリセット（Reset Wi-Fi and Bluetooth settings））。

• iPhone と iPad： 設定 → 一般 → 転送または iPhone をリセット → リセット → ネットワーク設定をリセット。保存済みの Wi-Fi ネットワークとパスワードが消去され、構成プロファイル以外でインストールされた VPN 設定も削除されます。

• 共通： VPN アプリや広告ブロックアプリ（多くはローカル VPN として動作します）をオフにし、Wi-Fi とモバイルデータ通信を切り替え、ブラウザアプリを更新してください。

ウェブサイト管理者向け：訪問者の接続をリセットしているものを突き止める

訪問者から ERR_CONNECTION_RESET の報告があり、複数のネットワークからサイトにアクセスできない場合、リセットはあなたのサーバー環境から送られています。外側から内側へ向かって調べましょう：

• 外部から再現する。 ネットワーク外のマシンから curl -v https://yourdomain.com を実行するか、ポートチェッカー でポート 443 をテストします。リセットが TLS ハンドシェイクの前、最中、リクエスト送信後のどの段階で起きたかを記録してください。

• セキュリティ層を確認する。 レート制限、fail2ban、CrowdSec、クラウド WAF は、BAN した IP を TCP リセットで拒否することがあります（例：iptables の REJECT --reject-with tcp-reset ルール）。何よりも先に、報告してきたユーザーの IP が BAN されていないか確認しましょう。

• クラッシュと再起動を探す。 リクエスト処理中に終了したプロセスは、開いていた接続を道連れにします。journalctl -u your-service、pm2 logs を確認し、Linux の OOM キラーについては dmesg -T | grep -i "killed process" を確認してください。

• TLS を確認する。 TLS 1.2 と 1.3 を、完全な証明書チェーンとともに提供しましょう。古いプロトコル設定や壊れたチェーンは、一部のクライアントでハンドシェイクを突然終了させることがあります。SSL チェッカー では証明書チェーンと有効期限を、HTTP ヘッダーチェッカー では実際のリクエストが受け取る応答を確認できます。

• CDN を確認する。 Cloudflare などの CDN を利用している場合は、オリジンサーバーに手を付ける前に、セキュリティイベントログで訪問者の IP や国を確認してください。

# 訪問者の IP は fail2ban で BAN されているか？
sudo fail2ban-client status              # jail の一覧
sudo fail2ban-client status sshd         # 1つの jail で BAN された IP
sudo fail2ban-client set sshd unbanip 203.0.113.7

# OOM キラーがアプリを終了させたか？
dmesg -T | grep -i "killed process"

ERR_CONNECTION_RESET・REFUSED・TIMED_OUT・CLOSED の違い

この4つのエラーは画面上では似ていますが、ネットワーク上で起きていることは異なり、それぞれ別の解決策を示します。コードは Chromium 独自のネットエラー番号です。

関連エラーの詳しいガイド：ERR_CONNECTION_REFUSED、ERR_CONNECTION_TIMED_OUT、ERR_CONNECTION_CLOSED。ネットワークがセキュア DNS もブロックしている場合は、「このネットワークは暗号化された DNS トラフィックをブロックしています」の解説をご覧ください。