اگر n8n را روی سرور مجازی، Docker یا سرور اختصاصی نصب کرده باشید، یکی از مهم‌ترین اقداماتی که باید قبل از استفاده عملیاتی انجام دهید، فعال‌سازی SSL و دسترسی از طریق HTTPS است.
بدون HTTPS، ارتباط مرورگر و سرور ممکن است به‌صورت رمزنگاری‌نشده برقرار شود. این موضوع برای پلتفرمی مانند n8n که اطلاعات ورود، Credentialها، Webhookها و ارتباط با APIهای مختلف را مدیریت می‌کند، اهمیت زیادی دارد.
خوشبختانه برای فعال‌سازی HTTPS نیازی به خرید گواهی تجاری ندارید. با استفاده از Let's Encrypt می‌توانید گواهی TLS معتبر و رایگان دریافت کنید.
در این آموزش، نحوه نصب SSL برای n8n را روی Nginx و OpenLiteSpeed بررسی می‌کنیم. همچنین یاد می‌گیریم چگونه HTTPS را در Docker تنظیم کنیم، از Cloudflare استفاده کنیم، تمدید خودکار گواهی را فعال کنیم و خطاهای رایج SSL را برطرف کنیم.
SSL چیست و چرا برای n8n اهمیت دارد؟
SSL یا Secure Sockets Layer نام فناوری قدیمی رمزنگاری ارتباطات اینترنتی است. امروزه پروتکل مورد استفاده TLS نام دارد، اما اصطلاح SSL همچنان به‌صورت رایج برای گواهی‌های HTTPS استفاده می‌شود.
زمانی که یک وب‌سایت از HTTPS استفاده می‌کند، ارتباط میان مرورگر و سرور با TLS محافظت می‌شود.
برای مثال، این آدرس از HTTP استفاده می‌کند:
http://n8n.example.com
اما این آدرس از HTTPS استفاده می‌کند:
https://n8n.example.com
مزایای HTTPS برای n8n
رمزنگاری اطلاعات: داده‌های منتقل‌شده بین مرورگر و سرور در مسیر ارتباط محافظت می‌شوند.
اعتبارسنجی هویت سرور: گواهی معتبر کمک می‌کند مرورگر اطمینان پیدا کند با دامنه موردنظر ارتباط برقرار کرده است.
امنیت ورود کاربران: اطلاعات ورود و نشست‌های کاربران از طریق اتصال رمزنگاری‌شده منتقل می‌شوند.
پشتیبانی از Webhookهای امن: بسیاری از سرویس‌های خارجی برای ثبت Webhook به یک آدرس HTTPS معتبر نیاز دارند.
سازگاری با OAuth: هنگام اتصال بعضی سرویس‌ها، استفاده از HTTPS برای Redirect URI عمومی ضروری است.
البته SSL به‌تنهایی تمام مشکلات امنیتی را حل نمی‌کند. همچنان باید دسترسی کاربران، امنیت سرور، Credentialها و Workflowها را مدیریت کنید.
آیا n8n خودش SSL دارد؟
n8n می‌تواند با تنظیمات مناسب در معماری‌های مختلف اجرا شود، اما در بیشتر نصب‌های Self-hosted، مدیریت HTTPS به یک Reverse Proxy سپرده می‌شود.
برای مثال:
مرورگر یا سرویس خارجی
|
| HTTPS :443
v
Nginx / OpenLiteSpeed
|
| HTTP داخلی
v
n8n :5678
در این ساختار، Reverse Proxy اتصال HTTPS را دریافت می‌کند و درخواست را به n8n انتقال می‌دهد.
این روش چند مزیت دارد:
- مدیریت ساده‌تر گواهی‌های SSL
- امکان میزبانی چند سرویس روی یک IP
- تمدید خودکار گواهی
- عدم نیاز به انتشار مستقیم پورت n8n
- کنترل بهتر ترافیک ورودی
اگر ارتباط داخلی میان Reverse Proxy و n8n روی همان سرور و از طریق localhost برقرار باشد، این معماری برای بسیاری از نصب‌ها مناسب است.
اما اگر Reverse Proxy و n8n روی دو سرور مجزا هستند، باید ارتباط بین آن‌ها را نیز با شبکه خصوصی امن یا TLS محافظت کنید.
پیش‌نیازهای فعال‌سازی SSL برای n8n
قبل از شروع، موارد زیر را آماده کنید:
- یک دامنه یا زیردامنه فعال
- دسترسی به تنظیمات DNS
- سرور لینوکسی دارای IP عمومی
- n8n نصب‌شده و در حال اجرا
- دسترسی SSH و مجوز مدیریتی
- وب‌سرور Nginx یا OpenLiteSpeed
- دسترسی ورودی به پورت‌های موردنیاز اعتبارسنجی گواهی
در این آموزش از دامنه فرضی زیر استفاده می‌کنیم:
n8n.example.com
و فرض می‌کنیم n8n روی آدرس داخلی زیر اجرا شده است:
http://127.0.0.1:5678
تمام آدرس‌های نمونه را با اطلاعات واقعی خود جایگزین کنید.
مرحله اول: بررسی اتصال دامنه به سرور
قبل از دریافت گواهی SSL باید مطمئن شوید دامنه به سرور صحیح اشاره می‌کند.
در پنل DNS دامنه، رکورد A را بررسی کنید.
| نوع رکورد | نام | مقدار |
|---|---|---|
| A | n8n | IP سرور |
برای مثال اگر IP سرور برابر 203.0.113.10 باشد، رکورد A باید به همین IP اشاره کند.
برای بررسی DNS از دستور زیر استفاده کنید:
dig +short n8n.example.com A
اگر IPv6 فعال است، رکورد AAAA را نیز بررسی کنید:
dig +short n8n.example.com AAAA
اگر دامنه به IP اشتباه اشاره کند، اعتبارسنجی Let's Encrypt ممکن است ناموفق باشد.
بررسی دسترسی پورت‌ها
برای روش رایج HTTP-01، سرور اعتبارسنجی باید بتواند از طریق پورت 80 به دامنه دسترسی پیدا کند.
وضعیت فایروال را بررسی کنید:
sudo ufw status
در صورت نیاز، پورت‌های HTTP و HTTPS را مجاز کنید:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
اگر ارائه‌دهنده VPS دارای فایروال مستقل است، تنظیمات آن را نیز بررسی کنید.
مرحله دوم: بررسی عملکرد n8n
قبل از فعال‌سازی SSL مطمئن شوید خود n8n به‌درستی اجرا می‌شود.
اگر از Docker Compose استفاده می‌کنید:
cd /opt/n8n
sudo docker compose ps
برای بررسی پاسخ‌گویی برنامه:
curl -i http://127.0.0.1:5678/healthz
اگر پاسخ موفق دریافت کردید، سرویس آماده اتصال به Reverse Proxy است.
اگر درخواست ناموفق بود:
sudo docker compose logs --tail=100 n8n
تا زمانی که Backend به‌درستی پاسخ نمی‌دهد، نصب SSL مشکل اجرای n8n را برطرف نمی‌کند.
مرحله سوم: نصب SSL برای n8n با Nginx
در این روش فرض می‌کنیم Nginx روی سرور نصب شده یا می‌خواهید آن را به‌عنوان Reverse Proxy اصلی استفاده کنید.
اگر OpenLiteSpeed یا وب‌سرور دیگری از قبل پورت‌های 80 و 443 را اشغال کرده است، این روش را بدون تغییر معماری اجرا نکنید.
نصب Nginx
روی Ubuntu اجرا کنید:
sudo apt update
sudo apt install nginx -y
وضعیت سرویس را بررسی کنید:
sudo systemctl status nginx
ایجاد Virtual Host
فایل تنظیمات دامنه را ایجاد کنید:
sudo nano /etc/nginx/sites-available/n8n
محتوای زیر را وارد کنید:
server {
listen 80;
server_name n8n.example.com;
location / {
proxy_pass http://127.0.0.1:5678;
proxy_http_version 1.1;
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-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 300s;
}
}
این تنظیم درخواست‌های ورودی را به n8n منتقل می‌کند.
فعال‌سازی تنظیمات
sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/n8n
اگر لینک از قبل وجود دارد، آن را دوباره ایجاد نکنید.
سپس صحت تنظیمات را بررسی کنید:
sudo nginx -t
در صورت موفقیت:
sudo systemctl reload nginx
اکنون Nginx باید درخواست‌های HTTP دامنه را به n8n منتقل کند.
مرحله چهارم: دریافت SSL رایگان با Certbot
Certbot ابزاری برای دریافت و مدیریت گواهی‌های Let's Encrypt است.
روی Ubuntu می‌توانید از بسته‌های موجود در مخازن سیستم‌عامل استفاده کنید.
sudo apt install certbot python3-certbot-nginx -y
سپس دستور زیر را اجرا کنید:
sudo certbot --nginx -d n8n.example.com
Certbot تلاش می‌کند مالکیت دامنه را تأیید کند و گواهی را دریافت و در تنظیمات Nginx اعمال کند.
ممکن است در طول اجرا از شما اطلاعاتی مانند ایمیل و موافقت با شرایط سرویس درخواست شود.
پس از صدور موفق گواهی، آدرس زیر را باز کنید:
https://n8n.example.com
اگر تنظیمات صحیح باشند، پنل n8n باید از طریق HTTPS در دسترس باشد.
گواهی‌های SSL کجا ذخیره می‌شوند؟
در نصب معمول Certbot، فایل‌های گواهی در مسیر زیر قرار می‌گیرند:
/etc/letsencrypt/live/n8n.example.com/
مهم‌ترین فایل‌ها عبارت‌اند از:
| فایل | کاربرد |
|---|---|
privkey.pem | کلید خصوصی گواهی |
cert.pem | گواهی دامنه |
chain.pem | زنجیره گواهی |
fullchain.pem | گواهی همراه با زنجیره |
کلید خصوصی باید فقط برای فرایندها و کاربران مجاز قابل دسترسی باشد.
مرحله پنجم: تنظیم HTTPS در Docker n8n
اگر n8n داخل Docker اجرا می‌شود و Nginx روی همان سرور قرار دارد، معمولاً نیازی نیست گواهی SSL را داخل کانتینر n8n نصب کنید.
کافی است n8n روی یک پورت داخلی قابل دسترسی باشد.
برای مثال:
ports:
- "127.0.0.1:5678:5678"
این تنظیم باعث می‌شود پورت منتشرشده فقط روی localhost میزبان در دسترس باشد.
سپس آدرس عمومی n8n را در متغیرهای محیطی تنظیم کنید.
فایل .env:
N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://n8n.example.com/
WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1
توضیح متغیرها
N8N_HOST نام میزبان عمومی را مشخص می‌کند.
N8N_PROTOCOL پروتکل عمومی n8n را تعیین می‌کند.
N8N_EDITOR_BASE_URL آدرس محیط ویرایشگر را مشخص می‌کند.
WEBHOOK_URL برای تولید آدرس صحیح Webhookها استفاده می‌شود.
N8N_PROXY_HOPS تعداد لایه‌های Reverse Proxy مورد اعتماد را مشخص می‌کند.
در معماری‌ای که فقط یک Reverse Proxy مستقیماً جلوی n8n قرار دارد، مقدار 1 معمولاً مناسب است.
انتقال متغیرها به کانتینر
اگر از Docker Compose استفاده می‌کنید، مطمئن شوید متغیرها در بخش environment سرویس n8n نیز تعریف شده‌اند:
environment:
N8N_HOST: ${N8N_HOST}
N8N_PROTOCOL: ${N8N_PROTOCOL}
N8N_EDITOR_BASE_URL: ${N8N_EDITOR_BASE_URL}
WEBHOOK_URL: ${WEBHOOK_URL}
N8N_PROXY_HOPS: ${N8N_PROXY_HOPS}
این قطعه باید به تنظیمات موجود سرویس n8n اضافه شود، نه اینکه جایگزین تمام تنظیمات دیتابیس و Volumeها شود.
سپس:
sudo docker compose config --quiet
sudo docker compose up -d --no-deps n8n
برای بررسی:
sudo docker compose exec n8n printenv WEBHOOK_URL
اگر دامنه صحیح نمایش داده شد، متغیر به کانتینر منتقل شده است.
مرحله ششم: نصب SSL برای n8n در OpenLiteSpeed
اگر سرور شما از OpenLiteSpeed استفاده می‌کند، می‌توانید SSL را مستقیماً در همان وب‌سرور مدیریت کنید.
در این روش نیازی به نصب Nginx نیست.
فرض می‌کنیم:
- OpenLiteSpeed فعال است.
- یک Virtual Host برای دامنه n8n ایجاد کرده‌اید.
- دامنه در Listenerهای مربوطه Map شده است.
- Reverse Proxy درخواست‌ها را به
127.0.0.1:5678منتقل می‌کند.
ایجاد مسیر اعتبارسنجی Let's Encrypt
برای استفاده از روش Webroot باید یک مسیر قابل دسترسی از طریق HTTP داشته باشید.
برای مثال:
sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge
مسیر /var/www/letsencrypt را به‌عنوان Webroot اعتبارسنجی در نظر می‌گیریم.
باید در تنظیمات OpenLiteSpeed یک Context یا Rule مناسب تعریف کنید تا درخواست‌های مسیر زیر از همان Webroot پاسخ داده شوند:
/.well-known/acme-challenge/
نکته مهم این است که این درخواست‌ها نباید به n8n منتقل شوند.
اگر Proxy Context عمومی / دارید، باید مطمئن شوید مسیر ACME Challenge به‌صورت مستقل و با اولویت صحیح پاسخ داده می‌شود.
آزمایش مسیر اعتبارسنجی
یک فایل آزمایشی ایجاد کنید:
echo "acme-test" | sudo tee \
/var/www/letsencrypt/.well-known/acme-challenge/test.txt
سپس اجرا کنید:
curl -i http://n8n.example.com/.well-known/acme-challenge/test.txt
اگر محتوای acme-test دریافت شد، مسیر اعتبارسنجی آماده است.
پس از آزمایش، فایل تست را حذف کنید.
دریافت گواهی
Certbot را نصب کنید:
sudo apt install certbot -y
سپس:
sudo certbot certonly --webroot \
-w /var/www/letsencrypt \
-d n8n.example.com
اگر اعتبارسنجی موفق باشد، فایل‌های گواهی در مسیر /etc/letsencrypt/live/ ایجاد می‌شوند.
اتصال گواهی به OpenLiteSpeed
وارد پنل WebAdmin شوید.
به بخش زیر بروید:
Virtual Hosts → n8n → SSL
در تنظیمات گواهی، مسیرها را وارد کنید:
Private Key File:
/etc/letsencrypt/live/n8n.example.com/privkey.pem
Certificate File:
/etc/letsencrypt/live/n8n.example.com/fullchain.pem
Chained Certificate:
Yes
اطمینان پیدا کنید Listener مربوط به HTTPS روی پورت 443 فعال است و دامنه به Virtual Host صحیح Map شده است.
در صورت نیاز، تنظیمات SSL Listener را نیز بررسی کنید.
پس از ذخیره تغییرات، یک Graceful Restart انجام دهید.
اکنون آدرس HTTPS دامنه را آزمایش کنید.
نکته درباره دسترسی فایل‌های گواهی
OpenLiteSpeed باید بتواند فایل‌های موردنیاز را هنگام بارگذاری تنظیمات SSL بخواند.
اگر خطای دسترسی مشاهده کردید، مجوزهای فایل‌ها و فرایند وب‌سرور را بررسی کنید.
برای رفع مشکل، مجوز کلید خصوصی را به‌صورت عمومی باز نکنید.
مرحله هفتم: فعال‌سازی Redirect از HTTP به HTTPS
پس از فعال‌سازی موفق HTTPS بهتر است درخواست‌های HTTP به HTTPS هدایت شوند.
روش Nginx
اگر Certbot تنظیمات Redirect را اعمال نکرده است، می‌توانید یک Server Block مخصوص HTTP داشته باشید:
server {
listen 80;
server_name n8n.example.com;
return 301 https://$host$request_uri;
}
این تنظیم باید با پیکربندی فعلی Nginx هماهنگ باشد.
اگر Certbot از قبل Redirect را ایجاد کرده است، قانون تکراری اضافه نکنید.
روش OpenLiteSpeed
در Virtual Host مربوط به n8n می‌توانید از Rewrite Rule استفاده کنید:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://n8n.example.com/$1 [R=301,L]
این Rule باید در محل مناسب تنظیمات Rewrite قرار بگیرد.
اگر Cloudflare یا Proxy دیگری نیز HTTPS را مدیریت می‌کند، قبل از فعال‌سازی Redirect باید معماری کامل را بررسی کنید تا حلقه Redirect ایجاد نشود.
مرحله هشتم: تنظیم SSL برای n8n در Cloudflare
اگر دامنه شما از Cloudflare استفاده می‌کند، دو ارتباط مجزا وجود دارد:
Browser
|
| HTTPS
v
Cloudflare
|
| HTTPS
v
Origin Server
|
| HTTP داخلی
v
n8n
ارتباط اول بین مرورگر و Cloudflare است.
ارتباط دوم بین Cloudflare و سرور اصلی شما برقرار می‌شود.
برای امنیت مناسب باید هر دو ارتباط محافظت شوند.
تفاوت حالت‌های SSL در Cloudflare
| حالت | توضیح |
|---|---|
| Flexible | ارتباط Cloudflare تا Origin می‌تواند HTTP باشد |
| Full | ارتباط تا Origin رمزنگاری می‌شود، اما اعتبار گواهی به‌صورت سخت‌گیرانه بررسی نمی‌شود |
| Full (strict) | ارتباط تا Origin رمزنگاری شده و گواهی نیز اعتبارسنجی می‌شود |
برای یک سرویس عملیاتی، حالت Full (strict) معمولاً انتخاب مناسب‌تری است.
استفاده از Let's Encrypt در کنار Cloudflare
می‌توانید روی Origin یک گواهی Let's Encrypt معتبر نصب کنید و Cloudflare را روی Full (strict) قرار دهید.
در این حالت، اتصال مرورگر به Cloudflare و اتصال Cloudflare به Origin از HTTPS استفاده می‌کنند.
استفاده از Cloudflare Origin Certificate
Cloudflare امکان صدور Origin Certificate را نیز فراهم می‌کند.
این نوع گواهی برای ارتباط Cloudflare با Origin طراحی شده است.
تفاوت مهم آن با Let's Encrypt این است که Origin Certificate معمولاً توسط مرورگرهایی که مستقیماً به Origin متصل می‌شوند، به‌عنوان گواهی عمومی معتبر شناخته نمی‌شود.
بنابراین اگر قصد دارید دامنه در حالت DNS Only نیز مستقیماً در مرورگر باز شود، گواهی عمومی معتبری مانند Let's Encrypt انتخاب مناسب‌تری است.
مرحله نهم: تمدید خودکار SSL برای n8n
گواهی‌های TLS تاریخ انقضا دارند و باید پیش از انقضا تمدید شوند.
Certbot می‌تواند فرایند تمدید را خودکار کند.
بررسی گواهی‌های موجود
sudo certbot certificates
این دستور اطلاعات گواهی‌های مدیریت‌شده توسط Certbot را نمایش می‌دهد.
آزمایش تمدید
sudo certbot renew --dry-run
اگر آزمایش موفق باشد، فرایند تمدید در شرایط فعلی به‌درستی کار می‌کند.
بررسی زمان‌بندی خودکار
systemctl list-timers --all | grep certbot
بسته به روش نصب، Certbot ممکن است از Systemd Timer یا Cron برای تمدید استفاده کند.
قبل از ایجاد زمان‌بندی جدید، بررسی کنید مکانیزم تمدید خودکار از قبل فعال نباشد.
تمدید SSL در Nginx
اگر گواهی با پلاگین Nginx مدیریت می‌شود، Certbot می‌تواند تنظیمات مرتبط را نیز مدیریت کند.
برای بررسی نتیجه تمدید، از --dry-run استفاده کنید.
تمدید SSL در OpenLiteSpeed
در OpenLiteSpeed، اگر Certbot فقط گواهی را دریافت کند، ممکن است پس از تمدید نیاز باشد وب‌سرور مجدداً گواهی جدید را بارگذاری کند.
می‌توانید یک Deploy Hook ایجاد کنید تا فقط پس از تمدید موفق گواهی، Graceful Restart انجام شود.
ابتدا فایل Hook را ایجاد کنید:
sudo nano /etc/letsencrypt/renewal-hooks/deploy/reload-openlitespeed.sh
محتوا:
#!/bin/sh
set -e
/usr/local/lsws/bin/lswsctrl restart
سپس:
sudo chmod 700 \
/etc/letsencrypt/renewal-hooks/deploy/reload-openlitespeed.sh
قبل از استفاده عملیاتی، مسیر دستور کنترل و رفتار Restart را با نسخه OpenLiteSpeed نصب‌شده بررسی کنید.
همچنین اگر چند گواهی روی سرور دارید، ممکن است بخواهید Hook را فقط برای گواهی‌های مرتبط اجرا کنید.
مرحله دهم: بررسی صحت گواهی SSL
پس از نصب، بهتر است گواهی را از چند روش بررسی کنید.
بررسی با curl
curl -Iv https://n8n.example.com
در خروجی، وضعیت اتصال TLS و اعتبار گواهی را بررسی کنید.
بررسی با OpenSSL
openssl s_client \
-connect n8n.example.com:443 \
-servername n8n.example.com \
</dev/null
این دستور اطلاعات اتصال TLS و گواهی ارائه‌شده را نمایش می‌دهد.
برای مشاهده تاریخ انقضا:
echo | openssl s_client \
-connect n8n.example.com:443 \
-servername n8n.example.com 2>/dev/null \
| openssl x509 -noout -dates
خروجی شامل تاریخ شروع و پایان اعتبار گواهی خواهد بود.
بررسی از طریق مرورگر
آدرس HTTPS را باز کنید و اطلاعات امنیتی اتصال را مشاهده کنید.
اگر مرورگر خطای گواهی نمایش می‌دهد، نباید صرفاً با نادیده گرفتن هشدار وارد پنل مدیریتی شوید.
ابتدا علت خطا را مشخص کنید.
مرحله یازدهم: رفع خطای Secure Cookie در n8n
یکی از خطاهایی که ممکن است هنگام دسترسی به n8n مشاهده کنید، مربوط به Secure Cookie است.
متن خطا ممکن است مشابه این باشد:
Your n8n server is configured to use a secure cookie,
however you are either visiting this via an insecure URL,
or using Safari.
این پیام معمولاً زمانی ظاهر می‌شود که تنظیمات Cookie امن با نحوه دسترسی به n8n سازگار نیست.
چرا این خطا رخ می‌دهد؟
یکی از دلایل رایج این است که n8n برای استفاده از Cookie امن تنظیم شده، اما شما از طریق HTTP به آن دسترسی دارید.
برای مثال:
http://SERVER_IP:5678
درحالی‌که باید از آدرس HTTPS استفاده کنید:
https://n8n.example.com
راهکار پیشنهادی
ابتدا مطمئن شوید HTTPS به‌درستی فعال است.
سپس n8n را از طریق دامنه امن باز کنید.
متغیرهای عمومی را نیز بررسی کنید:
N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://n8n.example.com/
WEBHOOK_URL=https://n8n.example.com/
اگر مشکل ادامه داشت، تنظیمات Proxy و هدرهای Forwarded را بررسی کنید.
آیا باید N8N_SECURE_COOKIE را غیرفعال کنیم؟
متغیر زیر وجود دارد:
N8N_SECURE_COOKIE=false
اما غیرفعال کردن Secure Cookie برای یک پنل عمومی عملیاتی توصیه نمی‌شود.
این کار ممکن است محافظت Cookieهای نشست را کاهش دهد.
برای محیط واقعی بهتر است علت مشکل HTTPS را برطرف کنید و تنظیمات امنیتی را حفظ کنید.
مرحله دوازدهم: رفع خطای ERR_SSL_PROTOCOL_ERROR
اگر مرورگر خطای زیر را نمایش می‌دهد:
ERR_SSL_PROTOCOL_ERROR
احتمال دارد ارتباط TLS به‌درستی برقرار نشود.
دلایل احتمالی:
- سرویس HTTPS روی پورت 443 فعال نیست.
- Listener مربوط به SSL اشتباه تنظیم شده است.
- Reverse Proxy به‌جای HTTPS، پاسخ HTTP ارائه می‌دهد.
- تنظیمات TLS ناقص است.
- تداخل میان چند وب‌سرور وجود دارد.
بررسی پورت 443
sudo ss -lntp | grep ':443'
اگر هیچ سرویسی روی پورت 443 گوش نمی‌دهد، باید تنظیمات وب‌سرور را بررسی کنید.
بررسی پاسخ HTTPS
curl -Iv https://n8n.example.com
اگر TLS Handshake ناموفق باشد، خروجی این دستور می‌تواند به تشخیص مشکل کمک کند.
مرحله سیزدهم: رفع خطای NET::ERR_CERT_COMMON_NAME_INVALID
این خطا معمولاً زمانی رخ می‌دهد که نام دامنه مورد استفاده با نام‌های معتبر موجود در گواهی مطابقت ندارد.
برای مثال، گواهی برای دامنه زیر صادر شده است:
example.com
اما شما وارد این آدرس می‌شوید:
n8n.example.com
گواهی دامنه اصلی الزاماً زیردامنه را پوشش نمی‌دهد.
راهکار
اطمینان پیدا کنید گواهی شامل نام دامنه موردنظر باشد.
برای دریافت گواهی اختصاصی زیردامنه در Nginx:
sudo certbot --nginx -d n8n.example.com
اگر از OpenLiteSpeed استفاده می‌کنید، گواهی را با روش مناسب همان وب‌سرور دریافت و متصل کنید.
مرحله چهاردهم: رفع خطای گواهی منقضی‌شده
اگر گواهی منقضی شود، مرورگر ممکن است خطایی مانند زیر نمایش دهد:
NET::ERR_CERT_DATE_INVALID
ابتدا تاریخ سرور را بررسی کنید:
timedatectl
سپس گواهی‌های Certbot را مشاهده کنید:
sudo certbot certificates
برای تلاش جهت تمدید گواهی‌های واجد شرایط:
sudo certbot renew
پس از تمدید، مطمئن شوید وب‌سرور گواهی جدید را بارگذاری کرده است.
همچنین باید علت ناموفق بودن تمدید خودکار قبلی را بررسی کنید.
مرحله پانزدهم: رفع خطای Too Many Redirects
گاهی اوقات پس از فعال‌سازی SSL، مرورگر خطای زیر را نمایش می‌دهد:
ERR_TOO_MANY_REDIRECTS
این مشکل ممکن است ناشی از تنظیمات Redirect تکراری یا ناسازگار باشد.
برای مثال:
HTTP → HTTPS → HTTP → HTTPS
موارد قابل بررسی
- قوانین Redirect در Nginx
- قوانین Rewrite در OpenLiteSpeed
- تنظیمات Cloudflare
- مقدار
N8N_PROTOCOL - هدر
X-Forwarded-Proto - تنظیمات HTTPS در لایه‌های مختلف
برای بررسی مسیر Redirect:
curl -IL --max-redirs 10 https://n8n.example.com
اگر از Cloudflare استفاده می‌کنید، حالت Flexible را با تنظیمات Redirect اجباری HTTPS در Origin ترکیب نکنید.
در بسیاری از معماری‌ها، استفاده از Full (strict) همراه با گواهی معتبر روی Origin مناسب‌تر است.
مرحله شانزدهم: رفع مشکل Mixed Content
گاهی صفحه n8n با HTTPS باز می‌شود، اما مرورگر در Console خطای Mixed Content نمایش می‌دهد.
این خطا زمانی رخ می‌دهد که صفحه HTTPS تلاش کند منابع ناامن HTTP را بارگذاری کند.
برای مثال:
https://n8n.example.com
اما یک منبع از آدرس زیر درخواست شود:
http://n8n.example.com/resource
راهکار
ابتدا متغیرهای محیطی را بررسی کنید:
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://n8n.example.com/
WEBHOOK_URL=https://n8n.example.com/
سپس تنظیمات Reverse Proxy و هدرهای مربوط به پروتکل اصلی را بررسی کنید.
اگر مشکل مربوط به فایل یا سرویس خارجی است، باید آدرس آن منبع نیز اصلاح شود.
مرحله هفدهم: بررسی HTTPS در Webhookهای n8n
پس از نصب SSL، باید مطمئن شوید Webhookها با آدرس HTTPS صحیح ساخته می‌شوند.
در n8n یک Workflow جدید ایجاد کنید.
سپس Webhook Node را اضافه کنید.
برای مثال مسیر زیر را انتخاب کنید:
ssl-test
آدرس Test Webhook معمولاً مشابه زیر خواهد بود:
https://n8n.example.com/webhook-test/ssl-test
در حالت انتظار برای درخواست آزمایشی، می‌توانید اجرا کنید:
curl -X POST \
https://n8n.example.com/webhook-test/ssl-test \
-H "Content-Type: application/json" \
-d '{"status":"ssl-ok"}'
البته متد Webhook Node باید روی POST تنظیم شده باشد.
اگر درخواست به Workflow رسید، ارتباط HTTPS و مسیر Webhook در این آزمایش درست عمل کرده‌اند.
برای استفاده عملیاتی، Workflow را فعال یا منتشر کنید و Production Webhook را آزمایش کنید.
مرحله هجدهم: بررسی SSL در OAuth
هنگام اتصال سرویس‌هایی مانند Google به n8n، ممکن است لازم باشد یک Redirect URI در پنل توسعه‌دهندگان ثبت کنید.
پس از فعال‌سازی HTTPS، آدرس Redirect باید با آدرس عمومی n8n هماهنگ باشد.
برای مثال ممکن است Redirect URI در Credential مربوطه از دامنه HTTPS استفاده کند.
مقدار دقیق را از همان Credential در n8n دریافت کنید و در پنل سرویس مقصد ثبت کنید.
اگر دامنه یا پروتکل تغییر کرده باشد، ممکن است لازم باشد تنظیمات OAuth را به‌روزرسانی کنید.
مرحله نوزدهم: نکات امنیتی SSL برای n8n
برای استفاده عملیاتی، رعایت چند نکته ضروری است.
استفاده از گواهی معتبر
از گواهی صادرشده توسط مرجع معتبر استفاده کنید.
محافظت از کلید خصوصی
فایل privkey.pem نباید در اختیار کاربران غیرمجاز قرار بگیرد.
فعال‌سازی تمدید خودکار
انقضای گواهی می‌تواند باعث اختلال در پنل و Webhookها شود.
استفاده از TLS مناسب
نسخه‌ها و الگوریتم‌های رمزنگاری را متناسب با نسخه وب‌سرور و سیاست امنیتی خود تنظیم کنید.
عدم انتشار مستقیم پورت n8n
در نصب Docker با Reverse Proxy روی همان سرور، بهتر است پورت 5678 فقط روی localhost منتشر شود.
بررسی تنظیمات Cloudflare
اگر از Cloudflare استفاده می‌کنید، ارتباط تا Origin را نیز با TLS معتبر محافظت کنید.
مانیتورینگ تاریخ انقضا
علاوه بر تمدید خودکار، بهتر است برای نزدیک شدن به تاریخ انقضای گواهی هشدار دریافت کنید.
چک‌لیست نهایی فعال‌سازی SSL
پس از انجام مراحل، موارد زیر را بررسی کنید:
- [ ] دامنه به IP صحیح اشاره می‌کند.
- [ ] n8n روی سرور فعال است.
- [ ] پورت 443 در دسترس است.
- [ ] گواهی SSL معتبر است.
- [ ] نام دامنه با گواهی مطابقت دارد.
- [ ] آدرس HTTPS بدون هشدار باز می‌شود.
- [ ] Redirect از HTTP به HTTPS صحیح است.
- [ ] متغیرهای محیطی n8n تنظیم شده‌اند.
- [ ] Webhookها از HTTPS استفاده می‌کنند.
- [ ] اتصال OAuth در صورت نیاز بررسی شده است.
- [ ] تمدید خودکار گواهی فعال است.
- [ ] تست تمدید SSL موفق بوده است.
- [ ] کلید خصوصی گواهی محافظت می‌شود.
جمع‌بندی
در این مقاله یاد گرفتیم چگونه SSL را برای n8n فعال کنیم و پنل مدیریت و Webhookها را از طریق HTTPS در دسترس قرار دهیم.
ابتدا با مفهوم TLS و اهمیت آن آشنا شدیم، سپس روش دریافت گواهی رایگان Let's Encrypt را با Certbot بررسی کردیم.
در ادامه نحوه تنظیم HTTPS در Nginx و OpenLiteSpeed، اتصال گواهی به Reverse Proxy، استفاده از Cloudflare و تنظیم متغیرهای محیطی n8n را آموزش دادیم.
همچنین روش تمدید خودکار گواهی و رفع خطاهای رایج مانند Secure Cookie، خطای پروتکل SSL، گواهی نامعتبر، Mixed Content و Redirect Loop را بررسی کردیم.
فعال‌سازی SSL یکی از اقدامات پایه‌ای برای راه‌اندازی امن n8n است، اما باید در کنار سایر تنظیمات امنیتی سرور و برنامه انجام شود.
با یک پیکربندی صحیح می‌توانید n8n را از طریق دامنه اختصاصی و HTTPS اجرا کنید و ارتباط امن‌تری برای کاربران و سرویس‌های خارجی فراهم کنید.
سوالات متداول
آیا نصب SSL برای n8n ضروری است؟
برای استفاده عمومی و عملیاتی، HTTPS به‌شدت توصیه می‌شود. بسیاری از اتصال‌های خارجی و مکانیزم‌های امنیتی نیز به HTTPS معتبر وابسته هستند.
آیا SSL رایگان برای n8n وجود دارد؟
بله. می‌توانید از Let's Encrypt برای دریافت گواهی TLS معتبر و رایگان استفاده کنید.
آیا برای نصب SSL در n8n باید Docker را تغییر دهیم؟
اگر HTTPS توسط Reverse Proxy مدیریت می‌شود، معمولاً نیازی به نصب گواهی داخل کانتینر n8n نیست. کافی است متغیرهای عمومی و تنظیمات Proxy صحیح باشند.
آیا OpenLiteSpeed از SSL برای n8n پشتیبانی می‌کند؟
بله. می‌توانید گواهی را در OpenLiteSpeed تنظیم کنید و درخواست‌های HTTPS را به Backend مربوط به n8n منتقل کنید.
آیا می‌توان از Cloudflare Origin Certificate استفاده کرد؟
بله، در صورتی که ترافیک عمومی از Cloudflare عبور کند و ارتباط Cloudflare تا Origin به‌درستی تنظیم شده باشد. این گواهی جایگزین عمومی Let's Encrypt برای دسترسی مستقیم مرورگر به Origin نیست.
چرا n8n خطای Secure Cookie نمایش می‌دهد؟
یکی از دلایل رایج، دسترسی از طریق HTTP در حالی است که Cookie امن فعال است. بهتر است n8n را از طریق HTTPS معتبر باز کنید.
آیا می‌توان Secure Cookie را غیرفعال کرد؟
از نظر فنی امکان‌پذیر است، اما برای محیط عملیاتی عمومی توصیه نمی‌شود. بهتر است مشکل HTTPS را برطرف کنید.
چرا بعد از نصب SSL خطای 502 دریافت می‌کنم؟
خطای 502 معمولاً مربوط به ارتباط Reverse Proxy با Backend است و لزوماً از گواهی SSL ناشی نمی‌شود. وضعیت n8n، پورت داخلی و لاگ‌های وب‌سرور را بررسی کنید.
آیا Let's Encrypt گواهی را خودکار تمدید می‌کند؟
Certbot می‌تواند تمدید را به‌صورت خودکار انجام دهد، اما باید زمان‌بندی و بارگذاری مجدد گواهی توسط وب‌سرور را بررسی کنید.
آیا می‌توان برای چند نمونه n8n از یک SSL استفاده کرد؟
اگر چند نمونه روی زیردامنه‌های مختلف هستند، می‌توانید برای هر زیردامنه گواهی مستقل دریافت کنید یا در شرایط مناسب از گواهی چنددامنه‌ای یا Wildcard استفاده کنید.
آیا پس از فعال‌سازی SSL باید Workflowها را تغییر دهیم؟
معمولاً خود Workflowها نیازی به تغییر ندارند، اما آدرس‌های Webhook ثبت‌شده در سرویس‌های خارجی، تنظیمات OAuth و URLهای قدیمی باید بررسی شوند.
آیا می‌توان SSL را بدون دامنه فعال کرد؟
روش‌های خاصی برای گواهی‌های مبتنی بر IP یا محیط‌های داخلی وجود دارد، اما برای بیشتر نصب‌های عمومی n8n استفاده از دامنه اختصاصی ساده‌تر و مناسب‌تر است.
