Internet por dentro: DNS, HTTP, IP y otros demonios invisibles

Ese momento en el que todo “está bien”… hasta que te cae el screenshot del cliente: “No se puede acceder a este sitio”. Tú vienes de un deploy que “pasó”, el servidor responde, el Wi‑Fi tiene barritas, y aún así el navegador nomás no carga.

Ahí es donde viven los demonios invisibles: DNS, rutas, puertos, TLS, caches, proxies. Cosas que nadie pela… hasta que truena production a las 6:40 pm y tu jefe pide “un cambio en corto” antes del deadline.

La neta, entender internet por dentro no es para sonar pro. Es para que puedas aislar la falla en 10 minutos, no en 3 horas reiniciando el módem y rezándole al santo del rollback.

Qué vas a aprender

• Qué pasa de verdad cuando escribes midominio.com y le das Enter.
• Cómo se encadena DNS → IP → TCP/UDP → HTTP/HTTPS, y por qué una sola pieza rota se siente como “se cayó internet”.
• Un workflow práctico para diagnosticar:
  • “No resuelve el dominio”
  • “Resuelve pero no conecta”
  • “Conecta pero responde mal (HTTP)”
  • “En mi compu jala, en producción no”
• Comandos de batalla (los que sí se usan en el jale): dig, nslookup, ping, traceroute/tracert, curl, openssl s_client.

La película completa en 60 segundos

Cuando metes un URL, tu máquina hace más o menos esto:

1. DNS: “¿Qué IP tiene api.midominio.com?”
2. Red: “¿Puedo llegar a esa IP? (rutas, NAT, firewall)”
3. Transporte: “¿Abre el puerto 443 (TCP)?”
4. TLS (si es HTTPS): “¿El certificado cuadra con el dominio?”
5. HTTP: “Dame /v1/health… y respóndeme 200, no 502.”

Plot twist: “internet” casi siempre sí funciona. Lo que falla es una parte de la cadena.

Escenas muy reales:

• Estás en un coworking con una laptop ya viejita, conectas al Wi‑Fi “Premium_5G”. WhatsApp jala, pero git pull no. Resultado: DNS chafa o proxy metiche.
• En la oficina alguien “endureció seguridad” y cerró salidas. Tu app en staging ya no pega a api.stripe.com. Obvio se descubre el viernes en la tarde.

Guía principal: debug por capas (sin perderte)

Regla de oro: empieza abajo y sube de capa. Si brincas directo a “es el código”, te vas a autosabotear.

1) ¿Es DNS? (el clásico “no resuelve”)

Señales:

• El navegador dice “No se puede encontrar el servidor”.
• curl te suelta: Could not resolve host.

Prueba rápida:

nslookup midominio.com

En macOS/Linux, esto es más claro:

dig midominio.com +short

Si no te regresa IPs:

• Dominio mal escrito (sí pasa, sobre todo con prisas).
• No existe el registro DNS (A/AAAA/CNAME).
• Tu resolver DNS anda fallando (router, oficina, ISP).

¿Quién te está contestando el DNS?

dig midominio.com

Busca SERVER:. Si ves algo como 192.168.0.1, estás usando el DNS del router. En routers baratos eso a veces es una ruleta.

Prueba de realidad: pega a un DNS público

Google: 8.8.8.8 | Cloudflare: 1.1.1.1

dig @1.1.1.1 midominio.com +short

Si con eso sí resuelve, tu bronca no es “se cayó internet”, es tu resolver.

Decisión que te ahorra dolor: si vas a cambiar DNS en producción, respeta el TTL. Ese numerito define cuánto se queda cacheado. Un TTL largo con un cambio mal hecho es receta para drama.

2) ¿Ya tienes IP? Entonces: ¿hay ruta o te están bloqueando?

Si DNS resolvió, agarra una IP y prueba reachability.

Ping (con matices)

ping -c 4 93.184.216.34

Ojo: ping usa ICMP y mucha infraestructura lo bloquea.

