إعداد Cloudflare Tunnel على VPS بلا فتح منافذ

ما الذي يفعله Cloudflare Tunnel، وما يعنيه فعلاً عدم فتح منافذ

يضع Cloudflare Tunnel عميلاً خفيفاً يُسمّى cloudflared على VPS لديك. يفتح هذا العميل اتصالاً صادراً إلى Cloudflare ويحافظ عليه مفتوحاً. تصل الطلبات الموجّهة إلى اسم المضيف لديك إلى الحافة الخاصة بـCloudflare، ثم تُمرَّر عبر ذلك الاتصال القائم، لذلك لا يحتاج أي شيء إلى الاتصال بالخادم من الداخل.

الخطوة التي لا تصل إليها معظم الأدلة: تثبيت النفق لا يغلق أي منفذ. إذا ظل المنفذان 80 و443 مفتوحين في جدارك الناري، وظل تطبيقك يستمع على 0.0.0.0، فقد أضفت طريقة دخول ثانية بدلاً من استبدال الطريقة الأولى. يظل عنوان IP الخاص بالخادم الأصلي قابلاً للوصول، وأي شخص يعثر عليه سيتجاوز Cloudflare ويتصل مباشرة بالخادم. إغلاق هذين المنفذين خطوة يدوية، وهي الخطوة التي تجعل كل ما سبق مفيداً.

يحتاج cloudflared إلى اتصال صادر يصل إلى region1.v2.argotunnel.com وregion2.v2.argotunnel.com عبر المنفذ 7844. ويستخدم UDP لبروتوكول QUIC، ثم ينتقل إلى TCP باستخدام HTTP/2 عند الحاجة. إذا كانت الشبكة تفرض تصفية على الاتصالات الصادرة، فاسمح بالبروتوكولين، أو أجبِر المسار القائم على TCP باستخدام --protocol http2.

قبل أن تبدأ

• نطاق مضاف مسبقاً إلى حساب Cloudflare، وتخدم خوادم أسماء Cloudflare منطقة النطاق. يكتب cloudflared tunnel route dns السجلات في هذه المنطقة، لذلك يجب أن تكون المنطقة موجودة أولاً.
• السماح بالاتصالات الصادرة على المنفذ 7844 من VPS، عبر UDP وTCP.
• تطبيق يستمع محلياً بالفعل، حتى لو كان يستمع فقط على python3 -m http.server 8080 للاختبار الأول.
• وجود sudo على الخادم، وفتح جلسة SSH ثانية قبل تعديل الجدار الناري.

ثبّت cloudflared على Ubuntu أو Debian

توفّر Cloudflare حزمة .deb مع كل إصدار cloudflared، لذلك يتطلب التثبيت عملية تنزيل واحدة واستدعاء dpkg واحداً.

curl -fsSL -o /tmp/cloudflared.deb \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i /tmp/cloudflared.deb
cloudflared --version

شغّل dpkg --print-architecture أولاً إذا لم تكن متأكداً من بنية النظام. في ARM ذي 64 بت، ينتهي اسم الملف بـ arm64 بدلاً من amd64، ولا يتغير أي شيء آخر. إن طباعة cloudflared --version لسلسلة إصدار هي التأكيد الوحيد الذي تحتاج إليه قبل المتابعة.

تُثبَّت الحزمة بهذه الطريقة خارج مسار التحديث في apt، لذلك لن ينقلها apt-get upgrade إلى إصدار أحدث، وستصبح تحديثاتها مسؤوليتك. يجلب sudo cloudflared update أحدث إصدار ويستبدل الملف التنفيذي في مكانه؛ وبعد إنشاء الخدمة، شغّل sudo systemctl restart cloudflared لكي تصبح العملية قيد التشغيل هي الملف التنفيذي الجديد. أدرج ذلك في الجدول نفسه المستخدم لبقية عمليات التصحيح، لأن برنامج tunnel daemon يواجه الإنترنت حتى وإن كان لا يفتح أي منفذ.

سجّل الدخول وأنشئ نفقاً باسم

cloudflared tunnel login

على VPS بلا واجهة رسومية، لا يفتح أي متصفح. لذلك انسخ URL المعروض والصقه في المتصفح على حاسوبك المحمول، ثم اختر المنطقة. عند اكتمال العملية، يصبح ~/.cloudflared/cert.pem موجوداً.

