El billete es clásico: “el sitio funciona en oficina, no en 4G”. Inspeccionas los registros de la aplicación, nada. El certificado TLS es válido. El TTFB es correcto según su seguimiento. Luego, una prueba desde un teléfono revela una página que carga el encabezado, se congela en una imagen pesada o un paquete de JavaScript y termina sin ningún mensaje útil.
No siempre es un error. A veces es un paquete demasiado grande para un túnel y un firewall que se traga los ICMP necesarios para el cambio de tamaño automático.
MTU, fragmentación y PMTUD en dos minutos
La MTU (Unidad de transmisión máxima) es el tamaño máximo de un paquete IP en un enlace; a menudo 1500 bytes en Ethernet, menos en VPN o dispositivos móviles.
PMTUD (Descubrimiento de ruta MTU) permite a los hosts descubrir el tamaño utilizable al recibir ICMP de “fragmentación necesaria”. Si un firewall bloquea estos ICMP, la conexión entra en un agujero negro: los paquetes pequeños pasan, los grandes permanecen bloqueados.
| Contexto | MTU típica | Riesgo |
|---|---|---|
| Centro de datos Ethernet | 1500 | Bajo |
| PPPoE/DSL | 1492 | Medio |
| WireGuard/OpenVPN | 1420-1450 | Alto si no está sujeto |
| GRE / IPsec de sitio a sitio | Varía | Alto |
Un sitio de laboratorio “rápido” puede fallar en la producción móvil porque la ruta de la red, no el código, limita el tamaño del paquete.
Síntomas que deberían hacerte pensar en MTU
Carga parcial (HTML sí, activos no). SSH o HTTPS están bien para solicitudes pequeñas, congelar en transferencias grandes. Problema solo a través de VPN corporativa o de algunos ISP. API REST ligera OK, cargar o descargar colgado.
Correlacione con donde se rompe: cliente, VPN, CDN, equilibrador de carga, servidor.
Diagnóstico paso a paso
Haga ping con No fragmentar
ping -M hacer -s 1472 su-servidor.tld
Reduzca -s hasta que encaje nuevamente. El tamaño útil más 28 bytes (encabezados IP/ICMP) ≈ MTU de ruta.
Utilice mtr o tracepath con tamaños grandes para detectar el salto que está cayendo. En el lado del servidor, marque ip link show en las interfaces del túnel; una MTU explícita demasiado alta es sospechosa. CDN y WAF: algunos túneles entre el borde y el origen tienen su propia MTU; Un origen VPN de sitio a sitio es un caso común.
Soluciones duraderas
Fijación de MSS en el enrutador o servidor VPN. MTU explícita en la interfaz del túnel (WireGuard: MTU = 1420 en la configuración). Permitir ICMP tipo 3 código 4 (se necesita fragmentación) en los firewalls, algo que a menudo se olvida “por seguridad”. tcp_mtu_probing en Linux como último recurso.
No reduzca ciegamente la MTU de toda la interfaz pública sin realizar mediciones: apunte al túnel o enlace infractor.
La cumbre: tu seguimiento no verá el agujero negro
Decide y avanza sin puntos ciegos
Reproduzca desde la red informada (4G, cliente VPN, ISP relevante) antes de tocar el código de la aplicación. Pruebe ping DF y mtr para localizar el salto infractor. Documente la MTU de cada túnel entre usted y el host. Elija un host con soporte de red receptivo a través de nuestra comparación si el problema persiste en el lado de origen.
Preguntas frecuentes
¿Qué es un problema de MTU en la práctica?
Paquetes demasiado grandes más ICMP filtrado: conexión congelada sin error claro en el lado del navegador. Las pequeñas solicitudes pasan, las grandes transferencias fallan silenciosamente.
¿Por qué el problema sólo aparece en determinadas redes?
Las VPN, los túneles y los operadores móviles reducen la MTU efectiva. Sin un PMTUD que funcione, los paquetes grandes no pasan por esta ruta específica.
¿Cómo confirmar un agujero negro de MTU?
ping -M lo hace con tamaños decrecientes, mtr, tracepath, hasta identificar el salto que descarta los paquetes de gran tamaño.
¿Qué ajustar en el lado del servidor o del host?
Abrazadera de MSS, MTU explícita en el túnel, permite la fragmentación ICMP necesaria, tcp_mtu_probing como último recurso.
Cuando una página "falla sin motivo alguno", pregunte: ¿pasan paquetes grandes por esta ruta?, no sólo si el servidor responde.