Failed to Fetch Error: What It Means and the 12 Fixes That Work

"Failed to fetch" means your browser sent a request and got nothing usable back. It is almost always one of five things: CORS, a wrong URL or port (or a server that is down), a blocked request (ad blocker, VPN, firewall), mixed content, or a request cut off before it finished. Start with the quick check below, then jump to your case.

Read this in: Español | Português | Deutsch | Türkçe

Which one are you?

What does "Failed to Fetch" mean?

It means your browser or app asked a server for something and got silence.

Not a 404, which is the server saying the page doesn't exist. Not a 500, which is the server saying it broke. Those are answers. "Failed to fetch" is the absence of one: the request went out and nothing came back that the browser could use.

That's why the message is so unhelpful. The browser's Fetch API rejects with a TypeError for every failure that happens before a response arrives, and it deliberately doesn't say which one. Telling a script exactly why a cross-origin request failed would leak information about other people's servers.

So the browser gives you three words and leaves you to work it out. This page is how you work it out.

Is "Failed to fetch" my fault?

In an app or website you didn't build, usually not. The four most common reasons are a browser extension blocking the request, the network you're on (VPN, office firewall, weak Wi-Fi), an old copy of the page after the site updated, or the service being down for a few minutes. None of those means you broke anything, and none of them is a virus. Go straight to fixes 1 to 5.

Quick diagnosis: the DevTools Network tab checklist

If the error is in your own code, the first rule is this: "Failed to fetch" is never the real message. Open the browser console (F12) and read the line directly above or below it. A CORS failure, for example, prints something like "Access to fetch at ... from origin ... has been blocked by CORS policy", followed by the specific reason. That second half tells you what to fix.

Then open DevTools, go to Network, tick Preserve log, and reproduce the error. Work through this list.

• Does the request appear at all? If it never shows up, it was blocked before it left the browser. That points at an extension or a Content Security Policy rule, not at your server.
• What does the Status column say? A CORS-blocked request typically shows "CORS error" or "(failed)" rather than a number. A status of 0 means no response was received.
• Is there an OPTIONS request just before it? Non-simple requests send a preflight first. If the OPTIONS call failed, the real request never happened, and your fix belongs in how the server answers OPTIONS.
• Check the response headers. Look for access-control-allow-origin. If it's missing, or names an origin that isn't yours, that's your answer.
• Watch for "Provisional headers are shown". This often means the request was blocked or never completed, so check extensions and CSP.
• Read the Console tab alongside it. Network tells you what happened; Console usually tells you why, and CORS messages name the exact rule that failed.

Copy-paste test: is it CORS or the network?

The browser hides the real reason from your code, but you can make it show its hand. Paste this into the DevTools Console on the page that fails, with your URL in the first line:

const url = 'https://api.example.com/data'; // the URL that fails

fetch(url)
  .then((r) => console.log('OK', r.status))
  .catch(async (err) => {
    console.log('Normal fetch failed:', err.message);
    try {
      await fetch(url, { mode: 'no-cors' });
      console.log('Server is reachable: this is a CORS problem. Check Access-Control-Allow-Origin.');
    } catch {
      console.log('Server not reachable: check the URL, DNS, HTTPS/mixed content or an extension.');
    }
  });

A no-cors request is allowed to reach the server even when CORS would block your normal request; you just can't read the reply. If the second request goes through and the first doesn't, the server is up and the fix is its Access-Control-Allow-Origin header (fix 6). If both fail, look at the URL, DNS, HTTPS and mixed content, or an extension (fixes 7 to 9). Run it in a private window too, with extensions off.

Fixes 1 to 5: if you see it in an app or website

Run these five checks in order, because each one rules out a cause.

