📡

Verificador de Estado Web

Un verificador de estado web envía una petición HTTP a una URL e informa del código de estado que devuelve el servidor. Los códigos 200–399 cuentan como activo; 400–599 o un tiempo de espera agotado cuentan como caído. Comprobar aquí https://example.com devuelve 200 OK en unas pocas decenas de milisegundos, así que el sitio nos responde a nosotros, no solo a ti.

Incrustar esta herramienta en tu sitio web

× px

                        

💡 Consejo de integración

Copie el código de incrustación y péguelo en el HTML de su sitio web. La versión responsive se adapta automáticamente a todos los tamaños de pantalla.

0 valoraciones
✓

Códigos de estado HTTP y lo que informa este verificador

Código Frase de motivo Veredicto aquí Qué significa para tu comprobación
200 OK Activo El servidor respondió con normalidad. No hay nada que arreglar.
301 Moved Permanently Activo Redirección permanente. Esta herramienta no la sigue, así que verás el 301 junto con la cabecera Location.
302 Found Activo Redirección temporal, a menudo hacia una página de mantenimiento, de inicio de sesión o de enrutamiento geográfico.
304 Not Modified Activo La copia en caché sigue siendo válida. Solo se devuelve cuando la petición incluye validadores.
403 Forbidden Caído El servidor respondió, así que el host es accesible y esto no es una caída. Un WAF, un filtro antibots o una lista de IP permitidas rechazó a este cliente; el veredicto sigue siendo Caído porque 403 es un código 4xx.
404 Not Found Caído El host respondió, así que es accesible: solo falta la ruta que pediste. Prueba a continuación el dominio a secas.
429 Too Many Requests Caído Límite de peticiones: demasiadas en poco tiempo. Si la respuesta incluye una cabecera Retry-After, espera hasta el momento que indique —un número de segundos o una fecha HTTP— antes de volver a probar.
500 Internal Server Error Caído La aplicación falló en el origen. Consulta el registro de errores del origen.
502 Bad Gateway Caído Un proxy o una CDN no pudo alcanzar el origen, a menudo durante un despliegue.
503 Service Unavailable Caído Sobrecarga o mantenimiento programado. Temporal por definición; comprueba Retry-After.
504 Gateway Timeout Caído El origen tardó en responder más de lo que el proxy estaba dispuesto a esperar.
0 Sin respuesta Caído No respondió nada: fallo de DNS, conexión rechazada, certificado TLS no válido o tiempo agotado: 8 segundos para establecer la conexión y 15 segundos en total.

Los veredictos siguen las clases de estado del RFC 9110: 200–399 se informa como activo y 400–599 como caído. El veredicto describe la URL que has escrito, no la máquina que hay detrás: con un 403 o un 404 el servidor ha respondido, así que el host es accesible y ninguno de los dos casos es una caída. Un 304 cuenta como activo porque el recurso existe; un 404 cuenta como caído porque la URL solicitada no existe.

¿El sitio está caído o solo me pasa a mí?

La comprobación de arriba se ejecuta en nuestro servidor, no en tu navegador, y eso es justo lo que hace útil la comparación. Si esta página informa de un 200 OK mientras tu navegador muestra un error de conexión, la avería es local: un resolver DNS con un registro muerto en caché, una VPN o un proxy corporativo, una entrada en tu archivo hosts o un problema de enrutamiento de tu operador. Si fallan las dos, el origen o su CDN están realmente caídos y no hay nada que arreglar en tu equipo.

¿Por qué se caen los sitios web?

Casi todas las caídas pertenecen a seis familias, y el código de estado te dice ante cuál estás:

  • Certificado TLS caducado o que no coincide con el nombre: la conexión falla antes de que empiece HTTP, por eso ves el estado 0.
  • Registros DNS cambiados o caducados: el nombre de host ya no se resuelve, de nuevo estado 0.
  • El proceso de la aplicación se ha caído o se ha quedado sin memoria: 500 desde el origen, 502 desde el proxy que tiene delante.
  • Más tráfico que capacidad, o una ventana de mantenimiento planificada: 503, normalmente con Retry-After.
  • Una base de datos lenta o un arranque en frío que supera el tiempo de espera del proxy: 504.
  • Un incidente del proveedor en una CDN, una región de nube o un registrador, capaz de tumbar a la vez miles de sitios sin relación entre sí.

¿Qué hago si mi web está caída?

