nTools

¿Está caído un sitio web o solo te pasa a ti? Cómo comprobarlo paso a paso

Actualizado:

Cuando un sitio no abre, la primera pregunta es si está caído para todos o solo para ti. La segunda, dónde falla. Entre escribir un nombre y ver una página, el navegador atraviesa cuatro capas: el registro del dominio, el DNS, la conexión con la dirección IP del servidor y el servidor web. Cada una falla a su manera y muestra su propio error, así que comprobarlas en orden suele dar con la causa en pocos minutos.

De un nombre a una página

  1. El dominio está registrado. Un registro, como el de .com o el de .pt, anota el nombre, su registrador y qué servidores de nombres responden por él.
  2. El DNS convierte el nombre en una dirección. Tu dispositivo pregunta a un resolvedor DNS, que localiza los servidores de nombres del dominio y obtiene su dirección IPv4 (un registro A) o IPv6 (un registro AAAA).
  3. El navegador se conecta a esa dirección. Abre una conexión con el servidor y, si es https, comprueba el certificado de seguridad del servidor.
  4. El servidor web responde. Devuelve la página con un código de estado HTTP de tres dígitos: 200 cuando todo va bien, o un error como 404 o 503.

Tu propio dispositivo está delante de las cuatro: su caché DNS, su red, una VPN o una extensión del navegador pueden cortar el camino aunque todas las capas del lado del sitio funcionen.

Qué capa está fallando

CapaQué fallaLo que sueles ver en Chrome
Registro del dominioEl dominio caducó, el registro o el registrador lo suspendieron, o se eliminóDNS_PROBE_FINISHED_NXDOMAIN, o una página del registrador que dice que el dominio ha caducado
DNSEl nombre no tiene ningún registro ni ninguna dirección, o sus servidores de nombres no respondenDNS_PROBE_FINISHED_NXDOMAIN o ERR_NAME_NOT_RESOLVED
Dirección IP y conexiónEl servidor está apagado, un cortafuegos descarta el tráfico o la ruta de red está cortadaERR_CONNECTION_TIMED_OUT o ERR_CONNECTION_REFUSED
Certificado de seguridadEl certificado ha caducado o no coincide con el nombreNET::ERR_CERT_DATE_INVALID o NET::ERR_CERT_COMMON_NAME_INVALID
Servidor webEl servidor está en marcha, pero no puede servir páginasUna página de error con un código como 500, 502 o 503, o ERR_TOO_MANY_REDIRECTS

Paso 1: compruébalo desde otro lugar

Empieza por comprobar el sitio desde fuera de tu propia conexión. Si allí también está caído, está caído para todos y el fallo está del lado del sitio. Si allí funciona pero a ti no, el problema está en algún punto entre tu dispositivo y el sitio, y lo que debes probar son los pasos que vienen más abajo.

Nuestro comprobador de estado lo hace desde un centro de datos de Cloudflare y desde sondas en seis regiones del mundo, y examina el dominio, el DNS y el servidor web de una sola vez. También puedes probar con el móvil usando datos móviles en lugar de la Wi-Fi: usa otra red y, normalmente, otros servidores DNS.

¿Está caída la web?

Paso 2: el registro del dominio

Un dominio se alquila, no se compra, y, cuando no se renueva, el sitio desaparece aunque el servidor funcione perfectamente. Los datos públicos de registro, disponibles a través de RDAP (el sucesor de WHOIS), muestran la fecha de caducidad y los códigos de estado del dominio.

Algunos códigos de estado sacan el dominio del DNS. Con clientHold, que pone el registrador, o serverHold, que pone el registro, el dominio no se publica en el DNS y no se resuelve. Lo mismo ocurre con inactive, que significa que no hay servidores de nombres configurados. Estados como clientTransferProhibited son bloqueos normales contra transferencias no deseadas y no afectan al sitio.

En los dominios genéricos como .com, .org o .net, la Expired Registration Recovery Policy (política de recuperación de registros caducados) de ICANN establece qué ocurre tras la caducidad. El registrador debe interrumpir el DNS del dominio durante, al menos, los últimos ocho días consecutivos en que el titular todavía puede renovarlo, y cualquier página que muestre en su lugar debe indicar claramente que el dominio ha caducado y cómo renovarlo. Si después se elimina el dominio, entra en un Redemption Grace Period (periodo de gracia de redención) de 30 días con el DNS desactivado, seguido de 5 días en pendingDelete, tras los cuales cualquiera puede registrarlo. Los dominios de código de país, como .pt, .br o .de, siguen las normas de su propio registro.

Consulta WHOIS / RDAP

Paso 3: el DNS

Si el dominio está activo, comprueba que su nombre se resuelve. Una respuesta NXDOMAIN significa que el nombre no existe en absoluto en el DNS. Una respuesta sin registro A ni AAAA significa que el nombre existe, pero no apunta a ninguna dirección, lo que suele ser un error de configuración, por ejemplo tras cambiar de proveedor de alojamiento.

Las respuestas DNS se guardan en caché durante el tiempo que indica el TTL del registro. Por eso un cambio puede tardar minutos u horas en llegar a todos, y por eso, durante ese tiempo, un sitio puede funcionar para una persona y fallar para otra. Las respuestas negativas también se guardan en caché: si a tu resolvedor le dijeron que el nombre no existía, puede seguir repitiéndolo durante un tiempo después de que se solucione el problema.

