Frontend · JavaScript · Interview

Eight CORS Errors You'll Actually Hit — and One Chrome Just Invented

By kyriewen · Aug 22, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Chrome's Private Network Access enforcement is breaking local development workflows that have worked for years, and the error message is easily mistaken for a standard CORS failure. Knowing to look for `more-private address space` in the console saves hours of chasing a phantom regression.

Summary

CORS errors are notoriously cryptic, but they boil down to three root causes: a missing header, a wrong header value, or a new browser rule. This breakdown walks through eight specific error messages, each with the raw browser output, the underlying mechanism, and the fix. The first seven cover the usual suspects—wildcard credentials mismatches, duplicate headers, missing preflight methods, and cached preflight results—while the eighth tackles Chrome's Private Network Access policy, a restriction that began rolling out last year and is behind a wave of "it worked yesterday" localhost failures.

A quick-reference table maps each error's keyword directly to its cause and solution, turning a ten-minute debugging session into a ten-second lookup. The piece also dismantles three persistent myths: `mode: 'no-cors'` returns an opaque, unreadable response; browser extensions only fix your machine; and JSONP is a dead-end for modern applications.

Takeaways

— Every CORS error traces to a server response-header problem, not a front-end code bug.

— Wildcard `*` in `Access-Control-Allow-Origin` is illegal when the request carries cookies; the server must echo the specific origin and set `Access-Control-Allow-Credentials: true`.

— Duplicate `Access-Control-Allow-Origin` headers—often from nginx and the application both setting it—cause an instant block.

— Preflight requests check `Access-Control-Allow-Methods` and `Access-Control-Allow-Headers`; any missing method or custom header kills the request before it is sent.

— `Access-Control-Max-Age` caches preflight results, so a fixed config can still appear broken until the cache expires or is cleared.

— A 302 redirect shifts CORS responsibility to the final URL; if that target lacks the header, the request fails.

— Chrome's Private Network Access requires public pages accessing localhost or intranet resources to pass a preflight and receive `Access-Control-Allow-Private-Network: true`.

— `mode: 'no-cors'` yields an opaque response with no readable status or body—useful only for fire-and-forget telemetry.

— Browser extensions that inject CORS headers fix only the local browser; they do nothing for production users.

— JSONP is GET-only, needs backend support, and carries injection risk; standard CORS is the only reliable path.

Conclusions

The Private Network Access error is a policy change masquerading as a configuration bug, and its gradual rollout means teams will encounter it at different times with no obvious trigger.

Most CORS debugging time is wasted on the wrong layer—developers tweak front-end code when the fix is always a server or proxy configuration change.

The quick-reference approach of matching error keywords to fixes treats CORS as a pattern-recognition problem rather than a protocol deep-dive, which matches how most developers actually troubleshoot.

Listing `no-cors` as a CORS solution in documentation is actively harmful; it silences the error while guaranteeing the data is unusable.

Concepts & terms

Preflight request

An OPTIONS request the browser sends before a cross-origin request that uses non-simple methods (PUT, DELETE) or headers (custom headers, `application/json` Content-Type). The server must respond with matching `Access-Control-Allow-Methods` and `Access-Control-Allow-Headers` before the real request proceeds.

Private Network Access (PNA)

A Chrome security policy that restricts public web pages from accessing resources on more-private networks (localhost, intranet IPs). It requires a preflight check and the response header `Access-Control-Allow-Private-Network: true`, plus a secure context (HTTPS or localhost) for the requesting page.

Opaque response

A response fetched with `mode: 'no-cors'` that JavaScript cannot inspect. The status code is reported as 0, and the body is unreadable, making it suitable only for one-way operations like analytics pings.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