Cómo optimizar transferencias masivas en LAN en Windows

Inicio » Windows » Cómo optimizar transferencias masivas en LAN en Windows

Cuando intentas mover decenas o cientos de gigas por la red local en Windows y ves que la velocidad pega un subidón al principio para luego desplomarse, la sensación es de estar tirando el tiempo a la basura. Da igual que tengas un router gigabit, cables nuevos y ambos equipos conectados por cable: si la copia se queda en 10-30 MB/s, algo en la cadena se está atragantando.

La parte buena es que, si el hardware no es una patata, casi siempre hay margen para acercarse mucho al límite real de tu LAN. Combinando ajustes de Windows, revisando bien el cableado y los equipos de red, afinando SMB y usando herramientas de copia adecuadas, es perfectamente posible mover proyectos de vídeo de 80-100 GB de forma bastante más rápida y estable, tanto en Windows 7 como en Windows 10 y 11.

Causas habituales de transferencias lentas en LAN con Windows

Lo primero es entender por qué una red que “va fina” para navegar o ver vídeos puede ir a pedales al copiar archivos grandes. En la mayoría de escenarios, no hay un único culpable, sino la suma de varios factores que, combinados, tiran por tierra el rendimiento real.

En el caso típico de un servidor de archivos con Windows Server 2022 Datacenter y clientes con Windows 7, 10 y 11 (mezcla de Home y Pro), es bastante frecuente que las copias hacia el servidor se queden en torno a 10-30 MB/s (unos 100-300 Mbit/s) pese a tener infraestructura gigabit. Esto no es un límite “normal” de SMB, suele haber algo más detrás.

Entre las causas más habituales de velocidad baja o inestable al transferir en LAN en Windows encontramos una buena lista de sospechosos:

• Red limitada a 10/100 Mbps por un switch o router antiguo, o por un adaptador sin soporte gigabit.
• Cableado deficiente: cables Cat5 viejos, conectores mal crimpados, tiradas largas en paralelo a líneas eléctricas, hubs en vez de switches, etc.
• Discos lentos o saturados (especialmente HDD mecánicos muy llenos o con mucha fragmentación) que no pueden seguir el ritmo de la red.
• Software antivirus, antimalware y de protección de endpoint analizando cada archivo que entra o sale, disparando CPU y latencias.
• Funciones avanzadas de la NIC mal llevadas, como Large Send Offload (LSO) o otras opciones de offloading que con ciertos drivers rinden peor desactivadas.
• Programas VPN, proxys o inspección de tráfico que fuerzan a que el flujo SMB “pase por el aro” de cifrados y reescrituras innecesarias en una LAN local.
• Controladores y firmware desactualizados en tarjetas de red, switches, routers o controladoras de almacenamiento.
• Configuraciones de Windows poco óptimas: Compresión Diferencial Remota (RDC), autoajuste TCP, Jumbo Frames mal configurados, etc.
• Servidores NAS o cabinas (por ejemplo, My Cloud) ocupados indexando, generando miniaturas o haciendo copias de seguridad mientras reciben datos.
• Escenarios de DFS mal resueltos, con rutas de acceso UNC caídas o referencias DFS remotas que generan retrasos constantes.

Además, hay que asumir una realidad incómoda: la velocidad teórica de la red y la real no tienen nada que ver. Aunque una LAN gigabit prometa 125 MB/s, en el mundo real lo normal son valores sostenidos de 30-60 MB/s, y en Wi‑Fi las cifras caen todavía más, sobre todo en 2,4 GHz.

Revisión de la capa física: NIC, cables, switches y discos

Antes de tocar configuraciones “mágicas” de Windows, conviene asegurar que la base no hace aguas. Si la capa física es mala, el mejor ajuste de SMB del mundo no va a salvar la situación.

En el lado de los equipos Windows, el primer filtro es claro: revisa si el adaptador de red y el puerto al que está conectado negocian a 1,0 Gbps Full Dúplex. En el propio Windows, desde las propiedades del adaptador o el Centro de redes, puedes ver la velocidad. Si ves 100 Mbps, ya tienes un cuello de botella clarísimo.

