למה בסין היבשתית אפשר להתחבר ישירות לחלק משירותי Google, בעוד שהתראות דחיפה של FCM לרוב לא דורשות פרוקסי?

AIDO debug
, , ,
1

רבים נתקלים בתופעה הזו בפעם הראשונה ותוהים: www.google.com, גרסת הווב של Gmail, ו-YouTube בדרך כלל לא יציבים ואף בלתי נגישים בסין היבשתית, אבל חלק מההתראות בדחיפה (push) באנדרואיד שתלויות ב‑Google / Firebase Cloud Messaging (FCM) דווקא עדיין מתקבלות לעיתים קרובות; ואפילו יש סטים מסוימים של כללי פרוקסי שמכוונים במכוון את GoogleFCM ל‑DIRECT. זה לא ש“לא חסמו את Google בכלל”, אלא שהמדיניות שנפגעת מהחסימה שונה בין מוצרים, דומיינים, פורטים ופרוטוקולים שונים של Google.

המאמר הזה מתחיל מהמסקנה: בסין היבשתית החסימה של Google אינה “מתג אחד שסוגר הכול”, אלא מטופלת בשכבות, לפי דומיינים, לפי פורטים, לפי פרוטוקולים, לפי סביבת רשת, לפי חלונות זמן. ערוץ הדחיפה בצד המכשיר של FCM, ומה שאנשים ניגשים אליו ביום‑יום כמו www.google.com / Gmail / YouTube, הם בכלל לא אותה שרשרת תקשורת.

קודם המסקנות

  • קליטת התראות דחיפה בצד המכשיר של FCM לא נשענת על www.google.com, אלא על שמות מארחים כמו mtalk.google.com, mtalk4.google.com, alt1-mtalk.google.com עד alt8-mtalk.google.com ועוד.
  • הפורטים המרכזיים ש‑Google מציינת רשמית עבור צד המכשיר של FCM הם בעיקר 5228, 5229, 5230, וכן 443.
  • Google גם מציינת במפורש: פרוטוקול ה‑FCM לקליטת התראות בצד המכשיר אינו מתאים לעבור דרך פרוקסי רשת, והמכשיר אמור להיות מסוגל להתחבר ישירות לשרתי FCM.
  • לכן הרבה סטים של כללים מפרידים את GoogleFCM כחריג בפני עצמו, ומעדיפים DIRECT. לרוב זה לא “פספוס”, אלא התאמה טובה יותר להמלצות הרשמיות ולביצועים בפועל ברשת.
  • אבל זה גם לא אומר ש“בכל הרשתות בסין ובכל זמן אפשר להתחבר ישירות ל‑FCM”. ספקים שונים, רשתות אוניברסיטה, רשתות ארגוניות, שעות שונות, ותנאי IPv4/IPv6 — כולם יכולים להוביל לתוצאות שונות.

באילו כתובות ופורטים FCM משתמשת בעצם?

Google / Firebase ציינו ברשימת “Configure your Network for FCM” שעודכנה ב‑2026-03-20 רשימה די ברורה.

צד המכשיר לקליטת דחיפה

Google ממליצה לאפשר את שמות המארחים הבאים:

  • mtalk.google.com
  • mtalk4.google.com
  • mtalk-staging.google.com
  • mtalk-dev.google.com
  • alt1-mtalk.google.com עד alt8-mtalk.google.com
  • android.apis.google.com
  • device-provisioning.googleapis.com
  • firebaseinstallations.googleapis.com

הפורטים התואמים הם בעיקר:

  • 5228
  • 5229
  • 5230
  • 443

Google גם מדגישה במיוחד שפרוטוקול ה‑FCM בזמן קליטת דחיפה בצד המכשיר לא מתאים לתיווך דרך פרוקסי רשת, ולכן המכשיר צריך להיות מסוגל להתחבר ישירות לשרתים שלה.

צד השרת לשליחת הודעות

אם אתה קורא ל‑FCM מהצד השרת כדי לשלוח הודעות, הכתובות המרכזיות ש‑Google מציינת הן:

  • fcm.googleapis.com
  • accounts.google.com
  • iid.googleapis.com

