Por que é que a sua nuvem privada funciona com Wi-Fi mas falha com dados móveis?

Uma nuvem privada pode funcionar perfeitamente no Wi-Fi de casa e ainda assim falhar nos dados móveis. Isso normalmente não significa que a aplicação da nuvem privada está avariada. Significa que o seu telemóvel está a usar um caminho de rede diferente.

Em casa, o telemóvel pode aceder a um endereço IP local, um nome local do host, ou um serviço de descoberta apenas para LAN. Em dados móveis, o telemóvel deve aceder à sua nuvem privada através de um domínio público, IP público, VPN, túnel, ou outro caminho de acesso remoto. Se o DNS, roteamento, certificados, domínios confiáveis, regras do firewall, ou comportamento do operador estiverem errados, o Wi-Fi funciona enquanto os dados móveis falham.

Wi-Fi e Dados Móveis Acedem à Sua Nuvem Privada de Formas Diferentes

O sintoma é familiar: a sua aplicação de nuvem privada funciona no Wi-Fi de casa, o backup de fotos corre normalmente, a sincronização de ficheiros conecta-se, e a interface web abre no seu telemóvel. Depois muda para 5G ou LTE e vê timeout, não consegue conectar, falha no login, erro de certificado, ou uma aplicação que fica a carregar.

No Wi-Fi, o seu telemóvel e a nuvem privada estão dentro da mesma LAN. A ligação pode usar um endereço local como 192.168.1.50, um nome local do host, ou descoberta automática. Em dados móveis, o seu telemóvel está na rede do operador. Deve aceder ao seu servidor doméstico através de um caminho remoto, não pela mesma rota local.

O sucesso no Wi-Fi apenas prova que o caminho local funciona. A falha nos dados móveis significa que o caminho externo está em falta, bloqueado, mal configurado ou incompatível com a rede móvel. A resolução de problemas deve separar o acesso interno do acesso externo em vez de os tratar como uma única ligação.

A Aplicação Pode Estar a Usar um Endereço Local Que Só Funciona em Casa

A causa mais comum é também a mais simples. A aplicação da nuvem privada pode estar guardada com um URL como http://192.168.1.50:8080, https://cloud.local, https://nas.local, ou um nome de dispositivo atribuído pelo router. Esses endereços podem funcionar em casa e falhar em qualquer outro lugar.

Intervalos privados IPv4 como 10.x.x.x, 172.16–31.x.x e 192.168.x.x destinam-se a redes privadas. Um endereço privado apenas local não é um destino público na internet, por isso o seu telemóvel não pode aceder diretamente a ele enquanto estiver em dados móveis.

Se a aplicação móvel estiver a usar um URL apenas para LAN, não comece por alterar configurações aleatórias do firewall. Primeiro decida se o acesso móvel deve usar um domínio público, uma VPN ou mesh VPN, ou um túnel. Sem um desses caminhos, o telemóvel está a tentar aceder a um endereço que só existe dentro da sua casa.

URL Interna e URL Externa São Frequentemente Confundidas

Muitas configurações de nuvem privada acabam com duas identidades. A URL interna funciona em casa, como http://192.168.1.50:8080. A URL externa deve funcionar a partir do exterior, como https://cloud.example.com ou um nome de host de túnel.

Esses dois nomes podem apontar para o mesmo serviço, mas não são o mesmo design de acesso. A URL interna pode usar um IP privado, DNS local ou um certificado autoassinado. A URL externa pode requerer DNS público, HTTPS, um proxy reverso, encaminhamento de portas, roteamento VPN ou um túnel.

Os problemas surgem quando favoritos, aplicações móveis, clientes de sincronização e atalhos de navegador misturam estas identidades. Para dados móveis, use a URL externa se o serviço for para ser acessível a partir do exterior. Se quiser manter tudo privado, conecte-se primeiro via VPN e depois use o endereço da LAN.

O DNS Pode Resolver Corretamente no Wi-Fi mas Falhar na Rede Móvel

Um domínio pode funcionar em casa e falhar em dados móveis porque o telefone está a perguntar a um sistema DNS diferente. Em casa, o seu router, Pi-hole, AdGuard Home ou servidor DNS local pode resolver cloud.example.com para um IP interno. Em dados móveis, o DNS da operadora ou o DNS público pode devolver uma resposta diferente ou nenhuma resposta.

Isto é comum em configurações de DNS dividido. Dentro da LAN, o domínio aponta para o endereço privado para velocidade e simplicidade. Fora da LAN, deve apontar para um IP público, nome acessível por VPN ou ponto final de túnel. Se o registo externo estiver em falta ou desatualizado, o telefone não consegue encontrar o serviço.