Por otro lado, los ordenadores muy antiguos, con CPU de 32 bits y poco RAM, suelen traer tarjetas de 10/100 Mbps y, aunque soporten Windows modernos, les cuesta procesar grandes volúmenes de datos, sobre todo si se usan a la vez para otras tareas. En esos casos, actualizar el adaptador a gigabit y cerrar programas que comen CPU y memoria marca bastante diferencia.

El cableado también tiene mucho que decir. Usar cables Cat6 o superiores, conectados a switches gigabit de verdad y evitar hubs es fundamental. Un simple hub o un conmutador de baja gama saturado por streaming, copias de seguridad y otros tráficos puede hundir la experiencia de copia de archivos.

No hay que olvidar los discos: una unidad mecánica fragmentada, casi llena, que aloja a la vez el sistema, las copias y los servicios de servidor de archivos, puede ser el tapón principal. Copiar en local dentro del propio servidor (por ejemplo, de una carpeta a otra del mismo volumen) es una prueba rápida: si ya ahí va lento, antes de culpar a la red hay que revisar controladores de almacenamiento, desfragmentación en HDD, TRIM en SSD y el propio estado físico de las unidades.

Velocidades teóricas vs velocidades reales en redes domésticas y de oficina

Para poner los números en contexto, conviene saber qué se considera razonable en el mundo real. Las especificaciones hablan de megabits por segundo, pero lo que vemos al copiar en Windows son megabytes por segundo, y ahí suele venir la confusión.

Algunos ejemplos orientativos de anchos de banda máximos teóricos frente a rangos reales medios en entornos domésticos u oficinas pequeñas serían:

• 10 Base‑T (10 Mbps): teórico 1,25 MB/s; real, muy por debajo de 1 MB/s.
• Fast Ethernet 100 Base‑T (100 Mbps): alrededor de 12,5 MB/s teóricos; entre 6 y 8 MB/s en condiciones normales.
• Gigabit Ethernet 1000 Base‑T (1 Gbps): máximo de 125 MB/s; en la práctica es habitual ver 30-60 MB/s sostenidos con equipos de gama media.
• Wi‑Fi 802.11n o 802.11ac: aunque el estándar hable de cientos de Mbps, a la hora de copiar archivos suele quedarse en unos pocos MB/s en 2,4 GHz y algo más en 5 GHz, dependiendo de interferencias, distancia, saturación, etc.

Esta discrepancia no implica que algo vaya “mal” de por sí, pero sí sirve para identificar situaciones claramente anómalas: si en una LAN gigabit te quedas fijo en ~10 MB/s con tráfico cableado y sin saturación evidente, hay margen de mejora casi seguro.

Ajustes de Windows para mejorar transferencias masivas en LAN

Superada la parte física, toca afinar el sistema operativo. Windows (especialmente Windows 10 y 11, pero también 7 y Server) incluye varias características de red que, según el combo de hardware y drivers, pueden ayudar o fastidiar seriamente las copias de archivos.

Desactivar la Compresión Diferencial Remota (RDC)

La funcionalidad de Compresión Diferencial Remota está pensada para que algunos servicios comparen solo diferencias entre archivos. Sin embargo, en muchos equipos añade sobrecarga innecesaria y puede empeorar la transferencia de datos por SMB.

Para desactivarla en Windows basta con:

• Abrir el cuadro de búsqueda (Windows + S) y escribir “Características de Windows”.
• Entrar en “Activar o desactivar las características de Windows”.
• Localizar “Compresión diferencial remota” y desmarcarla.
• Pulsar Aceptar y reiniciar el equipo.

Es importante aplicar este cambio en todos los equipos implicados en las copias, tanto origen como destino, para notar el efecto completo.

Ajustar o deshabilitar el autoajuste de TCP (TCP Auto-Tuning)

Windows incorpora un mecanismo llamado TCP Auto-Tuning que adapta dinámicamente parámetros de la conexión en función de la red. En algunas combinaciones de routers y switches, este autoajuste genera inestabilidad en la velocidad de copia.

Para probar si desactivarlo mejora el rendimiento:

• Abre una consola con privilegios de administrador (Terminal o Símbolo del sistema).
• Ejecuta: netsh int tcp set global autotuninglevel=disabled
• Repite la transferencia masiva y observa si la velocidad se mantiene más estable.

