CDN Static Assets Loading Broken? Fix DNS & CORS First

You set up a CDN, and now your site looks broken. Images, CSS, or JavaScript files return 404 or 403 errors. Or they just don't load at all. I've fixed this for dozens of clients running everything from small WordPress sites to enterprise apps on AWS CloudFront, Azure CDN, and Cloudflare. The fix is usually straightforward.

The Quick Fix: Check DNS First

The number one reason static assets break after CDN setup is that your DNS hasn't propagated yet. You changed your domain's CNAME to point to the CDN, but the old DNS records are still cached. This causes requests to land on the wrong server or get dropped entirely.

Here's what to do:

1. Run nslookup yourdomain.com from a terminal or PowerShell. If it shows your old server IP instead of the CDN hostname, DNS hasn't fully propagated.
2. Check TTL (Time To Live) on your DNS records. If you set it to 24 hours before switching, you'll wait up to that long. Lower it to 300 seconds (5 minutes) before making changes, then raise it back after everything works.
3. Use a global DNS checker like whatsmydns.net to see propagation across different regions. If Europe resolves fine but Asia doesn't, you're still propagating.

I've seen setups where the origin server (your main host) was still serving requests for static files while the CDN was supposed to handle them. The browser cached the old DNS result and kept hitting the origin. Clear your DNS cache locally with ipconfig /flushdns on Windows or sudo dscacheutil -flushcache on macOS.

If DNS looks clean and assets still don't load, move to the next step.

The Second Most Common Culprit: Missing CORS Headers

Your CDN acts as a reverse proxy. When a browser requests a font file or a WebP image from a different subdomain (like cdn.yourdomain.com instead of www.yourdomain.com), the browser checks for CORS (Cross-Origin Resource Sharing) headers. If they're missing, the request gets blocked.

This shows up as a 403 error in the browser console, with a message like "No 'Access-Control-Allow-Origin' header is present on the requested resource."

Fix it by adding CORS headers at the origin server level. For Apache, add this to your .htaccess:

Header set Access-Control-Allow-Origin "*"

For Nginx, add to your server block:

add_header Access-Control-Allow-Origin *;

Then make sure your CDN forwards these headers. In CloudFront, go to your distribution settings, Behavior tab, and set "Cache Based on Selected Request Headers" to "Whitelist" and add Origin. Without this, CloudFront strips the Origin header and your server won't know to send CORS headers back. I've wasted hours on that one.

For Azure CDN, you set CORS at the endpoint level under the "Rules engine." For Cloudflare, use the "CORS" option under "Scrape Shield" or set it via page rules.

Why This Works

CDN caching works by pulling content from your origin server once and serving it from edge locations. But if DNS points to the old server or CORS headers are missing, the whole chain breaks. DNS issues mean the browser never reaches the CDN. CORS issues mean the browser gets the file but refuses to use it. Fixing these two things resolves 80% of cases I've seen.

The CDN itself doesn't generate content — it just mirrors what's on your origin. So if your origin is configured wrong, the CDN will serve broken content or nothing at all.

Less Common Variations

SSL/TLS Mismatch

Your CDN uses HTTPS, but your origin server only serves HTTP. Mixed content warnings block assets. Make sure your origin supports HTTPS, or configure the CDN to connect to the origin via HTTP (not recommended for production). In CloudFront, check the "Origin Protocol Policy" — set it to "Match Viewer" or "HTTPS Only."

Cache Invalidation Not Done

You updated files on the origin but the CDN still serves old versions. By design, CDNs cache assets for hours or days. You need to invalidate the cache. In CloudFront, create an invalidation for /*. In Azure CDN, use "Purge." Cloudflare lets you "Purge Cache" from the dashboard. Don't forget this step — I've seen people wait 24 hours wondering why changes didn't appear.

Path Mismatch

Your origin serves files from /assets/images/logo.png, but your CDN is configured to look in /static/images/logo.png. This gives a 404. Double-check the "Origin Path" setting in your CDN. In CloudFront, it's under "Origins" — leave it blank unless you specifically changed folder structures.

File Permissions on Origin

If your origin is a web server with strict permissions, the CDN might not have read access. For Linux servers, ensure files are readable by the web server user (www-data or nobody). Run chmod 644 /path/to/static/files/* and chmod 755 /path/to/static/directories/.

Prevention for Future Setups

Next time you configure a CDN, follow this checklist:

• Set DNS TTL to 300 seconds before making changes.
• Test with a browser in incognito mode or curl to bypass local cache.
• Add CORS headers to your origin before pointing the CDN at it.
• Use a tool like curl -I https://cdn.yourdomain.com/style.css to inspect headers. Look for Access-Control-Allow-Origin and Content-Type.
• Invalidate cache after any file update.
• Monitor your CDN logs for 4xx errors during the first hour after setup.

That's it. DNS and CORS are the usual suspects. Fix those, and your static assets should load fine. If they don't, check the less common variations above. You'll save hours of head-scratching.