Diagnosticar conectividad web: herramientas

Por qué “no carga” no es un error: es un síntoma (y se puede medir)

Diagnosticar problemas conectividad web herramientas no va de memorizar comandos: va de aprender a aislar la capa que falla. Una tienda online puede “caerse” para un usuario en Málaga y funcionar perfecta en Madrid; un panel de WordPress puede tardar 8 segundos en abrir por una resolución DNS lenta; o un firewall puede bloquear solo un rango de IPs. Si atacas el problema sin método, acabas reiniciando servicios al azar, tocando TTLs sin entender el impacto o culpando al proveedor equivocado.

En más de 23 años gestionando servidores y redes, el patrón se repite: los incidentes que más tiempo consumen no son los más complejos, sino los que se diagnostican tarde. Un buen diagnóstico reduce el MTTR (tiempo de recuperación) porque convierte “la web va mal” en una frase operativa: “hay pérdida de paquetes a partir del salto 7” o “el dominio resuelve a una IP antigua”.

La buena noticia: con cuatro herramientas clásicas —DNS lookup, ping, traceroute y el análisis de cabeceras— puedes acotar la mayoría de problemas de conectividad web. En esta primera parte vamos a construir el método y a recorrer las tres primeras piezas (DNS, ping y ruta). En la segunda parte entraremos en headers HTTP, TLS y el análisis fino de servidor/CDN.

El mapa mental: de tu navegador al servidor (las 5 capas donde suele romperse)

Antes de teclear nada, conviene dibujar el recorrido. Cuando escribes un dominio, el navegador hace más pasos de los que parece. Si entiendes la cadena, cada herramienta encaja de forma natural.

DNS: convierte www.tudominio.es en una IP (A/AAAA) y define alias (CNAME). Si DNS falla, ni siquiera “encuentras” el servidor.
Red (IP/ICMP): aquí viven latencia y pérdida de paquetes. Ping te da una foto rápida, aunque incompleta.
Ruta (tránsito y peering): el tráfico cruza saltos (routers) entre tu ISP y la red del destino. Traceroute/MTR localizan dónde se degrada.
Transporte y seguridad (TCP/TLS): el handshake TCP o la negociación TLS pueden fallar aunque el servidor “esté bien”.
Aplicación (HTTP): cabeceras, redirecciones, cookies, cache-control, compresión… Aquí “carga pero lento” suele tener explicación.

Un detalle práctico: no todos los problemas están “en el servidor”. La conectividad depende también del ISP del usuario, de la red intermedia y de cómo está publicado el servicio (DNS y certificados). Por eso el diagnóstico debe empezar por lo verificable desde fuera.

Checklist de preparación: qué datos recoger antes de ejecutar comandos

Este paso parece burocrático, pero es el que separa un diagnóstico profesional de una caza de brujas. Si lo haces bien, muchas incidencias se resuelven con un correo o ticket bien escrito, porque ya llevas las pruebas.

Paso 0: define el alcance (y evita falsos positivos)

Responde a estas preguntas con datos, no con impresiones:

¿Falla desde todas las redes o solo desde una (fibra de X, móvil 5G, VPN, red corporativa)?
¿Afecta a todo el dominio o solo a una subruta (por ejemplo /wp-admin)?
¿Es caída total (timeout) o degradación (lento, cortes, cargas parciales)?
¿Cuándo empezó y es intermitente o continuo?
¿Cambió algo recientemente (DNS, SSL, migración, CDN, firewall, plugin)?

Consejo de campo: prueba siempre desde al menos dos ubicaciones. Si tú estás en oficina, repite desde datos móviles. Si falla en una y en otra no, ya tienes la pista: el problema no es “la web”, es el camino.

Herramientas mínimas para seguir esta guía (Windows, macOS y Linux)

No necesitas un laboratorio. Con un terminal y un navegador vale:

Windows: PowerShell / CMD con ping, tracert y nslookup.
macOS/Linux: Terminal con ping, traceroute y, si está disponible, dig (o nslookup).
Extra recomendado: mtr (combina traceroute + ping en tiempo real) y curl para HTTP (lo usaremos en la segunda parte).

Diagnosticar problemas conectividad web herramientas: método paso a paso

