Android 푸시 알림이 VPN에서 작동하지 않나요? 이것을 확인하세요
FCM은 5228-5230 포트에서 자체 아웃바운드 연결을 유지합니다. 알림 설정을 건드리기 전에 프록시 규칙, NAT 타임아웃, VPN 우회를 확인하세요.
다른 것은 기업 VPN을 통해 잘 탐색하는 휴대폰에서 알림이 도착하지 않는다. 웹 페이지는 열리고 앱도 열리지만, 메시지는 집에 있을 때나 터널을 끈 뒤에만 나타난다. Firebase Cloud Messaging으로 만든 앱에서 푸시 채널은 별도의 장기 아웃바운드 연결이며, 브라우저가 방금 입증한 HTTPS 경로가 아니다. 다음 점검을 순서대로 진행하고 처음 실패하는 항목에서 멈춘다.
앱이 실제로 FCM을 쓰는지 확인한다
모든 알림이 푸시는 아니다. 앱이 기기에서 직접 예약하는 것도 있고, 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을 허용하는 방화벽도 푸시를 깨뜨릴 수 있고, 앱의 API 도메인을 허용하는 규칙은 별도 서비스인 메시징 엔드포인트를 포함하지 않는다.
이들은 휴대폰에서 나가는 아웃바운드 연결이다. 기기나 VPN 게이트웨이에 인바운드 포트를 공개하지 않으므로, 누군가 포트 포워딩을 제안한다면 설계가 이미 잘못된 것이다. 하나의 포트를 인터넷의 모든 주소에 여는 규칙도 마찬가지이므로, 문서화된 대상으로 범위를 좁혀야 한다.
| Port | Role | What to verify |
|---|---|---|
| 5228 | Primary FCM connection | Outbound allowed and session state kept |
| 5229, 5230 | Fallback ports | Often missing from hand-written allowlists |
| 443 | Last-resort fallback | Works only if the client actually falls back |
| HTTP proxy | Not a supported FCM transport | Proxy exclusion or bypass, not a port rule |
Firebase의 네트워크 지침도 FCM 전달 프로토콜은 일반 HTTP 프록시로 전달할 수 없다고 밝힌다. 따라서 브라우저가 기업 웹 프록시를 통해 동작한다는 사실은 푸시 소켓에 대해 아무것도 증명하지 않는다. 둘은 경로가 다른 별개의 클라이언트다.
소켓을 끊는 유휴 타임아웃을 확인한다
FCM 연결은 메시지 사이에도 열려 있어 NAT와 상태 기반 검사의 타임아웃에 민감하다. Firebase 지침은 그러한 정책이 적용되는 곳에서 최소 30분의 유휴 허용을 요구한다. 오 분의 세션 타임아웃은 매핑을 조용히 제거하고, 휴대폰은 무언가 깨울 때만 다시 연결되므로 메시지가 한꺼번에 오거나 전혀 오지 않는다.
방화벽이나 VPN 게이트웨이의 세션 테이블을 읽고 휴대폰의 5228-5230 연결을 찾는다. 남은 수명을 문서화된 값과 비교한다. 더 짧으면 기기의 모든 정책을 바꾸는 대신 해당 포트의 타임아웃을 늘린다. 전역 타임아웃 변경은 정당화하기 어렵고 되돌리기는 더 어렵다.
푸시 전달은 Wi-Fi와 셀룰러 사이를 이동할 때 엔드포인트 매핑이 살아남는지에도 달려 있다. 하나의 인터페이스에 묶인 매핑은 두 네트워크가 모두 포트를 허용해도 핸드오버에서 삭제될 수 있다.
VPN 우회를 허용할지 결정한다
Android VPN 클라이언트는 트래픽이 터널을 우회하도록 허용할 수 있고, 그 우회가 허용되면 FCM이 하위 네트워크를 사용할 수 있다. 이 경우 푸시 채널은 암호화된 상태로 남지만 더는 터널의 주소를 싣지 않으므로 VPN의 IP 마스킹이 적용되지 않는다. 이는 정책상의 절충이며 고장이 아니다.
정책이 우회를 금지한다면 터널 경로가 연결을 실어야 한다. 포트를 열고, 타임아웃을 충분히 길게 하고, 프록시가 방해하지 않게 한다. 관리되는 서비스를 조용히 제외하거나, 관리되지 않는 네트워크에서 알림이 동작한다는 이유만으로 잠금을 느슨하게 하지 않는다. VPN 아이콘은 특정 서비스가 어떤 경로를 선택했는지 알려주지 않습니다
전달과 표시를 분리하고, 한 번만 시험한다
권한, 채널 설정, 방해 금지, 앱별 토글이 전달된 메시지를 표시할지 결정한다. Android 13 이상에서 알림 권한은 런타임 부여이며, 거부된 부여는 포트가 막힌 것과 똑같이 보이는 침묵을 만든다. 도착했지만 표시되지 않은 메시지는 표시 문제이므로 따로 다룬다.
메시지를 즉흥적으로 보내는 대신 통제된 시험을 한 번 한다. 기기, 계정, 앱을 고정하고 알려진 타임스탬프로 메시지 하나를 보낸 뒤 VPN 상태를 승인된 비VPN 네트워크와 비교한다. 각 실행의 logcat 수신 시각과 표시 시각을 기록한다. 전달은 다르지만 표시가 같다면 네트워크 경로가 변수다. 둘 다 같다면 앱을 계속 살펴본다.
네트워크 담당자에게 포트, 프록시 제약, 측정된 타임아웃, 우회 결정을 하나의 메모로 전달한다. «VPN을 끄라»는 것은 발견이 아니고, 모든 Google 트래픽을 허용하는 것은 범위가 정해진 수정이 아니다.