¿Por qué la herramienta muestra el sitio como online cuando mi navegador no puede llegar?

La herramienta corre desde infraestructura cloud neutral (red global de Cloudflare) que tiene peering directo con la mayoría de operadores y CDNs grandes. Tu conexión local añade capas que la herramienta no ve: tu router doméstico/oficina (bugs de firmware, mala configuración DNS), tu ISP (cortes regionales, disputas de peering que no afectan a rutas cloud), VPN corporativa (split tunnel, política DNS), caché del navegador (sirviendo página de error vieja), extensiones del navegador (ad blockers, extensiones de seguridad) o resolver DNS del sistema operativo. Si múltiples checkpoints ven el sitio online pero tu conexión específica no, el problema está en tu camino de red local — prueba `dig` desde línea de comandos, cambia a datos móviles, o chequea desde otra red. El veredicto 'el sitio está online' responde a '¿está el internet público alcanzándolo?', no a '¿está tu conexión específica alcanzándolo?'.

Verificador de Estado Web — Uptime y Tiempo de Respuesta

Q: ¿Cómo decide la herramienta que un sitio está online?

La herramienta envía una petición HTTP desde un servidor edge de Cloudflare en una región específica e inspecciona el código de estado de la respuesta según RFC 9110 §15 (Fielding, Nottingham y Reschke, 2022). Una respuesta 2xx significa que el servidor procesó la petición. Una 3xx redirige a otra URL — la herramienta sigue hasta un límite razonable. Una 4xx indica que el cliente hizo una petición inválida (404 no encontrado, 403 prohibido); el servidor está técnicamente online pero rechaza esa ruta. Una 5xx es un error del lado del servidor (500 interno, 502 bad gateway, 503 service unavailable, 504 gateway timeout) — el servidor procesa pero falla. La herramienta detecta casos de 'soft 200' donde un 200 OK contiene una página de error obvia en el cuerpo — las aplicaciones a menudo devuelven 200 para errores renderizados en cliente en vez de un 4xx/5xx correcto, ocultando caídas reales a verificadores ingenuos.

Q: ¿Cuál es la diferencia entre fallo DNS y fallo HTTP?

Capas de red distintas fallan de forma distinta. La resolución DNS ocurre antes de la petición HTTP: la herramienta primero pide a un resolver que traduzca el nombre de host a una dirección IP. RFC 1035 §4.1.1 (Mockapetris, 1987) define los códigos de respuesta — RCODE 3 (NXDOMAIN, name error) significa que el dominio no existe o ha sido borrado; RCODE 2 (SERVFAIL, fallo de servidor) significa que el resolver no pudo procesar la consulta (cadena DNSSEC rota, timeout del servidor autoritativo, etc.). Cualquiera de los dos errores DNS bloquea la petición HTTP por completo. La herramienta muestra fallos DNS separados de fallos HTTP porque la vía de remediación difiere: NXDOMAIN significa que el registro de dominio o la zona DNS desapareció, SERVFAIL significa que el nameserver está roto, mientras que una resolución exitosa que luego da HTTP 5xx apunta a problemas de aplicación.

Q: ¿Por qué varían tanto los tiempos de respuesta entre regiones?

Dos factores: distancia física y calidad de routing. La luz en fibra mono-modo viaja a ~c/n con n≈1,47, dando ~5 ms one-way por 1000 km (~10 ms RTT) más tiempo de procesamiento por salto de router. Un sitio alojado en Frankfurt responde más rápido desde Madrid que desde São Paulo porque la distancia ida y vuelta es menor. La calidad del routing afecta esto aún más — los acuerdos de peering, ISPs de tránsito y políticas BGP determinan qué camino toman realmente los paquetes, que a menudo no es la ruta geográfica más corta. El despliegue Anycast (RFC 4786 BCP 126, Abley y Lindqvist, 2006) permite anunciar una sola dirección IP desde varias localizaciones y enrutar automáticamente al edge más cercano — Cloudflare, el 8.8.8.8 de Google y Fastly suelen lograr respuesta sub-50 ms desde regiones con presencia edge cercana (no es uniforme globalmente — interior de África, islas del Pacífico, etc. siguen viendo latencia mayor). Los sitios sin anycast ni CDN muestran 100-400 ms de variación inter-región según la ubicación de origen y el routing intercontinental.

