نشر موقع ServBay على الإنترنت (بروكسي عكسي، نفق وتحويل المنافذ)

بالإضافة إلى التطوير المحلي، يقوم العديد من المستخدمين بنشر ServBay على خادم دائم (مثل Mac mini في مركز بيانات، جهاز مكتب ثابت أو خادم Windows)، لاستخدامه كـخادم مصدر خلفي (origin server)، ثم نشر الموقع للعامة على الإنترنت. هذا الحل عملي تمامًا في بيئات الإنتاج—وهناك عدد كبير من المستخدمين يعتمدونه بثبات.

لكن إذا لم تكن على دراية بالسلوك الافتراضي للشبكة في ServBay، قد تواجه مشاكل في البروتوكولات أو الشهادات أو رأس الـ Host أو جوانب الشبكة الأخرى مما يؤدي إلى ظاهرة "كل شيء يعمل محليًا ولكن الوصول من الإنترنت لا يعمل". هذا الدليل مُخصص لكل من يريد استخدام ServBay كخادم مصدر خلفي؛ سنشرح أولاً السلوك الافتراضي، ثم نقدم الحلول بالترتيب: النفق المدمج → البروكسي العكسي (الموصى به) → تحويل المنافذ، وأخيرًا قائمة فحص لحل الأعطال.

المنصات المدعومة

هذا الدليل ينطبق على ServBay لنظام macOS و ServBay لنظام Windows. وضعية البروتوكول وسلوك الاستماع ومسارات الشهادة متطابقة في كلا النظامين، ويختلف فقط مجلد التثبيت الأساسي (macOS: /Applications/ServBay، Windows غالبًا: C:\ServBay). الخادم الافتراضي فقط يختلف: macOS يستخدم Caddy افتراضيًا وWindows يستخدم Nginx افتراضيًا، ويمكن التبديل لأي منهما (Nginx/Apache/Caddy).

افهم أولاً السلوك الافتراضي لشبكة ServBay

الأخطاء في الوصول من الإنترنت غالبًا ما تعود لسوء فهم أحد السلوكيات الافتراضية التالية:

1. افتراضيًا، مواقعك تعمل بنمط HTTP & HTTPS. ففي هذا الوضع، أي طلب عبر HTTP (المنفذ 80) سيتم إعادة توجيهه تلقائيًا (301) إلى HTTPS (المنفذ 443). هذا مقصود لاتباع المعايير الحديثة—ينبغي عليك الالتزام بـ HTTPS بدلاً من العودة إلى 80 غير المشفر.
2. تحديد الموقع والشهادة يتم عبر SNI في HTTPS. إذا كان لديك عدة مواقع على نفس ServBay، يتم التمييز بينها في handshake عبر حقل SNI (يساوي اسم النطاق). عند العودة عبر HTTPS من البروكسي العكسي، يجب إرسال SNI الصحيح وإلا ستحصل على موقع افتراضي أو شهادة خاطئة.
3. الخادم يستمع افتراضيًا لكل واجهات الشبكة (0.0.0.0) على المنافذ الافتراضية HTTP 80 / HTTPS 443، ما يعني أنه متاح للاستقبال من خارج الجهاز عادة دون تغيير.
4. شهادة HTTPS المحلية موقعة من ServBay CA. لدى ServBay CA داخلي (يظهر غالبًا كـ ServBay User CA - ECC Root في سلسلة الشهادات) يُوقع الشهادات لمواقعك. متصفحات الضيوف من الإنترنت لن تثق به بالطبع—لكن يكفي أن يثق بروكسيك العكسي بهذه CA أو يتجاوز التحقق ، ولا داعي للتقديم على شهادة عامة للوصلة بين البروكسي وServBay.

خطأ شائع: HTTP & HTTPS + تحويل المنفذ 80 فقط

إذا احتفظ الموقع بنكهة HTTP & HTTPS وقمت بتحويل المنفذ 80 فقط دون معالجة 443: يطلب العميل http://domain → يعيد ServBay توجيهه لـ https://domain (301) → يحاول العميل الاتصال بـ 443 → لا يوجد رد → فشل في الوصول. المتصفح وHSTS قد يخزنان الـ301، ما يُعقّد التشخيص.