Si no notas mejora o quieres dejarlo tal cual estaba, puedes restaurar el nivel normal con el comando: netsh int tcp set global autotuninglevel=normal. De nuevo, es recomendable hacer las pruebas en todos los equipos críticos para copiar.

Desactivar Large Send Offload (LSO) y otros offloads problemáticos

Las tarjetas de red modernas ofrecen varias funciones de offloading para delegar en la propia NIC ciertos trabajos que, de lo contrario, haría la CPU. LSO (Large Send Offload) es una de las más habituales. Sobre el papel ayuda; en la realidad, con algunos drivers hace justo lo contrario.

Para desactivar LSO en Windows:

• Pulsa Windows + X y entra en “Administrador de dispositivos”.
• Haz doble clic en el adaptador de red que estés usando.
• En la pestaña “Opciones avanzadas”, localiza “Large Send Offload v2 (IPv4)” y “Large Send Offload v2 (IPv6)”.
• Pon ambas opciones en “Desactivado” y guarda.

Tras hacer el cambio, conviene reiniciar o deshabilitar y habilitar de nuevo el adaptador. Muchas veces, esto elimina los picos de bajada brutal en medio de una copia grande.

Impacto del antivirus, VPN, proxy y otros intermediarios

Más allá de la pila de red de Windows, todo lo que se coloca “en medio” entre un PC y otro puede ser responsable de buena parte de los problemas de rendimiento. Los casos más repetidos tienen que ver con seguridad y túneles.

Los antivirus y soluciones de protección del endpoint suelen inspeccionar en tiempo real los archivos que se leen o se escriben. En una transferencia de unas pocas fotos ni se nota; en una migración de miles de ficheros pequeños, el impacto es tremendo. Es habitual ver la CPU disparada en el cliente o en el servidor mientras la copia parece congelarse.

La opción más sensata en un entorno controlado es, mientras se realiza la copia masiva entre equipos de confianza dentro de la misma LAN, desactivar temporalmente el análisis en tiempo real o excluir rutas concretas de origen y destino. Eso sí, solo si tienes claro que los datos son seguros y detrás de un firewall corporativo o doméstico decente.

En cuanto a VPNs, proxys y soluciones de inspección de tráfico, hay que dejar claro que la LAN local no debería depender de ellas para un simple intercambio interno de archivos. Si el tráfico SMB se está reencapsulando en una VPN o pasando por un proxy de contenido, es normal que el ancho de banda efectivo caiga a la mitad o menos. Para copias grandes dentro de la misma ubicación física, merece la pena sacar esos equipos del túnel, aunque sea de forma puntual.

Particularidades de SMB, DFS y Windows Server al compartir archivos

Cuando hablamos de Windows Server (2008, 2012, 2016, 2022…) como servidor de archivos, entra en juego toda la capa de SMB y DFS. Aquí no solo importa la tarjeta de red o el disco del servidor; también el tipo de recurso compartido y cómo se resuelven las rutas desde el cliente.

Un primer chequeo básico es distinguir si la carpeta compartida es una carpeta DFS o un recurso SMB simple. Basta con abrir las propiedades del recurso desde un cliente: si aparece la pestaña “DFS”, estamos ante un namespace DFS.

Si es DFS, merece la pena probar a acceder a la misma carpeta usando directamente la ruta UNC real del servidor (por ejemplo, \\SERVIDOR\Recurso) en lugar de la ruta DFS (\\DOMINIO\Namespace\Carpeta). Si con la ruta UNC directa la copia va rápida y con la DFS se arrastra, el problema viene de cómo se están gestionando las referencias DFS.

En ese caso conviene:

• Revisar en la pestaña DFS de las propiedades qué rutas UNC de destino figuran como referencias.
• Quitar las rutas que ya no existan, no respondan o estén caídas para que el cliente no pierda tiempo probándolas en cadena.
• Verificar que todas las rutas activas son accesibles directamente desde el cliente afectado.

