Síntoma y contexto

Una web caída se manifiesta de muchas formas y cada una orienta el diagnóstico hacia un sitio distinto. A veces el navegador se queda cargando hasta mostrar un timeout. Otras veces aparece de inmediato un aviso de privacidad o certificado no válido. También es frecuente ver páginas de error con códigos como 502 Bad Gateway, 503 Service Unavailable, 521 Web Server Is Down o 525 SSL Handshake Failed, sobre todo cuando hay Cloudflare u otro CDN delante del servidor.

Antes de asumir que "el hosting se ha caído", conviene separar tres capas: el dominio y su DNS, el certificado y la capa de proxy si existe, y el servidor o plataforma que sirve los archivos. Un fallo en cualquiera de las tres puede hacer que la URL deje de funcionar aunque el resto esté sano. Pregúntate también si el problema lo ven todos los visitantes o solo tú: una caché local, una VPN o un DNS corporativo pueden mostrar un estado distinto al del resto del mundo.

Esta guía cubre sitios estáticos y dinámicos en hosting compartido, VPS, Cloudflare Pages, Vercel, Netlify, GitHub Pages y configuraciones con nginx o Apache detrás de un proxy. No sustituye el acceso al panel cuando el origen está apagado, pero sí te permite descartar causas habituales y reunir evidencia útil antes de escribir.

Causas probables

DNS que no resuelve o apunta al sitio equivocado. El dominio puede tener nameservers antiguos tras una migración, un registro A obsoleto, un CNAME mal puesto o propagación pendiente. Si el dominio expiró o está en hold en el registrador, tampoco resolverá aunque el hosting esté bien.
Certificado SSL caducado o emitido para otro dominio. Los certificados Let's Encrypt y comerciales tienen fecha de vencimiento. Si la renovación automática falló, o el certificado cubre www pero no el dominio raíz (o al revés), el navegador bloquea la conexión.
Proxy CDN mal configurado. Cloudflare en modo proxy (nube naranja) necesita un origen alcanzable con un certificado que el proxy acepte. Errores 521, 522, 523 y 525 suelen indicar que el origen no responde, tarda demasiado o presenta un certificado inválido al proxy.
Servidor de origen caído o proceso web detenido. El VPS puede estar encendido pero nginx, Apache o el runtime (Node, PHP-FPM) parado. En hosting compartido, una cuenta suspendida por facturación o por exceso de recursos deja la web fuera de línea.
Despliegue roto o directorio vacío. Un deploy que borró archivos, un build que no generó la carpeta pública, o un cambio en la ruta de publicación deja el servidor respondiendo pero sin contenido útil, a veces con 404 en todas las rutas.
Reglas de firewall o IP bloqueada. Si cambiaste de servidor y no actualizaste las reglas, o si el hosting bloquea el país o la IP desde la que pruebas, puedes ver timeout o 403 solo desde ciertas redes.
Redirecciones infinitas o configuración HTTPS forzada. Un bucle entre http y https, o entre www y el dominio raíz, puede impedir que la página cargue aunque el servidor esté activo.
Mantenimiento o caída del proveedor. Menos frecuente, pero conviene mirar la página de estado del hosting o del CDN antes de cambiar configuraciones a ciegas.

Checklist copiable

DIAGNÓSTICO WEB CAÍDA - [URL exacta]
Fecha: ___________  Hora (zona): ___________

1. SÍNTOMA (lo que ve el usuario)
   [ ] Timeout / no carga nunca
   [ ] Error SSL o "conexión no privada"
   [ ] Código HTTP visible: ___________
   [ ] Página en blanco
   [ ] Solo falla en móvil / solo en mi red

2. INFRAESTRUCTURA
   Hosting o plataforma: ___________
   [ ] Cloudflare delante   [ ] Sin proxy CDN
   DNS gestionado en: ___________

3. DNS (resultado de dig o captura panel)
   A / AAAA / CNAME: ___________
   Nameservers: ___________
   ¿Cambio DNS últimas 48 h?  [ ] Sí  [ ] No

4. SSL
   ¿Aviso de caducidad?  [ ] Sí  [ ] No
   Emisor / validez (si la ves): ___________

5. PRUEBAS
   [ ] curl -I a la URL (pegado abajo)
   [ ] Probado en otra red o 4G
   [ ] Probado sin VPN

   Salida curl:
   ___________

6. CAMBIOS RECIENTES
   [ ] Deploy nuevo   [ ] Cambio DNS   [ ] Renovación dominio
   [ ] Cambio de hosting   [ ] Ninguno conocido

7. NO ENVIAR
   [ ] Sin contraseñas de hosting
   [ ] Sin tokens en claro

Qué capturar antes de escribir

Lo mínimo útil es la URL exacta que falla, incluyendo si el problema afecta a https://tudominio.com, a https://www.tudominio.com o a ambas. Una captura de pantalla del error tal como la ve el navegador aporta contexto inmediato. Si puedes ejecutar una comprobación desde terminal, pega la salida de curl -I o al menos el código HTTP y los encabezados relevantes.

