Failed to Fetch: qué significa y las 12 soluciones que funcionan

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

"Failed to fetch" significa que tu navegador envió una petición y no recibió nada utilizable. Casi siempre es una de cinco cosas: CORS, una URL o un puerto incorrectos (o un servidor caído), una petición bloqueada (bloqueador de anuncios, VPN, firewall), contenido mixto o una petición cortada antes de terminar. Empieza por la comprobación rápida de abajo y luego salta a tu caso.

¿Qué significa "Failed to Fetch"?

"Failed to fetch" significa que tu navegador, app o programa intentó conectarse a un servidor y no recibió respuesta. No es un virus. Casi nunca es un problema de tu internet. Es un fallo de conexión entre dos sistemas.

Y aquí está el detalle que casi todo el mundo pasa por alto. Un 404 no lanza este error. Un 500 tampoco. Cuando el servidor responde, aunque responda mal, fetch() cumple su promesa sin problema y te deja un objeto Response con ok: false. El error que estás viendo es distinto: el navegador ni siquiera pudo entregar la petición, o se negó a dejarte leer la respuesta.

fetch() devuelve una promesa. Esa promesa se rechaza con un TypeError únicamente en dos situaciones: cuando la petición no pudo salir o llegar, y cuando el navegador bloqueó tu acceso a la respuesta por política de seguridad. Todo lo demás, cualquier código de estado entre 200 y 599, se resuelve correctamente.

Por eso este código te engaña:

const res = await fetch(url);
const data = await res.json(); // esto sí revienta con un 404

Si esperabas que fetch lanzara una excepción con un 404, no lo hace. Comprueba siempre res.ok antes de parsear.

Failed to fetch no es un error de tu backend. Es un error de que tu backend nunca se enteró.

Hay varias situaciones distintas. Elige la tuya:

→ Me sale en una app o página web (Instagram, ChatGPT, una tienda online, un juego, una app de banco): soluciones 1 a 5.

→ Me sale en una extensión de VPN ("Can't fetch server config"): la sección de ese mensaje.

→ Me sale en mi propio código (JavaScript, Node.js, Python, un agente de IA): empieza por el diagnóstico rápido y sigue con las soluciones 6 a 10.

Diagnóstico rápido: la lista de la pestaña Network

Si el error está en tu código, la primera regla es esta: "Failed to fetch" nunca es el mensaje real. Abre la consola del navegador (F12) y lee la línea justo encima o debajo. Casi siempre dice el motivo verdadero; un bloqueo de CORS, por ejemplo, aparece ahí en rojo con el origen exacto que fue rechazado.

Después abre DevTools, ve a la pestaña Network, marca Preserve log y reproduce el error. Revisa esto:

• ¿Aparece la petición? Si ni siquiera aparece, se bloqueó antes de salir del navegador. Eso apunta a una extensión o a una regla de Content Security Policy, no a tu servidor.
• ¿Qué dice la columna Status? Una petición bloqueada por CORS suele mostrar "CORS error" o "(failed)" en lugar de un número. Un estado 0 significa que no llegó ninguna respuesta.
• ¿Hay una petición OPTIONS justo antes? Las peticiones no simples envían primero un preflight. Si el OPTIONS falló, la petición real nunca ocurrió, y la solución está en cómo responde el servidor al OPTIONS.
• Revisa las cabeceras de la respuesta. Busca access-control-allow-origin. Si falta, o nombra un origen que no es el tuyo, ahí tienes la respuesta.
• Atento a "Provisional headers are shown". Suele indicar que la petición se bloqueó o nunca terminó. Revisa extensiones y CSP.
• Lee la pestaña Console a la vez. Network te dice qué pasó; la consola suele decirte por qué.

Tabla de diagnóstico

Prueba para copiar y pegar: ¿es CORS o la red?

El navegador le oculta el motivo real a tu código, pero puedes obligarlo a delatarse. Pega esto en la Consola de DevTools, en la página que falla, con tu URL en la primera línea:

const url = 'https://api.example.com/data'; // la URL que falla