cert.pem هو بيانات اعتماد حسابك. ويمنح الإذن لإنشاء الأنفاق، وكتابة سجلات DNS في تلك المنطقة، وحذف الأنفاق. لا يستخدمه النفق قيد التشغيل مطلقاً. تعامل معه مثل كلمة مرور، لأن نسخة واحدة من ذلك الملف تكفي لتمكين أي شخص من نشر أسماء مضيفين جديدة على نطاقك.

cloudflared tunnel create homelab

تعرض العملية الناجحة السطرين أدناه، وتكون UUID الموجودة فيهما هي القيمة التي ستلصقها في ملف الإعداد.

Tunnel credentials written to /home/you/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.
Created tunnel homelab with id 6ff42ae2-765d-4adf-8112-31c55c1551ef

ملف JSON هذا هو هوية النفق، وهو بيانات الاعتماد الوحيدة التي تحتاج إليها الخدمة قيد التشغيل. يمكن لأي شخص يملك هذا الملف التسجيل باعتباره نفقك وتلقي حركة الشبكة الخاصة بك. لا توجد طريقة لتدويره بمفرده؛ إذ يعني إبطاله cloudflared tunnel delete homelab وإنشاء نفق جديد.

ضع ملف بيانات الاعتماد في مسار مناسب

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

sudo install -d -m 700 -o root -g root /etc/cloudflared
sudo install -m 600 -o root -g root \
  ~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json \
  /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
rm ~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
sudo ls -l /etc/cloudflared
cloudflared tunnel list

يجب أن يعرض ls -l القيمة -rw------- root root في ملف JSON. يقرأ cloudflared tunnel list القيمة cert.pem، لذلك سيواصل العمل، ويجب أن يطبع اسم النفق وUUID الخاص به وعدد الاتصالات الحالية التي يحتفظ بها.

اكتب config.yml بقواعد ingress الفعلية

اكتب الإعداد في /etc/cloudflared/config.yml، وليس في المجلد الرئيسي الخاص بك. السبب هو أن cloudflared service install ينسخ أي إعداد يجده إلى /etc/cloudflared/config.yml، ثم يثبت --config /etc/cloudflared/config.yml داخل وحدة systemd. إذا أنشأت الملف في ~/.cloudflared/config.yml، فستكون تلك النسخة لقطة لمرة واحدة. أي تعديل لاحق على النسخة الموجودة في المجلد الرئيسي لن يغيّر شيئاً، وستواصل الخدمة تقديم القواعد القديمة من دون أي تحذير. إنشاء الملف في موقعه الفعلي يزيل المشكلة بالكامل.

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
loglevel: info

ingress:
  - hostname: app.example.com
    service: http://127.0.0.1:8080
  - hostname: files.example.com
    service: http://127.0.0.1:8081
  - hostname: grafana.example.com
    path: ^/api/
    service: http://127.0.0.1:3000
  - service: http_status:404

تُقرأ القواعد من الأعلى إلى الأسفل، وتفوز أول قاعدة مطابقة. القاعدة التي لا تحتوي على hostname تطابق كل أسماء المضيفين، لذلك يجب وضع قاعدة المطابقة الشاملة في النهاية. إذا حذفتها، يُرفض الإعداد مع The last ingress rule must match all URLs (i.e. it should not have a hostname or path filter). http_status:404 خدمة مضمّنة تستجيب بالرمز 404 ولا تنفذ أي شيء آخر. وجودها مهم: من دونها، قد ينتهي طلب موجّه إلى اسم مضيف لم تقصد نشره إلى أي قاعدة فعلية تصادف أنها الأخيرة.

استخدم 127.0.0.1 في عنوان service: بدلاً من localhost. في Ubuntu، يحل localhost أولاً إلى ::1، ويرفض تطبيق يستمع إلى loopback الخاص بـIPv4 فقط هذا الاتصال. يكون سطر السجل dial tcp [::1]:8080: connect: connection refused، ويرى الزائر خطأ 502.

