ERR_CONNECTION_REFUSEDとは？接続が拒否される原因と解決方法

ERR_CONNECTION_REFUSED とは？

ERR_CONNECTION_REFUSED は、ブラウザがウェブサイトの IP アドレスを見つけたものの、そのアドレスにあるマシンに接続を拒否されたという意味です。 Chrome は「このサイトにアクセスできません」と表示し、「example.com で接続が拒否されました。」というメッセージと ERR_CONNECTION_REFUSED のコードを示します。Chromium のエラー一覧では -102 番のエラーです（net_error_list.h）。

あなたのデバイスはサーバーの IP アドレスとポート（HTTPS なら 443、HTTP なら 80）に TCP の接続要求を送り、すぐに拒否の応答を受け取りました。応答は TCP リセットか、ファイアウォールが返す「port unreachable（ポート到達不能）」メッセージのどちらかです。つまり、そのポートで接続を受け付けているプログラムがなかったか、ファイアウォールが要求を拒否したということです。DNS は成功しており、失敗したのは接続のほうです。

言い換えれば、これは無言ではなく「お断り」という返事です。何も応答がなければ、Chrome は待ち続けたうえで ERR_CONNECTION_TIMED_OUT を表示します。接続がいったん確立してから切断された場合は ERR_CONNECTION_RESET、サーバーがページを送る前に接続を閉じた場合は ERR_CONNECTION_CLOSED です。

他のブラウザやアプリではどう表示されるか

接続拒否はどこで起きても同じ現象で、変わるのは表示の文言だけです。Chromium ベースのブラウザ（Chrome、Edge、Brave、Opera）は ERR_CONNECTION_REFUSED のコードを表示し、アプリは OS 自身のエラーを報告します。

どの文言で表示されても、以下の解決策はそのまま使えます。そのアドレスとポートにある何かが接続を断った、ということだからです。

ERR_CONNECTION_REFUSED のよくある原因

サイト側から自分側の順に、原因は次のとおりです。

• ウェブサイトのサーバーがダウンしている — ウェブサーバー（nginx、Apache、Node.js）がクラッシュした、再起動中、または停止されています。マシン自体はオンラインでも、ポート 80 や 443 では何も応答しません。
• 拒否（reject）に設定されたファイアウォール — サーバー側、あなたのネットワーク、またはデバイス上のファイアウォールが、そのポートへの接続を（黙って破棄するのではなく）拒否しています。
• サイトがあなたのネットワークをブロックしている — VPN の出口サーバーや特定の国など、アドレスの範囲ごと接続を拒否するサイトがあります。
• セキュリティソフトや VPN — 通信をいったん自分自身に通すウイルス対策ソフトのウェブ保護や VPN が、接続を拒否しています。（Chrome をブロックしているのがデバイス上のファイアウォールの場合は、「インターネット アクセスがブロックされています」（ERR_NETWORK_ACCESS_DENIED）という別のページが表示されます。）
• IP アドレスが間違っている — 古い DNS キャッシュや hosts ファイルの記述のせいで、古いサーバーや自分のコンピューター（127.0.0.1）に接続しており、そこでは何も待ち受けていません。
• 記憶されたリダイレクトや HTTPS のルール — Chrome がリダイレクトやサイトの HSTS ルールをキャッシュしていて、サイトがもう使っていないポートへ送り続けています。
• localhost で何も待ち受けていない — 開発者向け：ローカルサーバーが起動していない、クラッシュした、または開いたものとは別のポートやアドレスで動いています。

特定のサイトだけ？すべてのサイト・ブラウザで？原因の切り分け方

何かを変更する前に、エラーがどこで出るかを見れば、どこを調べればよいかがわかります。

「すべてのブラウザで」という点が重要です。Edge、Firefox、Safari は Chrome のキャッシュや拡張機能を共有していないので、どのブラウザでも拒否されるなら、原因はブラウザより下の層、つまりデバイス、ネットワーク、またはサイトそのものにあります。

解決策1：サイト自体が落ちていないか確認する

デバイスの設定を変える前に、サイトが全員の接続を拒否していないかを確かめましょう。そうであれば、自分の側で何をしても直りません。

最も手早いのは、別のネットワーク経路から試すことです。スマホで Wi-Fi をオフにしてモバイルデータ通信でサイトを開いてください。続いて、次の DNS Robot のツールでサーバーを外部からテストします。

