Fix 504 Gateway Timeout Website: Developer & Host Checklists
- Onlive Server
- 7 days ago
- 7 min read
A 504 Gateway Timeout can make an otherwise working website appear unavailable. If you need to fix 504 Gateway Timeout website issues, the first step is finding out where the delay occurs whether it involves the network, web server, application, PHP-FPM, or database.
A 504 error happens when a gateway or proxy waits too long for a response from an upstream server. Fixing the problem is not always about increasing a timeout value. In many cases, the better solution is to identify and remove the bottleneck causing the delay.
What Is a 504 Gateway Timeout?
A 504 Gateway Timeout is an HTTP status error that usually means one server did not receive a response from another server within the expected time.
A typical website request may follow this path:
Visitor → Nginx/Proxy → PHP-FPM → Application → Database
If one component takes too long to respond, the request can eventually time out.
For example, Nginx may receive a request and pass it to PHP-FPM. If PHP-FPM is waiting for a slow database query, Nginx may continue waiting until its configured timeout is reached. The visitor can then see a 504 error.
For a broader explanation of the error and its causes, this guide to 504 Gateway Timeout error troubleshooting provides useful background.
Client-Side vs. Server-Side Causes of a 504
Before changing server settings, it helps to determine where the problem is occurring.
Most 504 errors are related to the server-side request path, but temporary network or connectivity issues can sometimes affect communication between the visitor and the website.
Area | Possible Cause | What to Check |
Client/Network | Temporary connectivity issue | Try another network or device |
DNS | Incorrect or delayed resolution | Check DNS records |
Proxy | Gateway waiting too long | Review proxy timeout settings |
Web Server | Nginx or Apache delays | Review server logs |
PHP | Slow or overloaded PHP-FPM workers | Check PHP-FPM status and logs |
Application | Inefficient code | Review recent changes and slow operations |
Database | Long-running queries | Optimize queries and indexes |
Server Resources | CPU or RAM pressure | Monitor resource usage |
This distinction helps prevent unnecessary troubleshooting. If the website fails for multiple users across different networks, focus on the server, application, and infrastructure first.
How to Fix 504 Gateway Timeout Website Problems
Once you know the issue is related to the server-side request path, check each component systematically.
1. Check Nginx Timeout Settings
Nginx often works as a web server or reverse proxy. It can forward requests to PHP-FPM or another backend service and wait for the response.
Several Nginx settings can affect how long it waits for an upstream response.
For example:
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
fastcgi_read_timeout 60s;
}
The exact PHP-FPM socket and configuration depend on the server environment.
The fastcgi_read_timeout setting controls how long Nginx waits for a response from the FastCGI server. If a legitimate operation requires more time, the value may need adjustment.
However, do not increase the timeout immediately. If a normal webpage takes 60 seconds to respond, increasing the timeout may simply hide the underlying performance problem.
After changing the configuration, test it before reloading Nginx:
nginx -t
If the configuration test succeeds, reload Nginx using the appropriate command for your operating system.
2. Review PHP-FPM Settings
PHP-FPM manages PHP worker processes that execute PHP applications. If these workers become overloaded, slow, or stuck, requests can take longer to complete.
Important PHP and PHP-FPM settings can include:
max_execution_time
max_input_time
memory_limit
pm.max_children
pm.max_requests
The correct values depend on the application and the server's available resources.
Check max_execution_time
PHP has an execution-time limit that can stop scripts running longer than the configured value.
For example:
max_execution_time = 60
Increasing this value can be appropriate for a legitimate long-running operation. However, it should not be used to compensate for inefficient application code.
Check PHP-FPM Workers
PHP-FPM can run multiple worker processes to handle incoming requests. If all available workers are busy, new requests may have to wait.
Check:
The number of active PHP processes
Whether workers remain busy for long periods
PHP-FPM error logs
Memory usage
Whether PHP processes are being terminated
Increasing the number of workers is not always the answer. Each worker consumes system resources, so raising the limit without checking available RAM can create additional performance problems.
3. Optimize Slow Database Queries
A slow database is a common reason an application takes too long to respond.
Imagine a WordPress website with a large product catalog. A search page may request thousands of records and perform several filtering operations before generating the final result.
If the query is poorly designed, the application may wait too long for the database. Eventually, the gateway can return a 504 error.
What Developers Can Check
Look for database queries that:
Process unnecessarily large datasets
Retrieve information that is not required
Perform inefficient joins
Execute the same expensive operation repeatedly
Lack appropriate indexes
Sort or filter large datasets unnecessarily
Database optimization should begin by identifying the actual slow query rather than adding more server resources without knowing the cause.
4. Check Application Code
If Nginx and PHP-FPM appear healthy, investigate the application itself.
A recently added feature, plugin, theme, API integration, or code change may have introduced a slow operation.
Developers should review:
Recent deployments
Application error logs
Long-running functions
External API calls
Loops processing large datasets
File-processing operations
Background tasks
A request that depends on several external services can also become slow if one service takes too long to respond.
5. Monitor CPU, RAM, and Server Load
Server resources can directly affect website response times.
When CPU usage remains high, applications may take longer to process requests. If available memory becomes too low, processes can slow down or fail.
Check:
CPU utilization
RAM usage
Swap usage
Disk space
Disk activity
Number of running processes
Network activity
If the server regularly reaches its resource limits, infrastructure may need to be reviewed alongside application optimization. For workloads that require flexible resources and strong network capacity, researching high bandwidth cloud VPS can help when comparing different hosting environments.
6. Check DNS, Firewall, and Network Connectivity
Not every 504 error is caused by application code.
If Nginx cannot communicate correctly with its upstream service, the request may fail after waiting for a response.
Check whether:
The upstream server is reachable
DNS resolves correctly
Firewall rules allow the required connections
The backend service is running
Network routes are functioning correctly
The configured upstream address and port are correct
This is especially important when a website uses separate application, database, API, or proxy servers.
Should You Increase Nginx Timeouts?
Sometimes, but only when the workload genuinely requires additional processing time.
A report-generation application, for example, may legitimately take longer than a normal webpage request.
Increasing fastcgi_read_timeout can prevent Nginx from ending a request too early. However, if a simple page consistently takes an unusually long time to load, investigate the underlying cause first.
A useful troubleshooting approach is:
Identify the slow operation → measure its duration → optimize it → adjust the timeout only when necessary.
This approach helps prevent timeout settings from masking deeper application or infrastructure problems.
Common Mistakes to Avoid
Increasing Every Timeout
Changing several timeout values at once can make troubleshooting harder. It may also allow inefficient requests to consume server resources for longer.
Increasing PHP-FPM Workers Without Checking RAM
More workers can handle more concurrent requests, but each worker consumes memory. Increasing the worker limit without considering available RAM can create another performance problem.
Ignoring Database Performance
A slow database query can make the entire application appear slow. Always investigate database operations when a page depends heavily on stored data.
Assuming the Server Is Down
A 504 does not necessarily mean the server is offline. PHP-FPM, the database, an external API, or another backend service may be responsible for the delay.
Making Changes Without Testing
Configuration changes should be tested carefully. Keep track of what you changed so you can determine which adjustment affected the result.
How to Prevent Future 504 Errors
Fixing the immediate error is important, but preventing repeated timeouts is even better.
Useful practices include:
Monitor CPU, RAM, storage, and network usage regularly.
Review application and web server logs.
Identify and optimize slow database queries.
Keep application components updated.
Test major code, plugin, and configuration changes.
Monitor external API response times.
Configure reasonable PHP and proxy limits.
Remove unnecessary processes and requests.
Plan server resources around expected traffic.
Monitor important pages and APIs for slow responses.
Regular monitoring makes it easier to identify performance problems before they turn into visible gateway errors.
Frequently Asked Questions
1. What causes a 504 Gateway Timeout?
A 504 usually occurs when a gateway or proxy waits too long for an upstream server to respond. Slow applications, databases, PHP-FPM processes, external APIs, and server resource problems can all contribute.
2. Can Nginx cause a 504 error?
Nginx can return a 504 when the upstream service does not respond within the configured timeout. The underlying cause may still be PHP, the application, database, or another backend service.
3. How do I check whether PHP-FPM is causing the problem?
Check PHP-FPM logs, active processes, worker limits, and server resource usage. If all available workers remain busy or processes take too long to finish, PHP-FPM may be contributing to the delay.
4. Can a database query cause a 504?
Yes. If an application waits too long for a database query to finish, the upstream request can exceed the gateway's timeout. Optimizing the query and database structure can help reduce the delay.
5. Is increasing the timeout a permanent fix?
Not necessarily. It can help when a legitimate operation needs more processing time, but it does not solve inefficient application code or an overloaded server.
6. How can I tell whether the problem is client-side or server-side?
Try the website from another device or network and check whether other users experience the same issue. If the error consistently affects different visitors, investigate the server-side request path.
Conclusion
To fix 504 Gateway Timeout website problems effectively, focus on the complete request path instead of changing one setting blindly. Check Nginx, PHP-FPM, application code, database queries, network connectivity, and server resources to identify where the delay occurs.
A timeout setting may sometimes need adjustment, but performance optimization should come first whenever an application is taking longer than expected. If you are reviewing hosting infrastructure for a website with changing resource or bandwidth requirements, exploring high bandwidth cloud VPS options can be a useful next step.
Comments