En tu propio dispositivo puedes borrar la caché DNS: en Windows, con ipconfig /flushdns; en macOS, con sudo killall -HUP mDNSResponder. Chrome también tiene su propia caché, que puedes borrar en chrome://net-internals/#dns. Cambiar a otro resolvedor público, como 1.1.1.1 u 8.8.8.8, es una forma rápida de descartar el DNS de tu proveedor.

Consulta DNS

Paso 4: la dirección IP y la conexión

Con una dirección en la mano, el navegador tiene que llegar a ella. Una conexión que agota el tiempo de espera suele significar que el servidor está apagado, sobrecargado o detrás de un cortafuegos que descarta el tráfico. Una conexión rechazada significa que algo respondió en esa dirección, pero ningún servidor web está escuchando.

Muchos sitios tienen una dirección IPv4 y otra IPv6. Los navegadores prueban ambas y usan la que conecte primero, así que una configuración IPv6 averiada en cualquiera de los dos lados suele pasar desapercibida, pero no siempre: un sitio puede funcionar en una red y fallar en otra porque solo uno de los dos caminos está roto.

Algunos bloqueos dependen de dónde estés. Un sitio puede rechazar a los visitantes de ciertos países, un proveedor puede bloquear un sitio por ley y la red de una empresa puede filtrarlo. Probar otra red, o comparar con una comprobación hecha desde otro lugar, permite distinguir estos casos de una caída real.

¿Cuál es mi IP?

Paso 5: el servidor web

Cuando la conexión funciona, el código de estado HTTP del servidor indica qué ha pasado. Los códigos del 200 al 299 significan éxito, y los del 300 al 399, una redirección. Los códigos del 400 al 499 significan que el servidor funciona, pero rechazó lo que se le pidió o no lo encontró, y los del 500 al 599, que el propio servidor tiene un problema. Los sitios que están detrás de Cloudflare también pueden mostrar códigos propios de Cloudflare, como 521 o 522, cuando el servidor que hay detrás no responde.

La siguiente guía de esta serie explica los códigos habituales uno por uno, con lo que significa cada uno para un visitante y para el propietario del sitio.

Cuando un sitio que funciona parece caído

Los comprobadores automáticos, incluido el nuestro, no siempre ven lo mismo que una persona. Estos casos hacen que un sitio que funciona parezca caído para un comprobador, o solo para algunas personas:

También ocurre lo contrario: un sitio puede parecer que funciona cuando no es así. Una red de distribución de contenidos puede seguir sirviendo páginas en caché mientras el servidor que tiene detrás está caído, y un dominio caducado puede mostrar una página de aparcamiento del registrador que responde con normalidad. Por eso nuestro comprobador muestra el título de la página junto al resultado: «Dominio caducado» o «En mantenimiento» con un código 200 no es el sitio real.

Si el sitio es tuyo

  1. Comprueba el dominio: que esté renovado, que no tenga ningún estado de retención (hold) y que apunte a los servidores de nombres correctos.
  2. Comprueba el DNS: que los registros A y AAAA contengan las direcciones actuales de tu servidor. Si los cambiaste hace poco, ten en cuenta el TTL.
  3. Consulta la página de estado de tu proveedor de alojamiento y comprueba que el servidor y el servicio web estén en marcha.
  4. Comprueba la fecha de caducidad del certificado y que cubra todos los nombres que usas, con y sin www.
  5. Lee el registro de errores del servidor a la hora del fallo: los códigos 5xx casi siempre dejan rastro ahí.

Preguntas frecuentes

¿Cómo sé si un sitio está caído para todos?

Compruébalo desde otra red o con un comprobador en línea. Si allí también falla, está caído para todos. Si allí funciona, el problema está de tu lado: tu caché DNS, tu red, tu VPN o tu navegador.

¿Por qué un sitio funciona en mi móvil pero no en mi ordenador?

Con datos móviles, el teléfono usa otra red y, normalmente, otros servidores DNS. Puede que el ordenador tenga en caché una respuesta DNS antigua, use otro resolvedor o tenga por medio una VPN, un cortafuegos o una extensión.

¿Cuánto tarda un cambio de DNS en llegar a todos?

Hasta el TTL del registro antiguo, que a menudo va de unos minutos a un día. Los resolvedores que guardaron en caché la respuesta antigua siguen usándola hasta que caduca.

¿Un dominio caducado deja de funcionar de inmediato?

No siempre. En los dominios genéricos, el registrador debe interrumpir el DNS durante, al menos, los últimos ocho días en que el dominio aún puede renovarse, pero el día exacto depende del registrador. Una vez eliminado, el dominio deja de resolverse durante el periodo de redención de 30 días.

Siguiente en la serie Códigos de estado HTTP y errores de Cloudflare: qué significan 403, 404, 429, 500, 503 y 521 →

Referencias

  1. ICANN — EPP Status Codes: What Do They Mean, and Why Should I Know?
  2. ICANN — Expired Registration Recovery Policy
  3. ICANN — FAQs for Registrants: Domain Name Renewals and Expiration
  4. RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE) (March 1998)
  5. RFC 9083 — JSON Responses for the Registration Data Access Protocol (RDAP) (June 2021)

Guías relacionadas