• Si ping falla, no significa necesariamente que esté caído.
• Si ping responde, al menos sabes que hay ruta y la IP “vive”.

Traceroute: ¿en dónde se muere el camino?

macOS/Linux:

traceroute 93.184.216.34

Windows:

tracert 93.184.216.34

Si se muere en el primer salto, huele a red local (router, VPN, reglas internas). Si se muere hasta el final, puede ser ISP, peering raro o firewall del destino.

Dato de calle: en México sí se ven rutas raras y congestión en horas pico. No es magia negra, es saturación y acuerdos de peering.

3) ¿El puerto correcto está abierto? (TCP/UDP)

Para web casi siempre:

• HTTP: 80/TCP
• HTTPS: 443/TCP

Prueba con curl para validar puerto + HTTP:

curl -I http://midominio.com
curl -I https://midominio.com

Si sale:

• Failed to connect → firewall, servicio caído, puerto cerrado, security group, etc.
• Connection timed out → más a bloqueo o ruta que a “la app tronó”.

Con nc (netcat):

nc -vz midominio.com 443

4) ¿Es bronca de TLS/HTTPS? (certificados, SNI, cadena)

Señales:

• El navegador te asusta con “Tu conexión no es privada”.
• curl se queja de SSL certificate problem.

Prueba con:

openssl s_client -connect midominio.com:443 -servername midominio.com

Cosas que valen oro revisar:

• El cert coincide con el dominio (CN/SAN).
• No está expirado (sí pasa, y duele).
• El servidor entrega la cadena completa (intermediate certs).

Decisión de arquitectura que pega: si estás detrás de un load balancer, a veces el TLS termina ahí y el backend habla HTTP interno. Si alguien movió TLS al backend “nomás porque sí”, puedes romper clientes, health checks o proxies sin avisar.

5) Ya estás en HTTP: ahora sí, toca ver si es la app (o el reverse proxy)

HTTP no es “carga o no carga”. Te da pistas con status codes.

curl -v https://midominio.com/health

• 200: ok.
• 301/302: redirecciones (ojo con loops).
• 401/403: auth/permisos/WAF.
• 404: ruta no existe (o el proxy apunta a otro lado).
• 500: truena app.
• 502/503/504: gateway/proxy/backends caídos o lentos.

Ejemplos típicos:

• Tu app está bien, pero Nginx apunta a un upstream que ya no existe → 502.
• El backend tarda 60s y el LB corta en 30s → 504.

Headers que te cuentan el chisme

curl -I https://midominio.com

Busca:

• server: (nginx, cloudflare, envoy…)
• via: (proxies)
• x-cache: (CDN)
• set-cookie: (sesión)

Tradeoff real: CDNs y caches son magia… hasta que te sirven contenido viejo. Si “ya hiciste el cambio” y “no se ve”, antes de quemar todo revisa cache (y si aplica, purge o Cache-Control: no-cache).

Diagnóstico express (10 minutos, sin pánico)

Este es mi workflow cuando alguien suelta “se cayó el sitio” y tú estás a media talacha:

Paso 1: ¿es tu red o es general?

• Prueba desde tu cel con datos (sin Wi‑Fi).
• Si usas VPN del trabajo, prueba con y sin VPN.

Si con datos sí jala pero con Wi‑Fi no, ya tienes el olor: red local/DNS/proxy.

Paso 2: DNS

dig midominio.com +short

• Si no hay IP, es DNS.
• Si hay IP, guárdala.

Paso 3: ruta

traceroute <IP>

• Si muere al inicio, es tu red.
• Si muere al final, destino/firewall.

Paso 4: puerto

nc -vz midominio.com 443

• Si no abre, es red/puerto/reglas.

Paso 5: HTTP

curl -v https://midominio.com/

• Revisa status code.
• En el -v fíjate a qué IP se conectó.

Paso 6: si el bug es “solo en producción”

• Compara variables de entorno.
• Revisa DNS split-horizon (interno vs externo).
• Confirma que el hostname en producción apunte al LB correcto.