1. Reload properly with Ctrl+Shift+R (Cmd+Shift+R on Mac). This skips the cache without clearing cookies, so you stay logged in. On a phone, close the app fully and reopen it.
2. Try a private window. If it works there but not in your normal window, an extension is blocking the request, usually an ad blocker or a privacy add-on. Turn them off one at a time.
3. Turn off VPN, proxy or antivirus web protection for a minute. Anything between your browser and the internet can drop a request silently, and office firewalls belong here too.
4. Switch networks. Move from Wi-Fi to mobile data or back. If one network works and the other doesn't, the problem is the network, not the app.
5. Check whether the service is down. If it fails on every network and browser, it's on their side. Check the service's status page or social account and try again in a few minutes.

If it works in a private window, on another network or on another device, the app is fine. The problem is somewhere between you and it.

TypeError: Failed to fetch in Chrome, Firefox and Safari

The same failure carries different names depending on where you see it. If you searched one of these, you're in the right place:

The Firefox wording is defined in Firefox's own source code as its fetch failure message, and WebKit's public bug tracker shows Safari reporting the same failure as "TypeError: Load failed". The first three mean the same thing and take the same fixes. Node's "fetch failed" is a different animal with its own section below, and Swagger's message is the browser error with a hint list attached.

Failed to fetch in your language

The message is usually shown in English, even when the rest of the app is translated. Here's what it means, and where to read the full guide in your language.

Failed to fetch in a specific app

These are the apps people name most when they search this error. Fixes 1 to 5 still come first; this adds what's specific to each one.

"Connection error. Can't fetch server config."

This one does not come from websites or from your code. It is a popup from a browser VPN extension: users on Mozilla's support forum report it from the VeePN extension in Firefox, appearing again and again while the extension tries to connect. The "server config" is the extension's own setup, which it has to download from its provider before it can connect, and that download failed.

What helps, in order:

1. Turn the extension off and on again. Users in that thread report that refreshing the extension sometimes let it connect.
2. Disable your other extensions for a moment, in case one of them blocks the download.
3. Pick a different server or country in the extension.
4. Update the extension, or remove and reinstall it.
5. Try another network. Some office and school networks block VPN traffic.

If none of that works, contact the VPN provider's support, because the message comes from their extension and only they can see why their config server did not answer.

Fixes 6 to 10: the 5 causes in your own code

From here on, this is for developers.

Fix 6: CORS (the most common cause)

Your JavaScript runs on one origin and asks for data on another. The browser checks whether the server gave permission, and if the Access-Control-Allow-Origin header isn't there or doesn't match, it throws the request away before your code sees it.

The giveaway: the URL works when you paste it into the address bar or run curl, and fails in fetch. curl doesn't enforce CORS. Browsers do.

The fix is on the server. It must return the header naming your site's origin. If you own the backend, add it there. If you don't own it, put a small proxy in your own backend and call that instead.

One mistake to avoid:

fetch(url, { mode: 'no-cors' })  // does not fix CORS

This makes the error disappear and hands you an opaque response: status 0, body unreadable. You've swapped a visible failure for a silent one.

Watch out for the credentials rule too. If your request sends cookies, the browser rejects a wildcard Access-Control-Allow-Origin: *. You have to name the origin explicitly.

Fix 7: Wrong URL, port or DNS

Less glamorous, very common. A typo in the domain, the wrong port, a local server you forgot to start, or a DNS name that doesn't resolve. In development, the API on 3001 while your code calls 3000 accounts for a good share of these.

The fix: copy the request URL from the Network tab, run it with curl, and correct the host, port or environment variable behind it, or start the server you forgot.

Fix 8: Mixed content (HTTPS page calling HTTP)

If your page is served over https:// and your fetch targets http://, the browser blocks it without asking. The console says "Mixed Content". Change the target to https://.

Fix 9: Something between the browser and the network

Extensions, ad blockers, privacy tools, VPNs, proxies, corporate firewalls and antivirus software can all stop a request before it leaves. A Content Security Policy can too: if connect-src doesn't allow the host you're calling, the browser refuses the connection and says so in the console.

The fix: use the private-window test to find the extension and turn it off for that site, or add the host to connect-src in your Content Security Policy.

Fix 10: The request was cut off