fetch(url)
  .then((r) => console.log('OK', r.status))
  .catch(async (err) => {
    console.log('Fetch normal falló:', err.message);
    try {
      await fetch(url, { mode: 'no-cors' });
      console.log('El servidor responde: es un problema de CORS. Revisa Access-Control-Allow-Origin.');
    } catch {
      console.log('El servidor no responde: revisa la URL, el DNS, HTTPS/contenido mixto o una extensión.');
    }
  });

Una petición no-cors sí puede llegar al servidor aunque CORS bloquee la normal; simplemente no puedes leer la respuesta. Si la segunda pasa y la primera no, el servidor funciona y la solución es su cabecera Access-Control-Allow-Origin (solución 6). Si fallan las dos, revisa la URL, el DNS, HTTPS y el contenido mixto, o alguna extensión (soluciones 7 a 9). Pruébalo también en una ventana privada sin extensiones.

Soluciones 1 a 5: si te sale en una app o página web

No siempre estás depurando tu propio código. A veces el error aparece en ChatGPT, en OneDrive, en un formulario de pago, en una tienda online o en el panel de una herramienta que usas todos los días. Ahí no puedes tocar el servidor, pero sí puedes descartar tu lado en un minuto.

Prueba en este orden:

1. Recarga la página con Ctrl + Shift + R (Cmd + Shift + R en Mac). Fuerza al navegador a bajar todo de nuevo y salta la caché. Arregla más casos de los que parece.
2. Abre la misma página en una ventana de incógnito. Si ahí funciona, el culpable es una extensión: un bloqueador de anuncios, una VPN del navegador o una extensión de privacidad. Desactívalas una por una hasta encontrarla.
3. Desactiva la VPN, el proxy o la protección web del antivirus un minuto. Cualquier cosa entre tu navegador e internet puede tirar una petición sin avisar.
4. Cambia de red. Si estás en la wifi de la oficina o de la universidad, prueba con los datos del móvil. Los firewalls corporativos bloquean puertos y dominios sin avisar.
5. Comprueba si el servicio está caído. Busca la app en DownDetector, o su nombre junto con "status" o "down". Si el fallo es de ellos, no hay nada que hacer en tu lado más que esperar 10-15 minutos.

Si después de esto sigue fallando y solo te pasa a ti, actualiza la app si es de escritorio o móvil, y borra las cookies de ese sitio y vuelve a iniciar sesión (te cerrará la sesión en ese sitio, nada más). Si les pasa a todos, el problema está en su servidor y lo mejor que puedes hacer es reportarlo con una captura de la consola.

Un caso muy común: "failed to fetch payment methods"

Aparece en pasarelas de pago cuando el navegador bloquea la petición al proveedor (Stripe, PayPal, MercadoPago). Casi siempre es un bloqueador de anuncios que filtra dominios de terceros. Desactívalo para ese sitio o paga desde incógnito.

TypeError: Failed to fetch en Chrome, Firefox y Safari

Es el mismo error con nombres distintos. Si buscaste una de estas frases, estás en el sitio correcto. Aunque tu navegador esté en español, el mensaje suele salir en inglés.

El texto de Firefox está definido en el propio código fuente de Firefox como su mensaje de fallo de fetch, y el gestor público de errores de WebKit muestra a Safari informando del mismo fallo como "TypeError: Load failed". Los tres primeros significan lo mismo y tienen las mismas soluciones. El de Node.js se parece, pero es otro error y tiene su propia sección más abajo.

Connection error. Can't fetch server config.

Este mensaje no viene de una web ni de tu código. Es una ventana emergente de una extensión de VPN del navegador: usuarios del foro de soporte de Mozilla lo reportan con la extensión VeePN en Firefox, donde aparece una y otra vez mientras la extensión intenta conectar. El "server config" es la configuración de la propia extensión, que tiene que descargar de su proveedor antes de conectar, y esa descarga falló.

Qué ayuda, en este orden:

1. Desactiva la extensión y vuelve a activarla. Usuarios de ese hilo cuentan que, tras refrescar la extensión, a veces conectaba.
2. Desactiva un momento tus otras extensiones, por si alguna bloquea la descarga.
3. Elige otro servidor u otro país en la extensión.
4. Actualiza la extensión, o desinstálala y vuelve a instalarla.
5. Prueba otra red. Algunas redes de oficina y de universidad bloquean las VPN.