En cuanto a rendimiento general desde el lado del servidor, Microsoft recomienda mantener Windows Server actualizado con los últimos hotfixes específicos de servicios de archivos (antiguas KB como 2473205 para 2008/7 o 2899011 para 2012/8, y sus sucesoras en versiones más modernas). También es importante comprobar si el servidor DFS local está operativo, si las subredes en Sites and Services de Active Directory están correctamente definidas —incluido IPv6 si lo usas— y si el cliente se está conectando al servidor del sitio correcto o a uno remoto vía WAN.

Cuándo la lentitud es “normal” y cuándo no

No todos los escenarios de copia lenta implican un fallo. Hay varias situaciones en las que, aunque Fast Ethernet o Gigabit funcionen bien, el resultado práctico seguirá siendo un tiempo de copia considerable.

Un clásico es la diferencia entre copiar un único archivo grande y una carpeta con muchos ficheros pequeños. Si copias, por ejemplo, una ISO de 40 GB, la copia puede ir bastante rápido y con una curva de velocidad estable. Sin embargo, mover 40 GB repartidos en millones de archivos de pocos KB siempre será muchísimo más lento, por diseño: hay más operaciones de metadatos, más entradas de directorio que actualizar y más impacto en antivirus y demás capas.

En NAS como My Cloud o soluciones similares, otro factor a contar es la indexación y la generación de miniaturas: mientras el dispositivo transcodifica, indexa y crea vistas previas del contenido multimedia que se está subiendo, parte de la CPU y del disco se dedican a esa tarea, restando recursos a la pura escritura de datos.

A esto hay que sumar la carga general de la red: backups programadas, streaming de vídeo, descargas, dispositivos adicionales en la LAN… cuando todo se junta, es bastante fácil que aparezca una sensación de lentitud aunque, mirado con lupa, no haya un problema concreto sino simple saturación de recursos compartidos.

Optimizar el entorno: cliente, red y dispositivo de almacenamiento

Si quieres ir un paso más allá y dejar el entorno fino, tienes una buena colección de buenas prácticas a aplicar de forma ordenada.

En el lado del cliente, además de los ajustes de TCP y de NIC que ya hemos visto, viene bien:

• Comprobar que la estación de trabajo (Workstation) está en ejecución y que el “Cliente para redes Microsoft” está habilitado en la conexión de red.
• Evitar que el ordenador entre en suspensión o hibernación durante una copia larga.
• En portátiles, conectar a la corriente y, si se puede, usar siempre Ethernet por cable en lugar de Wi‑Fi.
• En equipos antiguos con poco RAM, cerrar aplicaciones pesadas mientras se realiza la transferencia.

En la capa de red, los consejos clave son:

• Sustituir hubs por switches gigabit y actualizar routers viejos que solo ofrecen 10/100.
• Actualizar firmware de router, switch y puntos de acceso, y descartar hardware defectuoso.
• Si hay mucho tráfico concurrente (streaming, copias de seguridad, etc.), planificar ventanas horarias para las transferencias masivas.
• Siempre que sea posible, conectar los equipos implicados en la copia al mismo switch o segmento para reducir saltos intermedios.

• Desactivar temporalmente servicios de acceso remoto, DLNA o iTunes mientras se hace una subida muy grande.
• Parar tareas de copia de seguridad internas o de sincronización en segundo plano para que no compitan por el disco.
• Asegurarse de que la unidad USB usada para copiar o hacer backup es USB 3.0 real y de buena calidad.

Herramientas y estrategias para copiar grandes volúmenes en Windows

El Explorador de archivos cumple su función, pero si estás migrando un PC entero o moviendo terabytes entre máquinas, usar herramientas específicas tiene mucho sentido. No solo por velocidad, también por fiabilidad y control.

Una de las opciones nativas más potentes es Robocopy, que viene de serie en Windows. Permite copias multihilo (con /MT), reintentos, exclusiones granulares y logs detallados. Usarlo desde la línea de comandos para mover grandes árboles de directorios reduce mucho los fallos “a mitad de camino” y suele exprimir mejor la red que el arrastrar y soltar habitual.