Trabaja de fuera hacia dentro, en este orden:

  1. Lanza la comprobación aquí para confirmar que el fallo no es solo de tu red.
  2. Lee el código. 0 apunta a DNS o TLS; 5xx, al origen; 403, a una regla de cortafuegos; 404, a un vhost o una ruta equivocados.
  3. Abre la lista de cabeceras de respuesta: Server, Location y Retry-After identifican la capa que te respondió.
  4. Consulta las páginas de estado de tu proveedor de hosting y de tu CDN antes de abrir un ticket de soporte.
  5. Repite la comprobación después de cada cambio y exporta el CSV para que el ticket lleve marcas de tiempo en lugar de capturas de pantalla.

¿Cómo de rápido debería responder un sitio web?

El tiempo de respuesta que se muestra es el viaje de ida y vuelta que necesitó nuestro servidor para una única petición HEAD: resolución DNS, conexión TCP, handshake TLS y la primera respuesta del servidor. No incluye imágenes, CSS, JavaScript ni el renderizado, así que es mucho menor que una cifra de carga de Lighthouse. Estas son las bandas de color que usa esta página:

Tiempo de respuesta Color Lectura
< 500 ms Verde Saludable. Típico de un nodo de CDN o de una caché caliente.
500–1500 ms Amarillo Aceptable, pero conviene vigilarlo: normalmente es un viaje hasta el origen sin caché en el borde.
> 1500 ms Rojo Lento. Revisa la CPU del origen, las consultas a la base de datos, los arranques en frío y el enrutamiento intercontinental.

Un sitio que responde 301 o 302 en lugar de 200 está redirigiendo: comprueba adónde redirige la URL y si la cadena termina en una página que funciona.

Acerca de Verificador de Estado Web

Un verificador de estado web responde bien a una pregunta muy concreta: ¿respondió el servidor y qué dijo? Esta herramienta abre una única petición HTTP HEAD a la dirección que escribes, concede 8 segundos para establecer la conexión y 15 segundos para la petición completa, e informa de cuatro datos — el código de estado numérico, el tiempo de ida y vuelta en milisegundos, el Content-Type y la cabecera Server — más la lista completa de cabeceras de respuesta que devolvió el origen.

Dos decisiones de diseño hacen que la lectura sea inequívoca. Primero, no se siguen las redirecciones. Si example.com responde 301, ves 301 y su cabecera Location en lugar del estado de otra página tres saltos más allá; eso es justo lo que quieres al verificar una regla de HTTP a HTTPS o de non-www. Segundo, el veredicto sigue las clases de estado definidas en el RFC 9110: de 200 a 399 se informa como activo, de 400 a 599 como caído, y un estado 0 significa que la petición nunca llegó a completarse — el DNS no resolvió, la conexión fue rechazada, el certificado TLS no validó o el origen agotó el tiempo.

La comprobación se ejecuta desde nuestro servidor y no desde tu navegador, y por eso resuelve la duda de si el sitio está caído para todos o solo para ti. Si tu equipo no puede cargar una web pero esta página informa de un 200 OK, el fallo es local: tu resolver, tu operador, una VPN, un proxy corporativo o una entrada obsoleta en el archivo hosts. Si fallan los dos, el problema está en el origen o en su CDN.

El modo masivo acepta hasta 10 direcciones, una por línea, y las comprueba en orden con una pausa de 300 ms entre peticiones, de modo que una sola ejecución no agote la cuota de 60 comprobaciones por minuto. Los resultados vuelven como una lista compacta que puedes descargar en CSV o copiar como tabla separada por tabuladores directamente en una hoja de cálculo o en una incidencia. Cada comprobación genera además un enlace que vuelve a ejecutarse solo cuando alguien lo abre, así que el aviso de caída llega con la prueba adjunta y no con una captura de pantalla.

Una advertencia que conviene recordar: las peticiones salen de una IP de centro de datos con el user agent FreeWebTools Status Checker/1.0. Los sitios con filtrado agresivo de bots pueden respondernos 403 mientras atienden con normalidad a los navegadores, así que lee un 403 como «ha rechazado a este cliente» y no automáticamente como «caído».

Casos de uso

Resolver la duda de si el sitio está caído para todos o solo para ti: la petición sale de nuestro servidor, así que un 200 aquí mientras tu navegador falla apunta a tu DNS, tu VPN o tu operador.
Confirmar un despliegue: pega en el modo masivo las diez URLs que acabas de publicar y comprueba que todas responden 200 y no 500 o 502.
Verificar redirecciones antes de una migración: como este verificador no las sigue, un 301 se informa como 301 con su cabecera Location intacta.
Adjuntar pruebas a una incidencia: exporta la ejecución en CSV o pega el enlace compartible para que soporte repita exactamente la misma comprobación.
Seguir un incidente de CDN o de nube: repite la comprobación cada pocos minutos y observa cómo los 502 y 503 vuelven a 200, sin abrir una cuenta de monitorización.

