How to Fix Nginx 504 Gateway Timeout Error

In this tutorial, you'll learn about How to Fix Nginx 504 Gateway Timeout Error. We cover key concepts, practical examples, and best practices.

The Problem

Your Nginx reverse proxy returns 504 Gateway Time-out when the upstream backend server takes longer than expected to respond, often because a script, API, or database query runs slowly.

Quick Fix

Increase the proxy_read_timeout

sudo sed -i '/location \/ {/a \    proxy_read_timeout 120s;' /etc/nginx/sites-available/myapp
sudo nginx -t && sudo systemctl reload nginx
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful

proxy_read_timeout (default 60s) limits the time Nginx waits for the backend to send data. Increase it to 120s or higher for long-running requests.

Increase proxy_connect_timeout as Well

sudo sed -i '/location \/ {/a \    proxy_connect_timeout 30s;' /etc/nginx/sites-available/myapp
sudo nginx -t && sudo systemctl reload nginx
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

proxy_connect_timeout (default 60s) controls how long Nginx waits to establish a connection to the upstream. Set both timeouts together for consistency.

Check the Upstream Backend Logs

tail -n 50 /var/log/myapp/error.log
# [2026-06-24 12:00:00] WARNING: Request took 90s to process
journalctl -u myapp-backend --since "5 minutes ago"
# -- Logs begin at ...

A 504 usually means the backend is slow, not Nginx. Check the application logs to see why requests take longer than 60 seconds.

Set Timeouts in the http Block Globally

sudo tee -a /etc/nginx/nginx.conf << 'EOF'
http {
    proxy_read_timeout 120s;
    proxy_connect_timeout 30s;
    proxy_send_timeout 120s;
}
EOF
sudo nginx -t && sudo systemctl reload nginx
# nginx: the configuration file syntax is ok

Set timeouts in the http block to apply them globally to all proxy locations. Individual locations can still override these values.

Log Slow Upstream Responses for Analysis

# Add to http or location block:
log_format upstream_time '\$remote_addr - \$upstream_response_time - \$request_uri';
access_log /var/log/nginx/upstream.log upstream_time;

Log the $upstream_response_time variable to track how long each upstream request takes. This helps identify which endpoints are slow and whether the 504 error is caused by a specific backend endpoint or all endpoints.

Test Configuration Changes First

sudo nginx -t
# nginx: the configuration file syntax is ok
# nginx: configuration file test is successful
sudo systemctl reload nginx

Always run nginx -t before reloading the configuration. This validates syntax, checks file paths, and verifies that SSL certificates are accessible before applying changes.

Additional Troubleshooting

# Check the error message and stack trace for more context
echo "Review the full error output to identify the root cause"

If the above steps do not resolve the issue, examine the complete error message and stack trace. Often the key detail is in the middle of the traceback rather than the final line. Search for the error message in the project documentation or issue tracker for additional solutions.

Prevention

• Set proxy_read_timeout and proxy_connect_timeout explicitly in every proxy configuration
• Monitor backend response times and set Nginx timeouts 10–20 seconds above the p99 latency
• Use proxy_next_upstream with http_504 to retry on a different backend when available
• Log upstream response times with $upstream_response_time in the access log format