No lobby de um hotel, 200 hóspedes conectam ao Wi-Fi ao mesmo tempo. No shopping, 3.000 dispositivos disputam banda entre lojas, praça de alimentação e estacionamento. No estádio, 40.000 celulares tentam postar o gol nos stories. Em todos esses cenários, a diferença entre “funciona” e “trava tudo” mora na arquitetura de sistemas para hotspot.
Se você é analista de redes, consultor de TI ou dono de provedor, entender essa arquitetura de ponta a ponta (do cabo físico até o dashboard de gestão) é o que separa um deploy profissional de uma gambiarra com roteador doméstico. Este guia cobre as sete camadas do sistema, as topologias de deployment, os vetores de ataque que a arquitetura precisa neutralizar e o que acontece com os dados depois que o cliente conecta.
Veja mais vídeos como esse em nosso canal do YouTube!
O que compõe a arquitetura de sistemas para hotspot (e por que roteador doméstico não conta)
Um hotspot profissional não é um roteador com senha compartilhada. É um ecossistema de hardware e software que resolve, ao mesmo tempo, cinco problemas distintos: conectividade, autenticação, segurança, conformidade legal e inteligência de dados.
A definição clássica de hotspot é direta: um ponto de acesso físico onde pessoas obtêm conexão à internet via Wi-Fi. Mas entre “ponto de acesso” e “sistema funcional em produção” existe uma distância enorme. Um roteador doméstico entrega conectividade. Só. Não identifica quem está na rede, não segmenta tráfego por perfil de usuário, não guarda logs exigidos pelo Marco Civil da Internet e não captura um único dado para o gestor do estabelecimento.
A arquitetura de sistemas para hotspot combina sete camadas funcionais que, juntas, sustentam desde o backhaul de internet até a experiência do usuário final e a monetização dos dados capturados. Pense nelas como engrenagens: se uma falha, o sistema inteiro perde eficiência.
E é justamente nessas sete camadas que mora o 80% do trabalho que o mercado ignora.
As 7 camadas de um sistema hotspot profissional
Desmembrar a arquitetura em camadas ajuda a dimensionar, orçar e diagnosticar problemas. Cada camada tem função específica, fornecedores próprios e pontos de falha previsíveis.
1. Backhaul e roteamento de borda
É a porta de entrada da internet. O link chega via fibra, enlace dedicado, satélite ou FWA 5G e termina em um gateway de borda. Esse gateway aplica NAT, distribui endereços via DHCP e impõe as primeiras regras de firewall. Em deploys maiores, o backhaul é redundante (dois links de operadoras diferentes), com failover automático.
2. Access Points (APs)
Os APs emitem o SSID, gerenciam canais de rádio, controlam potência e coordenam o roaming entre pontos. Em ambientes profissionais, APs de vendors como Cisco, Aruba, Ruckus, Ubiquiti e Cambium operam nos padrões 802.11ac, ax (Wi-Fi 6/6E) e, cada vez mais, 802.11be (Wi-Fi 7). A escolha do AP define a capacidade simultânea, a cobertura por unidade e o custo por metro quadrado.
3. WLAN Controller (WLC)
O controlador de rede sem fio gerencia centralizadamente dezenas a milhares de APs: configuração, firmware, alocação de canal, balanceamento de carga e políticas de QoS. Sem WLC, cada AP é uma ilha. Com WLC, a rede inteira se comporta como uma coisa só.
4. Gateway Hotspot / Sistema de gerenciamento
Aqui mora o cérebro operacional. O gateway hotspot executa o captive portal, aplica controle de banda, gera vouchers e impõe políticas de uso. Plataformas cloud-native modernas escalam de 10 a mais de 10.000 APs em uma única tenancy, sustentando milhões de sessões concorrentes com SLA de 99,9%.
5. Servidor AAA (Authentication, Authorization, Accounting)
RADIUS é o protocolo padrão. O servidor AAA responde três perguntas sobre cada usuário: quem é (autenticação), o que pode fazer (autorização) e o que fez (contabilização). Essa é a camada que viabiliza tanto o login social do captive portal quanto a autenticação 802.1x de ambientes corporativos.
6. Captive portal
A página web exibida ao usuário antes de liberar o acesso. Captura credenciais (e-mail, celular, login social), exibe termos de uso, pode mostrar anúncio ou pesquisa e dispara o opt-in de marketing. É a interface visível de toda a engrenagem que o usuário vivencia.
7. Plataforma de gestão e analytics
Dashboards em cloud (Cisco Meraki, Aruba Central, Ruckus Cloud, ExtremeCloud IQ, entre outros) oferecem telemetria em tempo real, gestão multi-tenant e integrações via REST APIs. É nessa camada que o analista de rede vê quantos dispositivos estão conectados, qual o consumo de banda por SSID e onde estão os gargalos.
A maioria dos artigos sobre o tema para por aqui. Mas saber quais são as camadas é metade do trabalho. A outra metade é entender como a camada 6 (captive portal) conversa com todas as outras por dentro.
Por dentro do captive portal: como o redirecionamento acontece
O captive portal é a peça da arquitetura que o usuário final vê. Mas o que acontece entre “conectar ao SSID” e “ver a tela de login” envolve lógica de rede que vale dominar, porque erros aqui geram reclamações imediatas (“o Wi-Fi não funciona”).
Existem três mecanismos principais de redirecionamento:
HTTP 302 Redirect. O gateway intercepta requisições HTTP e responde com um código 302, apontando o navegador para a URL do portal. Funciona bem com HTTP, mas não consegue redirecionar tráfego HTTPS sem disparar alertas de certificado no navegador.
DNS hijacking. O gateway responde a qualquer consulta DNS com o IP do portal, usando TTL=0 para evitar envenenamento de cache. Tecnicamente, é um man-in-the-middle legítimo. Eficiente, mas depende de o dispositivo não usar DNS over HTTPS (DoH).
Captive Portal API via DHCP/NDP. O método mais moderno. O gateway usa opções DHCP (ou mensagens IPv6 NDP) para sinalizar ao sistema operacional que existe um portal. iOS, Android, Windows e macOS detectam nativamente e exibem a tela de login sem precisar abrir o navegador. É o caminho que reduz fricção e funciona com HTTPS.
O ponto de atenção: sites HTTPS (que são a maioria absoluta em 2026) não podem ser redirecionados pelo método HTTP 302 sem gerar erro de certificado. Esse é o principal motivo pelo qual usuários relatam “internet que não conecta” em redes com captive portal mal configurado. Se a sua arquitetura depende exclusivamente de HTTP 302, o portal vai falhar para a maioria dos acessos.
Entendido o fluxo de conexão, a próxima decisão de projeto é: onde cada componente roda? Na rede local, na nuvem ou em combinação dos dois?
Topologias de deployment: on-premise, cloud ou híbrida
A escolha da topologia impacta latência de autenticação, custo operacional, residência de dados e capacidade de escalar. Não existe resposta universal. O que existe é a topologia certa para o cenário.
| Topologia | Onde roda o AAA/portal | Caso de uso típico | Prós | Contras |
|---|---|---|---|---|
| On-premise local | Gateway + RADIUS dentro da rede local | Empresas com data center próprio, setores regulados (saúde, finanças) | Latência mínima na autenticação, controle total dos dados | Custo de manutenção de hardware, escalabilidade limitada |
| Cloud-managed | Controller e portal em cloud pública, APs locais | Redes multi-site, franquias, provedores regionais | Escala elástica, gestão centralizada, menor CAPEX | Depende de link estável, latência variável por região |
| Híbrida | RADIUS on-premise + portal em cloud | Hospitais, universidades, hotelaria de grande porte | Residência de dados sensíveis local, portal flexível | Complexidade de integração, dois ambientes para monitorar |
Fonte: classificação baseada em práticas consolidadas de arquitetura Wi-Fi corporativa.
Para provedores de internet que atendem dezenas de clientes comerciais, a topologia cloud-managed é quase obrigatória. Gerenciar centenas de APs espalhados por cidades diferentes sem uma plataforma centralizada em nuvem é receita para incêndio operacional.
Já hospitais e clínicas tendem à topologia híbrida. A razão é prática: dados de pacientes (que podem transitar pela mesma infraestrutura de rede) precisam ficar em ambiente controlado, enquanto o portal de visitantes pode rodar em cloud sem problema.
Um ponto que poucos deploys consideram na fase de projeto: resiliência offline. O que acontece quando o link de internet cai? Se o RADIUS e o portal estão inteiramente na nuvem, nenhum novo usuário consegue se autenticar. Arquiteturas mais resilientes mantêm cache local de sessões ativas e um RADIUS secundário on-premise para garantir continuidade.
Com a topologia definida, a próxima preocupação é inevitável: segurança. E os números recentes não são reconfortantes.
Segurança na arquitetura: evil twin, spoofing e o que a lei exige
Hotspots públicos são, por design, redes abertas a desconhecidos. Essa abertura cria superfície de ataque. Ignorar esse fato no projeto da arquitetura é construir um hospital sem controle de infecção.
Os vetores de ataque mais comuns
Evil twin. O atacante posiciona um AP falso com o mesmo SSID da rede legítima. O equipamento necessário custa menos de USD 500 e pode ser escondido atrás de displays em cafeterias ou lobbies de aeroporto. Dispositivos dos usuários conectam automaticamente ao sinal mais forte, que é o do atacante.
MAC spoofing. O atacante clona o endereço MAC de um dispositivo já autenticado para burlar o captive portal e acessar a rede sem login.
DNS tunneling. Tráfego encapsulado via consultas DNS escapa do portal antes da autenticação, permitindo acesso não autorizado à internet.
Firewalls incompletos. Portas de saída deixadas abertas no gateway permitem que clientes não autenticados contornem o captive portal por protocolos não-HTTP.
O cenário real em hotelaria (onde os dados são piores)
31% das organizações de hospitalidade já reportaram violação de dados, e em 2020 hotéis representaram 13% de todos os comprometimentos cibernéticos globais. Em 2019, nenhum hotel passou em teste de hacking de Wi-Fi, em 45 locais e cinco países. A causa raiz, na maioria dos casos, é arquitetura de rede flat (sem segmentação) e ausência de autenticação forte.
Mitigações que a arquitetura precisa prever
- Segmentação de VLAN por perfil de usuário (visitante, funcionário, IoT, administrativo)
- Certificados digitais nos APs para evitar evil twin (Passpoint faz isso nativamente)
- EAP-TLS para autenticação mútua em ambientes corporativos
- Firewall stateful com política de deny-all por padrão, liberando apenas as portas necessárias por VLAN
- Monitoramento de APs rogues em tempo real via WLC
LGPD e Marco Civil: camada regulatória obrigatória
No Brasil, o Marco Civil da Internet exige guarda de logs de conexão. A LGPD exige base legal, transparência e consentimento explícito para qualquer coleta de dados pessoais via captive portal. Isso significa que o fluxo de cadastro, opt-in, retenção e exclusão de dados precisa estar embutido na arquitetura desde a fase de design, não remendado depois.
A arquitetura resolve a conexão e a segurança. Mas se o sistema para aí, o estabelecimento tem Wi-Fi seguro e zero inteligência sobre quem usa. E é exatamente no “depois da conexão” que mora o retorno financeiro.
O que acontece depois que o cliente conecta
Para o usuário, a jornada termina quando o navegador abre. Para o negócio, ela começa ali.
O captive portal captura, no momento do login, dados como nome, e-mail, telefone celular e perfil de rede social. Esses dados alimentam uma base de contatos que, em arquiteturas bem projetadas, flui automaticamente para sistemas de automação de marketing, CRM e canais de comunicação direta.
Esse é o princípio do Wi-Fi marketing: o hotspot deixa de ser um custo de infraestrutura e vira um canal de captura de clientes. Cada pessoa que conecta é um lead identificado, com dados de frequência de visita, tempo de permanência e, dependendo da integração, histórico de compras. A automação completa desse processo permite acionar campanhas em tempo real com base no comportamento de conexão.
O pipeline de dados na prática
- Captura no portal: o cliente faz login via celular, e-mail ou rede social. O sistema registra o dado com opt-in e base legal (LGPD).
- Enriquecimento: a plataforma cruza o dado com visitas anteriores, horários de conexão e dispositivo utilizado.
- Segmentação: visitantes frequentes, novos, inativos há X dias. Cada segmento recebe tratamento diferente.
- Ativação: campanhas automáticas por e-mail, SMS ou WhatsApp. O lead capturado no Wi-Fi vira conversa no WhatsApp Empresarial em minutos, sem intervenção humana.
- Mensuração: ROI por campanha, taxa de retorno de clientes, incremento de ticket médio.
A maioria dos artigos sobre arquitetura de hotspot ignora completamente essa camada de pós-conexão. Trata o sistema como se a missão fosse “dar internet”. Mas para o gestor de um restaurante, academia ou hotel, a internet é commodity. O valor está no dado que a conexão gera. E o dado só gera valor se a arquitetura contempla o pipeline inteiro, do AP ao dashboard de marketing.
Para quem opera em múltiplos setores ou múltiplas unidades, a plataforma de gestão precisa ser multi-tenant. Redes de franquias, por exemplo, precisam de visão consolidada (todas as unidades) e segmentada (cada franqueado vê só a sua base) na mesma interface.
Enquanto o captive portal domina o cenário atual de autenticação, a próxima onda tecnológica já está em rollout. E ela muda a lógica de como a arquitetura lida com identidade.
Passpoint, OpenRoaming e Wi-Fi 7: o que muda na arquitetura
O captive portal tem um problema estrutural: ele depende de redirecionamento web, gera fricção e não funciona bem com HTTPS. A indústria respondeu com uma sequência de padrões que prometem eliminar esse gargalo, incluindo abordagens de single sign-on Wi-Fi que dispensam a tela de login.
Hotspot 2.0 / Passpoint
Baseado no IEEE 802.11u, o Hotspot 2.0 permite que o dispositivo do usuário obtenha informações da rede (via protocolo ANQP) antes de se associar. A autenticação usa 802.1x com EAP, entregando conexão automática, criptografada via WPA2/WPA3-Enterprise, em menos de um segundo. Nada de tela de login.
OpenRoaming: federação global
OpenRoaming é a camada de federação construída sobre Passpoint, gerenciada pela Wireless Broadband Alliance (WBA). Ela conecta Identity Providers (operadoras, Google, Apple) com Access Network Providers (aeroportos, hotéis, shoppings). O usuário configurado uma vez nunca mais precisa fazer login em redes participantes.
Os números de adoção são expressivos: 81% dos executivos do setor Wi-Fi planejam implantar OpenRoaming em 2025 ou 2026, um aumento de 18,9% sobre 2024. Dos comprometidos, 25% já estão em rollout, 42% planejam para 2025 e 27% para 2026.
O caso mais emblemático no Brasil: em 2021, o Aeroporto de Guarulhos (GRU) tornou-se sede da primeira rede OpenRoaming pública sobre Wi-Fi 6 em um aeroporto, em parceria entre Boingo, Broadcom, Cisco e Samsung.
Wi-Fi 7 e alta densidade
O mercado de Wi-Fi 7 deve saltar de USD 2,76 bilhões em 2025 para USD 4,56 bilhões em 2026, com CAGR de 65,4%. Para a arquitetura de hotspot, Wi-Fi 7 traz:
- MLO (Multi-Link Operation): o AP agrega múltiplas bandas simultaneamente, dobrando ou triplicando a capacidade por dispositivo
- Canais de 320 MHz e 4K-QAM: throughput agregado acima de 10 Gbps por AP
- Latência sub-10 ms: viabiliza aplicações de realidade aumentada e telemetria industrial em hotspots
Wi-Fi 7 não substitui a lógica de autenticação (Passpoint/OpenRoaming). Ele complementa. O futuro combina hardware Wi-Fi 7 com federação OpenRoaming, eliminando fricção do captive portal mesmo em redes de altíssima densidade como estádios e hubs de transporte.
O que isso significa na prática para quem projeta hoje
Se você está desenhando uma arquitetura de hotspot em 2026, projete para suportar Passpoint na camada de autenticação, mesmo que o deploy inicial use captive portal. A migração será incremental: o captive portal continua dominante em varejo, bares e clínicas (pela simplicidade e pelo valor de marketing). Mas ambientes enterprise, educacionais e de transporte vão migrar para federação automática nos próximos dois anos.
O captive portal não vai morrer. Ele vai se especializar. E para PDVs que dependem de captura de dados, ele segue sendo a melhor porta de entrada para construir base de clientes.
Para quem quer operar (não só projetar)
Se o seu negócio é revender soluções de Wi-Fi para estabelecimentos comerciais, a arquitetura que sustenta o hotspot precisa ser white label. O revendedor configura, personaliza o portal com a marca do cliente e gerencia tudo em uma plataforma multi-tenant. Provedores de internet, empresas de TI e agências de marketing digital encontram nesse modelo uma fonte de receita recorrente mensal escalável, sem precisar desenvolver software próprio.
Perguntas frequentes
Qual a diferença entre hotspot e Wi-Fi?
Wi-Fi é a tecnologia de rede sem fio (IEEE 802.11). Hotspot é o caso de uso: um ponto de acesso público ou semipúblico onde pessoas se conectam à internet via Wi-Fi. Todo hotspot usa Wi-Fi, mas nem todo Wi-Fi é um hotspot.
Quais são os componentes obrigatórios de uma arquitetura de hotspot?
Sete camadas: backhaul (link de internet + gateway de borda), access points, WLAN Controller, gateway hotspot com captive portal, servidor AAA (RADIUS), o próprio captive portal e plataforma de gestão/analytics. A ausência de qualquer uma compromete segurança, conformidade legal ou capacidade de escala.
O captive portal é obrigatório?
No Brasil, sim, na prática. O Marco Civil da Internet exige identificação de usuários e guarda de logs de conexão. O captive portal é a forma mais direta de cumprir essa exigência, além de viabilizar o opt-in exigido pela LGPD para coleta de dados pessoais.
Passpoint e OpenRoaming substituem o captive portal?
Em ambientes de transporte, enterprise e educação, sim. O Passpoint elimina a tela de login e entrega conexão automática criptografada. Mas em varejo, alimentação e serviços, o captive portal segue dominante porque funciona como canal de captura de dados e Wi-Fi marketing.
Qual topologia escolher: on-premise, cloud ou híbrida?
Depende do cenário. Cloud-managed é ideal para multi-site e franquias (escala e gestão centralizada). On-premise atende setores regulados com requisitos de residência de dados. Híbrida combina os dois para operações que precisam de RADIUS local e portal flexível em nuvem.
Como a arquitetura de hotspot se conecta a Wi-Fi marketing?
O captive portal captura dados do usuário (e-mail, telefone, login social) no momento da conexão. Esses dados alimentam automações de marketing, CRM e canais como WhatsApp. A arquitetura precisa contemplar esse pipeline desde o projeto, integrando a camada de autenticação com plataformas de ativação e mensuração de ROI.
