O que fazem os servidores STUN e TURN
O WebRTC está por trás de chamadas de vídeo, compartilhamento de tela e transferências de arquivos entre navegadores. Antes que dois dispositivos possam se comunicar diretamente, cada um precisa saber em qual endereço o outro pode ser alcançado. A maioria dos dispositivos, porém, fica atrás de um roteador doméstico ou de um firewall corporativo, usando endereços privados traduzidos por NAT. Os servidores STUN e TURN resolvem isso:
- STUN informa ao dispositivo como ele é visto a partir da internet: seu endereço IP público e sua porta. Com essa informação, dois pares muitas vezes conseguem se conectar diretamente.
- TURN atua como retransmissor quando a conexão direta é impossível, por exemplo atrás de NAT simétrico, firewalls restritivos ou redes que só permitem TCP.
Executando o teste
- Digite a URL do servidor com o prefixo stun:, turn: ou turns: (por exemplo, stun:server.example.com:3478 ou turn:server.example.com:3478?transport=tcp).
- Para servidores TURN, preencha o usuário e a credencial. Se você usa credenciais com prazo de validade, confira se não expiraram.
- Adicione mais servidores, se necessário, e execute o teste. Seu navegador reúne os candidatos ICE e lista cada um com tipo, endereço, protocolo e o tempo que levou para chegar.
Se você não tem um servidor próprio, use a opção de testar os nossos servidores para ver como é um resultado funcionando.
Entendendo os tipos de candidato
Cada linha do resultado é um candidato ICE. O significado depende do tipo:
- host: o endereço local do próprio dispositivo. Navegadores modernos o escondem atrás de um nome .local aleatório por privacidade.
- srflx: o endereço público informado pelo servidor STUN. Se aparecer, o STUN está funcionando.
- relay: o endereço de retransmissão alocado pelo servidor TURN. Se aparecer, o TURN e a autenticação estão funcionando.
- prflx: um endereço descoberto durante as verificações de conectividade; raramente aparece em um teste de um lado só.
A coluna de tempo mostra quantos milissegundos após o início cada candidato chegou. Ela dá uma ideia da distância e da carga do servidor; tempos de várias centenas de milissegundos podem atrasar visivelmente o início de uma chamada.
Problemas comuns
- Nenhum candidato relay: usuário ou senha incorretos, static-auth-secret divergente no servidor ou porta TURN bloqueada por firewall.
- Funciona só em UDP: para usuários em redes restritas, adicione ?transport=tcp ou use turns: (TLS) na porta 443.
- turns: falha, mas turn: funciona: o certificado TLS pode estar inválido, expirado ou não corresponder ao nome do host.
- Endereço srflx inesperado: com CGNAT ou VPN, o endereço público pertence ao seu provedor ou ao serviço de VPN.
O teste roda inteiramente no seu navegador; as credenciais que você digita são usadas apenas pelo navegador para se conectar ao servidor indicado. Para ver seu IP público e o status de vazamento WebRTC, acesse Qual é o Meu IP. Para medir a perda de pacotes real em um canal de dados WebRTC, experimente o teste de perda de pacotes, e confira a latência de base com o teste de ping antes de ajustar a qualidade das chamadas na sua própria aplicação.