エラーの内容
This site can't be reached.
The connection was reset.
ERR_CONNECTION_RESET
このエラーは原因が曖昧なため厄介です。ブラウザがTCPハンドシェイク中にRSTパケットを受信したか、サーバーがHTTPデータを送信する前に接続を切断しています。原因はクライアント側（ブラウザ、ファイアウォール、VPN、ウイルス対策ソフト）、ネットワーク側（ルーター、ISP、プロキシ）、またはサーバー側（アプリのクラッシュ、ファイアウォールルール、TLSの設定ミス）のいずれかにある可能性があります。
主な原因
- ブラウザまたはOS レベルのTCPスタックの問題（古いソケット、破損した状態）
- ウイルス対策ソフト／セキュリティソフトがHTTPSを傍受してRSTを送信している
- VPNまたはプロキシが接続を切断している
- サーバーのファイアウォールがIPをブロックしているか、ポート443/80でリセットしている
- サーバープロセスが接続中にクラッシュまたは再起動した
- SSL/TLSの設定ミスによるハンドシェイク失敗 → RST
- ネットワーク経路上のMTUの不一致
- 破損したブラウザプロファイルまたは拡張機能がリクエストに干渉している
修正1: ブラウザ側の簡易リセット
まずここから始めましょう — 全体の約40%のケースに対応できます。
# DNSキャッシュをフラッシュ
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches
次にブラウザのソケットプールをクリアします。Chromeの場合、以下にアクセスしてください：
chrome://net-internals/#sockets
Flush socket pools をクリックします。同じページからDNSもクリアできます：
chrome://net-internals/#dns
再度サイトにアクセスしてみてください。表示されれば、古いソケットが原因でした。
修正2: ウイルス対策ソフト／VPNを一時的に無効化
ウイルス対策ソフトによるSSLインスペクションは、意外と多い原因のひとつです。Kaspersky、Avast、ESETはいずれもOSレベルでHTTPS接続をMITMします。TLSハンドシェイクを正常に処理できない場合、代わりにRSTを送信します。
- ウイルス対策ソフトを一時的に無効にして再試行する
- サイトが表示された場合 — ウイルス対策の設定でHTTPS/SSLスキャンを無効にするか、そのサイトを例外に追加する
- VPNも同様：切断して再試行。接続できた場合は、VPNのトラフィックルーティングまたはファイアウォールルールが原因
修正3: Windowsのネットワークスタックをリセット
Windowsでは、WinsockやTCP/IPの設定が破損することで、このエラーが想像以上に頻繁に発生します。
# 管理者として実行
netsh winsock reset
netsh int ip reset
netsh int tcp reset
ipconfig /release
ipconfig /flushdns
ipconfig /renew
実行後は再起動してください。これによりネットワークスタック全体がデフォルトにリセットされます。
修正4: MTUサイズを確認する
MTUの不一致は気づきにくい問題です — 接続は問題なく始まりますが、大きなパケットでRSTが発生します。大きなpingペイロードでテストしてみましょう：
# Windows
ping -f -l 1472 8.8.8.8
# macOS / Linux
ping -M do -s 1472 8.8.8.8
「Packet needs to be fragmented」と表示された場合、MTUが高すぎます。PPPoE接続の標準値である1452に下げてください：
# Windows — "Wi-Fi" を実際のインターフェース名に置き換えてください
netsh interface ipv4 set subinterface "Wi-Fi" mtu=1452 store=persistent
# Linux
sudo ip link set dev eth0 mtu 1452
まずインターフェース名を確認してください：
# Windows
netsh interface show interface
# Linux
ip link show
修正5: サーバー側の診断
他のユーザーも同じエラーが発生していますか？それならサーバーを確認しましょう。以下のコマンドで実際にRSTを送信しているものを特定します：
# サーバーが接続をRSTしているか確認
tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0' -n
# プロセスが動作しているか確認
systemctl status nginx # または apache2、使用中のアプリ
# ファイアウォールが接続をリセットしているか確認
iptables -L -n -v | grep REJECT
iptables -L -n -v | grep DROP
# サーバーログで接続エラーを確認
tail -f /var/log/nginx/error.log
journalctl -u nginx -f
よくあるサーバー側の修正：
- スタックしているか zombieState になっている場合はWebサーバーを再起動する
tcp_reset_on_errorとタイムアウトの設定を確認する — 積極的すぎる値は接続の遅いクライアントを早期に切断する- ロードバランサーの背後にある場合は、ヘルスチェックの設定を確認する。「ダウン」とマークされたバックエンドは接続が即座にリセットされる
修正6: TLS/SSLの問題
TLSハンドシェイクの失敗はほぼ必ずRSTで終わります。コマンドラインから直接テストしてみましょう：
# TLSハンドシェイクを手動でテスト
openssl s_client -connect yoursite.com:443 -tls1_2
openssl s_client -connect yoursite.com:443 -tls1_3
# 証明書の有効性を確認
curl -vI https://yoursite.com 2>&1 | grep -E '(SSL|TLS|certificate|expire)'
証明書の期限切れ、ホスト名の不一致、またはサポートされていないTLSバージョンはここで確認できます。証明書を修正するか、TLS設定を適切に更新してください。
修正7: 別のDNSを試す
直接RSTを引き起こす可能性は低いですが、ISPのDNSがRSTで応答するIPを返すケースが稀にあります。素早く切り替えてみましょう：
# Windows — PowerShell経由:
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","8.8.8.8")
# Linux — /etc/resolv.conf を編集するか nmcli を使用:
nmcli con mod "your-connection" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli con up "your-connection"
確認方法
修正を適用したら、接続が正常かどうかを以下のコマンドで確認してください：
# 基本的な接続テスト
curl -v https://yoursite.com
# TCPハンドシェイクのタイミングを確認
curl -v --trace-time https://yoursite.com 2>&1 | head -40
curlは動作するのにChromeでまだエラーが出る場合は、ブラウザ固有の問題です。まずシークレットモードで試して拡張機能の影響を排除してください。シークレットモードで表示できた場合は、拡張機能を1つずつ無効にしてみてください。シークレットモードでも表示できない場合は、新しいChromeプロファイルを作成してください — 破損したプロファイルはセッションをまたいでソケットの状態が残ることがあります。
予防策とヒント
- 開発用ドメインではウイルス対策のSSLスキャンを無効にするか、適切な例外を設定する
- サーバーでは適切なTCPキープアライブとタイムアウト値を設定する — 積極的すぎる設定は接続の遅いクライアントを切断してしまう
- サーバーの接続リセット率を監視する：
netstat -s | grep reset - クライアントIPが許可されたCIDRブロック内にあるか確認したい場合は、ToolCraftのSubnet Calculatorでローカルツール不要で計算できます
クイックチェックリスト
- ブラウザのDNS＋ソケットプールをフラッシュ
- VPN／ウイルス対策を無効にして再テスト
- Winsockリセットを実行（Windows）
- 大きなpingでMTUを確認
- サーバープロセスが動作しているか確認＋ログを確認
- opensslでTLSハンドシェイクをテスト
- シークレットモード／別のブラウザで試す