Este es el flujo que usamos en operaciones cuando hay que acotar rápido. Empieza por DNS, sigue por conectividad básica, y termina en ruta. Si aquí todo está bien, la probabilidad de que el problema sea de aplicación/HTTP sube muchísimo (y eso lo atacaremos después).

Paso 1 — DNS lookup: confirma que el dominio apunta donde crees

El DNS lookup es la comprobación más rentable cuando algo “no carga”, porque detecta errores silenciosos: IPs antiguas tras una migración, CNAME mal encadenados, registros inexistentes, o resoluciones distintas según el resolvedor. Y lo mejor: se verifica en segundos.

Analogía rápida: DNS es la agenda de contactos. Si el número está mal, puedes llamar cien veces… nunca vas a hablar con la persona correcta.

1.1 Comprueba A/AAAA y CNAME desde tu equipo

En Windows:

nslookup www.tudominio.es

En macOS/Linux (si tienes dig):

dig +short A www.tudominio.es

dig +short AAAA www.tudominio.es

dig +short CNAME www.tudominio.es

Qué buscar:

IP inesperada: si apunta a una IP vieja o a otra infraestructura, el fallo no es “conectividad”, es publicación DNS.
Solo AAAA (IPv6) o solo A (IPv4): puede funcionar en unas redes y fallar en otras. Si tu servidor o red no atiende bien IPv6, el usuario en una red IPv6 “pura” sufrirá.
CNAME en bucle o sin destino: el dominio parece “bien”, pero realmente no resuelve.

1.2 Comprueba DNS desde un resolvedor público (para descartar caché local)

Tu equipo y tu router cachean DNS. Eso a veces enmascara un cambio reciente. Para forzar una vista externa, consulta un resolvedor concreto (ejemplo con Google DNS y Cloudflare DNS). Con dig:

dig @8.8.8.8 www.tudominio.es A +short

dig @1.1.1.1 www.tudominio.es A +short

Con nslookup:

nslookup www.tudominio.es 8.8.8.8
nslookup www.tudominio.es 1.1.1.1

Interpretación práctica:

Si un resolvedor devuelve una IP y otro devuelve otra, suele haber propagación parcial, split-horizon no intencionado o registros inconsistentes.
Si el resolvedor devuelve “NXDOMAIN”, el registro no existe o estás consultando el nombre equivocado (muy típico con y sin www).

1.3 Revisa TTL y tiempos de cambio (sin obsesionarte)

El TTL (Time To Live) define cuánto tiempo se puede cachear una respuesta DNS. No es “malo” tener TTL alto; es eficiente. El problema llega cuando haces cambios y esperas inmediatez. En migraciones planificadas se baja el TTL con antelación; en emergencias, toca gestionar expectativas.

Si gestionas dominios con frecuencia, tener el registro ordenado y el proveedor de hosting bien alineado evita el 80% de los sustos. Si necesitas ayuda con la parte de dominio y zona DNS, puedes centralizar la gestión desde la sección de registro de dominios para simplificar cambios y renovaciones.

1.4 Caso práctico: “A mí me carga, al cliente no”

Escenario típico: acabas de migrar una web, tú la ves bien, pero un usuario sigue llegando al servidor antiguo. Al hacer DNS lookup desde tu equipo, obtienes la IP nueva. Pero al consultarlo desde otro resolvedor, aún sale la IP antigua. Diagnóstico: caché DNS en la cadena (router del cliente, ISP o resolvedor corporativo). Solución: esperar TTL, forzar limpieza local donde sea posible, y durante la ventana crítica mantener el servicio antiguo respondiendo o con redirecciones controladas.

Paso 2 — Ping: mide latencia y pérdida (y entiende sus trampas)

Ping es una prueba ICMP: envía “ecos” al destino y mide si vuelven, y en cuánto tiempo. Sirve para detectar latencia elevada o pérdida de paquetes, pero no es una sentencia final. Muchos servidores filtran ICMP, y eso puede hacer que ping “falle” aunque HTTP funcione.

Piensa en ping como en llamar al timbre de una oficina. Si nadie responde, puede que no haya nadie… o puede que el timbre esté desconectado. Por eso ping se usa como indicador, no como veredicto.

2.1 Ejecuta ping de forma útil (no con 4 paquetes y ya)

En Windows (envía 20):

ping -n 20 tudominio.es

En macOS/Linux (envía 20):

ping -c 20 tudominio.es

Qué mirar:

