504 Gateway Timeout: Causes and Fixes for Visitors and Website Owners

A 504 Gateway Timeout means a server acting as a gateway or proxy did not receive a timely response from another server it needed to complete your request. Visitors can retry and check whether the problem affects their connection. Website owners need to identify which server or application stopped responding in time.

The HTTP specification defines 504 as an upstream response timeout. It tells you what failed, but does not identify the underlying cause.

What does a 504 Gateway Timeout mean?

A gateway is a server that handles requests on behalf of another server. It might be a reverse proxy, a load balancer that distributes traffic, or a content delivery network (CDN).

The server it contacts is called the upstream server. The website’s main hosting server is often called its origin server.

If that upstream response takes too long, the gateway can return a 504. Your browser may show “Gateway Timeout,” “HTTP Error 504,” or “504 Gateway Time-out.”

These related errors describe different failures:

Common causes of a 504 error

A timeout may result from:

• Heavy server load: Requests wait while processing capacity is occupied.
• Slow application work: Database queries, reports, or other operations take too long.
• An unavailable upstream server: A server or service cannot respond.
• Blocked connections: Firewall rules or network problems prevent communication.
• An unsuitable timeout setting: The gateway stops waiting before a legitimate operation can finish.

AWS’s gateway timeout guidance recommends checking origin accessibility and application responsiveness before increasing timeout limits.

How visitors can troubleshoot a 504 Gateway Timeout

1. Wait briefly, then retry the page

For an ordinary page view, wait a short while and refresh once. Check the website’s status page or support updates if the problem continues.

If the error appeared after a payment, booking, or form submission, check for confirmation before submitting again. A timeout does not prove that the underlying action failed, so repeated attempts could create duplicates.

2. Compare another browser or connection

Try a private browsing window or another browser. If practical, compare Wi-Fi with mobile data.

If the site works elsewhere, investigate your connection, optional VPN, or proxy configuration. On a managed work network, ask your IT team before changing settings.

MDN’s 504 troubleshooting guidance notes that unusual client networking configurations can sometimes be involved, although these errors usually require server administration.

3. Send the website owner useful details

Report the affected page, what you were doing, the time and time zone, and any request ID displayed on the error page. A screenshot can help.

Remove personal information and secret tokens from screenshots or URLs. You do not need to send passwords or payment details.

How website owners can fix a 504 Gateway Timeout

1. Identify the failing request and its scope

Start with a specific incident. Record the URL, action, timestamp, and request ID if available.

Then establish whether the problem affects:

• Every page or one particular action.
• All visitors or certain networks or locations.
• Normal browsing or a task such as checkout, search, or an export.
• A recent change or a particular traffic period.

A homepage that loads successfully does not demonstrate that checkout is working. Reproduce the reported action when it is safe to do so.

2. Find which server generated the timeout

Compare CDN, load balancer, web server, and application logs around the same timestamp. Ask your host to identify the upstream service and whether the timeout happened while connecting or waiting for a response.

A CDN can pass along an origin server’s error. Its logo alone does not establish responsibility. Cloudflare’s 502/504 documentation distinguishes origin failures from errors within its own network.

If the gateway cannot reach the upstream server, have your administrator check the configured destination, routing, and relevant firewall rules. Make targeted corrections rather than disabling the firewall.

3. Check capacity and slow application work

Compare response times and resource usage during normal operation and the affected period. Look for sustained CPU or memory pressure and slow database queries. Add resources when measurements support that decision; optimize expensive operations where possible.

For WordPress sites using PHP-FPM, also investigate worker availability. PHP workers process application requests, and PHP-FPM’s pm.max_children setting limits how many requests can be served simultaneously.

Ask your host whether workers were occupied and whether PHP slow logs identify the code involved. Increasing the PHP memory limit alone does not establish that the actual bottleneck has been fixed.

4. Investigate WordPress changes carefully

If errors began after a plugin, theme, or configuration change, start there. Take a backup and reproduce the issue on a staging copy before testing changes.

WordPress’s plugin and theme troubleshooting guidance recommends a controlled process for isolating conflicts.

Test likely causes one at a time. Check whether the failing action waits on a payment, shipping, or other external service. For imports and reports, consider a supported background-processing option so visitors do not have to keep a request open while the entire job runs.

5. Review the correct timeout setting

Once the underlying service is healthy, check whether a legitimate operation needs more time. Identify every relevant gateway’s limit before changing application settings.

In NGINX, the setting depends on how the upstream connection works:

• proxy_read_timeout applies when NGINX proxies a request to another HTTP server.
• fastcgi_read_timeout applies to FastCGI responses, such as those from PHP-FPM.

Both measure the allowed gap between successive reads, rather than a single maximum duration for the whole response. A connection timeout is a separate setting.

There is no universal timeout value that fixes every website. Increasing PHP’s execution limit also does not override an independent CDN or proxy limit. Have your host align the settings with the application’s needs and available resources.

6. Verify the original action after the fix

Repeat the affected workflow, using test transactions where appropriate. Confirm both that the request succeeds and that the expected result exists.

Monitor error rates and response times through the conditions that previously triggered the problem. Keep a record of the change and its effect so recurring incidents are easier to investigate.

Can 504 errors affect SEO?

Persistent 504 errors can disrupt crawling and indexing. Google’s HTTP status code documentation explains that server errors can reduce crawling. Already indexed URLs may remain initially, but persistent failures can eventually cause them to be removed.

An isolated timeout does not automatically mean lost rankings. Focus on restoring reliable responses and checking Search Console for continuing server errors.

Frequently asked questions

Is a 504 Gateway Timeout my fault?

Usually, the website’s server infrastructure needs attention. If the website works through another connection, your network, VPN, or proxy may be involved.

How long does a 504 error last?

There is no fixed recovery time. A temporary interruption may clear quickly, while a recurring application or configuration problem can continue until someone fixes it. The 504 code itself does not provide an estimated recovery time.

Does clearing the browser cache fix a 504?

Clearing cache cannot repair an upstream server that is failing to respond. Comparing another browser can help isolate local behaviour, but repeated cache clearing is not a substitute for investigating a recurring server timeout.

If repeated errors are disrupting your business website, explore HMDIA’s website services and contact HMDIA to discuss your site’s needs.