Se hai mai provato ad accedere al tuo homelab da una rete mobile in India, da un hotel con WiFi restrittivo, o da dietro un CGNAT del tuo ISP — conosci il dolore. La connessione Tailscale funziona, ma a 2 Mbps via DERP con latenza allucinante. Addio streaming, addio trasferimenti file, addio Proxmox da remoto.
Il 18 febbraio 2026, Tailscale ha reso GA (Generally Available) i Peer Relays — e i risultati cambiano tutto: da 2.2 Mbps a 27.5 Mbps nello stesso scenario. Un miglioramento di 12,5x. Ecco come funzionano e come configurarli.
Il problema: DERP non basta
Tailscale seleziona automaticamente il percorso migliore tra i tuoi dispositivi:
- Connessione diretta: NAT traversal riuscito. Latenza minima. Funziona nel ~90% dei casi.
- Peer Relay: quando il diretto fallisce, un tuo dispositivo fa da relay. Capacità dedicata. Novità.
- DERP: fallback sui server Tailscale. TCP over TLS, infrastruttura condivisa, QoS throttling.
Il problema è quel 10% di connessioni che finiscono su DERP. ISP con CGNAT aggressivo (Jio, Airtel, Iliad in alcune zone), symmetric NAT che rompe l'UDP hole punching, firewall aziendali restrittivi, AWS/Azure NAT Gateway — tutti scenari in cui la connessione diretta fallisce e il traffico viene instradato su server condivisi a migliaia di km di distanza.
Peer Relays: come funzionano
Un Peer Relay è semplicemente un nodo del tuo tailnet configurato come relay. La differenza rispetto a DERP è fondamentale:
- Protocollo UDP invece di TCP over TLS — meno overhead, meno latenza
- La tua infrastruttura — nessuna competizione per banda, nessun throttling
- Posizionamento strategico — lo piazzi vicino alle risorse che servono
- Crittografia WireGuard end-to-end — il relay non può decifrare nulla
Il relay ascolta su una porta UDP configurabile. Entrambi i client stabiliscono connessioni UDP indipendenti verso il nodo relay, che inoltra pacchetti opachi (cifrati WireGuard) tra le due connessioni. Solo nodi autenticati del tuo tailnet possono accedere.