The request started and the browser dropped it before a response arrived. A redirect (window.location = ...) or a page reload right after the call cancels it mid-flight, and so do closing the tab or the device losing its network. Nothing was ever wrong with the server.

One common claim is wrong: calling abort() on an AbortController does not produce this error. It rejects with a DOMException named AbortError, and a timeout from AbortSignal.timeout() rejects with one named TimeoutError. Check err.name before treating a failure as real.

The fix: await the fetch before you navigate or reload, and handle AbortError and TimeoutError separately from the TypeError.

Network problem or code problem? How to tell

One command settles it. Run the exact URL your code is calling:

curl -I https://api.yoursite.com/data

If curl returns headers: the server is up, reachable and answering. Your problem is in the browser layer: CORS, mixed content, an extension or CSP. Fixes 6, 8 and 9.

If curl hangs or errors: the server, the address or the network is the problem, and the browser was telling the truth. Fix 7, or the service is down (fix 5).

That single test routes you to the right half of this page in about ten seconds, and it's the step most people skip.

Node.js "fetch failed" is not "Failed to fetch"

Different environment, different problem, similar wording. There is no CORS in Node. If you see TypeError: fetch failed on the server, it's a network problem, and the real reason is hiding in cause.

Fix 11: print err.cause, and try 127.0.0.1 instead of localhost.

try {
  await fetch(url);
} catch (err) {
  console.error(err.cause);   // the actual reason lives here
}

One classic trap: in some Node versions localhost resolves to the IPv6 address ::1 first. If your server only listens on 127.0.0.1, the connection is refused. Swapping localhost for 127.0.0.1 fixes it immediately.

And if your backend is Python (FastAPI, Flask, Django) while your frontend shows "Failed to fetch", the cause is almost always missing CORS middleware on the Python side. Python itself never produces this error; its client-side equivalent is requests.exceptions.ConnectionError.

"Failed to fetch dynamically imported module"

A close relative, and it usually shows up right after a site ships an update.

Modern web apps split their code into chunks and pull each one in with import() when you open the part that needs it. If that download fails, the import rejects with a TypeError, worded differently per browser:

The usual cause is a stale page after a deploy. Chunk filenames change with every build, and a host may delete the previous deployment's assets when the new one goes live, as Vite's documentation notes. A tab opened before the deploy, or a cached HTML page, still points at the old filenames, gets a 404, and the import fails.

The other causes:

