Origin Server Accessible but CDN Returns 404? How to Troubleshoot Origin Host and Cache

The origin address works fine when accessed directly, but the domain returns a 404 after being added to the CDN.

When this happens, many people's first reaction is: 'The CDN failed to fetch from the origin.'

However, a 404 is different from a 502 or 504. A 502 or 504 usually means the CDN did not receive a valid response from the origin, whereas a 404 often means a layer did receive the request but believes the resource you requested does not exist.

The issue may originate at a CDN edge node or at the origin. More often, the CDN does fetch from the origin, but the domain, path, protocol, or port used for the origin fetch differs from those used when accessing the origin directly.

So the first troubleshooting step is not to purge the cache or repeatedly change DNS settings, but to confirm:

Who is actually returning this 404?

First, determine whether the 404 comes from the CDN or the origin

A complete request typically passes through the following layers:

Browser → CDN edge node → CDN origin fetch configuration → web server → website application or object storage

Any of these layers can return a 404.

You can start by checking the response headers:

curl -I https://www.example.com/test.jpg

To see the redirect process and more complete information, use:

curl -sS -L -D - -o /dev/null \
  https://www.example.com/test.jpg

Pay particular attention to these response headers:

HTTP/2 404
server:
via:
age:
x-cache:
cf-cache-status:
x-request-id:
x-served-by:

Different CDNs use different response headers, so you cannot draw conclusions from a single field alone. However, if the response contains an obvious cache status, edge node ID, or CDN request ID, you can at least confirm that the request passed through the CDN.

You can also use CdnChart'sCDN detection tool, to first confirm which CDN the domain currently resolves to and which CNAMEs and node IPs it uses, so you can avoid actually hitting old nodes or another acceleration service.

The most common issue: the CDN uses the wrong Host when fetching from the origin

An origin server often hosts multiple websites at the same time, for example:

www.example.com
api.example.com
static.example.com

Nginx, Apache, and other web servers usually rely on theHostHost header in the HTTP request to determine which site should handle the request.

Suppose the website actually configured on the origin is:

www.example.com

But the CDN sends the following when fetching from the origin:

Host: origin.example.com

Or it sends the origin IP directly as the Host. The web server may then route the request to the default site. Because the default site cannot find the corresponding file, it naturally returns a 404.

This is also one of the most common reasons why 'the origin works, but the CDN returns a 404.'

Check the following configurations in the CDN console:

• What is entered as the origin fetch Host?

• Is the origin fetch Host the accelerated domain, the origin domain, or the origin IP?

• Does the origin web server have a corresponding virtual host configured?

• Is the SNI domain used for HTTPS origin fetches correct?

• Do multiple business domains share the same origin fetch configuration?

If the website actually relies on thewww.example.comHost header to identify the virtual host, the origin fetch Host should usually also be set to that domain rather than an arbitrary origin address.

Do not compare by accessing the HTTPS origin IP directly

Many people directly open:

https://203.0.113.10/test.jpg

and, finding that it is accessible, conclude that the origin has no problems.

This kind of test is not reliable.

An HTTPS connection involves not only the HTTP Host but also SNI during the TLS handshake. When you access the IP directly, the origin may return a default certificate or default virtual host, which differs from the request the CDN actually sends when fetching from the origin.

A more accurate approach is to usecurl --resolve, which connects the request to a specified origin IP while preserving the original domain, Host, and TLS SNI:

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

Here, replace the following:

www.example.com    你的加速域名
203.0.113.10       你的源站IP
/test.jpg          出现404的实际路径

Then test the result through the CDN:

curl -sS -D - -o /dev/null \
  https://www.example.com/test.jpg

Compare the two results side by side.

If specifying the origin IP returns 200 but going through the CDN returns 404, the problem is most likely in CDN caching, the origin fetch Host, URL rewriting, or origin selection configuration.

If both return 404, the problem usually lies in the origin's site configuration, application routing, or file paths.

