نشر منصة تداول عبر نفق SSH — دروس من الصين

مشكلة البنية التحتية التي تواجهها كل منصة تداول

إذا سبق لك بناء منصة تداول تحتاج إلى خدمة مستخدمين عبر عدة دول، فأنت تعرف المشكلة بالفعل: China Mobile تمنع اتصالات SSH المباشرة بالخوادم الخارجية. لا تحذير، لا رسالة خطأ — فقط انقطاع صامت للاتصال يجعلك تعتقد أن خادمك معطل بينما هو في الواقع سليم.

الإعداد لدينا: محطة الرئيسية تعمل على خادم RackNerd (107.174.186.162) في الولايات المتحدة، لكن كل التطوير يتم من الصين. SSH مباشر؟ محظور. وكيل VPN؟ غير موثوق لبرامج النشر الآلي. الحل الذي توصلنا إليه بعد أسابيع من المحاولات الفاشلة هو سلسلة SSH بسيطة لكنها فعالة.

هندسة خادم القفز JD Cloud

الرؤية الأساسية: China Mobile تمنع SSH الخارجي، لكن الخوادم السحابية المحلية يمكنها الاتصال بالخوادم الخارجية بحرية. لذلك نستخدم خادم JD Cloud (京东云) بنظام Windows (111.228.37.165) كخادم قفز:

الكمبيوتر المحلي (الصين)
  → خادم القفز JD Cloud (IP محلي، 111.228.37.165)
    → خادم RackNerd الهدف (IP خارجي، 107.174.186.162)

في Python باستخدام Paramiko، يبدو هذا كالتالي:

import paramiko

# الخطوة 1: الاتصال بـ JD Cloud
ssh_jd = paramiko.SSHClient()
ssh_jd.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh_jd.connect('111.228.37.165', port=22, username='root', password='***')

# الخطوة 2: فتح قناة TCP مباشرة عبر JD Cloud إلى RackNerd
channel = ssh_jd.get_transport().open_channel(
    'direct-tcpip', 
    ('107.174.186.162', 22),  # الهدف
    ('127.0.0.1', 22)         # المصدر
)

# الخطوة 3: الاتصال بـ RackNerd عبر القناة
ssh_rn = paramiko.SSHClient()
ssh_rn.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh_rn.connect('107.174.186.162', port=22, username='root', password='***', sock=channel)

# الآن ssh_rn متصل — استخدم sftp, exec_command, إلخ.
sftp = ssh_rn.open_sftp()
sftp.put('local_file.html', '/var/www/blog/tools/file.html')

استدعاء open_channel('direct-tcpip', ...) هو السحر — فهو يطلب من خادم JD Cloud توجيه اتصال TCP إلى الهدف، مما ينشئ نفق SSH بشكل فعال دون الحاجة إلى تكوين إعادة توجيه المنفذ على خادم القفز.

مشكلة سرعة النشر

بمجرد عمل سلسلة SSH، المشكلة التالية هي السرعة. مع وجود أكثر من 200 ملف HTML للنشر، رفعها واحدًا تلو الآخر عبر نفق SSH يستغرق وقتًا طويلاً. محاولتنا الأولى رفعت الملفات بشكل فردي — انتهت المهلة عند 300 ثانية بعد معالجة نصف الملفات فقط.

الحل: ضغط كل شيء في ملف tar.gz واحد، رفعه مرة واحدة، فكه على الخادم:

import tarfile, os

# الضغط محليًا
with tarfile.open('upload.tar.gz', 'w:gz') as tar:
    for f in os.listdir('tools/'):
        if f.endswith(('.html', '.json')):
            tar.add(f'tools/{f}')

# رفع ملف واحد
sftp.put('upload.tar.gz', '/tmp/upload.tar.gz')

# التحقق من تطابق الحجم (أمر بالغ الأهمية — رأينا رفعًا مبتورًا)
assert sftp.stat('/tmp/upload.tar.gz').st_size == os.path.getsize('upload.tar.gz')

# فك الضغط على الخادم
ssh_rn.exec_command('cd /var/www/blog && tar xzf /tmp/upload.tar.gz')

هذا قلص وقت النشر من 5 دقائق إلى أقل من 30 ثانية.

فخ ذاكرة التخزين المؤقت لـ Cloudflare CDN

بعد النشر، كنا نتحقق بجلب الرابط المباشر — وأحيانًا كان المحتوى القديم لا يزال يظهر. الجاني: ذاكرة التخزين المؤقت لـ Cloudflare CDN، حتى عندما تم تكوين Nginx باستخدام Cache-Control: no-cache.

الجزء الصعب: إعداد DNS لـ gfil-lab.com كان على "DNS-only" (السحابة الرمادية)، وليس "Proxied" (السحابة البرتقالية). هذا يعني أن Cloudflare لا ينبغي أن تخزن أي شيء — الطلبات تذهب مباشرة إلى خادم Nginx الخاص بنا. لكن بعض مزودي خدمة الإنترنت والبروكسيات المؤسسية لا تزال تخزن الردود. الحل:

# إضافة رؤوس كسر التخزين المؤقت في إعدادات Nginx
location ~* \.(html|xml|txt|md)$ {
    add_header Cache-Control "no-cache, must-revalidate" always;
}

# عندما تحتاج إلى تحديث إجباري، أضف معامل استعلام
# https://gfil-lab.com/tools/entity.html?v=2

لكن الدرس الحقيقي: عندما يكون ملفك المحلي صحيحًا لكن الموقع المباشر يعرض محتوى قديمًا، لا تفترض فشل النشر. تحقق من الخادم مباشرة أولاً (curl http://localhost/tools/entity.html من الخادم نفسه) قبل قضاء ساعات في تصحيح نشر نجح بالفعل.

الدرس: تحقق دائمًا من جانب الخادم أولاً

أهدرنا دورة تدقيق كاملة معتقدين أن النشر فشل. قام مراجع Claude بفحص الرابط المباشر ووجد محتوى قديمًا. أعدنا النشر. نفس النتيجة. اتضح أن الخادم كان لديه الملفات الصحيحة طوال الوقت — المحتوى القديم كان قادمًا من طبقة تخزين مؤقت وسيطة.

قائمة التحقق الخاصة بنا الآن:

1. التحقق من جانب الخادم: curl http://localhost/path من الخادم — يتجاوز كل التخزين المؤقت
2. التحقق الخارجي: curl https://domain/path من الخارج — يختبر ما يراه المستخدمون
3. تجزئة المحتوى: مقارنة سلاسل محددة (مثل grep -c "liudapao880807-arch" /var/www/blog/tools/entity.html) بدلاً من مقارنة الملفات بالكامل

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

جرب أدواتنا المجانية

هذه البنية التحتية تدعم 22 أداة حاسبة تداول مجانية بأربع لغات. جرب حاسبة حجم الصفقة — تتعامل مع الفوركس، الذهب، العملات الرقمية، والمؤشرات بقيم pip صحيحة لأكثر من 30 أداة.