A page can load normally while its custom typeface silently falls back to a system font. In DevTools, the .woff2 request may even show 200 OK, yet the console still reports a CORS error. That is not a contradiction: the CDN delivered a response, but the browser refused to expose that response to the page.
This guide shows how to separate an origin configuration problem from a stale CDN object, an incorrect response-header rule, or an unrelated preflight request. The examples apply to fonts served from a dedicated static hostname or any CDN domain.
Identify the exact request that failed
Open the browser's Network panel, filter for font, woff, or woff2, and reload the page. Record the page origin, font URL, request method, status code, content type, and response headers. Pay particular attention to Access-Control-Allow-Origin.
Remember that an origin is defined by scheme, hostname, and port. https://www.example.com and https://static.example.com are different origins, as are HTTP and HTTPS versions of the same hostname.
Before changing CORS settings, rule out simpler failures:
A
404usually points to an incorrect URL or deployment path.A
403may indicate an access-control or signed-URL rule.A
200response containing HTML may be an origin error page or rewrite fallback, not a font file.An incorrect
Content-Typeor a redirect to another hostname can change the request path you need to diagnose.
Cross-origin fonts are subject to CORS checks. For a public font that does not use credentials, the font response can commonly return Access-Control-Allow-Origin: *. If access must be limited, return one complete permitted origin such as https://www.example.com; do not use a URL path or a comma-separated list of origins.
Compare the CDN response with the origin response
Use a GET request with an Origin header to inspect the response that the CDN actually serves. Replace the example hostnames with your own:
curl -sS -D - -o /dev/null \ -H 'Origin: https://www.example.com' \ 'https://static.example.net/fonts/site.woff2'
Check the status code, Content-Type, Access-Control-Allow-Origin, Vary, and any vendor-specific cache-status header. Then make the same request directly to the origin, if the origin can be reached safely for testing.
The comparison usually narrows the fault quickly:
If the origin includes the correct CORS header but the CDN does not, inspect CDN response-header policies and stale cached objects.
If neither response includes the header, fix the font response at the origin first.
If a new URL works while the old URL fails, the previous object or its metadata is probably still cached.
If both responses look correct but the browser still blocks the font, inspect redirects, the final request URL, credential mode, and the complete console message.
curl can show what the server returned, but it does not enforce browser CORS rules. Treat it as a header inspection tool, not proof that the browser will accept the resource.
Account for cached response headers
A CDN normally caches response headers together with the object. Adding Access-Control-Allow-Origin at the origin does not automatically repair an object that is already cached at edge locations. You may need to purge the affected font URLs, wait for expiration, or test with a new versioned filename.
Dynamic origin allowlists need extra care. When the response changes according to the request's Origin, return Vary: Origin and confirm that the CDN's cache-key and header-handling rules preserve the required variants. Vary: Origin is an HTTP signal; it does not guarantee that every CDN configuration will create the variants you expect.
Also check whether the CDN forwards the Origin request header to the origin. A rule that generates a site-specific CORS response cannot work consistently if the header is removed before the request reaches the origin.
Configure public font responses safely in Nginx
The following Nginx example is suitable for public fonts that do not use cross-origin credentials. Review the site's existing location blocks before applying it; do not paste it over a production configuration without testing.
location ~* \.(woff2?|ttf|otf)$ {
add_header Access-Control-Allow-Origin * always;
add_header X-Content-Type-Options nosniff always;
}Back up the relevant configuration, run nginx -t, and reload Nginx only after the syntax check succeeds. Nginx response-header inheritance can be surprising: defining add_header at a lower configuration level may affect which headers are inherited from a higher level. Recheck existing cache and security headers after the change.
Avoid returning duplicate or conflicting Access-Control-Allow-Origin headers from both Nginx and a CDN response-header policy. One correct policy in a clearly defined layer is easier to test and maintain.
If requests include credentials, a wildcard origin is not valid for credentialed CORS. Return the explicit approved origin and review Access-Control-Allow-Credentials. Public font delivery normally does not need cookies, so first check whether the frontend or a shared request wrapper is adding credentials unnecessarily.
Do not assume every OPTIONS request belongs to the font
A normal cross-origin font GET generally does not trigger a separate preflight by itself. If the Network panel shows an OPTIONS request, open it and verify its URL and intended follow-up method. It may belong to an API request on the same page, or it may have been triggered by a non-simple method or custom request headers.
A preflight response must authorize the method and headers used by its associated cross-origin request. Fixing an API preflight is different from adding CORS headers to a static font. Matching the OPTIONS request to the correct resource prevents unrelated issues from being mixed together.
Verify the repair from edge to browser
After changing the origin or CDN policy, purge only the affected objects when possible, or wait for their cache lifetime to expire. Then test in a private browser window and confirm all of the following:
The final font URL returns the expected font content and content type.
The response contains the correct
Access-Control-Allow-Originvalue.The console no longer reports a CORS error for that font.
The browser's Computed panel shows the expected font in use.
An approved page origin works, while an unapproved origin remains blocked if you use an allowlist.
If a versioned font URL succeeds but the original URL still fails, focus on cache invalidation and rule scope. If the origin and CDN headers are correct but the browser still fails, save one complete request-and-response record and inspect redirects, credentials, service workers, and the final URL instead of repeatedly changing the CORS policy.
References
Sources verified: September 18, 2026.
