لتشغيل Cloudflare Tunnel في Docker، أضِف صورة cloudflare/cloudflared الرسمية كخدمة داخل ملف docker-compose.yml، ومرِّر رمز النفق من لوحة تحكم Cloudflare عبر متغيّر البيئة TUNNEL_TOKEN، وضَع cloudflared على شبكة Docker نفسها الموجود عليها التطبيق الذي تريد عرضه. هذه هي الحيلة كاملةً: لا منافذ مفتوحة على جدارك الناري، ولا وكيل عكسي (reverse proxy) لتهيئته، ويصل cloudflared إلى تطبيقك عبر اسم حاويته على شبكة Docker الداخلية. يشرح هذا الدليل إعداد Compose بالضبط، والمأزق الشبكي الوحيد الذي يوقع كل الناس تقريبًا، والحدود التي يستحق أن تعرفها قبل أن تعتمد عليه.
إذا أردت الصورة الكاملة لكيفية عمل الأنفاق عبر كل طرق التثبيت (systemd، وmacOS، والأنفاق السريعة، إضافةً إلى Cloudflare Access أمامها)، فراجع دليلنا الكامل لإعداد Cloudflare Tunnel. هذا المقال أضيق نطاقًا عن قصد: نمط الحاويات مع Docker Compose الذي تتجاهله الوثائق الرسمية غالبًا.
لماذا تشغِّل cloudflared كحاوية؟
إنّ صورة Docker المسمّاة cloudflare/cloudflared هي عفريت الموصِّل (connector daemon) الذي يفتح اتصالًا صادرًا فقط نحو حافة شبكة Cloudflare ويعيد توجيه الطلبات إلى خدماتك المحلية. تشغيله كحاوية بدلًا من حزمة نظام يمنحك ثلاث مزايا حقيقية لأي منظومة مستضافة ذاتيًا. فهو يعيش في ملف docker-compose.yml نفسه مع كل شيء آخر، بحيث تنطلق المنظومة كاملةً بأمر واحد هو docker compose up -d. وهو مثبَّت على وسم صورة (image tag) محدَّد، لذا فإنّ الترقيات تكون عبر docker pull مقصودًا، لا تحديثًا تلقائيًا في الخلفية. ويمكنه التحدّث إلى حاوياتك الأخرى مباشرةً عبر شبكة Docker خاصة، ما يعني أنّ التطبيق الذي تعرضه لا يحتاج أبدًا إلى منفذ منشور.
أمّا النموذج الأمني فهو الجزء الذي يقلِّل الناس من شأنه. لأنّ cloudflared يتصل صادرًا نحو Cloudflare عبر QUIC/HTTPS، يمكن لخادم VPS أو خادمك المنزلي أن يبقي كل منفذ وارد مغلقًا عند الجدار الناري. لا يوجد 80/443 يستمع على الإنترنت العام كي يُمسح أو يُهاجَم بالقوة الغاشمة. وبالنسبة لجهاز مستضاف ذاتيًا، فهذا تقليص ملموس لمساحة الهجوم مقارنةً بفتح ثغرات لوكيل عكسي تقليدي.
المتطلبات المسبقة
- نطاق مُدمَج في Cloudflare (يستخدم خوادم أسماء Cloudflare). تذكر وثائق الإعداد الرسمية أنّ هذا مطلوب لنشر تطبيق عبر نفق.
- تثبيت Docker وDocker Compose على المضيف. إذا كنت تبدأ من خادم فارغ، فإنّ دليلنا للساعة الأولى الآمنة على VPS يغطّي التحصين قبل أن تعرض أي شيء.
- رمز نفق (tunnel token) يُنشأ بخطوة واحدة في لوحة التحكم (القسم التالي).
أمّا Cloudflare Tunnel نفسه فهو مجاني بعرض نطاق ترددي غير محدود — كل ما تحتاجه هو حساب Cloudflare المجاني ونطاق على نظام أسماء نطاقاتهم.
الخطوة 1 — أنشئ نفقًا مُدارًا عن بُعد وانسخ الرمز
في لوحة تحكم Cloudflare، انتقل إلى Zero Trust ← Networks ← Tunnels ← Create a tunnel، واختر Cloudflared، وسمِّه، ثم احفظ. في شاشة "install connector"، اختر Docker. تعرض لك Cloudflare أمر docker run مع رمز طويل مضمَّن فيه — لست بحاجة إلى الأمر كاملًا، بل إلى سلسلة الرمز فقط بعد --token. يصادق هذا الرمز على الموصِّل ويخبره أيضًا بأي نفق ينتمي إليه.
هذا هو النموذج المُدار عن بُعد: تُهيَّأ قواعد توجيه النفق (أي اسم مضيف يُطابَق مع أي خدمة محلية) في لوحة التحكم، لا في ملف تهيئة محلي. وهو أبسط مسار لـ Docker والمسار الذي تعتمده Cloudflare افتراضيًا الآن. أمّا البديل، المُدار محليًا، فيُبقي ملف config.yml وملف بيانات الاعتماد داخل الحاوية — وهو أكثر قابليةً للنقل وللتحكّم بالإصدارات، لكنّه ذو أجزاء متحرّكة أكثر. يقارن الجدول أدناه بينهما.
| مُدار عن بُعد (رمز) | مُدار محليًا (config.yml) | |
|---|---|---|
| أين يوجد التوجيه | لوحة تحكم Cloudflare | config.yml على المضيف |
| ما تحتاجه الحاوية | فقط TUNNEL_TOKEN | ملف التهيئة + بيانات اعتماد JSON مُثبَّتة داخلها |
| الأنسب لـ | معظم إعدادات Docker، بدء سريع | GitOps، أسماء مضيفين كثيرة، بنية قابلة للاستنساخ |
| تعديلات الدخول (Ingress) | نقرة في لوحة التحكم | تعديل الملف، إعادة تشغيل الحاوية |
| أسرار يجب حمايتها | الرمز | ملف بيانات الاعتماد |
الخطوة 2 — أضِف cloudflared إلى docker-compose.yml
إليك ملف Compose بسيطًا يعرض حاوية تطبيق (سمِّها webapp، تستمع على المنفذ 3000) عبر النفق:
services:
webapp:
image: your/webapp:latest
restart: unless-stopped
networks: [internal]
# note: no "ports:" — nothing is published to the host
cloudflared:
image: cloudflare/cloudflared:latest
restart: unless-stopped
command: tunnel --no-autoupdate run
environment:
- TUNNEL_TOKEN=${TUNNEL_TOKEN}
networks: [internal]
networks:
internal:
ضَع الرمز في ملف .env بجوار ملف Compose (TUNNEL_TOKEN=ey...) وأضِف ذلك الملف إلى .gitignore. لا تودِع الرمز أبدًا في المستودع — فأي شخص يمتلكه يستطيع تشغيل نفقك. ولإعداد محصَّن، استخدم سرًّا في Docker بدلًا من متغيّر بيئة. راية --no-autoupdate مقصودة: فوسم الصورة يتحكّم بالإصدار، بحيث تُرقّي بسحب صورة جديدة، لا بترك العفريت يرقِّع نفسه أثناء التشغيل.
أمّا الأمر المكافئ لمرة واحدة، إن لم تكن تستخدم Compose، فهو نفسه الذي تطبعه لوحة التحكم:
docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <TUNNEL_TOKEN>
الخطوة 3 — وجِّه النفق نحو حاويتك (المأزق)
هنا يعلق معظم الناس، والأمر منتشر في كل أنحاء منتديات مجتمع Cloudflare. عُد إلى لوحة التحكم، وافتح نفقك، وانتقل إلى تبويب Public Hostname، وأضِف مسارًا: اختر نطاقًا فرعيًا (لنقُل app.yourdomain.com) واضبط عنوان service URL.
الخطأ هو إدخال http://localhost:3000. فداخل حاوية cloudflared، يكون localhost هو حاوية cloudflared نفسها — لا تطبيقك، ولا مضيف Docker. ولأنّ الحاويتين تتشاركان شبكة internal، يستطيع cloudflared أن يحلّ اسم التطبيق عبر اسم خدمته في Compose. لذا فإنّ قيمة service الصحيحة هي:
http://webapp:3000
يُطابق نظام DNS المدمج في Docker الاسم webapp مع عنوان IP لحاوية التطبيق على الشبكة المشتركة. وإذا كان تطبيقك يعمل في مكان آخر غير حاوية شقيقة — مثلًا على المضيف مباشرةً — فستستخدم بدلًا من ذلك http://host.docker.internal:3000 (مع مدخل extra_hosts المناسب على Linux). إنّ ضبط هذا العنوان صحيحًا يمثّل 90% من نفق يعمل؛ فخطأ 502 عند الحافة يعني غالبًا أنّ cloudflared لا يستطيع الوصول إلى العنوان الذي كتبته هنا.
الخطوة 4 — شغِّله وتحقّق
docker compose up -d
docker compose logs -f cloudflared
في السجلّات، ابحث عن أسطر تؤكّد اتصالات مسجَّلة بحافة شبكة Cloudflare (عادةً أربعة، إلى مراكز بيانات مختلفة). وبمجرد أن تصبح فعّالة، حمِّل https://app.yourdomain.com — إذ يُنهى TLS عند حافة Cloudflare تلقائيًا، فتحصل على HTTPS دون أن تثبِّت أي شهادة على جهازك أبدًا. وإذا لم يُحلّ العنوان، فتحقّق من أنّ سجل DNS لـ Public Hostname قد أُنشئ (تضيف Cloudflare سجل CNAME موكَّلًا (proxied) نيابةً عنك) ومن أنّ عنوان service يطابق اسم حاويتك ومنفذها.
حدود يستحق أن تعرفها قبل أن تعتمد عليه
الأنفاق متينة، لكنّ الوكيل المجاني له حدود صلبة:
- سقف رفع 100 MB. تفرض خطتا Free وPro من Cloudflare حدًّا أقصى لحجم جسم الطلب قدره 100 MB. ارفع ملفًا أكبر عبر النفق فتُعيد الحافة رمز HTTP 413 قبل أن يصل إلى حاويتك حتى. يؤثّر هذا في تطبيقات رفع الملفات والنسخ الاحتياطي ومنشورات الوسائط الكبيرة.
- ليس لبثّ الوسائط الثقيل. لا يُقصَد بوكيل Cloudflare تقديم أحجام كبيرة من المحتوى غير النصي (غير HTML) مثل مكتبات الفيديو؛ إذ قد يواجه Plex أو Jellyfin مستضاف ذاتيًا خلف نفق تقييدًا للسرعة. استخدمه للتطبيقات ولوحات المعلومات، لا كشبكة توزيع محتوى (CDN) لمجموعة أفلام.
- الأنفاق السريعة للاختبار فقط. أنفاق
trycloudflare.comالقابلة للتخلّص لها حدّ قدره 200 طلبًا متزامنًا ولا تدعم أحداث الخادم المرسَلة (Server-Sent Events). مناسبة لعرض توضيحي، لكنها خاطئة للإنتاج — استخدم بدلًا منها نفقًا مسمّى بنطاقك الخاص. - أنت تثق بحافة Cloudflare. كل حركة المرور تعبر شبكتهم. وبالنسبة لمعظم المستضيفين ذاتيًا، فهذه مقايضة مقبولة مقابل منافذ واردة مغلقة؛ فإن لم تكن كذلك بالنسبة لنموذج تهديدك، فإنّ WireGuard مستضافًا ذاتيًا أو وكيلًا عكسيًا هما البديل.
ولطبقة أمان أعمق، يمكنك أيضًا وضع Cloudflare Access أمام اسم المضيف بحيث لا يصل إلى التطبيق سوى المستخدمين الموثَّقين — وهو مشمول في دليل الأنفاق العام.
أين يقع هذا في منظومة مستضافة ذاتيًا
يتألّق نمط نفق Docker حين تكون بالفعل تشغِّل تطبيقاتك في حاويات — وهو الاتجاه الذي مضى إليه معظم الاستضافة الذاتية. اقرِنه بـ دليلنا خطوةً بخطوة لاستضافة تطبيقاتك ذاتيًا على VPS فيصبح cloudflared هو خدمة "الباب الأمامي" الوحيدة والقابلة للنقل التي تُدرجها في كل منظومة. صورة واحدة، ومتغيّر بيئة واحد، وصفر منافذ مفتوحة.
الأسئلة الشائعة
هل يمكنني تشغيل cloudflared في docker-compose؟
نعم. أضِف cloudflare/cloudflared:latest كخدمة مع command: tunnel --no-autoupdate run ومتغيّر بيئة TUNNEL_TOKEN يحمل رمزًا أنشأته في لوحة تحكم Cloudflare Zero Trust. ضَعه على شبكة Docker نفسها الموجود عليها التطبيق الذي تعرضه كي يصل إلى الحاوية عبر الاسم.
كيف يصل cloudflared إلى حاوية أخرى؟
عبر نظام DNS الداخلي في Docker. حين تتشارك الحاويتان شبكة معرَّفة من المستخدم، يحلّ cloudflared اسم الحاوية الأخرى عبر اسم خدمتها في Compose — فيكون عنوان service للنفق هو http://<service-name>:<port> (على سبيل المثال http://webapp:3000)، لا http://localhost:3000 أبدًا، لأنّ localhost داخل الحاوية يشير إلى cloudflared نفسه.
هل أحتاج إلى فتح منافذ لـ Cloudflare Tunnel في Docker؟
لا. يجري cloudflared اتصالًا صادرًا فقط نحو حافة Cloudflare، فلا تُنشَر منافذ واردة على الحاوية ولا تُفتح على جدار المضيف الناري. وهذا الوضع بمنافذ مغلقة هو الفائدة الأمنية الرئيسية على وكيل عكسي تقليدي.
هل Cloudflare Tunnel مجاني؟
نعم. Cloudflare Tunnel مجاني بعرض نطاق ترددي غير محدود على الخطة المجانية؛ كل ما تحتاجه هو حساب Cloudflare مجاني ونطاق يستخدم نظام أسماء نطاقات Cloudflare. ترفع الخطط المدفوعة بعض حدود الوكيل (مثل سقف الطلب البالغ 100 MB) لكنها ليست مطلوبة لتشغيل نفق.
Cloudflare Tunnel أم وكيل عكسي — أيّهما ينبغي أن أستخدم في Docker؟
استخدم وكيلًا عكسيًا (Caddy أو Traefik أو Nginx) حين تكون مرتاحًا لفتح 80/443 وتريد تحكّمًا كاملًا في TLS والتخزين المؤقت على جهازك. واستخدم Cloudflare Tunnel حين تفضّل إبقاء كل منفذ وارد مغلقًا وترك Cloudflare تتولّى TLS وتوجيه الحافة. تشغِّل منظومات كثيرة الاثنين معًا: نفقًا للوصول الخارجي، ووكيلًا للتوجيه الداخلي.
المصادر
- Cloudflare — Set up Cloudflare Tunnel: خطوات التثبيت الرسمية، وأمر
docker run cloudflare/cloudflared، ومتطلّب وجود النطاق على Cloudflare، محدَّثة في أبريل 2026. - Docker Hub — cloudflare/cloudflared: صورة الموصِّل الرسمية المستخدمة في ملف Compose.
- Cloudflare Community — cloudflared in docker-compose: سؤال شبكات الحاويات المتكرّر الذي يحلّه هذا الدليل.
- Cloudflare Community — maximum upload limit on the free plan: يؤكّد سقف جسم الطلب البالغ 100 MB الذي يُعيد رمز HTTP 413.
وقاص احمد وسیر
وقاص احمد وسیر مطوّر ومهندس أتمتة بخبرة تزيد على 8 سنوات في بناء أنظمة إنتاجية يستخدمها أكثر من 100 ألف شخص. يبني تطبيقات SaaS متعددة المستأجرين، وأتمتة بالذكاء الاصطناعي (n8n، تدفقات LLM، بوتات واتساب)، وبنية استضافة (WHM/cPanel، CloudLinux) — وهو صانع WaSphere وFlowMaticX وعلامة الاستضافة WaseerHost. أنجز أكثر من 100 مشروع لشركات صغيرة ومتوسطة ووكالات وشركات ناشئة ممولة.