Tiempo medio: si se dispara de forma estable, hay latencia (distancia, congestión o ruta subóptima).
Pérdida: un 1-2% sostenido ya puede provocar cargas erráticas en TCP/HTTP, especialmente con muchas peticiones.
Jitter (variación): latencias muy variables suelen correlacionar con congestión.

2.2 Si ping falla, no te quedes ahí: prueba por puerto (TCP)

Cuando ICMP está bloqueado, ping da “timeout” aunque el servicio esté vivo. En Windows PowerShell puedes probar conectividad TCP:

Test-NetConnection -ComputerName www.tudominio.es -Port 443

Si el test a 443 funciona pero ping no, el diagnóstico cambia por completo: no es “caída”, es ICMP filtrado (normal en entornos con políticas de seguridad). Esto también explica por qué algunos monitores basados en ping “ven” caídas inexistentes.

2.3 Latencia y geografía: por qué Madrid no es lo mismo que Sídney

La latencia no es solo “el servidor”. La distancia física cuenta, y también el peering entre redes. Por eso alojar infraestructura cerca del público objetivo mejora el tiempo de ida y vuelta. En VisualTec HOST, por ejemplo, operamos con infraestructura propia en el datacenter NLighten de Madrid (Tier III+), lo que suele dar rutas más directas para audiencias en España. Si te interesa el contexto de conectividad y ubicación, tienes más detalle en Datacenter Madrid.

Paso 3 — Traceroute (y MTR): localiza el salto donde empieza el problema

Traceroute muestra los “saltos” intermedios entre tu equipo y el destino. Es la herramienta que convierte una queja difusa (“va lento”) en una pista accionable (“a partir de tal carrier empieza la pérdida”). Y cuando la incidencia es intermitente, MTR suele ser todavía mejor porque repite medidas en bucle y ofrece porcentajes de pérdida por salto.

3.1 Ejecuta traceroute según tu sistema

En Windows:

tracert www.tudominio.es

En macOS/Linux:

traceroute www.tudominio.es

Qué significa lo que ves:

Cada línea es un router (salto) con sus tiempos de respuesta.
Asteriscos (*) indican que ese salto no responde a las sondas (no necesariamente que esté caído).
Si el salto final responde bien, una parte de asteriscos intermedios suele ser normal: muchos routers priorizan tráfico real y degradan respuestas a traceroute.

3.2 La interpretación correcta: dónde “mide” y dónde “falla” no siempre coincide

El error más común con traceroute: culpar al primer salto que muestra latencia alta o pérdida. Un router puede estar configurado para responder lento a ICMP/UDP de traceroute y aun así reenviar tráfico perfectamente. La señal buena es otra: cuando el problema aparece en un salto y se mantiene en todos los siguientes. Si en el salto 6 ves 40% de pérdida y del 7 al final también, ahí sí hay una pista consistente.

3.3 MTR: la versión “de guardia” para problemas intermitentes

Si tienes acceso a mtr (Linux/macOS con instalación previa), ejecuta algo así:

mtr -rwzbc 100 www.tudominio.es

Cómo leerlo:

Loss%: pérdida de paquetes hacia cada salto.
Avg/Best/Wrst: latencia media y extremos; si el “Wrst” es muy alto, suele haber microcortes o congestión puntual.
Consistencia: un único salto “rojo” con los siguientes en verde suele ser falso positivo por rate limiting.

3.4 Caso práctico: caída solo desde una operadora

Escenario típico de soporte: “desde la fibra de X no abre, desde 5G sí”. Con traceroute desde la red que falla, ves que la ruta se queda colgada antes de llegar a la red de destino, o entra por un carrier concreto y a partir de ahí hay pérdida sostenida. Con ese dato, el siguiente paso ya no es “reinicia Apache”: es abrir incidencia con pruebas (traza + hora + IP destino) para que se revise el peering, un bloqueo o un problema de ruta.

En entornos profesionales, esta fase se acelera mucho cuando puedes ejecutar pruebas desde el propio hosting (por ejemplo, desde un acceso SSH). Si trabajas con proyectos donde el diagnóstico fino es parte del día a día, un plan con acceso avanzado facilita el trabajo; en VisualTec esto encaja con Hosting Premium con recursos dedicados y SSH (además de cPanel y aislamiento con CloudLinux), especialmente para equipos técnicos.