Si nada de esto funciona, escribe al soporte del proveedor de la VPN. El mensaje sale de su extensión y solo ellos pueden ver por qué su servidor de configuración no respondió.

Soluciones 6 a 10: las 5 causas en tu propio código

Ordenadas por frecuencia real, no por orden alfabético.

Solución 6: CORS, el sospechoso número uno

Si tu petición sale de un origen y va hacia otro, el navegador exige permiso explícito del servidor. Sin la cabecera Access-Control-Allow-Origin correcta, el navegador descarta la respuesta y tú recibes Failed to fetch.

Lo confuso es que la petición sí llegó al servidor. Puedes verla en tus logs. El bloqueo ocurre después, en el navegador.

Cómo confirmarlo: abre la consola, no la pestaña de red. El mensaje de CORS aparece ahí, en rojo, con el origen exacto que fue rechazado. El TypeError es solo el eco.

La solución está en el servidor, siempre. Añade el origen a Access-Control-Allow-Origin, y si tu petición usa métodos distintos de GET o cabeceras personalizadas, asegúrate de responder también al preflight OPTIONS. Poner mode: "no-cors" en el cliente no arregla nada, solo te devuelve una respuesta opaca que no puedes leer.

Solución 7: La URL, el puerto o el DNS

Menos glamuroso, igual de frecuente.

Un localhost:3000 cuando el servidor escucha en el 3001. Una variable de entorno vacía que deja la URL como undefined/api/users. Un dominio mal escrito. Un servicio que se cayó hace veinte minutos.

Prueba el mismo endpoint desde la terminal con curl. Si curl también falla, el problema no está en tu JavaScript: corrige el host, el puerto o la variable de entorno, o levanta el servicio que se cayó.

Solución 8: Contenido mixto

Tu página se sirve por HTTPS y tu petición apunta a http://. Los navegadores modernos bloquean eso sin preguntar.

Suele aparecer al pasar de desarrollo local a un entorno desplegado, y sorprende porque en local todo funcionaba.

La solución es servir el endpoint por HTTPS. Un certificado autofirmado en tu API tiene el mismo efecto: el navegador rechaza la conexión y tú ves Failed to fetch sin más pistas.

Solución 9: Algo entre tu navegador y la red

Un bloqueador de anuncios que filtra por URL. Una extensión de privacidad. Una VPN corporativa. Un firewall que no deja salir ese puerto. Una Content Security Policy cuyo connect-src no incluye el host al que llamas.

Esta causa tiene una señal muy clara: funciona en ventana de incógnito con las extensiones desactivadas, o funciona en otro navegador, o funciona desde otra red.

Si tu URL contiene palabras como ads, track, analytics o pixel, un bloqueador la va a matar aunque tu endpoint sea completamente legítimo. La solución: renombra esa ruta, desactiva la extensión para ese sitio, o añade el host al connect-src de tu Content Security Policy.

Solución 10: La petición se interrumpió antes de terminar

Aquí hay que hilar fino, porque casi toda la web repite un dato falso.

Un AbortController no produce Failed to fetch. Cuando llamas a abort(), la promesa de fetch() se rechaza con un DOMException cuyo name es AbortError, no con un TypeError. Si le pasas un motivo, abort(motivo), se rechaza con ese valor. Y un timeout hecho con AbortSignal.timeout() se rechaza con otro DOMException distinto, de nombre TimeoutError.

Así que el componente de React que se desmonta y cancela la petición en el cleanup del useEffect te va a dar AbortError. Eso es una buena noticia: el error viene etiquetado, y distinguirlo es trivial.

try {
  const res = await fetch(url, { signal });
} catch (e) {
  if (e.name === 'AbortError') return;      // cancelación deliberada
  if (e.name === 'TimeoutError') return;    // AbortSignal.timeout()
  // aquí sí: TypeError "Failed to fetch"
}

