1サイトだけ ERR_CONNECTION_RESET
一つのサイトだけ ERR_CONNECTION_RESET で開かない? ネットワーク、拡張機能、プロキシ、DNS、時計、curl による SNI フィルタリングの確認手順。
他のサイトはすべて開くのに、一つだけ「このサイトにアクセスできません」と ERR_CONNECTION_RESET で失敗し続ける。再読み込みしても変わらない。このガイドは判断の流れ図です。各ステップで原因が見つかるか、一つの原因が除外されます。順番は、最も手早い確認から最も多くを語る確認へと進みます。
「接続のリセット」が実際に意味すること
TCP 接続は穏やかに終わることもあれば、リセットパケット(RST)で一気に切られることもあります。Chrome などの Chromium 系ブラウザーは、ページが届く前にリセットが届くと ERR_CONNECTION_RESET を表示します。Firefox も同様の「接続がリセットされました」というページを表示します。リセットはサイトのサーバーから、あなた自身のコンピューター上のソフトウェアから、あるいは両端のどちらかになりすますネットワークの途中の機器から来ることがあります。
だから同じエラーでも原因がこれほど違うのです。コツは、誰が、いつリセットを送ったかを見つけることです。
ステップ 1: 本当に一つのサイトだけ?
関係のないサイトを二つ三つ、めったに訪れないものも含めて開いてみます。複数が失敗するなら、問題はその一つのサイトではなく、回線、ルーター、端末です。ルーターを再起動し、同じネットワークの他の端末が使えるか確認してください。一つのサイトだけが失敗するなら、先へ進みます。
ステップ 2: 一つのネットワークだけ?
これが最も多くを教えてくれるテストで、しかも無料です。Wi-Fi ではなくモバイルデータでサイトを開くか、ノートパソコンをスマートフォンにテザリングします。一方のネットワークでは開き、もう一方ではリセットされるなら、失敗する側のネットワークが関わっています。よくある原因はモバイルデータでは開くのに Wi-Fi では開かないのはなぜ?で取り上げています。どこでも失敗するなら、サイト自体か端末が原因である可能性が高くなります。
ステップ 3: 別のブラウザー、プライベートウィンドウ、拡張機能なし
ほとんどの拡張機能がデフォルトでオフになるプライベートウィンドウ(シークレットウィンドウ)で試します。次に別のブラウザーで試します。広告ブロッカー、プライバシー拡張機能、「セーフブラウジング」系のアドオン、企業のブラウザーポリシーは、どれも接続を閉じることがあります。プライベートウィンドウで開くなら、エラーが再び出るまで拡張機能を一つずつオンに戻してください。
ステップ 4: 他の VPN、プロキシ、HTTPS スキャンをオフにする
通信の経路にあるものは何でも、気に入らない接続をリセットできます。
- 他の VPN やプロキシのアプリ。 完全にオフにしてもう一度テストします。
- ウイルス対策ソフトの「HTTPS スキャン」や「Web 保護」。 暗号化された通信を検査し、危険と判断した接続を切るセキュリティソフトがあります。テストのために一時的にその機能を止め、その後オンに戻してください。
- システムのプロキシ。 Windows では、設定 → ネットワークとインターネット → プロキシを確認します。macOS では、システム設定 → ネットワーク → お使いの接続 → 詳細 → プロキシを確認します。見覚えのないプロキシや、古いアプリの残りのプロキシが、特定のサイトだけを壊すことがあります。自分で設定したとわかっているものだけを削除し、管理されたコンピューターなら IT チームに相談してください。
ステップ 5: DNS キャッシュを消去し、暗号化 DNS を試す
サイトがサーバーを移転した場合、端末がまだ古いアドレスを使っていて、リセットやタイムアウトになることがあります。キャッシュを消去します。
# Windows (Command Prompt)
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Chrome's own cache: open chrome://net-internals/#dns and click "Clear host cache"
次に、ネットワークの応答と独立したリゾルバーの応答を比べます。nslookup example.com を実行し、続けて nslookup example.com 1.1.1.1 を実行します。結果が異なり、独立したリゾルバーの応答だけが使えるなら、ネットワークの DNS が問題です。この種のブロックは暗号化 DNS で直ります。DoH と DoT で説明しています。ただし、大きなサイトはネットワークごとに別のサーバーを返すので、アドレスが違うだけでは証拠になりません。
ステップ 6: 日付と時刻を確認する
時計がずれていると、たいていリセットではなく証明書エラーになりますが、確認は10秒で済みます。日付と時刻の自動設定をオンにして、再読み込みします。失敗するページを「突破」するために証明書の警告をクリックして先へ進むことは、決してしないでください。
ステップ 7: サイトはダウンしている?
サイトのステータスページや公式の SNS アカウントを確認するか、公開されている「みんなが見られないのか、自分だけか」のチェッカーを使います。サイトがダウンしているなら、待ちましょう。チェッカーは自分のサーバーからテストするので、そこで「稼働中」でも、あなたのネットワークから到達できる証明にはならない点に注意してください。
ステップ 8: curl でリセットを読む
それでも一つのネットワークでだけサイトがリセットされるなら、ハンドシェイクそのものを見てみましょう。curl は Windows 10 と 11、macOS、ほとんどの Linux システムに組み込まれています。example.com を対象のサイトに置き換えて、ターミナルで実行します。
curl -v https://example.com
正常な接続では、次のような行がいくつか表示され、その後にページのヘッダーが続きます。正確な文言は curl のバージョンと TLS ライブラリによって異なります。
* Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...
< HTTP/2 200
名前によるフィルタリングを示すパターンは次のようになります。
* Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
一行ずつ読んでいきます。「Connected」は、サーバーの IP アドレスへの TCP 接続が成功したことを意味するので、アドレスが丸ごとブロックされているわけではありません。「Client hello」は最初の TLS メッセージで、SNI というフィールドにサイト名を平文で載せています。その直後の「Connection reset by peer」は、名前が見えた途端、サーバーが応答する前に何かが接続を切ったことを意味します。代わりに接続を静かに閉じるネットワークもあり、curl はそれを予期しないファイル終端や SSL の「syscall」エラーとして報告し、Chrome は ERR_CONNECTION_CLOSED を表示することがあります。
他の結果と比べてみましょう。
| curl の表示 | 考えられる意味 |
|---|---|
| Could not resolve host | DNS の失敗または DNS ブロック。ステップ 5 に戻る |
| 「Trying」で止まり、タイムアウト | IP アドレスに到達できない。IP ブロック、ファイアウォール、サーバーのダウン |
| 「Client hello」の直後にリセットまたは切断、一つのネットワークでだけ | おそらくそのネットワークでの SNI フィルタリング |
| ハンドシェイクが完了し、その後 HTTP エラーコード | サイトは応答している。問題はサイト側かアカウントにある |
裏付けを強めるには、別のネットワークで同じコマンドを実行します。そこで成功するなら、フィルターは最初のネットワークのものです。これはまれな状況についての推測ではありません。2020年の OONI と Centre for Internet and Society の調査では、Bharti Airtel で特定のサイトへの TLS 接続が ClientHello の直後に切られ、Reliance Jio では SNI と宛先アドレスの組み合わせで切られていたことが確認されました。CIS は別に Jio が SNI 検査を使っていると報告し、その報告は ntc.party フォーラムでも議論されました。背景の詳細はサイトがブロックされているか確認する方法をご覧ください。
GreenTunnel が役立つ場面と役立たない場面
GreenTunnel は私たちが作っている端末上で動くローカル VPN なので、この部分は私たちに偏りがあることを踏まえてお読みください。上の原因のうち二つを対象にしています。
- SNI フィルタリング。 接続の最初の TLS パケットの形を変えます。たとえば Client hello やその TLS レコードを分割し、サイト名を探すフィルターがひとかたまりの名前を見つけられないようにします。仕組みは SNI、DPI、TLS レコード分割をご覧ください。
- DNS ブロック。 名前解決は暗号化 DNS(DoH または DoT)で Cloudflare、Google、Quad9 に送られるので、ネットワークが黙って偽の応答を返すことはできません。
Inspect URL(URL を調べる)ツールは、今いるネットワークで一つのサイトについてステップ 5 と 8 の比較を実行し、サイトが名前でフィルタリングされているか、偽の DNS 応答を返されているか、IP アドレスでブロックされているか、問題ないかを教えてくれます。効く技法があれば、Use this technique をタップできます。
次の場合には役立ちません。
- サイトがダウンしている、またはリセットがサイト自身のサーバーや保護サービスから来ている場合、
- IP アドレスによるブロックで、「Trying」でのタイムアウトとして現れる場合、
- 職場、学校、その他の管理されたネットワークが意図的にサイトをブロックしている場合。そのネットワークのルールを決めるのは所有者です。ポリシーを尊重し、仕事でアクセスが必要なら管理者に相談してください、
- 原因が自分の端末上の拡張機能、ウイルス対策ソフト、古い DNS である場合。それらは直接直してください。
正直な限界と責任ある利用
GreenTunnel は IP アドレスを隠さず、匿名化ツールでもありません。IP ブロック、ネットワークの遮断、許可リストは回避できず、特定のサイトが開けることも約束しません。フィルターは時間とともに変わり、ISP によっても異なるので、今日の結果が来月には違うかもしれません。
よくある質問
ERR_CONNECTION_RESET は常にサイトがブロックされているサインですか?
いいえ。拡張機能、ウイルス対策ソフトの HTTPS スキャン、残ったプロキシ、古い DNS、サイト自体のどれでも起こりえます。ブロックの可能性が高くなるのは、リセットが一つのネットワークで、Client hello の直後に起き、別の場所ではサイトが開く場合だけです。
なぜモバイルデータでは開くのに Wi-Fi ではリセットされるのですか?
二つのネットワークはプロバイダー、リゾルバー、フィルターが違います。どちらかがサイト名を読んでいるか、DNS に別の応答を返しているのかもしれません。両方で curl -v を実行し、それぞれがどこで止まるか比べてください。
Cookie を消去すれば接続のリセットは直りますか?
めったに直りません。Cookie は接続が確立した後に送られますが、ほとんどのリセットはその前に起きます。サイトデータの消去が役立つのは、サイト自身が不正なセッションを拒否している場合で、その場合はたいてい代わりに HTTP エラーが表示されます。
会社のファイアウォールによるリセットを GreenTunnel で直せますか?
そのためのものではありません。管理されたネットワークは所有者のポリシーでサイトをブロックしています。回避しようとせず、管理者に相談してください。
出典
- OONI と Centre for Internet and Society、Investigating TLS blocking in India、2020年7月。
- Centre for Internet and Society、Reliance Jio is using SNI inspection to block websites。
- ntc.party フォーラム、SNI filtering by Indian ISP Reliance Jio。
- curl プロジェクト、curl マニュアル(
-vオプション)。