Não presuma que um domínio está correto só porque funciona em Wi-Fi. Teste o mesmo domínio em dados móveis e confirme onde ele resolve. Se os resultados DNS internos e externos forem intencionalmente diferentes, documente esse design para que as configurações da aplicação não usem acidentalmente o nome errado.

Domínios Confiáveis, URLs Base e Proxies Reversos Podem Rejeitar o Acesso Móvel

Por vezes, o pedido móvel chega ao servidor, mas a aplicação ainda falha. Pode surgir um aviso de domínio não confiável, erro de host inválido, falha de login, ciclo de redirecionamento ou problema de sincronização WebDAV. Isso geralmente significa que o caminho chegou à nuvem privada, mas a aplicação não confia no nome ou nos cabeçalhos do proxy que recebeu.

O software de nuvem privada frequentemente necessita de configurações explícitas de nome de host e URL. A referência de configuração do Nextcloud inclui configurações de domínio confiável e URL base, e a sua documentação de proxy reverso cobre detecção de URL de proxy reverso quando a deteção automática de nome de host, protocolo ou raiz web falha.

Se os dados móveis carregam a página de login mas o login, redirecionamentos, sincronização ou links de partilha falham, verifique a configuração da aplicação. O nome do host externo deve ser confiável, a URL pública deve corresponder ao que os utilizadores inserem, os cabeçalhos do proxy devem estar corretos e os redirecionamentos HTTP-para-HTTPS não devem enviar a aplicação de volta para um endereço LAN privado.

Os Certificados HTTPS Muitas Vezes Revelam o Design de Acesso Errado

O acesso Wi-Fi pode funcionar com um certificado autoassinado, um nome de host interno ou um aviso do navegador que aceitou manualmente há meses. As aplicações móveis podem ser mais rigorosas, especialmente ao sincronizar ficheiros, fotos, calendários ou dados WebDAV em segundo plano.

Os certificados HTTPS estão ligados a nomes. Se a aplicação ligar a 192.168.1.50, cloud.local, ou um nome de host diferente do certificado, os clientes móveis podem rejeitar a ligação. Se um proxy reverso alterar incorretamente o nome do host ou protocolo, a aplicação também pode falhar após o login.

Uma configuração externa limpa usa um domínio público estável com um certificado válido e uma configuração de proxy reverso correspondente. Uma configuração privada limpa usa VPN ou mesh VPN primeiro, depois acesso interno. Misturar endereços IP, nomes locais, nomes públicos e certificados incompatíveis é o que torna o acesso móvel pouco fiável.

Encaminhamento de Porta, VPN ou Túnel Devem Fornecer o Caminho Móvel

Uma nuvem privada não se torna automaticamente acessível a partir de dados móveis só porque funciona em Wi-Fi. O tráfego externo precisa de um caminho intencional para a rede doméstica ou para o ponto final do serviço.

Existem três padrões comuns. O encaminhamento de porta envia tráfego público específico através do router para a nuvem privada. Uma VPN ou mesh VPN permite que o telemóvel se junte primeiro a uma rede privada. Um túnel reverso permite que o servidor crie uma ligação de saída para um ponto final público, depois os dispositivos móveis ligam-se através desse ponto final.

Para acesso a nuvem privada pessoal, VPN ou mesh VPN é geralmente a primeira escolha mais segura. Para partilhar um serviço diretamente com outros, um domínio público com HTTPS, proxy reverso e controlo de acesso cuidadoso pode ser apropriado. Para CGNAT ou routers bloqueados, um túnel pode ser mais prático do que encaminhamento de porta.

O CGNAT Pode Fazer o Encaminhamento de Portas Parecer Correto mas Ainda Falhar

O CGNAT é frustrante porque a configuração doméstica pode parecer correta. A nuvem privada funciona em Wi-Fi. O firewall do servidor permite a porta. O router tem uma regra de encaminhamento. Mas os dados móveis ainda não conseguem alcançar o serviço.

O problema é que o seu router pode não ter um endereço IPv4 público real. O RFC 6598 reserva 100.64.0.0/10 como espaço de endereços partilhado usado para CGNAT. Quando o seu ISP coloca o seu router atrás de um NAT de nível operador, o tráfego externo pode nunca chegar ao seu router doméstico, por isso a sua regra de encaminhamento de portas não tem nada para encaminhar.

Compare o IP WAN mostrado no seu router com o IP público mostrado por um site externo de verificação de IP. Se não coincidirem, ou se o endereço WAN estiver em intervalos partilhados ou privados, o encaminhamento de portas clássico provavelmente não é a solução correta. Use uma opção de IP público do ISP, uma VPN em malha ou um túnel reverso em vez disso.

As Redes Móveis Podem Acrescentar Problemas Específicos de IPv6 e do Operador

