لماذا يمكن الوصول مباشرةً إلى بعض خدمات Google في البرّ الرئيسي الصيني، بينما غالبًا ما تعمل إشعارات FCM دون وكيل؟

AIDO تصحيح الأخطاء
, , ,
1

كثيرون عندما يواجهون هذه الظاهرة لأول مرة يحتارون: www.google.com ونسخة الويب من Gmail وYouTube في برّ الصين الرئيسي عادةً غير مستقرة أو حتى غير متاحة مباشرةً، لكن بعض إشعارات الدفع (Push) على Android التي تعتمد على 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 لاستقبال الإشعارات على الجهاز غير مناسب للمرور عبر وكيل (Proxy)، وينبغي أن يتمكّن الجهاز من الاتصال مباشرةً بخوادم FCM.
  • لهذا السبب تفصل كثير من مجموعات القواعد GoogleFCM كحالة خاصة وتفضّل DIRECT. غالبًا لا يكون هذا «سهوًا»، بل أقرب لتوصيات Google الرسمية ولأداء الشبكات في الواقع.
  • لكن هذا لا يعني أيضًا أن «كل شبكات البرّ الرئيسي وفي كل الأوقات يمكنها الاتصال بـ FCM مباشرةً». فقد تختلف النتائج باختلاف المشغّل، أو شبكة الجامعة، أو شبكة الشركة، أو الوقت، أو ظروف IPv4/IPv6.

ما العناوين والمنافذ التي يستخدمها FCM بالضبط؟

قدّمت وثيقة Google / Firebase الرسمية المحدّثة بتاريخ 2026-03-20 بعنوان «Configure your Network for FCM» قائمة واضحة نسبيًا.

جهة استقبال الإشعارات على الجهاز

توصي 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 الخاصة بالصين تلخّص حاليًا قياسات واردة من 226 شبكة محلية و40,219,834 عملية قياس، كما تنبّه بوضوح إلى أن النتائج الشاذة ينبغي مراقبتها مع الزمن وضمن بيئة الشبكة، وأن الشذوذ لمرة واحدة قد ينتج عنه حكم خاطئ. وهذا يوضّح أن القياس الشبكي في برّ الصين الرئيسي ليس مسألة «نقطة واحدة تكفي للحسم».

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%

لكن منتجات 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 تحديدًا، لأنها تستخدم نطاقات مختلفة ومنافذ مختلفة وبروتوكولات مختلفة، ولأن التوصية الرسمية أصلًا هي الاتصال المباشر من الجهاز، فمن غير المستغرب أن تعمل مباشرةً في بعض شبكات البرّ الرئيسي.

المراجع

  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