3.5 Cuándo parar aquí (y pasar a HTTP)

Si DNS resuelve correctamente, ping no muestra pérdida significativa (o has confirmado que ICMP está filtrado) y traceroute/MTR no detectan un punto claro de degradación sostenida, tu problema probablemente ya no es “conectividad” pura. Suele estar en TCP/TLS o en la capa HTTP: redirecciones infinitas, HSTS, cabeceras de caché contradictorias, compresión, un WAF demasiado agresivo o un backend saturado.

Ahí es donde entran los headers HTTP y pruebas con curl para ver qué responde el servidor realmente, no lo que “parece” en el navegador. Lo veremos en la segunda parte, con ejemplos reproducibles y un checklist para dejarlo documentado.

Paso 4 — Headers HTTP con curl: cuando la web “responde”, pero no como esperas

Si ping y traceroute te dicen “llego” y DNS te dice “resuelvo”, el siguiente cuello de botella suele estar en HTTP. Aquí es donde diagnosticar problemas conectividad web herramientas se vuelve realmente quirúrgico: no miras “si carga”, miras qué está contestando exactamente el servidor (o el CDN/WAF delante), con qué código, qué redirecciones encadena y qué política de caché está aplicando. Y la herramienta más práctica para hacerlo sin depender del navegador es curl, porque te enseña la verdad desnuda: cabeceras, estado y tiempos.

Empieza por una prueba simple de cabeceras, sin descargar el cuerpo:

curl -I https://tudominio.es/

Ese “-I” (HEAD) te devuelve lo esencial: status code, Server, Location, Cache-Control, Content-Type, etc. Si ves un 200 OK, la ruta base responde. Si ves un 301/302, hay redirección; si ves un 403, se está denegando el acceso; un 404 indica recurso inexistente; y un 500/502/503/504 suele implicar problema de backend, saturación o un proxy/CDN que no logra hablar con el origen.

Status codes que “parecen normales” y sin embargo rompen la experiencia

Hay códigos que a simple vista no alarman, pero explican muchos “no carga” intermitentes. Un 301 permanente mal aplicado puede encadenar redirecciones entre http/https o con/sin www hasta que el navegador corta por exceso de saltos. Un 302 o 307 temporal puede estar bien en mantenimiento, pero si se queda instalado provoca cachés inconsistentes: usuarios que entran y otros que no, porque cada uno guarda un estado distinto.

Y luego están los 4xx “selectivos”. Un 403 que solo afecta a ciertas rutas suele ser regla de WAF, bloqueo geográfico o protección anti-bots demasiado agresiva. Un 429 (Too Many Requests) no es “se ha caído”: es rate limiting. La diferencia importa porque la solución cambia: ajustar reglas, permitir IPs, revisar picos, o corregir un plugin que dispara demasiadas peticiones en paralelo.

Redirecciones: sigue la cadena y encuentra el eslabón roto

Para ver la cadena completa, usa:

curl -IL https://tudominio.es/

El “-L” sigue redirecciones y te enseña cada salto. Aquí suelen aparecer patrones clásicos: el primer salto lo gestiona el CDN, el segundo un balanceador, el tercero la app. Si el salto que falla siempre es el mismo, has localizado el punto exacto. Si cambia, huele a configuración inconsistente (varios orígenes con reglas distintas) o a DNS devolviendo IPs diferentes según el resolutor.

Cache-Control, cookies y compresión: rendimiento y “cosas raras” que no son red

Cuando una web “va lenta”, el instinto es culpar a la conectividad. Pero muchas veces el problema está en cómo se están gestionando caché y sesiones. Mira cabeceras como Cache-Control, Expires, ETag y Vary. Una home pública con “no-store” obliga a recalcular siempre; al revés, un exceso de caché en páginas personalizadas provoca que un usuario vea contenido que no le corresponde (o que el login falle por una cookie servida de forma incoherente).

Las cookies merecen lupa. Con curl puedes verlas (sin almacenar nada) con:

curl -I https://tudominio.es/ | grep -i set-cookie

Si aparecen cookies con dominios mal definidos (p. ej., para “www” cuando navegas sin www), el navegador puede crear duplicados y la sesión se convierte en un caos. En WordPress esto se nota como accesos que “entran y salen” del panel, o carritos que se vacían en eCommerce.

