ERR_CONNECTION_REFUSED
結論
ERR_CONNECTION_REFUSEDは、ブラウザーが宛先アドレスには到達したものの、Webサイトがレスポンスを返す前に接続を拒否されたことを示します。よくある原因には、Webサーバーの停止、ポート80または443で待ち受けているプロセスがないこと、localhostのみにバインドされたサービス、誤ったDNSの宛先、アクセスをブロックするファイアウォールルールなどがあります。まず宛先と待ち受け状態を確認し、その後、外部ネットワークからテストしてください。
要点
- すぐに拒否される場合は、接続が遅いというより、サービス、ポート、バインド、またはネットワークルールの問題であることが一般的です。
- ブラウザーの設定を変更する前に、Nginx、Apache、またはアプリケーションサーバーが稼働しているか確認してください。
- リクエストされたポート（通常はHTTPが80、HTTPSが443）でプロセスが待ち受けていることを確認してください。
127.0.0.1で待ち受けている場合、ローカルでは動作しても外部接続は拒否されることがあります。- 変更を行うたびにサーバー外部からテストし、ローカルでの成功によって外部アクセスの問題が隠れないようにしてください。
Site Administrator
このエラーの意味と見分け方
- Chrome、Edge、またはその他のChromiumベースのブラウザーに「このサイトにアクセスできません — ERR_CONNECTION_REFUSED」と表示される。
- 長時間待機した後ではなく、すぐにエラーが表示される。長い遅延は、
ERR_CONNECTION_TIMED_OUTなどのタイムアウトのほうが典型的です。 - 以前は動作していたサイトが、サーバーの再起動、デプロイ、DNS変更、設定更新、またはファイアウォール変更の後にアクセスできなくなる。
- 同じマシン上のSSHや別のアプリケーションポートには引き続き到達できる一方、Webポートへの接続は拒否されることがある。
- サービスがlocalhostのみに待ち受けている場合や、外部ファイアウォールがポートをブロックしている場合、サーバー上からのリクエストは成功しても外部からのリクエストは失敗する。
可能性の高い順の主な原因
- Webサーバーまたはアプリケーションプロセスが停止している — Nginx、Apache、またはアプリケーションサーバーがクラッシュした、停止された、または起動に失敗した可能性があります。
- リクエストされたポートで何も待ち受けていない — サービスが別のポートを使用している一方で、リクエストは80または443に送られている可能性があります。
- サービスが誤ったインターフェースにバインドされている —
127.0.0.1で待ち受けるサービスはローカルリクエストを受け付けますが、外部からの直接接続は受け付けません。 - ホストまたはクラウドのファイアウォールがトラフィックを拒否している — OSのファイアウォール、セキュリティグループ、ネットワークACL、またはプロバイダーのファイアウォールが変更された可能性があります。
- DNSが誤った宛先を指している — ドメインが古いサーバー、再構築されたサーバー、または未設定のサーバーに解決されている可能性があります。AAAAレコードによって、一部の訪問者がWebリスナーの動作していないIPv6アドレスに誘導されることもあります。
修正方法
1. 宛先アドレスを確認する
ドメインのAレコードとAAAAレコードを確認し、解決されたアドレスをリクエストを受けるはずのサーバーと比較します。ドメインが古いサーバー、廃止済みのサーバー、または新しく再構築されたサーバーを指している場合は、Webサービスの設定を変更する前にDNSを修正してください。IPv4とIPv6の両方のレコードが存在する場合は、サービスとファイアウォールが両方の経路に対応していることを確認します。
2. サービスが稼働しているか確認する
SSHなど、権限のある管理方法を使用して、該当するサービスを確認します。たとえば、systemctl status nginxでNginxの状態を確認します。Apacheまたはアプリケーションサーバーの場合は、同等のサービス名を使用してください。
サービスが停止または失敗している場合は、起動する前に状態とログを確認します。最近の変更で導入された設定エラーは、起動失敗の一般的な原因です。Nginxではnginx -t、Apacheではapachectl configtestを使用して設定を検証します。テストに成功し、サービスを変更する権限がある場合に限り、再起動またはリロードを行ってください。再起動によって処理中のリクエストが中断される可能性があるため、本番環境のピーク時には適切でない場合があります。
3. 待ち受けポートとインターフェースを確認する
サーバー上でss -tlnpまたはプラットフォームに相当するコマンドを使用して、待ち受け状態を確認します。通常は:80または:443など、リクエストされたポートで想定されるプロセスが待ち受けていることを確認してください。
ポートだけでなく、バインドアドレスも確認します。
0.0.0.0:80または0.0.0.0:443は、通常、利用可能なIPv4インターフェースで待ち受けます。- 特定のサーバーアドレスが表示される場合、サービスはそのインターフェースにバインドされています。
127.0.0.1:80または127.0.0.1:443は、ローカルリクエストのみを受け付けます。
アプリケーションをlocalhostで意図的に非公開にしている場合は、公開側のリバースプロキシが稼働し、アプリケーションへ転送していることを確認します。それ以外の場合は、承認済みのメンテナンスまたはデプロイ変更の中で、意図したインターフェースで待ち受けるようサービス設定を調整してください。
4. ホストとクラウドのファイアウォールルールを確認する
ufw status、iptables -L、またはOSに相当するコマンドを使用して、サーバーのファイアウォールを確認します。続いて、対象サーバーに関連付けられたクラウドのセキュリティグループ、ネットワークACL、またはプロバイダーのファイアウォールを確認します。
必要なポートへのインバウンドトラフィックが、適切な送信元から許可されていることを確認します。公開Webサイトではインターネットからのアクセスが必要になる場合がありますが、内部サービスでは承認済みのより狭い範囲を使用すべきです。両方のレコードタイプを公開している場合は、IPv4とIPv6のルールを個別に確認します。必要以上にアクセス範囲を広げず、ファイアウォールの変更は必ず承認を得て行ってください。
5. ローカルと外部からテストする
サーバー上から、ローカルのリスナーと設定済みのホスト名を別々にテストします。ローカルで成功しても、そのマシン上で何かが応答していることしか確認できず、外部クライアントがポートに到達できることは証明できません。
DNS、サービス、バインド、またはファイアウォールを修正した後、別のネットワークまたは外部マシンから、影響を受けたホスト名に対して詳細なcurl -vリクエストを実行します。リクエストが想定されたアドレスとポートに到達していること、および拒否が解消されたことを確認してください。
6. 最近の変更を比較する
デプロイ、再起動、サーバーの再構築、DNS更新、またはファイアウォール変更の後に障害が始まった場合は、現在の設定を最後に正常だったバージョンと比較します。特に、変更されたポート、サービスの起動失敗、localhostのみのバインド、誤ったサーバーに適用されたルール、不完全なIPv6設定を確認してください。
予防と修正確認
- サービスマネージャーまたはプロセススーパーバイザーを使用して、予期しない障害からWebサービスを復旧できるようにします。
nginx -tやapachectl configtestなどの設定検証を、リロードまたは再起動前に必ず行うデプロイチェックにします。- 想定ポート、バインドアドレス、ファイアウォールルール、セキュリティグループ、DNSレコードを正常時の基準として文書化します。
- ローカルのヘルスチェックだけに頼らず、サーバー外部からサービスを監視します。
- ドメインにAレコードとAAAAレコードの両方がある場合は、IPv4とIPv6のリスナーおよびファイアウォールルールを確認します。
- インフラストラクチャの変更を記録し、新たな接続拒否をデプロイ、再構築、DNS更新、またはファイアウォール変更と関連付けられるようにします。
外部の助けが必要なタイミング
サービスが稼働し、想定ポートが正しいインターフェースで待ち受け、DNSが意図したサーバーを指し、ファイアウォールルールがトラフィックを許可しているにもかかわらず、外部接続が拒否され続ける場合は、ホスティングまたはクラウドプロバイダーにエスカレーションしてください。影響を受けたホスト名、おおよその開始時刻、最近のインフラストラクチャ変更、待ち受けポートの出力、関連するファイアウォールまたはサービスログの調査結果を提供します。診断情報を共有する前に、非公開の認証情報と機密性の高い設定を削除してください。
よくある質問
ERR_CONNECTION_REFUSEDはタイムアウトと同じですか？
いいえ。ERR_CONNECTION_REFUSEDは通常、宛先が接続を拒否した場合、または利用可能なリスナーが接続を受け付けない場合に、すぐ返されます。タイムアウトは一般に、想定された時間内にリクエストへの応答がなかったことを意味します。
ERR_CONNECTION_REFUSEDでは、まず何を確認すべきですか？
Webサーバーまたはアプリケーションプロセスが稼働しているか確認し、次にリクエストされたポートでプロセスが待ち受けていることを確認します。これらの確認により、サービス停止の問題なのか、ポート、バインド、またはファイアウォールの問題なのかをすばやく切り分けられます。
サーバー上ではサイトが動作するのに、自分のコンピューターからは動作しないのはなぜですか？
サービスが127.0.0.1のみにバインドされている可能性があります。この場合、ローカル接続は受け付けますが、外部接続は受け付けません。ホストのファイアウォール、クラウドのセキュリティグループ、またはネットワークACLによって、ローカルトラフィックは許可されていても外部からのリクエストがブロックされることもあります。
一般的に関係するポートはどれですか？
HTTPでは通常ポート80、HTTPSでは通常ポート443を使用しますが、サイトまたはリバースプロキシが別の設定済みポートを使用する場合もあります。リクエストされたポートを、ss -tlnpまたはプラットフォームに相当するコマンドで表示されるリスナーと比較してください。
DNSがERR_CONNECTION_REFUSEDの原因になることはありますか？
DNS自体がTCP接続を拒否するわけではありませんが、誤ったAレコードまたはAAAAレコードによって、適切なWebリスナーがないサーバーにブラウザーが接続することがあります。解決されたアドレスと、その宛先でのサービス設定を確認してください。
Webサーバーをすぐに再起動すべきですか？
サービスの状態、ログ、設定構文を確認する前に再起動すべきではありません。再起動によってリクエストが中断されたり、元の原因が分からなくなったり、構文エラーが原因で再び失敗したりする可能性があります。まず設定を検証し、適切な権限がある場合に限って再起動またはリロードを行ってください。
関連ドキュメント
信頼できる参考資料については、ブラウザーの接続エラー、OSのサービスマネージャーとソケットツール、インストールされているNginxまたはApacheのバージョン、ホストのファイアウォール、クラウドプロバイダーのセキュリティグループまたはネットワークACL、DNSプロバイダーのAレコードとAAAAレコードの管理に関するドキュメントを参照してください。対象環境のサーバーOS、Webサーバー、ホスティングプラットフォーム、ネットワーク設計に合ったドキュメントを使用してください。