OBS não conecta na rede do evento: qual porta?

Esse é um dos chamados mais previsíveis de quem transmite evento: tudo foi testado, a live subiu no escritório, e no auditório o encoder fica tentando reconectar. Quase nunca é defeito do OBS nem da plataforma. É a rede entre os dois, e dá para provar isso em dois minutos, sem abrir o OBS, e chegar ao administrador da rede com o pedido certo.

O roteiro abaixo parte de um trecho do episódio do Café & Tech Podcast sobre transmissão de eventos, transmitido ao vivo em 23/10/2024 pelo canal JMV Technology, com Mário Sérgio e Josimar Machado. As portas, os comandos e o que cada plataforma documenta foram conferidos nas fontes oficiais em 13/10/2026, com link em cada afirmação.

O sintoma: funciona em casa, falha no local

O problema tem assinatura. Mesma máquina, mesma chave, mesmo OBS: transmite de casa ou pelo celular e não transmite na rede do local. No OBS, isso aparece como falha ao conectar com o servidor (em algumas versões, “não foi possível conectar ao servidor”), como tempo de conexão esgotado ou como o encoder desconectando e reconectando em laço logo depois de iniciar.

Antes de mexer em qualquer configuração, faça o teste que separa as hipóteses em um minuto: tire o notebook da rede do local e conecte pelo roteamento do celular (hotspot 4G/5G). Não altere mais nada.

• Subiu pelo celular: o OBS, a chave e a plataforma estão certos. O bloqueio é da rede do local, e o resto deste artigo é para você.
• Não subiu nem pelo celular: a rede do local é inocente. Confira a chave e o endereço do servidor; se a live também não sobe pelo 4G, o suspeito é outro: a Família de IP do OBS.

É a pergunta que o Josimar faz no episódio, e que a maior parte das equipes só se faz no dia: “você vai testar o evento da sua casa ou você vai testar o evento usando a estrutura do evento?” (27:26).

Qual porta a transmissão usa: a resposta está na URL

Não existe “a porta do OBS”. O OBS abre uma conexão de saída para o servidor que você configurou, e a porta é a que o endereço desse servidor determina. Abra Configurações → Transmissão e leia o campo Servidor:

O que está no campo “Servidor”	Porta de saída	Transporte
rtmp://endereco/app	1935	TCP
rtmps://endereco/app	443	TCP
rtmp://endereco:PORTA/app	a porta escrita na URL	TCP
srt://endereco:PORTA	a porta escrita na URL, que varia por plataforma	UDP

A 1935 não é convenção de fabricante: é a porta registrada na IANA para o serviço macromedia-fcs, o servidor de mídia que deu origem ao RTMP, como mostra o registro oficial de portas (conferido em 13/10/2026). A 443 é a porta do HTTPS, e o RTMPS é o RTMP dentro de uma conexão TLS que sai por ela.

Para SRT não há porta universal. A documentação da AWS IVS, por exemplo, usa a 9000 (conferido em 13/10/2026); outra plataforma publica outra. Desconfie de qualquer lista que atribua porta fixa ao SRT, inclusive as geradas por IA: vale o número que está na URL que a sua plataforma entrega. E como o SRT viaja sobre UDP, a regra de liberação é outra e o teste de conexão TCP da próxima seção não serve para ele.

Um detalhe que confunde: se o serviço foi escolhido pela lista do OBS (YouTube, por exemplo) em vez de Personalizado, o endereço do servidor não aparece na tela. Nesse caso, a porta é a que a ajuda da própria plataforma documenta.

Como testar a porta em 2 minutos, sem abrir o OBS

O sistema operacional já traz uma ferramenta que tenta abrir uma conexão TCP numa porta remota e diz se conseguiu. Troque endereco-do-servidor pelo domínio do seu servidor, só o nome, sem rtmp:// e sem o caminho depois da barra.

Windows (PowerShell), com o Test-NetConnection:

Test-NetConnection -ComputerName endereco-do-servidor -Port 1935
Test-NetConnection -ComputerName endereco-do-servidor -Port 443

Olhe a última linha da resposta: TcpTestSucceeded : True significa que a porta está aberta para saída; False, que a conexão não passou.

macOS e Linux (Terminal):

