ERR_CONNECTION_REFUSED とは？意味と解決方法

ERR_CONNECTION_REFUSED とは？

ERR_CONNECTION_REFUSED は、ブラウザがウェブサイトのサーバーに到達したにもかかわらず、サーバーが接続を積極的に拒否したときに表示される Chrome のエラーです。ネットワークレベルでは、あなたのコンピューターがサーバーの IP アドレスとポートに TCP 接続要求（SYN）を送信したのに対し、サーバー（またはその手前のファイアウォール）が受け入れる代わりに、「ここでは誰もあなたと通信しない」というリセット（RST）パケットで応答した状態です。

この点で、ERR_CONNECTION_REFUSED は DNS_PROBE_FINISHED_NXDOMAIN のような DNS エラーとは根本的に異なります。DNS エラーの場合、ドメイン名がそもそも IP アドレスに解決されていません。一方 ERR_CONNECTION_REFUSED では DNS は完璧に機能しており、ブラウザはサーバーの場所を正確に知っています。しかし、そのアドレスにあるマシンが扉を開けることを拒んだのです。

この拒否は通常、次の3つのいずれかを意味します。そのポートで待ち受けているサービスがない（ウェブサーバーが停止またはクラッシュしている）、ファイアウォールがそのポートへのトラフィックを拒否している、あるいはあなたのデバイスがそもそも間違った IP アドレスに接続している（古い DNS キャッシュや壊れたプロキシが原因など）、のいずれかです。

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

ブラウザごとに接続拒否の表示は異なりますが、根底にある TCP レベルの拒否は同一です。

Chromium ベースのブラウザ（Chrome、Edge、Brave、Opera）はいずれも生の ERR_CONNECTION_REFUSED コードを表示します。Firefox と Safari は平易な言葉で言い換えていますが、原因も解決方法もまったく同じです。

ERR_CONNECTION_REFUSED のよくある原因

おおむね半分のケースでは問題はサーバー側にあり、残りの半分はあなたのデバイスやネットワーク上の何かが干渉しています。以下に、頻度の高い順によくある原因を挙げます。

• ウェブサイトのサーバーがダウンしている — ウェブサービス（nginx、Apache、Node.js）がクラッシュした、再起動中、または停止された状態です。マシン自体はオンラインでも、ポート 80/443 では何も応答しません。

• ファイアウォールがポートをブロックしている — サーバー側、あなたのネットワーク、またはデバイス上のファイアウォールが、そのポートへの接続を拒否しています。

• プロキシ設定の誤り — システムが、オフラインまたは到達不能なプロキシサーバー経由でトラフィックをルーティングしています。クライアント側で最もよくある原因のひとつです。

• 古い DNS キャッシュ — サイトは新しいサーバーへ移転したのに、キャッシュされた DNS エントリが、もう何も待ち受けていない古い IP アドレスを指したままになっています。

• VPN やウイルス対策ソフトの干渉 — セキュリティソフトが接続を横取りして拒否している、あるいは VPN の出口サーバーがサイトに到達できない状態です。

• ブラウザ拡張機能の干渉 — 広告ブロッカー、プライバシー系拡張機能、マルウェアに感染した拡張機能が、特定のホストへの接続をブロックすることがあります。

• hosts ファイルの上書き — hosts ファイル内でドメインが誤った IP（多くは 127.0.0.1）にマッピングされており、ブラウザが自分自身のマシンに接続して拒否されている状態です。

• localhost で何も待ち受けていない — 開発者向け：ローカルの開発サーバーが起動していない、クラッシュした、または開いているポートとは別のポートにバインドされています。

• router の問題 — 不調な router やモデムが、再起動されるまで接続を壊し続けることがあります。

解決策1：サイトが全員にとってダウンしているか確認する

デバイスの設定を変更する前に、まず問題がサーバー側にあるのかを確かめましょう。サイトが全員にとってダウンしているなら、ローカルでの対処は何の役にも立ちません。

