Notificações push do Android não funcionam com VPN? Verifique isto

As notificações param de chegar num telefone que, de resto, navega bem pela VPN corporativa. As páginas web carregam, o aplicativo abre e as mensagens só aparecem em casa ou depois de desligar o túnel. Num aplicativo baseado no Firebase Cloud Messaging, o canal push é uma conexão de saída separada e de longa duração, não o caminho HTTPS que o navegador acabou de comprovar. Percorra estas verificações em ordem e pare na primeira que falhar.

Confirme que o aplicativo realmente usa FCM

Nem toda notificação é push. Algumas são agendadas localmente pelo aplicativo, outras são consultadas via HTTPS e outras chegam por um canal do fornecedor que nada tem a ver com o Firebase. Se o manifesto e as dependências do aplicativo incluírem o Firebase Messaging, as notificações normalmente trafegam pela conexão FCM, e a biblioteca cliente registra o registro sob uma tag previsível.

adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebase

Um token de registro no log confirma o transporte. Sem ele, você está depurando um pipeline de notificações no nível do aplicativo, e mudanças no firewall não vão ajudar. Essa distinção importa porque uma mensagem entregue mas nunca exibida e uma mensagem que nunca chega parecem iguais para o usuário.

Verifique as portas de saída, não o site

As conexões dos dispositivos ao FCM são TCP originadas pelo dispositivo para a porta 5228, com 5229 e 5230 como alternativas e 443 como último recurso. Um firewall que permite a 443 para navegação ainda pode quebrar o push, e uma regra que permite o domínio de API de um aplicativo não cobre os endpoints de mensagens, que são serviços separados.

São conexões de saída do telefone. Você não publica uma porta de entrada no dispositivo nem no gateway VPN, então se alguém sugerir um redirecionamento de porta, o projeto já está errado. O mesmo vale para uma regra que abre uma porta para todos os endereços da internet: limite-a aos destinos documentados.

As orientações de rede do Firebase também afirma que o protocolo de entrega do FCM não pode ser transportado por um proxy HTTP comum. Portanto, o navegador funcionar pelo proxy web corporativo não prova nada sobre o socket push: são dois clientes diferentes com caminhos diferentes.

Verifique os tempos limite de inatividade que matam o socket

A conexão do FCM permanece aberta entre as mensagens, o que a torna sensível aos tempos limite de NAT e de inspeção com estado. As orientações do Firebase pedem pelo menos 30 minutos de tolerância à inatividade onde essas políticas se aplicam. Um tempo limite de sessão de cinco minutos remove o mapeamento em silêncio, e o telefone só se reconecta quando algo o desperta, então as mensagens chegam em rajadas ou não chegam.

Leia a tabela de sessões no firewall ou no gateway VPN e encontre a conexão do telefone para 5228-5230. Compare o tempo de vida restante com o valor documentado. Se for menor, aumente o tempo limite para essas portas em vez de mudar todas as políticas do dispositivo, porque uma mudança global de tempo limite é difícil de justificar e mais difícil ainda de desfazer.

A entrega push também depende de o mapeamento do endpoint sobreviver a um roaming entre Wi-Fi e rede móvel. Um mapeamento vinculado a uma interface pode ser descartado na transferência mesmo quando ambas as redes permitem as portas.

Decida se o bypass da VPN é aceitável

Os clientes VPN do Android podem permitir que o tráfego contorne o túnel, e o FCM pode usar a rede subjacente quando esse bypass é permitido. Nesse caso o canal push continua criptografado, mas não carrega mais o endereço do túnel, então o mascaramento de IP da VPN não se aplica a ele. É uma troca de política, não um defeito.

Se a sua política proíbe o bypass, o caminho do túnel tem de carregar a conexão: portas abertas, tempos limite longos o bastante, proxy fora do caminho. Não exclua silenciosamente um serviço gerenciado nem relaxe o bloqueio só porque as notificações funcionam numa rede não gerenciada. O ícone da VPN não diz qual caminho um determinado serviço escolheu

Separe a entrega da exibição e teste uma vez

Permissão, configurações de canal, Não perturbe e chaves por aplicativo decidem se uma mensagem entregue é exibida. No Android 13 e posteriores a permissão de notificação é concedida em tempo de execução, e uma concessão negada gera um silêncio que parece exatamente uma porta bloqueada. Uma mensagem que chegou mas não foi exibida é um problema de apresentação; trate-a separadamente.

Faça um teste controlado em vez de enviar mensagens ao acaso. Mantenha o dispositivo, a conta e o aplicativo fixos, envie uma única mensagem com um carimbo de data e hora conhecido e compare a condição com VPN com uma rede sem VPN aprovada. Registre o horário de recebimento no logcat e o horário de exibição em cada execução. Se a entrega diferir mas a exibição não, o caminho de rede é a variável; se ambos forem idênticos, continue olhando o aplicativo.

Entregue ao responsável de rede as portas, a limitação do proxy, o tempo limite medido e a decisão sobre o bypass numa única nota. «Desligue a VPN» não é um achado, e permitir todo o tráfego do Google não é uma correção delimitada.