Error 1033 de Cloudflare Tunnel: causas y solución

Qué significa el error 1033 de Cloudflare Tunnel

El error 1033 de Cloudflare Tunnel significa que Cloudflare no encuentra un cloudflared sano para el nombre que pidió el visitante. Dicho de otra forma: el túnel de ese hostname no está conectado a la red de Cloudflare en este momento. Casi siempre la causa está en tu servidor o en tu DNS, no en Cloudflare.

Si has visto este error en la web de otra persona, no tienes nada que arreglar. Avisa al dueño del sitio: el fallo está entre su servidor y Cloudflare.

El resto de esta guía es para quien gestiona el túnel. El método es sencillo. Cloudflare ya te dice en qué estado está cada túnel, y cada estado tiene su arreglo. Primero lees el estado, después actúas. Si todavía no tienes un túnel montado, empieza por cómo publicar un servicio con Cloudflare Tunnel sin abrir puertos. Aquí no repetimos la instalación.

Paso 1: mira el estado que informa Cloudflare

Puedes verlo en dos sitios. En el panel de Cloudflare, ve a Networking > Tunnels. En el servidor, si allí iniciaste sesión con cloudflared, ejecuta:

cloudflared tunnel list

Busca en la lista el túnel que debería servir tu hostname y fíjate en su estado. Cloudflare usa cuatro: Healthy, Inactive, Down y Degraded. En la página del error 1033, el estado sano aparece también como Active, así que trata las dos palabras como la misma cosa. Puede que cloudflared tunnel list no funcione en ese servidor, por ejemplo porque el túnel se instaló solo con un token. En ese caso usa el panel, que da la misma información.

Un detalle importa antes de seguir. El estado que tienes que leer es el del túnel al que apunta tu DNS, no el del túnel que crees que está corriendo. Casi siempre son el mismo. Cuando no lo son, aparece el caso más confuso de esta guía. Tiene su propia sección más abajo.

Inactive: el conector nunca se ha conectado

Cloudflare define Inactive así: el túnel se creó (en el panel o con la API), pero el conector cloudflared no se ha ejecutado nunca. El túnel existe en tu cuenta y no tiene ningún servidor detrás.

Esto pasa cuando creas el túnel en el panel y no llegas a ejecutar en el servidor el comando de instalación que te muestra Cloudflare. También pasa cuando lo ejecutas en un servidor distinto del que pensabas.

La solución es instalar y ejecutar cloudflared en el servidor de origen. En el panel, entra en Networking > Tunnels, elige el túnel y, en la pestaña Overview, pulsa Add a replica. Cloudflare te mostrará el comando para tu sistema. Ejecútalo en el servidor y vuelve a mirar el estado.

Down: el servicio se paró, o nunca fue un servicio

Down significa que el túnel estuvo conectado y ahora no lo está, porque el proceso cloudflared se detuvo. Cloudflare recomienda comprobar que el servicio o el proceso sigue en marcha. También recomienda revisar si el servidor se apagó, si una aplicación falló o si cambió algo en la red.

En un VPS con systemd, empieza por el servicio. cloudflared es el nombre de servicio que usa la guía de Cloudflare para Linux:

sudo systemctl status cloudflared
sudo journalctl -u cloudflared -n 50 --no-pager

En systemctl status, la línea Active: te dice si el servicio corre, si falló o si no existe. Si systemd responde que no encuentra la unidad, no hay ningún servicio instalado. En el journal, busca las últimas líneas antes de que el proceso parara: un mensaje de nivel error, una configuración que no se puede leer o un archivo de credenciales que falta. Si el servicio falla una y otra vez y no entiendes el código de salida, consulta cómo leer los códigos de salida cuando una unidad de systemd no arranca.

Hay una causa de Down muy frecuente que no es un fallo. Quizá arrancaste el túnel a mano con cloudflared tunnel run dentro de una sesión SSH. Ese proceso termina con el siguiente reinicio del servidor. El túnel queda Down y nadie lo vuelve a levantar. Cloudflare explica que instalarlo como servicio permite que arranque con el sistema y siga corriendo mientras el origen está en línea. Por eso recomienda hacerlo así en la mayoría de los casos.

Para un túnel gestionado localmente, la guía de Cloudflare para Linux usa cloudflared service install. Por defecto, cloudflared busca la configuración en $HOME/.cloudflared/config.yml. Si usas sudo, la guía indica pasar la ruta de forma explícita:

sudo cloudflared --config /home/TU_USUARIO/.cloudflared/config.yml service install
sudo systemctl start cloudflared
sudo systemctl status cloudflared

Después comprueba que el servicio arrancará solo tras un reinicio:

systemctl is-enabled cloudflared

Si la respuesta no es enabled, actívalo con sudo systemctl enable cloudflared. Reinicia el servidor una vez a propósito y mira el estado del túnel en el panel. Así sabrás que sobrevive al próximo reinicio de verdad.

Degraded: algunas conexiones salientes fallan

Degraded significa que cloudflared está corriendo y el túnel sirve tráfico, pero al menos una de sus conexiones ha fallado. Un túnel sano mantiene cuatro conexiones con la red de Cloudflare. Degraded es un aviso: el túnel puede seguir funcionando y acabar en Down.