Lo que sí produce Failed to fetch es que el navegador tire la conexión por su cuenta, sin que tu código cancele nada: el usuario recarga o navega a otra página a mitad de la llamada, cierra la pestaña, o el dispositivo pierde la red. En esos casos no hay AbortError que te avise, porque no hubo un abort(). Solo el TypeError genérico.

La solución: espera a que el fetch termine (await) antes de redirigir o recargar, y separa AbortError y TimeoutError del TypeError como en el código de arriba.

Cuándo es un problema de red y cuándo es de código

Tres comprobaciones, en este orden, y en menos de dos minutos sabes de qué lado está el problema.

1. curl desde la terminal. Si falla, es red, servidor o URL, y no es tu JavaScript (solución 7).
2. Si curl funciona pero el navegador no, es casi con total seguridad CORS o contenido mixto (soluciones 6 y 8). El navegador aplica reglas que curl ignora.
3. Incógnito sin extensiones. Si ahí funciona, tienes un bloqueador o una extensión interfiriendo (solución 9).

El mismo error en Node.js: "fetch failed" no es "failed to fetch"

Aquí es donde mucha gente se pierde, sobre todo si trabaja con agentes de IA o servicios en el servidor.

En Node.js el mensaje es ligeramente distinto: TypeError: fetch failed. Y en Node no hay CORS, así que puedes descartar la causa número uno de inmediato.

Solución 11: imprime error.cause y prueba 127.0.0.1 en lugar de localhost.

catch (e) { console.error(e.cause); }

Ahí verás lo que de verdad pasó: ECONNREFUSED si nada escucha en ese puerto, ENOTFOUND si el DNS no resuelve, o un error de certificado si el TLS falló. Esa propiedad convierte un error genérico en un diagnóstico exacto.

Una trampa clásica: en algunas versiones de Node, localhost se resuelve primero a la dirección IPv6 ::1. Si tu servidor solo escucha en 127.0.0.1, la conexión se rechaza. Cambiar localhost por 127.0.0.1 lo arregla al momento.

Este es exactamente el caso que aparece cuando un agente local intenta hablar con Ollama y el servicio no está levantado. Lo explicamos a fondo en nuestra guía sobre el error fetch failed con Ollama, que cubre la configuración de host y puerto que casi siempre es la culpable.

Failed to fetch en agentes de IA: n8n, MCP, OpenClaw y Ollama

Si el error te sale en un agente o una automatización, la causa casi siempre es una de estas.

OpenClaw y Ollama. El agente intenta hablar con Ollama en localhost:11434 y nadie responde: Ollama no está arrancado, escucha en otro host o puerto, o el agente corre dentro de Docker, donde localhost apunta al propio contenedor y no a tu máquina. Lo explicamos paso a paso en la guía del error fetch failed con Ollama. En Windows, mira también nuestra guía en inglés de Ollama "Connection refused" en Windows. Si aún estás eligiendo qué modelo correr, aquí tienes los mejores modelos gratis para OpenClaw, probados y ordenados.

n8n (solución 12). Si n8n corre en Docker y Ollama (o cualquier API local) en tu máquina, localhost no funciona desde el contenedor. En la credencial de Ollama usa http://host.docker.internal:11434, y en Linux añade --add-host=host.docker.internal:host-gateway al arrancar el contenedor. Tienes todas las URLs correctas por entorno en nuestra guía de fetch failed y connection refused en Ollama. Y si Docker Desktop con WSL 2 ni siquiera arranca en Windows, primero tienes que activar la Plataforma de máquina virtual.

MCP. Un cliente MCP que se conecta a un servidor remoto por HTTP devuelve fetch failed si la URL o el puerto del servidor están mal, o si el servidor no está levantado. Si el cliente corre en el navegador, como MCP Inspector, un servidor sin cabeceras CORS produce Failed to fetch aunque esté funcionando. Para ver qué llamada falla exactamente, consulta cómo depurar las llamadas a herramientas MCP, y si las herramientas conectan pero n8n las rechaza, nuestra guía en inglés de herramientas MCP rechazadas en n8n.

API key inválida. Muchas APIs responden a una key incorrecta con un 401 sin cabeceras CORS. En el navegador, ese 401 no se ve como 401: se ve como Failed to fetch. Si todo lo demás está bien, revisa la key y la página de status del proveedor.

