¿Qué significa 'connection refused' o 'timeout' en el reporte?

Ambos son fallos a nivel TCP según RFC 9293 (Eddy Ed., agosto 2022, STD 7 que deja obsoleto el RFC 793) — pre-HTTP. Connection refused significa que el SYN TCP llegó al host pero ningún servicio escuchaba en el puerto solicitado (proceso crasheado, firewall del puerto, servidor detenido). Timeout significa que los paquetes SYN o respuesta nunca llegaron — puede ser IP-layer inalcanzable (host caído o routing roto según RFC 1122 §3.2.2 Braden, octubre 1989), firewall descartando paquetes silenciosamente, o la ruta entre el sondeo y el destino degradándose. DNS resuelve correctamente y TLS no ha empezado todavía. La remediación difiere: refused = comprobar salud del servicio, timeout = comprobar ruta de red / firewall.

¿Es esta herramienta un sustituto de DownDetector o páginas de estado?

Complementaria, no sustituta. DownDetector agrega reportes de usuarios — refleja caídas percibidas desde una muestra auto-seleccionada (gente que se queja activamente), así que es ruidosa y va con minutos de retraso respecto a caídas reales. La página oficial de estado de un sitio (status.example.com) refleja el monitoreo propio del operador y es autoritativa cuando se publica, pero los operadores a veces retrasan actualizaciones durante incidentes. Esta herramienta es un sondeo activo sintético — te dice ahora mismo si el sitio responde desde múltiples regiones Cloudflare, qué capa HTTP/TCP/DNS falló si no respondió, y si tu red local es el problema. Usa las tres: esta herramienta para un sí/no inmediato, página de estado para transparencia del incidente, DownDetector para corroboración por reportes de usuarios.

¿Está Caída? Verificador de Caídas de Sitios — Local vs Distribuida

Q: ¿Cómo distingue la herramienta si el sitio está caído para todos o solo para mí?

La herramienta corre sondeos de alcance desde múltiples puntos anycast de Cloudflare (RFC 4786 BCP 126 Abley y Lindqvist, diciembre 2006), cada uno en una región distinta. Si cada sondeo regional devuelve el sitio como inalcanzable, la caída es global — probablemente crash del servidor, DDoS o mala configuración del origen. Si solo algunos sondeos regionales fallan, el problema es parcial — normalmente fallo de POP del CDN, problema de routing de ISP regional o propagación DNS en curso. Si todos los sondeos regionales funcionan pero tú sigues sin alcanzar el sitio, el problema es local a tu red: problema de tránsito del ISP, caché del resolver DNS con registros anticuados, caché del navegador sirviendo un 5xx desactualizado, antivirus o firewall bloqueando, o secuestro por portal cautivo. La salida de la herramienta distingue explícitamente estos tres patrones para que no escales un problema local al ingeniero de guardia.

Q: ¿Cuál es la diferencia entre una caída HTTP 4xx y 5xx?

Según RFC 9110 §15 (Fielding, Nottingham y Reschke, junio 2022), los códigos 4xx significan que el servidor procesó la petición pero la rechazó por razones del lado del cliente — 404 Not Found (la ruta no existe), 401/403 (auth falló), 429 (rate-limited), 451 (legal). El servidor está activo; el problema es la petición. Los códigos 5xx significan que el servidor mismo falló — 500 Internal Server Error (crash de aplicación), 502/504 (fallos de gateway upstream, común cuando el origen está sobrecargado), 503 Service Unavailable (throttling intencional o mantenimiento). 5xx es la señal real de caída; 4xx significa que el servidor está sano pero tu petición específica no es válida. La herramienta muestra el código exacto para que sepas qué vía de remediación aplica.

¿Está Caída? — Sondeo Multi-Región y Diagnóstico de 5 Capas de Fallo