最も確実なテスト方法は、別のネットワーク経路から試すことです。スマートフォンで Wi-Fi をオフにしてモバイルデータ通信でサイトを開いてください。そこでも失敗するなら、サーバー自体が接続を拒否しており、サイトの管理者が修正するのを待つしかありません。

また、次の DNS Robot のツールでサーバーを直接テストすることもできます：

• [ポートチェッカー](/port-checker) — サイトのドメインを入力し、ポート 443（HTTPS）と 80（HTTP）をテストします。両方とも closed と表示されるなら、ウェブサーバーはあなただけでなく全員に対してダウンしているか、ファイアウォールで遮断されています。

• [Ping テスト](/ping) — サーバーのマシンがそもそも応答するかを確認します。ping は通るのにポートが closed なら、マシンは稼働しているもののウェブサービスが停止しています。

• [HTTP ヘッダーチェッカー](/http-headers) — DNS Robot のサーバーから実際の HTTP リクエストを送信します。こちらでは応答が得られるのにあなたのブラウザでは失敗する場合、問題はあなたのデバイスかネットワークにあります。

解決策2：router とデバイスを再起動する

定番の最初の一手には理由があります。再起動により、router の接続テーブル、DNS キャッシュ、そして接続拒否の原因になり得る不調な NAT の状態がクリアされるからです。

router（モデムが別体の場合はモデムも）の電源を抜き、30秒待ってから再び差し込み、完全に再接続するまで 2〜3 分待ちます。コンピューターやスマートフォンも再起動してネットワークスタックをリセットしてから、もう一度サイトを開いてみてください。

解決策3：ブラウザのキャッシュと Cookie を削除する

Chrome が壊れたリダイレクト、古い HSTS エントリ、あるいは死んだサーバーへ誘導する Cookie をキャッシュしている可能性があります。これらを削除すると、完全に新しい接続が強制されます。

• Chrome を開く → 右上の3点メニューをクリック → 閲覧履歴データを削除

• 期間 → 全期間 を選択

• チェックを入れる：「Cookie と他のサイトデータ」と「キャッシュされた画像とファイル」

• データを削除をクリックし、Chrome を再起動して、もう一度サイトを開きます

解決策4：プロキシ設定を無効にする

設定ミスや機能していないプロキシは、すべてのウェブサイトで一斉に ERR_CONNECTION_REFUSED が発生する最もよくある原因のひとつです。もう存在しないプロキシ経由でトラフィックをルーティングするようシステムが設定されていると（古い VPN、学校や職場の設定、マルウェアの残骸であることが多い）、すべての接続が拒否されます。

Windows：設定 → ネットワークとインターネット → プロキシ を開きます。「手動プロキシ セットアップ」の下の「プロキシ サーバーを使う」をオフにし、社内プロキシを使っていないなら「設定を自動的に検出する」もオフにします。

macOS：システム設定 → ネットワーク → Wi-Fi → 詳細 → プロキシ を開きます。組織で必要とされていない限り、リスト内のすべてのプロトコル（Web プロキシ HTTP、保護された Web プロキシ HTTPS、SOCKS プロキシ）のチェックを外し、OK をクリックします。

Chrome はオペレーティングシステムのプロキシ設定を使用するため、変更後はブラウザを再起動してからもう一度テストしてください。

解決策5：DNS キャッシュをフラッシュする

ウェブサイトが最近新しいサーバーに移転した場合、キャッシュされた DNS エントリが依然として古い IP アドレスを指していることがあります。そこではもう何も待ち受けていないため、接続が拒否されます。キャッシュをフラッシュすると、デバイスは現在のアドレスを強制的に再取得します。

# Windows (Command Prompt as Administrator)
ipconfig /flushdns

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

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Also clear Chrome's internal DNS cache:
# chrome://net-internals/#dns → Clear host cache

フラッシュした後は、chrome://net-internals/#dns で Chrome 自身の DNS キャッシュも削除し、chrome://net-internals/#sockets でソケットプールもフラッシュしてください。Chrome はどちらもオペレーティングシステムとは別に保持しています。詳しい手順は、こちらのガイドをご覧ください：各 OS で DNS をフラッシュする方法。

