Optimiser TCP sous Linux : bons réglages sysctl pour serveur web

Optimiser TCP sur un serveur dédié peut améliorer la stabilité, la latence et la capacité à absorber beaucoup de connexions. Cependant, les vieux réglages copiés-collés depuis des forums de 2010 font souvent plus de dégâts qu’autre chose.

Le cas typique : un serveur web affiche beaucoup de connexions TIME_WAIT, puis quelqu’un recommande de réduire brutalement les timeouts, d’activer tcp_tw_recycle, de désactiver SACK, et de lancer sysctl -p avec la confiance d’un chat devant un aquarium.

Aujourd’hui, on va faire mieux : mesurer d’abord, comprendre les états TCP, éviter les options obsolètes, puis appliquer uniquement des réglages adaptés à un serveur web moderne sous Linux.

Avant de tuner TCP : mesurez le serveur

Avant de modifier le noyau, commencez par regarder l’état réel des connexions. L’ancien outil netstat fonctionne encore sur certaines distributions, mais ss est l’outil moderne fourni par iproute2. Il affiche les statistiques de sockets et donne plus d’informations TCP que netstat.

Pour obtenir un résumé rapide :

ss -s

Pour compter les connexions par état TCP :

ss -tan | awk 'NR > 1 {print $1}' | sort | uniq -c | sort -nrCode language: JavaScript (javascript)

Pour lister les ports TCP en écoute :

ss -tlnp

Pour observer uniquement les connexions HTTP et HTTPS :

ss -tan '( sport = :80 or sport = :443 )'Code language: JavaScript (javascript)

Sur un serveur web actif, voir des connexions TIME_WAIT n’a rien d’anormal. TCP garde volontairement certaines connexions fermées pendant un moment pour éviter la confusion entre anciens et nouveaux paquets. Ce n’est donc pas automatiquement un problème.

TIME_WAIT : faut-il vraiment s’en débarrasser ?

Pas forcément. TIME_WAIT est un état normal du protocole TCP. Il apparaît après la fermeture d’une connexion, notamment pour éviter que des paquets retardés perturbent une future connexion utilisant le même couple IP/port.

Le vrai problème n’est pas “j’ai des TIME_WAIT”. Le vrai problème serait plutôt :

• une explosion anormale du nombre de connexions ;
• une saturation des ports éphémères ;
• des erreurs côté application ;
• une file d’attente SYN saturée ;
• un reverse proxy ou un backend qui ouvre trop de connexions courtes ;
• un crawler, un bot ou une attaque qui tape le serveur comme un métronome énervé.

Avant de toucher au noyau, vérifiez donc qui génère ces connexions :

ss -tan state time-wait | awk 'NR > 1 {print $5}' | sed 's/:[0-9]*$//' | sort | uniq -c | sort -nr | head -30Code language: JavaScript (javascript)

Si une IP ressort massivement, le problème se règle peut-être mieux avec Nginx, Apache, Fail2ban, CrowdSec, votre WAF, Cloudflare ou une règle firewall. TCP n’a pas vocation à compenser une application mal protégée.

Les anciens réglages à ne plus utiliser

Commençons par le ménage. Certains réglages que l’on trouvait partout il y a quelques années ne doivent plus être recommandés aujourd’hui.

Ne pas utiliser tcp_tw_recycle

tcp_tw_recycle était censé recycler plus vite les connexions en TIME_WAIT. Le problème : cette option cassait des connexions légitimes, surtout lorsque plusieurs clients passaient par une même adresse IP, comme derrière du NAT.

Sur les noyaux Linux modernes, cette option a disparu. Si un vieux tutoriel vous dit d’ajouter ceci, ne le faites pas :

net.ipv4.tcp_tw_recycle = 1

Si votre système connaît encore cette option, laissez-la désactivée :

sysctl net.ipv4.tcp_tw_recycle 2>/dev/null || trueCode language: JavaScript (javascript)

Ne pas désactiver tcp_sack

tcp_sack active les accusés de réception sélectifs. En clair, TCP peut mieux récupérer après une perte de paquets, sans retransmettre inutilement trop de données.

Sur un serveur web moderne, le laisser activé est le bon choix par défaut :

net.ipv4.tcp_sack = 1

Ne pas désactiver tcp_timestamps par réflexe

Certains anciens guides recommandaient de désactiver tcp_timestamps pour économiser quelques octets dans les en-têtes TCP. Sur les réseaux actuels, ce gain est rarement pertinent. Les timestamps servent notamment à TCP pour mieux gérer certains scénarios liés au temps, aux pertes et aux connexions rapides.