For origins that only serve HTTP, you can also test as follows:

curl -sS -D - -o /dev/null \
  -H "Host: www.example.com" \
  http://203.0.113.10/test.jpg

A modified origin fetch path can also cause a 404

The path accessed by the browser is not necessarily the path the origin ultimately receives.

For example, a user requests:

https://www.example.com/images/logo.png

Because of rule configurations, the CDN may fetch from the origin using:

http://203.0.113.10/static/images/logo.png

or it may incorrectly become:

http://203.0.113.10/images/images/logo.png

Common causes include:

• An origin fetch path prefix is configured

• CDN edge rules rewrite the URL

• The origin Nginx applies another rewriterewrite

• Object storage paths do not match the website URLs

• Inconsistent handling of trailing slashes

• URL case mismatches

• Special characters are double-encoded

• Incorrect rules for ignoring or preserving query parameters on the CDN

Linux file paths are usually case-sensitive:

/Images/Logo.png
/images/logo.png

In some local development environments, both addresses may open, but after deployment to a Linux origin or object storage, they are two different paths.

Therefore, do not test only the homepage when troubleshooting. Copy the full URL that returns the 404, including the path, filename, extension, and query parameters, and test it separately through the CDN and against the origin.

The CDN may have cached a previous 404

CDNs do not necessarily cache only 200 responses.

If a CDN node requested the resource from the origin before it was uploaded, and the origin returned a 404 at that time, and the CDN is configured to cache error status codes, that 404 may remain on the node.

Later, even after the file has been uploaded to the origin, users may still receive the previously cached 404.

You can look for clues in the response headersAge, cache status, or vendor-specific fields:

curl -I https://www.example.com/test.jpg

For example:

HTTP/2 404
Age: 1860
X-Cache: HIT

This kind of result usually indicates that the 404 was not just fetched from the origin but hit a cached copy on the node.

Actions to take include:

1. Purge this specific URL in the CDN console.

2. Check the cache TTL for 404 status codes.

3. Confirm whether the cache key includes query parameters.

4. Check whether different directories have different cache rules applied.

5. After purging, retest from multiple regions.

The HTTP specification allows certain status codes to be cached under specific conditions, so you should not assume that a 404 will never be cached. For the semantics of the 404 status, seeHTTP 404 specification.

Do not purge the entire domain every time a 404 appears. Purge a specific URL first to confirm that the issue is actually cache-related, avoiding unnecessary large-scale origin fetches.

Why do only some regions return 404?

If Beijing works but Guangzhou returns 404, or China Telecom works but China Mobile returns 404, this is usually not a simple case of a missing file on the origin.

More likely areas to check include:

• Some CDN nodes still hold cached old 404 responses

• Different regions are routed to different CDN providers

• Different origins are used for mainland China and overseas

• Different lines are configured with different origin fetch Hosts

• Configuration for a certain region has not finished syncing

• Files or versions differ across multiple origins

• A canary release updated only some servers

• DNS is still returning old nodes that have been taken offline

At this point, testing only from your own computer has limited value. You can use CdnChart'swebsite speed test toolto observe status codes, resolution results, and access performance from different regions and carriers.

When testing, it is best to use the same fixed URL and record:

• Test time

• Test region

• Network carrier

• Resolved node IP

• HTTP status code

• Response headers

• Response content

• CDN request ID

If the 404s are concentrated on the same node IP or in the same region, the scope for troubleshooting narrows considerably.

Multi-origin configurations can also easily create 'random 404s'

Many websites configure multiple origins:

源站A：203.0.113.10
源站B：203.0.113.20

If a file is synced only to origin A, users may see:

第一次：200
第二次：404
第三次：200

It looks like CDN instability, but in fact the content on the two origins is inconsistent.

You can test by specifying each origin IP separately:

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

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

If one returns 200 and the other returns 404, there is no need to keep going in circles around CDN nodes. Check file synchronization, release versions, shared storage, or origin health check policies.