Y no te olvides de la compresión. Una respuesta sin gzip/brotli no “tumba” la web, pero multiplica el tamaño a transferir, especialmente en CSS/JS. Revisa “Content-Encoding” y valida que al menos para texto haya compresión:

curl -I -H "Accept-Encoding: gzip" https://tudominio.es/

HTTP/2: menos conexiones, menos fricción… cuando está bien

HTTP/2 permite multiplexar varias solicitudes en una sola conexión TLS. Eso reduce latencias y cuellos de botella típicos (sobre todo en páginas con muchos assets), pero también puede destapar problemas de configuración en proxies o inspección SSL. Comprueba el protocolo negociado con:

curl -I --http2 https://tudominio.es/

Si falla en HTTP/2 pero funciona en HTTP/1.1, no es “internet”: suele ser un punto intermedio que no negocia bien ALPN o que está rompiendo la conexión. Ese dato, en un ticket de soporte, vale oro porque acota el fallo a un componente concreto.

Paso 5 — Diagnóstico TLS/SSL: el candado no basta, hay que validar la cadena

El TLS/SSL es la parte menos visible y más traicionera del camino. En apariencia “hay HTTPS”, pero el navegador puede estar negociando un certificado erróneo por SNI, un intermedio faltante o una cadena mal presentada. Y aquí el síntoma suele ser dramático: avisos de seguridad, errores de “conexión no privada”, bloqueos en pasarelas de pago o recursos mixtos que rompen estilos y scripts.

Con curl puedes ver el handshake con más detalle (sin necesidad de herramientas gráficas) usando el modo verbose:

curl -vI https://tudominio.es/

Busca mensajes de verificación y el CN/SAN del certificado que devuelve. Si aparece otro dominio, tu pista es clara: SNI. SNI (Server Name Indication) es la extensión TLS que permite a un servidor presentar el certificado correcto según el nombre de host. Sin SNI, un servidor con varios sitios puede entregar el certificado “por defecto”, causando el típico error que solo aparece en ciertos clientes o librerías antiguas.

OpenSSL s_client: la lupa para cadena y SNI

Cuando necesitas ver la cadena completa (certificado + intermedios), OpenSSL es el bisturí. Ejecuta:

openssl s_client -connect tudominio.es:443 -servername tudominio.es -showcerts

El “-servername” fuerza SNI. Si al quitarlo el certificado cambia, ya sabes que hay clientes que podrían recibir el equivocado (por ejemplo, integraciones antiguas). Y con “-showcerts” puedes comprobar si faltan intermedios: un error típico es que en algunos dispositivos la cadena no se valida, aunque en Chrome parezca “bien”, porque el navegador trae más intermedios cacheados.

Errores TLS típicos que se confunden con caída

Certificado caducado: el usuario ve bloqueo total, y muchos bots de monitorización también lo reportan como “down”.
Hostname mismatch: el certificado no incluye el dominio exacto (www vs raíz, subdominio olvidado).
Cadena incompleta: algunos clientes validan, otros no; soporte recibe informes “a unos les va y a otros no”.
Handshake timeout: no es DNS ni ping; suele ser saturación, inspección SSL en un proxy o un WAF que corta la negociación.

Relación con SEO y analítica: cuando un fallo de TLS “no solo” afecta a usuarios

HTTPS es un requisito operativo: navegadores y buscadores penalizan experiencias inseguras, y muchas integraciones (pagos, APIs, iframes) directamente se niegan a funcionar sin un TLS correcto. Además, los errores de certificado pueden generar picos de rebote, pérdida de conversiones y rastreo irregular. Si tu estrategia depende de visibilidad orgánica, el TLS no es un check: es infraestructura de confianza.

Si necesitas reforzar este punto en tu stack, tiene sentido centralizar la gestión en una solución robusta y con renovación controlada. En VisualTec HOST puedes apoyarte en la parte de certificados desde /ssl, y combinarlo con una configuración de hosting que no deje cabos sueltos (cadena correcta, redirecciones coherentes y renovaciones automatizadas donde aplique).

¿Cómo saber si el problema está en el CDN/WAF o en el servidor origen?

El problema está en el CDN/WAF cuando la petición no llega al origen o llega “filtrada”, y se identifica porque la respuesta la firma el edge (cabeceras, códigos y patrones de bloqueo), no tu servidor. Dicho de forma práctica: si cambias de ruta, user-agent o IP y el comportamiento cambia radicalmente, normalmente no es Apache ni PHP, es una capa intermedia aplicando reglas.

