Nextcloud Talk call problems are often described as “bad video quality,” but the underlying causes are not all the same. A user may have enough bandwidth and still fail to connect because a firewall blocks peer-to-peer WebRTC traffic. Another call may connect successfully through TURN but feel slower because all media is being relayed. A larger meeting may struggle even with a perfectly working TURN server because the deployment is still using the built-in peer-to-peer topology instead of the High Performance Backend.
The most useful troubleshooting approach is therefore to separate connectivity, media path, and scalability. As of October 6, 2026, Nextcloud's upstream Talk documentation still describes TURN as the fallback when direct WebRTC connectivity is not possible and recommends port 443 for maximum compatibility. It also notes that a TURN server can still be required when the High Performance Backend is in use. See the official Nextcloud Talk TURN documentation and official coturn setup guidance for Talk.
Use the symptom pattern to choose the next action instead of changing several settings at once.
| Symptom | Most likely area | First action | Trade-off |
|---|---|---|---|
| Call works on one network but fails from a corporate or hotel network | Firewall, NAT, or missing TURN fallback | Verify TURN over UDP/TCP and, where needed, TLS on port 443 | Relaying improves reachability but consumes TURN bandwidth and may add latency |
| Two-person calls are fine, larger calls become unstable | Call topology and client upload/CPU load | Evaluate the Nextcloud Talk High Performance Backend | More infrastructure, but better scaling for multi-participant calls |
| Video connects but is pixelated or freezes | Packet loss, latency, Wi-Fi, uplink capacity, or overloaded endpoints | Test from a wired or known-good network before changing TURN | TURN cannot create bandwidth that is not available |
| TURN test fails even though coturn is running | Secret mismatch, firewall, NAT mapping, DNS, or relay ports | Check credentials, public IP mapping, and relay range | Opening a large relay range is simpler; narrowing it reduces exposed ports but requires deliberate capacity planning |
Iniziate con due brevi test. Innanzitutto, effettuate una chiamata tra due client su reti semplici, come due normali connessioni a banda larga. Quindi ripetete il test da una rete più restrittiva, come il Wi-Fi aziendale, una VPN o un hotspot mobile. Se il problema si verifica solo con la rete più restrittiva, TURN è un forte sospettato. Se entrambe le chiamate vanno a buon fine ma la qualità video è scarsa, raccogliete dati di rete e del dispositivo prima di modificare l'architettura di inoltro.
La sequenza di connessione documentata di Nextcloud tenta prima una connessione peer-to-peer diretta, utilizza STUN per individuare gli indirizzi raggiungibili e si affida a TURN quando non è possibile stabilire un percorso diretto. Ciò significa che TURN è principalmente una soluzione di ripiego per la connettività , non un sistema universale per migliorare la qualità video. Un percorso instradato può essere più affidabile, ma è anche più lungo e sposta la larghezza di banda multimediale sul server TURN.
Per le implementazioni self-hosted, coturn è l'implementazione TURN più comune documentata da Nextcloud. Nextcloud consiglia l'autenticazione con chiave segreta condivisa per questa integrazione. Genera una chiave segreta casuale robusta e utilizza lo stesso valore sia in coturn che nelle impostazioni di amministrazione di Talk.
openssl rand -hex 32Una configurazione minima include in genere una porta di ascolto, il fingerprinting, l'autenticazione tramite chiave condivisa, un realm e le restrizioni peer. La posizione esatta del file dipende dal sistema operativo e dal pacchetto utilizzato. Una configurazione rappresentativa è la seguente:
listening-port=443
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_RANDOM_SECRET
realm=turn.example.com
total-quota=0
bps-capacity=0
stale-nonce
no-multicast-peersLe versioni precedenti di coturn potrebbero richiedere opzioni non più necessarie nelle versioni più recenti, quindi non copiare ciecamente una vecchia configurazione. La documentazione di Nextcloud relativa a coturn etichetta esplicitamente le direttive dipendenti dalla versione. Verifica la versione di coturn installata confrontandola con le istruzioni di Nextcloud relative a coturn attualmente in uso .
Se coturn si trova dietro un NAT, configura correttamente la mappatura degli indirizzi pubblici e privati. La documentazione di configurazione di coturn spiega la external-ipmappatura e richiede che le porte di inoltro vengano mappate in modo coerente attraverso il NAT. Consulta l' esempio di configurazione di coturn a monte .
Per i contenuti multimediali in tempo reale, UDP è solitamente il protocollo di trasporto preferito perché evita la ritrasmissione di TCP e il blocco in testa alla coda. Tuttavia, alcune reti aziendali e per ospiti bloccano completamente UDP. TCP o TURN su TLS possono fornire una valida alternativa attraverso reti che consentono solo traffico di tipo web.
Per garantire la massima raggiungibilità, Nextcloud consiglia di rimanere in ascolto sulla porta 443 e supporta TURN/TLS. L'utilizzo di entrambi turn:i protocolli turns:migliora la compatibilità, ma implica anche la gestione di certificati e percorsi di trasporto aggiuntivi. Se tutti gli utenti si trovano su reti controllate in cui è noto che UDP funziona, una configurazione più semplice basata su UDP potrebbe essere più facile da gestire. Se gli utenti si connettono regolarmente da hotel, sedi di clienti, uffici con restrizioni di accesso o VPN, il fallback a TCP/TLS è generalmente una soluzione valida, nonostante la configurazione aggiuntiva.
Un errore comune è quello di aprire solo la porta di ascolto di TURN. Il client contatta prima coturn sul suo listener, ma coturn alloca anche endpoint di inoltro per i contenuti multimediali. Le impostazioni predefinite di coturn 49152-65535per l'inoltro dei contenuti multimediali utilizzano porte UDP. Se tale intervallo è bloccato dal firewall dell'host, dal gruppo di sicurezza cloud, dal router a monte o dal dispositivo NAT, l'autenticazione potrebbe avere successo ma il trasferimento dei contenuti multimediali potrebbe comunque fallire.
È possibile mantenere l'intervallo di inoltro predefinito o ridurlo intenzionalmente con min-porte max-port. Il compromesso è semplice: un intervallo ampio è semplice da gestire e offre un'ampia capacità di allocazione; un intervallo ristretto è più facile da descrivere nelle policy del firewall, ma può diventare un collo di bottiglia in termini di capacità se troppi inoltri simultanei richiedono porte. Dimensionare un intervallo ridotto in base alla concorrenza prevista, anziché scegliere un numero piccolo arbitrario.
Se l'host TURN ha un indirizzo privato dietro un router, mantieni la mappatura delle porte uno a uno per l'intervallo di inoltro selezionato e imposta la mappatura dell'indirizzo pubblico in coturn. Se l'host ha un IP pubblico direttamente sulla sua interfaccia, il passaggio di mappatura NAT non è necessario.
Apri l'area di amministrazione di Nextcloud e vai alle impostazioni di Talk. Aggiungi il server TURN utilizzando host e porta senza nome, non un http://URL https://. La documentazione attuale di Nextcloud su Talk afferma che lo schema TURN viene selezionato separatamente, quindi il campo server dovrebbe essere nel formato <server> turn.example.com:443.
Inserisci la stessa chiave segreta condivisa configurata in coturn e abilita i protocolli effettivamente accettati dal tuo server. Se utilizzi TLS, seleziona lo schema TURN corrispondente e assicurati che il certificato corrisponda al nome host TURN. Puoi anche utilizzare il tuo servizio TURN come server STUN, il che semplifica la gestione degli host, sebbene mantenere STUN e TURN separati possa essere utile quando si desiderano domini di errore indipendenti o relay distribuiti geograficamente.
Non divulgare il segreto condiviso in screenshot, ticket o esempi di configurazione pubblici. Nextcloud lo utilizza per generare credenziali TURN temporanee per i client.
Dopo aver salvato la configurazione di Talk, utilizzare il controllo amministrativo che verifica se il server TURN restituisce candidati ICE utilizzabili. Un risultato positivo dimostra che il browser è riuscito a ottenere candidati funzionanti dal servizio TURN configurato. Ciò non garantisce che ogni rete utente, ogni percorso di inoltro e ogni chiamata di grandi dimensioni funzioneranno correttamente.
Ripeti una chiamata reale da almeno una rete restrittiva. Questo è importante perché un controllo lato server può avere esito positivo mentre una rete utente blocca ancora UDP, la risoluzione DNS o un particolare protocollo di trasporto. Se UDP fallisce ma TCP/TLS sulla porta 443 ha successo, mantieni il percorso di fallback. Se tutti i percorsi falliscono, controlla i log del firewall, i log di coturn, il DNS, la validità del certificato, la chiave segreta condivisa e il mapping NAT.
TURN e il backend ad alte prestazioni risolvono problemi diversi. TURN inoltra il traffico quando i client non riescono a stabilire il percorso WebRTC richiesto. Il backend ad alte prestazioni modifica la gestione dei flussi multimediali multi-partecipante, in modo che ogni partecipante non debba caricare un flusso separato per ogni altro partecipante.
L'interfaccia Talk di Nextcloud avverte che l'esecuzione senza il backend ad alte prestazioni è pensata solo per chiamate di dimensioni molto ridotte, generalmente descritte nel progetto come chiamate con due o tre partecipanti. Se il problema si presenta solo all'aumentare del numero di partecipanti, l'aggiunta di TURN potrebbe rendere raggiungibili più client, ma non eliminerà il carico di upload e CPU peer-to-peer. Prima di scalare le chiamate di gruppo, consultare i requisiti di sistema di Nextcloud Talk e le linee guida del progetto relative al backend ad alte prestazioni.
Anche con il backend ad alte prestazioni, è importante mantenere TURN disponibile quando gli utenti si connettono da reti con restrizioni. Nextcloud documenta un intervallo di porte multimediali WebRTC predefinito 20000-40000per il backend e specifica che un client limitato alla porta 443 potrebbe comunque richiedere a TURN di inoltrare i pacchetti a tale intervallo di porte del backend.
| Opzione | Dettagli | Costi e limiti | Migliore vestibilità |
|---|---|---|---|
| ritorno autogestito | Controllo completo, percorso dati sotto la vostra amministrazione, configurazione prevedibile | Gestisci certificati, aggiornamenti, monitoraggio, larghezza di banda, policy del firewall e capacità geografica. | Organizzazioni con competenze infrastrutturali o requisiti di controllo rigorosi |
| Turno gestito | Minore impegno operativo e potenziale maggiore facilità di copertura geografica. | I costi di servizio continuativi e i contenuti multimediali potrebbero transitare attraverso un fornitore di servizi di inoltro di terze parti. | Team che privilegiano la semplicità operativa e la portata multiregionale |
| Vietato svoltare | Costo del server più basso e percorso più breve quando WebRTC diretto funziona sempre | Le chiamate possono fallire su NAT simmetrici e firewall restrittivi | Ambienti controllati in cui le reti client sono note e testate |
min-porteffettiva max-port.Se Nextcloud Talk funziona su alcune reti ma non su altre, configura un servizio TURN correttamente raggiungibile e verifica il listener, la chiave segreta condivisa, il mapping NAT e le porte di inoltro. Se le chiamate si connettono ma la qualità è scarsa, misura innanzitutto il carico della rete client e dell'endpoint, poiché TURN può aggiungere latenza anziché rimuoverla. Se il problema si aggrava con l'aumentare del numero di partecipanti, la soluzione architetturale più appropriata è solitamente l'utilizzo del backend ad alte prestazioni, mantenendo TURN come soluzione di compatibilità per le reti con restrizioni.
Scopri cosa fa Microsoft IIS, come funzionano la sua pipeline di richieste e i pool di applicazioni e quando Apache, NGINX o Caddy potrebbero essere più adatti alle tue esigenze di server web.
Diagnostica i picchi di utilizzo della CPU del browser Jitsi Meet e riduci il carico del client controllando i riquadri video, gli effetti della fotocamera, la grafica del browser e le impostazioni dell'host.
Monitora lo stato di salute, il carico della conferenza e il traffico di Jitsi Videobridge con il suo endpoint Prometheus integrato, quindi esplora e visualizza i dati in Grafana.
Configura un dominio personalizzato per Jitsi Meet Docker con DNS, URL pubblico, HTTPS, Let's Encrypt, porte del firewall, impostazioni NAT e verifica end-to-end.
Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.
Scopri come diagnosticare e risolvere l'avviso di configurazione di PHP OPcache di Nextcloud controllando l'SAPI PHP attivo, i limiti di dimensionamento, i commenti e le impostazioni di riconvalida.
Risolvere i problemi di migrazione del database Kopano dopo un aggiornamento di MySQL o MariaDB verificando i backup, le versioni del server, le modalità SQL, il set di caratteri, lo stato dello schema e i log.
Collega Nextcloud a LDAP o Active Directory con trasporto sicuro, filtri per utenti e gruppi, attributi di accesso e un'implementazione collaudata.
Risolvi i problemi di notifiche di Element Android sui telefoni senza Google configurando UnifiedPush, le autorizzazioni Android, le impostazioni della batteria ed eseguendo test di verifica affidabili.
Risolvi l'avviso di Nextcloud relativo agli indici del database mancanti utilizzando il comando ufficiale occ. Prima di procedere, esegui un backup, visualizza in anteprima le modifiche, avvia la riparazione e verifica il risultato.
