WireGuard أم OpenVPN في إيران؟ عندما يصبح تمويه الاتصال أهم من اختيار البروتوكول

بعد عودة الإنترنت الدولي، توقعت أن تكون المشكلة انتهت. فتحت الهاتف، وصلتني الإشعارات المتأخرة، ثم شغلت الـVPN الذي أستخدمه عادةً على WireGuard. بقي عند الاتصال. بدلت الخادم، ثم خادمًا ثانيًا. لا شيء. انتقلت إلى OpenVPN TCP لأنني أعرف النصيحة المعتادة: إذا تعثر UDP، جرّب TCP على 443. هذه المرة اتصل، لكن التصفح أصبح ثقيلًا إلى درجة أنني بدأت أتساءل إن كنت قد حللت المشكلة أم غيرت شكلها فقط. كنت أريد WhatsApp وبعض صفحات العمل، لا مقارنة بروتوكولات.

هذا السؤال أصبح أكثر إلحاحًا في إيران خلال 2026. بعد انقطاع دولي استمر قرابة 88 يومًا، عاد الوصول إلى الإنترنت العالمي في مايو، لكن الاتصال بقي غير مستقر والقيود ظلت ثقيلة، مع استمرار اعتماد كثير من المستخدمين على VPN للوصول إلى خدمات مثل WhatsApp. (Reuters)

لذلك بدا السؤال طبيعيًا:

WireGuard أم OpenVPN؟

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

السؤال الذي يسبقها هو:

هل شكل اتصال الـVPN نفسه يستطيع المرور على الشبكة المقيدة؟

بدأت بـWireGuard لأنه الاختيار الذي أفضله عادةً

WireGuard سريع وخفيف، وعندما تكون الشبكة متعاونة لا أحتاج معه إلى التفكير كثيرًا.

وهذا بالضبط ما كنت أريده.

ضغطت اتصال.

انتظرت.

لا handshake.

اخترت خادمًا ثانيًا.

ثم ثالثًا.

النتيجة نفسها.

WireGuard يعتمد على UDP، (WireGuard) لكنني لم أكن بحاجة إلى شرح طويل لأفهم ما يحدث في تجربتي: كنت أغير عنوان الخادم، بينما شكل الاتصال الأساسي لا يتغير.

هنا بدأت أفكر في المشكلة بطريقة مختلفة.

إذا كان الطريق نفسه لا يمر، فلن يساعدني كثيرًا أن أملك عشرات الوجهات التي أرسل عبرها النوع نفسه من الحركة.

ولهذا انتقلت إلى الخيار التقليدي التالي.

OpenVPN TCP اتصل، لكنه لم ينهِ المشكلة

اخترت OpenVPN TCP على 443.

هذا خيار منطقي على الشبكات المقيدة لأن TCP 443 هو المنفذ المعتاد لحركة HTTPS، وOpenVPN يستطيع استخدامه عندما يصبح UDP صعبًا. (OpenVPN)

هذه المرة ظهر الاتصال.

فتحت الصفحة التي أريدها.

عملت.

لثوانٍ اعتبرت المقارنة محسومة: OpenVPN أفضل.

ثم بدأت أستخدم الاتصال فعلًا.

الصفحة التالية تأخرت.

الملف الصغير أخذ وقتًا أطول مما ينبغي.

أرسلت رسالة وانتظرت.

لم يعد الاتصال مفقودًا، لكنه أصبح شيئًا أحتاج إلى الصبر عليه.

وهذا غيّر حكمي مرة أخرى.

WireGuard لم يصل.

OpenVPN TCP وصل، لكنه جعلني أتعامل مع الشبكة بدل أن أنسى وجودها.

لم أكن أبحث عن البروتوكول الذي يفوز نظريًا.

كنت أبحث عن طريق يسمح لي باستخدام الإنترنت.

تجارب المستخدمين جعلت فكرة «الفائز» أقل إقناعًا

خلال مايو 2026 ظهرت تجارب من داخل إيران تصف اختلاف النتيجة بين الأدوات والأجهزة؛ اتصال يعمل جيدًا على Linux قد لا يعطي النتيجة نفسها على هاتف Android، وخدمة تكون سريعة عندما تتصل قد لا تنجح في الاتصال كل مرة. (Reddit)

هذا أضاف نقطة عملية واحدة فقط:

المشكلة لا تُحسم باسم البروتوكول وحده.

لذلك توقفت عن التفكير بهذه الطريقة:

WireGuard سريع، إذن أستخدم WireGuard.

OpenVPN يعمل على 443، إذن أستخدم OpenVPN.

وأصبحت أركز على شيء أهم:

في شبكة مقيدة، قدرة الاتصال على تغيير شكله أمام الشبكة أهم من الاختيار النظري بين WireGuard وOpenVPN.

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

TCP 443 ليس عباءة إخفاء

كان لدي افتراض آخر احتجت إلى التخلص منه.

كنت أتصور أن وضع OpenVPN على TCP 443 يجعله شبيهًا تلقائيًا بتصفح HTTPS العادي.

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

TCP 443 قد يساعد كثيرًا عندما يكون الحجب بسيطًا أو عندما تكون المشكلة في UDP، لكنه لا يزيل بالضرورة قدرة الشبكة على تمييز نوع مختلف من الحركة.

وهذا يفسر لماذا استطاع OpenVPN أن يبدأ الاتصال بينما بقي الاستخدام ثقيلًا.

