504 Gateway Timeout Behind Cloudflare

DIRECT ANSWER

A Cloudflare-branded 504 Gateway Timeout usually means Cloudflare’s edge did not receive a timely response from your origin. Common causes include slow database or application work, an unreachable origin, incorrect DNS or firewall settings, and SSL/TLS configuration problems. Test the origin separately, then optimize or background long-running work and review the Cloudflare timeout that applies to the request and plan.

Key takeaways

Cloudflare branding and a Ray ID indicate that Cloudflare generated the displayed error rather than your application’s normal error handler.
Reports, exports, uploads, and bulk actions are common examples of requests that may exceed the applicable timeout.
A direct-origin test helps distinguish a slow or unhealthy backend from a Cloudflare-to-origin connectivity problem.
Increasing an Nginx, Apache, or application timeout cannot make Cloudflare wait beyond the edge limit that applies to the request.
Persistent 504 errors across ordinary requests require checks of DNS, firewall access, origin health, proxy status, and SSL/TLS settings.

Updated 2026-09-24 · Editorial review pending HTTP & Server Errors

Site Administrator

What this error means & how to recognize it

The error page has Cloudflare branding and commonly includes a Cloudflare Ray ID instead of your site’s normal error layout.
A specific report, export, upload, API call, or bulk action fails while ordinary pages continue to load.
The same request may respond slowly, time out, or fail when tested directly against the origin.
The problem may be intermittent when the origin is overloaded or consistent when Cloudflare cannot reach the configured origin.
Application or web-server logs may show that the request started but did not complete before the client-facing timeout.

Root causes, ordered by likelihood

The origin is taking too long. A database query, report, export, upload, or other synchronous operation may exceed the time Cloudflare will wait.
The request reaches a Cloudflare timeout limit. The applicable limit depends on the request, account configuration, and plan. Increasing the origin web-server timeout does not extend Cloudflare’s edge limit.
Cloudflare cannot reliably reach the origin. Firewall rules, network failures, an incorrect DNS target, an unavailable service, or connection saturation can prevent a timely response.
The endpoint is not suitable for proxying. An internal or specialized API may require a carefully controlled DNS-only design rather than passing through Cloudflare’s proxy.
SSL/TLS settings do not match the origin. Review the origin certificate, hostname, and certificate validity when using Full (strict). Certificate problems can produce other Cloudflare origin errors, so confirm the exact response instead of assuming every SSL issue is a 504.

How to fix it

Diagnostic flow at a glance — full detail in the steps below.

1. Confirm that Cloudflare produced the response

Inspect the error page for Cloudflare branding and a Ray ID, then compare it with your application’s normal error page. If Cloudflare generated the page, changing only application error handling will not resolve the edge-to-origin problem.

2. Define the scope and timing

Record the exact hostname and path, HTTP method, user action, approximate start time, and whether the issue affects all visitors or one operation. Check whether ordinary pages work while a report, export, or API request fails.

A failure limited to one expensive operation points more strongly to backend duration. Failures across ordinary and fast requests point more strongly to origin reachability, capacity, or configuration.

3. Test the origin independently

Use an authorized direct-origin test that preserves the required hostname, Host header, TLS behavior, authentication, and routing. A temporary DNS-only test hostname can be useful if it is configured safely and origin access remains appropriately restricted.

Origin is also slow or fails: inspect application logs, database queries, worker capacity, upstream dependencies, server load, and connection saturation.
Origin is fast but the public hostname returns 504: investigate Cloudflare-to-origin firewall access, DNS, SSL/TLS settings, proxy status, and the affected endpoint.
The direct test is not representative: repeat it with the same authentication, host-based routing, headers, and other requirements used by the failing request.

4. Fix a genuinely slow operation

For a report, export, bulk action, or other long-running task, avoid holding one browser request open until all work finishes. Move the operation to a background job, display a processing state, and let the user retrieve the result through polling or a completion notification.

Also measure database queries, application traces, upstream calls, queue depth, and resource usage. Do not treat an origin timeout increase as the primary fix without measuring the operation: if Cloudflare reaches its limit first, the visitor still receives an error while the origin may continue doing unnecessary work.

5. Review the applicable Cloudflare timeout

