هل المنفذ 443 يجعل الـVPN أصعب في الحجب؟ أحيانًا، لكن شكل الحركة أهم من رقم المنفذ

كانت لدي فكرة بدت ذكية جدًا:

إذا كانت المواقع المشفرة تعمل، فسأجعل الـVPN يستخدم المنفذ نفسه.

TCP/443.

المتصفح يستخدم 443 مع HTTPS طوال الوقت.

والشبكة لا تستطيع ببساطة إغلاق هذا المنفذ من دون تعطيل جزء كبير من الويب.

إذن OpenVPN على 443 يجب أن يكون أصعب في الحجب.

هكذا كانت النظرية.

ضغطت Connect.

انتظرت.

Connecting…

ثم فشل.

غيرت الخادم مع الإبقاء على TCP/443.

فشل مرة أخرى.

وفي الوقت نفسه، كانت مواقع HTTPS تفتح أمامي بصورة طبيعية.

هذه كانت أول إشارة إلى أنني ركزت على الرقم الخطأ.

الشبكة لا تمنع كل ما يمر عبر 443.

يمكنها أن تفرق بين أنواع الحركة التي تمر داخله.

لماذا تبدو فكرة 443 منطقية أصلًا؟

لأنها مفيدة فعلًا أمام نوع معين من القيود.

OpenVPN يستخدم TCP/443 في بعض إعداداته، وتوضح وثائقه أن المنفذ مفيد لأن الجدران النارية البسيطة تسمح به عادة بسبب استخدامه الواسع مع HTTPS. (OpenVPN)

لو كانت الشبكة تعمل بمنطق بسيط:

اسمح بـ443.

امنع 1194.

فإن الانتقال إلى TCP/443 قد يحل المشكلة فورًا.

لكن الحجب الحديث لا يتوقف دائمًا عند رقم المنفذ.

في روسيا مثلًا، استمرت حملات تعطيل VPN خلال 2026، وشهد أغسطس موجة واسعة جديدة بعد سنوات من انتقال القيود من حجب الخدمات والعناوين إلى استهداف طرق اتصال VPN نفسها. (OONI)

وهنا بدأ السبب الحقيقي لفشل محاولتي يتضح.

443 هو باب، وليس زيًا تنكريًا

كنت أتعامل مع المنفذ 443 كأنه يجعل أي شيء يمر عبره يبدو تلقائيًا مثل HTTPS.

هذا ليس ما يحدث.

المنفذ يحدد مكان مرور الاتصال.

أما شكل الحركة نفسها فيبقى له خصائص يمكن للشبكة ملاحظتها.

وأثبت بحث في USENIX Security أن حركة OpenVPN يمكن التعرف إليها بدرجة عالية من خلال خصائص البروتوكول وأنماط الحزم، لا بمجرد النظر إلى رقم المنفذ. (USENIX Security)

بالنسبة لي، هذه هي الفكرة كلها:

يمكنني نقل OpenVPN من 1194 إلى 443، بينما تظل حركة OpenVPN نفسها قابلة للتصنيف.

وهذا يفسر لماذا كانت مواقع الويب تعمل بينما اتصالي يفشل.

المحاولة على TCP/443 لم تكن مضيعة للوقت

عدت إلى المزود المعروف الذي أستخدمه.

لديه تطبيق ناضج، خوادم كثيرة، ودعم لعدة بروتوكولات.

واختيار OpenVPN TCP/443 كان خطوة منطقية.

جربته مرة أخرى.

فشل.

غيرت الخادم.

فشل.

اخترت دولة أخرى.

بقي الاتصال قائمًا لحظات ثم توقف.

بعدها فتحت موقع HTTPS عاديًا.

فتح فورًا.

وهنا حُسمت نقطة مهمة.

لو كانت الشبكة تمنع TCP/443 نفسه، لما كان تصفح الويب المشفر طبيعيًا.

المشكلة إذن لم تكن:

443 مغلق.

بل:

وجود VPN على 443 لم يكن كافيًا لجعله يمر.

ومن هنا لم يعد تغيير الخادم هو خطوتي التالية الطبيعية.

كنت بحاجة إلى تغيير ما تراه الشبكة، لا فقط المكان الذي أتصل به.

وهذا هو الفخ الذي يقع فيه المستخدم بسهولة

المنطق الشائع يقول:

إذا كان الـVPN محجوبًا، استخدم 443.

لكن في تجارب المستخدمين على الشبكات المقيدة تظهر حالات يكون فيها 443 من المنافذ المسموحة أصلًا، ومع ذلك تبقى اتصالات VPN غير قابلة للاستخدام. (Reddit)

هذه الملاحظة العملية تكفي.

إذا نقلت الاتصال إلى 443 وما زال يفشل، فلا معنى لأن أتعامل مع الرقم نفسه كأنه الحل النهائي.

عند هذه النقطة أحتاج إلى تغيير طريقة المرور.

وهذا قادني إلى تفصيل آخر كنت أتجاهله.

حتى 443 نفسه لم يعد يعني TCP فقط