Empieza por leer cabeceras en busca de pistas: valores de cache, headers de protección, o un “Via”/identificador del proxy (si se expone). Después, fuerza peticiones que suelen activar WAF: por ejemplo, un querystring con caracteres especiales o un POST a /wp-login.php. Si obtienes 403/429 solo en esos casos, tu web “vive”, pero el filtro está siendo demasiado estricto.

En el lado contrario, el origen está fallando cuando el CDN devuelve 5xx asociados a backend (y, sobre todo, cuando ves timeouts). Un patrón muy típico: el HTML carga, pero los endpoints dinámicos (AJAX, API, checkout) dan 502/504. Eso suele indicar saturación de PHP, límites de procesos, consultas lentas o un servicio de base de datos estresado.

Una comprobación limpia consiste en atacar directamente la IP del origen (si la tienes) manteniendo el Host para que el virtualhost responda:

curl -I --resolve tudominio.es:443:IP_ORIGEN https://tudominio.es/

Si por origen funciona y por CDN falla, el culpable se acerca al edge/ruleset. Si por origen ya falla, el problema está “dentro”: servidor, aplicación o base de datos. Ojo: en entornos con protección estricta o anti-DDoS, el acceso directo puede estar intencionadamente limitado; ese “bloqueo” también es un dato válido para el diagnóstico.

Qué mirar en el hosting cuando la conectividad es el síntoma, no la causa

Cuando el diagnóstico de red y DNS sale limpio, la pregunta correcta cambia: ¿está el hosting respondiendo con recursos suficientes y con estabilidad? Aquí es donde la experiencia pesa. En más de 23 años gestionando servidores, el patrón se repite: muchas “caídas” son en realidad picos de carga (PHP saturado, procesos colgados, I/O alto), que se manifiestan hacia fuera como timeouts y 5xx.

Logs: el mapa de la realidad (y por qué conviene separar síntoma y causa)

Los logs son la cronología objetiva. En un hosting con cPanel, el binomio mínimo es: access log (qué se pidió, desde dónde, con qué status) y error log (qué se rompió por dentro). Si ves muchos 404 en rutas de WordPress, puede ser un bot o enlaces rotos; si ves 500 con patrones repetidos, casi siempre hay un plugin/tema o una regla .htaccess provocando fallos.

Un detalle útil: correlaciona timestamp del problema con lo que el usuario hace. “No me carga la ficha de producto” tiene más valor si lo conviertes en “GET /producto/xyz devuelve 504 desde las 10:32 hasta 10:40”. Esa precisión reduce el diagnóstico de horas a minutos.

Límites y aislamiento: cuando el vecino no debe afectar a tu web

En entornos compartidos, el aislamiento marca la diferencia entre “lento de forma aleatoria” y “estable”. CloudLinux es una capa que limita recursos por cuenta para evitar que una web acapare CPU, RAM o procesos, y eso corta de raíz muchos picos contagiosos. Aun así, tu propia web puede llegar a su techo: demasiadas conexiones simultáneas, cron jobs agresivos o un WooCommerce mal optimizado en hora punta.

¿La pista? Errores 508/509 en algunos entornos, 500 intermitentes, o respuestas que pasan de 200 a timeout según la hora. El diagnóstico real aquí no es “internet”: es dimensionamiento y optimización. Para proyectos que necesitan más margen y control, disponer de acceso SSH para revisar procesos, colas y rendimiento cambia el juego; en VisualTec HOST eso encaja con un enfoque de /hosting-premium (recursos más holgados y acceso para tareas avanzadas).

PHP-FPM y OPcache: dos piezas que deciden si tu WordPress “abre” o “suspira”

PHP-FPM es el gestor de procesos PHP: controla cuántas peticiones dinámicas pueden atenderse en paralelo. Si el pool se queda sin workers, el síntoma externo es claro: la web responde a ratos, pero el panel o el checkout se quedan pensando y acaban en 504. En paralelo, OPcache es la caché de bytecode de PHP: evita recompilar scripts en cada request. Sin OPcache (o con una configuración demasiado limitada), cada carga cuesta más CPU y el pico llega antes.

