Fix NS_E_CACHE_ORIGIN_SERVER_NOT_FOUND (0XC00D13ED)

Yeah, this error is annoying. You're running a cache proxy or reverse proxy with IIS and Application Request Routing (ARR), and suddenly your cached pages stop loading. The error says the origin server can't be found. Let's fix it.

The quick fix — check three things

What's actually happening here is your cache server (the one with IIS + ARR) tried to fetch content from the real origin server (like your backend web server), but couldn't find it. The error comes from the cache, not the origin. So you need to fix how your cache talks to the origin.

Can your cache server resolve the origin's hostname? Open a command prompt on your cache server and run: nslookup your-origin-server.com. If it fails, your DNS is wrong. Either fix your DNS records or add a hosts file entry. (On Windows Server 2019/2022, the hosts file is at C:\Windows\System32\drivers\etc\hosts.)
Can your cache server reach the origin's IP and port? Run: telnet origin-ip 80 (or 443 for HTTPS). If it hangs or fails, a firewall is blocking the connection. Check Windows Firewall and any network firewall between the cache and origin. You need to allow outbound traffic from the cache to the origin on the right port.
Is the origin URL in your cache rule correct? In IIS Manager, open your URL Rewrite rule under the server node. Look at the "Rewrite URL" pattern. Does it point to http://your-origin-server.com/{R:1} or similar? The hostname must match exactly what DNS resolves. A typo here gives you this error every time.

I've seen step 3 catch people most often. They copy a rule from another server but forget to update the origin hostname. Double-check it.

Why this fix works

The reason step 1 matters is the cache server needs to resolve the origin's hostname to an IP before it can connect. If DNS is broken, the cache literally doesn't know where to send the request. But even with correct DNS, step 2 can kill you — a firewall rule blocking port 80 or 443 from the cache to the origin stops the TCP handshake. And step 3 is about the cache rule itself — if the URL rewrite pattern is malformed, the cache sends a request to a non-existent path.

All three steps together cover the full path from name resolution to network connectivity to application configuration. Most of the time, one of them is misconfigured.

Less common variations of the same error

Sometimes the error isn't about DNS or firewall. Here are three edge cases I've run into:

SSL certificate mismatch on the origin. If your cache proxies HTTPS to an origin with a self-signed or expired cert, ARR can reject the connection. The error might look like 0XC00D13ED but the root cause is TLS. Fix: make sure the origin's cert is valid, or disable certificate validation in ARR (not recommended for production).
Origin server is overloaded or crashed. If the origin is running but not responding to new connections, the cache can't fetch content. Check the origin's event logs and resource usage. Sometimes a simple restart of the origin's web service (like iisreset on the origin) fixes it.
Cache disk is full. Unlikely but possible. If the cache can't write to its disk, it can't serve cached content and throws this error. Check the drive where your cache is stored (usually C:\inetpub\temp\ARR or whatever you configured). Free up space if needed.

Prevention — stop this from coming back

Don't wait for the error again. Do these:

Set up DNS monitoring. Use a simple script that runs nslookup against your origin hostname every 5 minutes and alerts you if it fails. I use a PowerShell scheduled task for this.
Document your cache rules. Keep a text file or wiki page that lists each ARR rule, its origin URL, and the port. When you change something, update the doc. Saves hours later.
Test firewall rules after any network change. Every time someone touches the firewall, run a quick telnet test from the cache to the origin. It's boring but catches issues fast.
Monitor origin health. Set up a basic health check that hits the origin's status page every 30 seconds. If it fails, alert before your users see the error.