ERR_EMPTY_RESPONSE

結論

`ERR_EMPTY_RESPONSE` は、接続は確立したものの、ブラウザーが利用可能な HTTP レスポンスヘッダーまたは本文データを受信する前に接続が閉じられたことを示します。別のブラウザーまたはネットワークから失敗する URL をテストし、詳細出力に対応したクライアントと、相関する Web サーバー、PHP-FPM、アプリケーション、プロキシ、システムのログを使って、どの層が接続を閉じたのかを特定します。よくある原因には、アプリケーションワーカーのクラッシュ、Nginx またはファイルディスクリプターの容量枯渇、利用できない upstream、互換性のないプロキシの keepalive 設定などがあります。

要点

ERR_EMPTY_RESPONSE は、利用可能な HTTP レスポンスがないまま接続が終了したことを示します。connection refused や timeout とは異なります。
サーバー設定を変更する前に、別のブラウザー、デバイス、またはネットワークから、失敗している正確なパスをテストします。
詳細出力に対応したコマンドラインリクエストと正確なタイムスタンプを使い、クライアントの挙動をプロキシ、Web サーバー、PHP-FPM、アプリケーション、システムのログと突き合わせます。
サーバー側でよくある原因には、終了した PHP-FPM ワーカー、アプリケーション障害、Nginx またはファイルディスクリプターの容量枯渇、upstream による接続リセットがあります。
リバースプロキシでは、upstream が接続を閉じた後にプロキシが再利用しようとすることで、keepalive や timeout の不一致が表面化することがあります。
サービスを再起動したり制限値を増やしたりする前に証拠を収集し、本番環境の変更は承認済みの運用プロセスを通じてのみ実施します。

更新日: 2026-09-25 · 編集レビュー待ち HTTP とサーバーのエラー

Site Administrator

このエラーの意味と見分け方

ブラウザーに 200、404、500 などの HTTP ステータスではなく ERR_EMPTY_RESPONSE が表示されます。
ブラウザーがレスポンスヘッダー、HTML、アプリケーションのエラーページを受信する前にリクエストが失敗します。
ワーカー、接続プール、または upstream サービスが復旧すると、再読み込みで一時的に成功することがあります。
ほかのサイトにはアクセスできるのに、特定のホスト名またはルートだけが失敗することがあります。
詳細出力に対応したコマンドラインリクエストでは、TCP 接続が確立した後、レスポンスヘッダーなしで閉じられたことが示される場合があります。
リバースプロキシ経由の公開 URL は失敗する一方、upstream サービスへの許可されたリクエストでは異なる挙動になることがあります。
ほかのクライアントが正常に動作していても、特定のブラウザー、デバイス、接続元ネットワーク、VPN、またはプロキシ経路だけにエラーが発生することがあります。

可能性の高い順の主な原因

レスポンスを送信する前にアプリケーションまたは PHP-FPM ワーカーが終了した。 致命的なアプリケーションエラー、ワーカーのクラッシュ、プロセス制限、メモリ不足、依存サービスの障害などにより、正常な HTTP レスポンスが生成される前にリクエストが終了することがあります。
Nginx またはホストが接続数もしくはファイルディスクリプターの容量に達した。 実効的な worker_connections、オープンファイル制限、アクティブ接続数、利用可能なメモリは、リクエストと upstream 接続が完了できるかどうかに影響します。
リバースプロキシが有効な upstream 接続を維持できない。 keepalive の動作、接続の再利用、timeout 値、プロキシ設定の不一致により、upstream ヘッダーが到着する前にクライアント接続が閉じられることがあります。
upstream サービスが利用できない、または接続をリセットしている。 サービスが起動していても、リクエストを受け付けたり、処理したり、完了させたりできない場合があります。
ファイアウォール、VPN、WAF、ロードバランサー、その他のネットワーク機器が接続を閉じている。 エラーがクライアントネットワーク、接続元アドレス、または経路に依存する場合、この可能性が高くなります。
ブラウザー固有の状態がリクエストに干渉している。 他のクライアントが正常に動作している場合でも、拡張機能、キャッシュされた接続状態、ローカルプロキシ、VPN、セキュリティソフトによって同様の症状が発生することがあります。

修正方法

Diagnostic flow at a glance — full detail in the steps below.

1. 障害の範囲を確認する

ホスト名、正確なパス、タイムゾーン付きのおおよその発生時刻、クライアント、ネットワーク、障害が一貫して発生するかどうかを記録します。同じパスをプライベートウィンドウ、別のブラウザー、別のデバイス、そして許可されている場合は別のネットワークからテストします。