Cloudflare pide dos cosas en este caso. La primera es revisar los registros de cloudflared. La segunda es comprobar que la red local y el cortafuegos permiten las conexiones hacia Cloudflare Tunnel. Según la documentación de Cloudflare que consultamos el 28 de octubre de 2026, cloudflared sale hacia Cloudflare por el puerto 7844, y el cortafuegos debe permitir ese puerto en TCP y UDP. Comprueba el dato en la documentación actual antes de tocar reglas, porque puede cambiar.

Los dos protocolos se explican por el parámetro --protocol. Su valor por defecto es auto, que usa QUIC (sobre UDP) y vuelve a http2 (sobre TCP) si no consigue abrir conexiones UDP. Por eso un bloqueo de UDP no tumba el túnel del todo. Si el puerto 7844 está bloqueado en UDP y en TCP a la vez, Cloudflare lo dice claro: el túnel no puede funcionar.

En los registros, busca mensajes de nivel error y, en concreto, fallos del handshake QUIC sobre el puerto 7844. Cloudflare atribuye ese síntoma a una red o un cortafuegos que bloquea el UDP saliente. En un túnel gestionado localmente puedes ver más detalle con --loglevel debug. En uno gestionado de forma remota, el registro se configura en los parámetros de ejecución del túnel.

Revisa el cortafuegos en las dos capas. Primero el del propio servidor. Si configuraste ufw con la política de salida en deny, abre el puerto:

sudo ufw allow out 7844/tcp
sudo ufw allow out 7844/udp

Después revisa el cortafuegos de red del proveedor. En muchos paneles es un control aparte, con sus propias reglas de salida. Para probar la salida TCP desde el servidor puedes usar uno de los nombres regionales por defecto de Cloudflare:

nc -vz -w 5 region1.v2.argotunnel.com 7844

Si la conexión se abre, el TCP sale. Si se queda esperando hasta el tiempo límite, algo lo bloquea por el camino. UDP no se puede probar así de forma fiable, así que para UDP confía en los registros de cloudflared. Tienes más formas de probar puertos en cómo comprobar si un puerto está abierto en Linux. Si tu cortafuegos filtra por SNI, la documentación de Cloudflare lista otros nombres que también debes permitir en el puerto 7844.

El túnel sale Healthy y el hostname sigue dando 1033

Este es el caso que más tiempo hace perder. El panel dice que el túnel está sano, con sus cuatro conexiones, y el navegador sigue mostrando el 1033.

Para entenderlo hay que saber cómo llega un nombre al túnel. Cuando creas un túnel, Cloudflare le genera un subdominio <UUID>.cfargotunnel.com. Tu hostname llega al túnel mediante un registro CNAME que apunta a ese subdominio. El registro DNS y el túnel son piezas independientes. Un CNAME puede apuntar a un túnel que no está corriendo, mientras el túnel sano es otro.

La página de Cloudflare sobre el 1033 da una sola indicación para este caso: comprueba que el registro DNS apunta al subdominio del túnel correcto. La explicación más probable es esta. Recreaste el túnel, y un túnel nuevo tiene un UUID nuevo. El CNAME sigue apuntando al UUID del túnel anterior, que ya no tiene conector. El túnel nuevo está sano, pero nadie le envía tráfico.

Cómo comprobarlo:

1. Anota el UUID del túnel que quieres usar. En un túnel gestionado localmente es el valor de tunnel: en tu config.yml. En uno gestionado de forma remota, búscalo en la ficha del túnel en Networking > Tunnels.
2. En el panel de Cloudflare, abre la zona DNS de tu dominio y busca el registro de tu hostname.
3. Compara su destino con <UUID>.cfargotunnel.com. Si el UUID no coincide, esa es la causa del 1033.

Para corregirlo, edita el registro en el panel y pon como destino <UUID>.cfargotunnel.com con el UUID correcto. En un túnel gestionado localmente también puedes crear la ruta desde la línea de comandos:

cloudflared tunnel route dns MI_TUNEL app.ejemplo.com

Si el comando se queja de que ya existe un registro con ese nombre, cambia o borra el antiguo en el panel y repite. Si tu ordenador sigue viendo el resultado antiguo después del cambio, vacía la caché DNS en Ubuntu antes de volver a probar.

Una nota para cuentas FedRAMP High: allí el CNAME debe apuntar a <UUID>.fed-cfargotunnel.com. Cloudflare avisa de que el destino estándar cfargotunnel.com devuelve 1033 en esas cuentas aunque el túnel esté sano. En una cuenta normal esto no te afecta.

Remotely-managed o locally-managed: arrancar el túnel equivocado

Cloudflare distingue dos tipos de túnel. Mezclarlos es la otra forma de acabar con un túnel sano que no es el que usa tu DNS.

Un túnel remotely-managed (gestionado de forma remota) se crea en el panel, en Networking > Tunnels, y su configuración vive en Cloudflare. Se ejecuta con un token: cloudflared tunnel run --token <TUNNEL_TOKEN>, o con la variable de entorno TUNNEL_TOKEN. El parámetro --token es solo para este tipo.

