Um AP, gateway ou switch de escritório pequeno que não aparece na plataforma de gestão em nuvem é um dos problemas mais comuns logo no primeiro dia de uma implantação SOHO. Seja um AP, um gateway ou um switch, o caminho de registro é o mesmo — esta é a ordem de verificação que encontra o bloqueio mais rápido, os lugares exatos a verificar, e as causas que respondem pela maioria desses chamados.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Dispositivo diferente, o mesmo handshake de registro — exatamente por isso as mesmas seis verificações continuam resolvendo o problema.
Um AP, gateway ou switch que não se registra na plataforma de gestão em nuvem é um dos problemas mais comuns em uma implantação SOHO recém-iniciada. Os três tipos de dispositivo se registram da mesma forma — ligam, entram em contato com um serviço de registro, são reivindicados por um projeto — então tratar uma falha de integração de AP como algo fundamentalmente diferente de uma falha de switch geralmente é perda de tempo. É mais rápido seguir a mesma lista curta de verificações independentemente do tipo de dispositivo: se o dispositivo sequer está ligado e em configuração de fábrica, se consegue alcançar a internet, se consegue resolver o domínio de registro, se algo a montante está bloqueando as portas que ele precisa, e se já está reivindicado por algum projeto.
A seguir está a árvore de falhas na qual isto se baseia, as verificações de cada etapa com o que procurar, as causas que aparecem repetidamente depois de descartado o óbvio, e algumas respostas de perguntas frequentes tiradas de casos reais de campo.
As falhas de registro se dividem em três formas: o próprio dispositivo não está pronto, o caminho de rede o bloqueia, ou a plataforma em nuvem já o reivindica.
Colocar primeiro o sintoma nesta árvore evita muito retrabalho — ela indica qual das seções abaixo realmente se aplica ao que você está vendo.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
O ramo de prontidão do dispositivo e o ramo do caminho de rede respondem pela grande maioria dos chamados de integração. O ramo de reivindicação de projeto é mais raro, mas o mais confuso quando ocorre, porque todas as outras verificações podem parecer perfeitamente limpas.
Cinco verificações, em ordem — cada uma descarta um ramo inteiro da árvore de falhas ou aponta diretamente para a correção.
Se um AP nem sequer aparece como detectável, não pule ainda para a plataforma em nuvem — confirme primeiro que ele tem energia e terminou de inicializar.
Nada a jusante disso importa se o dispositivo não consegue alcançar a internet — verifique o lado WAN antes de qualquer coisa específica da nuvem.
Um dispositivo que alcança a internet perfeitamente ainda pode falhar ao se registrar se não conseguir resolver o único nome de host de que precisa.
ping register.cloud-onboarding.net
Error: Unknown host register.cloud-onboarding.net.
// no DNS server address was ever handed to this device -- fix DHCP upstream, not the device itself
ping register.cloud-onboarding.net
PING register.cloud-onboarding.net (*.*.*.*): 56 data bytes
Request time out
Request time out
Request time out
Request time out
Request time out
--- register.cloud-onboarding.net ping statistics ---
5 packet(s) transmitted, 0 packet(s) received, 100.00% packet loss
// name resolved fine -- the failure is downstream: reachability or a firewall block, not DNSO DNS resolve e a rede é alcançável, mas o dispositivo ainda nunca aparece — o próximo lugar a verificar é qualquer firewall entre o dispositivo e a internet.
Todas as outras verificações podem sair limpas e o dispositivo ainda não entrará em um novo projeto, porque a plataforma em nuvem acredita que ele já pertence a um.
Depois que as cinco verificações acima indicarem em qual ramo está a falha, essas seis causas explicam a maior parte do que realmente está errado.
SINTOMAO ping para o domínio de registro retorna "Unknown host", e o dispositivo nunca aparece na plataforma em nuvem, não importa quanto tempo você espere.
CAUSAEm uma configuração com gateway de terceiros — onde o dispositivo SOHO não é quem distribui o DHCP — a configuração DHCP do gateway a montante simplesmente não inclui um endereço de servidor DNS em suas respostas. O dispositivo obtém um IP, um gateway padrão, e nada para resolver nomes.
SOLUÇÃOConfigure o servidor DHCP a montante para incluir informações do servidor DNS em suas ofertas, ou aponte o dispositivo diretamente para um servidor DNS funcional, se isso for suportado.
SINTOMAO DNS resolve corretamente, o dispositivo consegue alcançar a internet em geral, mas ainda assim nunca aparece online na plataforma.
CAUSAUm firewall ou dispositivo UTM a montante não permitiu as portas sul específicas que a plataforma em nuvem usa para conversar com os dispositivos — a navegação web geral funciona porque 80/443 estão abertos, mas os canais de registro e gestão usam portas diferentes que nunca foram adicionadas ao conjunto de regras.
SOLUÇÃOAdicione regras de permissão explícitas para a lista de portas sul documentada pelo fornecedor em vez de abrir todo o firewall; confirme que o registro é bem-sucedido depois que as regras estiverem em vigor.
SINTOMATodas as verificações do lado da rede passam, mas o dispositivo ainda não se registra — ou se registra, e imediatamente parece errado na plataforma.
CAUSAO dispositivo foi integrado antes, seja a este mesmo projeto anteriormente ou a uma implantação completamente diferente, e ainda carrega uma configuração local ou vinculação à nuvem daquela vida anterior. Um dispositivo que ficou ligado por cerca de cinco dias ou mais sem ser integrado também atrasa seu próprio intervalo de solicitação de registro, o que parece idêntico a uma tentativa de registro morta.
SOLUÇÃOMantenha o botão de reset pressionado por 6 segundos ou mais (ou redefina pela página web local) para devolver o dispositivo às configurações de fábrica, e reinicie qualquer dispositivo que tenha ficado ocioso por vários dias antes de integrá-lo novamente.
SINTOMAO AP nunca aparece como detectável — não é uma falha de registro, é silêncio completo, e isso é específico de APs.
CAUSAA porta do switch que alimenta o AP não tem PoE habilitado, está configurada com o modo/classe de potência errado para aquele AP, ou a própria porta falhou — e nada disso produz qualquer erro do lado do AP, porque o AP simplesmente nunca inicializa.
SOLUÇÃOVerifique primeiro o indicador link/PoE físico da porta do switch; se estiver apagado, corrija primeiro o PoE na porta do switch — habilite-o, corrija o modo de potência — antes de fazer qualquer outra coisa.
SINTOMAO assistente de integração sinaliza que o dispositivo já foi adicionado em outro lugar, e o registro é bloqueado diretamente em vez de apenas lento.
CAUSAO mesmo dispositivo — identificado pelo número de série — foi anteriormente integrado a um projeto diferente na plataforma em nuvem, um resultado comum ao reimplantar equipamentos entre sites ou clientes, e a plataforma não permite que dois projetos reivindiquem o mesmo hardware ao mesmo tempo.
SOLUÇÃOUse a migração integrada do assistente se o dispositivo ainda conseguir voltar a ficar online em seu projeto original — reinicie, aguarde o estado de piscar lento, migre em cerca de uma hora; caso contrário, remova-o primeiro do projeto antigo e redefina-o de fábrica.
SINTOMANada relacionado à nuvem sequer é tentado, porque o gateway não tem alcançabilidade à internet desde o início.
CAUSAUm WAN configurado com PPPoE atrás de um ONT que ainda está em modo roteador em vez de modo bridge, um WAN configurado com DHCP apontando para um pool de endereços esgotado ou em conflito, ou um IP estático que colide com outro dispositivo na rede — qualquer um desses impede o gateway antes mesmo de o registro ser possível.
SOLUÇÃOConfirme o modo bridge no ONT para PPPoE, verifique a saúde e o endereçamento do pool DHCP do provedor para DHCP, e verifique conflitos de IP para atribuições estáticas.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Leia com atenção a mensagem exata. Um "Unknown host" imediato (ou equivalente "não foi possível resolver") significa que o dispositivo nunca obteve um endereço de servidor DNS funcional — o pacote nunca saiu com um IP de destino real por trás. Um resultado que mostra o IP resolvido e depois expira solicitação por solicitação significa que o DNS funcionou bem e o problema real está a jusante — alcançabilidade ou bloqueio de firewall. Trate-os como duas soluções completamente diferentes.
Geralmente não. Um AP que oscila depois de já ter se registrado com sucesso é mais frequentemente uma configuração incorreta do DHCP Snooping no switch ao qual está conectado — especificamente, a porta de uplink em direção ao gateway não estar configurada como interface confiável de DHCP Snooping. Confirme que toda porta que carrega tráfego DHCP legítimo a montante está marcada como confiável, não apenas as portas voltadas para dispositivos finais.
A descoberta de topologia depende do LLDP. Um dispositivo de terceiros no caminho, ou uma porta compatível com LLDP que foi desabilitada manualmente, quebra a capacidade da plataforma de construir uma imagem precisa. Se não houver equipamento de terceiros no caminho e o LLDP estiver habilitado em todos os lugares, uma atualização manual da topologia geralmente corrige uma visão desatualizada; se um dispositivo de terceiros não conseguir repassar o LLDP, a topologia permanece incompleta e a configuração por dispositivo precisa ser feita manualmente.
Os dois caminhos de gestão são isolados um do outro. Qualquer coisa que você altere localmente não será sincronizada de volta para a plataforma em nuvem, e a plataforma não tem visibilidade disso, então uma alteração local pode divergir silenciosamente do que a plataforma em nuvem acredita estar configurado. Trate a página web local como somente leitura assim que o dispositivo estiver sob gestão em nuvem, a menos que esteja deliberadamente contornando um recurso que a plataforma não expõe.
Geralmente apenas para visibilidade, não para gestão completa. Um controlador tipicamente aparece para fins de visão geral na plataforma em nuvem e no aplicativo complementar, mas a configuração do dia a dia ainda precisa acontecer localmente no próprio controlador — trate a visibilidade na nuvem como um extra, não um substituto da administração local.
Um dispositivo que está ligado mas nunca foi integrado aumenta gradualmente o intervalo entre suas próprias tentativas de solicitação de registro, especificamente para evitar sobrecarregar desnecessariamente o serviço de registro. Depois de vários dias ocioso, esse intervalo pode ficar longo o suficiente para parecer que o dispositivo simplesmente desistiu. Reinicie-o e comece a integração novamente prontamente — a reinicialização redefine o intervalo.
Esta nota se baseia em um modelo de registro de AP/gateway/switch de escritório pequeno gerenciado em nuvem — o serviço de registro sul do fornecedor, o console de gestão em nuvem e o aplicativo complementar — além dos casos de campo por trás dele. Se sua ferramenta de integração for de outro fornecedor, os menus exatos e as listas de portas mudam, mas a ordem de verificação subjacente — prontidão do dispositivo, alcançabilidade WAN, resolução de DNS, permissão de firewall, conflitos de reivindicação de projeto — se aplica diretamente. Não cobre a integração empresarial baseada em um controlador de rede dedicado, que segue um fluxo diferente, nem a integração de overlay SD-WAN. Se você ainda está terminando o cabeamento inicial e a configuração local, comece com Small Office Network from Scratch antes de solucionar o registro na nuvem.
Conte-nos em qual verificação está falhando — prontidão do dispositivo, alcançabilidade WAN, DNS, firewall ou reivindicação de projeto — e ajudamos você a interpretar.