ERR_CONNECTION_REFUSED は、ブラウザーがリクエストを送ったものの、サーバー——またはあなたとサーバーの間にある機器——が能動的に接続を拒否したことを意味します。タイムアウトとは異なり、拒否された接続は即座に起こります。サーバー（またはファイアウォール）が、単に応答しないのではなく、拒否を返したのです。
解決策は、どちら側が拒否を引き起こしているかに完全に依存します。手順を進める前に、まずサイトチェックツールを使って2つの経路を切り分けてください。
要点: サイトが全員にとってダウンしているなら、解決策はサーバー側にあります——PHP-FPM または Apache/nginx が動作しているか確認し、ファイアウォールのルールがポート80と443を許可しているか確かめ、
.htaccessに不正なリライトルールがないか調べます。サイトが他の全員にとって動作しているなら、解決策はあなたのマシン側にあります——ブラウザーキャッシュを消去する、DNS をフラッシュする、またはプロキシ設定を無効にします。両方の経路を以下で段階的に解説します。
Contents
ブラウザーの問題か、サーバーの問題か？
どの解決策にも取りかかる前に、サイトが全員にとってダウンしているのか、あなただけなのかを見極めてください。1回の確認で、無駄なトラブルシューティングの時間のほとんどを省けます。
| あなたの状況 | 考えられる原因 | どこから始めるか |
|---|---|---|
| サイトが全員にとってダウン（チェッカーが確認） | サーバープロセスの停止、ポート80/443を遮断するファイアウォール、不正な .htaccess |
下のサーバー側の解決策セクション |
| 他の人にはサイトが見える。エラーはあなたの端末だけ | ブラウザーキャッシュ、DNS、プロキシ、ローカルファイアウォール | 下のクライアント側の解決策 |
エラーが localhost または 127.0.0.1 のみ |
XAMPP/WAMP のポート競合 | ローカルサーバーのポート設定を確認 |
| WP STAGING のプッシュ後に staging URL のみエラー | ネットワークマッピングまたはルーティングの設定ミス | 下の WP STAGING セクション |
/wp-admin のみエラー。フロントエンドは正常に読み込まれる |
セキュリティプラグインによるロックアウトまたは IP ブロック | FTP/SSH でセキュリティプラグインを無効化 |
よくある原因
ERR_CONNECTION_REFUSED は、クライアント側とサーバー側の両方の問題から生じる可能性があります。
- ネットワーク接続の問題: インターネット接続の不具合がサイトへのアクセスを妨げることがあります。
- 誤って設定されたファイアウォールやセキュリティソフト: 厳しすぎる設定が、あなたのマシンやホスティングサーバーでのアクセスを遮断することがあります。
- ブラウザーのキャッシュとクッキー: 破損または古くなったキャッシュデータがサイトの読み込みを妨げることがあります。
- DNS の問題: サイト名を IP アドレスに変換する際の不具合が接続を妨げることがあります。
- サーバープロセスの停止: Web サーバープロセス（Apache、nginx、PHP-FPM）がクラッシュしたか、再起動後に立ち上げ直されなかった場合、すべてのリクエストが TCP レイヤーで拒否されます。
- ポート80または443を遮断するファイアウォール: ホスティングパネルのファイアウォールは、異常なトラフィックパターンやログイン失敗のあとに HTTP/HTTPS ポートを自動的に閉じることがあります。
- 不正な
.htaccessまたは nginx のリライトルール: プラグインの更新や手動編集で持ち込まれた不正なリライトルールが、サーバーに特定の URL——あるいはすべての URL——を拒否させることがあります。
ERR_CONNECTION_REFUSED のための7つのクライアント側の解決策
これらの解決策は、エラーがあなたの端末でのみ起きている場合——サイトチェックツールがサイトは他の人にはアクセスできると確認している場合——に対処するものです。
- サイトの状態を確認する
- ネットワーク接続を確認する
- ルーターを再起動する
- ブラウザーキャッシュを消去する
- DNS キャッシュをフラッシュする
- ブラウザー拡張機能を無効にする
- プロキシ設定を無効にする
1. サイトの状態を確認する
Down For Everyone or Just Me や Is It Down Right Now のようなサイト監視ツールを使います。ツールにサイトの URL を入力して、全員にとってアクセス可能かダウンしているかを確認します。
ツールがサイトは全員にとってダウンしていると確認したら、サーバー側の解決策セクションへ進んでください。サイトはアクセス可能と報告された場合、問題はあなたの側にあります——下の解決策へ進んでください。
これで解決しない場合: 一部の CDN は、オリジンサーバーが接続を拒否していてもサイトを「アクセス可能」と報告します。チェッカーが「アクセス可能」と言うのに、異なるネットワークの複数の端末でまだエラーが見える場合は、サーバー側の問題として扱ってください。
2. ネットワーク接続を確認する
同じネットワーク上の他の端末を試します。どれもサイトに接続できないなら、問題はあなたのインターネットプロバイダーにあるかもしれません——サービス障害やデータ上限を確認してください。
これで解決しない場合: 同じネットワーク上の他の端末が問題なくサイトに到達するなら、問題は端末固有です。別のブラウザーを試すか、VPN ソフトがバックグラウンドで動作していないか確認してください。
3. ルーターを再起動する
ルーターの電源を30秒間抜き、差し直して、完全に再接続するまで待ちます。立ち上がったら、サイトへの再アクセスを試みます。これでネットワーク接続がリセットされ、一時的なルーティングの不具合が解消されることがあります。
4. ブラウザーキャッシュを消去する
ブラウザーは、読み込み時間を短くするためにサイトのデータを保存します。古いまたは破損したキャッシュデータが、ときに接続エラーを引き起こすことがあります。
Google Chrome: Ctrl + Shift + Delete を押し、希望する期間を選んで「データを削除」をクリックします。
Mozilla Firefox: Ctrl + Shift + Delete を押し、適切な期間を選んで「今すぐ消去」をクリックします。
キャッシュを消去したら、サイトを再読み込みしてエラーが解決したか確認します。それでもページが読み込まれない場合は、ブラウザーを閉じて開き直してみてください。
これで解決しない場合: 2つ目のブラウザー（Edge、Firefox、Safari）で試します。2つ目のブラウザーでページが読み込まれるなら、問題はブラウザー固有です——1つ目のブラウザーの設定をリセットするか、再インストールしてください。
5. DNS キャッシュをフラッシュする
DNS キャッシュをフラッシュすると、接続問題の原因になりうる、コンピューターに保存された古いまたは破損したホスト名から IP へのマッピングが削除されます。
検索バーに cmd と入力し、コマンドプロンプトを右クリックして「管理者として実行」を選びます。
次のコマンドを入力して Enter を押します。
ipconfig /flushdns
DNS リゾルバーキャッシュが正常にフラッシュされたことを確認するメッセージが表示されるはずです。そのあと、サイトを再読み込みしてエラーが解決したか確認してください。
これで解決しない場合: macOS ではターミナルを開き、sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder を実行します。ネットワーク内のすべてのブラウザーでエラーが続く場合は、モバイルホットスポットでサイトを試してください。そこで読み込まれるなら、あなたのインターネットプロバイダーがポートを遮断しているか DNS を傍受している可能性があります——パブリック DNS サーバーへの切り替えを試してください。
6. ブラウザー拡張機能を無効にする
広告ブロッカー、VPN 拡張機能、プロキシアドオンは、接続を傍受する原因として多いものです。ブラウザーの設定に進み、拡張機能またはアドオンのセクションへ移動します。
すべての拡張機能を切り替えてオフにし、一時的に無効化します。
拡張機能を無効にしたら、ウェブページを再読み込みします。エラーが消えたら、いずれかの拡張機能が問題を起こしています——1つずつ有効に戻して特定してください。
7. プロキシ設定を無効にする
誤って設定された、または応答しないプロキシサーバーは接続の仲介役として働き、不正なプロキシ設定が ERR_CONNECTION_REFUSED を引き起こします。
スタートメニューを開き、設定に進んで「ネットワークとインターネット」をクリックします。
左のメニューから「プロキシ」を選び、「手動プロキシセットアップ」の下で「プロキシ サーバーを使う」をオフにします。
システムやブラウザーがプロキシのアプリや拡張機能を使っている場合は、そのアプリまたは拡張機能の設定に進んでプロキシをオフにします。プロキシを無効にしたら、サイトの再読み込みを試してください。
これで解決しない場合: 企業ネットワークでは、プロキシが IT ポリシーで強制されていることがあります。その場合は、システム全体のプロキシを無効にしないでください——代わりに、該当サイトがプロキシ設定のホワイトリストに入っているか IT 管理者に尋ねてください。
WordPress における ERR_CONNECTION_REFUSED のサーバー側の解決策
サイトチェックツールがサイトは全員にとってダウンしていると確認した場合、問題はサーバーにあります。変更を加える前に、まず WordPress サイトをバックアップし、WordPress のデバッグモードを有効にして、根本的なエラーが wp-content/debug.log に書き込まれるようにしてください。
Web サーバープロセスが動作しているか確認する
SSH アクセスのある VPS または専用サーバーで、Apache または nginx と PHP-FPM がアクティブか確認します。
# Apache
sudo systemctl status apache2
# nginx
sudo systemctl status nginx
# PHP-FPM (8.2 をインストール済みの PHP バージョンに置き換えてください)
sudo systemctl status php8.2-fpmいずれかのサービスが inactive または failed と表示されたら、再起動します。
sudo systemctl restart apache2 # または nginx, php8.2-fpm私たちのサポートキューでは、停止した PHP-FPM プロセスが WordPress サイトにおける ERR_CONNECTION_REFUSED のサーバー側の原因として最も多いものです——サービスが起動時に自動的に開始するよう設定されていないと、サーバーの再起動後に静かに停止することがよくあります。
ポート80と443のファイアウォールルールを確認する
Web サーバープロセスは動作しているのに接続がまだ拒否される場合、ホスティングパネルのファイアウォールや iptables のルールがポート80（HTTP）や443（HTTPS）を遮断しているかもしれません。ホスティングのコントロールパネルでファイアウォールまたはセキュリティの設定を確認し、受信ルールが両ポートで TCP トラフィックを許可していることを確かめます。
ufw を使う VPS では：
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status.htaccess と nginx のリライトルールを確認する
不正な .htaccess ファイル——多くは WordPress プラグインのインストールや手動編集で持ち込まれます——は、サーバー側の拒否のよくある原因です。問題を切り分けるために、一時的に名前を変更します。
- FTP または SSH でサーバーに接続します。
/public_html/.htaccessを.htaccess_backupに名前変更します。- サイトを再読み込みします。読み込まれたら、
.htaccessが原因でした。 - wp-admin の 設定 → パーマリンク に進み、保存をクリックして、きれいな
.htaccessを再生成します。
nginx の構成では、WordPress の try_files リライトブロックがサーバーブロック構成に存在し、正しく整形されていることを確認します。
競合するプラグインまたはテーマを切り分ける
フロントエンドが読み込まれる一方で /wp-admin のみエラーが出る場合、セキュリティプラグインや IP ブロックのルールが管理画面への接続を拒否している可能性が高いです。WordPress のデバッグモードを有効にしたあと、wp-content/debug.log にブロックされたリクエストのエントリーがないか確認してください。
本番サイトで直接変更を加えないよう、WordPress のステージングサイトを作成し、プラグインを1つずつ無効にして競合を切り分けてください。
ときに、データベース接続の問題が、実際の原因が MySQL のパケットサイズ制限であるにもかかわらず、ブラウザーで ERR_CONNECTION_REFUSED として現れることがあります。wp-content/debug.log に「Packet too large」や「MySQL server has gone away」のエントリーがないか確認してください——それらが出ている場合は、続行する前に MySQL の max_allowed_packet を増やしてください。
WP STAGING のステージングおよびプッシュのエラー
WP STAGING のサポートチケットからは、ERR_CONNECTION_REFUSED は、宛先ドメイン URL のマッピングが誤って設定されている本番へのプッシュ操作中に最も多く現れます——ステージングサイトの内部リンクがプッシュ後もステージングドメインを参照したままで、本番サーバーが誤ったホストへ振り向けられたリクエストを拒否してしまうのです。WP STAGING → Settings → Network Mapping を確認し、宛先 URL が本番ドメインと正確に一致していることを確かめてください。
それ以外はアクセス可能なサイトで、プッシュやクローンの操作が接続エラーで失敗する場合、根本原因はしばしば遮断された REST API エンドポイントです。診断手順については WordPress REST API の接続エラーを修正するを参照してください。同じ問題のタイムアウト系については、cURL エラー28「connection timed out」を修正するがそれらのケースを扱っています。
まとめ
ERR_CONNECTION_REFUSED は、2つの根本原因にきれいに分かれます。クライアント側の不具合（ブラウザーキャッシュ、DNS、プロキシ、ネットワーク）か、サーバー側の不具合（Web サーバープロセスの停止、ポートを遮断するファイアウォール、不正なリライトルール）です。どちらに当てはまるかを最も速く見極める方法はサイトチェックツールです——サイトが他の人にはアクセスできるならクライアント側の解決策を進め、全員にとってダウンしているならサーバーの確認へ直行してください。
WordPress サイトの所有者にとっては、サーバー側の経路のほうが影響が大きいものです。最近のバックアップを保持し、構成変更を本番に適用する前にステージングサイトで試すことで、最悪の結果のほとんどを避けられます。ERR_CONNECTION_REFUSED を解決したあとに SSL の警告に出くわした場合、「この接続ではプライバシーが保護されません」を修正するのが自然な次のステップです。接続エラーの空応答系については、WordPress で ERR_EMPTY_RESPONSE を修正するを参照してください。
関連記事
