كيفية استخدام نطاق مخصص و HTTPS مع n8n

لاستخدام نطاق مخصص مع HTTPS في n8n، أنشئ سجل DNS من النوع A مثل n8n.example.com يشير إلى IP السيرفر الخاص بك. بعد ذلك ضع وكيلًا عكسيًا (reverse proxy) يتولى إنهاء اتصال TLS أمام حاوية n8n. يمكن أن يكون هذا الوكيل Nginx مع شهادة Let's Encrypt مجانية من certbot، أو Traefik/Caddy إذا كانت بيئة التشغيل لديك تتضمن أحدهما بالفعل. أخيرًا، اضبط N8N_HOST وN8N_PROTOCOL=https وWEBHOOK_URL وN8N_EDITOR_BASE_URL على النطاق الجديد، ثم أعد إنشاء الحاوية باستخدام docker compose up -d.

ينطبق هذا الدليل على استضافة n8n من Cloudesta، وعلى أي VPS يعمل بنظام Ubuntu 22.04/24.04 ويشغّل n8n داخل Docker. اتبعه عند التوقف عن استخدام عنوان IP المباشر لأول مرة، أو كلما غيّرت نطاق n8n.

المتطلبات المسبقة

صلاحية وصول SSH بحساب root أو بصلاحيات sudo إلى السيرفر الذي يشغّل n8n.
إمكانية الوصول إلى منطقة DNS الخاصة بنطاقك، أيًّا كانت الجهة التي تستضيف DNS النطاق.
عنوان IPv4 العام للسيرفر (مثلًا 203.0.113.10).
أن يكون المنفذان 80 و443 متاحين من الإنترنت، إذ تحتاج Let's Encrypt إلى المنفذ 80 للتحقق من النطاق.
عنوان بريد إلكتروني فعّال لاستقبال إشعارات انتهاء صلاحية الشهادة.

1. كيف أوجّه نطاقي إلى سيرفر n8n؟

أضف هذا السجل لدى مزوّد DNS الخاص بك:

Type: A
Name: n8n          (becomes n8n.example.com)
Value: 203.0.113.10
TTL: 300

إذا كان هناك سجل AAAA للاسم نفسه، فاحذفه ما لم يكن يشير إلى عنوان IPv6 الخاص بهذا السيرفر. تفضّل Let's Encrypt استخدام IPv6، ولذلك يؤدي وجود سجل AAAA خاطئ إلى فشل التحقق. تأكد من أن السجل يُحَل بشكل صحيح قبل المتابعة:

dig +short n8n.example.com A
dig +short n8n.example.com AAAA

2. هل يوجد Traefik أو Caddy بالفعل على سيرفر n8n لديّ؟

قبل تثبيت أي شيء، تحقق من الحاويات قيد التشغيل ومن المنافذ التي تنشرها:

sudo docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'
sudo ss -tlnp | grep -E ':(80|443)\s'

إذا كانت حاوية traefik أو caddy تشغل المنفذين 80/443، فاستخدم الخيار B (القسم 4).
إذا كان n8n وحده هو ما يعمل، أو لم يكن هناك ما يستمع على المنفذين 80/443، فاستخدم الخيار A (القسم 3).

بعد ذلك، حدّد المجلد الذي يحتوي على ملفَّي docker-compose.yml و.env الخاصين بـ n8n. استبدل n8n في الأمر أدناه باسم الحاوية الظاهر في المخرجات السابقة:

sudo docker inspect -f '{{ index .Config.Labels "com.docker.compose.project.working_dir" }}' n8n

3. الخيار A: كيف أُعدّ Nginx وLet's Encrypt أمام n8n؟

تثبيت Nginx وcertbot

sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginx
sudo ufw allow 'Nginx Full'

لا تلزم قاعدة ufw إلا إذا كان UFW مفعّلًا. يمكنك التحقق من ذلك باستخدام sudo ufw status.

إنشاء موقع الوكيل العكسي

أنشئ الملف /etc/nginx/sites-available/n8n باستخدام sudo nano /etc/nginx/sites-available/n8n والصق فيه الكتلة أدناه. الترويستان Upgrade وConnection ضروريتان، فبدونهما يفشل اتصال WebSocket الذي يستخدمه المحرر لاستقبال التحديثات الفورية (push)، وتظهر رسالة "Connection lost".

server {
    listen 80;
    listen [::]:80;
    server_name n8n.example.com;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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;
        proxy_buffering off;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        client_max_body_size 50m;
    }
}