• サーバーダウンチェック — 世界 11 か所とあなた自身のブラウザからサイトを開きます。どこからもダウンならサイト側の問題、自分以外からはすべて正常なら自分側の問題です。
• ポートチェック — サイトとポート 443 を入力します（example.com:443 の形でも可）。閉じている（closed）なら当方からの接続も拒否されたということで、開いている（open）ならサーバーは接続を受け付けており、拒否はあなたの環境だけで起きています。
• Pingテスト — 世界 11 都市からサイトのポート 443 に接続し、さらに 1 か所から通常の ping を送ります。すべての都市で拒否されるなら、マシンは稼働しているものの、そのポートで何も待ち受けていません。通常の ping に応答がなくても何の証明にもなりません。多くのサーバーは ping を無視するからです。

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

Chrome 自身が最初に挙げる「接続を確認する」でも、「ケーブルを確認し、使用しているネットワーク デバイス（ルーター、モデムなど）を再起動してください。」と案内しています。再起動すると、ルーターにたまった状態が DNS キャッシュも含めてリセットされます。

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

解決策3：Chrome に残ったリダイレクトと HTTPS ルールを削除する

Chrome は恒久的なリダイレクトと、各サイトの HSTS ルール（「常に HTTPS を使う」という指示）を記憶しています。サイトがその後移転したり、ポート 443 で HTTPS を提供しなくなったりすると、Chrome は何も待ち受けていないアドレスやポートへ送り続けます。

• Chrome を開く → 3点メニュー → 閲覧履歴データを削除
• 期間 → 全期間 を選び、キャッシュされた画像とファイル にチェックを入れます（Cookie はそのままで構いません）
• データを削除をクリックします（Chrome にログインしていない場合は このデバイスから削除）。その後、もう一度サイトを開きます
• まだ拒否される場合： chrome://net-internals/#hsts を開き、「Delete domain security policies」の欄にドメインを入力して「Delete」をクリックします（この画面は英語表示のみです）。削除できるのはサイト自身が設定したルールだけで、Chrome に組み込まれた HSTS プリロードリストのドメインには効きません。

2026 年の変更点：Chrome 154（2026 年 10 月）では「常に安全な接続を使用する」が既定でオンになり、HTTPS に対応していない公開サイトに初めてアクセスする前に、Chrome は黙って試すのではなく許可を求めるようになります（Google Security Blog）。

解決策4：プロキシ設定を確認する

Chrome のエラーページにはプロキシの確認が挙がっているので、確認はしておきましょう。ただし、何が表示されるかは知っておいてください。Chrome がプロキシ サーバーに接続できない場合に表示されるのは ERR_CONNECTION_REFUSED ではなく、見出しが 「インターネットに接続されていません」 で、ERR_PROXY_CONNECTION_FAILED（「プロキシ サーバーに問題がある、またはアドレスが正しくありません。」）と出るページです。そのページが表示されているなら、この解決策が当てはまります。

Windows：設定 → ネットワークとインターネット → プロキシ。「手動プロキシ セットアップ」で「プロキシ サーバーを使う」の横の 編集 をクリックし、オフにして 保存 をクリックします。見覚えのないアドレスなら「セットアップ スクリプトを使う」もオフにします。「設定を自動的に検出する」は、ネットワークで使われていないとわかっている場合を除き、オンのままにしてください。

macOS：システム設定 → ネットワーク → Wi-Fi → 詳細 → プロキシ。組織が設定したもの以外のプロキシをすべてオフにして、OK をクリックします。

Chrome はシステムのプロキシ設定を使い、Firefox も既定では同じです（「システムのプロキシー設定を利用する」）。そのため、古いプロキシが1つ残っているだけで、すべてのブラウザが一斉に使えなくなります。学校や職場のデバイスでは、プロキシは管理者が設定しており、自分では変更できません。

解決策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 をフラッシュする方法。

コンピューターが実際に使っているアドレス（hosts ファイルとキャッシュを含む）を確認するには、ping example.com、または PowerShell で Resolve-DnsName example.com を実行し、DNS確認 の結果と比べます。この用途に nslookup は使わないでください。nslookup は DNS サーバーに直接問い合わせるため、hosts ファイルもキャッシュも通りません。

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

フラッシュしても ISP の DNS サーバーが古いアドレスを返し続ける場合は、パブリックリゾルバーに切り替えて最新の回答を得ましょう。

