Stand: 06.10.2026
Traefik Proxy 3.4 mit dem Codenamen Chaource erschien im Mai 2025. Das Release brachte unter anderem Redis-Rate-Limiting, P2C-Load-Balancing und neue ACME-Optionen. Für neue Installationen solltest du jedoch eine aktuelle 3.x-Version einsetzen; dieser Beitrag erklärt, was 3.4 eingeführt hat und wie du ein bestehendes Upgrade sauber prüfst.
Auf einen Blick
- Traefik 3.4 ergänzt Redis als verteilten Speicher für den Rate Limiter.
- Der Servers-Load-Balancer kann mit P2C eine Auswahlstrategie nutzen.
- ForwardAuth kann die ursprüngliche HTTP-Methode an den Auth-Dienst weiterreichen.
- Vor dem Upgrade sind Konfiguration, CRDs und ein kontrollierter Rollback wichtig.
Was hat Traefik Proxy 3.4 konkret eingeführt?
Die Release Notes nennen mehrere Erweiterungen, die im Alltag relevant sein können. Dazu gehören acme.profile und acme.emailAddresses. Außerdem lassen sich Server-URLs bei mehreren Label-Providern konfigurieren. Das hilft vor allem bei Docker, Swarm, ECS, Nomad und Consul Catalog.
Im Kubernetes-Umfeld wurde die CEL-Validierung für IngressRoute-CRDs verbessert. Zusätzlich kann Traefik den Ingress-Status für Services vom Typ ClusterIP oder NodePort setzen. Für Gateway API erhielt TLSRoute eine explizite Regelpriorität.
| Bereich | Neuerung in 3.4 | Nutzen |
|---|---|---|
| Rate Limiting | Redis-Unterstützung | Gemeinsame Limits über mehrere Traefik-Instanzen |
| Load Balancing | P2C-Strategie | Serverauswahl anhand zweier Kandidaten |
| ForwardAuth | HTTP-Methode erhalten | Authentifizierungsdienste sehen die ursprüngliche Methode |
| Error Pages | Statuscode umschreiben | Antwortstatus für Fehlerseiten gezielt anpassen |
| TLS | Session Tickets deaktivieren | TLS-Verhalten an Sicherheitsvorgaben anpassen |
Warum ist Redis-Rate-Limiting für mehrere Replikate wichtig?
Ein lokaler Rate Limiter zählt nur innerhalb einer einzelnen Instanz. Läuft Traefik mehrfach, können Clients deshalb je Replica ein eigenes Kontingent erhalten. Mit Redis teilen die Instanzen den Zähler. Dadurch gelten Limits konsistent, auch wenn ein Load Balancer Anfragen verteilt.
Plane Redis trotzdem als Abhängigkeit ein. Prüfe Netzwerk, TLS, Zugangsdaten und das Verhalten bei einem Redis-Ausfall. Setze Rate Limits zudem passend zur Anwendung, nicht nach einer pauschalen Zahl.
Wie funktioniert die P2C-Strategie?
P2C steht für „Power of Two Choices“. Traefik zieht zwei Backends in Betracht und wählt anhand der Last den günstigeren Kandidaten. Die Strategie ist eine Option des Servers-Load-Balancers. Sie ersetzt keine Health Checks und keine sauberen Ressourcenlimits.
Miss daher vor und nach der Umstellung Latenzen, Fehler und die Auslastung der Backends. Für Monitoring-Grundlagen findest du eine Anleitung zu Kubernetes-Monitoring mit Grafana und Prometheus.
Welche Konfiguration gehört wohin?
Traefik trennt statische und dynamische Konfiguration. EntryPoints, Provider, API und Zertifikatsresolver gehören in die statische Konfiguration. Router, Services und Middlewares sind dagegen dynamisch und kommen etwa aus Docker-Labels, Dateiprovider oder Kubernetes-Ressourcen.
Diese Trennung verhindert einen verbreiteten Fehler: Eine Middleware lässt sich nicht sinnvoll in die statische Datei legen und per Neustart erwarten. Definiere sie über den gewählten dynamischen Provider und referenziere sie am Router. Für eigene Erweiterungen siehe Traefik Plugins erstellen.
# statische Konfiguration, zum Beispiel traefik.yml
entryPoints:
websecure:
address: ":443"
providers:
docker: {}
certificatesResolvers:
letsencrypt:
acme:
email: admin@example.invalid
storage: /data/acme.json
httpChallenge:
entryPoint: web
Wie bereitest du ein Upgrade auf Traefik Proxy 3.4 vor?
Traefik Proxy 3.4 war ein Zwischenrelease der 3.x-Reihe. Heute ist es vor allem für Bestandsumgebungen interessant. Prüfe vor jedem Versionssprung die Migrationshinweise der Zielversion und aktualisiere anschließend auf einen gepflegten Patchstand.
- Ist-Zustand sichern: Exportiere die statische Konfiguration, Manifeste, Helm-Werte sowie eine Kopie des ACME-Speichers. Behandle
acme.jsonwie ein Secret. - Versionshinweise lesen: Prüfe besonders Änderungen an Rule-Syntax, Providern und CRDs. Die Optionen
defaultRuleSyntaxundruleSyntaxwurden in 3.4 als veraltet markiert. - Staging aktualisieren: Nutze dieselben Router, Zertifikate nur in einer Testumgebung und repräsentative Backends. Teste HTTP, HTTPS, Weiterleitungen und Authentifizierung.
- Konfiguration validieren: Starte den Container zunächst mit der neuen Image-Version und kontrolliere die Logs sowie das Dashboard nur in einer geschützten Umgebung.
- Rollback vorbereiten: Halte Image-Tag und Konfiguration der vorherigen Version bereit. Wechsle bei Fehlern zurück, statt Konfigurationsänderungen im Live-Betrieb zu raten.
# Docker Compose: Version zunächst in Staging ändern
services:
traefik:
image: traefik:v3.4
command:
- --configFile=/etc/traefik/traefik.yml
Verwende diesen Tag nur, wenn du ein historisches 3.4-Upgrade nachvollziehen musst. Für einen neuen Betrieb wähle stattdessen einen aktuellen, dokumentierten 3.x-Patchstand. Das offizielle GitHub-Release weist für heute v3.7.14 als aktuelle Version aus.
Was solltest du in Kubernetes zusätzlich prüfen?
Vergleiche zuerst die installierten CRDs mit den CRDs der Zielversion. Danach prüfst du IngressRoute, Middleware, TLSOption und ServersTransport. Eine neue CRD-Validierung kann zuvor geduldete, aber fehlerhafte Ressourcen sichtbar machen.
Setzt du ExternalDNS ein, prüfe auch den Ablauf von Ingress-Status und DNS-Einträgen nach dem Rollout. Der Beitrag Traefik und ExternalDNS in Kubernetes zeigt den Zusammenhang. Aktualisiere außerdem nicht blind vom alten Major-Release: Die Anleitung zur Migration auf Traefik v3 behandelt die grundlegenden Brüche von v2 zu v3.
Welche Aussagen aus älteren 3.4-Artikeln sind falsch?
Traefik 3.4 führte keine allgemeine Geo-Blocking-Middleware ein. Auch pauschale Aussagen zu besseren HTTP/3-Latenzen oder einer festen prozentualen Beschleunigung sind ohne reproduzierbaren Benchmark nicht belastbar. Die Release Notes nennen stattdessen konkrete Funktionen wie Redis-Rate-Limiting, P2C und Änderungen an TLS, Middleware und Providern.
JSON-Access-Logs und TLS 1.3 waren zudem nicht erst mit 3.4 neu. Behandle sie daher als bestehende Traefik-Funktionen und konfiguriere sie nach der aktuellen Referenzdokumentation.
Fazit
Traefik Proxy 3.4 brachte nützliche Bausteine für verteilte Limits, Load Balancing und Kubernetes-Validierung. Für produktive Neuinstallationen ist die Version jedoch überholt. Nutze die genannten Funktionen als Upgrade-Kontext, teste in Staging und aktualisiere auf einen aktuellen 3.x-Patchstand.
Quellen
- Traefik Proxy v3.4.0 Release Notes
- Aktuelles Traefik-Release auf GitHub
- Traefik-Migrationsdokumentation
- Traefik-Konfigurationsreferenz
Häufige Fragen
Traefik Proxy 3.4, Codename Chaource, ist ein im Mai 2025 veröffentlichtes 3.x-Release mit unter anderem Redis-Rate-Limiting, P2C-Load-Balancing und neuen Middleware-Optionen.
Nein. Für Neuinstallationen solltest du einen aktuellen, gepflegten 3.x-Patchstand wählen. 3.4 ist vor allem für die Einordnung bestehender Umgebungen relevant.
Redis ermöglicht mehreren Traefik-Replikaten, einen gemeinsamen Zähler für Rate Limits zu verwenden. So gelten Limits konsistent über mehrere Instanzen hinweg.
P2C steht für Power of Two Choices. Der Load Balancer betrachtet zwei Server und wählt abhängig von der Last den günstigeren Kandidaten.





1 Pingback