الحل ليس العودة لمنفذ HTTP 80، بل جعل HTTPS فعالًا بشكل كامل (انظر حلول البروكسي العكسي أدناه).

كيفية اختيار طريقة النشر

الطريقة	الشرح	السيناريو المناسب
النفق المدمج (frpc / cloudflared إلخ)	مدمجة مع ServBay، تنشئ وصلة عكسية خارجية دون الحاجة لـ IP خارجي أو فتح منافذ	لا يوجد لديك IP خارجي، أو في شبكة منزلية/NAT، أو تريد النشر بأسرع ما يمكن
بروكسي عكسي أمامي (موصى به)	Nginx، HAProxy، Caddy، Traefik يتلقون زيارات الإنترنت ويديرون الشهادات، ثم يعودون إلى ServBay عبر HTTPS	لديك مدخل خارجي، أو تريد نقطة دخول موحدة، أو توحد الشهادات، أو تدير عدة مصادر خلفية
تحويل المنافذ (NAT)	الراوتر ينقل المنفذ الخارجي مباشرة إلى ServBay	لديك مصدر خلفي واحد، وتعرف ما تفعل بالضبط

الطريقة الأولى: النفق المدمج (الأسهل – بدون IP خارجي)

إذا لم يكن لديك IP خارجي أو لا تريد التعقيدات مع البروكسي والشهادات، فإن خدمات النفق المدمجة في ServBay هي الحل الأسرع. هذه الخدمات تنشئ وصلة من الجهاز نفسه إلى الإنترنت، متجنبة بذلك مشاكل NAT، IPv6، تحويل المنافذ والتحقق من الشهادات.

• Cloudflare Tunnel (cloudflared) — ينشر موقعك محلياً على الإنترنت عبر شبكة Cloudflare، مع HTTPS موثوق بشكل تلقائي ودون فتح أي منفذ. يناسب من يحتاج دومين خارجي مستقر + CDN أو WAF.
• frp (frpc) — يربط بخادم frps الذي تديره بنفسك لتحكم كامل.
• ngrok / Pinggy — ينشئ روابط إنترنت مؤقتة بسرعة للمشاركة والعروض ودمج الـ Webhook.

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

الطريقة الثانية: بروكسي عكسي أمامي مع العودة عبر HTTPS (موصى به)

هذا هو الحل الموصى به للإنتاج: البروكسي العكسي يقدّم HTTPS موثوق للعالم، ويرجع إلى ServBay أيضًا عبر HTTPS (حافظ على نمط الموقع HTTP & HTTPS) لتحقيق تشفير تام الطرفين.

لماذا يُنصح بالعودة عبر HTTPS بدل HTTP

الكثير من الشروحات القديمة تكتفي بجعل المصدر الخلفي يعمل عبر HTTP، والبروكسي يرجع بالـ HTTP فقط. نحن لا ننصح بذلك إلا إذا كان لديك مبررات قوية وتعي خطورة ذلك:

• تشفير تام للطرفين: حتى لو كان البروكسي وServBay على شبكة داخلية، تظل البيانات مشفرة بالكامل، ما يحمي من التجسس أو التلاعب الداخلي.
• الاستفادة من بروتوكولات حديثة: إبقاء HTTPS يسمح للبروكسي بتفعيل HTTP/2، والحصول على مزايا مثل تعدد الاتصالات وضغط الرؤوس وتوفير الأداء؛ ولو عدت لـ 80 ستعلق مع الأساليب القديمة.
• تجنب مشاكل التخفيض للبروتوكول الأقدم: العودة لـ HTTP تعني مواجهة مشاكل مع 301 أو HSTS أو إعادة إنتاج الروابط أو تدوير عمليات إعادة التوجيه.
• الثقة بـ ServBay CA سهلة التنفيذ: لا بأس من التوقيع الذاتي—يكفي أن تجعل بروكسيك يثق بالـ CA الخاصة بـ ServBay أو يتجاوز التحقق؛ إعداد لمرة واحدة ويستمر.

طريقة HTTP 80 مذكورة في الطريقة الثالثة، ولا ننصح بها إلا في حالات خاصة جدًا وبعلم تام.

عناصر مهمة لجميع البروكسيات

هذه النقاط مهمة لأي بروكسي من الأنواع الأربعة؛ المثال التالي استعمال: نطاق خارجي example.com، المصدر الخلفي على 192.168.1.115، المنفذ 443، والموقع بنمط HTTP & HTTPS.