Q: ¿Qué significa un HTTP 403 desde todos los checkpoints?

El sitio está sirviendo peticiones pero las rechaza activamente con 403 Forbidden. Tres causas comunes: (1) reglas WAF bloqueando las IPs cloud desde las que corre la herramienta — Cloudflare, Vercel, Imperva tienen rangos por defecto que incluyen ASNs de centros de datos; (2) Geo-bloqueo rechazando tráfico de ciertos países — habitual por cumplimiento (RGPD, licencias regionales) o anti-DDoS; (3) Filtrado por User-Agent bloqueando peticiones 'bot' — aunque esta herramienta envía un User-Agent estilo Mozilla real. Los navegadores de usuarios finales en ISPs residenciales a menudo pasan sin problema, así que el 403 aparente es específico del checkpoint, no una caída real. Prueba otra región, o recurre a comprobar desde un navegador en conexión residencial.

Verificador de Estado Web — Sondeo HTTP, DNS y TLS Multi-Región

La verificación de estado web envía peticiones HTTP desde un edge cloud neutral y analiza la respuesta según RFC 9110 §15 (Fielding, Nottingham y Reschke, 2022). La herramienta sondea desde varios puntos regionales Cloudflare — aprovechando el modelo de routing anycast definido en RFC 4786 BCP 126 (Abley y Lindqvist, 2006) — para detectar si el sitio es alcanzable globalmente o solo desde ciertas regiones. Un código 2xx significa que el servidor procesó la petición; 3xx redirige a otra URL; 4xx señala problemas del cliente (el servidor está online pero rechaza esa ruta); 5xx indica errores del servidor. La herramienta también distingue fallos DNS (NXDOMAIN, SERVFAIL según RFC 1035 §4.1.1, Mockapetris 1987) de fallos HTTP, ya que las vías de remediación difieren. Tiempo de respuesta inferior a 300 ms es rápido, inferior a 1 s moderado, más allá apunta a problemas de origen o routing. Los fallos de handshake TLS (RFC 8446 TLS 1.3, Rescorla 2018) se informan por separado — los certificados expirados y configuraciones de cadena erróneas aparecen aquí, no en el estado HTTP. Útil para verificar despliegues, hacer una verificación rápida tras cambios DNS y descartar problemas de red local.

Cómo comprobar si un sitio está online

Introduce la URL o dominio que quieres verificar.
La herramienta envía peticiones HTTP desde servidores edge regionales de Cloudflare (routing anycast según RFC 4786) y devuelve código de estado, tiempo de respuesta y disponibilidad global.
Compara el código según RFC 9110 §15: 2xx funcionando, 3xx redirige, 4xx problema del cliente, 5xx caída del servidor. Los fallos DNS (NXDOMAIN/SERVFAIL) se marcan por separado.
Si todos los checkpoints ven el sitio online pero tu conexión específica no, el problema está en tu camino local (router, ISP, VPN, caché del navegador), no en el servidor.

Casos de uso comunes

Chequeo rápido de un sitio recién desplegado antes de compartir el enlace.
Verificar que el sitio de un cliente es alcanzable desde Europa tras oír que iba lento desde Sudamérica.
Auditar uptime de forma esporádica para detectar problemas antes de que suene el pager.
Descartar una caída local del ISP cuando tu propio navegador no carga un sitio.

Preguntas frecuentes

¿Cómo decide la herramienta que un sitio está online?

Envía petición HTTP desde el edge Cloudflare e inspecciona el estado (RFC 9110 §15). 2xx OK, 3xx redirige, 4xx error de cliente (sigue sirviendo), 5xx error de servidor. Detecta 'soft 200' donde 200 devuelve página de error en el cuerpo — enmascaramiento típico de aplicaciones.

¿Cuál es la diferencia entre fallo DNS y fallo HTTP?

DNS ocurre antes de HTTP: NXDOMAIN (RCODE 3) significa que el dominio no existe; SERVFAIL (RCODE 2) que el resolver se rompió (RFC 1035 §4.1.1). Cualquiera bloquea HTTP por completo. La herramienta los muestra por separado porque la remediación difiere.