• Wrong base path. The app lives under a subfolder, but the build still assumes / (Vite's default base), so every chunk URL points at the wrong place.
• Wrong MIME type. The server answers the missing chunk with index.html as a fallback, and browsers refuse a module not served as JavaScript. The console says "non-JavaScript MIME type".
• Network or an extension, exactly as in fix 9.

If you're just using the site: hard refresh with Ctrl+Shift+R (Cmd+Shift+R on Mac). That loads fresh HTML pointing at the current chunks.

If it's your app:

• Serve the HTML with Cache-Control: no-cache, so browsers don't keep a copy that references deleted chunks.
• If your host allows it, keep the previous deploy's assets online for a while, so open tabs can still load them.
• Reload automatically when a chunk fails, using Vite's vite:preloadError event (code below).
• Check that base in your Vite config matches the path the app is served from.

window.addEventListener('vite:preloadError', (event) => {
  window.location.reload()
})

Failed to fetch in AI agents: n8n, MCP, OpenClaw and Ollama

This error has quietly become one of the most common failures in AI agent setups, and the causes repeat.

Ollama

It listens on port 11434, and only on your own machine by default. Three situations produce the error: Ollama isn't running (ollama serve), you're connecting from another machine or a container (set OLLAMA_HOST=0.0.0.0), or a browser frontend calls it directly and hits CORS (OLLAMA_ORIGINS). Be careful with the second one: Ollama's API has no authentication, so binding to all interfaces exposes it to everyone on your network. Never put that port on the open internet. The Ollama connection refused and timeout fixes cover the variants, and Ollama connection refused on Windows covers the Windows-only causes.

n8n in Docker

Fix 12: call host.docker.internal, not localhost, from inside a container. This is the nastiest one. If n8n runs in a container and you configure Ollama as http://localhost:11434, that localhost is the container itself, not your machine. Use http://host.docker.internal:11434 instead, adding --add-host=host.docker.internal:host-gateway on Linux.

MCP servers

Same rules, new wrapper. A remote MCP server called from a browser-based client needs CORS headers like any other endpoint (fix 6), and an MCP server on localhost is unreachable from a hosted client for the reason above. If tools connect but misbehave rather than failing outright, see our guide to MCP server tools rejected in n8n.

OpenClaw

"fetch failed" here almost always points at the model endpoint, usually an Ollama that isn't reachable. Every variant is in OpenClaw Ollama fetch failed, and if the message mentions DNS, OpenClaw DNS lookup failed is the one you want.

The common thread across all four: self-hosted agents fail at the network layer far more often than at the model layer. That's the part few people mention when you decide to run your own stack.

Still stuck?

Paste the exact message into our OpenClaw fetch failed decoder, which maps the common variants to their causes, or search every agent error in the Agent Error Decoder.

And keep one idea from this page if you keep nothing else: "Failed to fetch" is a symptom, not a diagnosis. It's the browser saying "I heard nothing back" without knowing why. The real answer is one line up in the console, or one curl away in your terminal.

For everyone who arrived here without writing any code: if it worked in another window, on another network or on another device, you didn't break it.

Frequently Asked Questions

What does "Failed to fetch" mean?

It means a browser or app sent a request to a server and never got a usable reply. It is not an HTTP error like 404 or 500, because in those cases the server did answer. For people using an app, the usual causes are an extension, a VPN, the network or the service being down. In your own code, it is most often CORS, a wrong URL or port, or an HTTPS page calling an HTTP address.

Is "Failed to fetch" a problem with my internet?

Sometimes, but less often than people expect. An extension, a VPN, a wrong address, CORS or the service being down are all more common causes. Switch between Wi-Fi and mobile data and try a private window. If the error appears on every network and in every browser, your connection is fine and the problem is on the side of the service you are using.

How do I fix "Failed to fetch" in Chrome?

Hard reload with Ctrl+Shift+R (Cmd+Shift+R on Mac), then open an Incognito window to rule out extensions. If it still fails, turn off any VPN or proxy and switch networks. If you wrote the page, press F12 and read the console line next to the error, because Chrome prints the real reason there, such as a CORS block or mixed content.

What is "TypeError: Failed to fetch"?

It is the error the browser's fetch() function throws when a request fails before any response reaches your code. Chrome and Edge word it "TypeError: Failed to fetch", Firefox says "NetworkError when attempting to fetch resource." and Safari says "Load failed". The browser hides the reason from your script on purpose, so the console line next to it is where you find the actual cause.

Is "fetch failed" the same as "Failed to fetch"?

No. "Failed to fetch" comes from a browser and is often caused by CORS. "fetch failed" comes from Node.js, which has no CORS, and means a network problem on the server side. In Node, log err.cause to see the real reason, such as ECONNREFUSED when nothing is listening on the port or ENOTFOUND when the hostname does not resolve.

What does "Connection error. Can't fetch server config." mean?

It is a popup from a browser VPN extension, not from a website. Users on Mozilla's support forum report it from the VeePN extension. The extension could not download the configuration it needs from its provider before connecting. Turn the extension off and on, disable other extensions for a moment, pick another server, update or reinstall it, or try another network, since some office and school networks block VPNs.

How do I fix "Failed to fetch" in n8n or OpenClaw?

In both, the usual cause is that the tool cannot reach the model server, most often Ollama on port 11434. Check that Ollama is running with ollama serve. If n8n or OpenClaw runs in Docker, localhost points at the container itself, so use http://host.docker.internal:11434 instead. If another machine connects, start Ollama with OLLAMA_HOST=0.0.0.0 and keep that port off the open internet.