Desde fuera, esto se ve con curl midiendo tiempos (TTFB alto, variación brusca). Desde dentro, se ve en logs y métricas del sistema. La solución rara vez es “reinicia”: suele ser ajustar pools, limpiar cuellos (plugins pesados, queries lentas) y aplicar cachés coherentes por capa (página, objeto, opcode).

Otro clásico: el sitio “va bien” hasta que un bot insiste en un endpoint caro. WordPress, por popularidad (impulsa más del 40% de la web), recibe ruido constante: intentos de login, enumeraciones, scraping. Si además hay búsqueda interna sin limitación o filtros complejos en eCommerce, el consumo se dispara. El resultado exterior es engañoso: parece red, pero es CPU y base de datos al límite.

La receta de diagnóstico: identifica rutas calientes en access logs, mira si coinciden con el momento del incidente, y valida si hay respuestas 200 con tiempos altos. A partir de ahí, bloqueo selectivo, rate limiting, caché y, cuando toca, ajuste de recursos.

Plantilla de reporte para soporte: el ticket que acelera la solución (y el que la retrasa)

Un soporte técnico bueno puede investigar rápido; un soporte técnico excelente, además, te enseña a reportar mejor para que la próxima vez tardes menos. La diferencia entre “mi web no carga” y un reporte útil es estructurar evidencia por capas: DNS, red, HTTP, TLS y aplicación. Si envías el ticket con datos reproducibles, el técnico no tiene que adivinar: puede actuar.

Datos mínimos (cópialos tal cual y rellena)

Dominio afectado: tudominio.es
Fecha/hora del incidente: (zona horaria España)
Desde dónde se reproduce: operador (si se conoce), ciudad aproximada, si ocurre en móvil/Wi-Fi
Síntoma exacto: “timeout”, “error 502”, “certificado no válido”, “login en bucle”, etc.
¿Es total o parcial? “home carga, checkout falla”, “solo /wp-admin”, “solo imágenes”, etc.

Evidencia técnica (pega salida de comandos)

DNS: salida de nslookup/dig (A/AAAA/CNAME) y TTL si aparece
Red: traceroute (resumido) o al menos dónde se corta
HTTP: curl -IL https://tudominio.es/ruta (cadena de redirecciones y status)
Tiempos: curl -o /dev/null -s -w "time_namelookup:%{time_namelookup} time_connect:%{time_connect} time_starttransfer:%{time_starttransfer} time_total:%{time_total}\n" https://tudominio.es/
TLS: error exacto del navegador o salida de curl -vI / openssl s_client

Contexto del cambio (la pista que más se subestima)

Indica si has cambiado algo en las últimas horas: plugin nuevo, reglas de redirección, actualización de WordPress, migración DNS, activación de CDN/WAF, cambios de SSL. En hosting, los incidentes sin “cambio” también existen, pero el 80% de las veces hay una modificación reciente que encaja con el inicio del problema.

Checklist final: buenas prácticas preventivas para no vivir en modo “apagafuegos”

La conectividad web estable no se consigue con un comando mágico, se consigue con disciplina. Cuando aplicas un método —capas, evidencia, reproducibilidad— dejas de perseguir fantasmas. Y lo mejor: el mismo método sirve para incidencias y para optimización.

Normaliza tu set de pruebas: guarda comandos curl y consultas DNS en un documento interno.
Vigila redirecciones y canonicalización: define una versión única (https + www o sin www) y elimina bucles.
Renueva y valida TLS con antelación: revisa cadena e incluye subdominios necesarios.
Activa compresión y cachés coherentes: no-cache donde toque (panel, checkout), caché fuerte en assets estáticos.
Audita endpoints sensibles: login, XML-RPC, búsqueda interna, APIs y cron.
Revisa límites y picos: identifica horarios y rutas que disparan CPU/DB.
Documenta cambios: un changelog simple evita días de hipótesis.

Conclusiones: diagnosticar bien es ahorrar horas (y proteger ingresos)

Una incidencia de conectividad web rara vez es “una cosa”. Es una cadena: DNS que apunta, rutas que atraviesan redes, TLS que negocia, HTTP que decide y, al final, una aplicación que consume recursos. Cuando sigues el orden correcto —ping/traceroute, DNS, headers HTTP y TLS— el ruido baja y aparece la causa. Diagnosticar problemas conectividad web herramientas no es aprenderte cuatro comandos: es aprender a descartar con método y a escribir reportes que un técnico pueda ejecutar sin interpretaciones.