Alguns problemas aparecem apenas em dados móveis. A mesma nuvem privada pode funcionar numa outra rede Wi-Fi, mas falhar em 5G ou LTE. Ou um operador funciona enquanto outro não. Isso aponta para além do router doméstico.

As redes móveis podem usar designs só com IPv6, NAT64, CGNAT, DNS do operador, políticas APN, filtragem ou comportamento de proxy. A orientação da Apple sobre compatibilidade de rede móvel só com IPv6 lembra que as redes móveis podem não se comportar como uma LAN doméstica dual-stack normal, especialmente se uma aplicação ou servidor assumir comportamento só com IPv4.

Se os dados móveis forem o único caminho que falha, teste mais do que uma perspetiva. Experimente o mesmo URL num navegador móvel, teste outro operador ou hotspot, verifique os registos DNS A e AAAA, confirme se o servidor suporta a família de endereços utilizada e experimente uma VPN sobre dados móveis. Se a VPN funcionar, provavelmente a nuvem privada está bem; o problema está no caminho público móvel.

As Aplicações Móveis Podem Comportar-se de Forma Diferente dos Navegadores

Um navegador de telemóvel e uma aplicação móvel nem sempre se comportam da mesma forma. O navegador pode abrir a página de login, enquanto a aplicação falha na sincronização. Ou a aplicação pode funcionar em Wi-Fi porque descobre o servidor localmente, mas falhar em dados móveis porque a descoberta já não está disponível.

As aplicações móveis podem armazenar em cache um URL antigo do servidor, exigir HTTPS, rejeitar incompatibilidades de certificados, usar um endpoint WebDAV ou API diferente da página do navegador, restringir dados em segundo plano ou seguir redirecionamentos de forma diferente. Algumas aplicações também armazenam endereços internos e externos separados sem o tornar óbvio.

Teste sempre ambos os caminhos. Abra o URL externo no navegador do telefone enquanto estiver em dados móveis, depois teste a aplicação. Se o navegador também falhar, o problema é provavelmente DNS, encaminhamento, TLS, CGNAT ou configuração do túnel. Se o navegador funcionar mas a aplicação falhar, concentre-se nas definições do URL da aplicação, domínios confiáveis, certificados, caminhos WebDAV/API e cache da aplicação.

VPN ou Mesh VPN Frequentemente Resolve o Problema Restaurando o Caminho LAN

Se a cloud privada funciona em Wi-Fi mas não em dados móveis, uma VPN pode ser uma solução limpa porque altera a posição do telefone. Em vez de aceder à cloud privada como um cliente externo aleatório, o telefone junta-se primeiro a uma rede privada.

Ferramentas Mesh VPN podem usar caminhos diretos ou de retransmissão dependendo das redes envolvidas. O Tailscale documenta acesso privado através de ligações diretas ou retransmitidas, o que é contexto útil quando um dispositivo móvel precisa de alcançar um servidor doméstico sem expor a cloud privada diretamente à internet.

Para acesso pessoal, este é geralmente o modelo menos confuso. A aplicação pode usar o endereço LAN interno ou um nome DNS privado após a ligação VPN estar estabelecida. A cloud privada mantém-se fora da internet aberta, e o dispositivo móvel autentica-se antes de aceder aos serviços internos.

Túneis Reversos Ajudam Quando Precisa de um URL Externo Sem Abrir Portas

Um túnel reverso é útil quando não pode ou não quer abrir portas de entrada no seu router. Isto é comum com CGNAT, routers ISP bloqueados, internet de apartamentos ou utilizadores que preferem não expor diretamente o router doméstico.

O Cloudflare Tunnel utiliza um túnel de saída para acesso remoto, onde o conector dentro da sua rede inicia a ligação para fora. Os dispositivos móveis acedem então a um nome de host público que encaminha de volta através do túnel.

Isto pode facilitar o acesso a dados móveis, mas deve ser configurado cuidadosamente. Utilize políticas de acesso, HTTPS, exposição limitada de serviços e separe as interfaces de administração dos serviços públicos para utilizadores. Um túnel resolve a acessibilidade; não resolve automaticamente permissões ou configuração da aplicação.

Uma Ordem Prática para Resolução de Problemas

Este problema torna-se complicado quando o DNS, regras do router, certificados, definições da aplicação e redes móveis são todos alterados ao mesmo tempo. Uma abordagem melhor é testar uma camada de cada vez.

Comece por anotar a URL exata que funciona no Wi-Fi. Decida se é um IP privado, nome local ou domínio público. Depois desligue o Wi-Fi e teste a mesma URL nos dados móveis. Em seguida, teste o domínio público pretendido, verifique o DNS público, compare o IP WAN do router com o IP público, confirme se está a usar encaminhamento de portas, VPN ou túnel, depois verifique o certificado TLS e as definições de domínio confiável.

