> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gcore.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Unavailable content after CDN resource creation

> Fix unavailable CDN content after resource creation by checking origin response, host header, DNS, SSL, and cache settings.

After a CDN resource is created, content can fail to load from the CDN hostname even when the origin still returns HTTP 200. Work through the origin check first, then the resource settings below. If a check restores delivery, stop. Otherwise continue to the next check.

## Origin HTTP response

Request a file that should be delivered through CDN from the origin, using GET and discarding the body. `curl -I` sends HEAD, which an origin application can handle differently from GET. An HTTP 200 response means the origin can serve the object for that request. An HTTP 4xx or 5xx on that same request usually means the origin cannot serve the object. CDN nodes can still fail later if the Host header, SNI hostname, origin ACL, or authentication differs from this request.

Reproduce the CDN pull: use the origin protocol, send the configured **Custom Host header**, use the configured [SNI hostname](/cdn/cdn-resource-options/security/set-the-hostname-passed-in-sni-requests-to-the-origin-server) in `--resolve` and in the URL for HTTPS, and pin `--resolve` to the origin IP. Add the same authentication headers or credentials the CDN sends when the origin requires them.

```sh theme={null}
curl -sS -D - -o /dev/null \
  --resolve sni.example.com:443:203.0.113.10 \
  -H "Host: host.example.com" \
  https://sni.example.com/image.png
```

Replace `sni.example.com` with the SNI hostname: the **Change Host header** value when **Dynamic SNI hostname** is selected, or **Specify SNI hostname** when **Custom SNI hostname** is selected. Replace `host.example.com` with **Custom Host header**. Replace `203.0.113.10` with the origin IP and `image.png` with the object path. For HTTP origin, use `http://`, port `80` in `--resolve`, and skip SNI.

## CDN resource settings

