Push-уведомления Android не работают через VPN? Проверьте это

Уведомления перестают приходить на телефон, который в остальном нормально работает в интернете через корпоративный VPN. Веб-страницы загружаются, приложение открывается, а сообщения появляются только дома или после отключения туннеля. В приложении на Firebase Cloud Messaging канал push — это отдельное долгоживущее исходящее соединение, а не тот путь HTTPS, который только что подтвердил браузер. Пройдите эти проверки по порядку и остановитесь на первой неудачной.

Убедитесь, что приложение действительно использует FCM

Не каждое уведомление является push. Часть из них планируется локально в приложении, часть запрашивается по HTTPS, а часть приходит через канал поставщика, не связанный с Firebase. Если манифест и зависимости приложения включают Firebase Messaging, его уведомления обычно идут через соединение FCM, а клиентская библиотека записывает регистрацию под предсказуемым тегом.

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

Токен регистрации в журнале подтверждает транспорт. Без него вы отлаживаете конвейер уведомлений на уровне приложения, и изменения межсетевого экрана не помогут. Это различие важно, потому что доставленное, но никогда не показанное сообщение и сообщение, которое не приходит вовсе, для пользователя выглядят одинаково.

Проверяйте исходящие порты, а не веб-сайт

Соединения устройств с FCM — это TCP, инициируемые устройством, на порт 5228, с 5229 и 5230 как резервными и 443 как последним средством. Межсетевой экран, разрешающий 443 для просмотра, всё равно может ломать push, а правило, разрешающее домен API приложения, не охватывает конечные точки обмена сообщениями, которые являются отдельными службами.

Это исходящие соединения с телефона. Вы не публикуете входящий порт ни на устройстве, ни на VPN-шлюзе, поэтому если кто-то предлагает проброс портов, проект уже неверен. То же касается правила, открывающего один порт всем адресам в интернете: ограничьте его документированными назначениями.

Сетевое руководство Firebase также утверждает, что протокол доставки FCM нельзя передать через обычный прокси HTTP. Поэтому работа браузера через корпоративный веб-прокси ничего не доказывает насчёт push-сокета: это два разных клиента с разными маршрутами.

Проверьте тайм-ауты простоя, которые убивают сокет

Соединение FCM остаётся открытым между сообщениями, что делает его чувствительным к тайм-аутам NAT и проверки с сохранением состояния. Руководство Firebase просит не менее 30 минут терпимости к простою там, где действуют такие политики. Пятиминутный тайм-аут сеанса молча удаляет сопоставление, и телефон переподключается только когда что-то его будит, поэтому сообщения приходят пачками или не приходят вовсе.

Прочитайте таблицу сеансов на межсетевом экране или VPN-шлюзе и найдите соединение телефона с 5228-5230. Сравните оставшееся время жизни с документированным значением. Если оно меньше, увеличьте тайм-аут для этих портов, вместо того чтобы менять все политики на устройстве, потому что глобальное изменение тайм-аута трудно обосновать и ещё труднее отменить.

Доставка push также зависит от того, переживёт ли сопоставление конечной точки роуминг между Wi-Fi и сотовой сетью. Сопоставление, привязанное к одному интерфейсу, может быть отброшено при передаче даже тогда, когда обе сети разрешают эти порты.

Решите, допустим ли обход VPN

Клиенты VPN в Android могут разрешать трафику обходить туннель, и FCM может использовать сеть под ним, когда такой обход разрешён. В этом случае канал push остаётся зашифрованным, но больше не несёт адрес туннеля, поэтому маскировка IP через VPN на него не распространяется. Это компромисс политики, а не неисправность.

Если ваша политика запрещает обход, путь туннеля должен нести соединение: порты открыты, тайм-ауты достаточно длинные, прокси не мешает. Не исключайте молча управляемую службу и не ослабляйте блокировку только потому, что уведомления работают в неуправляемой сети. Значок VPN не показывает, какой маршрут выбрала конкретная служба

Отделите доставку от отображения, затем проверьте один раз

Разрешение, настройки канала, «Не беспокоить» и переключатели для каждого приложения решают, будет ли показано доставленное сообщение. В Android 13 и новее разрешение на уведомления выдаётся во время выполнения, и отказ создаёт тишину, которая выглядит точно как заблокированный порт. Сообщение, которое пришло, но не отобразилось, — это проблема отображения; рассматривайте её отдельно.

Проведите один контролируемый тест вместо случайной отправки сообщений. Держите устройство, учётную запись и приложение неизменными, отправьте одно сообщение с известной меткой времени и сравните состояние с VPN и в одобренной сети без VPN. Запишите время получения в logcat и время отображения для каждого запуска. Если доставка различается, а отображение нет, переменной является сетевой путь; если оба совпадают, продолжайте смотреть на приложение.

Передайте владельцу сети порты, ограничение прокси, измеренный тайм-аут и решение об обходе одной заметкой. «Выключи VPN» — не вывод, а разрешение всего трафика Google — не точечное исправление.