לכן, “גישה לווב של Google” ו‑“ערוץ הדחיפה של FCM”, מבחינת דומיינים, פורטים, פרוטוקולים ושימוש — הם מלכתחילה שני דברים שונים.

למה google.com לעיתים קרובות לא עובד, אבל FCM אולי עדיין יכול להתחבר ישירות?

הסיבה המרכזית פשוטה: החסימה אינה “חותכת” לפי תווית של “חברת Google” באופן גורף, אלא מתבצעת לפי מאפייני רשת מפורטים יותר.

1. הדומיינים שנפגעים שונים

מה שמשתמשים רגילים פוגשים הכי הרבה:

  • www.google.com
  • mail.google.com
  • youtube.com
  • drive.google.com

ואילו בצד המכשיר של FCM נפוצים יותר:

  • mtalk.google.com
  • alt1-8.mtalk.google.com
  • מעט דומיינים נלווים לאתחול

מנקודת המבט של מערכת החסימה, אלה לא אותה מטרה.

2. פורטים ופרוטוקולים שונים

כשניגשים לווב, רוב התעבורה היא HTTPS רגיל על 443; לעומת זאת, דחיפה במכשיר דרך FCM לרוב היא חיבור TCP ארוך‑טווח שנשמר לאורך זמן, שרץ על 5228-5230, והמשמעות שלו יותר “חיבור דחיפה מתמשך” ולא “פתיחת דף אינטרנט”.

זה אומר שהוא יפגע בנתיבי זיהוי והתערבות שונים.

3. סביבת רשת שונה

אותו דומיין ברשתות שונות יכול להניב תוצאות שונות לגמרי. אינטרנט ביתי, נתונים סלולריים, רשת קמפוס, רשת ארגונית — כולם יכולים לטפל באופן שונה ב‑DNS, IPv4, IPv6, SNI, חיבורים ארוכי‑טווח, ומדיניות פרוקסי.

עמוד סין של OONI מסכם כרגע 40,219,834 מדידות מ‑226 רשתות מקומיות, ומזהיר במפורש: צריך לעקוב לאורך זמן ולפי סביבת רשת, וגם חריגה חד‑פעמית עשויה להיות טעות. זה בדיוק מראה שמדידות רשת בסין היבשתית אינן משהו שאפשר להסיק ממנו מסקנה חד‑משמעית מנקודת מדידה אחת.

4. לא כל נקודות הקצה של Google חשובות באותה מידה או קלות לטיפול באותה מידה

זו השערה, אבל היא מאוד הגיונית הנדסית: חיפוש ווב, וידאו, ממשק דואר — לעומת חיבור דחיפה מתמשך של מכשירים — הם סוגי תעבורה שונים מבחינת שכבת הרשת; אם חוסמים את כל נקודות הקצה באותה עוצמה, היקף הפגיעה השגויה ועלות התחזוקה עשויים להיות גבוהים יותר.

לכן בשטח, המצב הנפוץ אינו “הכול פתוח” או “הכול חסום”, אלא חלק לא עובד לאורך זמן, חלק מקרטע לפעמים, וחלק עובד רק ברשתות מסוימות.

מה אפשר לראות מנתונים ציבוריים?

מדידות ציבוריות גם תומכות בתצפית הזו של “לא הכול באותה גזרה”.

באינדקס הציבורי הנוכחי של GreatFire, אפשר לראות 0% עבור קבוצת נקודות קצה של mtalk

נכון לרגע כתיבת המאמר, בעמוד האינדקס הציבורי של GreatFire אפשר לראות:

  • https://mtalk.google.com מוצג כ‑0%
  • https://mtalk.google.com:5228 מוצג כ‑0%
  • https://alt1-mtalk.google.com עד https://alt8-mtalk.google.com גם מופיעים עם רשומות 0%

אבל מוצרי Web טיפוסיים של Google עדיין מופיעים עם הרבה רשומות 100% blocked

