Надсилання FCM через проксі не маршрутизує з'єднання телефона
Відокремте маршрут Admin API Firebase від постійного мережевого з'єднання FCM пристрою Android, що приймає.
Бекенд може успішно надіслати запит Firebase Cloud Messaging через корпоративний проксі, тоді як пристрій Android так і не отримає сповіщення. Запит Admin API бекенду й з'єднання FCM пристрою — це різні шляхи.
Мережеві настанови Firebase зазначають, що протокол пристрою FCM не можна проксіювати через мережевий проксі. Налаштування HTTP-клієнта на відправнику не перетворює це постійне з'єднання пристрою на запит HTTP-проксі.
Для пристроїв Android задокументовані цільові порти TCP — 5228, 5229, 5230 і 443. FCM зазвичай використовує 5228, інші порти також доступні. Застосуйте відповідну політику в мережі, до якої підключаються пристрої-одержувачі.
Використовуйте опубліковані настанови Firebase щодо імен хостів, коли брандмауер обмежує призначення; вони не радять фіксовані списки дозволених IP, бо адреси можуть змінюватися. Пристроям також потрібен робочий DNS і стабільний шлях для їхнього довготривалого з'єднання.
Якщо відправник зазнає збою під час отримання токена або запиту Admin API, діагностуйте той серверний HTTP-транспорт. Для HTTP-інтерфейсів Firebase Admin Java налаштуйте транспорт API й транспорту облікових даних разом. Якщо надсилання успішне, а доставка не вдалася, збережіть цей результат і дослідіть шлях пристрою, а не замінюйте знову і знову проксі-облікові дані бекенду.