Thông báo đẩy Android không hoạt động với VPN? Hãy kiểm tra những điều này
FCM duy trì kết nối ra riêng trên các cổng 5228-5230. Kiểm tra quy tắc proxy, thời gian chờ NAT và việc bỏ qua VPN trước khi chạm vào cài đặt thông báo.
Thông báo ngừng đến trên một chiếc điện thoại vốn duyệt web tốt qua VPN của công ty. Trang web tải được, ứng dụng mở được, và tin nhắn chỉ hiện khi ở nhà hoặc sau khi tắt đường hầm. Với ứng dụng xây trên Firebase Cloud Messaging, kênh đẩy là một kết nối ra riêng biệt và tồn tại lâu, không phải đường HTTPS mà trình duyệt vừa chứng minh. Hãy thực hiện các kiểm tra này theo thứ tự và dừng ở kiểm tra đầu tiên thất bại.
Xác nhận ứng dụng thực sự dùng FCM
Không phải mọi thông báo đều là đẩy. Một số do ứng dụng lên lịch cục bộ, một số được hỏi qua HTTPS, và một số đến qua kênh của nhà cung cấp không liên quan gì đến Firebase. Nếu tệp kê khai và các phụ thuộc của ứng dụng có Firebase Messaging, thông báo của nó thường đi qua kết nối FCM, và thư viện khách ghi lại đăng ký dưới một thẻ có thể đoán trước.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebase
Một mã đăng ký trong nhật ký xác nhận đường truyền. Không có nó, bạn đang gỡ lỗi đường ống thông báo ở cấp ứng dụng, và các thay đổi tường lửa sẽ không giúp gì. Sự khác biệt này quan trọng vì một tin nhắn đã được gửi nhưng không bao giờ hiển thị và một tin nhắn không bao giờ đến trông giống nhau với người dùng.
Kiểm tra các cổng ra, không phải trang web
Kết nối thiết bị tới FCM là TCP do thiết bị khởi tạo tới cổng 5228, với 5229 và 5230 làm dự phòng và 443 là phương án cuối. Một tường lửa cho phép 443 để duyệt web vẫn có thể làm hỏng đẩy, và quy tắc cho phép miền API của ứng dụng không bao gồm các điểm cuối nhắn tin, vốn là những dịch vụ riêng.
Đây là các kết nối ra từ điện thoại. Bạn không công bố cổng vào trên thiết bị hay trên cổng VPN, nên nếu ai đó đề xuất chuyển tiếp cổng thì thiết kế đã sai. Điều tương tự đúng với quy tắc mở một cổng cho mọi địa chỉ trên internet: hãy giới hạn nó trong các đích đã ghi tài liệu.
| 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 |
Hướng dẫn mạng của Firebase cũng nói rằng giao thức gửi của FCM không thể được mang qua proxy HTTP thông thường. Vì vậy việc trình duyệt chạy qua proxy web của công ty không chứng minh gì về ổ cắm đẩy: đó là hai khách hàng khác nhau với đường đi khác nhau.
Kiểm tra thời gian chờ không hoạt động giết chết ổ cắm
Kết nối FCM vẫn mở giữa các tin nhắn, khiến nó nhạy cảm với thời gian chờ NAT và kiểm tra trạng thái. Hướng dẫn của Firebase yêu cầu ít nhất 30 phút dung sai không hoạt động ở nơi áp dụng chính sách đó. Thời gian chờ phiên năm phút âm thầm xóa ánh xạ, và điện thoại chỉ kết nối lại khi có thứ gì đánh thức nó, nên tin nhắn đến theo đợt hoặc không đến.
Đọc bảng phiên trên tường lửa hoặc cổng VPN và tìm kết nối của điện thoại tới 5228-5230. So sánh thời gian sống còn lại với giá trị đã ghi tài liệu. Nếu ngắn hơn, hãy tăng thời gian chờ cho các cổng đó thay vì thay đổi mọi chính sách trên thiết bị, vì một thay đổi thời gian chờ toàn cục rất khó biện minh và còn khó hoàn tác hơn.
Việc gửi đẩy cũng phụ thuộc vào việc ánh xạ điểm cuối sống sót qua chuyển vùng giữa Wi-Fi và mạng di động. Một ánh xạ gắn với một giao diện có thể bị bỏ khi bàn giao dù cả hai mạng đều cho phép các cổng.
Quyết định xem bỏ qua VPN có chấp nhận được không
Ứng dụng khách VPN trên Android có thể cho phép lưu lượng bỏ qua đường hầm, và FCM có thể dùng mạng bên dưới khi việc bỏ qua đó được phép. Khi đó kênh đẩy vẫn được mã hóa, nhưng không còn mang địa chỉ của đường hầm, nên việc che IP của VPN không áp dụng cho nó. Đó là sự đánh đổi chính sách, không phải hỏng hóc.
Nếu chính sách của bạn cấm bỏ qua, đường hầm phải mang kết nối: cổng mở, thời gian chờ đủ dài, proxy không cản đường. Đừng âm thầm loại trừ một dịch vụ được quản lý và đừng nới lỏng khóa chỉ vì thông báo chạy trên mạng không được quản lý. Biểu tượng VPN không cho biết dịch vụ nào đã chọn đường nào
Tách việc gửi khỏi việc hiển thị, rồi thử một lần
Quyền, cài đặt kênh, Không làm phiền và công tắc từng ứng dụng quyết định một tin nhắn đã gửi có được hiển thị hay không. Trên Android 13 trở đi, quyền thông báo được cấp khi chạy, và việc từ chối tạo ra sự im lặng trông y hệt một cổng bị chặn. Một tin nhắn đã đến nhưng không hiển thị là vấn đề trình bày; hãy xử lý riêng.
Hãy làm một bài kiểm tra có kiểm soát thay vì gửi tin nhắn tùy tiện. Giữ cố định thiết bị, tài khoản và ứng dụng, gửi một tin nhắn với dấu thời gian đã biết, và so sánh tình trạng VPN với một mạng không VPN đã được phê duyệt. Ghi lại thời điểm nhận trong logcat và thời điểm hiển thị cho mỗi lần chạy. Nếu việc gửi khác nhau nhưng hiển thị không, đường mạng là biến số; nếu cả hai giống nhau, hãy tiếp tục xem ứng dụng.
Trao cho chủ mạng các cổng, giới hạn proxy, thời gian chờ đã đo và quyết định bỏ qua trong một ghi chú. «Tắt VPN đi» không phải là phát hiện, và cho phép toàn bộ lưu lượng Google không phải là bản sửa có phạm vi.