Un túnel locally-managed (gestionado localmente) se crea con cloudflared tunnel create <NAME>, que genera un UUID y un archivo de credenciales. Su configuración vive en tu directorio .cloudflared, en config.yml, con la línea tunnel: y la ruta credentials-file. Los parámetros config y origincert son solo para este tipo.

Así se rompe. Empiezas con un túnel creado en el panel y su token. Más tarde sigues un tutorial con config.yml y creas un túnel local con otro nombre y otro UUID. Ahora el servicio arranca uno de los dos, y el CNAME apunta al otro. cloudflared tunnel list enseña un túnel Healthy, pero no es el que importa. Hay otro síntoma del mismo error: editas las reglas de config.yml y nada cambia. La razón es que el proceso en marcha es un túnel remoto, y su configuración está en Cloudflare.

Para saber qué arranca tu servicio, mira cómo se lanza:

systemctl cat cloudflared

Busca la línea ExecStart. Si lleva --token, el servicio ejecuta un túnel gestionado de forma remota. Si lleva --config o una ruta a config.yml, ejecuta uno local. En ese caso, abre el archivo y lee su línea tunnel:. Ese UUID tiene que coincidir con el destino del CNAME. Elige un solo modo por hostname y borra lo que sobre. Así la próxima vez no habrá dos candidatos.

Esto no es un error 1033

Varios fallos se confunden con el 1033. Distinguirlos te ahorra horas.

• La web no carga desde España en días de partido. Tu sitio deja de responder solo desde conexiones españolas, por ejemplo durante los partidos de LaLiga. El navegador muestra un error de tiempo de espera como ERR_CONNECTION_TIMED_OUT y no aparece ninguna página de Cloudflare. Eso no es un 1033. El síntoma apunta a un bloqueo de direcciones IP en la red del operador, y no se arregla tocando el túnel. El 1033 es una respuesta de Cloudflare que puede llegar como HTML, JSON o Markdown según la cabecera Accept; el contenido de error personalizado puede sustituir la respuesta predeterminada.
• Error 502 o 504. Un 502 o 504 genérico no demuestra que el túnel esté conectado: también hay errores de origen y de Cloudflare con esos códigos. Si el 502 va acompañado de Unable to reach the origin service, el túnel sí está conectado a Cloudflare. En ese caso, el problema está entre cloudflared y tu servicio local: cloudflared no consigue llegar al servicio de origen de la regla de ingress. Revisa que tu aplicación escucha en la dirección y el puerto que indica la regla. El estado Healthy no detecta este fallo, porque solo mide la conexión entre cloudflared y Cloudflare.
• El «error 1033» de MariaDB. En MariaDB, el error 1033 es ER_NOT_FORM_FILE, con el mensaje Incorrect information in file. No tiene nada que ver con Cloudflare: solo comparte el número. Para ese caso, consulta la documentación de códigos de error de MariaDB.

Resumen del proceso

Lee el estado del túnel al que apunta tu DNS. Inactive pide instalar y ejecutar el conector. Down pide revisar el servicio y dejarlo activado para que sobreviva a los reinicios. Degraded pide abrir la salida al puerto 7844 en TCP y UDP. Healthy con 1033 pide comparar el CNAME con el UUID del túnel que de verdad corre. En los cuatro casos, el panel o cloudflared tunnel list te dicen si el arreglo funcionó.

FAQ

¿Qué significa el error 1033 de Cloudflare?

Significa que Cloudflare no puede llegar a un cloudflared sano para el hostname que pidió el visitante. Es decir, el túnel de ese nombre no está conectado a la red de Cloudflare. Si eres un visitante, no tienes nada que arreglar: avisa al dueño del sitio. Si eres el dueño, mira el estado del túnel en Networking > Tunnels o con cloudflared tunnel list.

¿Por qué mi túnel aparece como Down después de reiniciar el servidor?

Down significa que el proceso cloudflared se detuvo. Tras un reinicio, la causa típica es que lo arrancaste a mano y no como servicio, o que el servicio no está activado para arrancar con el sistema. Instálalo con cloudflared service install, comprueba systemctl is-enabled cloudflared y revisa journalctl -u cloudflared si sigue sin arrancar.

El túnel está Healthy pero sigo viendo el 1033. ¿Qué compruebo?

Comprueba que el CNAME de tu hostname apunta a <UUID>.cfargotunnel.com con el UUID del túnel que está corriendo. Si recreaste el túnel, o si tienes uno remoto y otro local, el registro DNS puede apuntar a un túnel sin conector. Corrige el destino en el panel DNS o con cloudflared tunnel route dns.

¿Qué puertos necesita cloudflared en el cortafuegos?

Según la documentación de Cloudflare a 28 de octubre de 2026, cloudflared sale hacia Cloudflare por el puerto 7844, y debes permitir TCP y UDP. Con el protocolo por defecto, auto, usa QUIC sobre UDP y vuelve a HTTP/2 sobre TCP si UDP falla. Si los dos están bloqueados, el túnel no puede funcionar.