Qué hacen los servidores STUN y TURN
WebRTC hace posibles las videollamadas, la compartición de pantalla y las transferencias de archivos entre navegadores. Antes de que dos dispositivos puedan comunicarse directamente, cada uno necesita saber en qué dirección puede localizar al otro. Sin embargo, la mayoría de los dispositivos están detrás de un router doméstico o de un cortafuegos corporativo y usan direcciones privadas traducidas mediante NAT. Los servidores STUN y TURN resuelven esto:
- STUN le dice a un dispositivo cómo se ve desde internet: su dirección IP y su puerto públicos. Con esa información, dos pares a menudo pueden conectarse directamente.
- TURN actúa como relé cuando una conexión directa es imposible, por ejemplo detrás de un NAT simétrico, de cortafuegos estrictos o en redes que solo permiten TCP.
Cómo ejecutar el test
- Introduce la URL del servidor con el prefijo stun:, turn: o turns: (por ejemplo, stun:server.example.com:3478 o turn:server.example.com:3478?transport=tcp).
- En los servidores TURN, rellena el usuario y la credencial. Si usas credenciales de tiempo limitado, asegúrate de que no hayan caducado.
- Añade más servidores si lo necesitas y ejecuta el test. Tu navegador recopila los candidatos ICE y muestra cada uno con su tipo, dirección, protocolo y el tiempo que tardó en llegar.
Si no tienes servidor propio, usa la opción para probar nuestros servidores y ver cómo es un resultado correcto.
Cómo interpretar los tipos de candidato
Cada fila del resultado es un candidato ICE. Su significado depende de su tipo:
- host: la dirección local del propio dispositivo. Los navegadores modernos la ocultan tras un nombre .local aleatorio por privacidad.
- srflx: la dirección pública que indica el servidor STUN. Si aparece, STUN funciona.
- relay: la dirección de relé asignada por el servidor TURN. Si aparece, TURN y la autenticación funcionan.
- prflx: una dirección descubierta durante las comprobaciones de conectividad; rara vez aparece en un test unilateral.
La columna de tiempo muestra cuántos milisegundos después del inicio llegó cada candidato. Da una idea de la distancia y la carga del servidor; tiempos de varios cientos de milisegundos pueden retrasar notablemente el establecimiento de una llamada.
Problemas habituales
- Ningún candidato relay: usuario o contraseña incorrectos, un static-auth-secret que no coincide en el servidor o el puerto TURN bloqueado por un cortafuegos.
- Solo funciona por UDP: para usuarios en redes restringidas, añade ?transport=tcp o turns: (TLS) en el puerto 443.
- turns: falla pero turn: funciona: puede que el certificado TLS no sea válido, haya caducado o no coincida con el nombre de host.
- Dirección srflx inesperada: con CGNAT o una VPN, la dirección pública pertenece a tu proveedor de internet o de VPN.
El test se ejecuta íntegramente en tu navegador; las credenciales que introduces solo las usa tu navegador para conectarse al servidor indicado. Para ver tu IP pública y el estado de fugas WebRTC, visita ¿Cuál es mi IP?. Para medir la pérdida de paquetes real sobre un canal de datos WebRTC, prueba el test de pérdida de paquetes, y comprueba la latencia base con el test de ping antes de ajustar la calidad de las llamadas en tu propia aplicación.