Cuando el objetivo no es solo mover archivos sino además trasladar programas, cuentas de usuario y configuraciones de un PC antiguo a uno nuevo, entran en juego utilidades de migración específicas. Estas herramientas, instaladas en ambos equipos, permiten elegir qué se quiere pasar (archivos, carpetas, aplicaciones compatibles, incluso perfiles) y se encargan de orquestar la transferencia de forma optimizada sobre la LAN, sin que tengas que preocuparte de rutas UNC complejas ni permisos avanzados.

En entornos corporativos o semi-profesionales, además, es habitual combinar estas utilidades con scripts de orquestación y procesos automatizados que priorizan flujos, validan la integridad de los datos y, si es necesario, integran las transferencias con servicios en la nube como AWS o Azure.

UDP, TCP y su efecto indirecto en el rendimiento (caso RDP)

Aunque el escritorio remoto (RDP) no sea la herramienta típica para mover grandes archivos, su comportamiento ilustra bien cómo la elección del protocolo de transporte afecta a la experiencia incluso en una LAN.

Durante años, RDP se basó únicamente en TCP: fiable, ordenado, pero con tendencia a sufrir cuando hay pérdida de paquetes o latencias variables. Esto se traduce en sesiones lentas, con el ratón “pegado” y ventanas que tardan en actualizarse, sobre todo en enlaces problemáticos.

Con las versiones modernas de Windows, RDP introdujo un modo de transporte dual que permite usar también UDP. Al no tener que garantizar orden y entrega, UDP resulta más ágil y tolerante al jitter, especialmente adecuado para gráficos, vídeo y entrada de usuario en tiempo real.

En una LAN estable, habilitar RDP sobre UDP —asegurando que los puertos respectivos están abiertos en firewalls— ofrece una experiencia mucho más fluida, casi como trabajar en local. En entornos con Wi‑Fi muy saturado, conexión móvil o VPN inestable, puede ser preferible seguir usando solo TCP, sacrificando inmediatez a cambio de fiabilidad y compatibilidad.

Este ejemplo, aunque parezca tangencial, refuerza una idea clave: no basta con que la red “funcione”, hay que configurarla para el tipo de tráfico que realmente importa en cada entorno, ya sea escritorio remoto, streaming o transferencias masivas de archivos.

Visión global: productividad, nube y monitorización

En una pequeña empresa —y también en casa cuando trabajas con mucha producción audiovisual o backups pesados—, la velocidad de copia en LAN no es un capricho. Una migración que tarda horas en lugar de minutos afecta ventanas de mantenimiento, tiempos muertos del personal y, a la larga, costes.

Cuando, además de la red local, entran en juego servicios cloud como AWS o Azure, la cosa se complica todavía más. Las transferencias masivas hacia la nube deben diseñarse con cabeza: elegir la región adecuada, aprovechar cargas multiparte, usar herramientas oficiales optimizadas y evitar recorridos innecesariamente largos. Una arquitectura híbrida bien planteada, con puntos de transferencia cercanos y procesos automatizados, puede ahorrar mucho tiempo y bastante dinero en anchos de banda salientes.

Por último, no se puede dejar de lado la parte de observabilidad y seguridad. Monitorizar throughput, latencias, tasas de error y consumo de recursos en servidores y dispositivos de almacenamiento, usando paneles de control o herramientas de inteligencia de negocio tipo Power BI, ayuda a ver patrones y justificar inversiones en switches mejores, nuevas NIC o almacenamiento más rápido.

Algunas organizaciones incluso empiezan a usar agentes basados en IA para detectar anomalías en el tráfico, anticipar congestiones o priorizar tareas de copia cuando la red está más holgada. Sin llegar a tanto, simplemente medir antes y después de cada cambio, con pruebas controladas, permite decidir qué ajustes aportan realmente valor.

En conjunto, combinando buen hardware (cables decentes, switches gigabit, discos rápidos), ajustes sensatos de Windows (RDC, auto-tuning TCP, LSO), una configuración cuidada de SMB y DFS, y herramientas adecuadas para copiar y migrar datos, es posible transformar unas transferencias masivas en LAN erráticas y desesperantes en un proceso razonablemente rápido, estable y transparente, apto tanto para mover unas cuantas fotos de un PC viejo a uno nuevo como para trabajar a diario con proyectos de vídeo de 100 GB en un entorno completamente Windows.