CORS 'Did Not Succeed': Find the Real Failure

Your fetch throws, and the console says the CORS request did not succeed. Instinct screams CORS headers — you open the server config and start adding Access-Control-Allow-Origin everywhere. Thirty minutes later nothing changed, because headers were never the problem. No response ever arrived to carry them.

This message is Firefox's way of saying the request never completed. The server might be down. DNS might fail. The certificate might be expired. An extension might have killed the flight. The page might be https calling http. Every one of those dies before CORS headers could matter, yet the console still says the C-word and sends you to the wrong docs.

This guide teaches the split that ends the confusion: curl first to test connectivity without browser interference, a clean profile to rule out extensions, the Network tab to read failed versus blocked, and response.ok plus timeouts so your code reports the true cause instead of a shrug. Work the checks in order and you'll name the killer in minutes instead of burning a sprint on headers that were never missing.

Not a Header Problem: The Request Never Completed

Read the sentence literally: the CORS request did not succeed. Not 'was rejected', not 'lacked a header' — it never finished. A classic CORS header failure looks different: the browser completes an HTTP exchange, finds no Access-Control-Allow-Origin, and blocks your script from reading a response that fully arrived. You can see that response in the Network tab with a status code attached. With did-not-succeed there is no status, no bytes, no response to attach headers to. The flight crashed; arguing about landing permission misses the point.

This distinction decides your first hour. Header failures are fixed in server config — add the origin, answer the preflight, expose the needed headers. Incomplete requests are fixed in connectivity — start the dead server, repair DNS, renew the cert, disable the killer extension, unify the scheme. Every minute spent on the wrong list is wasted, and the console's wording pushes newcomers toward the wrong one because it contains the letters C-O-R-S. Train yourself to translate the message on sight: did-not-succeed equals transport, always.

Your code can enforce the split too. A fetch that rejects with TypeError never completed; a fetch that resolves with res.ok false completed with an error status. Log err.name and message in every catch, and check res.ok before parsing — the snippet with this section shows the pattern. Teams that classify at the call site get bug reports saying 'never completed, curl next' instead of 'CORS broken?', and their fixes land in the right layer the first time.

// did-it-connect.js — classify the failure instead of guessing CORS
async function fetchJson(url) {
  const ctrl = new AbortController();
  const timer = setTimeout(() => ctrl.abort(), 10000);
  try {
    const res = await fetch(url, { signal: ctrl.signal });
    if (!res.ok) {
      // HTTP completed: server answered, status is the story.
      throw new Error('HTTP ' + res.status + ' from ' + url);
    }
    return await res.json();
  } catch (err) {
    if (err.name === 'AbortError') {
      console.error('Timed out (stalled), server is slow: ' + url);
    } else {
      // TypeError: request never completed — curl the URL next.
      console.error('Never completed, check server/DNS/TLS: ' + err.message);
    }
    throw err;
  } finally {
    clearTimeout(timer);
  }
}

Server Down, DNS, and TLS: Failures That Look Like CORS

Three server-side deaths wear the CORS costume. A stopped or crashed API refuses connections, and Firefox reports each fetch as did-not-succeed because nothing ever answered. Confirm in seconds: curl -v the same URL and watch for an instant refusal, then check the server process and its listening log. If the backend moved ports in a deploy, diff the page's base URL against the new listen line — the frontend env var is the usual stale piece, and it announces itself in the first log line once you print it at boot.

DNS failures look identical from the page. A renamed host, an expired dev tunnel URL, or a VPN that hijacks resolution means the browser never found an IP to call. curl says 'Could not resolve host' plainly, while the console mumbles about CORS. Test the exact hostname the page uses — not localhost when the page calls a tunnel domain — and check whether the failure follows the network (office vs home vs hotspot) to finger VPNs and captive portals.

TLS failures are the sneakiest because everything looks configured. An expired cert, a hostname that doesn't match the cert, or a corporate proxy re-signing traffic with an untrusted root all kill the handshake before HTTP starts. curl -v spells it out ('certificate has expired', 'unable to get local issuer certificate'), and the fix is renewal or trust, never headers. Monitor cert expiry from outside your network — office caches and pinned roots can mask a public breakage for hours, as our incident below proves.

// reachability.js — prove each layer before blaming CORS
// Run these from the terminal, same machine as the browser.
// 1. DNS:      nslookup api.example.com
// 2. TCP:      curl -v http://api.example.com:3000/health
// 3. TLS:      curl -v https://api.example.com/health
// 4. App:      curl -v https://api.example.com/users -H "Origin: https://app.example.com"
async function probe(url) {
  try {
    const res = await fetch(url, { method: 'HEAD' });
    console.log(url + ' -> HTTP ' + res.status + ' (reachable)');
  } catch (err) {
    console.log(url + ' -> never completed: ' + err.message);
  }
}

probe('https://api.example.com/health');

Extensions, Ad Blockers, and Corporate Proxies That Kill Requests

Privacy extensions, ad blockers, script managers, and antivirus proxies all sit between your page and the network with permission to terminate requests. When one matches your API host or a tracking-looking path, the fetch dies inside the browser and surfaces as the same did-not-succeed line a dead server would produce. Your code is innocent, the server is innocent, and only the middlebox knows. The tell is distribution: it fails on your machine but passes in CI, on teammates' laptops, and on phones — because the killer lives in your profile.

The clean-profile test rules this in or out in under a minute. Chromium guest windows and fresh Firefox profiles load zero extensions by default; if the request succeeds there, bisect your daily profile by halves until the single culprit shows. Common offenders include over-broad blocklists that match api/analytics paths, corporate proxies that re-sign TLS with an untrusted root, and VPN clients that route localhost oddly. Document the find for the team — the next person with the same symptom gets a one-line fix.