Cuando un sitio web no carga, la pregunta rara vez es '¿está roto?' sino '¿dónde exactamente se rompe?' Los fallos se apilan en cinco capas: resolución DNS (RFC 1035 §4.1.1 NXDOMAIN/SERVFAIL, Mockapetris 1987), alcance a nivel IP (RFC 1122 §3.2.2 ICMP, Braden 1989), establecimiento de conexión TCP (RFC 9293 connection refused/timeout, Eddy 2022, STD 7), handshake TLS (RFC 8446, Rescorla 2018) y respuesta HTTP de aplicación (RFC 9110 §15 clases de código de estado 4xx/5xx, Fielding, Nottingham y Reschke, junio 2022). Cada capa falla de forma distinta y exige remediación distinta. Esta herramienta corre sondeos de alcance desde múltiples puntos anycast Cloudflare (RFC 4786 BCP 126, Abley y Lindqvist, diciembre 2006) — regiones geográficas distintas — y señala qué capa se rompió y desde qué checkpoints, para que distingas inmediatamente una caída distribuida real de un problema de red local (tu ISP, resolver DNS, caché del navegador, portal cautivo, antivirus o VPN). El diagnóstico responde a la canónica '¿está caída para todos o solo para mí?' con un desglose por capas que mapea directamente a vías de remediación.

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

Introduce la URL o dominio que quieres probar — URL íntegra con path funciona también.
La herramienta corre sondeos de alcance desde múltiples regiones anycast Cloudflare (RFC 4786) y devuelve resultados por capa (DNS / TCP / TLS / HTTP).
Lee el veredicto: todas las regiones fallan → caída distribuida; algunas fallan → problema parcial / regional; todas tienen éxito → probablemente local a tu red.
Empareja la capa que falló con la remediación: DNS = registrador/nameservers; TCP refused = servicio caído; TCP timeout = ruta de red; TLS = cert; HTTP 5xx = capa de aplicación.

Casos de uso comunes

Confirmar una caída global antes de avisar al ingeniero de guardia — fallo distribuido multi-región es el umbral de escalado para incidentes distribuidos.
Descartar problemas de red local (tránsito ISP, caché DNS, caché del navegador, portal cautivo) cuando tu conexión sola no puede alcanzar un sitio que múltiples regiones sí pueden.
Identificar un fallo parcial de POP del CDN o problema de routing de ISP regional que afecta solo a un subconjunto de usuarios.
Capturar evidencia por capas (RCODE DNS / estado TCP / error TLS / código HTTP) para un ticket de soporte para que el operador pueda hacer triaje más rápido que un 'el sitio está roto'.

Preguntas frecuentes

¿Cómo distingue la herramienta si el sitio está caído para todos o solo para mí?

Sondea desde múltiples regiones anycast Cloudflare (RFC 4786 BCP 126). Todas fallan = caída global. Algunas fallan = parcial/regional. Todas tienen éxito pero tú no puedes alcanzar = local a tu red (tránsito ISP, caché DNS, caché del navegador, antivirus, portal cautivo). Tres patrones explícitos mapeados a vías de remediación.

¿Cuál es la diferencia entre una caída HTTP 4xx y 5xx?

Según RFC 9110 §15 (Fielding/Nottingham/Reschke junio 2022): 4xx = el servidor procesó pero rechazó la petición (404, 401/403, 429, 451) — el servidor está bien, tu petición no es válida. 5xx = el servidor mismo falló (500 crash, 502/504 gateway, 503 mantenimiento) — la señal real de caída.

¿Qué significa 'connection refused' o 'timeout'?

Ambos son fallos a nivel TCP pre-HTTP según RFC 9293 (Eddy Ed., agosto 2022, STD 7). Refused = SYN llegó al host pero ningún servicio escuchaba en el puerto (proceso crasheado, firewall, servidor detenido). Timeout = paquetes nunca llegaron — IP-layer inalcanzable según RFC 1122 §3.2.2, firewall descartando, o ruta degradada.

¿Por qué DNS puede mostrar NXDOMAIN o SERVFAIL?

Ambos son fallos a nivel DNS según RFC 1035 §4.1.1 (Mockapetris 1987). NXDOMAIN = el dominio no existe (borrado del registrador, registro expirado, error tipográfico). SERVFAIL = el resolver mismo se rompió (DNS upstream mal configurado, fallo de validación DNSSEC, bug transitorio). Prueba un resolver distinto (1.1.1.1, 8.8.8.8) para confirmar.

