Fix Reason: CORS request did not succeed in Firefox

What the message means

Firefox prefixes every cross-origin failure with the same Cross-Origin Request Blocked sentence and puts the real diagnosis in the Reason: part. CORS request did not succeed is the reason for a request that never produced an HTTP response in the browser: the connection was blocked, refused, reset or failed its TLS handshake. That is why the status code is (null). Header problems look different: they carry a real status code and name the header.

# Console
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource
at https://api.example.com/data. (Reason: CORS request did not succeed). Status code: (null).

# What your code catches
TypeError: NetworkError when attempting to fetch resource.

# Compare: a real CORS header problem names the header and carries a status code
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource
at https://api.example.com/data. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200.

The 6 causes, in the order to check them

1. A privacy extension or ad blocker

   uBlock Origin, Privacy Badger and similar tools cancel requests to hosts on their lists, and Firefox reports the cancelled request as a CORS failure. Check: open the page in a private window with extensions disabled, or in Troubleshoot Mode. The Network tab shows the request as Blocked with the extension name in the details.

2. Enhanced Tracking Protection

   Firefox blocks known tracking domains itself in Strict mode and on some sites in Standard mode, which hits analytics and ad-tech APIs and the occasional CDN. Check: click the shield icon in the address bar and turn protection off for the site once. If the request succeeds, the host is on the tracking list.

3. A certificate Firefox does not trust

   Self-signed, expired or wrong-host certificates break fetch() silently: Firefox shows the warning page only for top-level navigations, never for a background request. Check: open the API URL in a new tab. If you see a certificate warning, fix the certificate on the server, or for local development, accept it in that tab once and reload your app.

4. Mixed content

   A page served over https:// may not call an http:// API; the browser blocks the request outright. Check: look at the scheme in the error. Fix: serve the API over HTTPS. No proxy helps here, including this one, which accepts HTTPS targets only.

5. The server is unreachable from the browser

   Wrong port, DNS name that only resolves inside your network, a firewall, a VPN that is down, or a local server that is not running. Check: curl -v the URL from the same machine and read the first lines. For localhost APIs, also compare the port in the error with the port the server prints at startup.

6. The server drops the connection on the request

   Some servers close the connection on an OPTIONS preflight they do not implement, crash on the request, or reset HTTP/2 streams; nothing comes back, so Firefox cannot even report a status. Check: curl -i -X OPTIONS with an Origin header and watch for an empty reply. Fix your own server by answering OPTIONS with 204; for a public API you do not control, read the next section.

# 1. Can anything reach it? Look for DNS, connection refused, timeout, or a certificate error
curl -v https://api.example.com/data -o /dev/null

# 2. Does the server survive a preflight? A dropped connection here shows up as "did not succeed"
curl -i -X OPTIONS https://api.example.com/data \
  -H 'Origin: https://www.yoursite.com' \
  -H 'Access-Control-Request-Method: GET'

# 3. Does the real request answer, and with which CORS headers?
curl -i https://api.example.com/data -H 'Origin: https://www.yoursite.com'

When a proxy is the fix

For a public API that is up but hostile to browsers, dropping preflights, resetting connections on cross-origin requests, or sitting on a blocklist your visitors use, routing the GET through a CORS proxy removes the browser from the equation: the browser talks to proxy.cors.dev only, the proxy answers the OPTIONS preflight itself with a 600 second Access-Control-Max-Age, fetches the API from its own servers with a 10 second deadline and 4 redirect hops at most, and relays the response with Access-Control-Allow-Origin for your origin.

// The browser now talks to proxy.cors.dev only: the proxy answers the OPTIONS preflight itself
// and fetches the API from its servers, so a flaky or preflight-hostile public API stops failing.
const feed = 'https://feeds.bbci.co.uk/news/technology/rss.xml';
const response = await fetch('https://proxy.cors.dev/' + feed, { credentials: 'omit' });

if (!response.ok) {
  // upstream_unreachable or upstream_timeout: the API really is down or slow
  throw new Error(response.headers.get('X-Cors-Error') ?? `HTTP ${response.status}`);
}
const xml = await response.text();

It does not help for causes 3, 4 and 5 when the server is yours: a bad certificate, an http:// endpoint or a server that is down stays broken, and the proxy reports it as upstream_unreachable with a 502. Private hosts, localhost and IP literals are refused with target_not_allowed, so local development problems need the fixes above, not a proxy.

Limits and pricing

Good questions.