Envoyer FCM via un proxy ne route pas la connexion du téléphone
Séparez la route Admin API de Firebase de la connexion réseau FCM persistante de l'appareil Android destinataire.
Un backend peut envoyer avec succès une requête Firebase Cloud Messaging via un proxy d'entreprise alors qu'un appareil Android ne reçoit jamais la notification. La requête Admin API du backend et la connexion FCM de l'appareil sont deux chemins distincts.
Les recommandations réseau de Firebase indiquent que le protocole d'appareil de FCM ne peut pas être proxifié via un proxy réseau. Configurer un client HTTP côté émetteur ne transforme pas cette connexion persistante de l'appareil en requête de proxy HTTP.
Pour les appareils Android, les ports TCP de destination documentés sont 5228, 5229, 5230 et 443. FCM utilise normalement 5228, les autres ports étant également disponibles. Appliquez la politique appropriée sur le réseau auquel se connectent les appareils destinataires.
Utilisez les recommandations publiées de Firebase sur les noms d'hôte lorsqu'un pare-feu restreint les destinations ; elles déconseillent les listes d'autorisation IP fixes, car les adresses peuvent changer. Les appareils ont aussi besoin d'un DNS fonctionnel et d'un chemin stable pour leur connexion de longue durée.
Si l'émetteur échoue lors de l'obtention du jeton ou d'une requête Admin API, diagnostiquez ce transport HTTP côté serveur. Pour les interfaces HTTP de Firebase Admin Java, configurez ensemble les transports de l'API et des identifiants. Si l'envoi réussit mais que la livraison échoue, conservez ce résultat et examinez le chemin de l'appareil plutôt que de remplacer à répétition les identifiants de proxy du backend.