1. العودة عبر HTTPS: البروكسي يجب أن يشير إلى https://192.168.1.115:443.
2. إرسال SNI الصحيح: يجب أن يكون SNI مساويًا لدومين موقع ServBay (example.com)، وإلا لن يحصل على الشهادة أو الموقع الصحيح.
3. الثقة بـ ServBay CA (موصى بها) أو تجاوز التحقق (سهل): طريقة الحصول عليها أسفله.
4. تمرير رأس Host دون تعديل: أي Host: example.com ليسمح بمطابقة server_name في ServBay.
5. تمرير الرأس X-Forwarded-Proto: https: يعلم التطبيقات الخلفية أن الطلب الأصلي كان عبر https حتى لا تخلق روابط http أو دورات توجيه.
6. دعم IPv4/IPv6 بشكل متسق: انظر دعم IPv4/IPv6.

أين تجد شهادة CA الخاصة بـ ServBay (لتوثيق العودة الخلفية)

ملف شهادة CA الجذرية في مسار التثبيت:

• macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
• Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (حسب مسارك)

انسخ هذا الملف (.crt) إلى سيرفر البروكسي (مثل /etc/nginx/servbay-ca/)، واستعمله كـ CA موثوقة للعودة الخلفية.

حول سلسلة الشهادة

هيكلية شهادات ServBay هي "CA جذرية + CA وسيطة"؛ شهادة الموقع تُوقع من CA وسيطة. إذا لم يتم قبول الشهادة عند توثيق العودة عبر CA الجذرية فقط، اجمع الشهادتين (الجذرية + الوسيطة) في ملف CA bundle واحد ليستعملها البروكسي كـ CA موثوقة؛ أو استخدم أولاً طريقة "تجاوز التحقق" للاختبار، ثم احول للتوثيق الصارم.

Nginx بروكسي عكسي (العودة عبر HTTPS)

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # لتفعيل دعم IPv6 إن لزم
    server_name example.com;

    # شهادة موثوقة للعالم (مثلاً Let's Encrypt)
    ssl_certificate     /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    location / {
        proxy_pass https://192.168.1.115:443;                 # العودة عبر HTTPS

        # --- مهم: SNI وتوثيق العودة ---
        proxy_ssl_server_name on;                             # أرسل SNI
        proxy_ssl_name        example.com;                    # SNI = دومين الموقع
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # فعّل التوثيق بعد الثقة بـ ServBay CA
        proxy_ssl_verify_depth 2;                             # جذر + وسيط
        # الحل البسيط (بدون CA): proxy_ssl_verify off;

        # --- مهم: تمرير Host والبروتوكول ---
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# إعادة توجيه HTTP إلى HTTPS (من خلال البروكسي)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

HAProxy بروكسي عكسي (العودة عبر HTTPS)

frontend fe_web
    bind :80
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem
    http-request redirect scheme https unless { ssl_fc }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    default_backend be_servbay

backend be_servbay
    option forwardfor
    http-request set-header Host example.com
    # العودة عبر HTTPS: ssl + SNI + التوثيق
    server servbay1 192.168.1.115:443 ssl sni str(example.com) \
        verify required ca-file /etc/haproxy/servbay-ca/servbay-ca-bundle.crt
    # الحل البسيط: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Caddy بروكسي عكسي (العودة عبر HTTPS)

يقوم Caddy تلقائيًا بطلب الشهادة الخارجية وتحديثها لـ example.com. الوضع الافتراضي يمرر Host وX-Forwarded-*:

example.com {
    reverse_proxy https://192.168.1.115:443 {
        header_up Host {host}
        transport http {
            tls_server_name example.com                                  # SNI
            tls_trusted_ca_certs /etc/caddy/servbay-ca/servbay-ca-bundle.crt
            # الحل البسيط: tls_insecure_skip_verify
        }
    }
}

Traefik بروكسي عكسي (العودة عبر HTTPS)

مثال إعداد ديناميكي من file provider:

