Understanding and Resolving Common Server Error Codes

HTTP status codes in the 5xx range indicate that something went wrong on the server side of a request. Unlike 4xx errors, which usually mean the client made an invalid request, 5xx errors mean the server encountered a problem it could not handle. For small business owners managing their own servers or web applications, understanding what each code means is the first step toward fixing the underlying problem.

This guide covers the four most common server errors, explains what causes each one, and describes the diagnostic steps and fixes that apply in most cases.

500 Internal Server Error

A 500 error is the most generic server error code. It means something went wrong on the server, but the server could not be more specific. It is essentially the server saying "I encountered an unexpected condition."

Common Causes

• A syntax error or exception in application code (PHP, Python, Node.js, etc.)
• Incorrect file permissions — the web server cannot read a required file
• A misconfigured .htaccess file on Apache servers
• A PHP memory limit being exceeded
• A database connection failure

How to Diagnose It

The server's error log is the most useful starting point. On a Linux server running Apache, the default error log is at /var/log/apache2/error.log. For Nginx, it is typically at /var/log/nginx/error.log. The log entry for a 500 error usually contains the actual exception or error message that caused the problem.

If you are running a PHP application, temporarily enabling error display can help during development. Add this to the top of the relevant PHP file:

ini_set('display_errors', 1);
error_reporting(E_ALL);

Remove this before the site goes back into production — displaying errors to users is a security risk.

502 Bad Gateway

A 502 error occurs when a server acting as a gateway or proxy receives an invalid response from an upstream server. In practice, this most commonly appears when a web server (such as Nginx) is forwarding requests to an application server (such as PHP-FPM, Gunicorn, or a Node.js process) and that application server is not responding correctly.

Common Causes

• The application server process has crashed or stopped
• The application server is overloaded and not responding within the timeout period
• A misconfiguration in the proxy settings — wrong port or socket path
• The upstream service (a third-party API, CDN, or microservice) is down

How to Diagnose It

Check whether the application server process is running. For PHP-FPM:

systemctl status php8.1-fpm

If the process is stopped, start it and check the logs for why it stopped. If the process is running, check the Nginx or Apache error log for the specific upstream error — it will usually include the socket or address that is failing.

503 Service Unavailable

A 503 error means the server is temporarily unable to handle the request. Unlike a 500 error, which indicates an unexpected failure, a 503 is often intentional — the server knows it cannot handle the request right now and is saying so explicitly.

Common Causes

• The server is overloaded — too many concurrent requests for the available resources
• The server is in maintenance mode
• A rate limiter is rejecting requests from a specific IP address
• The application has run out of worker processes

How to Diagnose It

Check server resource usage. On Linux:

top

or

htop

If CPU or memory usage is at 100%, the server is overloaded. The immediate fix is to identify and stop whatever process is consuming the resources. The longer-term fix depends on the cause — it might be a traffic spike, a runaway process, or a need to upgrade the server's resources.

If the server appears healthy, check whether maintenance mode is enabled in your application's configuration. Many content management systems and frameworks include a maintenance mode that returns 503 errors to all visitors.

504 Gateway Timeout

A 504 error is similar to a 502, but instead of receiving an invalid response from the upstream server, the gateway received no response at all within the allowed time. The upstream server took too long to respond.

Common Causes

• A slow database query that exceeds the timeout limit
• An external API call that is taking too long
• The upstream server is overloaded and processing requests slowly
• Network latency between the gateway and the upstream server

How to Diagnose It

Check the application's slow query log if the problem appears to be database-related. For MySQL:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;

This logs any query taking more than 2 seconds. Review the slow query log to identify which queries are causing the timeout.

If the problem is an external API call, check whether the API provider has a status page. Many major services publish real-time status information. You can also increase the timeout value in your application code as a temporary measure, though this is not a fix — it just delays the error.

Determining Whether the Problem Is on Your Server

Before spending time diagnosing your own server, it is worth confirming that the problem is actually there. Several external factors can cause 5xx errors that appear to originate from your server:

• A CDN or load balancer in front of your server may be generating the error code itself
• A DDoS attack may be overwhelming your server's capacity
• Your hosting provider may be experiencing infrastructure problems

Try accessing your server directly by IP address, bypassing any CDN or DNS. If the direct IP access works but the domain name does not, the problem is in the CDN or DNS layer, not your server.

Check your hosting provider's status page. Most managed hosting providers in Japan, including major providers like Sakura Internet, publish service status information that can confirm whether a platform-level incident is affecting your server.

Monitoring to Catch Problems Early

Reactive troubleshooting — waiting for users to report errors — is less effective than monitoring. Setting up basic uptime monitoring means you find out about server errors before your users do, and you have timestamp data that helps with diagnosis.

Free uptime monitoring services check your site at regular intervals and send an alert when it becomes unavailable. Even basic monitoring that checks every five minutes is significantly better than no monitoring at all. The IANA maintains authoritative documentation on HTTP status codes and their intended meanings.