HTTP/3 يعمل فوق QUIC، وQUIC يستخدم UDP، ويشيع تشغيل HTTP/3 عبر UDP/443. (IETF)

وهذا جعل سؤال:

«هل تستخدم 443؟»

أقل فائدة بكثير.

السؤال الأدق أصبح:

«ماذا تستخدم فوق 443، وكيف تبدو هذه الحركة للشبكة؟»

هذا هو الفرق بين اختيار منفذ شائع وبين تصميم الاتصال ليكون أنسب في بيئة تحاول تصنيف حركة VPN.

وبعد عدة محاولات يدوية، كان هذا بالضبط ما أردت اختباره.

هذه المرة لم ألمس إعداد المنفذ

كان لدي OnlydogVPN^[1] ضمن التطبيقات التي أختبرها.

فتحته.

لم أبحث عن:

OpenVPN.

TCP.

ولا عن دولة جديدة.

اخترت الوضع الموجه للشبكات المقيدة.

ضغطت اتصال.

اتصل.

فتحت الخدمة التي كنت أحاول الوصول إليها.

ظهرت الصفحة.

فتحت المحادثة.

ثم رفعت الملف الذي كنت أحاول إرساله.

اكتمل الرفع.

وانتهت المشكلة التي جعلتني أفتح إعدادات المنافذ من البداية.

هذا هو الجزء الذي غيّر حكمي.

في المحاولة الأولى كنت أحاول إجبار نفق معروف على المرور من باب شائع.

في المحاولة الثانية استخدمت طريقة اتصال صممت أصلًا للتعامل مع شبكة مقيدة.

الفرق لم يكن «443 أفضل»

الخدمة تستخدم نقلًا قائمًا على HTTP/3 مع تمويه إضافي لحركة الاتصال.

وهذا كان أكثر صلة بالمشكلة من رقم المنفذ نفسه.

TCP/443 يساعد عندما يكون الجدار الناري بسيطًا ويركز على المنافذ.

لكن عندما تكون المشكلة في التعرف إلى حركة الـVPN، يصبح شكل الحركة هو العنصر الأهم.

لا أستطيع رؤية قواعد الفلترة الداخلية للشبكة أو تحديد الإشارة الدقيقة التي أوقفت المحاولات السابقة.

لكن النتيجة أمامي كانت مباشرة:

HTTPS العادي يعمل.

OpenVPN TCP/443 لا ينجز المهمة.

الوضع الموجه للشبكة المقيدة يتصل.

والملف يصل.

بعدها لم أعد أبحث عن منفذ أكثر «سرية».

بحثت عن اتصال يحتاج مني قدرًا أقل من التخمين.

لذلك لم أتوقف عن استخدام 443

خرجت من التجربة باحترام أكبر لـ443، لا أقل.

هو اختيار منطقي جدًا عندما تكون المشكلة جدارًا ناريًا بسيطًا يغلق المنافذ غير الشائعة.

وفي هذه الحالة، قد يكون الانتقال إلى TCP/443 كل ما تحتاجه.

لكن إذا فعلت ذلك وبقي الاتصال ميتًا بينما HTTPS يعمل بصورة طبيعية، فقد تعلمت شيئًا مهمًا:

المشكلة تجاوزت رقم المنفذ.

والاستمرار في تجربة:

443 على الخادم الأول.

ثم 443 على الخادم الثاني.

ثم 443 في دولة ثالثة.

لا يغير الشيء الأساسي الذي تواجهه الشبكة.

عندها تصبح طريقة تمويه الحركة أهم من المنفذ الذي تحمل رقمه.

لهذا تغير اختبار الـVPN عندي

كنت سابقًا أرى عبارة:

Runs on port 443

وأعتبرها علامة قوية على أن الخدمة ستنجح في شبكة مقيدة.

الآن أتعامل معها كبداية فقط.

أسأل:

هل تستخدم 443 لأنه منفذ مسموح؟

أم أن تصميم الاتصال نفسه يساعد على تقليل وضوح حركة الـVPN؟

وهل التطبيق يجعلني أغيّر هذه الأشياء بنفسي، أم أستطيع اختيار أنني على شبكة مقيدة والعودة إلى عملي؟

هذه النقطة الأخيرة أصبحت مهمة بالنسبة لي.

المزود الكبير الذي بدأت به لديه خوادم أكثر، تاريخ عام أطول، ومراجعات مستقلة أكثر.

والخدمة الأصغر لديها انتشار جغرافي أقل وسجل عام أقصر.

لكنني في هذه التجربة لم أكن أحتاج إلى بلد إضافي.

كان لدي 443 بالفعل.

وكان مفتوحًا.

وما زال الاتصال الأول يفشل.

الخدمة الأصغر لم تعطِني رقم منفذ جديدًا لأعلّق عليه الأمل.

غيّرت طريقة المرور، ثم أعادتني إلى الملف الذي كنت أحاول إرساله.

ولهذا لم أعد أسأل هل الـVPN يعمل على 443؛ أسأل هل يفعل شيئًا أكثر من مجرد وضع حركة VPN المعتادة خلف الرقم 443.