استخدام http:// العادي صحيح هنا لأن الاتصال لا يغادر الجهاز. استخدم https:// فقط عندما يصر التطبيق المحلي على استخدام TLS (أمن طبقة النقل)، وتوقع x509: certificate is valid for example.com, not localhost عندما لا تطابق شهادته الاسم الذي اتصلت به. أصلح ذلك باستخدام originServerName ضمن originRequest، أو اقبل المخاطرة باستخدام noTLSVerify: true.

تحقق من القواعد قبل بدء أي شيء:

sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress validate
sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress rule https://app.example.com/login

يُبلغ ingress validate بأن الإعداد صالح، أو يحدد القاعدة التي تسببت في المشكلة. يأخذ ingress rule عنوان URL واحداً ويطبع أول قاعدة تطابقه. وهذه أسرع طريقة لمعرفة أن تعبير path النمطي لا يطابق ما افترضته.

وجّه DNS إلى النفق

cloudflared tunnel route dns homelab app.example.com
cloudflared tunnel route dns homelab files.example.com
cloudflared tunnel route dns homelab grafana.example.com

تنشئ كل عملية استدعاء سجل CNAME ممرَّراً يشير إلى 6ff42ae2-765d-4adf-8112-31c55c1551ef.cfargotunnel.com. لا يُحلّ هذا الهدف إلا داخل شبكة Cloudflare، لذلك تكون إجابة DNS العامة لاسم المضيف عبارة عن عنوان تابع لـCloudflare، ولا يظهر عنوان IP الخاص بـVPS فيها. لا يزال wildcard hostname في config.yml يتطلب سجل DNS مطابقاً لكل اسم تستخدمه فعلياً.

عندما يكون السجل موجوداً مسبقاً، يفشل الأمر كما يلي:

Failed to add route: code: 1003, reason: Failed to create record app.example.com with err An A, AAAA, or CNAME record with that host already exists.

يكون هذا السجل الموجود مسبقاً في الغالب سجل A القديم الذي يشير إلى عنوان IP العام الخاص بـVPS، وهو السجل الذي تريد حذفه تحديداً. احذفه من لوحة تحكم Cloudflare، ثم شغّل الأمر مرة أخرى. إبقاؤه يعني أن DNS سيواصل نشر عنوان IP الأصلي، ولذلك لن يخفي النفق شيئاً.

ثبّته كخدمة ليعمل بعد إعادة التشغيل

شغّله مرة واحدة في الواجهة الأمامية، لأن قراءة الخطأ في الطرفية الخاصة بك أسهل بكثير من قراءته في السجل.

sudo cloudflared --config /etc/cloudflared/config.yml tunnel run homelab

تُسجّل البداية السليمة عدة أسطر Registered tunnel connection، سطراً واحداً لكل موقع طرفي، ولكل منها connIndex الخاص بها. افتح أحد أسماء المضيفين في متصفح، وتحقق من أن قواعد الدخول توجّهك إلى المكان المتوقع، ثم أوقفه باستخدام Ctrl-C.

sudo cloudflared --config /etc/cloudflared/config.yml service install
systemctl status cloudflared

ينشئ ذلك /etc/systemd/system/cloudflared.service مع cloudflared-update.service وcloudflared-update.timer، ثم يشغّل systemctl enable cloudflared.service وsystemctl start cloudflared.service نيابةً عنك. يمثّل enable الجزء المهم هنا، لأنه يعيد تشغيل النفق بعد إعادة التشغيل. قيمة ExecStart في الوحدة هي cloudflared --no-autoupdate --config /etc/cloudflared/config.yml tunnel run، ولذلك فإن مسار الإعداد هذا غير قابل للتغيير.

تظهر في هذه الخطوة 3 حالات فشل برسائل محددة. تعني possible conflicting configuration in /home/you/.cloudflared/config.yml and /etc/cloudflared/config.yml أن الملفين موجودان وأن cloudflared يرفض التخمين: احذف الملف الذي لا تريده. وتعني configuration file ... must contain entries for the tunnel to run and its associated credentials (tunnel: TUNNEL-UUID, credentials-file: CREDENTIALS-FILE) أن إعدادك يستخدم الاختصار السريع url: بدلاً من مفاتيح النفق المسمّى، ولا يمكن تشغيل هذا الاختصار كخدمة. وتعني cloudflared service is already installed أن وحدة أقدم ما زالت موجودة، ولذلك شغّل sudo cloudflared service uninstall أولاً.