Cómo comprobar si un sitio web está caído

1

Deja seleccionada la pestaña URL única y escribe la dirección que quieres probar, por ejemplo example.com; si falta el prefijo https://, se añade automáticamente.

2

Haz clic en Comprobar estado. Una petición HTTP sale de nuestro servidor y el mensaje de resultado indica El sitio está ACTIVO para los códigos 200–399, o El sitio está CAÍDO para 400–599 y tiempos de espera agotados.

3

Lee las cuatro casillas: Código de estado, Tiempo de respuesta, Tipo de contenido y Servidor. Los tiempos por debajo de 500 ms se muestran en verde y por encima de 1500 ms en rojo.

4

Abre la lista Encabezados de respuesta para ver todo lo que envió el origen, incluido Location en un 301 y Retry-After en un 429 o un 503.

5

Cambia a la pestaña Comprobación masiva para pegar hasta 10 URL, una por línea, y guarda el resultado con Descargar CSV o Copiar como tabla.

6

Usa Copiar enlace para compartir y envía una dirección que repite exactamente la misma comprobación cuando alguien la abre.

Consejos Pro

  • Comprueba por separado el dominio a secas y la versión www. example.com y www.example.com suelen apuntar a hosts distintos, y puede que solo falle uno de ellos.
  • El estado 0 no es un 500. Significa que no respondió absolutamente nada, así que revisa la resolución DNS y la caducidad del certificado TLS antes de culpar a la aplicación.
  • Los tiempos de respuesta por debajo de 500 ms salen en verde, de 500 a 1500 ms en amarillo y por encima de 1500 ms en rojo. La cifra es solo el viaje al servidor: sin imágenes, CSS ni JavaScript.
  • Si aquí obtienes 403 pero el sitio carga en tu navegador, un WAF está filtrando las IP de centros de datos o nuestro user agent FreeWebTools Status Checker/1.0. Eso no es una caída.
  • El modo masivo está limitado a 10 URLs y la API permite 60 comprobaciones por minuto y dirección IP. Divide las listas largas en lotes en lugar de reintentar hasta provocar un 429.

Solución de problemas

Problema:

La comprobación devuelve el código de estado 0 y ninguna cabecera.

Solución:

No respondió nada. Puede que el nombre de host no se resuelva, que la conexión fuera rechazada, que el certificado TLS esté caducado o emitido para otro nombre, o que la petición agotara el tiempo: 8 segundos para establecer la conexión y 15 segundos en total. Revisa primero el DNS y el certificado, y prueba después la versión http:// para aislar un fallo de TLS.

Problema:

Indicamos 403 Forbidden pero el sitio carga bien en el navegador.

Solución:

Una regla de WAF o antibots está bloqueando las IP de centros de datos o el user agent FreeWebTools Status Checker/1.0. El sitio está activo: solo rechaza a los clientes automatizados. Añade la comprobación a la lista de permitidos o confírmalo desde una conexión doméstica.

Problema:

La comprobación masiva se detiene a mitad con un aviso de límite de peticiones.

Solución:

La API permite 60 comprobaciones por minuto y dirección IP. Espera sesenta segundos y vuelve a lanzar las URLs restantes, o divide la lista en lotes más pequeños. La ejecución ya separa sus peticiones 300 ms.

Problema:

Una página que funciona en el navegador devuelve 404 aquí.

Solución:

Probablemente estés probando una ruta que no existe en ese host, o el dominio resuelve a un host virtual por defecto. Prueba primero el dominio a secas y añade la ruta cuando la raíz responda 200.

Preguntas frecuentes

Escribe la dirección en el campo de arriba y pulsa «Comprobar estado». La herramienta envía una única petición HTTP desde nuestro servidor e informa del código de estado, del tiempo de respuesta y de todas las cabeceras de la respuesta. Un código entre 200 y 399 significa que el sitio está activo; de 400 a 599, o un estado 0, significa que está caído. El tiempo de respuesta que ves es el viaje de ida y vuelta que necesitó nuestro servidor, no tu navegador: resolución DNS, conexión TCP, handshake TLS y la primera respuesta, a menudo unas pocas decenas de milisegundos con un origen cercano.