Si tu proyecto ya está en una fase donde cada minuto cuenta (tienda online, captación de leads, campañas de pago), tiene sentido apoyarse en un hosting que reduzca variables: infraestructura sólida, aislamiento real entre cuentas y soporte que responda cuando el problema ocurre, no cuando “ya se pasó”. En VisualTec HOST llevamos desde 2003 operando con infraestructura propia en el datacenter NLighten de Madrid (Tier III+), servidores Dell PowerEdge con NVMe en RAID 10, CloudLinux para aislamiento, Apache optimizado y soporte 24/7/365 en español.

Si estás valorando dar ese salto, puedes revisar los planes de alojamiento en /hosting (con copias diarias, SSL gratuito de Let’s Encrypt y migración incluida) o ir directo a un entorno con más margen y acceso para tareas avanzadas en /hosting-premium. Y si el objetivo es blindar la capa de seguridad y confianza, la ruta natural pasa por /ssl. La diferencia, cuando llega la próxima incidencia, no es solo “que se arregle”: es que sepas exactamente qué ha pasado y por qué.

Preguntas Frecuentes

¿Cómo diagnosticar problemas de conectividad web con herramientas desde casa o la oficina?

Diagnosticar problemas de conectividad web con herramientas consiste en comprobar primero DNS (que el dominio resuelve bien), después latencia/pérdida con ping y, por último, la ruta con traceroute o MTR. Si esas capas están correctas, el foco suele pasar a HTTP/TLS (cabeceras, redirecciones, certificados).

Haz pruebas desde dos redes (por ejemplo, fibra y móvil) para detectar si el fallo es por ISP. Guarda capturas o salidas de comandos con hora, dominio y IP destino: acelera muchísimo cualquier escalado a soporte o a tu equipo de sistemas.

¿Qué es un DNS lookup y por qué ayuda a diagnosticar problemas de conectividad web?

Un DNS lookup es una consulta que traduce un dominio en una dirección IP (A/AAAA) o un alias (CNAME), y sirve para diagnosticar problemas de conectividad web porque detecta IPs antiguas, registros inexistentes o propagación parcial. Si DNS falla, la web puede parecer caída aunque el servidor funcione.

Comprueba el dominio con distintos resolvedores (por ejemplo 1.1.1.1 y 8.8.8.8) para descartar caché. Revisa también si hay diferencias entre www y el dominio raíz, y si IPv6 está implicado.

¿Cómo interpretar ping cuando quiero diagnosticar conectividad web y veo timeouts?

Interpretar ping para diagnosticar conectividad web requiere saber que ICMP puede estar filtrado: un timeout no implica necesariamente caída. Ping es útil para medir latencia y pérdida, pero si falla conviene probar conectividad por puerto (TCP 443) para confirmar si el servicio web responde realmente.

En Windows puedes usar Test-NetConnection a 443; si conecta, el sitio está accesible aunque ping no responda. Si hay pérdida sostenida (aunque sea baja), HTTP puede volverse errático en cargas con muchas peticiones.

¿Cuál es la diferencia entre traceroute y MTR para diagnosticar problemas de conectividad web?

La diferencia entre traceroute y MTR para diagnosticar problemas de conectividad web es que traceroute muestra una foto de los saltos en un momento concreto, mientras que MTR repite mediciones en bucle y da porcentajes de pérdida y latencia por salto. MTR es más útil en cortes intermitentes.

En ambos casos, la señal clave es la pérdida o latencia que aparece en un salto y se mantiene en los siguientes. Un salto aislado con pérdida puede ser rate limiting y no afectar al tráfico real.

¿Cómo saber si el problema de conectividad web es DNS, red o servidor usando herramientas?

Saber si el problema es DNS, red o servidor usando herramientas se basa en un orden: si el dominio no resuelve o resuelve a IP incorrecta, es DNS; si hay pérdida/latencia alta, es red o ruta; si DNS y ruta están bien, el fallo suele estar en servidor/HTTP (códigos, redirecciones, TLS, backend).

Documenta cada paso con la salida del comando y la hora. Con esos datos, un proveedor de hosting o un administrador puede reproducir y acotar si el fallo está en publicación, tránsito o en la aplicación web.

Diagnosticar problemas conectividad web herramientas: guía pro

Índice de contenidos