nc -vz endereco-do-servidor 1935
nc -vz endereco-do-servidor 443

Para referência, este é o resultado numa rede sem bloqueio. Rodamos o teste em 13/10/2026 contra os endereços de ingest do YouTube:

$ nc -vz a.rtmp.youtube.com 1935
Connection to a.rtmp.youtube.com (172.217.29.108) 1935 port [tcp/*] succeeded!
$ nc -vz a.rtmps.youtube.com 443
Connection to a.rtmps.youtube.com (172.217.162.236) 443 port [tcp/https] succeeded!

Numa rede que bloqueia, o comando fica parado até estourar o tempo ou devolve conexão recusada.

O que transforma esse teste em argumento é fazê-lo em par:

1. Rode os comandos na rede do local e guarde o resultado (print ou texto copiado).
2. Passe o notebook para o hotspot do celular e rode exatamente os mesmos comandos.
3. Compare. Falha na rede do local e sucesso no 4G, com a mesma máquina e o mesmo destino, é a prova de que o bloqueio está na rede. É isso que você anexa ao pedido.

Duas leituras honestas do resultado. Porta fechada garante a falha: se o TCP não conecta, a live não sobe por ali. Porta aberta não garante a transmissão: há redes com proxy obrigatório ou inspeção de tráfego que deixam a conexão abrir e derrubam o protocolo em seguida. Por isso o teste de porta não substitui uma transmissão de teste de alguns minutos, feita no local.

O que pedir ao TI: modelo de mensagem

“Liberar o OBS” não é um pedido que um administrador de rede consiga atender. Firewall não libera programa: libera origem, destino, porta e sentido. Rede de órgão público, banco, hospital ou empresa com política de segurança bloqueia por padrão e abre por regra específica, com prazo. Quanto mais estreito o pedido, mais fácil aprovar.

Assunto: Liberação de saída para transmissão ao vivo - [nome do evento], [data]

Olá, [nome].

Vamos transmitir ao vivo o [evento] a partir do [local/sala] e precisamos de uma regra de SAÍDA no firewall, apenas para o período abaixo:

Origem: [IP ou nome da máquina de transmissão], ponto de rede [sala/ponto]
Destino: [domínio do servidor de ingest, ex.: ingest.plataforma.com]
Porta: TCP 1935 (RTMP) e/ou TCP 443 (RTMPS), somente saída
Período: teste em [data, horário]; evento em [data, das hh:mm às hh:mm]

Anexo o teste de conexão feito hoje nesse ponto de rede: a porta falha aqui e conecta pelo 4G, com a mesma máquina e o mesmo destino.

Depois do evento a regra pode ser removida. Fico à disposição para repetir o teste com você.

Os quatro campos fazem o trabalho. Origem evita abrir a porta para a rede inteira. Destino por domínio limita a regra ao servidor da plataforma. Porta, transporte e sentido deixam claro que é saída, sem nada entrando. Período transforma a exceção em algo temporário, que é o que uma política de segurança costuma exigir.

A antecedência conta tanto quanto o texto. Como diz o Josimar no episódio, em “qualquer setor de governo, prefeitura, existe uma rede ali e alguém cuida dessa rede” (28:37). No dia do evento, essa pessoa pode estar de férias, ou quem abriu o espaço pode nem saber quem ela é. Descubra o nome e o contato na vistoria, não na véspera.

Se não liberarem a 1935: RTMPS na 443

Há redes em que a 1935 não será aberta, e nem sempre por má vontade: é uma porta que nenhum outro serviço da empresa usa. A saída é transmitir pela 443, a mesma porta do HTTPS, que qualquer rede com acesso à web já deixa sair.

Isso depende de a plataforma de destino oferecer um endereço rtmps://:

• O YouTube oferece. A Ajuda do YouTube avisa que o painel mostra por padrão o URL de RTMP comum, que o de RTMPS aparece ao clicar no ícone de bloqueio ao lado do campo, e que, em caso de erro de SSL, vale escrever a porta na URL, no formato rtmps://servidor:443/caminho (conferido em 13/10/2026).
• A AWS IVS trata o RTMPS pela porta de saída 443/TCP como o caminho padrão e o RTMP sem criptografia como opção a habilitar, segundo a documentação de configuração de streaming (conferido em 13/10/2026).
• Para qualquer outra plataforma, inclusive a nossa, a regra é a mesma: confirme com o suporte qual endereço seguro (RTMPS) ela oferece e use exatamente o que estiver no painel, em vez de trocar rtmp por rtmps na mão.

Há um ganho colateral: no RTMP comum a chave de transmissão viaja em texto claro pela rede do local. RTMPS também protege a chave de transmissão, o que pesa justamente quando a live sai por uma rede que não é sua.

E a ressalva da seção anterior continua valendo: em rede com inspeção de tráfego, a 443 aberta não é promessa. Só a transmissão de teste no local confirma.

Plano B: o 4G/5G que salva o evento, e a conta de dados

O mesmo celular que serviu de prova no diagnóstico é o plano B da transmissão. Para ele funcionar no dia, a conta de dados precisa ser feita antes. É aritmética:

• Bitrate × tempo ÷ 8 = volume de dados.
• A 6 Mbps: 6 × 3.600 s = 21.600 Mb ÷ 8 = 2.700 MB, ou 2,7 GB por hora.
• A 4 Mbps: 4 × 3.600 s ÷ 8 = 1,8 GB por hora.
• Evento de 3 horas a 6 Mbps: 3 × 2,7 = 8,1 GB.

Esses números consideram só o vídeo; some o bitrate do áudio, os testes antes do evento e uma folga. Confira a franquia do chip com essa conta em mãos, e não pelo nome do plano.

O segundo cuidado é o sinal. Auditório, subsolo e sala sem janela mudam tudo: teste o celular no ponto exato onde fica a mesa de transmissão, não no saguão.

O 4G é uma das camadas de reserva, não a única. No episódio, a transmissão é descrita como uma pilha de camadas (energia, internet, computador, mesa de corte, câmera, áudio), cada uma com o seu backup, e o Mário resume o critério: “a redundância a gente tem que ter em tudo aquilo que a gente tem a possibilidade de ter” (09:22).

Vistoria técnica: o checklist do local

Tudo o que este artigo descreve se descobre numa visita, dias antes. Testar em casa confirma o equipamento e não exercita nada do que falha no dia.

1. Leve o mesmo computador e o mesmo encoder que serão usados no evento.
2. Use a internet do local, por cabo, e confirme que o ponto de rede existe e está ativo. “Aqui tem cabo” dito por quem cuida do prédio não é confirmação.
3. Rode o teste de porta e faça uma transmissão de teste de 10 minutos.
4. Descubra quem administra a rede e pegue o contato direto dessa pessoa.
5. Pergunte se existe rede de visitantes ou intranet com regras diferentes da rede principal.
6. Meça o upload no horário do evento, não às oito da manhã com o prédio vazio.
7. Teste o 4G/5G no mesmo ponto.

Um caso contado no episódio, em relato de 2024, mostra por que a vistoria não é excesso de zelo. Numa transmissão em uma sede corporativa no centro de uma capital, a operadora contratada com meses de antecedência não entregou o link de internet: na véspera, não havia conexão. A saída foi comprar um cabo e puxá-lo da central de rede do prédio até o ponto da transmissão. Só deu tempo porque a equipe estava no local antes do evento.

A conclusão do Mário sobre isso serve de regra: “se você faz o teste na sua casa, que não tem restrição nenhuma, você conhece a sua estrutura, acreditando que no evento vai ter a mesma facilidade, a mesma estrutura, você cometeu o primeiro passo pro insucesso do seu evento” (35:46). Por isso a vistoria entra no orçamento do evento, como item de custo, e não como favor.

O que este diagnóstico não resolve

Bloqueio de porta é a causa mais comum de “funciona em casa e não funciona no local”, mas não é a única falha de rede em evento. Vale separar:

• Conectou, mas perde quadros? O diagnóstico é outro, de banda e estabilidade, e passa pelas estatísticas do próprio OBS. O SiteHost tem o passo a passo em como monitorar os quadros perdidos no OBS Studio.
• Quer a lista oficial de checagens do OBS? O guia Stream Connection Troubleshooting, do projeto OBS, cobre trocar de servidor, baixar o bitrate, Família de IP, firewall, VPN, driver de rede e contato com o provedor. Ele não trata de porta nem de rede corporativa (lido em 13/10/2026), que é a lacuna que este artigo preenche.

Perguntas frequentes

Qual porta o OBS usa para transmitir ao vivo?

A porta que está na URL do servidor configurada em Configurações, Transmissão. Endereço que começa com rtmp:// e não traz número usa a 1935/TCP; endereço rtmps:// usa a 443/TCP; se a URL termina em dois-pontos e um número, é aquele número. Não existe uma porta do OBS: quem define é o servidor de destino.

Como saber se o firewall da empresa está bloqueando a transmissão?

Leve o mesmo notebook, com a mesma chave, para o roteamento 4G ou 5G do celular. Se a live sobe pelo celular e falha na rede do local, o bloqueio está na rede. Para provar, rode o teste de porta nas duas redes: Test-NetConnection no Windows ou nc -vz no macOS e no Linux, apontando para o endereço do seu servidor.

O que eu peço para o TI liberar?

Liberação de saída, em TCP, da máquina de transmissão para o domínio do servidor de ingest, na porta que está na URL (1935 para rtmp://, 443 para rtmps://), no período do teste e do evento. Pedir por origem, destino, porta e período é o formato que uma rede com política de segurança consegue aprovar.

Usar a porta 443 resolve o bloqueio?

Resolve quando a plataforma de destino oferece endereço RTMPS. A 443 é a porta do HTTPS e costuma estar aberta para saída em qualquer rede que navega na web. Não é garantia: rede com proxy obrigatório ou inspeção de tráfego pode aceitar a conexão e derrubar a transmissão em seguida.

Posso transmitir o evento pelo 4G ou 5G?

Pode, como reserva ou como link principal, desde que a conta de dados seja feita antes e o sinal seja testado no ponto exato da mesa. A conta é bitrate vezes tempo: 6 Mbps durante uma hora consomem 2,7 GB só de vídeo; um evento de 3 horas, 8,1 GB.

Testei em casa e funcionou. Preciso testar no local do evento?

Precisa. O teste de casa confirma o computador, o encoder e a chave; não exercita nada do que costuma falhar no dia, que é a rede do local: porta fechada, ponto de cabo inexistente, upload insuficiente ou ninguém disponível para liberar o acesso.

Liberar a porta no roteador (port forwarding) resolve?

Não. A transmissão é uma conexão de saída, do encoder para o servidor. Redirecionamento de porta serve para conexões de entrada, quando alguém de fora precisa alcançar um equipamento dentro da rede. O que resolve é a regra de saída no firewall.

Próximos passos

Se o seu evento vai sair de uma rede que você não administra, a ordem é: vistoria, teste de porta em par, pedido ao TI com os quatro campos, endereço RTMPS como alternativa e 4G com a conta feita. Quem transmite a partir de prefeitura, câmara ou autarquia encontra o contexto completo em plataforma de vídeo para órgãos públicos; para os demais eventos, em transmissão ao vivo profissional. E se quiser repassar o seu cenário antes da vistoria, o nosso time atende pela central de contato ou pelo telefone (11) 4063-8923.

O episódio que deu origem a este artigo

O trecho sobre testar no local, rede restrita e vistoria técnica está no episódio Solução all-in-one para seu evento, do Café & Tech Podcast, com Mário Sérgio e Josimar Machado. Assista ao episódio completo no YouTube (59 minutos). Os momentos usados aqui:

• 03:43 — As camadas de uma transmissão ao vivo e o backup de cada uma
• 09:22 — Redundância em tudo o que depende de você
• 27:26 — Testar o evento em casa ou com a estrutura do evento
• 28:13 — Rede restrita, intranet e liberação no local do evento
• 28:54 — Liberar uma porta específica e quem libera no dia
• 35:12 — Vistoria técnica antes do evento

Episódio transmitido ao vivo em 23/10/2024. Condições comerciais, horários e recursos citados são daquela data; valem as informações do artigo acima, conferidas em 13/10/2026.

Transcrição dos trechos do episódio usados neste artigo (revisada a partir da legenda automática)

Os trechos estão na ordem do vídeo, com o minuto de início. O sinal […] marca cortes: falas fora do tema deste artigo e menções a terceiros foram omitidas. O episódio integral está no link acima.

[03:43] A quantidade de camadas que se coloca numa coisa mais complexa, ela fica mais difícil de digerir. […] A mesma coisa é quando a gente vai transmitir um evento. Aqui no evento, o estúdio é nosso; a internet não é nossa, mas tem a redundância, temos duas internets aqui. A energia não tem redundância […]. Então eu tenho uma camada de energia para tudo funcionar e eu tenho ali um backup. Eu tenho uma camada de internet que não está na minha mão, então eu tenho um backup. A gente tem um estúdio que é nosso, a gente tem uma ilha de transmissão que é nossa e tem a ilha de transmissão reserva. A gente tem ali a mesa de corte, mas, numa eventualidade de a mesa de corte dar problema, a gente tem como usar uma câmera só, alguma coisa assim. Então olha para você ver: são as camadas.

[09:16] A redundância que o Josimar citou é um elemento muito importante. Eu costumo dizer, Josimar, que a redundância a gente tem que ter em tudo aquilo que a gente tem a possibilidade de ter. O Josimar falou a questão da energia: energia é um terceiro, ou seja, a energia já não depende de você. Então a questão que depende de você, igual um computador, uma câmera, uma mesa de corte, uma internet, ou seja, é algo que depende de você, você tem a possibilidade de ter redundância para um evento.

[27:16] E outra, dica de ouro, pelo amor de Deus, e é óbvio, mas muita gente não faz: na hora de testar o evento, você vai testar o evento da sua casa ou você vai testar o evento usando a estrutura do evento? Já aconteceu várias vezes de o pessoal estar num lugar cômodo, às vezes até levou a câmera para casa para testar, mas não levou o computador, a ilha, não está com a mesma internet do lugar. Quantas vezes aí falta um cabo, o roteador é ruim, ou às vezes você está no cabo em casa, chega lá no evento: cadê o cabo? É wireless. O dono do local fala: não, aqui tem cabo, sim. O cara nem sabe o que é cabo; muitas vezes o cara é só dono do prédio lá que vai ter o evento. Esses pormenores jogam no mato demais na hora do evento.

[28:06] E muitas das vezes, Josimar, os locais do evento têm uma burocracia tão grande, porque muitas das vezes ali tem restrição de rede, tem restrição de IP. Às vezes a empresa precisa que você transmita o evento dentro de uma intranet, você precisa de liberação. Então são n possibilidades de dar errado quando você não testa direto do local.

[28:26] […] Quando a gente fala desses setores, qualquer setor de governo, prefeitura, existe uma rede ali e alguém cuida dessa rede. E as pessoas bloqueiam tudo […] até por questão de segurança […]. E aí você precisa liberar uma porta específica, porque o streaming, eventualmente, [usa] porta específica, quando o local que você contrata não tem um RTMP nativo na 80, igual a gente tem. A gente tem um RTMP nativo na 80 ou RTMPS, que é seguro, criptografado. Então, por isso, a importância de você, antes do evento, dar um jeito de levar o equipamento, ou pelo menos o mínimo da conexão da transmissão, e fazer um teste in loco, no local do evento.

[29:22] Justamente, porque se você deixar para fazer isso tudo no dia, vai que essa pessoa que libera a porta que você precisa não está no local, está de férias, machucou. Ou às vezes a pessoa lá do evento só abriu o espaço para você; às vezes não tem nem noção de quem cuida dessa parte.

[35:02] Se você não tem [uma pessoa técnica de confiança no local], você vai no evento pessoalmente, no local do evento, para ver as condições de fato, porque só ligando […] não funciona. A famosa vistoria técnica, que você tem que fazer quando você é contratado para fazer um evento, principalmente se for um evento em outra cidade, principalmente se for um evento em um ambiente restrito e um ambiente burocrático. […] Fique atento, que você vai encontrar essas barreiras, e você só consegue eliminar elas se você for fazer a vistoria técnica e falar com as pessoas que realmente ali vão estar responsáveis por fazer aquelas alterações. Porque se você faz o teste na sua casa, que não tem restrição nenhuma, você conhece a sua estrutura, acreditando que no evento vai ter a mesma facilidade, a mesma estrutura, você cometeu o primeiro passo pro insucesso do seu evento, ou do evento do seu parceiro que você foi contratado para fazer. […] Sempre testar antes, e do local.