فعّل الموقع وأعد تحميل Nginx:

sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/n8n
sudo nginx -t
sudo systemctl reload nginx

طلب الشهادة

sudo certbot --nginx -d n8n.example.com -m you@example.com --agree-tos --redirect

يضيف Certbot كتلة server خاصة بـ HTTPS، وإعادة توجيه من HTTP إلى HTTPS. كما يثبّت مؤقّت systemd يجدد الشهادة تلقائيًا.

ربط n8n بـ localhost فقط

في ملف docker-compose.yml، غيّر ربط منفذ n8n كما يلي، حتى يصبح الوصول إلى n8n ممكنًا عبر Nginx فقط وليس عبر http://203.0.113.10:5678:

    ports:
      - "127.0.0.1:5678:5678"

4. الخيار B: كيف أغيّر النطاق عندما يكون Traefik أو Caddy مثبتًا بالفعل؟

لا تثبّت Nginx في هذه الحالة، لأن المنفذين 80/443 مشغولان بالفعل، والوكيل الحالي يحصل على الشهادات بنفسه. افتح ملف .env الموجود في مجلد compose:

cd /path/from/step/2
sudo nano .env

تختلف أسماء المتغيرات حسب طريقة بناء بيئة التشغيل. يستخدم مثال Traefik الرسمي من n8n المتغيرات الموضحة أدناه. عدّل المتغيرات الموجودة فعليًا في ملفك، بدلًا من إضافة أسماء جديدة لن يقرأها أي شيء:

DOMAIN_NAME=example.com
SUBDOMAIN=n8n
SSL_EMAIL=you@example.com

في حالة Caddy، يُكتب اسم المضيف (hostname) غالبًا مباشرةً في ملف Caddyfile. إن كان الأمر كذلك، فاستبدل اسم المضيف القديم بـ n8n.example.com هناك أيضًا. وتحقق كذلك من labels الخاصة بـ Traefik في ملف docker-compose.yml بحثًا عن قاعدة Host(`...`) مكتوبة بقيمة ثابتة.

5. ما متغيرات بيئة n8n التي يجب أن تطابق النطاق؟

اضبط هذه المتغيرات في قسم environment: الخاص بخدمة n8n، أو في ملف .env إذا كان ملف compose يشير إليها من هناك:

    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_EDITOR_BASE_URL=https://n8n.example.com/
      - N8N_PROXY_HOPS=1

مهم: المتغير N8N_PORT هو المنفذ الذي يستمع عليه n8n داخل الحاوية، لذا أبقِه على 5678. لا تضبطه على 443، لأن الوكيل هو الذي يتعامل مع المنفذ 443. أما N8N_PROXY_HOPS=1 فيُعلِم n8n بأن يثق في ترويسات X-Forwarded-* القادمة من الوكيل.

6. كيف أعيد تشغيل n8n لتطبيق التغييرات؟

cd /path/to/compose/folder
sudo docker compose up -d
sudo docker compose logs -f --tail=50

استخدم docker compose up -d وليس docker compose restart. فأمر restart يعيد استخدام الحاوية القديمة ببيئتها القديمة، فتُتجاهَل المتغيرات الجديدة، بينما يعيد up -d إنشاء الحاوية. تبقى مسارات العمل (workflows) آمنة ما دامت وحدة تخزين بيانات n8n (volume) معرّفة في ملف compose، كما هو الحال في التثبيتات القياسية.

التحقق من نجاح الإعداد

curl -I http://n8n.example.com     # expect 301/308 redirect to https
curl -I https://n8n.example.com    # expect HTTP/2 200 or HTTP/1.1 200
sudo docker exec n8n printenv | grep -E 'N8N_HOST|WEBHOOK_URL|N8N_PROTOCOL'
sudo certbot renew --dry-run       # Option A only

افتح https://n8n.example.com في المتصفح. يجب أن يُظهر رمز القفل شهادة صالحة، وألا يعرض المحرر رسالة "Connection lost".
افتح أي عقدة Webhook. يجب أن يبدأ كلٌّ من Test URL وProduction URL بـ https://n8n.example.com/.
نفّذ webhook تجريبيًا من خارج السيرفر، مثلًا curl https://n8n.example.com/webhook-test/your-path أثناء الاستماع لحدث تجريبي.

مشكلات شائعة

روابط Webhook لا تزال تعرض عنوان IP أو المنفذ 5678 أو النطاق القديم

