تسريع SSH عبر نطاق Cloudflare الأفضل: مراجعة كلما أصلحناها بدت أكثر كفيلم غموض

[AIYA.DE5.NET]

معرض السلوكيات المزعجة في “تسريع” SSH: كيف حوّلنا “يشتغل” إلى “أخيرًا صار ثابتًا”

خلّني أقول الخلاصة أولًا كي لا تُغلق الصفحة في منتصف القراءة:

• هذه الخطة ترفع “الاستقرار”، لكنها لا تضمن خفض “رقم زمن التأخير” بشكل ملحوظ.
• Cloudflare المجاني + wstunnel قد ينقذ الموقف، لكنه لن يحوّل الاتصال إلى خط مخصص من العدم.
• أكبر مكسب: لاحقًا عند مواجهة مشاكل مشابهة، ستعرف أي طبقة تفحص أولًا بدل الاعتماد على “الحدس”.

الفصل الأول: 300ms ليست مخيفة، المخيف هو “يتقطّع كأنه PPT”

بدأت القصة ببساطة شديدة:

• من الصين إلى سنغافورة، ping حوالي 300ms.
• موقع الخدمة يبدو قابلًا للاستخدام، لأن هناك وكيل Cloudflare العكسي ونطاق مُحسَّن.
• لكن ما إن تكتب على SSH حتى تدخل مرحلة “أنت تتكلم وأنا أنتظر قليلًا ثم أرد”.

فجاء السؤال الوجودي:

“HTTP يمكن تسريعه، هل يمكن لـ SSH أن يستفيد أيضًا؟”

الجواب: نعم، لكن عليك تقبّل أنه ليس “سحر زر واحد”، بل أحجية متعددة الطبقات.

الفصل الثاني: ظننّاه شبكة، فإذا بالإعدادات تتصارع فيما بينها

أكثر جزء بدا كفيلم غموض هو:

• ssh.cafe.de5.net يبدو أنه يعمل.
• ssh.aiya.de5.net والشهادة أيضًا active.
• لكن العميل يتلقى رسائل مثل connection closed by foreign host وConnection refused.

ثم بعد التتبع اتضح أن:

• Cloudflare SaaS (البرمجيات كخدمة) مع المضيف المخصص (custom hostname) يجلب معه Host خاصًا عند الرجوع إلى الخادم الأصلي (origin).
• عندما لا يتضمن Nginx في server_name اسم ssh.aiya.de5.net، سيُسقِط الطلب على موقع/سيرفر خاطئ.
• وبعدها ما تراه ليس “خطأ واضحًا”، بل “كل شيء غير منطقي”.

وخلاصة بجملة واحدة:

هو ليس متعطلًا، لكنه في كل طبقة “شبه صحيح”.

الفصل الثالث: ظهور 400 في المتصفح غالبًا خبر جيد

كثيرون يُفزعهم هذا لأول مرة:

عند زيارة https://ssh.xxx ترى Invalid protocol request أو 400 وتعتقد أن كل شيء انهار.

لكن في هذه البنية، هذا غالبًا أمر جيد:

• يعني أن الطلب وصل إلى خلفية wstunnel.
• لكن ما أرسلته من المتصفح هو HTTP، وليس تدفق بروتوكول SSH-over-WS.

أي أن:

• 400 قد تعني “المسار يعمل لكن البروتوكول غير صحيح”؛
• أما 404 فأقرب إلى “لم يصل أصلًا إلى الخلفية التي تتوقعها”.

الفصل الرابع: العميل هو آخر ميل (وهو أيضًا أسهل ميل للانقلاب)

حتى لو ضُبط الخادم بالكامل، ما زال العميل قد ينقلب:

• تظن أنك تتصل بنطاق التسريع، لكن FinalShell في الحقيقة يتصل بـ 127.0.0.1:10022 بينما النفق المحلي لم يعمل.
• اختلاف إصدارات wstunnel وعدم توافق الوسائط؛ خيار -v واحد قد يعطي unexpected argument.
• في سجلات SSH يظهر kex_exchange_identification: Connection closed، وجوهر المشكلة أن النفق لم يُنشأ بثبات.

وفي النهاية، “الوضع الصحيح” بسيط جدًا:

1. شغّل على جهازك wstunnel client أولًا ليجعل المحلي 10022 في وضع الاستماع.
2. ثم اجعل FinalShell/الطرفية تتصل بـ 127.0.0.1:10022.
3. إذا لم يتصل، افحص أولًا “هل المنفذ المحلي في وضع الاستماع”، ولا تبدأ بتشكيكك في الحياة.

الفصل الخامس: هل فعلاً “سرّع”؟

هذا سؤال يستحق فقرة مستقلة.

في معظم الحالات ستحصل على:

• رقم زمن التأخير: تغيّر قليل (وأحيانًا شبه ثابت)
• الإحساس بالاستقرار: أفضل بوضوح (لا انقطاعات عشوائية ولا “جنون”)

لماذا؟

• Cloudflare المجاني ليس خط Argo مخصصًا، ولن يمحو المسافة الفيزيائية بسحر.
• لكنه غالبًا يحوّل “تذبذب المسار السيئ” إلى شيء أكثر قابلية للتحكم.

لذا هذه الخطة أقرب إلى:

تركيب “مثبّت اهتزاز” لـ SSH، لا استبدال “محرك بسرعة الضوء”.

قائمة تجنب الحفر لمن يأتي بعدنا (نسخة مركزة)

1. ثبّت نموذج المسار أولًا: هل تستخدم wstunnel أم cloudflared tunnel؟ لا تخلط المفاهيم.
2. في SaaS مع المضيف المخصص تأكد دائمًا من تطابق custom_origin_server وHost عند الرجوع للأصل.
3. يجب أن يغطي Nginx في server_name أسماء مضيفي SaaS، وإلا سيسقط على موقع خاطئ.
4. فتح نطاق SSH في المتصفح وإرجاع 400 ليس بالضرورة شيئًا سيئًا.
5. على العميل: افحص أولًا استماع المنفذ المحلي، ثم راجع سجلات SSH.
6. اجعل الهدف “الاستقرار” أولًا، لا التحديق في “يجب أن ينخفض التأخير”.

الجملة الأخيرة (لك الذي يسهر لضبط الشبكة)

أكبر قيمة في هذه المعاناة لم تكن “أمرٌ ما نجح أخيرًا”، بل أنك فككت سلسلة معقدة إلى وحدات قابلة للتحقق:

• DNS
• مضيف SaaS
• الرجوع إلى الأصل (origin)
• النفق
• العميل

عندما تستطيع تتبع الأعطال طبقةً بطبقة، تتحول “مشاكل الشبكة الغامضة” إلى “مشاكل هندسية عادية”.

مبارك: من شخص تعذبه الشبكة، إلى شخص يعذب الشبكة.