What to do when a CDN returns 502, 503, or 504? First identify whether the issue is with the edge node, origin fetch, or origin server.

After a website is onboarded to a CDN, 502, 503, or 504 errors may appear occasionally, and the pages all look similar: the site won't open, fails to load, or shows only a single line of English error text.

But these three status codes do not mean the same thing.

• 502 is more like: the CDN contacted the upstream and received a response it could not use.

• 503 is more like: the current server is temporarily unable to handle the request.

• 504 is more like: the CDN kept waiting for an upstream response, but timed out without receiving one.

According to the HTTP specification, 502 means a gateway or proxy received an invalid upstream response; 503 means the service is temporarily unavailable due to overload or maintenance; 504 means the proxy did not receive a timely response from the upstream server.

When actually troubleshooting, you should not just see “5xx” and check the server in a general way. A more effective approach is to first determine:

Who returned this status code—the CDN node, the origin web server, or the website application?

Start with a table to distinguish 502, 503, and 504

This table can only help determine the troubleshooting direction; it cannot directly determine whether the CDN or the origin is at fault.

The same 502 page may be generated by a CDN edge node or returned by origin Nginx; a 503 may come from CDN rate limiting, an origin maintenance page, or the application actively rejecting service.

Save the full response before troubleshooting

Do not just take a screenshot of the browser error page.

First, usecurlto save the response headers and response body:

curl -sS -D cdn-headers.txt \
  -o cdn-body.html \
  https://www.example.com/problem-path

You can also view it directly in the terminal:

curl -sS -D - -o /dev/null \
  https://www.example.com/problem-path

Be sure to record the following:

HTTP状态码
Date
Server
Via
Age
Retry-After
X-Cache
CF-Cache-Status
X-Request-ID
CDN厂商自定义请求ID

Different CDNs use different response headers, so do not seeServera field and immediately draw conclusions. However, the edge node ID, request ID, cache status, and error page style can usually help determine which layer the response came from.

If the issue does not occur continuously, also record the exact time, access region, carrier, and node IP. Without the time and request ID, it is difficult for the CDN provider to find the corresponding request in massive logs.

502: First check whether the CDN received an “abnormal origin response”

The focus of 502 is not “slowness,” but that the response the CDN receives as a proxy when accessing the upstream does not meet expectations.

MDN explains 502 as: the proxy or gateway received an invalid response from the upstream server; if no upstream response is received at all, it is closer to 504.

Common causes include:

• The origin actively resets the connection

• An origin process crashes or closes the connection early

• The CDN uses HTTPS for origin fetches, but the origin only supports HTTP

• The origin HTTPS certificate, SNI, or TLS version is incompatible

• The CDN origin fetch port is misconfigured

• The origin returns an incomplete or malformed HTTP response header

• Connection failure between Nginx or Apache and the application server

• Backend processes such as PHP-FPM, Node.js, or Java exit

• The origin firewall blocks CDN origin fetch IPs

• The CDN fetches from the wrong origin server

When you see 502, first bypass the CDN to test the origin

Assume:

加速域名：www.example.com
源站IP：203.0.113.10

You can usecurl --resolveto bypass the CDN while preserving the correct Host and HTTPS SNI:

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/problem-path

Then test the result through the CDN:

curl -sS -D - -o /dev/null \
  https://www.example.com/problem-path

If bypassing the CDN returns 200 but going through the CDN returns 502, check the following first:

• Whether the CDN origin protocol is misconfigured

• Whether the origin fetch port is correct

• Whether the origin fetch Host and SNI match

• Whether the firewall allows only some CDN nodes

• Whether the CDN is fetching from a different IP

• Whether the origin restricts the TLS version or cipher suites used by CDN nodes

If bypassing the CDN also returns 502, continue by checking the connections between the origin’s Nginx, Apache, load balancer, and application processes.

For example, Nginx logs may contain:

upstream prematurely closed connection
connection reset by peer
no live upstreams
SSL_do_handshake() failed
connect() failed

These logs are more valuable than a single “502 Bad Gateway” message in the browser.

For 502, do not check only CPU

Many 502 errors are not caused by excessive server load, but by an origin protocol or connection problem.

For example, the CDN is configured as:

HTTPS回源：443端口

but the origin actually listens only on:

HTTP：80端口

In this case, even if the origin CPU usage is only 5%, the CDN may still return 502.

So when you see 502, first check whether the connection is established correctly and the response is complete, then check server performance.

503: First determine who temporarily rejected the request

503 means the service is currently unable to handle the request, commonly due to temporary overload, system maintenance, rate limiting, or no available backend.