For dynamic websites, also check application routing

For dynamic websites such as WordPress, Laravel, Next.js, and Java Spring, a 404 may not be returned directly by Nginx; it may come from the application.

For example:

• The CDN drops query parameters during origin fetches

• The origin fetch Host is not in the application's allowed domain list

• The application loads different tenants based on the domain

• Pseudo-static or route rewriting is not working

• The CDN incorrectly converts POST requests to GET

• Paths with language, region, or version prefixes are rewritten

• Route caches are not updated after an application release

You can compare the 404 page content returned by the CDN and the origin:

curl -sS https://www.example.com/test-path \
  -o cdn-404.html

curl -sS \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/test-path \
  -o origin-404.html

Then compare the two files:

diff cdn-404.html origin-404.html

If the page content, response headers, and request ID all match, the 404 most likely comes from the origin application. If they are completely different, it is more likely the result of CDN edge rules or a different virtual host.

A more time-efficient troubleshooting sequence

When troubleshooting, you can proceed in the following order.

First, request the full URL through the CDN:

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

Then bypass the CDN and request the real origin:

curl -sS -D origin-headers.txt \
  -o origin-body.html \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/problem-path

Compare the status code, response headers, and page content:

diff cdn-headers.txt origin-headers.txt
diff cdn-body.html origin-body.html

If the origin returns 200 and the CDN returns 404, continue checking:

• Whether the CDN hit an old cached 404

• Whether the origin fetch Host and SNI are correct

• Whether the CDN modified the URL

• Whether the CDN selected another origin

• Whether an edge function or rule returned the 404 directly

If both the origin and CDN return 404, continue checking:

• Origin virtual hosts

• Nginx or Apache logs

• Actual file paths

• Application routing

• Release version

• Filenames and permissions in object storage

curlDetailed descriptions of the parameters can be found in theofficial curl manual.

After changing the configuration, do not test only once

After changing the origin fetch Host or purging the cache, the site opening on your own computer does not mean the problem is fully resolved.

At a minimum, also confirm:

• Whether all regions have recovered

• Whether China Telecom, China Unicom, and China Mobile give consistent results

• Whether IPv4 and IPv6 results are consistent

• Whether both the homepage and the specific failing resource work

• Whether URLs with and without parameters behave consistently

• Whether all origins return 200

• Whether old nodes are still present in DNS results

If the issue occurs only on certain networks, save the node IP, test time, and request ID from the response, then submit them to the CDN provider. Compared with simply saying 'the website occasionally returns 404,' this information makes it much easier for technical support to locate the specific node logs.

Frequently asked questions

If the origin returns 200, does that mean the CDN must be at fault?

Not necessarily. First confirm whether the origin test preserved the correct Host and HTTPS SNI. Getting a 200 by accessing the origin IP directly does not prove that the CDN fetches from the origin under the same request conditions.

What should I do if the 404 persists after purging the CDN cache?

Check the origin fetch Host, origin fetch path, protocol, port, and origin selection. Cache purging can only address cached old responses; it cannot fix an incorrect origin fetch configuration.

Why does the homepage work while some images return 404?

This is usually related to file paths, case sensitivity, cache rules, object storage directories, or static asset domains. Test the specific image URL separately through the CDN and against the origin instead of testing only the homepage.

Why do 404s appear and disappear intermittently?

First check whether the content across multiple origins is consistent and whether different CDN nodes have cached different versions. Recording the resolved node IP and response headers for each request often reveals the pattern quickly.

Will a CDN returning 404 affect SEO?

If search engines repeatedly receive 404s when crawling important pages, those pages may gradually drop out of the index. After fixing the issue, confirm that the pages consistently return 200, and check whether internal links, sitemaps, and canonicals still point to the correct URLs. Occasional node-level 404s should not be ignored either, because search engine crawlers may be routed to an abnormal node.