Hetzner Cloud VPS Tuning: Linux-Kernel & TCP BBR für Sub-50ms TTFB

Hetzner Cloud gehört im DACH-Raum zu den beliebtesten Hosting-Infrastrukturen für mittelständische Unternehmen und E-Commerce-Plattformen. Die AMD EPYC Instanzen (CPX-Serie) in den Rechenzentren Falkenstein und Nürnberg bieten hervorragende Rechenleistung pro Euro. Standardmäßig werden Linux-Images (Ubuntu 22.04 / 24.04 LTS oder Debian 12) jedoch mit generischen Kernel-Parametern ausgeliefert, die auf Desktop- oder Standard-Workloads ausgelegt sind – nicht auf hochfrequentierte Webserver.

In Produktionsumgebungen führt dies häufig zu unnötig hohen Time to First Byte (TTFB) Werten von 400ms bis 900ms, obwohl die Hardware-Ressourcen kaum ausgelastet sind.

Hier ist das praxiserprobte Runbook, mit dem wir Hetzner Cloud VPS Instanzen auf einen konstanten TTFB unter 50 Millisekunden optimieren.

1. Diagnose: Identifikation des Netzwerk- & Kernel-Engpasses

Vor jeder Parameteränderung erfassen wir die Baseline über curl und überprüfen den aktuellen TCP Congestion Control Algorithmus:

# Baseline TTFB Latenzmessung gegen den Origin Server
curl -o /dev/null -s -w "DNS: %{time_namelookup}s | Connect: %{time_connect}s | TLS: %{time_appconnect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" https://ihre-domain.de/

# Aktuellen TCP Congestion Control Algorithmus prüfen
sysctl net.ipv4.tcp_congestion_control
# Standard-Rückgabe auf frischen Instanzen meist: "cubic"

Der standardmäßige cubic-Algorithmus reagiert bei minimalem Packet Loss überproportional defensiv und halbiert das Congestion Window ($cwnd$). Googles BBR (Bottleneck Bandwidth and RTT) Algorithmus hält die Bandbreite dagegen am physischen Durchsatzmaximum, ohne die Warteschlangen im Puffer zu überfüllen.

2. Kernel-Tuning: TCP BBR & Socket Backlog in /etc/sysctl.d/99-hetzner-web.conf

Wir hinterlegen eine dedizierte Konfigurationsdatei, die Systemupgrades überdauert:

# /etc/sysctl.d/99-hetzner-web.conf

# 1. BBR Congestion Control & FQ Queuing Disziplin
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# 2. Erhöhung der Verbindungs-Backlogs für Traffic-Peaks
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 16384
net.core.netdev_max_backlog = 16384

# 3. Schnelles Schließen und Wiederverwenden von TIME_WAIT Sockets
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# 4. TCP Window Scaling & Puffergrößen (Optimiert für 10G Hetzner Network)
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 5. Schutz vor SYN-Flood & Portexhaustion
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_syncookies = 1

Aktivieren Sie die Parameter im laufenden Betrieb ohne Serverneustart:

sudo sysctl --system
# Verifizieren, dass BBR aktiv ist:
sysctl net.ipv4.tcp_congestion_control
# Ausgabe: net.ipv4.tcp_congestion_control = bbr

3. CPU-Governor: Umstellung auf Performance

Hetzner Shared CPU Instanzen drosseln ungenutzte vCPUs in Energiesparzustände. Bei unregelmäßigen Web-Anfragen führt das Aufwachen der CPU-Kerne zu mikrosekundengenauen Latenzen, die sich im TTFB aufsummieren:

# Aktuellen Governor prüfen
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# Auf Performance zwingen (falls cpufrequtils installiert ist)
sudo apt-get install -y cpufrequtils
echo 'GOVERNOR="performance"' | sudo tee /etc/default/cpufrequtils
sudo systemctl restart cpufrequtils

4. Hetzner vSwitch / Private Network Latenzen

Wenn Sie separate Instanzen für Nginx (Reverse Proxy) und MySQL/PostgreSQL betreiben, nutzen Sie ausschließlich das Hetzner Cloud Private Network (vSwitch) mit statischen MTU-Einstellungen:

# /etc/netplan/60-hetzner-private.yaml
network:
  version: 2
  ethernets:
    enp7s0:
      addresses:
        - 10.0.0.2/24
      mtu: 1450 # Hetzner Cloud vSwitch empfohlene MTU

Eine falsche MTU (>1450 auf dem internen VXLAN-Tunnel) führt zu stiller Paketfragmentierung und unerklärlichen 1,2-Sekunden-Lags bei Datenbankabfragen.

5. Das Ergebnis: Vorher / Nachher Benchmark

Nach dem Einspielen des Kernel-Tunings und der BBR-Aktivierung auf einer Hetzner CPX31 (4 vCPU AMD, 8 GB RAM):

Keine teurere Hardware, kein Umzug zu einem Managed Hosting Provider — reine Beherrschung der Linux-Systemparameter am Ursprung.

🔗 Zusammenhängende Systemdiagnosen & Infrastruktur-Geflecht:

Server- und Performance-Engpässe treten selten isoliert auf. Origin-Server-Latenzen, Datenbankstrukturen und Frontend-Metriken greifen direkt ineinander:

• MySQL InnoDB Buffer Pool Optimierung für Netcup & Hetzner: Festplatten-I/O eliminieren und Datenbank-Cache im RAM verankern.
• Redis Persistenter Objekt-Cache für Enterprise-Systeme: Wiederkehrende Datenbankabfragen durch In-Memory-Speicher entlasten.
• Varnish Cache als Reverse Proxy vor Nginx: Extrem hohe Parallelzugriffe ohne Origin-Server-Last verarbeiten.