Gardez donc la valeur par défaut, sauf cas très spécifique et testé :

net.ipv4.tcp_timestamps = 1

Créer un fichier sysctl propre

Évitez de coller vos réglages directement dans /etc/sysctl.conf. Préférez un fichier dédié dans /etc/sysctl.d/. C’est plus lisible, plus maintenable et plus simple à désactiver.

Créez le fichier suivant :

sudo nano /etc/sysctl.d/99-tcp-webserver.conf

On va y placer des réglages raisonnables pour un serveur web Linux moderne.

Réglages TCP sûrs pour un serveur web

Voici une base prudente. Elle convient à beaucoup de serveurs web, mais elle doit rester testée dans votre contexte : trafic, RAM, CPU, kernel, reverse proxy, firewall, hébergeur et type d’application.

# SkyMinds - TCP tuning for a modern Linux web server.
# Keep this file small, documented and easy to revert.

# Keep TCP window scaling enabled.
# Default is usually 1.
net.ipv4.tcp_window_scaling = 1

# Keep TCP timestamps enabled.
# Do not disable this just to save a few header bytes.
net.ipv4.tcp_timestamps = 1

# Keep Selective ACK enabled.
# This helps TCP recover efficiently from packet loss.
net.ipv4.tcp_sack = 1

# Increase the queue for incomplete incoming TCP handshakes.
# Useful on busy public services.
net.ipv4.tcp_max_syn_backlog = 8192

# Increase the global listen backlog limit.
# Your web server must also be configured to use an adequate backlog.
net.core.somaxconn = 8192

# Keep SYN cookies enabled as a fallback protection.
# This should not replace proper backlog sizing and filtering.
net.ipv4.tcp_syncookies = 1

# Reduce FIN_WAIT2 timeout moderately.
# Do not set this absurdly low.
net.ipv4.tcp_fin_timeout = 30

# Enable TCP receive buffer auto-tuning.
net.ipv4.tcp_moderate_rcvbuf = 1

# Allow larger socket buffers for high-throughput connections.
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728

# TCP read buffers: min default max.
net.ipv4.tcp_rmem = 4096 87380 134217728

# TCP write buffers: min default max.
net.ipv4.tcp_wmem = 4096 65536 134217728Code language: PHP (php)

Appliquez ensuite les paramètres :

sudo sysctl --system

Puis vérifiez les valeurs actives :

sysctl net.ipv4.tcp_window_scaling
sysctl net.ipv4.tcp_timestamps
sysctl net.ipv4.tcp_sack
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.core.somaxconn
sysctl net.ipv4.tcp_fin_timeout
sysctl net.core.rmem_max
sysctl net.core.wmem_maxCode language: CSS (css)

Activer BBR : bonne idée, mais pas partout

BBR est un algorithme de contrôle de congestion TCP. Il peut améliorer le débit et la latence sur certains liens, notamment quand la bande passante est élevée ou que la latence réseau est sensible. En revanche, il ne faut pas l’activer aveuglément sur tous les serveurs.

Commencez par vérifier les algorithmes disponibles :

sysctl net.ipv4.tcp_available_congestion_controlCode language: CSS (css)

Vérifiez ensuite l’algorithme actif :

sysctl net.ipv4.tcp_congestion_controlCode language: CSS (css)

Si bbr est disponible, vous pouvez le tester avec la file d’attente fq :

sudo modprobe tcp_bbr
echo "tcp_bbr" | sudo tee /etc/modules-load.d/tcp-bbr.confCode language: PHP (php)

Ajoutez ensuite ces lignes au fichier /etc/sysctl.d/99-tcp-webserver.conf :

# Optional: test BBR with fair queue packet scheduler.
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrCode language: PHP (php)

Appliquez les changements :

sudo sysctl --system

Puis vérifiez :

sysctl net.core.default_qdisc
sysctl net.ipv4.tcp_congestion_control
lsmod | grep bbr

Si vous hébergez surtout des pages WordPress derrière Nginx avec cache, CDN et connexions courtes, le gain peut être faible. Si vous servez beaucoup de fichiers, d’images, de médias, de sauvegardes ou d’assets lourds, le test devient plus intéressant.

Ajuster les keepalives TCP

