Wofür STUN- und TURN-Server da sind
WebRTC ist die Grundlage für Videoanrufe, Bildschirmfreigabe und Dateiübertragungen direkt zwischen Browsern. Bevor zwei Geräte direkt miteinander sprechen können, muss jedes wissen, unter welcher Adresse das andere erreichbar ist. Die meisten Geräte stecken jedoch hinter einem Heimrouter oder einer Firmen-Firewall und nutzen private Adressen, die per NAT übersetzt werden. STUN- und TURN-Server lösen dieses Problem:
- STUN teilt einem Gerät mit, wie es aus dem Internet aussieht: seine öffentliche IP-Adresse und seinen Port. Damit können zwei Gegenstellen oft direkt verbunden werden.
- TURN dient als Relay, wenn keine direkte Verbindung möglich ist, etwa hinter symmetrischem NAT, strengen Firewalls oder in Netzen, die nur TCP erlauben.
So führen Sie den Test durch
- Geben Sie die Server-URL mit dem Präfix stun:, turn: oder turns: ein (zum Beispiel stun:server.example.com:3478 oder turn:server.example.com:3478?transport=tcp).
- Tragen Sie bei TURN-Servern Benutzername und Passwort (Credential) ein. Bei zeitlich begrenzten Zugangsdaten achten Sie darauf, dass diese noch gültig sind.
- Fügen Sie bei Bedarf weitere Server hinzu und starten Sie den Test. Ihr Browser sammelt ICE-Kandidaten und listet jeden mit Typ, Adresse, Protokoll und Eintreffzeit auf.
Haben Sie keinen eigenen Server, testen Sie einfach unsere Server, um zu sehen, wie ein funktionierendes Ergebnis aussieht.
Die Kandidatentypen verstehen
Jede Zeile im Ergebnis ist ein ICE-Kandidat. Seine Bedeutung hängt vom Typ ab:
- host: die lokale Adresse des Geräts. Moderne Browser verbergen sie aus Datenschutzgründen hinter einem zufälligen .local-Namen.
- srflx: die vom STUN-Server gemeldete öffentliche Adresse. Erscheint sie, funktioniert STUN.
- relay: die vom TURN-Server zugewiesene Relay-Adresse. Erscheint sie, funktionieren TURN und Authentifizierung.
- prflx: eine bei Verbindungsprüfungen entdeckte Adresse; im einseitigen Test selten zu sehen.
Die Zeitspalte zeigt, wie viele Millisekunden nach dem Start der jeweilige Kandidat eintraf. Das gibt einen Eindruck von Entfernung und Auslastung des Servers; Zeiten von mehreren hundert Millisekunden können den Gesprächsaufbau spürbar verzögern.
Eigenen Server einrichten
Mit Open-Source-Software wie coturn lässt sich ein eigener STUN/TURN-Server betreiben. Nach der Einrichtung sollten Sie mindestens drei Varianten getrennt testen: turn: über UDP, turn: über TCP (?transport=tcp) und turns: über TLS. Achten Sie außerdem darauf, dass der Server seine externe IP-Adresse korrekt meldet. Fehlt diese Einstellung bei einem Server hinter NAT, entsteht zwar ein relay-Kandidat, in echten Gesprächen kommt aber kein Medienstrom zustande.
Häufige Probleme
- Kein relay-Kandidat: falscher Benutzername oder falsches Passwort, ein abweichendes static-auth-secret auf dem Server oder ein von der Firewall blockierter TURN-Port.
- Funktioniert nur per UDP: Ergänzen Sie für Nutzer in eingeschränkten Netzen ?transport=tcp oder turns: (TLS) auf Port 443.
- turns: schlägt fehl, turn: funktioniert: Das TLS-Zertifikat ist möglicherweise ungültig, abgelaufen oder passt nicht zum Hostnamen.
- Unerwartete srflx-Adresse: Bei CGNAT oder VPN gehört die öffentliche Adresse Ihrem Provider bzw. VPN-Anbieter.
Der Test läuft vollständig in Ihrem Browser; die eingegebenen Zugangsdaten nutzt nur Ihr Browser, um sich mit dem angegebenen Server zu verbinden. Ihre öffentliche IP und den WebRTC-Leak-Status sehen Sie unter Meine IP. Echten Paketverlust über einen WebRTC-DataChannel misst der Paketverlust-Test, und die Grundlatenz prüfen Sie mit dem Ping Test, bevor Sie die Gesprächsqualität Ihrer eigenen Anwendung optimieren.