لا توجد إعادة تحميل. بعد تعديل /etc/cloudflared/config.yml، شغّل sudo systemctl restart cloudflared. ثم أثبت عمل إعادة التشغيل بدلاً من افتراضه:

sudo reboot
# once it is back
systemctl is-enabled cloudflared
systemctl is-active cloudflared
journalctl -u cloudflared -n 50 --no-pager
curl -sI https://app.example.com

إن طباعة enabled بواسطة is-enabled وطباعة active بواسطة is-active هما الهدف الكامل من هذا القسم. بعد إنشاء المسارات وتشغيل الخدمة، لا يعود لدى cert.pem أي عمل إضافي على الخادم: rm ~/.cloudflared/cert.pem. وعند إضافة اسم مضيف لاحقاً، يكفي تشغيل cloudflared tunnel login مرة أخرى.

أغلق المنفذين 80 و443، وإلا فسيكون النفق مجرد مسار إضافي

تحتاج إلى إجراء تغييرين، وكلاهما ضروري. تنفيذ أحدهما دون الآخر يترك الخادم الأصلي قابلاً للوصول.

أولاً، اربط التطبيق بعنوان loopback. في nginx يعني ذلك استخدام listen 127.0.0.1:8080; بدلاً من listen 80;، كما هو موضح في شرح إعداد reverse proxy في nginx. وفي Docker Compose يعني ذلك استخدام ports: - "127.0.0.1:8080:80". ينشر الشكل "8080:80" العادي المنفذ على جميع الواجهات، ويكتب Docker قواعد NAT الخاصة به، التي تصل إليها الحزم قبل أن يراها ufw، لذلك لن تمنعها قاعدة deny في ufw. يشرح سبب تجاهل المنافذ التي ينشرها Docker لقواعد ufw هذه المشكلة بالتفصيل.

sudo ss -lntp

يجب أن تعرض كل خدمة نقلتها الآن 127.0.0.1:8080 في عمود Local Address. أما السطر الذي يعرض 0.0.0.0:8080 أو *:8080، فما زال يستمع للاتصالات من أي جهة.

ثانياً، أغلق المنافذ.

sudo ufw status numbered
sudo ufw delete allow 'Nginx Full'
sudo ufw status

احذف قواعد السماح للمنفذين 80 و443 بدلاً من إضافة قواعد deny فوقها، لأن ufw يتوقف عند أول قاعدة مطابقة، وقد تتغلب قاعدة سماح قديمة في موضع أعلى من القائمة. أبقِ قاعدة SSH. يشرح دليل أساسيات جدار ufw الناري بقية مجموعة القواعد. يشغّل معظم موفري VPS أيضاً جداراً نارياً منفصلاً للشبكة في لوحة التحكم الخاصة بهم، وهو ليس ufw، لذلك أغلق المنفذين 80 و443 هناك أيضاً.

تحقق الآن من مكان آخر، لأن curl http://127.0.0.1:8080 على الخادم نفسه لا يثبت شيئاً عن إمكانية الوصول من خارج الشبكة.

# run these from a different machine
nc -vz 203.0.113.10 443
curl -sI https://app.example.com

النتيجة المطلوبة هي nc مرفوض أو منتهي المهلة إلى عنوان IP الخام، مع 200 عبر اسم النطاق. يشرح التحقق من كون المنفذ مفتوحاً فعلاً طرقاً إضافية لاختباره.

النفق وسيلة نقل، وليس وسيلة مصادقة. كل ما تنشره من خلاله يكون قابلاً للوصول العام ما لم تضع تسجيل دخول أمامه، سواء باستخدام Cloudflare Access عند الحافة أو وكيل OAuth2 أمام التطبيق على الخادم. ويحتاج SSH أيضاً إلى إجراء مستقل، لأن النفق لا يغطيه: أبقِ المنفذ 22 مفتوحاً، لكن قيّد الوصول إليه بعناوين المصدر الخاصة بك.

ما الذي يوفّره Cloudflare Tunnel وما تكلفته

