How to Troubleshoot the 504 Gateway Timeout Error on Your KVM VPS

A 504 Gateway Timeout means one part of your server stack waited too long for the part behind it and gave up: nginx waiting for PHP-FPM or Apache, a proxy waiting for your Node.js or Python app, or Cloudflare waiting for your server. This guide is for a VPS or server you manage yourself, and shows how to find which layer timed out, why the request was slow, and how to set the timeouts sensibly. If your site is on Domain India shared hosting, use the shared-hosting guide linked below instead.

1. Where a 504 comes from

A web request on a typical VPS passes through several layers:

1. A CDN or proxy such as Cloudflare, if you use one.
2. The front web server, usually nginx (or Apache).
3. The application: PHP-FPM, or an app server running Node.js, Python or another language.
4. What the app waits on: the database, the disk, or an outside API.

Each layer has its own timeout. The 504 is sent by the layer that gave up, but the cause is almost always further back, in whatever was slow.

2. Find which layer sent it

• Cloudflare error page, or code 524. Cloudflare waited about 100 seconds for your server and gave up. Your server may still be working on the request.
• A plain "504 Gateway Time-out" page with nginx at the bottom. nginx timed out waiting for PHP-FPM or your app.
• Test around the CDN. From your own computer, send the request straight to the VPS to see whether the origin itself is slow:

curl -s -o /dev/null -w "%{http_code} in %{time_total}s\n" \
  --resolve yourdomain.com:443:YOUR_VPS_IP https://yourdomain.com/slow-page

If the page takes 60 seconds or more directly, the problem is on the VPS. If it is fast directly but slow through the CDN, look at the CDN settings and the network path.

3. Read the error logs at the time of the 504

Note the exact time of the error first; every log check depends on it.

What to look for:

• upstream timed out (110: Connection timed out) while reading response header from upstream in the nginx log: the app behind nginx was too slow. The line names the URL.
• server reached pm.max_children setting in the PHP-FPM log: every PHP worker was busy, so new requests queued until nginx gave up.
• executing too slow entries, if you enable the PHP-FPM slow log (request_slowlog_timeout = 10s and a slowlog path in the pool file): these show the exact PHP function each slow request was stuck in.

If you run a panel on the VPS, such as DirectAdmin, Webuzo or CyberPanel, the log locations differ; use the panel's log viewer.

4. Check the server's health

uptime                          # load average vs number of CPUs (nproc)
free -h                         # memory and swap
df -h && df -i                  # disk space and inodes
vmstat 1 5                      # "wa" column = time waiting for disk
journalctl -k | grep -i -E "out of memory|oom"   # processes killed for memory
top                             # press P for CPU, M for memory

A load average far above the CPU count, heavy swap use, a full disk or recent out-of-memory kills all explain slow responses. Fix the cause, or move to a plan with more resources.

5. Check and restart the services

systemctl status nginx
systemctl status php8.3-fpm     # Ubuntu/Debian; "php-fpm" on AlmaLinux/Rocky
systemctl status apache2        # "httpd" on AlmaLinux/Rocky
systemctl status mysql          # or mariadb

If a service has failed or is stuck, restart just that service, for example sudo systemctl restart php8.3-fpm. Before reloading nginx or Apache after a config change, test the config with sudo nginx -t or sudo apachectl configtest, so a typo does not take the site down.

6. Fix the slow request

Raising timeouts only hides slow work. Look for these first:

• PHP-FPM worker pool too small or too big. If the log shows pm.max_children reached, raise it, but only as far as memory allows: divide the RAM you can spare by the average size of a PHP-FPM process (see ps -o rss -C php-fpm8.3, or php-fpm on AlmaLinux/Rocky). Too many workers leads to swapping, which makes everything slower.
• Slow database queries. Turn on the MySQL or MariaDB slow query log, find the worst queries on the failing page, and add indexes or fix the code. See optimizing MySQL and MariaDB.
• Outside APIs without a timeout. A payment, shipping or licence API that hangs can hold a request for minutes. Give every outbound call a timeout of a few seconds and handle the failure.
• Long jobs in a web request. Imports, exports, reports, backups and bulk emails belong in a background queue or a cron job, not in a browser request.
• Bots and attacks. Check the access log for floods on login pages or search URLs, and rate-limit or block them.

7. Align the timeouts

Once the slow work is under control, make the timeouts consistent. Each layer should wait slightly longer than the one behind it, so the error comes from the layer that knows why.

A Cloudflare-proxied request is limited to about 100 seconds on most plans regardless of these values, so any page that needs longer must become a background job. Reload each service after changing its setting.

8. When the server looks healthy

If the logs are clean, resources are fine and the direct curl test is fast, the delay is probably outside the VPS: the CDN, DNS or the network path. Test with mtr yourdomain.com from your own computer. If the VPS itself is unreachable or you suspect a problem on our side, open a support ticket with the times of the errors, your test results and the VPS IP address.

9. Your VPS at Domain India

Domain India VPS plans are KVM virtual servers with full root access, and they are self-managed: you look after the operating system, the web stack and its settings. Support handles the platform side. Reboot from inside over SSH; for start, stop, a forced restart, a reinstall or a resize, open a ticket and support will do it.

If you would rather not manage a server at all, shared hosting or the App Platform may suit your site better; see VPS vs shared hosting.

Frequently asked questions

Ready to dig in? Start with the logs and the checks above, compare VPS plans if you need more resources, or set up monitoring with Prometheus, Grafana and Loki so you see the next slowdown before your visitors do.