# traefik-dynamic.yml
http:
  routers:
    servbay:
      rule: "Host(`example.com`)"
      entryPoints:
        - websecure
      service: servbay
      tls:
        certResolver: letsencrypt
  services:
    servbay:
      loadBalancer:
        passHostHeader: true                 # تمرير Host
        servers:
          - url: "https://192.168.1.115:443" # العودة عبر HTTPS
        serversTransport: servbay-tls

serversTransports:
  servbay-tls:
    serverName: example.com                  # SNI
    rootCAs:
      - /etc/traefik/servbay-ca/servbay-ca-bundle.crt
    # الحل البسيط: insecureSkipVerify: true

الطريقة الثالثة: تحويل المنافذ (NAT)

إذا كان لديك مصدر خلفي واحد، يمكن إعداد تحويل المنافذ (Port Forwarding) على الراوتر/البوابة إلى جهاز ServBay (مثلاً داخليًا 192.168.1.115).

موصى به: تحويل المنفذ 443، والحفاظ على HTTPS

1. إعداد تحويل المنفذ على البوابة: المنفذ الخارجي 443 → 192.168.1.115:443 (وأيضًا 80 للتوجيه).
2. إضافة سجل A في DNS للإشارة للـ IPv4 الخارجي.
3. احتفظ بنموذج الموقع على HTTP & HTTPS. بما أن الضيوف يتصلون مباشرة بجهاز ServBay، ستحتاج إلى شهادة عامة موثوقة لهذا النطاق (راجع أدناه).
4. تأكد من دعم IPv4/IPv6 بشكل متسق (انظر أدناه).

نشر HTTP 80 دون تشفير (في حالات خاصة فقط)

تحويل المنفذ 80 فقط وتغيير الموقع لوضع HTTP يفقدك مزايا HTTPS وHTTP/2، وقد يتعارض مع HSTS والذاكرة المؤقتة. لا يُنصح بها إلا في حالات يستحسنها المستخدم ويدرك الآثار تمامًا. إذا لزم: غيّر الموقع صراحة لـ HTTP فقط (لتجنب 301 إلى منفذ 443 غير مفتوح) وحوّل المنفذ 80 فقط.

دعم IPv4 / IPv6 بشكل متسق

من أكثر أسباب عدم استقرار الانترنت شيوعًا. إذا كان لنطاقك سجل A (IPv4) وسجل AAAA (IPv6)، سيحاول العميل أحيانًا تفضيل IPv6 (Happy Eyeballs). إذا كنت لم تعِد توجيه/بروكسي لـ IPv6، ستفشل زيارات IPv6. أمامك خياران:

• استعمل IPv4 فقط: تأكد أن نتيجة dig AAAA yourdomain +short فارغة واحتفظ بسجل A فقط.
• ادعم IPv6 كذلك: أعد توجيه المنفذ وأضف استماع [::] في البروكسي، وأكد وصول الخلفية عبر IPv6 أيضًا.

قائمة فحص الأعطال في الوصول من الإنترنت

إذا كنت تواجه مشاكل مثل (عدم التحميل، المهلة، أخطاء شهادة، أو وصول لموقع خاطئ)، اتبع التالي (مثال: النطاق example.com والجهاز 192.168.1.115):

1. هل هناك إعادة توجيه (301) لمنفذ 443 غير مفتوح؟

   curl -I http://example.com

   إذا عاد 301 مع Location: https://... وأنت لم تضبط 443 — هذه هي المشكلة. عليك تفعيل HTTPS (موصى به) أو تغيير الموقع لوضع HTTP فقط.

2. هل سبب المشكلة IPv6؟

   curl -4 -I https://example.com     # IPv4 فقط
   curl -6 -I https://example.com     # IPv6 فقط
   dig A example.com +short
   dig AAAA example.com +short        # وجود AAAA بدون دعم IPv6 → أزِل السجل أو أدعم IPv6

3. هل SNI/الشهادة صحيحة في العودة الخلفية؟ (في حالة العودة عبر HTTPS)

   curl -I --resolve example.com:443:192.168.1.115 https://example.com \
        --cacert /path/servbay-ca-bundle.crt

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

4. هل الطلبات تصل إلى ServBay؟ راقب سجل الوصول إلى سيرفرك في ServBay (من ميزة "عرض الملفات"). إذا لم يظهر الطلب، المشكلة في الشبكة أو البوابة أو البروكسي.