الفوائد حقيقية. لا يعود عنوان IP الخاص بخادم المصدر منشوراً، ولا يكون أي منفذ وارد مكشوفاً، ويعمل الإعداد من جهاز لا يملك عنوان IP عاماً على الإطلاق. تتولى Cloudflare أمر الشهادة العامة، لذلك لا يعمل عميل ACME (بيئة إدارة الشهادات تلقائياً) على جهازك. كما تُمتص الهجمات كبيرة الحجم عند الحافة بدلاً من استهلاك حصة النطاق الترددي لديك.

والتكاليف حقيقية بالقدر نفسه. تنهي Cloudflare جلسة TLS عند حافتها؛ إذ يُفك تشفير طلب الزائر هناك ثم يُعاد تشفيره داخل النفق، ولذلك تستطيع Cloudflare قراءة حركة الشبكة. وهذا ما يتيح جدار الحماية والتخزين المؤقت وقواعد Access لديها. ولا يوجد إعداد يعطّل ذلك ما دمت تستخدم وكيلها. إذا كان من غير المقبول أن يطّلع طرف ثالث على بياناتك النصية، فتوقف هنا واختر حلاً آخر.

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

لا تصل إلى اسم مضيف عام من متصفح عادي إلا بروتوكولات HTTP وHTTPS وWebSocket. أما أي بروتوكول TCP آخر، مثل SSH أو RDP (بروتوكول سطح المكتب البعيد) أو خادم ألعاب، فيحتاج إلى برنامج على جانب العميل أيضاً: cloudflared access tcp لإعادة توجيه منفذ محلي، أو عميل WARP. ولا يوجد مسار لهذه البروتوكولات من دون عميل.

تُفرض حدود على أجسام الطلبات عند الحافة، ويُرفض أي تحميل يتجاوز الحد باستخدام HTTP 413 قبل أن يصل إلى تطبيقك. اعتباراً من August 2026، يبلغ هذا الحد 100 MB في خطتي Free وPro، ويكون أعلى في الخطط المدفوعة. لذلك تحقّق من صفحة الحدود الحالية لدى Cloudflare قبل تصميم إعداد يعتمد على رقم محدد. كما تقيّد شروط Cloudflare للخدمة الذاتية استخدام الوكيل أساساً لتقديم الفيديو والملفات الكبيرة الأخرى غير HTML. من المفيد قراءة هذه الشروط قبل توجيه مكتبة وسائط إلى نفق مجاني.

Cloudflare Tunnel، أو نفق SSH عكسي، أو Tailscale Funnel

تعمل الخيارات الثلاثة باتصالات صادرة فقط، ولذلك تعمل من خادم لا يملك منفذاً وارداً ولا عنوان IP عاماً. ويختلف كل خيار منها في الجهة التي تحتفظ بالبيانات بنصها الصريح، واسم المضيف الذي يراه المستخدمون على الإنترنت.

يحتاج نفق SSH عكسي إلى جهاز ثانٍ يملك عنوان IP عاماً، ويصبح ذلك الجهاز نقطة الدخول: تكون الشهادة والـreverse proxy وجدار الحماية عليه مسؤوليتك بالكامل. ولا يفك أي طرف آخر تشفير البيانات. يتطلب هذا الخيار مكونات أكثر، كما يحتاج إلى autossh أو وحدة systemd تتضمن Restart=always قبل أن يستمر عمله بعد انقطاع قصير في الشبكة. يشرح دليل إعداد نفق SSH العكسي خلف CGNAT هذه البنية.

يُعد Tailscale Funnel المقارنة الأقرب. فهو يعمل باتصالات صادرة فقط بالطريقة نفسها، وينتهي TLS على جهازك أنت، ولذلك لا ترى مرحلات Tailscale البيانات بنصها الصريح. لكن المقابل هو أسماء المضيفين والمنافذ: لا يقدّم Funnel الخدمة إلا عبر أسماء تقع ضمن نطاق ts.net الخاص بشبكة tailnet، وفقط على المنافذ 443 و8443 و10000. يشرح الفرق بين Tailscale Serve وFunnel الجانبين.

لذلك اختر بناءً على القيد الفعلي الذي يحد خياراتك. اختر Cloudflare Tunnel عندما يجب أن يصل المستخدمون إلى نطاقك أنت، وتقبل أن Cloudflare يقرأ حركة الشبكة. اختر Tailscale Funnel عندما يكون اسم المضيف ts.net مقبولاً، ولا تريد تسليم البيانات بنصها الصريح إلى proxy. اختر نفق SSH عكسياً عندما تملك خادماً عاماً بالفعل، وتريد استبعاد أي طرف ثالث من المسار بالكامل.

