Se devi mettere online un servizio reverse proxy davanti a container Docker o in cluster Kubernetes, c’è nginx, lo standard de facto, robusto ma rigido nella sua configurazione statica. Poi HAProxy, eccellente per il load balancing ma poco amichevole nei moderni stack containerizzati. E poi ingress-nginx in Kubernetes: ma a novembre 2025 il Kubernetes SIG Network ha fissato la fine del supporto a ingress-nginx (marzo 2026), ovvero niente più patch di sicurezza, niente più aggiornamenti, niente più bug fix. Una parte enorme dell’infrastruttura web mondiale si è ritrovata a dover scegliere il successore.
In questo vuoto si è inserito Traefik, il reverse proxy scritto in Go nato nel 2016 dalla mente di Emile Vauge. La versione 3.7.1, rilasciata a maggio 2026, è quella che porta la piattaforma a una maturità diversa, con supporto nativo per HTTP/3, OpenTelemetry integrato, Gateway API per Kubernetes e, soprattutto, un provider dedicato che traduce automaticamente le annotation di ingress-nginx in configurazione Traefik. RKE2 di SUSE l’ha adottato come ingress controller di default dalla v1.36, e diverse distribuzioni Kubernetes stanno seguendo lo stesso tracciato.
Il punto di forza di Traefik è l’auto-scoperta dinamica (auto-discovery). Quando si avvia un nuovo container Docker sul server, Traefik se ne accorge da solo, legge le “etichette” del container, genera la configurazione al volo, crea il certificato SSL con Let’s Encrypt e inizia a mandargli traffico. Tutto in automatico, senza scrivere un solo file di configurazione e senza riavvi. Vediamo come funziona, perché ha senso adottarlo, e come tirarlo su in mezz’ora su un VPS qualsiasi.
Cosa cambia rispetto a un reverse proxy classico
Per capire perché Traefik abbia conquistato tanto terreno, bisogna ricordare come si configura un proxy tradizionale. Con nginx, ogni volta che aggiungi un servizio devi aprire nginx.conf, scrivere un nuovo blocco server, definire l’upstream, salvare, lanciare nginx -t per validare e infine nginx -s reload per applicare. Se hai dieci servizi e devi cambiare un certificato, la procedura si ripete.
Traefik ribalta questo modello. La sua configurazione si divide in due parti, statica e dinamica. La parte statica (file traefik.yml o argomenti CLI) definisce i punti d’ingresso, i provider e i resolver per i certificati. Si carica all’avvio e cambia raramente. La parte dinamica, invece, descrive i router, i middleware e i service, ed è in continuo aggiornamento.
La dinamica può arrivare da fonti diverse, chiamate appunto provider. Il Docker provider legge le label dei container in tempo reale tramite il socket /var/run/docker.sock. Il file provider monitora una cartella di file YAML che vengono riletti a ogni modifica. Esistono provider per Kubernetes, Consul, etcd, ZooKeeper e altri sistemi di service discovery. Aggiungere un servizio significa scrivere quattro label nel docker-compose.yml, fare docker compose up -d e ritrovarsi l’URL pubblico già attivo, con certificato TLS valido.
Il confronto più frequente è con Caddy e Nginx Proxy Manager. Caddy è eccellente per setup semplici dove vuoi un file di configurazione leggibile e HTTPS automatico, ma manca la profondità di Traefik e l’integrazione con Kubernetes. Nginx Proxy Manager offre una bella interfaccia web ma è pensato per chi non vuole sporcare le mani con il codice, e tende a diventare il collo di bottiglia in setup avanzati. Traefik si colloca nel mezzo, scrivi un po’ di YAML e ottieni un controllo molto fine.
Come funziona Traefik
L’architettura interna di Traefik si basa su quattro concetti che vale la pena conoscere prima di toccare un file di configurazione. Una volta capiti, tutto il resto diventa una variazione sul tema.
- L’entryPoint è la porta su cui Traefik resta in ascolto. Tipicamente sono due, una per HTTP (porta 80) e una per HTTPS (porta 443), chiamate convenzionalmente web e websecure
- Il router è la regola che decide quale traffico va dove, basandosi su host, path, headers o altre condizioni. Una Host rule del tipo
Host(app.tuosito.it) è il caso più comune - Il middleware è uno o più filtri applicati prima che il traffico arrivi al servizio finale. Possono fare redirect, autenticazione, rate limiting, manipolazione degli header e molto altro
- Il service è la destinazione vera, di solito un container Docker o un set di pod Kubernetes che gestisce la richiesta
Il flusso di una richiesta è lineare. Arriva sulla porta 443, l’entryPoint websecure la accetta, il router cerca una regola che combaci con l’host richiesto, applica i middleware configurati (per esempio aggiunge header di sicurezza), e infine inoltra al service. Ogni passaggio è osservabile dalla dashboard integrata e dai log strutturati.
La cosa che spesso disorienta chi viene da nginx è la mancanza di un file sites-enabled da gestire manualmente. In Traefik, l’esistenza stessa di un container con la label traefik.enable=true dichiara al proxy “ehi, gestiscimi“. Cancelli il container, sparisce la rotta. Riavvii il container con label diverse, la nuova configurazione è attiva nel giro di secondi. È zero downtime nativo, senza dover pensare a reload manuali.
Installare Traefik con Docker Compose
Il setup più tipico per un homelab o un VPS singolo usa Docker Compose. Servono pochi file e una struttura di cartelle pulita. Crea una directory traefik e al suo interno il seguente docker-compose.yml.
services:
traefik:
image: traefik:v3.7
container_name: traefik
restart: unless-stopped
ports:
- "80:80"
- "443:443"
- "8080:8080" # dashboard, da disabilitare in produzione
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- ./traefik.yml:/etc/traefik/traefik.yml:ro
- ./acme.json:/acme.json
- ./logs:/var/log/traefik
networks:
- proxy
networks:
proxy:
external: trueLa rete proxy è esterna perché ci si collegheranno tutti gli altri container. Crearla è banale.
docker network create proxyAdesso serve il file traefik.yml con la configurazione statica. Questo definisce gli entryPoint, il provider Docker, il resolver ACME e il logging.
api:
dashboard: true
insecure: true # solo per test locale, in produzione metti basic auth
entryPoints:
web:
address: ":80"
http:
redirections:
entryPoint:
to: websecure
scheme: https
websecure:
address: ":443"
providers:
docker:
endpoint: "unix:///var/run/docker.sock"
exposedByDefault: false
network: proxy
certificatesResolvers:
letsencrypt:
acme:
email: [email protected]
storage: /acme.json
tlsChallenge: {}
log:
level: INFO
filePath: /var/log/traefik/traefik.log
accessLog:
filePath: /var/log/traefik/access.logTre dettagli importanti. Il flag exposedByDefault: false significa che Traefik ignorerà i container che non hanno esplicitamente la label traefik.enable=true, evitando di esporre per sbaglio cose che dovrebbero restare interne. Il tlsChallenge è il metodo più semplice per ottenere certificati Let’s Encrypt e funziona se le porte 80 e 443 sono raggiungibili da internet. Il file acme.json va creato vuoto con permessi 600.
touch acme.json
chmod 600 acme.json
docker compose up -dAprendo http://IP-DEL-SERVER:8080 vedrai la dashboard di Traefik, ancora vuota perché non hai esposto alcun servizio. Da qui controlli router, middleware, service e provider attivi in tempo reale.
Il primo servizio, ACME e HTTPS automatico
Per vedere il flusso completo, niente di meglio del classico whoami, un piccolo container che restituisce informazioni sulla richiesta in arrivo. Crea un secondo docker-compose.yml in una directory separata.
services:
whoami:
image: traefik/whoami
container_name: whoami
restart: unless-stopped
networks:
- proxy
labels:
- "traefik.enable=true"
- "traefik.http.routers.whoami.rule=Host(`test.tuosito.it`)"
- "traefik.http.routers.whoami.entrypoints=websecure"
- "traefik.http.routers.whoami.tls=true"
- "traefik.http.routers.whoami.tls.certresolver=letsencrypt"
- "traefik.http.services.whoami.loadbalancer.server.port=80"
networks:
proxy:
external: trueLe label fanno tutto il lavoro. La prima abilita Traefik su questo container. La seconda definisce la regola del router (il dominio da matchare). La terza e la quarta dicono di servirlo via HTTPS con il resolver letsencrypt configurato prima. L’ultima specifica la porta interna del container a cui inoltrare il traffico.
Prima di lanciare docker compose up -d, assicurati che il dominio test.tuosito.it punti via DNS all’IP del server. Al primo avvio, Traefik contatta Let’s Encrypt, completa la TLS challenge sulla porta 443 e salva il certificato in acme.json. Dal momento dopo, aprire https://test.tuosito.it mostra il classico output di whoami, con un certificato valido e nessun warning del browser.
Per chi gestisce molti sottodomini wildcard o non può aprire la porta 80, l’alternativa è la DNS-01 challenge. Si configura il resolver per parlare con l’API del registrar (Cloudflare, OVH, Hetzner DNS, Route53 e una sessantina di altri sono supportati), e Traefik dimostra il possesso del dominio creando record TXT temporanei. È il metodo da scegliere se vuoi un certificato wildcard del tipo *.tuosito.it.
certificatesResolvers:
letsencrypt:
acme:
email: [email protected]
storage: /acme.json
dnsChallenge:
provider: cloudflare
resolvers:
- "1.1.1.1:53"Ricordati di passare le credenziali API al container Traefik come variabili d’ambiente, per esempio CF_DNS_API_TOKEN per Cloudflare. La documentazione ufficiale ha la lista completa di tutte le variabili attese per ogni provider.
I middleware importanti da conoscere
Qui Traefik fa davvero la differenza rispetto a soluzioni più semplici. I middleware sono il livello dove si modella il comportamento del proxy senza toccare le applicazioni. Ce ne sono decine, ma cinque coprono il 90% dei casi reali.
Il primo è il redirect HTTPS, già visto nella configurazione statica ma replicabile anche a livello di middleware. Forza tutto il traffico HTTP a passare su HTTPS, una buona pratica che dovresti applicare ovunque.
Il secondo è il rate limit, un filtro che limita le richieste per IP in un certo intervallo di tempo. Se hai un’API o un form di login pubblico, è il modo più pulito per scoraggiare brute force e abusi.
labels:
- "traefik.http.middlewares.limit.ratelimit.average=100"
- "traefik.http.middlewares.limit.ratelimit.burst=50"
- "traefik.http.routers.app.middlewares=limit@docker"Il terzo è la basic auth, perfetta per proteggere dashboard interne tipo quella di Traefik stesso, di Portainer o di Prometheus. La password va passata come hash bcrypt o htpasswd, non in chiaro.
htpasswd -nb admin tuapassword
# admin:$2y$05$XYZ...labels:
- "traefik.http.middlewares.auth.basicauth.users=admin:$$2y$$05$$XYZ..."
- "traefik.http.routers.dashboard.middlewares=auth@docker"Attenzione al doppio dollaro $$ nei file Docker Compose, serve a evitare che Compose interpreti la stringa come variabile d’ambiente.
Il quarto è il secure headers, un pacchetto di intestazioni HTTP che alza il livello di sicurezza percepito dai browser. HSTS, X-Frame-Options, Content-Security-Policy e altri header che, se gestiti uno per uno, fanno perdere molto tempo.
labels:
- "traefik.http.middlewares.secure-headers.headers.stsSeconds=31536000"
- "traefik.http.middlewares.secure-headers.headers.stsIncludeSubdomains=true"
- "traefik.http.middlewares.secure-headers.headers.frameDeny=true"
- "traefik.http.middlewares.secure-headers.headers.contentTypeNosniff=true"Il quinto è il compress, che applica gzip e brotli alle risposte. Banale da abilitare con traefik.http.middlewares.gzip.compress=true, ma fa risparmiare banda non da poco su risposte JSON o HTML pesanti.
I middleware si possono concatenare con la sintassi middlewares=auth@docker,limit@docker,secure-headers@docker, e Traefik li applica in ordine prima di raggiungere il service finale. È un modello mentale molto pulito che rende facile capire cosa succede a ogni richiesta.
Le novità di v3.7 e il dopo ingress-nginx
La versione 3.7.0, rilasciata il 5 maggio 2026, è l’aggiornamento più orientato alla migrazione mai pubblicato dal team di Traefik Labs. Il pezzo forte è il provider kubernetesIngressNGINX, una shim che legge le risorse Ingress esistenti con le loro annotation NGINX e le traduce automaticamente in configurazione Traefik. In pratica, su un cluster Kubernetes puoi installare Traefik fianco a fianco con ingress-nginx, spostare gradualmente i workload modificando il campo ingressClassName e tenere lo stesso file YAML che già funziona. È la via meno traumatica possibile per uscire da ingress-nginx.
Le novità non si fermano qui. La feature Multi-Layer Routing introdotta in Traefik Hub consente di valutare i router in sequenza secondo priorità esplicite, abilitando pattern come API versioning, blue-green deployment e A/B testing direttamente a livello di proxy. Lo stesso meccanismo è disponibile in modo più semplice anche in Traefik Proxy standalone, controllando l’ordine di matching con la label traefik.http.routers.NAME.priority.
In v3.7 sono arrivati anche due nuovi middleware. L’encodedCharacters permette di gestire i caratteri encodati negli URL in modo più granulare, utile per applicazioni legacy che si aspettano comportamenti specifici. Il refresh del Retry middleware con nuove opzioni dà un controllo più fine su quando ritentare una richiesta fallita, con backoff configurabile.
Ora l’integrazione con OpenTelemetry, già introdotta in v3.0, è diventata stabile e produttiva. Traefik emette nativamente trace, metriche e log strutturati in formato OTLP, che puoi inviare a Grafana Tempo, Jaeger, Datadog o qualunque backend compatibile. Per un homelab serio è il pezzo che mancava per passare da “funziona” a “so esattamente cosa sta succedendo“.
Traefik: considerazioni finali
Traefik nel 2026 si trova in una posizione che pochi software open source raggiungono. È contemporaneamente maturo dopo dieci anni di sviluppo, attivamente migliorato con release stabili ogni paio di mesi, e proiettato su uno scenario in cui la sua quota di mercato è destinata a crescere parecchio nei prossimi mesi. La fine di ingress-nginx non sposterà tutto su Traefik (ci sono Istio Gateway, Kong, Gateway API standalone), ma per chi cerca semplicità e adozione veloce è il candidato più ovvio.
La curva di apprendimento iniziale c’è, non lo nascondo, perché capire la divisione tra configurazione statica e dinamica, padroneggiare la sintassi delle label e dominare i middleware richiede qualche giorno di pratica. Ma una volta superato lo scoglio, aggiungere un nuovo servizio diventa un’operazione da trenta secondi.
L’unico aspetto su cui consiglio cautela è la dashboard. Quella di default è insicura (api.insecure: true) , in produzione mettila dietro basic auth e idealmente accessibile solo via VPN o WireGuard. Esporre la dashboard pubblicamente non è una buona idea. Per il resto, vale la pena dedicare del tempo a costruirsi un setup proprio, magari partendo dai repository pubblici di SimpleHomelab o di altri appassionati che hanno già fatto il grosso del lavoro.
