En resumen. WireGuard vive dentro del kernel de Linux desde la versión 5.6 y usa ChaCha20-Poly1305 sobre UDP, sin opción de cambiarlo. Las mayores ganancias vienen de tres frentes: valores correctos de MTU y MSS, offloads GRO/GSO activos y pruebas con varios flujos paralelos usando iperf3 -P 4. PersistentKeepalive sirve para atravesar NAT, no para ganar velocidad.
De qué depende el rendimiento de WireGuard
WireGuard es rápido por diseño, pero alcanza sus valores máximos solo con una configuración limpia. Tres factores deciden el resultado: las características de la CPU, el valor correcto de MTU y una metodología de prueba rigurosa. Buena parte de los problemas nace de errores simples, como una MTU incorrecta (Maximum Transmission Unit) que fragmenta los paquetes, o pruebas de un solo flujo que nunca revelan lo que aportan varios núcleos.
Vuelve a probar después de cada cambio. Así confirmas si la medida sirvió y conservas un camino claro de regreso.
Por qué WireGuard es más rápido
La velocidad viene de tres decisiones de diseño: un código reducido, criptografía moderna y su ubicación dentro del sistema operativo. Eso explica por qué supera de forma constante a los protocolos VPN tradicionales.
- Diseño reducido: unas 4,000 líneas de código frente a decenas de miles en OpenVPN, lo que simplifica auditorías y optimización.
- Cifrado moderno: ChaCha20-Poly1305 corre con eficiencia en cualquier procesador, mientras que AES depende de la aceleración por hardware (AES-NI) para dar su máxima velocidad.
- Integración en el kernel: procesa paquetes sin cambios de contexto costosos.
- Optimización para UDP: aprovecha las funciones de aceleración de red integradas en Linux.
- Rotación de llaves transparente: las llaves cambian solas mediante handshakes breves, cada pocos minutos o al superar cierto número de mensajes, sin cortar los flujos activos.
Con tarjetas de red multi-queue, las distintas conexiones se reparten entre varios núcleos. WireGuard escala entonces por procesamiento paralelo, en lugar de topar con el límite de un solo núcleo.
Comandos para verificar el rendimiento
Antes de ajustar nada, verifica tres cosas: un kernel actual, el módulo de WireGuard cargado y los offloads de red activos.
Revisa el kernel:
uname -rWireGuard viene integrado desde la versión 5.6 del kernel. Los kernels modernos (5.15+ o 6.x) suelen ofrecer mejor throughput y un manejo de red más eficiente.
Verifica el módulo de WireGuard:
sudo modprobe wireguard
lsmod | grep wireguardCon esto confirmas que corre el módulo de kernel y no una implementación en espacio de usuario, que es más lenta.
Revisa los offloads de red:
ethtool -k eth0 | grep -E 'gro|gso|tso'GRO, GSO y TSO reducen la carga del procesamiento de paquetes al agrupar o segmentar el tráfico. Activos, mejoran bastante el throughput y bajan el uso de CPU, sobre todo en conexiones rápidas de un VPS o un Dedicated Server.
Benchmark de WireGuard: más que una prueba de velocidad
Un benchmark útil compara el rendimiento normal de la red con el del túnel VPN. Prueba primero la conexión sin WireGuard y repite después las mismas pruebas a través del túnel. Así ves cuánto cuestan el cifrado y el encapsulado.
Las dos pruebas necesitan condiciones idénticas: mismo cliente, mismo servidor, misma ruta, misma duración y el mismo número de flujos paralelos. Si no, los resultados no se pueden comparar.
Metodología básica de prueba
iperf3 es la herramienta más práctica. Empieza con una prueba TCP normal y repítela luego con varios flujos paralelos, por ejemplo -P 4 o -P 8. Importan porque el rendimiento de WireGuard depende mucho de qué tan bien el sistema aprovecha varios núcleos.
Prueba también las dos direcciones. Con -R inviertes la prueba, y vale la pena porque la subida y la bajada pueden dar cifras distintas.
Para UDP usas iperf3 -u con un ancho de banda definido mediante -b. Vigila la pérdida de paquetes, ya que un throughput UDP alto solo sirve si nada se descarta.
Cómo interpretar los resultados
Durante cada prueba, monitorea la carga de CPU y los paquetes descartados con top, mpstat o ip -s link. Si WireGuard queda muy por debajo de la red sin túnel, revisa los valores de MTU y MSS, los offloads GRO/GSO y si un solo núcleo está saturado.
Variables de ajuste del rendimiento de WireGuard
Un buen rendimiento casi siempre viene de optimizar unos cuantos ajustes de sistema y de red, no de un único parámetro mágico.
Qué conviene ajustar
| Variable | Por qué importa | Prueba rápida | Solución |
| MTU/MSS | Los valores incorrectos provocan fragmentación, retransmisiones y menos throughput | Observa retransmisiones o velocidades inestables en las pruebas | Ajusta la MTU a tu ruta de red y usa MSS clamping si hace falta |
| Paralelismo | Una sola conexión no siempre aprovecha todos los núcleos | Compara iperf3 -P 1 con -P 4 o -P 8 | Usa flujos paralelos en transferencias grandes y benchmarks |
| Offloads GRO/GSO | Reducen la carga del procesamiento de paquetes y el uso de CPU | Revisa el estado con ethtool | Déjalos activos salvo que estés diagnosticando un problema |
| Escalado de CPU | El cifrado de WireGuard consume mucha CPU | Vigila el uso por núcleo en las pruebas | Pon el governor de CPU en performance para los benchmarks |
| Kernel y controladores | Los viejos limitan el escalado y el throughput | Revisa la versión del kernel y compara resultados | Usa kernels modernos (5.15+ o 6.x) y controladores actualizados |
Comandos esenciales
Estos comandos resuelven las causas más frecuentes: problemas de MTU, offloads ausentes y búferes de sistema muy pequeños.
Usa MSS clamping cuando WireGuard enruta tráfico entre subredes y las conexiones TCP van lentas, inestables o afectadas por la fragmentación.
sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuCon eso, las conexiones TCP adoptan un tamaño de paquete seguro para la ruta del túnel.
Aumenta los búferes del sistema:
cat >/etc/sysctl.d/99-wireguard.conf <<'EOF'
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.core.netdev_max_backlog = 250000
EOFEstos valores ayudan en sistemas muy cargados o de alto throughput, porque Linux absorbe picos de tráfico más grandes.
Aplica los cambios con:
sudo sysctl --systemUn punto que se malinterpreta seguido: WireGuard no te deja elegir un cifrado más rápido, porque su criptografía está fijada por diseño. Y PersistentKeepalive ayuda a atravesar NAT, no a ganar velocidad. En la mayoría de los casos, las mayores ganancias llegan con una MTU correcta, los offloads activos y pruebas paralelas bien hechas, antes de tocar ajustes avanzados del kernel.
Cómo configurar la interfaz del servidor WireGuard
Empieza con una configuración mínima y agrega las optimizaciones de forma sistemática.
Nota: con el complemento de WireGuard de 1 clic de Contabo, tu WGDashboard ya viene listo y configurado, así que puedes saltarte estos pasos.
Requisitos y generación de llaves
Tu servidor Linux necesita wireguard-tools (kernel 5.6+ de preferencia) y el puerto UDP 51820 abierto. Genera las llaves del servidor con los permisos adecuados:
umask 077
wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickeyConfiguración mínima del servidor
Crea /etc/wireguard/wg0.conf:
[Interface]
Address = 10.0.0.1/24
PrivateKey = <SERVER_PRIVATE_KEY>
ListenPort = 51820
# MTU = 1440 (leave unset for auto-selection, or set after testing)
[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.0.0.2/32
PersistentKeepalive = 25 # usually set on the NATed client, not needed on serverReemplaza las llaves y usa una red privada /24.
Configuración de firewall y red
La configuración del firewall es decisiva para el rendimiento y la conectividad. Aplica estas reglas antes de arrancar el servicio.
Reglas básicas:
# Permitir el puerto UDP de WireGuard
sudo iptables -A INPUT -p udp --dport 51820 -j ACCEPTPara dar acceso a internet a través del túnel, habilitas el reenvío de IP y NAT:
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-sysctl.conf
sudo sysctl --system
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEReemplaza eth0 con la interfaz de tu servidor que da a internet.
NAT y travesía de firewall: WireGuard maneja NAT solo, y los clientes detrás de NAT no necesitan configuración especial. Si un cliente debe recibir conexiones entrantes a través de NAT, agrega PersistentKeepalive = 25 a su configuración de peer. Cada 25 segundos sale un paquete keepalive que mantiene vivo el mapeo.
Solución de problemas: si WireGuard conecta pero los clientes no llegan a internet, comprueba con sysctl net.ipv4.ip_forward que el reenvío de IP esté habilitado y con iptables -t nat -L -v que NAT funcione.
Activar y verificar
Arranca WireGuard y verifica la conectividad:
sudo systemctl enable --now wg-quick@wg0
sudo wg showOptimización de la MTU
Mantenlo simple al principio: deja la MTU sin definir para que wg-quick la elija sola y revisa el resultado con ip link show wg0.
Si quieres fijarla a mano, averigua la PMTU hacia la IP pública del servidor con ping -M do -s <tamano> <server_ip> y empieza en 1472. Resta la sobrecarga del encapsulado, unos 60 bytes en IPv4 y 80 en IPv6. Pon ese valor como MTU en el bloque [Interface] de cada peer, reinicia y repite las pruebas con flujos paralelos (iperf3 -P 4, en las dos direcciones).
Verificaciones finales
Confirma que los handshakes con los clientes ocurren y que el enrutamiento hacia internet funciona como esperas. Después de cada cambio de MTU o de firewall corresponde un nuevo benchmark. Hay más detalles en la documentación oficial de WireGuard Quick Start.
Conceptos avanzados de rendimiento
Con el ajuste básico hecho, las ganancias adicionales vienen casi siempre de un mejor uso de la CPU, kernels modernos y controladores de red eficientes.
Túneles conscientes de los offloads
WireGuard se beneficia mucho de los offloads de red de Linux como GRO y GSO, porque bajan la carga de CPU al procesar paquetes.
ethtool -k eth0 | grep -E 'gro|gso'En la mayoría de los casos conviene dejar estas funciones activas, salvo que estés persiguiendo un problema de red concreto.
Paralelismo y escalado de CPU
Una sola conexión rara vez aprovecha del todo una CPU moderna o un enlace rápido. Probar con varios flujos paralelos refleja mejor las cargas de transferencia reales.
iperf3 -P 4Si no mejora con flujos paralelos, busca cuellos de botella de CPU o colas de red saturadas.
Optimización de CPU y sistema
Pese a su eficiencia, WireGuard está limitado por la CPU. Mantén las frecuencias estables en las pruebas con el governor performance:
# Set performance governor
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorEn sistemas NUMA con varios sockets, mantén las interrupciones de red y los endpoints de WireGuard en el mismo socket para evitar accesos entre nodos. Este comando solo está disponible en Dedicated Servers, no en máquinas virtuales.
Kernel y controladores
Los kernels de Linux más nuevos y los controladores de red actualizados suelen mejorar el throughput y el manejo de paquetes. Los controladores modernos de virtio, ENA y NIC multi-queue dan los mejores resultados de escalado en entornos de VPS y Dedicated Server.
Rendimiento de TCP dentro del túnel
Casi todo el tráfico de WireGuard transporta conexiones TCP dentro del túnel cifrado. Una latencia alta o la pérdida de paquetes castigan mucho a TCP. En algunos entornos, los algoritmos modernos de control de congestión como BBR mejoran el throughput a larga distancia.
echo 'net.ipv4.tcp_congestion_control=bbr' >> /etc/sysctl.confMide siempre antes y después de activar BBR, porque los resultados varían según la red.
Aplica los cambios con:
sudo sysctl --systemFAQ sobre el rendimiento de WireGuard
WireGuard crea conexiones VPN cifradas de peer a peer y las autentica con llaves públicas y privadas. En Linux corre dentro del kernel, lo que reduce la sobrecarga y mejora el rendimiento frente a protocolos VPN más antiguos.
Solo UDP. Eso mantiene bajas la latencia y la sobrecarga del protocolo, y habilita optimizaciones de Linux como GRO y GSO. Si una red bloquea UDP, WireGuard se puede encapsular en túneles TCP o HTTPS, aunque eso cuesta rendimiento.
Ejecuta wg. Una marca de tiempo reciente en “latest handshake” y contadores de transferencia que suben indican un túnel activo. También puedes hacer ping a la IP de WireGuard del peer. Para medir rendimiento, corre iperf3 por el túnel y compara con una prueba fuera de la VPN. Si algo falla, revisa las reglas de firewall del puerto UDP 51820, los AllowedIPs en los dos peers y la configuración de MTU o MSS.
En la mayoría de los casos, déjala sin definir y que wg-quick la elija sola. Si necesitas ajustarla a mano, empieza cerca de 1420 a 1440 y corrige según tu ruta de red y las pruebas de fragmentación.
Casi siempre son valores incorrectos de MTU o MSS, offloads GRO/GSO desactivados o cuellos de botella de CPU por tráfico de un solo flujo. Compara con y sin túnel usando pruebas de iperf3 individuales y paralelas para localizarlo.