באותו עמוד אינדקס ציבורי של GreatFire, אפשר לראות למשל:

  • https://www.google.com עם רשומה של 100% blocked
  • הרבה רשומות https://www.youtube.com/... עם 100% blocked
  • הרבה רשומות הקשורות ל‑mail.google.com, drive.google.com גם מופיעות עם 100% blocked

העמודים הללו הם תוצאות אינדוקס של מדידות ציבוריות; זה לא אומר “כך זה תמיד”, אבל זה לפחות מראה דבר אחד: הנגישות של שירותים הקשורים ל‑Google בסין היבשתית באמת אינה גורל אחיד.

בדיקה מעשית שלי על מחשב ברשת בסין היבשתית

כדי לא להסתמך רק על כללים ולא על המציאות, ביצעתי בדיקה ישירה על מחשב Windows שנמצא בסביבת רשת בסין היבשתית, בתאריך 2026-03-22.

התוצאה:

  • המחשב הצליח להקים ישירות חיבור TCP אל mtalk.google.com:5228.
  • בעת ההתחברות היעד בפועל היה 2404:6800:4008:c02::bc:5228.
  • בקונפיגורציה של mihomo במחשב, GoogleFCM הופרד לקבוצת כללים ייעודית, וברירת המחדל העדיפה DIRECT.

זה לא אומר שכל רשת בסין מתנהגת כך, אבל זה לפחות מראה ש: הטענה “FCM בסין חייב פרוקסי” אינה נכונה. ברשתות מסוימות הוא פשוט עובד בחיבור ישיר.

אז האם צריך לתת ל‑FCM “רשת ביטחון” דרך פרוקסי?

ההמלצה שלי: להעדיף חיבור ישיר, ורק בעת הצורך להשאיר פרוקסי כגיבוי.

יש לכך שלוש סיבות:

  • זה קרוב יותר להמלצה הרשמית של Google עבור FCM בצד המכשיר.
  • חיבורים מתמשכים של דחיפה לרוב “שונאים טלטולים” — ככל שהנתיב פשוט יותר, כך הוא יציב יותר.
  • יש רשתות שבאמת חוסמות נקודות קצה כמו mtalk, ואז גיבוי דרך פרוקסי עדיין בעל ערך.

לכן בכלים כמו mihomo / Clash, דרך מחשבה סבירה לרוב היא:

  • להפריד את GoogleFCM כקטגוריה בפני עצמה.
  • כברירת מחדל לנסות DIRECT.
  • אם ברשת שלך חיבור ישיר נכשל לעיתים קרובות, לבחור ידנית צומת יציב כגיבוי.

משפט סיכום אחרון

סין היבשתית אינה “Google הכול אפשר ישירות”, וגם לא “Google הכול חייב פרוקסי”; ניסוח מדויק יותר הוא: לשירותי Google שונים יש גורלות רשת שונים. ענף הדחיפה של FCM, כי הוא משתמש בדומיינים אחרים, פורטים אחרים ופרוטוקולים אחרים, וגם כי Google ממליצה מלכתחילה על חיבור ישיר למכשיר — יכול לעבוד ישירות בחלק מהרשתות בסין היבשתית, וזה לא מפתיע.

מקורות

  1. תיעוד רשמי של Firebase: תצורת רשת ל‑FCM
    为 FCM 配置网络  |  Firebase Cloud Messaging

  2. OONI Explorer: סקירת מדידות רשת בסין
    Internet Censorship in China - OONI Explorer

  3. אינדקס ציבורי של GreatFire: mtalk.google.com / mtalk.google.com:5228 / alt1-8-mtalk.google.com עם רשומות 0%
    https://en.greatfire.org/SEARCH/HTTPS?page=706
    Censorship of Google Sites in China | GreatFire Analyzer
    https://en.greatfire.org/SEARCH/URLS?page=3602

  4. אינדקס ציבורי של GreatFire: www.google.com, YouTube וכו’ עם הרבה רשומות 100% blocked
    https://en.greatfire.org/SEARCH/URLS?page=390
    https://en.greatfire.org/SEARCH/HTTPS?page=202