Cómo diagnosticar y capturar paquetes por intermitencias de red entre contenedores Docker en Debian

Por Kevin Marcondes · Publicado el 30/10/2026 · 10 min de lectura

Las intermitencias de red entre contenedores Docker en Debian suelen ser difíciles de reproducir. La forma más rápida es confirmar la hipótesis con capturas en el punto correcto y pruebas controladas. Aprende a diagnosticar y capturar paquetes para intermitencias de red entre contenedores Docker en Debian usando tcpdump/tshark, nsenter, tc netem y comprobaciones de MTU.

Señales de intermitencia entre contenedores que justifican captura inmediata

La intermitencia rara vez es continua: suele aparecer como latencia variable, resets esporádicos o fallos DNS intermitentes. Si observas alguno de estos signos, prioriza capturar tráfico cerca de los contenedores afectados antes de que el problema desaparezca.

Utiliza esta lista para decidir dónde capturar y qué anotar mientras reproduces el error.

• Picos de latencia en rutas internas (p99 sube, media estable)
• Errores TCP RST al abrir conexiones ocasionalmente
• DNS resuelve a veces y falla otras (NXDOMAIN/timeout)
• Solicitudes gRPC/HTTP2 con streams interrumpidos de forma intermitente
• Logs muestran reintentos y timeouts sin patrón claro
• Diferencia entre tráfico intra‑host vs inter‑host (Swarm/K8s)

Mapa de causas probables y cómo verificar rápido

Usa el mapeo siguiente para ir directo a la hipótesis más probable y al comando que aporta evidencia objetiva. Captura en el host y en el namespace del contenedor cuando sea posible para comparar.

Si ya has visto caídas en redes bridge, profundiza en por qué los contenedores pierden conexión en la bridge y en soluciones en causas y soluciones en Bridge Docker.

¿Cómo saber si la intermitencia es DNS, ruta o MTU?

Sepáralo por capas: primero DNS, luego conectividad/ruta y por último MTU/MSS. Mide cada hipótesis con una prueba determinista que pueda repetirse bajo captura.

Para IPv6 en contenedores y redes bridge en Debian, sigue el paso a paso dedicado en habilitar y depurar IPv6.

• DNS: mide tiempos de resolución y diferencia NXDOMAIN de timeout.
• Ruta: usa tracepath/mtr y compara intra‑host vs inter‑host.
• MTU: prueba ICMP con DF y busca “Fragmentation Needed” en la captura.

# DNS (mede apenas resolução)
time getent hosts api.internal.svc || echo "falha DNS"

# Rota e MTU (Linux)
tracepath -n 10.0.0.25 | sed -n '1,6p'
# PMTUD: DF (do not fragment) e payload próximo a 1500
ping -M do -s 1472 10.0.0.25 -c 3

# TCP handshake cronometrado
TIMEFORMAT=%R; time bash -c 'exec 3<>/dev/tcp/10.0.0.25/443; echo ok >&3; exec 3<&- 3>&-'

¿Qué comando usar para capturar paquetes dentro del contenedor?

La forma más fiable es entrar en el namespace de red del contenedor con nsenter y ejecutar tcpdump/tshark allí. Así evitas mapear manualmente el par veth en el host.

Si prefieres capturar en el host, identifica la veth correcta y usa filtros por IP/puerto del contenedor.

# 1) Descubra o PID do container
eval PID=$(docker inspect -f '{{.State.Pid}}' nome_ou_id)

# 2) Entre no netns do container e capture (arquivo rotativo)
sudo nsenter -t "$PID" -n \
  tcpdump -ni any -w /tmp/cap.pcap -C 50 -W 5 \
  'host 10.0.0.25 and (tcp port 80 or 443)'

# Alternativa: tshark em modo texto
sudo nsenter -t "$PID" -n tshark -i any -Y 'tcp.analysis.retransmission or tcp.flags.reset==1' -T fields \
  -e frame.time -e ip.src -e ip.dst -e tcp.analysis.retransmission -e tcp.flags.reset

Flujo seguro para reproducir y capturar sin tumbar producción

Reproduce el error con tráfico controlado, captura con buffer en disco y delimita la ventana del test. Así cruzas timestamps de aplicación y red con precisión.

Configura filtros de captura antes de iniciar el test para reducir volumen y ruido.

• Define objetivo: IP/puerto y escenario (intra‑host o inter‑host).
• Crea una ventana corta de 2–5 minutos para la prueba.
• Usa ring buffer (-C/-W) para no llenar disco.
• Anota timestamps de inicio/fin e IDs de petición.

# Terminal A: captura rotativa no namespace do cliente
PID_CLIENT=$(docker inspect -f '{{.State.Pid}}' svc_a)
sudo nsenter -t "$PID_CLIENT" -n tcpdump -ni any -w /tmp/cap_a.pcap -C 25 -W 4 'host 10.0.0.25 and tcp'

# Terminal B: tráfego de reprodução (baixa taxa para isolar)
for i in $(seq 1 200); do
  TS=$(date -Is)
  curl -sS --max-time 2 https://10.0.0.25/health || echo "$TS FAIL" >&2
  sleep 0.2
done

# Terminal C: marcação de eventos
echo "START $(date -Is)" >> /tmp/marks.log; sleep 150; echo "END $(date -Is)" >> /tmp/marks.log

# Depois: analisar
sudo nsenter -t "$PID_CLIENT" -n tshark -r /tmp/cap_a.pcap -qz io,stat,1,'COUNT(tcp.flags.reset) tcp.flags.reset==1'

¿Cuándo usar tc netem para simular pérdida y latencia?

Emplea tc netem para reproducir pérdida/latencia y verificar si la aplicación falla en condiciones parecidas a las observadas. Aplícalo en el namespace del contenedor o en la bridge para aislar el alcance.