O resultado normalmente indica a camada. Se o navegador e a aplicação falharem, concentre-se no DNS, caminho público, CGNAT, certificado ou túnel. Se o navegador funcionar mas a aplicação falhar, concentre-se na configuração da aplicação, domínios confiáveis, pontos finais WebDAV/API, redirecionamentos e URLs em cache do servidor. Se a VPN sobre dados móveis funcionar, a nuvem privada está saudável; o problema está no caminho externo.

O Padrão Mais Seguro é Um Único Método Claro de Acesso Remoto

O acesso à nuvem privada torna-se pouco fiável quando existem demasiadas entradas a funcionar parcialmente: um IP LAN, um nome local, um nome DDNS, uma URL de túnel, uma URL antiga da aplicação, um nome de host de proxy reverso e um marcador que ninguém se lembra de ter criado.

Escolha um padrão principal. Para acesso pessoal, local apenas mais VPN é frequentemente a opção mais limpa. Para acesso direto à aplicação a partir do exterior, use um domínio público, HTTPS válido, definições corretas de domínio confiável e um proxy reverso seguro ou túnel. Para CGNAT, use um túnel ou VPN em malha em vez de lutar contra o encaminhamento de portas.

Quanto menos pontos de entrada mantiver, mais fácil será a configuração do telefone. Uma nuvem privada não deve precisar de uma URL misteriosa diferente para cada rede. A nomeação estável, certificados correspondentes e um método de acesso claro são o que fazem o Wi-Fi e os dados móveis comportarem-se de forma consistente.

Conclusão Final

Se a sua nuvem privada funciona no Wi-Fi mas falha em dados móveis, a nuvem privada em si pode estar bem. O Wi-Fi usa um caminho local. Dados móveis precisam de um caminho remoto. A falha é geralmente causada por um URL só local, incompatibilidade DNS, falta de encaminhamento de portas, VPN ou túnel, CGNAT, incompatibilidade de certificado TLS, configuração de domínio confiável, comportamento IPv6/IPv4 ou diferenças na app móvel.

Comece por verificar que URL a app usa, se esse URL é local ou público, se o DNS público resolve, se o router tem um IP público real e se HTTPS e domínios confiáveis correspondem ao nome externo. Para acesso pessoal, VPN ou mesh VPN é geralmente a solução mais limpa. Para acesso externo direto, use um domínio público consistente, certificado válido e caminho cuidadosamente seguro.

Um NAS de nuvem privada fiável pode alojar ficheiros, fotos, sincronização, backups e serviços de acesso remoto, mas o acesso por dados móveis depende do caminho da rede, domínio, certificado e configuração da app.

FAQ

Por que a minha nuvem privada funciona no Wi-Fi mas não em dados móveis?

O Wi-Fi usa a sua rede local, onde endereços IP privados e nomes locais podem funcionar. Dados móveis usam a rede do operador, por isso precisam de um domínio público, VPN, túnel ou outro caminho externo.

Posso usar 192.168.x.x em dados móveis?

Não. Um 192.168.x.x o endereço é privado e só funciona dentro da sua rede local. Para usar com dados móveis, conecte-se primeiro à sua rede doméstica via VPN ou mesh VPN.

Por que o meu domínio funciona em casa mas não no celular?

O seu Wi-Fi doméstico pode usar DNS local que aponta o domínio para um IP privado. No celular, o telefone usa DNS público ou do operador, que pode não ter o mesmo registo ou apontar para o endpoint errado.

Por que o navegador funciona mas a app móvel falha?

A app pode usar uma API ou caminho WebDAV diferente, guardar em cache um URL antigo, exigir um domínio confiável, rejeitar um certificado ou tratar redirecionamentos de forma diferente do navegador.

O CGNAT afeta o acesso à nuvem privada a partir de dados móveis?

Sim. Se o seu ISP doméstico usar CGNAT, o encaminhamento de portas pode nunca chegar ao seu router. Nesse caso, use uma opção de IP público, VPN/mesh VPN ou um túnel reverso.

O IPv6 pode causar problemas de acesso em dados móveis?

Pode ser. Algumas redes móveis usam apenas IPv6 ou preferem IPv6. Se o seu domínio, app ou servidor doméstico for só IPv4 ou tiver registos DNS incorretos, os dados móveis podem comportar-se de forma diferente do Wi-Fi.

VPN é melhor do que abrir portas para uma nuvem privada?

Para acesso pessoal, geralmente sim. VPN ou mesh VPN mantém a nuvem privada fora da internet aberta e permite que dispositivos confiáveis acedam como se estivessem na LAN doméstica.

O que devo verificar primeiro?

Verifique o URL guardado na app. Se for um IP local ou .local hostname, não funcionará em dados móveis a menos que utilize VPN. Depois verifique DNS público, CGNAT, HTTPS, domínios confiáveis e configurações da app.