ERR_EMPTY_RESPONSE

What this error means & how to recognize it

• The browser shows ERR_EMPTY_RESPONSE instead of an HTTP status such as 200, 404, or 500.
• The request fails before the browser receives response headers, HTML, or an application error page.
• Reloading may occasionally succeed if a worker, connection pool, or upstream service recovers.
• One hostname or route may fail while other sites remain accessible.
• A verbose command-line request may show that the TCP connection opens and then closes without response headers.
• The public URL may fail through a reverse proxy while an authorized request to the upstream service behaves differently.
• The error may affect only one browser, device, source network, VPN, or proxy path.

Root causes, ordered by likelihood

1. The application or PHP-FPM worker terminated before sending a response. Fatal application errors, worker crashes, process limits, memory pressure, or failed dependencies can end the request before a normal HTTP response is generated.
2. Nginx or the host has reached connection or file-descriptor capacity. Effective worker_connections, open-file limits, active connections, and available memory all affect whether requests and upstream connections can complete.
3. A reverse proxy cannot maintain a valid upstream connection. Incompatible keepalive behavior, connection reuse, timeout values, or proxy settings can cause the client connection to close before upstream headers arrive.
4. The upstream service is unavailable or resets connections. A service may be running but unable to accept, process, or complete the request.
5. A firewall, VPN, WAF, load balancer, or other network device closes the connection. This is more likely when the error depends on the client network, source address, or route.
6. A browser-local condition interferes with the request. Extensions, cached connection state, a local proxy, VPN, or security software can produce a similar symptom when other clients work normally.

How to fix it

1. Establish the failure scope

Record the hostname, exact path, approximate time with time zone, client, network, and whether the failure is consistent. Test the same path in a private window, another browser, another device, and—if permitted—another network.

If only one browser or device fails, first investigate extensions, local proxy settings, VPN software, cached connection state, and endpoint security controls. Do not assume the homepage is representative; test the specific route that fails.

2. Check whether the client receives response headers

From an affected or nearby client, make a read-only request to the authorized target. Replace the bracketed values with the real hostname and path:

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

If the connection closes without response headers, that supports an empty-response diagnosis. If an HTTP status is returned, investigate that status, redirect, TLS behavior, or browser rendering instead. Compare verbose output from a working and failing client when possible.

3. Correlate the request with server logs

Use the exact time and path to inspect:

1. Nginx or the relevant web server’s access and error logs.
2. PHP-FPM logs if the route invokes PHP.
3. Application logs for fatal errors, uncaught exceptions, and failed dependencies.
4. Operating-system logs for out-of-memory events, process termination, file-descriptor exhaustion, and service failures.

An access-log entry without a completed upstream response, an upstream reset, or a worker-termination message helps identify which layer closed the connection. The browser error alone cannot identify the responsible component.

4. Check PHP-FPM and application health

For a dynamic route, determine whether PHP-FPM has available workers and whether workers are repeatedly exiting, reaching configured limits, or being killed by the operating system. Check for recent deployments, fatal errors, memory pressure, slow database calls, and other blocked dependencies.

Change PHP-FPM limits, application code, or service state only after confirming the relevant evidence and assessing capacity and operational impact. A restart may temporarily clear failed workers, but it will not fix a recurring crash, resource exhaustion, or application defect. If a restart is authorized, capture logs and process state before performing it.

5. Check Nginx connection and file-descriptor capacity

Review the effective Nginx configuration and operating-system limits for the affected service. Examine worker_connections, worker-process behavior, active connections, open-file limits, available memory, and error messages indicating that a resource limit was reached.

Do not simply increase worker_connections. The operating-system file-descriptor limit and available memory must support the change. Capture current values and traffic conditions, follow the approved change procedure, and validate the result after a controlled reload or restart if one is authorized.

6. Isolate a reverse-proxy or upstream failure

If a CDN, load balancer, ingress, or Nginx reverse proxy sits in front of the application, compare:

• The public request through the proxy.
• An authorized request to the upstream from the proxy host or an equivalent internal test point.
• Proxy error logs and upstream application logs for the same timestamp.

Check whether the proxy is reusing a connection that the upstream has already closed, whether keepalive settings are compatible, and whether proxy and upstream timeouts suit the route. Change one related setting at a time, document the expected impact, and repeat the same test.

7. Check network and security controls

If no web-server log entry exists at the failure time, inspect the firewall, VPN, WAF, load balancer, routing, and client-side security path. Compare a working source network with the failing one and look for policy decisions, connection resets, or idle-connection handling that match the timestamp.

If the connection disappears before reaching the web server, escalate to the network or hosting team rather than changing application code.

8. Validate the fix while preserving evidence

After an approved application, configuration, or network change, repeat the same path and client tests. Confirm that the response now includes headers and an appropriate HTTP status, not merely that the browser stopped displaying the original message. Review proxy, web-server, upstream, application, and system logs, and retain before-and-after configuration values for comparison or rollback.

Prevention & how to verify the fix

• Monitor web-server errors, upstream resets, PHP-FPM worker availability, process exits, memory pressure, open-file usage, and connection-limit warnings.
• Document reverse-proxy, upstream keepalive, and timeout policies, and test them after infrastructure changes.
• Include a request identifier or precise timestamp with time zone in incident reports so proxy, web-server, and application logs can be correlated.
• Capacity-test connection and file-descriptor settings before increasing traffic or changing worker counts.
• Deploy application changes with a rollback plan and watch for fatal errors, worker crashes, and dependency failures immediately afterward.
• Maintain an authorized procedure for testing both the public endpoint and the upstream service separately.
• Keep service restarts and production limit changes within an approved change process.

Frequently asked questions