5. هل رأس Host صحيح؟ (في البروكسي العكسي على مستوى L7)

   curl -k -I -H "Host: example.com" https://192.168.1.115/

   إذا نجح الاتصال المباشر وفشل عبر البروكسي — لم يقم بتمرير Host.

الشهادات والأمان

• رابطة العودة الخلفية: عند العودة عبر HTTPS من البروكسي إلى ServBay، اجعل البروكسي يثق بشهادة CA الخاصة بـ ServBay (ServBay-Private-CA-ECC-Root.crt) وأدرج الشهادة الوسيطة إذا لزم.
• شهادة الواجهة أمام الزوار: يجب أن تكون شهادة خارجية موثوقة دوليًا. البروكسيات مثل Caddy/Traefik تصدر الشهادة وتحدثها أوتوماتيكيًا؛ في حالة تحويل المنافذ تحتاج ضبط شهادة عامة مباشرة على ServBay (راجع كيفية طلب شهادة ACME). الشهادة الافتراضية من ServBay صالحة فقط للاستخدام المحلي/الداخلي—الضيوف الخارجيون لن يثقوا بها.
• لا تفتح منصات قواعد البيانات للعامة: لا تفتح منافذ MySQL وRedis وMemcached وما سواها عند نشر Web للخارج. راجع الوصول عبر الشبكة المحلية لأهم النصائح الأمنية.
• الجدار الناري: افتح فقط المنافذ التي تحتاجها واغلق البقية تمامًا.

الأسئلة الشائعة (FAQ)

• س: الموقع يعمل محليًا وليس من الإنترنت، هل السبب DNS؟
  • ج: غالبًا لا. المشكلات الأكثر شيوعًا هي: إعادة توجيه 301 إلى منفذ 443 غير معد، SNI/الشهادة خطأ، Host ليس مُمرّرًا، أو عدم تساوي دعم IPv4/IPv6. تحقق من قائمة الفحص أعلاه.
• س: هل يجب العودة إلى HTTP 80 ليعمل البروكسي؟
  • ج: لا إطلاقًا. يُوصى دائمًا بالاحتفاظ على وضع HTTP & HTTPS، وأن يعود البروكسي عبر HTTPS ويثق بـ ServBay CA أو يتجاوز التحقق مؤقتًا، لتحصل على التشفير الكامل ودعم HTTP/2.
• س: يظهر خطأ شهادة أو موقع غير مطابق مع العودة الخلفية من البروكسي؟
  • ج: تحقق أنك ترسل SNI صحيح (= اسم الموقع)، وأن البروكسي يثق بـ ServBay CA (أضف الوسيطة إذا لزم). للتحقق سريعًا جرب تجاوز التحقق مؤقتًا ثم فعّل التحقق بعد نجاح الاتصال.
• س: هل من الموثوق أن أنشر ServBay كخادم خلفي إنتاجي؟
  • ج: نعم. الكثيرون ينشرون ServBay على Mac mini أو خوادم Windows في مراكز البيانات ويخدمون بنجاح. الأهم هو ضبط البروتوكول المناسب، SNI، Host، الثقة بالشهادة ودعم IPv4/IPv6 المتسق.
• س: لا أملك IP خارجي، ما العمل؟
  • ج: استخدم الطريقة الأولى: النفق المدمج (cloudflared/frpc)، ولا حاجة لديك لا IP ولا لتحويل المنافذ.

الخلاصة

نشر ServBay كخادم مصدر خلفي على الإنترنت خيار عملي بالكامل. الطريق الأفضل هو الاحتفاظ بنمط الموقع على HTTP & HTTPS، واستخدام بروكسي عكسي للعودة عبر HTTPS، إرسال SNI الصحيح والثقة بشهادة ServBay CA، لتحصل بسهولة على تشفير طرف-لطرف ودعم HTTP/2 وغيرها من التقنيات الحديثة. إذا لم يكن لديك IP خارجي، يوفر لك النفق المدمج (cloudflared/frpc) حلاً مبسطًا وقويًا. خيار تحويل المنافذ يناسب من هم على دراية تامة بما يقومون به. عند مواجهة مشاكل في الوصول، استخدم قائمة الفحص لحلها سريعًا—فغالبًا ما ترتبط المشكلة بإعدادات البروتوكول، SNI/الشهادة، Host أو دعم IPv4/IPv6.