ERR_CONNECTION_REFUSED：原因と対処法

エラーの意味

ブラウザーはサーバーのアドレスを見つけ、ポート 443（または 80）に接続要求を送りましたが、サーバーは「ノー」と答えました。そのポートで待ち受けているプログラムがないときに、オペレーティングシステムが送る TCP リセットです。Chrome は ERR_CONNECTION_REFUSED（「このサイトにアクセスできません」）、Firefox は「接続できません」、Safari は「Safari がサーバに接続できません」と表示します。

これは、タイムアウト（まったく応答がない状態で、通常はパケットを破棄するファイアウォールや、電源が切れたサーバー）とも、DNS_PROBE_FINISHED_NXDOMAIN（名前が名前解決されない）とも異なります。接続拒否とは、マシンは稼働していて到達できるのに、その上のウェブサーバーが動いていない、別のポートやアドレスで待ち受けている、または破棄ではなく拒否するファイアウォールにブロックされている、ということです。

よくある原因

1. ウェブサーバーが停止しています。 nginx や Apache が、クラッシュした、設定変更後に起動に失敗した、アップデートで停止された。圧倒的に多い原因です。
2. ウェブサーバーが誤ったアドレスまたはポートで待ち受けています。 listen ディレクティブの変更後、DNS レコードは IPv6 アドレスを指しているのに、nginx が 127.0.0.1 のみ、または IPv4 のみにバインドしています。
3. ファイアウォールがポートを拒否しています。 ufw、firewalld、またはクラウドのセキュリティグループに、80/443 への reject ルールがあります。誰かがサーバーを「堅牢化」した後に多く起こります。
4. ウェブサーバーのない新しいサーバーです。 DNS レコードはすでに新しい IP を指しているのに、nginx がインストールされていない、またはまだ起動していません。
5. HTTPS が設定されていません。 ポート 80 は動作し、ポート 443 には待ち受けがないのに、ブラウザー（または HSTS のエントリ）が HTTPS を要求します。
6. 訪問者側のローカルな原因です。 使われていないプロキシを指すプロキシ設定、VPN、ウイルス対策の「ウェブシールド」、hosts ファイルのエントリ、ブラウザーの拡張機能。

訪問者の場合

1. プライベートウィンドウと別のブラウザーでサイトを試してください。拡張機能とキャッシュの影響を除外できます。
2. プロキシ設定を確認します。Windows の「プロキシ設定」、macOS の「ネットワーク」＞「詳細」＞「プロキシ」。使っていない手動のプロキシはオフにしてください。
3. VPN とウイルス対策のウェブ保護を、一時的にオフにしてください。
4. 移転したサイトの古いアドレスがキャッシュに残っている場合に備えて、DNS を消去します（ipconfig /flushdns、sudo dscacheutil -flushcache）。
5. https:// の代わりに http:// を一度試してください。それで動作するなら、サイトの HTTPS が壊れており、運営者が修復する必要があります。

ご自身のサイトの場合：まず確認

ウェブサイトダウンチェッカーを実行してください。外部から「Connection refused」と出れば、サーバー自体が拒否していることが確認できます。次に、SSH でログインします（ウェブサイトは拒否するのに SSH は動作する場合、それ自体が強いヒントです。サーバーは動いていて、ウェブサーバーが動いていません）。

# ウェブサーバーは動いているか？
systemctl status nginx
systemctl status apache2

# 80 と 443 で待ち受けているのは何か？
sudo ss -tlnp | grep -E ':80 |:443 '

# ファイアウォールのルール
sudo ufw status verbose
sudo firewall-cmd --list-all
sudo nft list ruleset | grep -E 'dport (80|443)'

ss が 443 に何も表示しない場合、ウェブサーバーが停止しているか、443 向けに設定されていません。0.0.0.0:443 や *:443 ではなく 127.0.0.1:443 と表示される場合は、ローカルでのみ待ち受けています。

ご自身のサーバーでの対処法

1. ウェブサーバーを起動し、停止した理由を読む

sudo systemctl start nginx
systemctl status nginx
sudo journalctl -u nginx -n 50

起動に失敗する場合、理由はほぼ必ず次のいずれかです。

• nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)：別のプログラムがポートを保持しています（Apache と nginx の両方がインストールされている、または古いプロセス）。sudo ss -tlnp | grep :80 で名前がわかります。不要な方を停止してください。
• [emerg] unknown directive または unexpected "}"：設定ファイルの構文エラーです。sudo nginx -t が、ファイルと行を表示します。
• cannot load certificate：証明書ファイルが削除されたか、別のパスに更新されました。ssl_certificate の行を、ディスク上のものと照合してください。
• Too many open files またはディスクの満杯：df -h、df -i。

Apache：sudo apachectl configtest、次に sudo journalctl -u apache2 -n 50。同じ分類が当てはまります。AH00558（サーバー名を判別できません）は警告にすぎず、原因ではありません。

再読み込みの前に必ずテストし、可能なら再起動ではなく再読み込みを使います。

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

2. 正しいアドレスで待ち受ける

nginx の server ブロックでは、IPv4 と IPv6 の両方に、次の両方が必要です。

listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

DNS に AAAA レコードがあるのに、サーバーが IPv6 で待ち受けていない（または IPv6 の接続がない）場合、IPv6 の訪問者は接続拒否になり、それ以外の訪問者は問題なく表示されます。待ち受けるようにするか、AAAA レコードを削除してください。

3. ファイアウォールを開ける

# ufw（Debian/Ubuntu）
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# firewalld（RHEL 系）
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

クラウドサーバーでは、コントロールパネルで、プロバイダーのセキュリティグループやネットワークファイアウォールも確認してください。そこにあるルールは、サーバーの内部からは見えません。

4. ポート 80 のみ応答する場合は HTTPS を設定する

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot が、443 の server ブロックとリダイレクトを追加します。その後、SSL チェッカーで、チェーンが完全であることを確認してください。

5. サーバーの移転後

DNS を変更する前に、新しいマシンのウェブサーバーがインストールされ、ドメイン用に設定され、起動していることを確認してください。すでに変更した場合は、いますぐインストールして起動するか、新しいサーバーの準備ができるまで、レコードを旧サーバーに戻してください。

ホスティング会社の問題の場合

共有ホスティングでの接続拒否は、ホスティング会社のウェブサーバーが、お客様のノードでダウンしているか、DNS を更新せずに新しい IP へ移されたことを意味します。次の文面を送ってください。

お世話になっております。ウェブサイト example.com が、20:15 UTC 頃から、ポート 80 と 443 で「connection refused」を返しています。ドメインは 203.0.113.10 に名前解決されます。アカウント内では何も変更していません。そのマシンのウェブサーバーがダウンしているのでしょうか。それとも、私のサイトが別のアドレスに移されたのでしょうか。

次回に備えて

接続拒否は、ほぼ必ずウェブサーバーの停止が原因です。そして、停止したサービスは、外部からのポートチェックとウェブサイトのチェックが、1 分以内に検知するものです。ご自身のサーバーでは、サーバーエージェントが、nginx や Apache が停止したときにアラートを出し、Quick Fix が、設定テストに合格した後で、定額で再起動します。午前 3 時に誰かがログインする必要はありません。設定自体が壊れている場合は、Deep Fix が修復します。