¿Es un sustituto de DownDetector o páginas de estado?

Complementaria. DownDetector agrega reportes de usuarios — ruidosa, va con retraso respecto a caídas reales. Las páginas de estado del operador son autoritativas cuando se publican pero a veces retrasadas. Esta herramienta es un sondeo activo sintético — sí/no inmediato con desglose de fallo por capas. Usa las tres para una visión panorámica.

Caída local vs distribuida — cómo leer el diagnóstico por capas

Tres patrones emergen del sondeo multi-región. (1) Cada checkpoint regional devuelve inalcanzable: la caída es global. El desglose por capas te dice si falló primero DNS, TCP, TLS o HTTP — esto mapea a una vía de remediación (DNS = problema de registrador / nameservers autoritativos; TCP refused = servicio caído en origen; TCP timeout = ruta de red o firewall; TLS = certificado expirado o cadena mal configurada según RFC 8446; HTTP 5xx = crash de capa de aplicación o fallo de gateway upstream). (2) Algunos checkpoints regionales tienen éxito y otros fallan: caída parcial. Fallo de POP del CDN (un nodo anycast caído), problema de routing de ISP regional, propagación DNS en curso tras un cambio de registro, o regla WAF regional clasificando mal tráfico. La remediación es geográfica — comprueba el dashboard del CDN de la región que falla o haz traceroute desde allí. (3) Todos los checkpoints regionales tienen éxito pero tú sigues sin alcanzar el sitio: el problema es local. Causas comunes: problema de tránsito del ISP entre tú y el edge del sitio, caché del resolver DNS con registros anticuados (vacía con `ipconfig /flushdns` Windows o `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` macOS), caché del navegador sirviendo un 5xx antiguo (hard refresh / incógnito), antivirus o firewall bloqueando el host, o secuestro por portal cautivo en Wi-Fi de hotel/aeropuerto. La herramienta señala cada patrón explícitamente para que enrutes el problema al equipo correcto — o evites escalar al de guardia cuando es un problema en tu lado.

Sondeos anycast multi-región desde edge Cloudflare (RFC 4786 BCP 126)
Diagnóstico de 5 capas de fallo (DNS / TCP / IP-ICMP / TLS / HTTP según RFC 1035 / 9293 / 1122 / 8446 / 9110)
Clasificación caída local vs distribuida vs parcial
Distinción HTTP 4xx (petición rechazada) vs 5xx (servidor falló) según RFC 9110 §15
Reporte TCP connection refused vs timeout (capa pre-HTTP)
Detección DNS NXDOMAIN/SERVFAIL según RFC 1035 §4.1.1 (pre-HTTP)

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 (6)

Fielding, R., Nottingham, M., & Reschke, J. (Eds.) (2022). HTTP Semantics. RFC 9110, IETF (June 2022 — STD 97 — §15 status code classes; distinguishes 4xx client-side from 5xx server-side failures).
Eddy, W. (Ed.) (2022). Transmission Control Protocol (TCP). RFC 9293, IETF (August 2022 — STD 7; obsoletes RFC 793; TCP connection refused/timeout semantics for pre-HTTP failure layer).
Mockapetris, P. (1987). Domain Names — Implementation and Specification. RFC 1035, IETF (November 1987 — §4.1.1 RCODE field NXDOMAIN/SERVFAIL pre-HTTP failure layer).
Braden, R. (Ed.) (1989). Requirements for Internet Hosts — Communication Layers. RFC 1122, IETF (October 1989 — STD 3 — §3.2.2 ICMP error reporting + IP-layer reachability requirements).
Abley, J., & Lindqvist, K. (2006). Operation of Anycast Services. RFC 4786, IETF (BCP 126, December 2006 — multi-region anycast routing foundation for distributed reachability probes).
Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, IETF (August 2018 — handshake failures separate from HTTP layer; cert/SNI errors).

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

Matemática de SLA de uptime — Qué significa realmente 99.9% vs 99.99% (y qué cuesta)El coste real de cada nueve adicional en tu SLA de uptime, en minutos de caída, cambios de arquitectura y esfuerzo de ingeniería.

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