Windows：設定 → ネットワークとインターネット → Wi-Fi → 既知のネットワークの管理 → 使っているネットワーク（有線の場合：イーサネット → 使っているネットワーク） → DNS サーバーの割り当ての「編集」 → 手動 → IPv4 をオン → 優先 DNS に 1.1.1.1、代替 DNS に 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つずつ試してください。まず VPN を切断して再読み込みします。次にウイルス対策ソフトのウェブ保護を1分だけ停止して再読み込みします。最後に、サードパーティ製のファイアウォール（ウイルス対策スイートに含まれていることが多い）を一時停止します。（macOS のファイアウォールは受信接続しか制御せず、Windows Defender ファイアウォールも、誰かがルールを追加していない限り送信方向の通信を許可します。Chrome に「インターネット アクセスがブロックされています」と表示される場合は、デバイス上のファイアウォールが原因です。）

どれかをオフにしてサイトが開けたら、それをオンに戻したうえで、そのサイトを例外に追加するか、別の VPN サーバーを選んでください。保護をオフにしたまま放置してはいけません。

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

拡張機能がこのエラーコードの原因になることはまれです。サイトをブロックする拡張機能の場合は ERR_BLOCKED_BY_CLIENT が表示されます。それでも、シークレット ウィンドウ（Ctrl+Shift+N、Mac では Cmd+Shift+N）で開くのは 10 秒でできるテストで、拡張機能とキャッシュされたデータをまとめて原因から外せます。シークレット モードでは、自分で許可していない限り拡張機能が無効になるからです。

シークレット モードで開けるなら、chrome://extensions ですべての拡張機能をオフにし、エラーが再発するまで1つずつオンに戻します。シークレット モードでも失敗するなら、原因は Chrome の外にあります。

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

hosts ファイルは、そこに書かれた名前について DNS より優先されます。サイトが 127.0.0.1 や古いサーバーの 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.

解決策10：スマホ（Android・iPhone）の場合

スマホでも接続が拒否される理由は同じで、操作する設定が違うだけです。

• 回線を切り替える：モバイルデータで開き、次に Wi-Fi で開きます。片方でだけ拒否されるなら、問題はスマホではなくそのネットワークにあります。
• VPN アプリをオフにする：VPN として動作する広告ブロッカーやファイアウォールのアプリも含みます（ステータスバーに鍵や VPN のアイコンが表示されます）。
• Wi-Fi のプロキシを外す：Android では、接続中の Wi-Fi ネットワークの設定を開き → 鉛筆アイコン → 詳細設定 → プロキシ → なし にします（表記は機種によって異なります）。iPhone では、設定 → Wi-Fi → ネットワーク名の横の ⓘ → プロキシを構成 → オフ にします。
• Chrome のデータを削除する：Chrome → 設定 → プライバシーとセキュリティ → 閲覧履歴データを削除 → キャッシュされた画像とファイル。
• 自分のサーバーをテストしている場合：スマホでは localhost はスマホ自身を指します。代わりにコンピューターのローカル IP アドレスを使ってください（次のセクションを参照）。

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

「localhost で接続が拒否されました。」（localhost refused to connect）や 127.0.0.1 での ERR_CONNECTION_REFUSED は、開いたアドレスとポートで、あなたのマシン上の何も接続を受け付けていないことを意味します。よくある理由は次のとおりです。

• 開発サーバーが起動していない — 起動し忘れたか、クラッシュしています。npm run dev、rails s、python manage.py runserver が動いているはずのターミナルを確認してください。
• ポートが違う — サーバーが別のポートで起動しています（3000 が使用中だったため 3001 になった、など）。起動時に表示される行からアドレスをコピーしてください。
• アドレスにポートがない — http://localhost はポート 80 に接続しますが、開発サーバーは独自のポート（3000、5173、8000、8080）を使います。
• 127.0.0.1 と [::1] の違い — ブラウザは localhost に対して両方のアドレスを試しますが、サーバーが片方でしか待ち受けていないことがあります。もう一方のアドレスを直接開いた場合（http://127.0.0.1:3000 や http://[::1]:3000）や、片方しか試さないツールから接続した場合は拒否されます。
• Docker の中で動かしている — アプリはコンテナ内で 0.0.0.0 で待ち受け、ポートを公開（-p 3000:3000）する必要があります。コンテナ内で 127.0.0.1 にバインドしたアプリには、手元のマシンから接続できません（代わりに ERR_EMPTY_RESPONSE が出ることもあります）。
• スマホやエミュレーターから開いている — そこでは localhost はその端末自身です。コンピューターの LAN 内 IP を使い、開発サーバーをすべてのインターフェースで起動する（Vite なら --host）か、Android Emulator ではコンピューターの localhost を指す別名 10.0.2.2 を使ってください。