Este comprobador se ejecuta desde nuestro servidor, no desde tu navegador, así que comparar los dos resultados localiza el fallo. Si nosotros informamos de un 200 OK y tú sigues sin poder cargar la página, el problema está de tu lado: caché DNS, VPN, proxy, caché del navegador o archivo hosts. Si nosotros también obtenemos un 502 o un tiempo agotado, el fallo está en el lado del sitio y no en el tuyo, aunque un bloqueo geográfico o una regla de cortafuegos contra nuestra IP se vería igual desde aquí.

503 Service Unavailable significa que el servidor es accesible pero ahora mismo se niega a atender la petición, normalmente por sobrecarga o por mantenimiento programado. Es temporal por definición y a menudo llega con una cabecera Retry-After que indica cuándo volver a intentarlo. Los buscadores interpretan un 503 breve como «vuelve más tarde» y no como un fallo permanente.

En la práctica: certificados TLS caducados o que no coinciden y registros DNS rotos (ambos aparecen como estado 0), una aplicación que ha fallado o se ha quedado sin memoria (500), un proxy que no alcanza el origen en mitad de un despliegue (502), tráfico por encima de la capacidad o mantenimiento (503), una base de datos más lenta que el tiempo de espera del proxy (504) e incidencias generales de CDN o de nube del proveedor.

Confirma primero aquí que el fallo no es local a tu red. Luego lee el código: 5xx significa revisar los registros del origen y el gestor de procesos, 0 significa comprobar el DNS y la caducidad del certificado, 403 apunta a una regla de cortafuegos o de WAF, y un 404 en el dominio a secas, a un host virtual equivocado. Consulta la página de estado de tu proveedor antes de abrir un ticket.

Sí. Cambia a la pestaña «Comprobación masiva» y pega hasta 10 URLs, una por línea. Se comprueban por turnos con 300 ms de separación entre peticiones, y los resultados aparecen como una lista con veredicto, código de estado y tiempo de respuesta. Después puedes descargar la tanda entera en CSV o copiarla como tabla separada por tabulaciones.

No, y es deliberado. Las redirecciones no se siguen para que un 301 o un 302 se muestre exactamente como lo envió el servidor, junto con su cabecera Location, que es justo lo que necesitas al comprobar una regla de HTTP a HTTPS o de non-www. Para recorrer una cadena de redirecciones salto a salto, usa nuestro Verificador de redirecciones.

Porque la petición llega desde una IP de centro de datos con el user agent FreeWebTools Status Checker/1.0. Los servicios antibots, los WAF y las reglas de cortafuegos de las CDN responden habitualmente a los clientes automatizados con 403 Forbidden o una página de desafío, mientras atienden con normalidad a los navegadores reales. Por eso un 403 de esta herramienta significa «ha rechazado a este cliente», no siempre «caído».

Es el tiempo, en milisegundos, que necesitó nuestro servidor para completar una única petición HEAD, incluidas la resolución DNS, la conexión TCP y el handshake TLS. No incluye imágenes, CSS, JavaScript ni el renderizado, así que es mucho menor que una puntuación de carga de Lighthouse. Compara unas mediciones con otras y cuenta con 100–300 ms extra si el origen está lejos.

No. El endpoint rechaza los nombres localhost, 127.0.0.1, 0.0.0.0 y ::1, cualquier IP de un rango privado o reservado como 192.168.x.x o 10.x.x.x, direcciones de metadatos de nube como 169.254.169.254 y puertos sensibles como el 22, el 3306 y el 6379. El nombre de host se resuelve una vez y se rechaza si esa dirección IPv4 es privada; la comprobación es solo IPv4, así que tómala como una protección frente a la falsificación de peticiones del lado del servidor (SSRF), no como una garantía. Para hosts internos, usa curl desde dentro de la red.

Fuentes y estándares

Las cinco clases de estado y el significado de cada código proceden de la especificación HTTP y del registro de la IANA que aparecen abajo. Las páginas de MDN y de Google Search Central son documentación, no especificaciones, y el 429 Too Many Requests está definido en el RFC 6585, no en el RFC 9110. El veredicto activo/caído es nuestra propia lectura de esos límites de clase: esta página considera activo el rango 200–399 y caído el 400–599, así como cualquier petición que no llegue a recibir un código de estado.

Herramientas populares

No hay más herramientas
Explorar todas las herramientas
FreeWebTools AI
Powered by free AI models · Full chat →