Importante: netem afecta tráfico real. Aplícalo en un entorno de pruebas o durante una ventana controlada y elimina la regla al finalizar.

# Aplicar latência e perda no netns do container servidor
PID_SRV=$(docker inspect -f '{{.State.Pid}}' svc_b)
nsenter -t "$PID_SRV" -n bash -lc '
  IF=$(ip -o -4 route show default | awk "/default/ {print \$5; exit}")
  tc qdisc add dev "$IF" root netem delay 80ms 20ms loss 1%
  tc -s qdisc show dev "$IF"
'

# Remover	nsenter -t "$PID_SRV" -n bash -lc 'tc qdisc del dev $(ip -o -4 route show default | awk "/default/ {print \$5; exit}") root || true'

MTU y MSS: por qué causan intermitencia y cómo medir

El encapsulamiento y rutas asimétricas pueden reducir la MTU efectiva. Si los ICMP “Fragmentation Needed” no llegan, el handshake puede fallar de forma intermitente. Valida la MTU con ICMP DF y ajusta el MSS cuando sea necesario.

Si usas overlay, considera una MTU menor para la bridge de Docker o ajusta TCPMSS en el host. Reiniciar Docker cambia redes: planifica una ventana, porque interfaces y contenedores pueden reconectarse.

• Prueba PMTUD: busca “Frag needed” en la captura.
• Ajuste provisional: TCPMSS clamp en la salida.
• Ajuste definitivo: MTU consistente en interfaces Docker/host.

# Medir MTU efetiva (ICMP com DF)
ping -M do -s 1472 10.0.0.25 -c 2 || echo "tente tamanhos menores: 1464, 1452, 1432"

# Clamp MSS (temporário) no host
sudo iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN \
  -o docker0 -j TCPMSS --clamp-mss-to-pmtu

# Definir MTU da bridge do Docker (requer restart do serviço)
# /etc/docker/daemon.json
# {
#   "mtu": 1450
# }
# sudo systemctl restart docker  # ATENÇÃO: interrompe redes do Docker momentaneamente

Cómo confirmar que se resolvió y evitar regresiones

Valida con mediciones comparadas: ausencia de errores durante un periodo suficiente, latencias estables y falta de resets/retransmisiones anómalas. Luego institucionaliza pruebas y observabilidad para no volver al punto ciego.

Los health checks y readiness bien configurados evitan cascadas de fallo durante degradaciones.

• Ejecutar mtr/tracepath 15–30 minutos sin pérdida.
• Capturar 5 minutos y confirmar 0 RST inesperados.
• Añadir comprobaciones sintéticas internas (curl con timeout).
• Configurar health/readiness con backoff y circuit breaker.
• Documentar PMTUD/MTU objetivo en el runbook.

# Métrica rápida de retransmissão (deveria ser 0 ou baixo)
sudo tshark -r /tmp/cap_a.pcap -Y tcp.analysis.retransmission -T fields -e frame.number | wc -l

# Health/readiness em apps PHP (exemplos e práticas)
# Veja: health checks e readiness em Docker Compose
# Link: /health-checks-readiness-docker-compose-php

Preguntas frecuentes

¿Necesito instalar tcpdump dentro del contenedor?

No. Es mejor usar nsenter para entrar en el namespace de red del contenedor y ejecutar tcpdump desde el host. Así evitas alterar la imagen y garantizas acceso a cualquier interfaz en el netns. La captura en el host también funciona, pero requiere mapear la veth correcta.

¿Qué interfaz debo capturar: docker0, veth o any?

Para aislar un contenedor, captura dentro del namespace con -i any. En el host, docker0 ve el tráfico bridgeado; la veth del contenedor muestra paquetes específicos de ese servicio. En redes overlay, captura también en la interfaz underlay para ver el encapsulamiento y comprobar la MTU.

¿El tráfico TLS dificulta el análisis?

TLS cifra el contenido, pero los metadatos ayudan: observando handshake, SNI, resets, latencia de intercambio de claves y retransmisiones puedes confirmar intermitencia en la capa de transporte. Combina tcpdump/tshark con logs de aplicación y comprobaciones sintéticas para completar el diagnóstico.

¿Ejecutar tcpdump en producción impacta el rendimiento?

El impacto es bajo si usas filtros y escribes en pcap con buffer rotativo. Evita capturas sin filtro en interfaces muy cargadas. Monitoriza I/O de disco y CPU durante la prueba y limita la ventana de captura a unos minutos.

¿Cómo confirmo un problema de MTU entre contenedores?

Usa ping con DF (-M do) variando el tamaño (-s) y captura ICMP; “Fragmentation Needed” confirma que la MTU efectiva es menor. En TCP observa SYN/SYN-ACK seguidos de RST o handshakes incompletos. Corrige con MTU consistente o clamp de MSS en el camino.

¿Cuándo usar tc netem en vez de pruebas reales?

Usa tc netem para reproducir condiciones difíciles de capturar en vivo, como pérdidas bajas y jitter. Aplícalo en el namespace del contenedor afectado y elimina la regla al finalizar. No sustituye el tráfico real, pero valida la resiliencia de la aplicación bajo degradación controlada.

Ver también

• 502 Bad Gateway intermitente en Docker Compose con Nginx y PHP‑FPM: cómo diagnosticar y corregir timeouts y exceso de conexiones
• Cómo detectar y corregir inconsistencias de SKUs duplicados entre WooCommerce y ERP sin perder pedidos
• Cómo resolver el error 'Too many open files' en Linux en servidores PHP‑FPM durante picos de carga
• Cómo reducir el tiempo de recuperación tras un crash de un servidor Linux con playbook Ansible y runbook de recuperación