Un último apunte antes de que vuelvas a tu consola

Failed to fetch tiene mala fama por ser vago, pero en realidad es honesto. Te está diciendo la única cosa que sabe con certeza: la petición no completó el viaje.

Lo que no te dice es por qué, y eso no es un defecto de la API. Es que el navegador, por diseño de seguridad, no te cuenta los detalles de una petición que bloqueó. Si lo hiciera, cualquier página podría sondear tu red interna.

Así que el mensaje seguirá siendo genérico. La habilidad no está en descifrarlo, está en saber qué comprobar primero.

Si quieres dejar de mantener este tipo de errores por tu cuenta, empieza gratis en BetterClaw. Un agente y 100 créditos al mes, sin tarjeta. El plan Pro cuesta 49 dólares al mes por cinco agentes, conectores ilimitados y 90 días de memoria, con un 20 por ciento de descuento en el plan anual. Precios completos aquí.

Preguntas frecuentes

¿Qué significa "failed to fetch" en español?

Literalmente, "error al obtener" o "no se pudo recuperar": fetch significa "traer" o "ir a buscar". El mensaje indica que la petición del navegador a un servidor no llegó a completarse, o que el navegador bloqueó la respuesta por seguridad. No es un 404 ni un 500, porque en esos casos el servidor sí respondió. Las causas típicas son CORS, una URL incorrecta, un servidor caído o una extensión.

¿"Failed to fetch" es un problema de mi internet?

A veces, pero menos de lo que parece. Una extensión, una VPN, una dirección incorrecta, CORS o un servicio caído son causas más frecuentes. Cambia entre wifi y datos móviles y prueba en una ventana de incógnito. Si el error aparece en todas las redes y en todos los navegadores, tu conexión está bien y el problema está del lado del servicio que usas.

¿Cómo soluciono "failed to fetch" en Chrome?

Recarga con Ctrl+Shift+R (Cmd+Shift+R en Mac) y luego abre una ventana de incógnito para descartar extensiones. Si sigue fallando, desactiva la VPN o el proxy y cambia de red. Si la página es tuya, pulsa F12 y lee la línea junto al error en la consola, porque Chrome muestra ahí el motivo real, como un bloqueo de CORS o contenido mixto.

¿Qué es "TypeError: Failed to fetch"?

Es el error que lanza la función fetch() del navegador cuando una petición falla antes de que llegue cualquier respuesta a tu código. Chrome y Edge lo escriben "TypeError: Failed to fetch", Firefox escribe "NetworkError when attempting to fetch resource." y Safari escribe "Load failed". El navegador oculta el motivo a tu script a propósito, así que la causa real está en la línea de al lado en la consola.

¿"fetch failed" es lo mismo que "failed to fetch"?

No. "Failed to fetch" sale del navegador y muchas veces es CORS. "fetch failed" sale de Node.js, donde no existe CORS, y significa un problema de red en el servidor. En Node, imprime error.cause para ver el motivo exacto, como ECONNREFUSED cuando nada escucha en ese puerto o ENOTFOUND cuando el nombre del host no se resuelve.

¿Qué significa "Connection error. Can't fetch server config."?

Es una ventana emergente de una extensión de VPN del navegador, no de una web. Usuarios del foro de soporte de Mozilla la reportan con la extensión VeePN. La extensión no pudo descargar de su proveedor la configuración que necesita antes de conectar. Desactívala y vuelve a activarla, apaga un momento las otras extensiones, elige otro servidor, actualízala o prueba otra red.

¿Cómo soluciono "failed to fetch" en n8n u OpenClaw?

En los dos, la causa habitual es que la herramienta no llega al servidor del modelo, casi siempre Ollama en el puerto 11434. Comprueba que Ollama está arrancado con ollama serve. Si n8n u OpenClaw corren en Docker, localhost apunta al propio contenedor, así que usa http://host.docker.internal:11434. Si se conecta otra máquina, arranca Ollama con OLLAMA_HOST=0.0.0.0 y nunca expongas ese puerto a internet.