Cómo investigar un error de red sin adivinar: DNS, TCP y TLS

Una página no abre y el navegador solo dice que hubo un error. En vez de cambiar configuraciones al azar, puedes comprobar por capas dónde se rompe la conexión.

«No hay internet» describe una experiencia, no una causa. Puede fallar la resolución del nombre, la ruta hacia el servidor, la negociación cifrada, el protocolo HTTP o la propia aplicación. El objetivo del diagnóstico inicial es separar esas posibilidades con pruebas pequeñas y observables.

Antes de empezar: define el síntoma

Anota el nombre del host, la hora aproximada, el mensaje de error y si el problema ocurre en un solo equipo, en una red o para todas las personas usuarias. Comprueba también si la dirección funciona desde otra conexión autorizada. No publiques tokens, cookies, direcciones privadas ni salidas que contengan información sensible.

1. ¿El nombre se resuelve? Comprueba DNS

DNS permite consultar registros asociados a un nombre, como las direcciones IP. En Windows puedes usar nslookup; en Linux y macOS, si está disponible, dig resulta útil para inspeccionar la respuesta.

# Windows, Linux o macOS
nslookup example.com

# Linux o macOS, si dig está instalado
dig example.com A
dig example.com AAAA

Revisa si aparece una respuesta y qué servidor DNS contestó. Una respuesta sin dirección puede ser legítima para cierto tipo de consulta; también puede haber diferencias entre IPv4 (registro A) e IPv6 (registro AAAA). Un error de timeout indica que la consulta no obtuvo respuesta a tiempo, pero por sí solo no demuestra que el servidor autoritativo esté caído.

• El nombre no se resuelve: compara con otro nombre conocido y revisa el resolver configurado y la red local.
• Obtienes una IP: DNS funcionó para esa consulta; aún falta comprobar si el servicio responde.
• Solo falla en una red: puede haber caché, configuración del resolver o políticas de red diferentes.

2. ¿Puedes alcanzar el servicio?

Que DNS devuelva una IP no garantiza que el servidor acepte conexiones. Para un servicio HTTPS normalmente se utiliza el puerto TCP 443, aunque la configuración puede ser distinta.

# Windows PowerShell
Test-NetConnection example.com -Port 443

# Linux, si curl está instalado
curl -I --connect-timeout 5 https://example.com/

Test-NetConnection puede informar si la conexión TCP al puerto especificado se estableció. curl -I solicita encabezados HTTP y además puede mostrar errores de resolución, conexión o TLS. Algunos servidores no aceptan solicitudes HEAD, por lo que un estado HTTP inesperado no siempre significa que el sitio completo esté inaccesible.

Un timeout, una conexión rechazada y un error de resolución son resultados diferentes. Un timeout puede deberse a filtrado, pérdida de paquetes, una ruta rota o un servicio que no responde. «Conexión rechazada» suele indicar que el destino respondió pero no aceptó esa conexión; la causa exacta depende del entorno.

3. ¿La negociación TLS funciona?

HTTPS utiliza TLS para proteger la comunicación. Si DNS y TCP parecen funcionar, pero el cliente informa un error de certificado o de negociación, revisa la hora del sistema, el nombre del host, la cadena de certificados y las versiones de protocolo admitidas. No desactives la validación de certificados como solución permanente: elimina una protección importante y puede ocultar un problema real.

# curl muestra detalles de la conexión y los errores TLS
curl -v --connect-timeout 5 https://example.com/

# OpenSSL, si está instalado
openssl s_client -connect example.com:443 -servername example.com

La salida de curl -v puede ayudar a identificar en qué etapa ocurre el error. openssl s_client permite observar información de la negociación TLS y del certificado presentado. La sintaxis y disponibilidad dependen de la versión instalada. No compartas la salida completa sin revisarla antes.

4. ¿El servidor respondió por HTTP?

Si la conexión y TLS se establecen, inspecciona el código de estado y los encabezados:

curl -sS -D - -o /dev/null https://example.com/

Un código 200 normalmente indica éxito para esa petición, mientras que un 301 o 302 indica una redirección. Un 403 suele indicar que la solicitud fue entendida pero denegada; un 404, que no se encontró el recurso solicitado. Un 500 o 503 apunta a un problema del lado del servicio o su disponibilidad, aunque la respuesta puede proceder de una CDN o un proxy y no necesariamente de la aplicación de origen.

Un estado HTTP es una pista, no un diagnóstico completo. Compara la ruta solicitada, los encabezados relevantes y, si administras el servicio, los registros de la aplicación y del proxy.

5. Sigue una secuencia, no una colección de trucos

1. Confirma el host y la ruta exactos que fallan.
2. Consulta DNS y guarda el resultado con hora.
3. Comprueba conectividad al puerto correcto.
4. Revisa TLS sin desactivar la validación.
5. Inspecciona el estado HTTP y las redirecciones.
6. Compara desde un segundo entorno autorizado y cambia una variable por prueba.

Esta secuencia es una guía práctica, no una ley universal. Por ejemplo, un navegador puede utilizar QUIC/HTTP/3 sobre UDP, mientras que las pruebas anteriores pueden comprobar TCP. Un resultado TCP correcto no demuestra que todos los protocolos de transporte funcionen, y una herramienta puede comportarse distinto al navegador por proxy, caché, DNS seguro o configuración local.

Una tabla rápida para orientar la siguiente prueba

• Falla la resolución del nombre: revisa DNS, configuración del resolver y diferencias de red.
• Resuelve, pero no conecta al puerto: revisa ruta, cortafuegos, puerto y estado del servicio.
• Conecta, pero falla TLS: revisa certificado, nombre del host, hora del sistema y compatibilidad.
• TLS funciona y hay un código HTTP: investiga la respuesta, la ruta, las reglas del proxy y la aplicación.
• Las herramientas funcionan pero el navegador no: compara proxy, caché, extensiones, DNS seguro y protocolo utilizado.

Qué registrar para que el diagnóstico sea útil

Guarda el comando utilizado, el momento de la prueba, el resultado esencial, el entorno y la hipótesis que quieres comprobar. Evita guardar secretos o datos personales. En un incidente real, una línea de tiempo con resultados comparables suele ser más valiosa que una captura aislada de un error.

Conclusión

Diagnosticar redes no consiste en memorizar comandos, sino en utilizarlos para distinguir capas. DNS responde a una pregunta diferente de TCP; TCP no verifica TLS; TLS no garantiza que la aplicación entregue el recurso correcto. Si registras qué comprobaste y qué resultado obtuviste, cada prueba reduce la incertidumbre en lugar de añadir cambios al azar.

← Volver a todas las investigaciones