¿Por qué varían tanto los tiempos de respuesta entre regiones?

Distancia + routing. ~5 ms one-way por 1000 km en fibra (~10 ms RTT, índice de refracción ~1,47) más overhead de saltos de router. Anycast (RFC 4786, Abley y Lindqvist 2006) permite que una IP llegue al edge más cercano — Cloudflare, 8.8.8.8, Fastly suelen lograr respuesta sub-50 ms desde regiones con presencia edge cercana. Los sitios sin anycast/CDN muestran 100-400 ms de variación inter-región.

¿Qué significa un HTTP 403 desde todos los checkpoints?

El sitio sirve pero rechaza. Tres causas: WAF bloqueando IPs cloud, geo-bloqueos rechazando ciertos países, o filtros de User-Agent. Los usuarios finales en ISPs residenciales suelen pasar bien — el 403 desde checkpoint no siempre es una caída real.

¿Por qué la herramienta muestra el sitio online cuando mi navegador no puede llegar?

La herramienta corre desde el edge neutral de Cloudflare con peering directo a redes mayores. Tus capas locales (router, ISP, VPN, caché del navegador, extensiones) añaden caminos que la herramienta no ve. 'El sitio está online' responde a '¿llega el internet público?', no a '¿llega tu conexión específica?'.

Por qué importa el chequeo de uptime multi-región — distinguiendo capas de fallo

Un único usuario reportando 'el sitio está caído' puede significar: una caída real (servidor crasheado, bug de aplicación, DDoS); un fallo regional de POP del CDN (parte de la audiencia afectada, otros bien); un problema de propagación DNS tras un cambio de registro (RFC 1035); una expiración de certificado TLS (RFC 8446 TLS 1.3 fallo de handshake); una regla WAF clasificando mal tráfico legítimo; o simplemente el ISP, router, navegador o caché del usuario. Distinguir entre estos requiere sondear desde varios puntos geográficamente distintos. El despliegue Anycast (RFC 4786, Abley y Lindqvist 2006, BCP 126) es la base moderna — una sola IP anunciada en docenas de localizaciones se enruta automáticamente al edge más cercano, así el checkpoint de la herramienta en la red Cloudflare alcanza un sitio por el mismo camino que los usuarios reales. La salida de estado distingue capas de señal: resolución DNS (NXDOMAIN/SERVFAIL pre-HTTP), conexión TCP (refused/timeout pre-HTTP), handshake TLS (errores de cert/SNI pre-aplicación) y respuesta HTTP (código de estado real de la aplicación). El fallo de cada capa apunta a una vía de remediación distinta. La herramienta también detecta patrones 'soft 200' donde las aplicaciones devuelven 200 OK con cuerpo de error — habitual en SPAs que manejan errores en cliente, lo que oculta caídas reales a verificadores ingenuos que solo miran el código de estado.

Semántica de códigos HTTP según RFC 9110 §15 (clases 200/3xx/4xx/5xx)
Sondas multi-región vía anycast (RFC 4786 BCP 126)
Detección de fallos DNS (NXDOMAIN/SERVFAIL según RFC 1035 §4.1.1)
Detección de errores de handshake TLS (capa RFC 8446 TLS 1.3)
Detección soft-200 (200 OK con cuerpo de página de error)
Calificación de tiempo de respuesta (rápido <300 ms / moderado <1 s / lento)

Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.

Fuentes (4)

Fielding, R., Nottingham, M., & Reschke, J. (Eds.) (2022). HTTP Semantics. RFC 9110, IETF (§15 status code classes 1xx-5xx).
Mockapetris, P. (1987). Domain Names — Implementation and Specification. RFC 1035, IETF (§4.1.1 RCODE field — NXDOMAIN/SERVFAIL).
Abley, J., & Lindqvist, K. (2006). Operation of Anycast Services. RFC 4786, IETF (BCP 126 — multi-region anycast routing).
Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, IETF (handshake failures separate from HTTP layer).

Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.

Guías relacionadas

Por Marco B. · Última verificación junio 2026 — corre en tu navegador