The server can also useRetry-Aftera response header to tell the client how long to wait before retrying.

For example:

HTTP/1.1 503 Service Unavailable
Retry-After: 120

This means the service suggests the client retry after 120 seconds.

However, 503 has many possible sources in real environments, and at least the following three cases should be distinguished.

CDN node returns 503

If the error page clearly carries the CDN brand, or the response header contains an edge node request ID, the 503 may come from the CDN itself.

Common causes include:

• Temporary overload of a CDN edge node

• Failure of nodes in a region

• A CDN security policy or rate-limiting rule is triggered

• The CDN cannot find a healthy origin

• Edge function execution fails

• The account plan, request volume, or resource quota is limited

In this case, observe whether the issue occurs only in certain regions or on certain carriers.

You can use CDNChart'swebsite speed test toolto test the same URL from different regions and networks. If 503 occurs only in a few regions while other regions are normal, the issue is more likely concentrated in regional nodes, scheduling, or configuration synchronization.

Origin web server returns 503

Nginx, Apache, IIS, or the origin load balancer may also return 503.

Common cases include:

• No healthy backend servers

• The PHP-FPM process pool is full

• All application services are offline

• The server is under maintenance

• The number of concurrent connections has reached the limit

• The reverse proxy is actively rate limiting

• The container or service instance is not ready yet

If there are multiple origins behind the load balancer, test each origin separately:

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/problem-path

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.20 \
  https://www.example.com/problem-path

If one origin returns 200 and another returns 503, it is usually a problem with backend instance status or health checks; do not keep blindly purging the CDN cache.

Website application actively returns 503

WordPress, Java, Node.js, PHP, and various web frameworks may also actively return 503.

For example:

• The website enters maintenance mode

• The database connection pool is full

• The application queue is backlogged

• An external dependency is unavailable

• An API hits a rate limit

• The application detects that the service is not ready

• Instances are temporarily offline during deployment

At this point, the web server may be running normally, but exceptions will appear in the application logs.

For 503, especially check all of the following:

CPU和内存
磁盘空间与磁盘IO
进程数量
数据库连接数
应用线程池
容器健康状态
请求限流规则
依赖服务状态

Do not only check whether the server is “online.” Being able to ping the server or log in via SSH does not mean the application can still handle HTTP requests.

504: First find out where the request is stuck, rather than immediately increasing the timeout

504 indicates that the CDN or another proxy has sent a request upstream but did not receive a response within the specified time.

The most obvious difference from 502 is:

• 502: The upstream returned an abnormal response, or the connection terminated abnormally.

• 504: The proxy waited a long time but still did not receive a timely response.

MDN also describes 504 as the proxy or gateway failing to receive a timely response from the upstream server.

Common causes include:

• The origin processes requests too slowly

• A database query takes too long

• An API call to a third-party service times out

• Dynamic page generation takes too long

• File upload or download exceeds CDN limits

• The origin has reached its connection limit

• The firewall drops connections instead of explicitly rejecting them

• Abnormal network quality between the CDN and the origin

• The origin timeout is set too short

• The application has a deadlock or blocked tasks

Use curl to determine whether the delay is in the connection or the response

The following command breaks down the main time spent on a request:

curl -sS -o /dev/null \
  -w 'DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nStatus: %{http_code}\n' \
  https://www.example.com/problem-path

The output may look like:

DNS: 0.012s
Connect: 0.048s
TLS: 0.103s
TTFB: 30.001s
Total: 30.001s
Status: 504

DNS, TCP, and TLS are all fast, but the time to first byte is 30 seconds, indicating the problem is likely in post-origin processing, such as the application, database, or external APIs.

time_starttransferThis includes connection setup time and the time the server takes to generate the response; for definitions, seethe official curl manual.

You should also bypass the CDN to test the origin:

curl -sS -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  -w 'TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nStatus: %{http_code}\n' \
  https://www.example.com/problem-path

If the origin itself takes 35 seconds to respond and the CDN origin timeout is 30 seconds, a 504 is not surprising.

Don't start by changing the timeout from 30 seconds to 300 seconds

Increasing the origin timeout can sometimes let the request complete, but it may also mask the real problem.

If an ordinary page takes tens of seconds to generate, check the following first:

• Whether there are slow SQL queries

• Whether the database is locked

• Whether application threads are blocked

• Whether external APIs respond slowly

• Whether the page runs many synchronous tasks

• Whether time-consuming operations such as exports or transcoding are placed in synchronous requests

• Whether application caching is missing

• Whether the connection pool is exhausted

