A cosa servono i server STUN e TURN
WebRTC alimenta videochiamate, condivisione dello schermo e trasferimenti di file da browser a browser. Prima che due dispositivi possano comunicare direttamente, ciascuno deve sapere a quale indirizzo è raggiungibile l'altro. La maggior parte dei dispositivi, però, si trova dietro un router domestico o un firewall aziendale e usa indirizzi privati tradotti tramite NAT. I server STUN e TURN risolvono questo problema:
- STUN indica a un dispositivo come appare da internet: il suo indirizzo IP pubblico e la porta. Con questa informazione, due peer riescono spesso a connettersi direttamente.
- TURN fa da relay quando una connessione diretta è impossibile, ad esempio dietro NAT simmetrico, firewall restrittivi o reti che consentono solo TCP.
Eseguire il test
- Inserisci l'URL del server con il prefisso stun:, turn: o turns: (ad esempio stun:server.example.com:3478 oppure turn:server.example.com:3478?transport=tcp).
- Per i server TURN, compila nome utente e credenziale. Se usi credenziali a tempo, assicurati che non siano scadute.
- Aggiungi altri server se necessario ed esegui il test. Il browser raccoglie i candidati ICE e li elenca uno per uno con tipo, indirizzo, protocollo e tempo impiegato ad arrivare.
Se non hai un server tuo, usa l'opzione per testare i nostri server e vedere come appare un risultato funzionante.
Leggere i tipi di candidato
Ogni riga del risultato è un candidato ICE. Il suo significato dipende dal tipo:
- host: l'indirizzo locale del dispositivo. I browser moderni lo nascondono dietro un nome .local casuale per tutelare la privacy.
- srflx: l'indirizzo pubblico restituito dal server STUN. Se lo vedi, STUN funziona.
- relay: l'indirizzo di relay assegnato dal server TURN. Se lo vedi, TURN e autenticazione funzionano.
- prflx: un indirizzo scoperto durante i controlli di connettività; raramente compare in un test unilaterale.
La colonna del tempo indica dopo quanti millisecondi dall'avvio è arrivato ciascun candidato. Dà un'idea della distanza e del carico del server; tempi di diverse centinaia di millisecondi possono rallentare sensibilmente l'avvio di una chiamata.
Problemi comuni
- Nessun candidato relay: nome utente o password errati, static-auth-secret non corrispondente sul server oppure porta TURN bloccata da un firewall.
- Funziona solo su UDP: per gli utenti su reti limitate, aggiungi ?transport=tcp oppure turns: (TLS) sulla porta 443.
- turns: non funziona ma turn: sì: il certificato TLS potrebbe essere non valido, scaduto o non corrispondere al nome host.
- Indirizzo srflx inatteso: con CGNAT o VPN, l'indirizzo pubblico appartiene al tuo provider o al fornitore della VPN.
Il test viene eseguito interamente nel browser; le credenziali inserite vengono usate solo dal browser per connettersi al server che hai indicato. Per vedere il tuo IP pubblico e lo stato delle fughe WebRTC, visita Qual è il mio IP. Per misurare la reale perdita di pacchetti su un canale dati WebRTC, prova il test di perdita pacchetti, e controlla la latenza di base con il ping test prima di ottimizzare la qualità delle chiamate nella tua applicazione.