Ihr PostgreSQL-Verbindungspool gibt plötzlich „Server hat die Verbindung unerwartet geschlossen“ zurück. Ihr WebSocket-Client stellt alle zehn Minuten eine neue Verbindung her. Ihre gRPC-API funktioniert lokal, aber in der Produktion hinter einem Load Balancer werden lange Streams ohne Anwendungsprotokolle abgeschnitten.
Der Schuldige ist nicht immer ein Codefehler. Oft hat ein Zwischengerät eine TCP-Leerlaufsitzung beendet, und niemand bemerkte es – bis zum nächsten Schreibvorgang.
Leerlauf-Timeout: Wer schneidet es ab und wann
| Schicht | Typischer Leerlauf-Timeout | Konsequenz |
|---|---|---|
| NAT-Box / 4G | 30 Sek. – 5 Min. | App-seitige „Zombie“-Verbindung |
| Load-Balancer-Cloud | 60er – 3500er | Stilles Herunterfahren während der Anforderung |
| Stateful-Firewall | Variiert | Drop ohne eigenes RST |
| DB-Server | Stunden | Seltener im Standard |
Ohne Datenverkehr verschwindet die Sitzung aus der Statustabelle des Vermittlers. Ihr Prozess glaubt immer noch, dass er verbunden ist.
Keepalive dient dazu, frühzeitig zu erkennen, dass der Pfad tot ist – und nicht, um eine Architektur zu ersetzen, die nützlichen Datenverkehr aufrechterhält.
TCP-Keepalive auf Kernel-Ebene
Linux sendet leere TCP-Probes nach einer Zeit der Inaktivität („tcp_keepalive_time“, Standard ~7200 s – oft zu lang für das Web).
Nützliche Einstellungen:
„Bash sysctl -w net.ipv4.tcp_keepalive_time=600 sysctl -w net.ipv4.tcp_keepalive_intvl=30 sysctl -w net.ipv4.tcp_keepalive_probes=5
Aktivieren Sie „SO_KEEPALIVE“ auf kritischen Server-Sockets (PostgreSQL „tcp_keepalives_*“, Redis, Proxys).
**Einschränkung**: Keepalive durchläuft nicht immer HTTP-Proxys, die TCP beenden. Legen Sie hinter Nginx auch „proxy_read_timeout“ und „proxy_send_timeout“ fest.
:::Hinweis
**Zur Erinnerung.** Keepalive TCP = Erkennung toter Peers. Anwendungs-Heartbeat = Geschäftslogik + Erkennung. Die beiden ergänzen sich; „none“ ersetzt einen schlecht konfigurierten Timeout-Load-Balancer.
:::
## Anwendungs-Heartbeat: Wenn TCP nicht ausreicht
Für WebSocket-, SSE- oder DB-Verbindungen über Pooler:
- **WebSocket**: RFC 6455 Ping/Pong oder periodische JSON-Nachricht (< NAT-Intervall).
- **ORM-Pools**: `pool_pre_ping` (SQLAlchemy), Abfragevalidierung beim Auschecken.
- **Nachrichtenwarteschlangen**: AMQP-Heartbeat, regelmäßige Verbraucherbestätigung.
Kalibrieren Sie das Intervall **unter** dem kürzesten Timeout in der Kette (NAT < LB < app).
## Load Balancer und Cloud-Host
Für verwaltete Angebote gelten feste Zeitüberschreitungen:
- AWS ALB im Leerlauf: bis zu 4000 s konfigurierbar.
- Nginx-Standard: 60 s auf dem Proxy.
- Cloudflare: 100 s bei klassischen HTTP-Verbindungen.
Lesen Sie das Dokument für *Ihre* Ebene – und stellen Sie dann Keepalive + Heartbeat entsprechend ein. Öffnen Sie ein Host-Support-Ticket, wenn das Standard-Timeout mit Ihren langen Flows nicht kompatibel ist.
## Oben: Eine „offene“ Verbindung ist möglicherweise bereits tot
:::Höhepunkt
**Fehler treten beim nächsten Schreibvorgang auf, nicht beim Herunterfahren.** Aus diesem Grund geben Pools ohne Validierung unter Last „zufällige“ Fehler zurück. Keepalive verringert das Unsicherheitsfenster – es entbindet jedoch nicht von der Verpflichtung, Wiederverbindungen ordnungsgemäß auf der Anwendungsseite zu handhaben.
:::
Die endgültige Robustheit bleibt in Ihrem Wiederholungs- und Wiederverbindungscode.
## Entscheide dich und gehe ohne blinden Fleck voran
1. **Machen Sie die Zeitüberschreitungen** von NAT, LB, Proxy und DB in einem Diagramm zuordnen.
2. **SO_KEEPALIVE aktivieren** + angepasste Sysctl-Einstellungen auf Servern.
3. **Anwendungs-Heartbeat hinzufügen** für WebSocket und langlebige Pools.
4. **Lasttest** mit bewussten Leerlaufverbindungen.
Vergleichen Sie Hosts und ihre Netzwerkgrenzen in unserem [Verzeichnis](/de/verzeichnis/).
## Häufig gestellte Fragen
### Was ist der Unterschied zwischen TCP-Keepalive und Anwendungs-Heartbeat?
Keepalive = Kernel prüft, ob ein toter Peer erkannt wird. Heartbeat = Geschäftsnachricht, die auch die Latenz messen oder eine Sitzung aktualisieren kann.
### Warum brechen meine DB-Verbindungen nach 5 oder 15 Minuten ab?
NAT, Firewall oder Load Balancer schließen inaktive Sitzungen; Der Client geht davon aus, dass die Verbindung offen ist.
### Welche Linux-Einstellungen sollte ich anpassen?
tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes – kürzere Zeit bei kurzen Zwischen-Timeouts.
### Verbraucht Keepalive viel Bandbreite?
Nein – ein paar Bytes pro Sonde; Vermeiden Sie ein zu aggressives Intervall bei Tausenden von Verbindungen.
---
Eine nützliche Verbindung ist nicht eine, die in einer Tabelle offen bleibt, sondern eine, die zwischen zwei tatsächlichen Anfragen **stille NATs überlebt**.