For long-running tasks such as report generation, video processing, and large file exports, asynchronous processing is usually more appropriate: return a task ID first, then let the user download the result when processing is complete, instead of keeping the CDN connection waiting.

How to determine whether the error is at the CDN or the origin

Compare the results with the CDN and bypassing the CDN side by side:

If you are still not sure which CDN a domain is currently using, you can start with CDNChart'sCDN detection toolto check the CNAME, node IP, and CDN detection results.

When only some URLs report errors, don't check the entire server first

If the homepage is normal and only a certain API returns 504, the underlying network and CDN integration are probably still normal.

In this case, focus on the business logic behind that URL:

/api/search
/api/export
/api/payment/callback
/report/download

These requests may be the only ones that run slow queries, call third-party APIs, or generate large files.

Likewise, if static assets are normal but dynamic pages return 503, you cannot simply conclude that a CDN node is faulty. Static assets may hit the edge cache directly without ever reaching the origin, while dynamic pages must go back to the origin every time.

When troubleshooting, select each of the following:

• A static file that reliably hits the cache

• An ordinary dynamic page

• A specific API that is failing

Only after testing them separately can you see whether the problem is in the cache layer, origin fetch path, or application layer.

For intermittent failures, test repeatedly instead of refreshing only once

502, 503, and 504 often do not occur continuously, but instead “fail twice out of ten attempts.”

You can send repeated requests and output the status code, node IP, and elapsed time:

for i in $(seq 1 10); do
  curl -sS -o /dev/null \
    -w "$(date '+%F %T') status=%{http_code} remote=%{remote_ip} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
    https://www.example.com/problem-path
  sleep 2
done

If every failure is concentrated on the same origin or the same node IP, the problem is no longer a “random failure.”

In multi-origin environments, also check:

• Whether all origins run the same deployment version

• Whether health checks truly cover business APIs

• Whether the abnormal origin is still in the load-balancing pool

• Whether database and cache configurations are consistent

• Whether a server has exhausted its connections

• Whether the CDN is still fetching from an IP that has been taken offline

Logs should be aligned on the same timeline

An effective failure record should include at least:

发生时间：精确到秒，并注明时区
访问域名和完整URL
请求方法
HTTP状态码
用户所在地区和运营商
CDN节点IP
源站IP
CDN请求ID
源站访问日志
源站错误日志
应用日志
请求总耗时

Then compare them at the same points in time:

1. The CDN has a record, but the origin has none: the problem may have occurred during the CDN-to-origin connection stage.

2. The origin received the request but did not complete the response: check for application blocking, timeouts, and process exceptions.

3. The origin explicitly returned 503: check capacity, maintenance mode, or application rate limiting.

4. The origin returned 200, but the user received 502: check intermediate proxies, response format, and connection interruptions.

5. The CDN waits for a fixed period and then returns 504: check the origin timeout threshold and origin processing time.

Do not infer the failure layer from a user's screenshot. As long as you can put the CDN request ID, origin access logs, and application logs on the same timeline, diagnosis is usually much faster.

Frequently asked questions

If a CDN returns 502 and it recovers after a refresh, does it still need to be addressed?

Yes. An intermittent 502 may come from an abnormal origin, an application process restart, a reset connection, or a failed TLS handshake. Recovery after a refresh only means the next request succeeded; it does not mean the root cause is gone.

Does 503 always mean the server is overloaded?

Not necessarily. 503 may also come from maintenance mode, CDN rate limiting, WAF rules, no healthy origin, an application that is not ready, or plan quota limits. First determine who returned the 503, then check resource utilization.

Can 504 be solved simply by increasing the CDN timeout?

Not necessarily. Increasing the timeout only makes the CDN wait longer. If the root cause is slow SQL, a blocked API, or an external service failure, users still have to wait a long time, and more connections are consumed.

Why are static files normal while website pages return 504?

Static files may already be cached on CDN nodes and do not need to go back to the origin, while dynamic pages need to access the origin, application, and database. Normal static assets do not prove that the origin’s dynamic services are normal.

Why do only overseas users see 502 or 504?

It may be related to the network path from overseas nodes to the origin, firewall policies, cross-border links, or regional origin fetch configuration. Record results by country, region, and node IP; do not test only in the origin’s region.

Are 502, 503, and 504 cached by CDNs?

It depends on the CDN provider and caching rules. Some configurations briefly cache error responses, and some CDNs continue serving stale cache when the origin fails. When troubleshooting, checkAge, the cache status, and error status code caching rules; do not assume every 5xx comes from the origin in real time.