FAQ

هل ما زلت بحاجة إلى إبقاء المنفذ 443 مفتوحاً مع Cloudflare Tunnel؟

لا. يتصل cloudflared من الخارج بـCloudflare عبر المنفذ 7844، وتصل كل الطلبات مجدداً عبر هذا الاتصال، لذلك لا يُستخدم أي منفذ وارد. لكن تثبيت النفق لا يغلق المنافذ تلقائياً. احذف قواعد السماح للمنفذين 80 و443 في ufw، وأغلقهما في جدار الشبكة المنفصل لدى مزود الخدمة، واربط التطبيق بـ127.0.0.1، واحذف أي سجل A متبقٍّ ما زال ينشر عنوان IP الخاص بـVPS. تحقّق باستخدام sudo ss -lntp على الخادم وnc -vz <your-ip> 443 من جهاز مختلف.

لماذا يعرض اسم المضيف لدي Cloudflare Error 1033؟

يعني Error 1033 أن Cloudflare يحتفظ بسجل DNS لاسم المضيف، لكنه لا يجد cloudflared سليماً ومتّصلاً لاستقبال الطلب. إما أن العملية متوقفة، أو أنها تعمل لكنها لا تستطيع الوصول إلى Cloudflare. تحقّق من systemctl status cloudflared وjournalctl -u cloudflared -n 50، ثم تأكد من السماح بالمنفذ الصادر 7844 عبر UDP وTCP معاً، لأن جداراً يحظر UDP وQUIC من دون السماح بالبديل TCP ينتج هذه المشكلة تحديداً. يعرض cloudflared tunnel info homelab الاتصالات التي يراها Cloudflare حالياً، وإذا كانت القائمة فارغة فالعطل من جانبك.

لماذا أحصل على 502 Bad Gateway عبر النفق؟

يعني الخطأ 502 أن cloudflared تم الوصول إليه، لكنه لم يستطع الوصول إلى خدمتك المحلية، لذلك يقع العطل بين هذين الطرفين وليس لدى Cloudflare. اقرأ السجل. يعني dial tcp [::1]:8080: connect: connection refused أنه لا توجد عملية تستمع في العنوان الذي حددته، ويعني [::1] في تلك الرسالة عادةً أنك كتبت localhost في عنوان service:، بينما يرتبط التطبيق بعناوين IPv4 فقط؛ لذلك اكتب http://127.0.0.1:8080 بدلاً منه. أما HTTP/1.x transport connection broken: malformed HTTP response فهو عدم التطابق المعاكس: فقد كتبت https:// عند أصل يتحدث HTTP عادي.

هل يمكنني تشغيل SSH أو RDP أو خادم ألعاب عبر Cloudflare Tunnel؟

ليس من عميل عادي. يحمل اسم المضيف العام عبر النفق بروتوكولات HTTP وHTTPS وWebSocket، وهي البروتوكولات التي يتحدث بها المتصفح. يحتاج أي بروتوكول TCP آخر إلى برنامج على جهاز العميل أيضاً، إما cloudflared access tcp لإعادة توجيه منفذ محلي أو عميل WARP. إذا أردت استخدام SSH من أي جهاز من دون تثبيت أي شيء، فالنفق ليس الأداة المناسبة. أبقِ المنفذ 22 مفتوحاً وقيّده حسب عنوان المصدر.

هل يرى Cloudflare حركة الشبكة الخاصة بي عبر النفق؟

نعم. ينهي Cloudflare TLS عند حافته، ويفك تشفير الطلب هناك، ثم يعيد تشفيره داخل النفق إلى خادمك. يتيح فك التشفير هذا لجدارهم الناري وسياسات التخزين المؤقت وAccess العمل، ويعني أيضاً أن بياناتك النصية غير المشفرة موجودة على أجهزتهم. لا توجد تهيئة تتجنب ذلك ما دمت تستخدم وكيلهم. إذا كان ذلك غير مقبول، فاستخدم Tailscale Funnel أو شغّل Reverse Proxy خاصاً بك على خادم عام.