Service workers deserve a mention as the self-inflicted middlebox. A stale worker can serve cached failure responses or route requests to a dead precache, faking a network fault with your own code. During debugging, bypass it: DevTools → Application → Service Workers → Bypass for network, or unregister the worker entirely. If the failure vanishes, the network was fine all along and your caching strategy needs the fix, not your CORS config.

// clean-room.js — bisect extensions without guessing
// 1. Open a guest window (extensions off by default) and retry.
// 2. If it works, re-enable half your extensions, retry, repeat.
// 3. Log what the page sees so the report is precise:
async function reportEnvironment() {
  console.log('UA: ' + navigator.userAgent);
  console.log('onLine: ' + navigator.onLine);
  const t0 = performance.now();
  try {
    await fetch('/health', { cache: 'no-store' });
    console.log('same-origin ms: ' + Math.round(performance.now() - t0));
  } catch (err) {
    console.log('same-origin failed too: ' + err.message);
  }
}

reportEnvironment();

Mixed Content: http on an https Page Dies Silently

An https page that fetches http:// is asking the browser to downgrade a secure context, and modern browsers refuse. Chromium blocks it as mixed content before any packet leaves; Firefox reports the fetch as not succeeding. Either way no CORS exchange happens, so no header can excuse it. The trap springs during deploys: everything works on http localhost, then staging goes https and the same code starts failing with a message that screams CORS at you.

Diagnosis is one glance at the Network tab: the row reads (blocked:mixed-content) and the console names mixed content alongside the failure. The durable fix is architectural, not per-request: keep the page and the API on one scheme and one origin. In dev, proxy /api through Vite or webpack so the browser never makes a cross-scheme call. In production, serve the API behind the same https host. The mkcert tool gives you trusted local https when the page must stay secure during development.

Treat scheme as part of the URL contract and review it in every deploy diff. A base URL that flips from https to http (or gains a hardcoded :80) deserves the same scrutiny as a changed hostname. Log the full request URL in development on failure — scheme included — so the next mismatch confesses in the first line of output instead of hiding behind a CORS costume for an afternoon.

// same-origin-api.js — one origin in dev kills mixed content for good
// vite.config.js proxy: page calls /api, Vite forwards to the API.
// No cross-scheme fetch ever leaves the browser.
async function getUsers() {
  const res = await fetch('/api/users', { headers: { Accept: 'application/json' } });
  if (!res.ok) {
    throw new Error('GET /api/users -> ' + res.status);
  }
  return res.json();
}

// Detect the trap at runtime and say so plainly:
if (location.protocol === 'https:' && !('serviceWorker' in navigator && location.host.includes('localhost'))) {
  console.log('page is https: API calls must be https or same-origin');
}

Reading the Network Panel: Failed vs Blocked vs CORS Error

The Network tab settles every argument about this error if you read three fields in order. First the Status column: (failed) or (blocked:*) with no HTTP code means the request never completed — work the connectivity list. A numeric status (200, 403, 500) with a CORS console line means the exchange finished and headers are genuinely at fault. This one column splits the two universes, yet most developers stare at the console and never look at it.

Second, the Timing tab. An instant failure — 1ms and dead — points at a client-side block, a refusal, or mixed content: something said no immediately. A long Waiting phase that ends in failure points at stalls: a slow endpoint, a buffering proxy, or a hung server that accepted the socket and never answered. Pair the timing with curl's verbose output, which timestamps DNS, TCP, and TLS phases separately and shows exactly which phase never finished.

Third, match the console text to the row. 'Did not succeed' alone beside a (failed) row confirms an incomplete request — don't open header docs. A CORS Allow-Origin line beside a 200 row confirms headers — now open them. Make this three-field read a team habit and the average 'CORS' ticket stops being a 2-hour mystery and becomes a 10-minute classification with the fix attached.

// read-the-row.js — what the Network tab is telling you
// Click the failed request and check, in order:
// 1. Status: (failed)/(blocked:*) = transport · HTTP status = headers/app
// 2. Timing: instant fail = block or refusal · long wait = stall or proxy
// 3. Console: 'did not succeed' alone = incomplete · plus Allow-Origin = headers
async function timedFetch(url) {
  const t0 = performance.now();
  try {
    const res = await fetch(url, { cache: 'no-store' });
    console.log(url + ' answered ' + res.status + ' in ' + Math.round(performance.now() - t0) + 'ms');
    return res;
  } catch (err) {
    console.log(url + ' never completed after ' + Math.round(performance.now() - t0) + 'ms: ' + err.message);
    throw err;
  }
}

The Checklist That Stops 'CORS' Wild-Goose Chases

Run this order and stop at the first failure. One: curl -v the exact URL the page calls, from the same machine. Any HTTP response means connectivity works — now headers and page code earn attention. Refused, resolve errors, or cert errors name the true culprit in one line. Two: retest in a clean profile with no extensions. Success there means a middlebox, not a server fault — bisect the extensions. Three: read the Network row's Status, Timing, and console text together to confirm transport versus headers.

Four: compare schemes — an https page must not call http APIs, so proxy /api through the dev server for a single origin. Five: wrap the fetch with a 10-second AbortSignal timeout and a catch that logs err.name, so stalls and refusals stop looking identical. Six: only now, with a curl response in hand and a numeric status in the Network tab, open the CORS header docs and fix the actual header gap.

Record the classification with every ticket: curl result, profile result, Network status. Three lines turn the next 'CORS?' report into a 5-minute confirmation instead of a fresh investigation. The message stops being scary once your team reads it as what it is — a request that never finished, with a short list of usual killers.