Troubleshooting

Common responses and fixes

Most issues come down to one of three things: the hostname isn’t active, the origin path doesn’t resolve, or the cache is holding an old copy.

A CDN URL returns “not found”

The hostname serves only when the site is verified and the plan is active. Check:

• The site is verified in the dashboard. Verification can lapse if the DNS record or verification file is removed, or the domain changes hands — re-run the check.
• The workspace’s trial or subscription is active. When trial credit runs out, cached images keep serving through a grace period while new optimizations are refused; after it the hostname stops serving until you choose a plan.
• The path is spelled exactly as it is at your origin (paths are case-sensitive).

The image is broken or errors on first load

The first request pulls the original from your origin. If that pull fails, the image can’t be served. Check:

• The original loads directly from your origin at the same path over the public internet.
• Your origin isn’t blocking the fetch (for example an allowlist or firewall that rejects server-side requests).
• The URL points at a supported image format — JPEG, PNG, WebP, AVIF, or GIF. Non-image responses are not optimized, and SVG is deliberately not served through the CDN.

I updated the image but still see the old one

That’s the cache doing its job. If you replaced the image at the same path, purge it — the next request re-pulls the new version. Remember your browser may cache it too; hard-refresh to confirm.

My resize parameter seems to be ignored

• w and h round up to your site’s configured width list — a value between two allowed widths is served at the next size up (and capped at the largest). Images are never enlarged past the original. See URL parameters.
• dpr must be 1, 2, or 3; fit must be cover, contain, or inside. Anything else falls back to the default.
• There is no quality URL parameter — quality is a per-site setting.

What the response status means

Errors from the image engine carry a machine-readable x-cdnmn-error header naming the exact reason. One exception: a hostname that isn’t active (unknown, still pending, or suspended) is refused directly at the edge with a bare 404 and no header — if the header is missing on a 404, check the hostname’s status in the dashboard first.

The website analyzer says my site is blocking it

The analyzer at /check fetches your homepage and up to twenty of the images on it — once, then not again for that site for a couple of minutes — and reads their headers to measure what an optimized version would save. It identifies itself honestly on every request:

User-Agent: CDN.MN Analyzer (+https://cdn.mn/docs/troubleshooting#analyzer-blocked)

Bot-protection and CAPTCHA services (Cloudflare, Akamai, DataDome, PerimeterX, Imperva and others) sometimes answer that request with a challenge page or a 403 instead of your site. When that happens the analyzer tells you so rather than guessing — your site is up; a filter in front of it declined an automated visitor. It is a deliberate choice on our side not to pretend to be a browser to get past that: it is your access control, and the fix is to let us through on purpose — narrowly.

Read this before you add a rule. A user-agent string is not an identity: anyone can send ours. A rule that switches protection off for every request carrying it would let any scraper through by copying the string. We do not currently publish a fixed set of source addresses to pin a rule to (our analyzer runs from short-lived workers whose addresses change), so the safe rule is a narrow one that exposes nothing that is not already public:

• match the user agent and the request method GET and the path you submit to the analyzer — normally your homepage, /. The analyzer reads exactly the page you enter (a deeper page such as /products is fetched as-is), then follows that page’s own <img> tags — with the same user agent, so a rule that allows only the page produces a report with no measured images (the report will say so). Add the path prefixes your images live under as well, e.g. /images/* or /wp-content/uploads/*. If you analyzed a deeper page, allow that path too — or simply re-run against your homepage;
• keep your rate limits on — one analysis is one page plus at most twenty image requests;
• never exempt sign-in, checkout, search, or API paths on the strength of a user agent.

Where the rule goes:

• Cloudflare — Security → WAF → Custom rules: a Skip rule with the expression (http.user_agent contains "CDN.MN Analyzer" and http.request.method eq "GET" and (http.request.uri.path eq "/" or starts_with( http.request.uri.path, "/wp-content/uploads/"))) skipping managed challenges / Super Bot Fight Mode — replace "/" with the path you submitted if it was not the homepage. (Plain Bot Fight Mode has no exceptions — switch to Super Bot Fight Mode or a WAF rule.)
• Other services — most have a user-agent allowlist; add the same three conditions. If yours can only allowlist by IP address, email support@cdn.mn — we can run a check for you and we are working on a fixed egress address so IP-based rules become possible.
• Your own server — if the block comes from your application or web server, allow the homepage GET for the user agent and make sure it returns 200 with text/html.

Then run the analysis again. The analyzer only ever reads public pages and image headers; it never signs in, submits forms, or follows more than a few redirects.

Still stuck?

Email support@cdn.mn with the exact CDN URL, what you expected, and the x-cdnmn-error header value if there is one — that’s the fastest way for us to help.