Debugging de Redes

Lo que vas a aprender

A diagnosticar problemas de red como un profesional. Cuando tu API devuelve 502, cuando CORS te bloquea, o cuando "funciona en mi maquina pero no en produccion", sabras exactamente donde buscar.

Al terminar tendras un toolkit mental y practico para resolver los problemas de red mas comunes.

Tu kit de herramientas

curl: La navaja suiza

# GET basico
curl https://api.example.com/health

# Ver headers de respuesta
curl -I https://api.example.com/health

# Ver todo el intercambio (request + response)
curl -v https://api.example.com/health

# POST con JSON
curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"test"}' \
  https://api.example.com/users

# Con autenticacion
curl -H "Authorization: Bearer TOKEN" https://api.example.com/me

# Medir tiempos
curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
  -o /dev/null -s https://api.example.com

ping: Verificar conectividad

# Basico
ping google.com

# Solo 4 paquetes
ping -c 4 google.com

# Si falla: problema de red o DNS
# Si funciona: el servidor responde a ICMP

nslookup / dig: DNS

# Resolver dominio
nslookup api.example.com

# Mas detalle con dig
dig api.example.com

# Ver registros especificos
dig api.example.com A      # IPv4
dig api.example.com AAAA   # IPv6
dig api.example.com CNAME  # Alias
dig api.example.com MX     # Mail servers

netstat / ss: Conexiones activas

# Ver puertos escuchando (Linux)
ss -tlnp

# Ver puertos escuchando (Mac)
netstat -an | grep LISTEN

# Ver conexiones establecidas
ss -tn
netstat -an | grep ESTABLISHED

Escenario 1: "Mi API devuelve 502"

Paso 1: Verificar que el servidor responde

# Primero, verificar DNS
nslookup api.example.com
# Si falla: problema de DNS

# Luego, verificar conectividad
ping api.example.com
# Si falla: servidor caido o firewall

# Finalmente, verificar HTTP
curl -I https://api.example.com/health

Paso 2: Si usas reverse proxy (Nginx)

# Ver logs de Nginx
sudo tail -f /var/log/nginx/error.log

# Errores comunes:
# "upstream timed out" - backend muy lento
# "connection refused" - backend no esta corriendo
# "no live upstreams" - todos los backends caidos

Paso 3: Verificar el backend

# Ver si el proceso esta corriendo
ps aux | grep node  # o python, java, etc.

# Ver si escucha en el puerto correcto
ss -tlnp | grep 3000

# Ver logs del backend
docker logs mi-app --tail 100

# O si es systemd
journalctl -u mi-app -f

Causa mas comun

502 Bad Gateway casi siempre significa:
1. El backend no esta corriendo
2. El backend escucha en puerto diferente
3. El backend tarda mas del timeout de Nginx

Escenario 2: "CORS me bloquea"

Entendiendo CORS

Tu frontend:     https://app.example.com
Tu API:          https://api.example.com

Navegador: "Oye API, mi origen es app.example.com"
API:       "No te conozco, bloqueado"
Navegador: "CORS error!"

Paso 1: Verificar el error exacto

Abre DevTools > Console

Errores comunes:
- "No 'Access-Control-Allow-Origin' header" → Falta header
- "not in the Access-Control-Allow-Origin list" → Origen no permitido
- "Method PUT is not allowed" → Metodo no permitido

Paso 2: Verificar headers con curl

# Simular preflight OPTIONS
curl -X OPTIONS \
  -H "Origin: https://app.example.com" \
  -H "Access-Control-Request-Method: POST" \
  -I https://api.example.com/endpoint

# Buscar estos headers en la respuesta:
# Access-Control-Allow-Origin: https://app.example.com
# Access-Control-Allow-Methods: GET, POST, PUT, DELETE
# Access-Control-Allow-Headers: Content-Type, Authorization

Paso 3: Configurar el servidor

// Express.js
const cors = require('cors');

app.use(cors({
  origin: 'https://app.example.com', // O array de origenes
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true // Si usas cookies
}));

Escenario 3: "El certificado SSL falla"

Paso 1: Verificar el certificado

# Ver detalles del certificado
echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null | openssl x509 -text -noout

# Ver solo fechas
echo | openssl s_client -connect api.example.com:443 2>/dev/null | openssl x509 -dates -noout

# Output esperado:
# notBefore=Jan  1 00:00:00 2024 GMT
# notAfter=Apr  1 00:00:00 2024 GMT

Errores comunes

Renovar con Certbot

# Ver estado de certificados
sudo certbot certificates

# Renovar manualmente
sudo certbot renew

# Renovar un dominio especifico
sudo certbot certonly -d api.example.com

Escenario 4: "Las respuestas son muy lentas"

Paso 1: Medir donde esta la latencia

curl -w "\n\
DNS:        %{time_namelookup}s\n\
Connect:    %{time_connect}s\n\
TLS:        %{time_appconnect}s\n\
TTFB:       %{time_starttransfer}s\n\
Total:      %{time_total}s\n" \
  -o /dev/null -s https://api.example.com/slow-endpoint

# Output ejemplo:
# DNS:        0.023s      <- Resolucion DNS
# Connect:    0.045s      <- Conexion TCP
# TLS:        0.120s      <- Handshake TLS
# TTFB:       2.500s      <- Tiempo hasta primer byte (PROBLEMA!)
# Total:      2.550s

Interpretacion

Si DNS es alto:     Problema de DNS resolver
Si Connect es alto: Latencia de red o servidor lejos
Si TLS es alto:     Problema de certificados/crypto
Si TTFB es alto:    El servidor tarda en procesar
Si Total >> TTFB:   Respuesta muy grande

Paso 2: Diagnosticar el backend

# Ver queries lentas en PostgreSQL
SELECT query, calls, mean_time
FROM pg_stat_statements
ORDER BY mean_time DESC
LIMIT 10;

# Ver procesos activos
SELECT pid, query, state, wait_event_type
FROM pg_stat_activity
WHERE state = 'active';

Cheat Sheet

Comandos esenciales

Status codes

Proximo paso

Practica estos comandos con tus propios servicios. Cuando algo falle, tendras las herramientas para diagnosticarlo.