الأمر نفسه ينطبق على WireGuard من الجهة الأخرى: WireGuard الأساسي لا يتضمن التمويه كجزء من البروتوكول؛ إذا أردت تغيير شكل حركته، فأنت تحتاج إلى طبقة إضافية. (WireGuard)

هذه كانت النقطة التي حسمت قراري.

لم أعد أريد التبديل بين WireGuard وOpenVPN.

أردت اتصالًا يبدأ من فكرة أن الشبكة نفسها مقيدة.

هذه المرة لم أختر البروتوكول يدويًا

فتحت OnlydogVPN واستخدمت الوضع المخصص للشبكات المقيدة.

ضغطت اتصال.

ثم تركت تطبيق الـVPN وعدت إلى المهمة التي كنت أحاول إنجازها منذ البداية.

فتحت WhatsApp.

وصلت المحادثات.

أرسلت رسالة.

ظهرت علامة الإرسال.

بعدها فتحت صفحة العمل التي كانت ثقيلة في المحاولة السابقة.

اكتملت.

ثم بدأت تنزيل ملف صغير.

استمر.

والفرق الذي لاحظته لم يكن رقم السرعة.

كان أنني لم أعد إلى تطبيق الـVPN.

لم أغير الخادم.

ولم أبدأ جولة جديدة بين WireGuard وOpenVPN.

كنت أستخدم الإنترنت بدل إدارة وسيلة الوصول إليه.

هنا فقط أصبحت التقنية مفيدة

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

بالنسبة لي، أهمية ذلك كانت بسيطة: لم أعد أكرر الشكل التقليدي نفسه للاتصال وأكتفي بتغيير الخادم، بل انتقلت إلى مسار مصمم أصلًا للشبكات التي تجعل اتصال VPN المعتاد صعبًا.

لا أستطيع من هاتفي رؤية قواعد التصفية الداخلية التي تطبقها الشبكة الإيرانية في تلك اللحظة. لكنني أستطيع مقارنة النتيجة التي أمامي: WireGuard بقي ينتظر، وOpenVPN TCP أوصلني باتصال ثقيل، بينما الوضع المقيد أعادني إلى التطبيقات التي كنت أريد استخدامها.

وهذا كان الاختبار الذي يهمني.

عندها تغير معنى «البروتوكول الأفضل»

لو سألتني على شبكة عادية، فسأختار غالبًا WireGuard بسبب بساطته وسرعته.

لكن هذه ليست شبكة عادية.

إذا كان WireGuard يمر، أستخدمه ولا أبحث عن تعقيد إضافي.

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

عندها لا تفيدني سرعته النظرية لأنني لم أصل أصلًا إلى مرحلة استخدام السرعة.

وهنا يستطيع OpenVPN TCP أن يكون محاولة ثانية مفيدة.

هو أثبت في تجربتي أن تغيير نوع النقل يمكن أن يغيّر النتيجة.

لكن نجاح الـhandshake ليس النهاية أيضًا.

إذا كان الاتصال لا يزال ثقيلًا، أو إذا استمرت الشبكة في مقاومة المسار، فأنا لا أريد قضاء عشر دقائق إضافية في ضبط البروتوكول.

أريد الانتقال إلى تمويه مصمم لهذه الحالة.

وهذا هو الفرق الذي جعل الخيار الأصغر أكثر منطقية بالنسبة لي.

إيران في 2026 جعلت المقارنة القديمة أقل فائدة

عودة الإنترنت الدولي بعد الانقطاع الطويل لم تعنِ عودة شبكة طبيعية. بقي الاتصال غير مستقر، واستمرت القيود على خدمات يستخدمها الناس يوميًا. (Reuters)

لذلك لم تفاجئني تجربة المستخدمين التي تقول إن أداة تعمل اليوم قد تتعثر غدًا، أو أن النتيجة تختلف بين الكمبيوتر والهاتف. (Reddit)

في بيئة كهذه، قائمة طويلة من البروتوكولات ليست دائمًا ميزة إذا كانت تعني أن عليّ أنا اكتشاف أي تركيبة ستعمل الآن.

أفضل أن أبدأ من المشكلة التي أعرفها:

هذه شبكة مقيدة.

ثم أترك التطبيق يختار طريقًا مناسبًا لها.

هذا يقلل عدد القرارات في اللحظة التي لا أريد فيها اتخاذ قرارات تقنية أصلًا.

التنازل موجود، لكنه ليس المشكلة التي واجهتها

الخدمة الأصغر لديها مواقع خوادم أقل، وتاريخ عام أقصر، ومراجعات مستقلة أقل من أكبر مزودي VPN.

إذا كان هدفي اختيار عشرات المدن أو الاعتماد على مزود أمضى سنوات أطول تحت التدقيق العام، فالأسماء الكبيرة لديها أفضلية واضحة.

لكنني لم أكن أعاني من نقص في الخوادم.

كان لدي خوادم كثيرة.

وكان لدي WireGuard.

وكان لدي OpenVPN.

ما كنت أفتقده هو طريقة للخروج من المقارنة بينهما عندما يصبح شكل اتصال الـVPN نفسه جزءًا من المشكلة.

ولهذا أصبحت إجابتي عن سؤال «WireGuard أم OpenVPN أفضل على الشبكات المقيدة في إيران؟» مختلفة عن أي جدول سرعات: WireGuard ممتاز عندما يمر، وOpenVPN TCP بديل عملي عندما يتعثر UDP؛ لكن عندما تبدأ الشبكة في مقاومة اتصال الـVPN نفسه، يصبح التمويه أهم من اسم البروتوكول المكتوب على زر الاتصال.