السبب إما أن المتغير WEBHOOK_URL غير موجود، وإما أن الحاوية لم يُعَد إنشاؤها. صحّح المتغير، وشغّل docker compose up -d، ثم تأكد من النتيجة باستخدام printenv. بعض عقد التشغيل (trigger) تسجّل رابطها لدى خدمة خارجية، مثل مشغّلات Telegram وStripe وGitHub. عطّل كل مسار عمل من هذه المسارات ثم فعّله من جديد ليعيد تسجيل الرابط الجديد.

فشل Certbot أو Traefik في اجتياز اختبار التحقق من الشهادة

تأكد من أن dig يعيد IP السيرفر الخاص بك، ومن عدم وجود سجل AAAA زائد. يجب أن يكون المنفذ 80 مفتوحًا في UFW وفي أي جدار ناري خارجي. إذا كان النطاق يمر عبر وكيل CDN مثل السحابة البرتقالية في Cloudflare، فحوّله إلى وضع DNS فقط (DNS-only) أثناء إصدار الشهادة. تفرض Let's Encrypt حدًّا على المحاولات الفاشلة المتكررة، لذا اختبر أولًا باستخدام --dry-run.

Nginx يعيد الخطأ 502 Bad Gateway

يعني هذا أن Nginx لا يستطيع الوصول إلى n8n. شغّل sudo docker compose ps للتأكد من أن n8n يعمل، وcurl -I http://127.0.0.1:5678 لاختباره من السيرفر المضيف، ثم اطّلع على sudo tail /var/log/nginx/error.log. غالبًا ما يكون السبب غياب ربط المنفذ، أو أن الحاوية تتعطل وتعيد التشغيل باستمرار، وهو ما سيظهر في docker compose logs.

فشل تسجيل الدخول عبر OAuth مع الخطأ "redirect_uri_mismatch"

لا تزال تطبيقات OAuth في Google وMicrosoft وSlack والخدمات المشابهة تحتوي على رابط callback القديم. افتح بيانات الاعتماد (credential) في n8n وانسخ OAuth Redirect URL الجديد، والذي يجب أن يبدأ بـ https://n8n.example.com/rest/oauth2-credential/callback. أضفه إلى إعدادات التطبيق لدى المزوّد، ثم أعد ربط بيانات الاعتماد.

Nginx لا يبدأ التشغيل: "Address already in use"

هناك وكيل آخر، عادةً Traefik أو Caddy، يشغل المنفذين 80/443 بالفعل. استخدم الخيار B بدلًا من ذلك، أو أزِل الوكيل الآخر قبل متابعة الخيار A.

الأسئلة الشائعة

هل يمكنني تشغيل n8n على النطاق الرئيسي بدلًا من نطاق فرعي؟

نعم. وجّه سجل A الخاص بالنطاق الرئيسي إلى السيرفر، واستخدم example.com في جميع الخطوات السابقة. لكن النطاق الفرعي يكون عادةً أسهل، لأنه يتيح إبقاء موقعك الإلكتروني على استضافة منفصلة.

هل أحتاج إلى تجديد شهادة Let's Encrypt يدويًا؟

لا. يتولى مؤقّت systemd الخاص بـ Certbot، وكذلك Traefik/Caddy، تجديد الشهادة تلقائيًا قبل انتهاء مدة صلاحيتها البالغة 90 يومًا. شغّل sudo certbot renew --dry-run مرة واحدة للتأكد من أن التجديد يعمل.

هل سيؤدي تغيير النطاق إلى حذف مسارات العمل أو بيانات الاعتماد؟

لا. تُخزَّن مسارات العمل وبيانات الاعتماد في وحدة تخزين بيانات n8n وفي قاعدة البيانات، ولا تتأثر بإعادة إنشاء الحاوية. ما يحتاج إلى تحديث فقط هو تسجيلات webhook لدى الخدمات الخارجية وروابط OAuth callback.

هل تحتاج إلى مساعدة؟ إذا واجهتك أي مشكلة، افتح تذكرة دعم عبر https://cloudesta.com/submitticket.php، وأرفق فيها نطاقك ومخرجات الأمر docker compose logs --tail=50. ستجد المزيد من الشروحات في مكتبة الشروحات من Cloudesta.

الإشعارات

تسجيل الدخول - هذه الصفحة مخصصة

دعم مميز

الاستضافة

النطاقات

G Suite

شهادة Wildcard