ドメインが現在どの IP に解決されるかは DNS Robot の DNS Lookup で確認できます。ターミナルの nslookup がグローバルな結果と異なる IP を表示するなら、原因はキャッシュだったということです。

解決策6：パブリック DNS サーバーに切り替える

ISP の DNS サーバーが古いレコードを返している場合、キャッシュをフラッシュしても意味がありません。同じ古い IP を再取得するだけだからです。高速なパブリックリゾルバーに切り替えれば最新のレコードが得られ、多くの場合ブラウジング全体も速くなります。

Windows：設定 → ネットワークとインターネット → 接続中の回線 → DNS サーバーの割り当ての「編集」 → 手動 → IPv4 をオン → 1.1.1.1 と 1.0.0.1 を入力 → 保存。

macOS：システム設定 → ネットワーク → Wi-Fi → 詳細 → DNS → 1.1.1.1 と 1.0.0.1 を追加し、古いエントリを削除 → OK。

あなたの場所からどのリゾルバーが最速かわからない場合は、DNS Robot の DNS スピードテスト を実行してください。Cloudflare・Google・Quad9 などをあなた自身の回線から数秒でベンチマークできます。

解決策7：VPN・ウイルス対策・ファイアウォールを一時的に無効にする

VPN、ウイルス対策ソフトのウェブ保護、ファイアウォールはいずれもブラウザとインターネットの間に位置し、それぞれが接続を拒否する可能性があります。特にウイルス対策ソフトの HTTPS スキャン機能は頻繁な原因です。暗号化されたトラフィックをローカルのサービス経由でプロキシしており、そのサービスが壊れると、すべての HTTPS サイトが拒否されます。

次の順でテストしてください。まず VPN を切断して再読み込み。次にウイルス対策のウェブ保護モジュールを1分だけ無効にして再読み込み。最後にファイアウォール（Windows Defender ファイアウォール、または macOS のファイアウォール）を短時間オフにして再読み込みします。

いずれかを無効にした時点でサイトが表示されたら、それを再度有効にしたうえで、そのサイトを例外に追加するか（VPN の場合は別のサーバーロケーションに切り替えるか）してください。保護をオフにしたまま放置してはいけません。

解決策8：シークレットモードで拡張機能をテストする

広告ブロッカー、プライバシーツール、VPN 拡張機能は、特定のホストへの接続を静かにブロックすることがあります。手早いテスト方法：シークレットウィンドウ（Ctrl+Shift+N / Cmd+Shift+N）でサイトを開きます。シークレットモードでは、ほとんどの拡張機能がデフォルトで無効になります。

シークレットモードで表示されるなら、原因は拡張機能です。chrome://extensions を開いてすべて無効にし、1つずつ再有効化してエラーが再発した時点のものが犯人です。それを削除するか、その拡張機能のフィルタからサイトを除外してください。

解決策9：hosts ファイルを確認する

hosts ファイルは、特定のドメインについて DNS を上書きします。サイトがそこで 127.0.0.1、0.0.0.0、または古いサーバー IP にマッピングされていると、ブラウザは代わりにそのアドレスへ接続し、拒否されます。開発時に残されたエントリや、広告ブロック用の hosts リストが定番の容疑者です。

# Windows — open as Administrator:
notepad C:\Windows\System32\drivers\etc\hosts

# macOS / Linux:
sudo nano /etc/hosts

# Look for lines containing the domain, e.g.:
# 127.0.0.1   example.com   ← forces the connection to your own PC
# 203.0.113.7 example.com   ← forces an old server IP

# Delete the offending line, save, then flush DNS.

localhost で接続が拒否される場合（開発者向け）

localhost refused to connect や 127.0.0.1 での ERR_CONNECTION_REFUSED は、すべての開発者が通る道です。これは、要求したポートであなたのマシン上の何も接続を受け付けていないことを意味します。よくある理由は次のとおりです：