Les keepalives TCP ne remplacent pas les timeouts applicatifs de Nginx, Apache, PHP-FPM, MySQL ou Redis. Ils servent surtout à détecter des connexions mortes au niveau TCP lorsque l’application utilise SO_KEEPALIVE.

Les valeurs par défaut sont souvent conservatrices. Vous pouvez les rendre un peu plus réactives :

# TCP keepalive tuning.
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 5Code language: PHP (php)

Ces valeurs signifient : attendre 10 minutes d’inactivité, envoyer une sonde toutes les 60 secondes, puis abandonner après 5 sondes sans réponse. C’est raisonnable pour beaucoup de serveurs, mais adaptez selon vos connexions longues : SSH, WebSocket, proxy, base de données distante, API ou applications temps réel.

Backlog TCP et serveur web : le noyau ne fait pas tout

Augmenter net.core.somaxconn aide seulement si votre serveur web accepte aussi une file d’attente suffisante. Sinon, vous avez agrandi le parking, mais laissé la porte d’entrée en mode chatière.

Avec Nginx, vérifiez notamment la directive listen et le backlog si vous gérez un trafic important :

server {
	listen 443 ssl http2 backlog=8192;
	server_name example.com;

	# ...
}Code language: PHP (php)

Sur Apache, regardez plutôt les paramètres MPM, le nombre de workers, les timeouts et la capacité réelle de PHP-FPM ou du backend. Si le backend est saturé, TCP ne fera pas de miracle. Il fera juste la queue avec une meilleure posture.

Surveiller les effets après modification

Après chaque changement, surveillez le serveur. Ne changez pas dix paramètres d’un coup en production, sinon vous ne saurez jamais lequel a aidé ou cassé quelque chose.

Résumé des sockets :

ss -s

Connexions par état :

ss -tan | awk 'NR > 1 {print $1}' | sort | uniq -c | sort -nrCode language: JavaScript (javascript)

Statistiques TCP du noyau :

nstat -az TcpExtListenOverflows TcpExtListenDrops TcpExtTCPSynRetrans TcpRetransSegs

Erreurs kernel liées au réseau :

journalctl -k --since "1 hour ago" | grep -Ei 'tcp|syn|overflow|drop|reset'Code language: JavaScript (javascript)

Sur Nginx, surveillez aussi les connexions actives si le module stub status est activé :

curl -s http://127.0.0.1/nginx_statusCode language: JavaScript (javascript)

Pour Apache, regardez plutôt mod_status, les logs d’erreur et l’état des workers.

Optimisation TCP ou problème applicatif ?

Beaucoup de “problèmes TCP” sont en réalité des problèmes applicatifs. Avant d’accuser le noyau, vérifiez :

• les timeouts Nginx ou Apache ;
• les limites PHP-FPM ;
• les workers saturés ;
• les requêtes SQL lentes ;
• les plugins WordPress trop lourds ;
• les appels HTTP externes bloquants ;
• les bots et crawlers agressifs ;
• les attaques sur wp-login.php, XML-RPC ou WooCommerce ;
• les limites de fichiers ouverts ;
• le suivi de connexion firewall, notamment avec conntrack.

Sur un serveur WordPress ou WooCommerce, optimiser TCP peut aider à absorber la charge réseau. Mais si PHP-FPM est saturé ou si MySQL passe son temps à trier des tables énormes sans index, le noyau pourra faire du yoga : la page restera lente.

Augmenter les limites de fichiers ouverts

Un serveur qui accepte beaucoup de connexions doit aussi pouvoir ouvrir assez de fichiers et sockets. Vérifiez la limite globale :

sysctl fs.file-maxCode language: CSS (css)

Vérifiez ensuite la limite d’un service systemd, par exemple Nginx :

systemctl show nginx --property=LimitNOFILE

Pour augmenter proprement la limite de Nginx :

sudo systemctl edit nginx

Ajoutez :

[Service]
LimitNOFILE=1048576

Puis rechargez systemd et redémarrez le service :

sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl show nginx --property=LimitNOFILE

Adaptez la même logique à Apache, PHP-FPM ou tout autre service exposé. Une limite élevée ne rend pas le serveur plus rapide par magie, mais elle évite certains plafonds absurdes lors des pics.

Faut-il modifier la plage des ports éphémères ?

La plage des ports éphémères concerne surtout les connexions sortantes. Elle peut devenir importante si votre serveur ouvre beaucoup de connexions vers d’autres services : API externes, Redis distant, bases distantes, proxy, microservices ou crawlers internes.

Vérifiez la plage actuelle :

