La Unidad Máxima de Transmisión (MTU) es el tamaño máximo de paquete que un enlace de red puede transportar sin fragmentación, y el valor predeterminado estándar para la mayoría del tráfico de internet es 1,500 bytes. En términos prácticos, la configuración de MTU determina cuántos datos tu interfaz puede colocar en un paquete antes de que la red deba dividirlo o descartarlo.
Puedes tener una conexión de proxy saludable, IPs rotativas y un panel de automatización receptivo, y aun así ver que páginas individuales fallan, cargas se estancan o sesiones de inicio de sesión desaparecen. La causa suele ser un desajuste en el tamaño de paquete entre un centro de datos de alta MTU o un segmento de VPN y un camino móvil de baja MTU. Tu scraper no necesariamente es lento. Puede estar enviando paquetes que un enlace oculto no puede transportar.
Por qué tu scraper falla incluso cuando la conexión parece estar bien
Un trabajo de scraping puede pasar su chequeo de salud y aun así fallar en el trabajo real. El proxy se autentica, el objetivo responde y la primera página se carga. Luego, una respuesta más grande, una presentación de formulario o una solicitud pesada en medios se queda colgada mientras otros destinos continúan funcionando.
Ese patrón engaña a los equipos porque los indicadores obvios parecen normales. DNS funciona, el socket se abre y la rotación de IP se comporta como se espera. La falla parece ser específica del destino o de la sesión, pero el problema subyacente puede ser un paquete que excede la MTU más pequeña en algún lugar entre tu trabajador, proxy, red de transporte y objetivo.
Regla práctica: Si las solicitudes pequeñas funcionan pero las transferencias más grandes se estancan, investiga el tamaño del paquete antes de culpar al ancho de banda o a la rotación del proxy.
Esto es importante en flujos de trabajo legítimos. Un equipo de redes sociales puede cargar un perfil pero fallar durante la configuración de la cuenta. Un proceso de verificación de anuncios puede recuperar la estructura de la página pero perder un script o respuesta de seguimiento. El monitoreo de precios puede recoger algunas páginas de productos mientras se agota el tiempo en una región o flujo de pago particular.
Por lo tanto, el mismo proxy puede parecer confiable en una prueba e inestable en producción. Un camino de centro de datos puede soportar paquetes más grandes localmente, mientras que un túnel de VPN o una ruta celular móvil impone un límite más pequeño. Si el remitente no se entera de ese límite, los paquetes sobredimensionados pueden ser fragmentados, descartados o retransmitidos repetidamente.
La pregunta práctica detrás de qué es una configuración de MTU no es solo “¿qué número debo ingresar?” Es si el tamaño del paquete sigue siendo seguro a lo largo de toda la ruta que utiliza tu automatización.
Definiendo la Configuración de MTU y su Función Principal
Una configuración de MTU es el tamaño máximo de paquete que una interfaz puede transmitir a través de un enlace sin fragmentación. La configuración pertenece a una interfaz de red, por lo que tu laptop, host de proxy, adaptador de VPN, contenedor, enrutador y puerta de enlace celular pueden tener diferentes límites.
En Ethernet estándar, la MTU ampliamente adoptada es 1,500 bytes. Ese número describe la carga útil transportada por el marco de Ethernet, no el marco completo en el cable. Un marco estándar de Ethernet II totaliza 1,518 bytes, combinando la carga útil de 1,500 bytes con 14 bytes de encabezado y 4 bytes de sobrecarga de secuencia de verificación de marco, como se documenta en la explicación de AWS sobre la MTU de red.
Qué sucede cuando los datos alcanzan el límite
Tu aplicación crea datos. Protocolos de transporte como TCP o UDP envuelven esos datos, IP agrega su encabezado y la interfaz coloca el paquete resultante en un marco. La MTU establece el límite superior para el paquete transportado a través de ese enlace.
Para un camino de Ethernet estándar, una MTU de 1,500 bytes deja 1,460 bytes para la carga útil de TCP, después de tener en cuenta un encabezado IP de 20 bytes y un encabezado TCP de 20 bytes, según la guía de Cisco sobre MTU y TCP MSS. Si un paquete es demasiado grande para la interfaz saliente, la red debe fragmentarlo o descartarlo, dependiendo del protocolo y la configuración.
Esa distinción te proporciona un vocabulario útil para la resolución de problemas:
- MTU de interfaz: El paquete más grande que una interfaz específica puede transportar sin fragmentación.
- MTU de ruta: El paquete más grande que puede cruzar la ruta completa de manera segura.
- Fragmentación: Dividir un paquete sobredimensionado en piezas más pequeñas.
- MSS: El límite de carga útil de TCP negociado entre los puntos finales.
El valor predeterminado se mantiene porque ofrece una amplia compatibilidad a través de redes de acceso a internet. Los marcos más grandes pueden ser eficientes en una red interna controlada, pero se vuelven arriesgados cuando un túnel, enlace de transporte, cortafuegos o dispositivo intermedio soporta menos.
Cómo la MTU Impacta la Latencia, el Rendimiento y la Fragmentación
La MTU afecta el rendimiento a través del conteo de paquetes y el manejo de fallas. Los paquetes más grandes transportan más carga útil por transmisión, por lo que generalmente reducen la sobrecarga del protocolo y el número de paquetes que tu sistema debe procesar. Los paquetes más pequeños son más fáciles de encajar a través de caminos restringidos, pero utilizan el ancho de banda de manera menos eficiente.
Un desajuste crea el peor resultado. La guía de MTU de Alibaba Cloud da un ejemplo claro: un paquete de 2,000 bytes cruzando un enlace de MTU de 1,500 bytes se divide en fragmentos de 1,500 bytes y 500 bytes. El receptor debe reensamblar esas piezas, y un fragmento perdido puede forzar la retransmisión de los datos afectados.
Por qué la fragmentación perjudica la automatización
La fragmentación añade trabajo en múltiples puntos:
- El remitente o enrutador divide el paquete.
- La red transporta múltiples fragmentos en lugar de un solo paquete.
- El receptor rastrea y reensambla los fragmentos.
- Un fragmento faltante puede retrasar la entrega o activar la retransmisión.
Ese procesamiento adicional puede aumentar la latencia y reducir el rendimiento efectivo. También crea más oportunidades para que un cortafuegos, dispositivo NAT o puerta de enlace de transporte maneje mal el tráfico. Un scraper puede seguir informando una conexión abierta mientras la aplicación espera un fragmento que nunca llega.
El error opuesto es establecer paquetes demasiado pequeños en todas partes. Los paquetes pequeños evitan muchos problemas de límite de ruta, pero aumentan el conteo de paquetes y reducen la eficiencia de la carga útil. Eso puede consumir más CPU y crear una sobrecarga de protocolo innecesaria, especialmente para transferencias sostenidas.
Ajusta para el camino, no para la interfaz más rápida
Una interfaz de centro de datos de alta MTU no hace que una ruta móvil sea de alta MTU. Una VPN puede añadir sobrecarga de encapsulación, y un operador celular puede imponer un límite efectivo más bajo. El objetivo útil es el tamaño de paquete más grande que se mantenga por debajo de cada límite de enlace relevante.
Mide la latencia junto con el comportamiento de los paquetes, no en lugar de ello. Un flujo de trabajo práctico de medición de latencia puede mostrar si un cambio reduce el retraso, pero un resultado de latencia limpio por sí solo no prueba que los paquetes más grandes crucen la ruta de manera confiable.
Para la automatización, evita cambiar la MTU solo para perseguir una ganancia teórica de rendimiento. Primero identifica si las fallas se correlacionan con respuestas más grandes, cargas o tráfico tunelizado. Si lo hacen, una MTU conservadora y probada de manera consistente generalmente supera un valor agresivo que solo funciona en el segmento local.
Entendiendo el Descubrimiento de MTU de Ruta y los Valores Predeterminados Comunes
La interfaz local solo conoce su propio límite. El Descubrimiento de MTU de Ruta, o PMTUD, determina el paquete más grande que puede viajar desde el remitente a un destino particular sin fragmentación. Ese valor puede cambiar cuando cambia la ruta, por lo que no es una propiedad universal de la máquina o proxy.
RFC 8201 describe el PMTU como vinculado a un camino específico y establece que el PMTU inicial se asume como la MTU del enlace de primer salto. RFC 4821 explica que cuando no hay retroalimentación útil de ICMP disponible, los puntos finales pueden sondear con paquetes sucesivamente más grandes para descubrir un tamaño funcional.
MTU de interfaz versus MTU de ruta
Considere un host de trabajo con una interfaz local configurada para 1,500 bytes. Su solicitud entra en una VPN, cruza una puerta de enlace proxy, viaja a través de una red de transporte y llega a un destino. El tamaño seguro del paquete está gobernado por el límite efectivo más pequeño a lo largo de esa ruta.
La situación inversa es más peligrosa para las operaciones de proxy. Un host o segmento de centro de datos puede soportar un paquete más grande, pero un túnel o camino de acceso móvil puede no hacerlo. Aumentar el valor local no incrementa la capacidad del camino remoto. En cambio, puede producir fragmentación o pérdida silenciosa cuando el paquete llega al salto restringido.
Los tramas jumbo pertenecen a entornos controlados donde cada dispositivo soporta el mismo tamaño de trama más grande. No son un valor predeterminado sensato para una ruta que incluye caminos de internet público, túneles de terceros o infraestructura celular cambiante.
Por qué PMTUD puede parecer inconsistente
PMTUD se basa en que los puntos finales y los dispositivos de red se comuniquen sobre los límites de los paquetes. Si la retroalimentación está bloqueada o se pierde, el remitente puede continuar utilizando un tamaño inadecuado. El resultado es una conexión que se establece con éxito pero se detiene una vez que la aplicación envía cargas útiles más grandes.
Utilice pruebas separadas para:
- Capacidad de la interfaz local, que confirma el MTU configurado.
- Capacidad del camino, que prueba paquetes a través de la ruta real.
- Comportamiento de la aplicación, que confirma que el proxy y el objetivo manejan transferencias más grandes.
Un pequeño ping que funcione no despeja el camino. Solo prueba que un paquete pequeño realizó el viaje. Para el scraping, la prueba relevante es si los patrones de solicitud y respuesta utilizados por el trabajo permanecen por debajo del límite efectivo del camino.
Proxies móviles, CGNAT y restricciones únicas de red
Un scraper puede funcionar de manera confiable a través de un proxy de centro de datos, y luego detenerse en una salida móvil incluso cuando ambas conexiones parecen saludables. La diferencia suele ser el MTU efectivo del camino, no el tiempo de respuesta del proxy.
Un proxy de centro de datos típicamente utiliza infraestructura con interfaces predecibles y redes locales controladas. Un proxy residencial sale a través de una conexión de acceso doméstico o fijo, por lo que el proveedor de acceso y el enrutador local moldean la ruta. Un proxy móvil utiliza una conexión celular 4G o 5G, con enrutamiento de operador y NAT entre el dispositivo proxy y el internet público.
Los proxies móviles comúnmente operan detrás de NAT de grado de operador, o CGNAT. Muchos suscriptores comparten un grupo más pequeño de direcciones IPv4 públicas. El diseño compartido también puede introducir capas adicionales de reenvío y variación de ruta, por lo que la dirección pública por sí sola no describe el camino de la red.
Por qué el tipo de proxy cambia el problema del MTU
Un enlace de centro de datos o VPN puede soportar un MTU de Ethernet familiar. Un camino móvil puede tener un límite efectivo más bajo porque el tráfico cruza infraestructura de acceso por radio, redes de operadores, NAT y a veces un túnel antes de llegar al objetivo. La encapsulación consume espacio en el encabezado. Por lo tanto, los paquetes que caben en el enlace de origen pueden exceder el límite del camino móvil.
El fallo puede ser silencioso. Una conexión puede establecerse, solicitudes pequeñas pueden tener éxito y respuestas más grandes pueden detenerse cuando la retroalimentación del MTU del camino está bloqueada o un paquete es descartado. Pruebe la ruta completa en lugar de copiar un valor de interfaz de centro de datos en una configuración móvil o VPN. Un camino que utiliza conectividad LTE puede seguir siendo utilizable mientras requiere un tamaño de paquete seguro más pequeño.
Opciones de transporte y targeting
La elección del transporte es importante porque la encapsulación adicional reduce la carga útil disponible para la aplicación. SOCKS5 puede transportar tráfico más allá de las solicitudes web ordinarias, por lo que su perfil de tráfico puede exponer problemas de MTU que una simple solicitud de navegador no. Tenga en cuenta la capa de proxy, la sobrecarga de VPN y cualquier otro túnel al probar el tamaño del paquete.
El targeting puede cambiar la ruta. La selección de país, ciudad o ASN puede colocar una solicitud en otro operador o red de acceso. Un ASN, o número de sistema autónomo, identifica el dominio de enrutamiento de un operador de red. Dos objetivos con la misma configuración de país aún pueden usar diferentes caminos y mostrar un comportamiento de MTU diferente.
Mantenga la rotación de IP separada de las pruebas de paquetes. La rotación cambia la identidad de salida y puede cambiar la ruta, mientras que una sesión persistente mantiene solicitudes relacionadas en una identidad de proxy para un flujo de trabajo definido. Para la gestión de cuentas, verificación de anuncios o QA dependiente de la geolocalización, el enrutamiento consistente a menudo importa más que cambiar la identidad en cada solicitud. Pruebe el comportamiento de la sesión y la estabilidad del camino juntos.
Cómo verificar y cambiar el MTU en los principales sistemas operativos
Comience verificando la interfaz que transporta el tráfico. Un valor local es evidencia sobre un enlace, no prueba del límite del camino.
Windows
Abra una terminal con privilegios de administrador y muestre los valores de la interfaz:
netsh interface ipv4 show subinterfaces
También puede inspeccionar los detalles del adaptador con:
ipconfig /all
Para un ajuste temporal, use el nombre de la interfaz mostrado por el primer comando:
netsh interface ipv4 set subinterface "Nombre de la Interfaz" mtu=1500 store=active
Cambie el valor solo después de probar. Evite ediciones del registro para trabajos rutinarios de MTU, porque la interfaz activa y la ruta pueden no ser las que usted piensa que son.
macOS
Liste las interfaces y sus configuraciones actuales:
ifconfig
Para un cambio temporal, reemplace en0 con la interfaz que transporta la ruta:
sudo ifconfig en0 mtu 1500
La configuración puede restablecerse después de un cambio de red o reinicio, así que use la configuración de red del sistema operativo si necesita persistencia.
Linux
Inspeccione las interfaces con:
ip link show
Pruebe un valor temporal:
sudo ip link set dev eth0 mtu 1500
Para una configuración persistente, use el administrador de red de la distribución o la configuración de red declarativa. No cambie solo la interfaz física si una VPN, puente de contenedor o interfaz virtual transporta el tráfico de automatización.
Pruebe progresivamente en lugar de hacer un gran salto. El valor correcto es el límite efectivo mínimo a lo largo de la ruta, y un MTU local más alto aún puede fallar en un enlace intermedio más pequeño. La guía de configuración de MTU de Cisco enfatiza esta distinción entre el MTU por interfaz y el MTU del camino.
Síntomas de solución de problemas y mejores prácticas para la automatización
Los fallos de MTU tienden a ser selectivos. Una conexión puede autenticarse, cargar un documento pequeño y luego fallar cuando la respuesta o la carga se vuelve más grande. Busque:
- Cargas parciales de página: HTML llega, pero scripts, imágenes o respuestas de API se detienen.
- Caídas de sesión: Flujos de trabajo de inicio de sesión o carga fallan después de la negociación inicial.
- Errores específicos de destino: Un sitio falla mientras que otro funciona a través de la misma interfaz local.
- Resultados de rotación inconsistentes: Algunas salidas de proxy completan un trabajo, mientras que otras se agotan porque sus caminos difieren.
- Fallos solo de VPN: El tráfico directo funciona, pero el tráfico encapsulado se rompe bajo carga.
Un paquete más grande que el MTU de salida puede ser descartado incluso cuando la interfaz local parece configurada correctamente. Se puede indicar a la fuente que reduzca su MTU de camino, pero si esa retroalimentación no llega al remitente, la aplicación puede seguir retransmitiendo un tamaño de paquete inadecuado, como se explica en la guía de descubrimiento de MTU de camino.
Una lista de verificación operativa práctica
- Captura la ruta. Prueba el trabajador, túnel, tipo de proxy, región objetivo y destino juntos.
- Compara categorías de proxy. No asumas que un resultado de centro de datos predice el comportamiento residencial o móvil.
- Preserva sesiones donde sea necesario. Usa sesiones persistentes para flujos de trabajo de múltiples pasos, luego prueba la rotación por separado.
- Verifica el transporte. Compara el tráfico HTTP/S con SOCKS5 cuando la aplicación soporte ambos.
- Prueba cargas útiles más grandes. Las solicitudes pequeñas pueden pasar mientras que las respuestas masivas fallan.
- Reduce con precaución. Reduce el MTU de la interfaz o túnel en pasos controlados, luego vuelve a probar el trabajo exacto.
- Monitorea la estabilidad. Revisa prácticas de estabilidad de red junto con latencia, tiempos de espera, retransmisiones y errores de aplicación.
- Mantén la conformidad en el alcance. Usa automatización para investigación autorizada, gestión de cuentas, verificación de anuncios, monitoreo de precios, protección de marca y QA, y sigue las reglas de cada plataforma.
La mejor configuración no es el número más grande en una interfaz. Es el valor seguro más grande que funciona de manera consistente a lo largo de toda la ruta de la que depende tu proceso empresarial.
Evoproxy proporciona conectividad de proxy móvil 4G, LTE y 3G para equipos que gestionan redes sociales de manera conforme, verificación de anuncios, investigación de mercado, QA geodependiente y flujos de trabajo de monitoreo. Visita Evoproxy para probar una ruta móvil y evaluar cómo se comporta su ruta de operador con tus sesiones, cargas útiles y requisitos de MTU.