• 開発サーバーが起動していない — 起動し忘れたか、クラッシュしています。npm run dev、rails s、python manage.py runserver が動いているはずのターミナルを確認してください。

• ポートが違う — サーバーが別のポートで起動しており（例：3000 が使用中だったため 3001）、あなたは古いポートを開いています。起動ログのどのポートにバインドしたかを示す行を読んでください。

• 別のインターフェースにバインドされている — サーバーが 0.0.0.0 やコンテナ内部の IP にバインドされているのに localhost にアクセスしている、またはその逆です。Docker のポートマッピング（-p 3000:3000）は、コンテナ内でアプリが待ち受けるポートと一致していなければなりません。

• ファイアウォールやセキュリティソフト — ローカルのファイアウォールはループバックのポートさえブロックすることがあります。会社支給のマシンでよく見られます。

• HTTPS と HTTP の取り違え — https://localhost:3000 を開いているのに、開発サーバーは素の HTTP しか話せない状態です。明示的に http:// を試してください。

# Which process is listening on port 3000?
# macOS / Linux:
lsof -i :3000

# Windows (PowerShell):
netstat -ano | findstr :3000

# No output = nothing is listening = connection refused.
# Start your dev server, or kill the stale process and restart it.

公開サーバーのポートが（マシン自身からではなく）インターネットから到達可能かを確認する必要がある場合は、DNS Robot の ポートチェッカー を使ってください。あなたのネットワークの外側から接続をテストするので、訪問者が実際に体験する状況そのものを確認できます。

ウェブサイト管理者向け：自分のサイトが接続を拒否する場合

訪問者から自分のウェブサイトで ERR_CONNECTION_REFUSED が出ると報告された場合、サーバー自体は稼働している（DNS は解決され、マシンはおそらく ping に応答する）ものの、ウェブサービスが接続を受け付けていない状態です。次のチェックリストを順に確認してください：

• ウェブサーバーのプロセスは動いていますか？ SSH でログインして確認します：systemctl status nginx（または apache2、caddy）。リロード失敗後のクラッシュや OOM キルによるプロセス停止が原因の第1位です。再起動：sudo systemctl restart nginx。

• 正しいポートで待ち受けていますか？ ss -tlnp | grep -E ':80|:443' を実行します。443 で何も待ち受けていないなら、TLS 設定の読み込みに失敗しています。nginx -t で設定エラーを確認してください。

• ファイアウォールは開いていますか？ ufw status またはクラウドプロバイダーのセキュリティグループを確認します。ポート 80 と 443 は 0.0.0.0/0 からのインバウンド TCP を許可する必要があります。

• サーバーの IP が変わっていませんか？ DNS Lookup を使って、DNS の A レコードとサーバーの実際の IP を比較します。移行後に古い A レコードが残っていると、訪問者は以前のマシンへ誘導されます。

• 外部からテストする — ポート 80 と 443 に対して ポートチェッカー を実行し、HTTP ヘッダーチェッカー で、サーバーが公共のインターネットからの実際のリクエストに応答することを確認します。

修正が効いたか確認する方法

各解決策を試した後は、単にページを再読み込みするのではなく、ネットワークレベルで接続を確認しましょう。これにより、ポートが実際に開いたかどうかがわかります。

# Test the TCP connection directly (Mac/Linux):
nc -zv example.com 443
# "succeeded" = port open, "refused" = still rejected

# Windows (PowerShell):
Test-NetConnection example.com -Port 443
# TcpTestSucceeded : True = fixed

# Then confirm what IP you're actually connecting to:
nslookup example.com

ターミナルを使いたくない場合は、DNS Robot の ポートチェッカー にドメインとポートを入力すれば、外部ネットワークからの open/closed の判定が即座に得られます。外部からはポートが open なのにブラウザが依然として ERR_CONNECTION_REFUSED を表示するなら、ブロックしているのはあなたのデバイス側です。上記のプロキシ、VPN、ウイルス対策、hosts ファイルの解決策を見直してください。