sysctl net.ipv4.ip_local_port_rangeCode language: CSS (css)

Une plage classique et plus large :

net.ipv4.ip_local_port_range = 10240 60999

Ne changez pas cette valeur sans raison. Sur un serveur web principalement entrant, ce n’est généralement pas le premier levier.

Configuration sysctl complète recommandée

Voici une configuration complète, mais encore raisonnable, pour un serveur web Linux moderne. Commentez BBR si vous ne l’avez pas testé.

# /etc/sysctl.d/99-tcp-webserver.conf
# TCP tuning for a modern Linux web server.
# Test changes progressively and monitor after deployment.

# Safe TCP defaults to keep.
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_moderate_rcvbuf = 1

# Queues and SYN handling.
net.core.somaxconn = 8192
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_syncookies = 1

# Moderate FIN_WAIT2 timeout reduction.
net.ipv4.tcp_fin_timeout = 30

# Keepalive behaviour for long idle TCP connections.
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 5

# Larger TCP buffers for throughput.
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728

# Optional: test BBR with fair queueing.
# Uncomment only after checking availability and monitoring impact.
# net.core.default_qdisc = fq
# net.ipv4.tcp_congestion_control = bbrCode language: PHP (php)

Appliquez avec :

sudo sysctl --system

Et gardez un moyen de retour arrière. Par exemple :

sudo mv /etc/sysctl.d/99-tcp-webserver.conf /root/99-tcp-webserver.conf.disabled
sudo sysctl --system

Checklist rapide

• Mesurer avec ss -s avant toute modification.
• Ne pas paniquer devant quelques connexions TIME_WAIT.
• Ne pas utiliser tcp_tw_recycle.
• Ne pas désactiver tcp_sack par défaut.
• Ne pas désactiver tcp_timestamps par réflexe.
• Utiliser un fichier dédié dans /etc/sysctl.d/.
• Tester BBR seulement si le contexte s’y prête.
• Surveiller les erreurs TCP après modification.
• Vérifier aussi Nginx, Apache, PHP-FPM, MySQL, firewall et bots.

FAQ

Beaucoup de connexions TIME_WAIT indiquent-elles un problème ?

Pas forcément. TIME_WAIT est un état normal de TCP. Il devient problématique seulement s’il accompagne une saturation, des erreurs, une attaque, une consommation excessive de ressources ou une application qui ouvre trop de connexions courtes.

Faut-il activer tcp_tw_reuse ?

Pas par défaut. Cette option peut aider dans certains scénarios de connexions sortantes, mais elle ne doit pas être activée au hasard sur un serveur web public. Mesurez d’abord le problème réel.

Pourquoi tcp_tw_recycle est-il déconseillé ?

Parce qu’il cassait des connexions légitimes, notamment derrière du NAT. Il a disparu des noyaux Linux récents. Si vous trouvez encore ce réglage dans un tutoriel, considérez le tutoriel comme périmé.

BBR améliore-t-il toujours les performances ?

Non. BBR peut améliorer certains scénarios, mais il peut aussi ne rien changer, voire dégrader certains comportements selon le réseau, le kernel, la file d’attente et le trafic. Testez avant de généraliser.

Ces réglages suffisent-ils pour accélérer WordPress ?

Non. Ils optimisent certains aspects réseau, mais WordPress dépend surtout du cache, de PHP-FPM, de MySQL, des plugins, du thème, des requêtes SQL, des images, du CDN et de la configuration serveur.

Conclusion

L’optimisation TCP moderne consiste moins à “réduire TIME_WAIT à tout prix” qu’à garder un noyau sain, mesurer correctement, dimensionner les files d’attente et éviter les tweaks dangereux.

Pour un serveur web Linux, gardez SACK, timestamps et window scaling activés. Augmentez prudemment les backlogs, ajustez les buffers si votre trafic le justifie, testez BBR dans les bons cas, puis surveillez les effets.

À lire aussi sur SkyMinds

• Serveur dédié : sécurisation de la couche TCP/IP
• Serveur dédié : analyse des performances du serveur
• Serveur dédié : installer Nginx avec HTTP/2, TLS, PHP et MariaDB
• Installer PHP 8.5 sur Ubuntu Server
• Résoudre l’erreur “is not in the sudoers file” sous Linux

Sources

• Linux man-pages — tcp(7)
• Linux man-pages — ss(8)
• Linux Kernel Documentation — IP sysctl
• Red Hat — Linux tools: How to use the ss command

Report a typo