In the [Gcore Customer Portal](https://portal.gcore.com), navigate to **CDN** > **CDN resources** and open the resource. Each check below maps to one setting that commonly blocks delivery after creation.

### Custom domain and DNS

A missing or incorrect CNAME prevents the [custom domain](/cdn/cdn-resource-options/general/create-and-set-a-custom-domain-for-the-content-delivery-via-cdn) from resolving to Gcore. Traffic does not automatically go to the origin; the custom hostname fails to resolve, or it resolves to the wrong target. The Setup guide reports whether DNS is in place.

**1. Open Setup guide**

In resource settings, click **Setup guide**. If Setup guide is not available, continue with [Host header](#host-header).

![Setup guide in CDN resource settings](https://mintcdn.com/gcore/2wEzzgnQCsXCQlDa/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image1.png?fit=max\&auto=format\&n=2wEzzgnQCsXCQlDa\&q=85\&s=92a14cb7c3cc7114004392b727f29010)

**2. Check DNS setup status**

Click **Check DNS setup status**.

![Check DNS setup status in the Setup guide](https://mintcdn.com/gcore/2wEzzgnQCsXCQlDa/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image2.png?fit=max\&auto=format\&n=2wEzzgnQCsXCQlDa\&q=85\&s=2792b0e25b5c959c354dd24dc6987b40)

If DNS is missing, this notification appears:

![DNS record has not been set up](https://mintcdn.com/gcore/2wEzzgnQCsXCQlDa/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image3.png?fit=max\&auto=format\&n=2wEzzgnQCsXCQlDa\&q=85\&s=ee446666abe48fa70f30a2da7fc37246)

**3. Confirm the CNAME**

When Setup guide reports that DNS is missing, open [DNS lookup](https://gcore.com/dev-tools/dns-lookup), enter the custom domain from the notification (`cdn.example.com` in the screenshot), select the resolvers, and click **Search**.

On the **CNAME** tab, compare the result with the Setup guide target. A matching CNAME means the record exists in those resolvers. If Setup guide still reports that DNS is missing, wait and repeat **Check DNS setup status**. Resolver caches often update within about 15 minutes, though a recent nameserver change can take longer.

If the lookup target does not match the Setup guide value, or the result is **No records were found**, add or correct the CNAME in [custom domain](/cdn/cdn-resource-options/general/create-and-set-a-custom-domain-for-the-content-delivery-via-cdn) settings.

**4. Wait for DNS propagation**

Save DNS changes and wait for propagation. Updates often finish within 15 minutes. A recent nameserver change can take up to 24 hours.

Request the object from the custom domain. If the CNAME was the cause, delivery resumes. If it does not, continue with [Host header](#host-header). If Setup guide does not report a DNS problem and the custom domain still fails, continue with [Host header](#host-header) as well.

### Host header

The [Host header](/cdn/cdn-resource-options/http-headers/configure-and-check-the-host-header) tells CDN nodes which origin hostname to request. When it does not match the origin, the origin cannot serve the object.

**1. Open Host header**

In resource settings, open **HTTP headers** and find **Host header**.

![Host header option in resource settings](https://mintcdn.com/gcore/2wEzzgnQCsXCQlDa/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image7.png?fit=max\&auto=format\&n=2wEzzgnQCsXCQlDa\&q=85\&s=0feb01dc40ed6b7b2f43b67116843015)

**2. Copy the Host header value**

Copy the value configured in **Custom Host header**.

**3. Request the origin with Host and SNI**

In a terminal, send GET and discard the body. Match the origin protocol, **Custom Host header**, [SNI hostname](/cdn/cdn-resource-options/security/set-the-hostname-passed-in-sni-requests-to-the-origin-server), and origin IP. Add authentication headers or credentials when the origin requires them.

```sh theme={null}
curl -sS -D - -o /dev/null \
  --resolve sni.example.com:443:203.0.113.10 \
  -H "Host: host.example.com" \
  https://sni.example.com/image.png
```

Replace `sni.example.com` with the configured SNI hostname, `host.example.com` with **Custom Host header**, `203.0.113.10` with the origin IP, and `image.png` with the object path. For HTTP origin, use `http://` and port `80` in `--resolve`.

**4. Update Custom Host header if needed**

A 2xx response means the Host header is not the cause. Continue with [Origin pull protocol](#origin-pull-protocol).

A 4xx or 5xx response means the origin rejected that Host header. For a single origin, set the origin hostname in **Custom Host header**. For several origins, each origin must accept that Host header. The header does not change automatically when the origin changes.

Click **Save changes**, [purge](/cdn/clear-cdn-resource-cache-by-url-pattern-or-all) the affected URL, then request the object from the CDN hostname again. If delivery works, stop. If it does not, continue with [Origin pull protocol](#origin-pull-protocol).

### Origin pull protocol

The [origin pull](/cdn/cdn-resource-options/general/specify-an-origin-and-the-origin-pull-protocol) protocol (HTTP, HTTPS, or both) is how CDN nodes fetch from the origin. The wrong protocol causes fetch errors or redirects.

**1. Confirm the origin protocol**

Open the origin in the browser and read the URL scheme. `https://example.com` is HTTPS. `http://example.com` is HTTP. Confirm both schemes if the origin is expected to serve both.

![Browser padlock on an HTTPS origin](https://mintcdn.com/gcore/evtADw-dx9HWoqdh/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image8.png?fit=max\&auto=format\&n=evtADw-dx9HWoqdh\&q=85\&s=0ed9ed65df189f581aa81fe3a1f82d72)

![Not secure label on an HTTP origin](https://mintcdn.com/gcore/evtADw-dx9HWoqdh/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image9.png?fit=max\&auto=format\&n=evtADw-dx9HWoqdh\&q=85\&s=aa64ecde088875f11c07c9185ee0c04e)

**2. Compare Origin pull protocol**

In resource settings, open **General** and find **Origin pull protocol**.

![Origin pull protocol in the General section](https://mintcdn.com/gcore/2wEzzgnQCsXCQlDa/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image10.png?fit=max\&auto=format\&n=2wEzzgnQCsXCQlDa\&q=85\&s=333ba56ebc5bc1bdbe48cfedfa9a3ba6)

**3. Save and retest**

If the origin protocol and **Origin pull protocol** match, continue with [SSL certificate](#ssl-certificate). If they differ, set **Origin pull protocol** to the origin protocol, click **Save changes**, [purge](/cdn/clear-cdn-resource-cache-by-url-pattern-or-all) the affected URL, then request the object from the CDN hostname again.

If delivery works, stop. If it does not, continue with [SSL certificate](#ssl-certificate).

### SSL certificate

HTTPS delivery needs a certificate on the custom domain. A missing or invalid certificate blocks HTTPS or shows a browser trust warning.

**1. Open SSL settings**

In **General**, open **SSL**.

![SSL settings in CDN resource settings](https://mintcdn.com/gcore/evtADw-dx9HWoqdh/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image11.png?fit=max\&auto=format\&n=evtADw-dx9HWoqdh\&q=85\&s=6a9ba8ce76b7208988f19d62e76af0ab)

**2. Confirm Enable HTTPS**

Confirm **Enable HTTPS** is on. Certificate types are **Free Let's Encrypt certificate** and **Custom SSL certificate**. After issuing or adding a certificate, click **Save changes** and allow 15–30 minutes for CDN edges to present it.

![Enable HTTPS and certificate type in SSL settings](https://mintcdn.com/gcore/2wEzzgnQCsXCQlDa/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image12.png?fit=max\&auto=format\&n=2wEzzgnQCsXCQlDa\&q=85\&s=7cd8d450540e3e9a1a9c47cca0614020)

**Let's Encrypt certificate**

Let's Encrypt cannot issue a certificate until the custom domain CNAME exists. Complete the [custom domain and DNS](#custom-domain-and-dns) check first.

In resource settings, open **Rules**. If there are no rules, continue with **Custom SSL certificate**.

![Rules section in CDN resource settings](https://mintcdn.com/gcore/2wEzzgnQCsXCQlDa/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image13.png?fit=max\&auto=format\&n=2wEzzgnQCsXCQlDa\&q=85\&s=bb9671000e8fc04033cb20da034c50ff)

A rule is a problem only when its behavior interferes with `/.well-known/acme-challenge/`. Broad patterns such as `/*` are not inherently blocking. Narrow the rule or exclude that path so automatic renewal continues working. Full issuance steps are in [Let's Encrypt](/cdn/ssl-certificates/configure-a-lets-encrypt-certificate).

**Custom SSL certificate**

A third-party certificate must cover the custom domain and present a complete chain. Browsers will not trust the certificate unless its chain leads to a public trusted CA. In [custom SSL](/cdn/ssl-certificates/configure-your-own-ssl-certificate) settings, **Signed by a trusted CA.** can be cleared when the certificate is not from a trusted CA. Clearing that checkbox allows the upload; it does not make browsers trust a private CA or an incomplete chain.

**1. Test TLS on the custom domain**

In a terminal, send GET and discard the body:

```sh theme={null}
curl -sS -D - -o /dev/null https://cdn.example.com/image.png
```

Replace `cdn.example.com` with the custom domain and `image.png` with the object path.

A 2xx response means the TLS handshake succeeded. Continue with the browser check.

A rejected server certificate typically looks like this:

```text theme={null}
curl: (60) SSL certificate problem: unable to get local issuer certificate
```

curl error 60 means the peer certificate was not verified. That can result from a private CA or an incomplete chain. curl error 77 is a different failure: the local CA certificate file or store could not be read.

**2. Inspect the certificate in the browser**

In the browser, open an object on the CDN hostname. Open the certificate viewer from the address bar or developer tools. Confirm the certificate covers the custom domain and is not expired. A wildcard is optional. A certificate for `*.example.com` covers `cdn.example.com`. It does not cover the apex domain `example.com` or a nested hostname `assets.cdn.example.com`.

![Certificate details in the browser](https://mintcdn.com/gcore/evtADw-dx9HWoqdh/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image14.png?fit=max\&auto=format\&n=evtADw-dx9HWoqdh\&q=85\&s=e480129a9c62fe9ddaa84e02ada5d5bd)

Renew or reissue the certificate if the name or dates are wrong. Click **Save changes** after attaching a replacement, then [purge](/cdn/clear-cdn-resource-cache-by-url-pattern-or-all) the affected URL.

**3. Inspect the chain on SSL Labs**

On [SSL Labs](https://ssllabs.com/ssltest), enter the custom domain in **Hostname** and click **Submit**. Use the report to inspect the certificate chain and trust path.

![SSL Labs test form](https://mintcdn.com/gcore/evtADw-dx9HWoqdh/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image15.png?fit=max\&auto=format\&n=evtADw-dx9HWoqdh\&q=85\&s=890a2356f1885f984372aa8c9b2c1b15)

If the report lists chain issues, the uploaded chain is incomplete. Certificate and private-key values cannot be changed after upload. Upload a new certificate that contains the complete chain (leaf, intermediate CA, root CA), attach it to the CDN resource, and click **Save changes**. Verify HTTPS on the custom domain, then [delete](/cdn/ssl-certificates/configure-your-own-ssl-certificate#delete-an-ssl-certificate) the old certificate. Full steps are in [custom SSL](/cdn/ssl-certificates/configure-your-own-ssl-certificate).

![SSL Labs A+ rating](https://mintcdn.com/gcore/evtADw-dx9HWoqdh/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image16.png?fit=max\&auto=format\&n=evtADw-dx9HWoqdh\&q=85\&s=3d95a6ec9d3075b2c03bb7c1f19d4988)

![SSL Labs B rating with chain issues](https://mintcdn.com/gcore/evtADw-dx9HWoqdh/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image17.png?fit=max\&auto=format\&n=evtADw-dx9HWoqdh\&q=85\&s=926fe31371c7df4a86168fc4f941596e)

If HTTPS delivery works after these SSL checks, stop. If the object still fails to load, continue with [Cache behavior](#cache-behavior) and [Cache purge](#cache-purge).

### Cache behavior

Wrong cache settings rarely make content unavailable. They more often serve a stale object or keep the origin busy. If the CDN hostname returns an error or an empty response, continue with [Cache purge](#cache-purge). If the object loads but looks outdated or the cache hit ratio is unexpectedly low, use the [low cache hit ratio](/cdn/troubleshooting/cache-percentage-is-low-how-to-solve-the-issue) checks.

**1. Inspect cache response headers**

Request a CDN object with GET and discard the body, then inspect `Cache` and `Cache-Control`.

```sh theme={null}
curl -sS -D - -o /dev/null https://cdn.example.com/image.png
```

![CDN caching option](https://mintcdn.com/gcore/2wEzzgnQCsXCQlDa/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image20.png?fit=max\&auto=format\&n=2wEzzgnQCsXCQlDa\&q=85\&s=16572becd104d2a3134996a563af012d)

**2. Review query string and Set-Cookie**

**Ignore query string** and **Ignore Set-Cookie** change how variants share a cache key. Enable them only when those values do not select different content or personalize the response. Otherwise, clients can receive the wrong cached object. Configuration is in the [query string](/cdn/cdn-resource-options/cache/ignore-the-set-cookie-or-query-string-parameters-when-caching-content-on-cdn-servers) article.

![Query string and Set-Cookie cache options](https://mintcdn.com/gcore/2wEzzgnQCsXCQlDa/images/docs/cdn/troubleshooting/content-is-unavailable-after-a-cdn-resource-creation-how-to-solve-the-issue/image21.png?fit=max\&auto=format\&n=2wEzzgnQCsXCQlDa\&q=85\&s=e7bb32cdd42195ae8832ef54671227a9)

After changing cache settings, click **Save changes**, [purge](/cdn/clear-cdn-resource-cache-by-url-pattern-or-all) the affected URL, then retest.

### Cache purge

A stale or wrong object can remain in cache after origin or settings changes. Confirm the purge in history, then confirm cache status on the object. `Content-Length` and `ETag` can differ because of compression or transformation, so matching those values does not prove that a purge succeeded.

**1. Check Purge history**

Open [Purge history](https://portal.gcore.com/cdn/purge/purge-history) and wait until the request status is **Successful**. Then test the object. History keeps requests for the past month. Details are in the [purge](/cdn/clear-cdn-resource-cache-by-url-pattern-or-all) article.

**2. Verify miss or bypass then hit**

Request the object from the CDN hostname with GET, discarding the body, and copy the `X-ID` header. That value identifies the edge that handled the request.

```sh theme={null}
curl -sS -D - -o /dev/null https://cdn.example.com/image.png
```

Resolve the edge IP from that `X-ID` value:

```sh theme={null}
nslookup m9-up-e245.fe.gc.onl
```

Replace `m9-up-e245` with the `X-ID` from the response. Use `dig` in place of `nslookup` if that is the local DNS tool.

Pin the next request to the same edge so both responses come from one server:

```sh theme={null}
curl -sS -D - -o /dev/null \
  --resolve cdn.example.com:443:203.0.113.10 \
  https://cdn.example.com/image.png
```

Replace `cdn.example.com` with the CDN hostname and `203.0.113.10` with the edge IP. An initial `Cache: MISS` or `Cache: BYPASS`, followed by `Cache: HIT` on the pinned request, means that edge fetched a fresh copy and then served it from cache.

**3. Purge again with a supported pattern**

If the object is still stale, purge again. Purge patterns are not regular expressions. Each path must start with `/` and can use `*` to replace any number of characters. Examples:

| Purge target | Pattern |
| - | - |
| One file, including query-string variants | `/static/image.jpg` |
| All files in a folder | `/static/*` |
| All `.jpg` files in a folder | `/static/*.jpg` |

If delivery still fails after these checks, contact [Gcore Support](mailto:support@gcore.com).