Indica el proveedor de hosting o plataforma (Cloudflare Pages, cPanel, OVH, Hetzner, etc.) y si hay Cloudflare u otro CDN activo. Si hubo un deploy o cambio DNS reciente, la hora aproximada ayuda a correlacionar. Si solo tú ves el fallo, menciona tu red, VPN y sistema operativo.

No hace falta compartir credenciales de hosting, claves SSH ni tokens de API. Con capturas del panel de DNS, del estado del certificado y del mensaje de error suele bastar para el primer diagnóstico remoto.

Comandos y paneles útiles

Comandos básicos desde terminal (sustituye la URL y el dominio):

# Cabeceras HTTP y código de respuesta
curl -I https://tudominio.com

# Seguir redirecciones y ver la cadena
curl -IL https://tudominio.com

# Resolución DNS
dig A tudominio.com +short
dig AAAA tudominio.com +short
dig NS tudominio.com +short

# Comprobar certificado (fecha de caducidad)
echo | openssl s_client -connect tudominio.com:443 -servername tudominio.com 2>/dev/null | openssl x509 -noout -dates -subject

Paneles donde mirar según el stack:

Cloudflare: DNS (estado proxy de cada registro), SSL/TLS (modo Flexible, Full o Strict), reglas de Page Rules o Redirect Rules, Analytics para códigos 5xx.
Hosting cPanel/Plesk: Estado del dominio, certificado SSL, logs de error de Apache/nginx, cuenta no suspendida.
Cloudflare Pages / Vercel / Netlify: Último deploy exitoso, dominio custom vinculado, build logs si la web no se generó.
Registrador del dominio: Fecha de expiración, nameservers activos, bloqueos por verificación de contacto.

Interpretar códigos frecuentes

502 / 504: El proxy o el servidor intermedio no obtuvo respuesta válida del origen a tiempo. Suele apuntar al backend caído o sobrecargado.
503: Servicio temporalmente no disponible: mantenimiento, proceso reiniciándose o límite de recursos.
521 (Cloudflare): El origen rechazó la conexión. El servidor puede estar apagado o el puerto cerrado.
525 / 526 (Cloudflare): Problema de handshake SSL entre Cloudflare y el origen. Revisa certificado en el servidor y modo SSL en el panel.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH: Configuración TLS antigua en el origen o certificado corrupto.

Pasos de diagnóstico por escenario

La web no resuelve (NXDOMAIN o DNS_PROBE_FINISHED_NXDOMAIN)

Comprueba que el dominio no ha expirado y que los nameservers coinciden con el proveedor donde gestionas el DNS. Si acabas de cambiar NS, espera propagación y prueba con un resolver público. Verifica que existe un registro A o AAAA para el dominio raíz, o un CNAME válido según las reglas del proveedor (en Cloudflare Pages, el CNAME debe apuntar al subdominio que te asigna la plataforma).

Error de certificado SSL

Mira la fecha de caducidad con openssl o el panel del hosting. Renueva si está vencido. Si el certificado es válido pero el navegador se queja, comprueba que accedes al mismo hostname que cubre el certificado. Con Cloudflare en modo Full (strict), el origen también necesita un certificado válido, no solo el edge de Cloudflare.

Cloudflare delante del origen

En el panel de Cloudflare, pausa temporalmente el proxy (nube gris) solo si sabes que el origen tiene IP fija y certificado correcto, para aislar si el fallo está en el CDN o en el servidor. Si al pausar el proxy la web carga directo por IP o por DNS sin proxy, el origen funciona y el problema es la configuración entre Cloudflare y el origen. Si tampoco carga sin proxy, el origen está caído o mal configurado.

La web cargaba y dejó de hacerlo tras un deploy

Revisa el historial de despliegues. Un build exitoso en verde no garantiza que el directorio de salida sea el correcto. Comprueba que el archivo de entrada (index.html o equivalente) existe en la ruta publicada. Si usas SPA, confirma reglas de rewrite para rutas que no sean la raíz.

Cuándo escalar

Sigue esta guía por tu cuenta si tienes acceso al DNS y al panel de hosting. Escala, o usa el formulario con categoría de web o despliegue, cuando:

DNS y SSL aparecen correctos en las pruebas pero la URL sigue sin responder desde varias redes y países.
Ves errores 521-526 con Cloudflare y no tienes acceso al servidor de origen para revisar el certificado o el servicio web.
El hosting muestra la cuenta activa pero no hay logs claros y el soporte del proveedor no responde con datos concretos.
Necesitas migrar el sitio a otro servidor sin cortar correo ni otros subdominios del mismo dominio.
Sospechas de bucle de redirecciones o regla en CDN que no localizas en el panel.
El fallo es intermitente y necesitas correlacionar logs de acceso con momentos concretos de caída.

En casos urgentes (tienda, landing de campaña activa), indica la prioridad en el mensaje y adjunta la checklist cumplimentada. Evita cambios simultáneos en DNS, hosting y código sin anotar cada paso: si algo empeora, necesitarás saber qué tocaste por último para revertir con rapidez.

¿Sigues atascado después de la checklist?

Escribir el problema Volver al triage