Check the Cloudflare account and relevant documentation for the timeout that applies to the affected request and plan. If the work is valid but cannot complete within a fixed limit, the practical options are to redesign it as asynchronous work or use an account configuration and plan that support the required timeout, where available.

6. Check reachability when failures are persistent

If ordinary and fast requests also fail, verify:

The DNS record points to the current origin address.
The origin firewall permits Cloudflare traffic as required, without exposing unnecessary services.
The web server is listening on the expected port and accepts the requested hostname.
The origin has sufficient capacity and is not dropping or queuing connections.
The SSL/TLS mode matches the origin certificate, hostname, and certificate validity, especially with Full (strict).
The affected record is intended to be proxied rather than served through a controlled DNS-only configuration.

Make DNS, firewall, SSL/TLS, or proxy changes only with appropriate authorization and a rollback plan. Re-test the exact failing endpoint after each material change so the cause and effect remain clear.

7. Escalate with useful evidence

If the origin is healthy and responds quickly through an equivalent direct test, collect the Ray ID, timestamp and time zone, hostname, path, request method, affected Cloudflare zone, and direct-test results. Give this information to the Cloudflare account administrator or support contact so edge-to-origin behavior can be investigated.

Prevention & how to verify the fix

Measure origin response time and total request duration separately from Cloudflare-facing availability.
Put predictable long-running reports, exports, uploads, and bulk operations behind background jobs with visible progress or completion status.
Alert on rising origin latency, connection failures, resource saturation, and queue depth before users encounter timeouts.
Keep DNS records, origin firewall rules, and Cloudflare traffic allowlists under change control.
Monitor origin certificate validity and hostname coverage when using Full (strict), and review SSL/TLS changes before deployment.
Document which endpoints are intended to use Cloudflare’s proxy and which require a controlled DNS-only design.
Retest representative origin connectivity after infrastructure, DNS, firewall, certificate, or proxy changes.

When to get outside help

Escalate when the 504 affects the whole site, persists after the origin has been checked, or follows a DNS, firewall, certificate, or proxy change. An authorized administrator should review the Cloudflare zone, origin access rules, and recent infrastructure changes. If the origin responds quickly through an equivalent direct test but Cloudflare still returns the error, provide the Ray ID, exact timestamp and time zone, hostname, path, request method, and direct-test results to the Cloudflare account administrator or support contact.

Run a website check

Frequently asked questions

What does a Cloudflare-branded 504 Gateway Timeout mean?

It generally means Cloudflare’s edge did not receive a timely response from the configured origin. The cause may be a slow application request or a problem reaching the origin; the branding and Ray ID indicate that Cloudflare produced the displayed error.

Will increasing the Nginx or Apache timeout fix a Cloudflare 504?

Not if Cloudflare’s edge reaches its own timeout first. Origin timeout settings matter when the origin is terminating the request, but they cannot make Cloudflare wait beyond the limit that applies to the request and plan.

Why do only exports or reports return a 504?

These operations often perform more work than ordinary page requests. Measure their duration and dependencies, then move the work to a background job with polling, a completion notification, or another retrieval mechanism instead of keeping one request open.

How can I test whether the origin is the problem?

Use an authorized direct-origin test that preserves the correct hostname, Host header, TLS behavior, authentication, and routing. If the request is slow or fails directly, investigate the backend. If it is fast directly but fails through Cloudflare, investigate reachability and Cloudflare configuration.

Can changing the Cloudflare plan remove this 504?

A plan or account configuration may provide different timeout options, but changing plans is not a substitute for fixing an overloaded or unreachable origin. First measure the request and determine whether the timeout limit or the backend is the actual constraint.

What information should I provide when escalating a Cloudflare 504?

Provide the Ray ID, exact time and time zone, hostname, path, request method, scope of the failure, relevant zone or plan context, and the results of an equivalent direct-origin test.

Further documentation

For authoritative reference, consult Cloudflare documentation covering gateway and origin 5xx errors, plan-specific origin response time limits, Cloudflare IP ranges, DNS proxy status, SSL/TLS modes, and Ray ID-based investigations. Also consult the documentation for the origin web server, application framework, database, and job queue used by the affected endpoint when reviewing request duration, capacity, and background processing.