HTTP & Server Errors

About this error category

# HTTP & Server Errors

HTTP and server errors occur when a request cannot be completed normally. Some failures return an HTTP status code such as 500, 502, 503 or 504. Others happen before the browser receives an HTTP response, producing messages such as ERR_CONNECTION_REFUSED or ERR_CONNECTION_TIMED_OUT.

The browser message identifies the symptom, not always the component that needs attention. Start by locating the failing boundary: browser to network, network to listening service, proxy to backend, or application to dependency.

Identify the failure type first

An HTTP status code was returned

A numeric status means an HTTP-capable component responded. That component might be the origin web server, a reverse proxy, load balancer or CDN rather than the application itself.

• 500 Internal Server Error: The server encountered an unexpected condition while processing the request. Begin with the application and web-server logs. See the [500 Internal Server Error guide](/http-500-internal-server-error).
• 502 Bad Gateway: A proxy received an invalid, empty or unusable response from its backend. Check the backend process, upstream host and port, and the connection between the proxy and origin. See the [502 Bad Gateway guide](/http-502-bad-gateway).
• 503 Service Unavailable: The service cannot handle the request at that time. Possible directions include maintenance mode, exhausted capacity, an unavailable process or a failed dependency. See the [503 Service Unavailable guide](/http-503-service-unavailable).
• 504 Gateway Timeout: A gateway forwarded the request but did not receive a response before its timeout expired. The backend may still be running but slow, overloaded or waiting on another service. See the [504 Gateway Timeout guide](/http-504-gateway-timeout).

A status code does not, by itself, prove which layer failed. Inspect the response branding, headers, timestamp and logs to determine whether the response came from the origin or an intermediary.

The browser reports a connection failure

A connection-level error means the browser did not receive a normal HTTP response from the expected endpoint.

• ERR_CONNECTION_REFUSED: The destination was reached, but the connection was rejected. Check whether a service is listening on the expected port and whether local or network security rules affect access. For development environments, see [ERR_CONNECTION_REFUSED on localhost](/err-connection-refused-localhost).
• ERR_CONNECTION_TIMED_OUT: The browser waited without receiving a usable response. Investigate the network path, routing, filtering, DNS, server reachability and resource availability before looking for an application-generated HTTP error. See the [ERR_CONNECTION_TIMED_OUT guide](/err-connection-timed-out).

A practical diagnosis sequence

1. Reproduce and record the failure

Reload once, then try the same URL in a private window or on another device. Record the exact URL, error text, status code, approximate time and visible response page. A branded CDN or proxy page suggests that the request reached an intermediary; a generic browser message may mean that no usable HTTP response arrived.

If only one browser or device fails, inspect its proxy, VPN, DNS cache, extensions and local security software. If the same URL fails across devices and networks, the server, proxy, origin or shared network path becomes more likely.

2. Define the affected scope

Determine whether the problem affects one route, one host, an entire application or the whole service.

• One route failing can indicate application code, a route-specific dependency or a slow query.
• Every route returning 500 suggests a broader application or server configuration problem.
• A 502 or 504 across a proxy directs attention to the origin process, upstream connection or proxy configuration.
• A refused connection on one port can mean that the expected service is not listening while other services remain available.

Compare a working endpoint with the failing one when possible. Differences in routing, authentication, dependencies and deployment state can be more informative than changing unrelated client settings.

3. Check the component that generated the response

For a 500, correlate application and web-server logs with the failure time. For 502, 503 and 504 responses, inspect both proxy or gateway logs and backend logs. Look for a stopped process, failed deployment, dependency connection failure, resource exhaustion or a request that exceeds a relevant timeout.

For a local ERR_CONNECTION_REFUSED, verify that Apache or Nginx is running and that the configured port is available. XAMPP, Laragon and MAMP can show this symptom when their web server has not started or another program prevents it from binding to the expected port.

4. Test the origin and dependencies separately

Where you administer the service, check whether the backend accepts connections and responds to a simple endpoint without assuming that a successful proxy connection proves the application is healthy. Then check required services such as the database or other configured dependencies.

A backend that is alive but consistently slow is more consistent with a 504 than a backend that is stopped or returning an unusable response, which can produce a 502. A 503 may occur before an application request is processed if the service is deliberately unavailable or a required dependency cannot be used.

Avoid repeated refreshes as a troubleshooting method. They can add load while the underlying process, dependency or timeout problem is being investigated.

Use error details to locate the layer

The response body, headers and timestamp can reveal which component handled the failure:

• A generic browser message usually indicates that no usable HTTP response was received.
• A branded proxy or CDN page indicates that an intermediary generated or presented the error.
• An application-specific error page may point more directly to the origin application.

For intermittent failures, correlate the timing with deployments, traffic increases, process restarts and dependency latency. For consistent failures, compare a working request with the failing request and inspect configuration differences before changing server settings.

For sites using Cloudflare, a Cloudflare-branded 504 generally means its edge could not obtain a response from the origin within the applicable timeout window. The [504 Gateway Timeout Behind Cloudflare guide](/504-gateway-timeout-cloudflare) explains how to separate an origin problem from a timeout produced by another gateway or by the origin itself.

What to include when requesting help

A useful report includes:

• The exact error text and status code
• The URL path and approximate failure time
• Whether the issue affects other users, devices or networks
• Whether a proxy, CDN or load balancer is involved
• Relevant web-server, proxy and application log entries, with passwords, tokens and other secrets removed

The objective is to identify the failing boundary. Once that boundary is known, the relevant error guide can provide more targeted checks without treating browser, network, proxy and backend causes as interchangeable.