# What is listening on port 3000?
# macOS / Linux:
lsof -nP -iTCP:3000 -sTCP:LISTEN

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

# No output = nothing is listening = connection refused.
# 127.0.0.1:3000 in the output = IPv4 only; [::1]:3000 = IPv6 only.

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

埋め込まれたページの中に「接続が拒否されました」と出る場合

他のページ内の枠（埋め込まれたフォーム、レポート、地図、ログイン画面など）の中に「example.com で接続が拒否されました。」と表示される場合、たいていはネットワークの問題ではありません。埋め込まれた側のサイトが X-Frame-Options または Content-Security-Policy: frame-ancestors ヘッダーで他サイトのページ内への表示を禁止しているときも、Chrome は同じ文を表示します。内部的には ERR_BLOCKED_BY_RESPONSE、エラー -27 です（net_error_list.h）。

訪問者としては、埋め込まれたリンクを別のタブで開けば表示されます。サイト管理者としては、自分のページを埋め込むページを Content-Security-Policy: frame-ancestors 'self' https://parent.example で許可します。X-Frame-Options で指定できるのは DENY か SAMEORIGIN だけで、両方のヘッダーが送られた場合、現在のブラウザは frame-ancestors に従います。自分のサイトが何を送っているかは HTTPヘッダーチェッカー で確認でき、正確なヘッダーの書き方は X-Frame-Options のガイド にまとめています。

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

訪問者から自分のサイトで ERR_CONNECTION_REFUSED が出ると報告された場合、パケットはあなたの IP のマシンまで届いていますが、そこで接続を受け付けるものがありません。次のチェックリストを順に確認してください。

• ウェブサーバーは動いていますか？ SSH でログインして systemctl status nginx（または apache2、caddy）を確認します。壊れた設定のまま再起動して起動に失敗したサーバーや、メモリ不足で強制終了されたサーバーは、何も待ち受けていない状態になります。sudo systemctl restart nginx で再起動します。
• 正しいポートとアドレスで待ち受けていますか？ ss -tlnp | grep -E ':(80|443) ' を実行します。127.0.0.1 でしか待ち受けていないサーバーは外部からの接続をすべて拒否します。443 で何も待ち受けていないなら、そのポートで待ち受ける server ブロックがありません（HTTPS が未設定か、サイトの設定ファイルが有効になっていない）。nginx -T で実際に読み込まれている設定を表示できます。
• ファイアウォールが拒否していませんか？ 拒否（iptables の REJECT、ufw reject）に設定したルールは拒否応答を返します。ufw の既定の deny や AWS のセキュリティグループなどのクラウドファイアウォールは、代わりにパケットを黙って破棄するため、訪問者には ERR_CONNECTION_TIMED_OUT として表示されます。
• fail2ban が誰かを BAN していませんか？ 既定の BAN は対象のアドレスを拒否するため、その訪問者（または SSH のログインに何度か失敗したあなた自身）には ERR_CONNECTION_REFUSED が表示され、他の人は普通にアクセスできます。sudo fail2ban-client status で確認します。
• サーバーの IP が変わっていませんか？ DNS確認 で A レコードとサーバーの実際の IP を比較します。移行後に古い A レコードが残っていると、訪問者は以前のマシンへ送られます。
• Cloudflare を使っていますか？ プロキシ（オレンジの雲）に設定したレコードでは、訪問者はあなたのサーバーではなく Cloudflare に接続するため、このコードは表示されません。オリジンサーバーが Cloudflare からの接続を拒否すると、Cloudflare は独自の Error 521: Web server is down を表示します。
• 外部からテストする：ポート 80 と 443 は ポートチェック で、公共のインターネットからの実際のリクエストは HTTPヘッダーチェッカー で確認します。

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

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

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

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

# Then confirm the address your computer actually uses:
ping -c 1 example.com          # Mac/Linux
Resolve-DnsName example.com    # Windows PowerShell

ターミナルを使わない方法もあります。DNS Robot の ポートチェック にドメインとポートを入力すれば、外部ネットワークから見た open/closed の判定がわかります。外部からはポートが開いているのにブラウザで ERR_CONNECTION_REFUSED が出続けるなら、ブロックしているのはあなたのデバイスかネットワークです。VPN、セキュリティソフト、hosts ファイルの解決策に戻ってください。