Você conecta no Wi-Fi de um restaurante. O celular mostra “conectado”, mas nada abre. Segundos depois, surge uma tela pedindo e-mail, telefone ou um simples aceite de termos. Só aí a internet libera de verdade.
Essa barreira entre conectar e navegar é o captive portal. E entender como funciona um captive portal muda a forma como você enxerga o Wi-Fi do seu estabelecimento: não como custo operacional, mas como ponto de captura de dados reais sobre quem frequenta o seu espaço.
Veja mais vídeos como esse em nosso canal do YouTube!
O que é um captive portal (e o que ele não é)
Captive portal é o sistema que mantém o acesso à internet restrito até o visitante cumprir uma condição: aceitar termos, preencher um cadastro, usar um voucher ou apresentar credenciais. A arquitetura definida pelo IETF no RFC 8952 separa três componentes: o mecanismo que aplica a restrição na rede, a API que informa o estado do acesso e a interface que o usuário vê.
Aqui entra uma confusão comum. A tela de login (splash page) é só a interface. Quem efetivamente bloqueia e libera o tráfego é o equipamento de controle da rede: roteador, firewall ou controlador. Instalar um formulário bonito sem integrar a autorização no equipamento não cria um portal funcional. Cria uma página decorativa.
Na prática, captive portals aparecem em hotéis, aeroportos, academias, restaurantes, hospitais, shoppings e redes públicas. A finalidade muda (marketing, segurança, conformidade legal, inclusão digital), mas a mecânica é a mesma: conectar não é navegar. A navegação só começa quando o portal autoriza.
E essa mecânica tem mais engrenagens do que parece à primeira vista.
Da conexão ao acesso: as 6 etapas do captive portal
O caminho entre “selecionar a rede Wi-Fi” e “abrir o Google” passa por seis etapas distintas. Pular uma delas, ou configurar errado, é exatamente o que causa aquele cenário frustrante de “conectado, sem internet”.
- O dispositivo se associa ao ponto de acesso (AP). Existe enlace de rádio, mas zero permissão de tráfego externo.
- Via DHCP, o dispositivo recebe endereço IP, gateway e DNS. É nessa etapa que o portal pode ser anunciado: o padrão RFC 8910 define a opção DHCPv4 114, que informa ao dispositivo a URL da API do portal.
- O equipamento de controle (firewall, roteador, controlador) restringe o tráfego, permitindo apenas o mínimo para completar o login: resolução DNS, o servidor do portal e os recursos do chamado “walled garden”.
- O sistema operacional do celular ou notebook faz uma sondagem (requisição HTTP a um endereço conhecido) e, ao detectar a restrição, apresenta a tela de login. No iPhone, aparece aquela janela flutuante. No Android mais recente, o navegador pode ser acionado via Custom Tabs.
- O visitante aceita os termos, informa os dados solicitados, digita o voucher ou faz login social. Essa ação é enviada ao servidor de autenticação.
- O equipamento de controle libera o tráfego conforme a política da sessão (tempo, banda, destinos permitidos). A internet funciona.
Um detalhe que faz diferença na escolha de solução: o portal pode estar hospedado fora do equipamento de rede. No fluxo externo documentado pela Meraki, o cliente é redirecionado a um servidor separado, as credenciais seguem em POST e, após a validação, ocorre novo redirecionamento. Isso explica por que hospedar a página e controlar o acesso são funções separadas. Uma pode funcionar enquanto a outra falha.
Falhar, aliás, é mais comum do que deveria. A próxima pergunta que todo gestor de rede faz: por que a página de login não aparece?
Por que a página de login não aparece (e como resolver)
Se existe uma reclamação universal sobre Wi-Fi de visitantes, é essa: “conectei, mas não apareceu nada”. O problema quase nunca é o portal em si. É a descoberta dele.
HTTPS e o fim da interceptação
No modelo legado, o portal funcionava interceptando uma requisição HTTP e devolvendo a splash page no lugar. Com a adoção massiva de HTTPS, isso deixou de funcionar para a maioria dos sites. Não há como redirecionar uma conexão cifrada sem gerar alerta de certificado inválido no navegador.
A solução moderna é a sondagem automática. Tanto iOS quanto Android fazem requisições periódicas a URLs específicas (connectivitycheck.gstatic.com no Android, captive.apple.com no iOS). Quando a resposta não é a esperada, o dispositivo entende que há um portal e abre a tela de login.
Quando essa sondagem falha, o visitante fica preso no “conectado, sem internet”. A documentação de troubleshooting do pfSense lista as causas mais frequentes: DNS bloqueado antes do login, regras de firewall impedindo a sondagem e dependências externas da splash page fora do walled garden.
Walled garden mal configurado
O walled garden é a lista de recursos acessíveis antes da autenticação. Se a splash page está em servidor externo e carrega fontes do Google, scripts de CDN ou imagens de outro domínio, todos esses endereços precisam estar liberados. Um portal visualmente correto pode travar porque o navegador não consegue carregar um único arquivo CSS.
MAC privado e reconhecimento de retorno
Desde iOS 14, a Apple ativa por padrão endereços MAC privados (rotativos) para redes com proteção mais fraca, incluindo captive portals. O Android segue caminho semelhante. O dispositivo pode se apresentar com um endereço diferente a cada conexão.
Para o gestor, a consequência é direta: reconhecimento de visitantes recorrentes baseado apenas em MAC se tornou não confiável. O portal precisa de outro identificador (e-mail, telefone, login social) para construir uma base de contatos real.
Checklist quando o portal não aparece
- DNS está acessível antes da autenticação?
- O servidor da splash page e todas as suas dependências (CDN, fontes, scripts) estão no walled garden?
- O certificado HTTPS do portal é válido e confiável?
- O dispositivo está reconectando do zero (opção “esquecer rede”)?
No iPhone, acessar os detalhes da rede Wi-Fi e tocar “Entrar na Rede” força a abertura da splash page. No Android 12+ com módulo atualizado em janeiro de 2026, o fluxo via Custom Tabs já traz autofill e compatibilidade com VPN e DNS privado.
Resolver a descoberta é condição mínima. Mas mesmo quando o portal funciona sem falhas, muitos gestores confundem o que ele faz com o que ele não faz.
Portal, senha do Wi-Fi e criptografia: três problemas diferentes
“Meu Wi-Fi tem captive portal, então está seguro.” Não necessariamente. Portal, senha e criptografia resolvem problemas distintos, e nenhum substitui o outro.
| Abordagem | O que resolve | O que não resolve |
|---|---|---|
| Senha compartilhada (WPA2/WPA3) | Controla quem entra na rede | Não identifica individualmente; quem tem a senha, acessa |
| Captive portal | Exige condição antes de liberar acesso (cadastro, aceite, voucher) | Não cifra o enlace Wi-Fi por si só |
| Enhanced Open (OWE) | Cifra o tráfego individualmente, mesmo sem senha | Não autentica o usuário; qualquer um se conecta |
| Passpoint (Hotspot 2.0) | Seleção automática e ingresso com credenciais verificáveis | Depende de provisionamento prévio e suporte do dispositivo |
Na maioria dos estabelecimentos comerciais, a combinação mais comum é rede aberta (ou com senha única) + captive portal. Funciona para capturar dados, mas deixa o tráfego sem criptografia individual. Se a segurança da comunicação importa (clínicas, escritórios, hotelaria corporativa), é necessário adicionar criptografia ao enlace, não apenas confiar na tela de login.
E por falar em confiança: a legislação brasileira define limites claros sobre o que o portal pode (e não pode) exigir.
O que a lei brasileira exige do seu portal cativo
Dois marcos regulatórios afetam diretamente qualquer captive portal operando no Brasil. A conformidade começa desde a fase de planejamento, e implementar a infraestrutura corretamente evita refações caras mais adiante.
LGPD: finalidade, necessidade e consentimento real
A Lei 13.709/2018 (LGPD) exige que toda coleta de dados tenha finalidade específica e colete apenas o necessário. Um portal que pede nome, CPF, e-mail, telefone, data de nascimento e gênero para liberar 30 minutos de Wi-Fi tem um problema de adequação: qual a necessidade de cada campo para a finalidade declarada?
Autorizações genéricas do tipo “aceito todos os termos e condições” são juridicamente frágeis. O consentimento precisa ser informado, livre e revogável por procedimento gratuito. Quando o controlador invoca legítimo interesse no lugar do consentimento, a ANPD exige teste de balanceamento documentado.
Marco Civil: registro de conexão, não de navegação
O Marco Civil da Internet (Lei 12.965/2014) determina que o administrador do sistema autônomo guarde registros de conexão por um ano. Registros de acesso a aplicações seguem regra diferente e, na provisão de conexão, o artigo 14 veda essa guarda.
Na prática: o portal pode (e deve) registrar quem se conectou, quando e por quanto tempo. Registrar o histórico de navegação do visitante não é autorização do Marco Civil para quem provê o acesso.
Separar acesso de marketing
Tratar o aceite dos termos de uso (conformidade) separadamente do opt-in de comunicações promocionais (marketing) é mais do que boa prática. Misturar os dois numa única caixa enfraquece o consentimento e frustra quem só quer internet.
O portal falso como ameaça concreta
Em novembro de 2025, a Australian Federal Police divulgou a condenação de um indivíduo que operava redes Wi-Fi falsas (evil twin) com páginas de login idênticas às legítimas para roubar credenciais. A pena: sete anos e quatro meses por múltiplos crimes.
Para o gestor, a lição é dupla. Um portal com identidade visual clara, HTTPS válido e comunicação transparente sobre os dados coletados ajuda a diferenciar seu Wi-Fi de uma armadilha. E quanto menos dados desnecessários o portal pedir, menor a superfície de risco se algo der errado.
Quando a conformidade e a segurança estão resolvidas, o captive portal pode fazer algo muito mais valioso do que proteger a rede: gerar receita.
Quando o captive portal vira canal de captura de leads
O captive portal tem uma vantagem que nenhum outro canal de marketing digital oferece: o visitante já está no seu espaço físico, já quer algo de você (a internet) e está disposto a interagir. A conversão acontece no momento de maior atenção.
O que funciona na prática
Em um caso público, o McDonald’s Bélgica usou a página pós-login para promover seu aplicativo, com links diretos para as lojas Apple e Google. O resultado foi aumento expressivo nos downloads. O material não divulga percentual, mas o aprendizado é claro: o momento pós-login é canal de distribuição, não fim da interação.
A Ahold Delhaize, rede varejista europeia, foi além. Combinando infraestrutura Cisco com OpenRoaming e Salesforce, conectou 3,6 milhões de dispositivos únicos em menos de um ano e reduziu a necessidade de formulário repetido, mantendo a integração com CRM. A relação comercial continuou mesmo quando o ingresso deixou de exigir preenchimento manual.
O que não funciona
- Formulários com 6+ campos para liberar 15 minutos de internet. O visitante preenche com dados falsos ou desiste.
- Pedir CPF sem justificativa visível. Gera desconfiança imediata.
- Login social como única opção. Nem todo mundo quer vincular Facebook ao Wi-Fi do restaurante.
- Página pesada que depende de recursos externos (irônico, considerando que o visitante está sem internet funcional naquele momento).
- Nenhum benefício em troca dos dados. “Preencha para ter Wi-Fi” é coerção velada. “Preencha e ganhe 10% no próximo pedido” é troca justa.
- Usar a infraestrutura para bloquear alternativas de conectividade dos visitantes, como hotspots pessoais. A FCC aplicou acordo de US$ 600 mil contra a Marriott por essa prática em 2014.
Um dado de contexto: a TIC Domicílios 2025 mostra que 99% dos usuários brasileiros acessam a internet pelo celular e 65% usam exclusivamente esse dispositivo. Além disso, 39% relatam esgotamento do pacote de dados nos três meses anteriores à pesquisa. O portal que não é leve, rápido e otimizado para tela pequena ignora o comportamento real do público que mais precisa de Wi-Fi.
Do portal à conversa: o ciclo que fecha a conta
O captive portal captura o dado. Mas dado parado em planilha não gera receita. O ciclo fecha quando o contato capturado vira comunicação ativa: follow-up, oferta personalizada, pesquisa de satisfação, convite de retorno. Entender como estruturar essa transformação do Wi-Fi em canal comercial faz diferença mensurável no ROI da infraestrutura.
É o que acontece quando o Wi-Fi alimenta automaticamente um canal de WhatsApp. O visitante conecta, informa o telefone, e a partir daí recebe comunicações relevantes sem depender de e-mail (que a maioria ignora) ou de app próprio (que quase ninguém baixa).
Se o seu estabelecimento ainda trata o Wi-Fi como commodity de internet, vale entender como o Wi-Fi Marketing transforma cada conexão em captura de cliente. E se a dúvida é como fechar o ciclo entre captura e conversão, o WhatsApp Empresarial integrado à base de Wi-Fi é onde isso acontece na prática.
Perguntas frequentes
Captive portal e splash page são a mesma coisa?
Não. O captive portal é o sistema completo que restringe e libera o acesso à internet. A splash page é apenas a interface visual (a tela de login) que o visitante vê. É possível ter splash page sem controle real de acesso, e controle de acesso sem splash page customizada. São camadas diferentes.
Por que meu Wi-Fi mostra “conectado, sem internet”?
Porque o dispositivo completou a associação ao ponto de acesso, mas o captive portal ainda não autorizou o tráfego externo. Procure a notificação de login automática, toque nos detalhes da rede Wi-Fi no celular ou abra manualmente um site HTTP para forçar o redirecionamento à splash page.
É obrigatório pedir CPF ou e-mail no portal?
Não. Portais podem funcionar com simples aceite de termos ou voucher. Se há coleta de dados pessoais, a LGPD exige finalidade específica e coleta mínima. Pedir CPF para liberar Wi-Fi é difícil de justificar como “necessário” para essa finalidade, salvo quando há obrigação regulatória específica.
O captive portal funciona com VPN e DNS privado?
Depende. A integração Android com Custom Tabs (módulo de 2026) prevê compatibilidade com VPN e Private DNS. Em portais legados ou equipamentos com suporte limitado, VPN e DNS privado podem impedir a descoberta do portal. Desativar temporariamente costuma resolver, mas não é solução ideal para o visitante.
O estabelecimento consegue ver tudo que eu acesso?
Captive portal não dá acesso irrestrito ao histórico de navegação. O sistema pode registrar dados de sessão (IP, horário, duração). No Brasil, o artigo 14 do Marco Civil veda guardar registros de acesso a aplicações na provisão de conexão. Sites com HTTPS, que são a maioria absoluta, cifram o conteúdo acessado.
Existe captive portal gratuito?
Sim. O pfSense inclui a funcionalidade no firewall, e algumas plataformas oferecem planos gratuitos com recursos básicos. Custo total zero não existe: infraestrutura, configuração e manutenção continuam presentes. Captura de leads, integração com CRM e automação de marketing geralmente exigem plataforma especializada.