Screenshots sugeridos

• Terminal con dig midominio.com mostrando SERVER: y la ANSWER SECTION.
• curl -v https://... donde se vea: resolución DNS, conexión a IP, handshake TLS y status HTTP.
• Output de traceroute con hops y dónde se corta.
• Config de DNS (Cloudflare/Route53) mostrando A/CNAME y TTL.
• Error típico de certificado en navegador (para reconocerlo, no para espantar).

Errores comunes (y cómo salir del hoyo)

“Ya cambié DNS y no se refleja”

Causa: TTL + caches (tu compu, router, ISP, navegador).

Cómo lo destrabas:

• Espera lo que definiste en TTL (sí, aunque duela).
• Prueba con otro resolver:

  dig @8.8.8.8 midominio.com +short
  dig @1.1.1.1 midominio.com +short
  

• Haz flush de cache DNS local (varía por sistema operativo).

“A mí me carga, al cliente no”

Causa típica: el cliente resuelve a otra IP (GeoDNS/CDN), trae proxy corporativo, o cache.

Cómo lo aterrizas:

• Pídele que corra nslookup y te pase la IP que ve.
• Confirma si hay CDN/WAF en medio.

“502 Bad Gateway” y todos culpan al backend

Causa típica: upstream mal configurado, health checks fallando, DNS interno del contenedor, o el backend se muere bajo carga.

Cómo lo atacas:

• Revisa logs del reverse proxy (Nginx/Envoy/ALB).
• Si puedes, pega directo al backend desde la misma red.

“El certificado está bien… según yo”

Causa: cert para otro dominio, falta cadena intermedia, SNI incorrecto.

Cómo lo confirmas:

• openssl s_client con -servername (SNI) y validar SAN/fechas.

“No conecta desde la oficina, desde casa sí”

Causa: firewall/proxy corporativo, DNS interno, puertos bloqueados.

Cómo lo acotas:

• Prueba con curl -v y revisa si está saliendo por proxy.
• Pregunta si existe whitelist para dominios/puertos.

Checklist final (para que no te gane el viernes en la noche)

• ¿Desde datos móviles también falla? (descarta tu Wi‑Fi)
• dig +short devuelve IP(s)
• dig muestra qué DNS server responde
• traceroute/tracert llega (o al menos no muere al inicio)
• Puerto 443/80 abre (nc -vz o curl -I)
• TLS ok (openssl s_client si hay bronca)
• curl -v muestra status code y headers
• Si hay CDN/cache: considerar purge/TTL
• Si es prod: revisar LB/health checks/logs del proxy

FAQ

1) ¿DNS y IP no son lo mismo?

No. DNS es la libreta de contactos (nombre → número). IP es el número (dirección) al que realmente te conectas. Puedes cambiar una IP sin cambiar el nombre, o al revés.

2) ¿Por qué ping falla pero el sitio sí abre?

Porque ping usa ICMP y muchos firewalls lo bloquean. Para web, curl al puerto 80/443 representa mejor lo que te importa.

3) ¿Qué cambia entre HTTP y HTTPS al hacer debug?

HTTPS agrega TLS (certificados, SNI, cadena). Puedes tener HTTP “bien” y HTTPS roto por un cert expirado o mal configurado.

4) ¿Qué son 502/503/504 y por qué salen tanto?

Son errores del intermediario (LB, Nginx, CDN): tu request sí llegó a un gateway, pero ese gateway no pudo hablar con el backend o se tardó demasiado.

5) Si solo memorizo un comando, ¿cuál?

curl -v. Te enseña DNS, conexión, TLS y respuesta HTTP en una sola corrida. Es linterna para el cuarto oscuro.

Siguiente episodio

Ya que puedes ver a los demonios invisibles, el siguiente paso es capturar tráfico y leerlo sin miedo.

Spoiler: DevTools y Wireshark para ver qué pasa cuando “solo era un endpoint”.