¿Sitio caído? Cómo descubrir el motivo

Cuando un sitio se cae, la tentación es reiniciarlo todo y cruzar los dedos. A veces funciona, pero no aprendes nada y el problema vuelve. Es más rápido descubrir dónde se rompe la solicitud.

Una visita pasa por etapas en orden: el navegador resuelve el nombre en el DNS, abre una conexión segura con el certificado TLS, llega a un servidor o proxy y, por último, tu aplicación responde. Cada etapa falla de una forma reconocible. El error que aparece te dice en cuál está la falla.

¿El sitio se cayó de verdad o solo te pasa a ti?#

Antes de tocar el servidor, confirma el alcance. Tres pruebas de un minuto:

1. Abre el sitio con los datos móviles del celular, fuera del Wi-Fi.
2. Ejecuta un curl desde otra máquina o desde un servidor.
3. Pide a otra persona que lo abra.

Si carga en otro lugar, el problema es local: caché de DNS antigua, VPN, antivirus, una extensión del navegador o tu proveedor de internet. Limpia la caché con ipconfig /flushdns (Windows) o sudo resolvectl flush-caches (Linux con systemd).

Si falla en todas partes, el problema es del sitio. Pasa al siguiente paso.

¿Cómo leer el error que aparece?#

curl muestra mejor que el navegador en qué capa se detuvo la solicitud:

curl -sS -o /dev/null -w "%{http_code}\n" -v https://tusitio.com

¿El DNS está resolviendo el dominio?#

Pruébalo con:

nslookup tusitio.com
dig +short tusitio.com

Si no devuelve ninguna IP, revisa dos cosas. Primero, si el dominio expiró en el registrador: es la causa más simple y una de las más comunes. Después, si el registro A o CNAME todavía existe. Detalles en DNS_PROBE_FINISHED_NXDOMAIN y en propagación de DNS.

Si acabas de cambiar el DNS, el resultado puede variar durante un tiempo: distintos resolvedores guardan el valor antiguo hasta que termina el TTL.

¿Venció el certificado?#

Los certificados de Let's Encrypt tienen una validez corta, y la documentación oficial recomienda renovarlos mucho antes del vencimiento. En diciembre de 2025, Let's Encrypt anunció una reducción gradual de la validez por defecto, así que la renovación tiene que ser automática. Si la renovación automática falla en silencio (cron detenido, puerto 80 bloqueado, DNS cambiado), el sitio "se cae" con un aviso de certificado vencido.

echo | openssl s_client -connect tusitio.com:443 -servername tusitio.com 2>/dev/null | openssl x509 -noout -dates

La línea notAfter es la fecha de vencimiento. Mira más en errores de certificado SSL y en cómo funciona Let's Encrypt.

¿Qué significan 502, 503 y 504?#

Son los errores que más asustan, y todos apuntan a la aplicación que está detrás de un proxy inverso:

• 502 Bad Gateway: el proxy habló con la aplicación y recibió una respuesta inválida, por ejemplo porque el proceso se cayó durante la solicitud o no está escuchando donde el proxy espera.
• 503 Service Unavailable: el servidor no puede atender ahora, por sobrecarga o mantenimiento.
• 504 Gateway Timeout: el proxy no recibió respuesta de la aplicación a tiempo.

En los tres casos, ve al log de la aplicación. Busca falta de memoria (Killed, JavaScript heap out of memory, MemoryError), una excepción no controlada al iniciar o un puerto equivocado. Un servidor Node.js tiene que escuchar en el puerto y la dirección que espera el proxy:

import http from "node:http";

const port = Number(process.env.PORT) || 3000;
http
  .createServer((req, res) => res.end("ok"))
  .listen(port, "0.0.0.0", () => console.log(`escuchando en el puerto ${port}`));

Escuchar solo en 127.0.0.1 o en un puerto que el proxy no conoce genera un 502 aunque la aplicación esté "funcionando".

¿Y si es un error 500 o una página en blanco?#

Aquí el servidor está funcionando y tu código se rompió. Mira el log a la hora del error y compáralo con el último deploy. Causas frecuentes: una variable de entorno que existía en tu máquina y no existe en el servidor, una dependencia que no se instaló, la base de datos rechazando la conexión y un archivo que no se subió en el deploy. Si empezó justo después de publicar, vuelve primero a la versión anterior e investiga después.

¿Cómo evitar la próxima caída?#

• Activa la renovación automática del dominio y revisa el correo de contacto en el registrador.
• Usa un monitor externo que pruebe la URL cada pocos minutos y avise por correo, SMS o webhook.
• Guarda los logs y sigue la memoria y la CPU, para ver que te acercas al límite antes de alcanzarlo.
• Asegúrate de que la aplicación se reinicie sola cuando el proceso falle.
• Mantén un camino de rollback al deploy anterior.
• Si el sitio no necesita código en el servidor, considera un sitio estático: hay menos piezas que pueden romperse.

Cómo hacerlo en Square Cloud#

En Square Cloud, el sitio se ejecuta en un contenedor aislado, siempre encendido; con el reinicio automático activado (lo predeterminado en el deploy desde el panel), la aplicación que termina con error vuelve sola. Ves los logs en tiempo real en el panel, en la CLI y en VS Code. Las métricas de CPU, RAM y red, recogidas cada 5 minutos y guardadas durante 24 horas, muestran si la memoria se agotó antes de la caída. Quedarse sin memoria detiene la aplicación, que sigue parada hasta que subes su RAM y la inicias de nuevo.

Cada aplicación web recibe un subdominio *.squareweb.app con HTTPS, lo que ayuda a separar un problema de dominio de un problema de aplicación: si el subdominio abre y tu dominio no, el fallo está del lado del dominio (registros DNS o el propio dominio), no en la aplicación. En un dominio personalizado (a partir de Standard), el panel muestra el estado de validación de los registros DNS en tiempo real, y el TLS es automático.

La analítica web, incluida en todos los planes, muestra visitas, rutas y códigos de estado; Pro y Enterprise añaden logs HTTP. No hay alertas por correo, así que usa un monitor externo para enterarte.

Para empezar, mira la página de hosting de sitios; los detalles del monitoreo están en la página de analítica.