1 つのブラウザーまたはデバイスだけで失敗する場合は、まず拡張機能、ローカルプロキシ設定、VPN ソフトウェア、キャッシュされた接続状態、エンドポイントセキュリティの制御を調査します。ホームページが代表的な結果だと決めつけず、失敗する具体的なルートをテストしてください。

2. クライアントがレスポンスヘッダーを受信しているか確認する

影響を受けているクライアント、またはその近くのクライアントから、許可された対象へ読み取り専用のリクエストを送信します。角括弧内の値を実際のホスト名とパスに置き換えてください。

text

curl -v https://[your hostname]/[path]

レスポンスヘッダーなしで接続が閉じられる場合、空のレスポンスという診断を裏付ける情報になります。HTTP ステータスが返される場合は、そのステータス、リダイレクト、TLS の挙動、またはブラウザーのレンダリングを調査します。可能であれば、正常なクライアントと失敗するクライアントの詳細出力を比較してください。

3. リクエストとサーバーログを突き合わせる

正確な時刻とパスを使って、次のログを確認します。

Nginx または対象の Web サーバーのアクセスログとエラーログ。
そのルートが PHP を呼び出す場合は PHP-FPM のログ。
致命的なエラー、キャッチされない例外、依存サービスの障害に関するアプリケーションログ。
Out of Memory イベント、プロセス終了、ファイルディスクリプターの枯渇、サービス障害に関するオペレーティングシステムのログ。

アクセスログに完了した upstream レスポンスが記録されていない、upstream のリセットが発生している、またはワーカー終了メッセージがある場合、どの層が接続を閉じたのかを特定する手がかりになります。ブラウザーのエラーだけでは、原因となったコンポーネントを特定できません。

4. PHP-FPM とアプリケーションの健全性を確認する

動的なルートでは、PHP-FPM に利用可能なワーカーがあるか、ワーカーが繰り返し終了していないか、設定された制限に達していないか、オペレーティングシステムによって kill されていないかを確認します。最近のデプロイ、致命的なエラー、メモリ不足、遅いデータベース呼び出し、その他のブロックされている依存サービスも確認してください。

関連する証拠を確認し、容量と運用上の影響を評価してから、PHP-FPM の制限、アプリケーションコード、サービス状態を変更します。再起動によって失敗したワーカーが一時的に解消されることはありますが、繰り返し発生するクラッシュ、リソース枯渇、アプリケーションの欠陥は修正できません。再起動が承認されている場合は、実施前にログとプロセス状態を収集してください。

5. Nginx の接続数とファイルディスクリプターの容量を確認する

対象サービスについて、実効的な Nginx 設定とオペレーティングシステムの制限を確認します。worker_connections、ワーカープロセスの動作、アクティブ接続数、オープンファイル制限、利用可能なメモリ、リソース制限に達したことを示すエラーメッセージを調べます。

worker_connections を単純に増やしてはいけません。オペレーティングシステムのファイルディスクリプター制限と利用可能なメモリが、その変更を支えられる必要があります。現在の値とトラフィック状況を記録し、承認済みの変更手順に従い、承認された制御下で reload または再起動を行う場合は、その後に結果を検証します。

6. リバースプロキシまたは upstream の障害を切り分ける

アプリケーションの前段に CDN、ロードバランサー、ingress、または Nginx リバースプロキシがある場合は、次を比較します。

プロキシ経由の公開リクエスト。
プロキシホストまたは同等の内部テストポイントから upstream に送信した許可済みのリクエスト。
同じ時刻のプロキシエラーログと upstream アプリケーションログ。

プロキシが、upstream によってすでに閉じられた接続を再利用していないか、keepalive 設定に互換性があるか、プロキシと upstream の timeout がそのルートに適しているかを確認します。関連する設定は一度に 1 つだけ変更し、想定される影響を記録して、同じテストを繰り返します。

7. ネットワークとセキュリティの制御を確認する

障害時刻に Web サーバーのログエントリがない場合は、ファイアウォール、VPN、WAF、ロードバランサー、ルーティング、クライアント側のセキュリティ経路を調査します。正常な接続元ネットワークと失敗するネットワークを比較し、タイムスタンプと一致するポリシー判断、接続リセット、アイドル接続の処理を探します。

Web サーバーに到達する前に接続が消えている場合は、アプリケーションコードを変更するのではなく、ネットワークまたはホスティングの担当チームにエスカレーションします。

8. 証拠を保持しながら修正を検証する

承認されたアプリケーション、設定、またはネットワークの変更後、同じパスとクライアントのテストを繰り返します。ブラウザーに元のメッセージが表示されなくなっただけでなく、レスポンスにヘッダーと適切な HTTP ステータスが含まれていることを確認します。プロキシ、Web サーバー、upstream、アプリケーション、システムのログを確認し、比較またはロールバックに備えて変更前後の設定値を保存します。

予防と修正確認

Web サーバーのエラー、upstream のリセット、PHP-FPM ワーカーの可用性、プロセス終了、メモリ不足、オープンファイル使用量、接続制限の警告を監視します。
リバースプロキシ、upstream の keepalive、timeout のポリシーを文書化し、インフラストラクチャの変更後にテストします。
インシデント報告にはリクエスト ID またはタイムゾーン付きの正確なタイムスタンプを含め、プロキシ、Web サーバー、アプリケーションのログを相関できるようにします。
トラフィックを増やしたりワーカー数を変更したりする前に、接続数とファイルディスクリプターの設定について容量テストを実施します。
アプリケーションの変更はロールバック計画とともにデプロイし、その直後に致命的なエラー、ワーカーのクラッシュ、依存サービスの障害を監視します。
公開エンドポイントと upstream サービスを個別にテストするための承認済み手順を維持します。
サービスの再起動と本番環境の制限変更は、承認済みの変更プロセス内で行います。

外部の助けが必要なタイミング

複数のクライアントまたはネットワークにエラーが発生している場合、あるいはワーカーのクラッシュ、リソース枯渇、upstream の繰り返し発生するリセットと同時にエラーが発生している場合は、サーバーまたはホスティングの担当チームにエスカレーションします。Web サーバーのログエントリがなく、ファイアウォール、VPN、WAF、ロードバランサー、ルーティング層が接続を閉じている可能性がある場合は、ネットワークチームに連絡してください。

ホスト名とパス、タイムゾーン付きのタイムスタンプ、クライアントとネットワークの比較結果、詳細なリクエスト出力、関連するプロキシ、Web サーバー、PHP-FPM、アプリケーション、システムログの抜粋を提示します。特に障害の証拠を収集する前は、承認なしに再起動を繰り返したり、本番環境の設定を変更したりしないでください。

Webサイトを確認

よくある質問

ERR_EMPTY_RESPONSE は connection refused と同じですか？

いいえ。connection refused は通常、その時点でリスナーが存在しないか、アクセスルールによって接続試行が拒否されたことを示します。ERR_EMPTY_RESPONSE は、利用可能な HTTP レスポンスがないまま接続が終了したことを示すため、接続確立後に Web サーバー、upstream、プロキシ、またはネットワーク機器が接続を閉じた可能性があります。

ERR_EMPTY_RESPONSE は timeout と同じですか？

いいえ。timeout は、必要なネットワークまたは HTTP の通信が完了しないまま、クライアントが想定された時間を超えて待機したことを示します。ERR_EMPTY_RESPONSE では、通常、レスポンスヘッダーなしで接続が閉じられます。ただし、正確なブラウザーの挙動は障害が発生した場所によって異なります。

PHP-FPM が ERR_EMPTY_RESPONSE の原因になることはありますか？

はい。PHP-FPM ワーカーがクラッシュ、終了、またはリクエストを完了できない場合、正常なレスポンスが生成される前に Web サーバーとアプリケーション間の経路が終了することがあります。PHP-FPM が原因だと決めつけず、PHP-FPM、アプリケーション、Web サーバー、システムのログで確認してください。

なぜ Nginx の worker_connections を確認する必要があるのですか？

Nginx が実効的な接続数またはファイルディスクリプターの容量に達すると、新しい接続や upstream 接続を安定して処理できなくなることがあります。設定を変更する前にエラーログとオペレーティングシステムの制限を確認してください。システム側の容量を合わせずに値を増やすと、別のリソース問題が発生する可能性があります。

リバースプロキシによって空のレスポンスが発生するのはなぜですか？

upstream 接続がリセットされた場合、upstream が閉じた後に接続を再利用した場合、または互換性のない keepalive や timeout の動作によって接続が終了した場合、プロキシがクライアント接続を閉じることがあります。プロキシのログを許可された upstream テストと比較し、両側の接続設定を確認してください。

支援を依頼する前に何を収集すべきですか？

正確なホスト名とパス、障害のタイムスタンプ、複数のクライアントまたはネットワークでの結果、詳細なリクエスト出力、相関するプロキシ、Web サーバー、PHP-FPM、アプリケーション、システムのログを収集します。これにより、どの層が接続を閉じたのかを特定し、推測に頼らずに済みます。