اگر n8n را روی سرور مجازی، Docker یا سرور اختصاصی نصب کرده باشید، احتمالاً در ابتدا از طریق آدرسی مانند http://SERVER_IP:5678 به آن دسترسی دارید.
این روش برای آزمایش اولیه مناسب است، اما برای استفاده دائمی و حرفه‌ای، بهتر است n8n را به یک دامنه یا زیردامنه اختصاصی متصل کنید.
برای مثال، می‌توانید پنل n8n خود را از طریق آدرس زیر در دسترس قرار دهید:
https://n8n.example.com
اتصال دامنه به n8n فقط باعث زیباتر شدن آدرس پنل نمی‌شود؛ بلکه برای راه‌اندازی HTTPS، دریافت Webhook از سرویس‌های خارجی، مدیریت احراز هویت و استفاده از برخی اتصال‌های OAuth نیز اهمیت دارد.
در این مقاله قصد داریم اتصال دامنه به n8n را به‌صورت قدم‌به‌قدم آموزش دهیم. ابتدا رکوردهای DNS را تنظیم می‌کنیم، سپس متغیرهای محیطی n8n را بررسی خواهیم کرد و در ادامه روش اتصال دامنه با Nginx و OpenLiteSpeed را توضیح می‌دهیم.
همچنین نحوه استفاده از Cloudflare، تنظیم Webhook URL و رفع خطاهای رایج را بررسی می‌کنیم.
چرا باید دامنه را به n8n متصل کنیم؟
n8n به‌صورت پیش‌فرض معمولاً روی پورت 5678 اجرا می‌شود.
در یک نصب ساده ممکن است آدرس دسترسی به این شکل باشد:
http://203.0.113.10:5678
اما استفاده از IP و پورت برای محیط عملیاتی چند محدودیت دارد.
۱. استفاده از آدرس اختصاصی
با اتصال دامنه می‌توانید به‌جای IP از یک آدرس مشخص استفاده کنید:
https://automation.example.com
این روش مدیریت سرویس و اشتراک‌گذاری آدرس آن را آسان‌تر می‌کند.
۲. فعال‌سازی HTTPS
استفاده از HTTPS باعث رمزنگاری ارتباط بین مرورگر یا سرویس خارجی و سرور شما می‌شود.
برای پنل مدیریتی که Credentialها و اطلاعات حساس را مدیریت می‌کند، استفاده از HTTPS اهمیت زیادی دارد.
۳. دریافت Webhook
بسیاری از سرویس‌های خارجی برای ارسال رویدادها به یک آدرس HTTPS عمومی نیاز دارند.
برای مثال، یک فروشگاه اینترنتی می‌تواند پس از ثبت سفارش جدید، درخواست Webhook را به n8n ارسال کند.
۴. استفاده از OAuth
هنگام اتصال بعضی سرویس‌ها مانند Google، ممکن است لازم باشد یک Redirect URI مشخص و عمومی را در پنل توسعه‌دهندگان سرویس ثبت کنید.
وجود دامنه ثابت و HTTPS تنظیم این فرایند را ساده‌تر می‌کند.
۵. مدیریت چند سرویس روی یک سرور
ممکن است روی یک VPS چند برنامه داشته باشید:
example.com
api.example.com
n8n.example.com
panel.example.com
با استفاده از Reverse Proxy می‌توانید درخواست‌های هر دامنه را به سرویس مربوطه هدایت کنید.
پیش‌نیازهای اتصال دامنه به n8n
قبل از شروع، باید موارد زیر آماده باشند:
- یک دامنه فعال
- دسترسی به پنل DNS دامنه
- سرور لینوکسی با IP عمومی
- یک نمونه n8n در حال اجرا
- دسترسی SSH به سرور
- امکان استفاده از پورت‌های 80 و 443
- یک Reverse Proxy مانند Nginx یا OpenLiteSpeed
در این آموزش فرض می‌کنیم n8n روی همان سرور و پورت 5678 اجرا شده است.
آدرس نمونه سرور:
203.0.113.10
زیردامنه نمونه:
n8n.example.com
این مقادیر آموزشی هستند و باید با اطلاعات واقعی جایگزین شوند.
Reverse Proxy چیست و چه ارتباطی با n8n دارد؟
Reverse Proxy یک واسط بین کاربران و برنامه اصلی است.
در معماری معمول، مرورگر کاربر مستقیماً به پورت 5678 متصل نمی‌شود؛ بلکه درخواست را از طریق HTTPS به وب‌سرور ارسال می‌کند.
وب‌سرور درخواست را دریافت کرده و به n8n منتقل می‌کند.
ساختار ارتباط به شکل زیر است:
User / Webhook Provider
|
v
n8n.example.com
|
v
HTTPS 443
|
v
Nginx / OpenLiteSpeed
|
v
127.0.0.1:5678
|
v
n8n
استفاده از Reverse Proxy مزایای مهمی دارد:
- مدیریت گواهی SSL
- استفاده از چند دامنه روی یک سرور
- محدودسازی دسترسی مستقیم به پورت برنامه
- تنظیم هدرهای HTTP
- مدیریت درخواست‌های Webhook
- امکان اعمال سیاست‌های امنیتی
برای این کار می‌توانید از Nginx، OpenLiteSpeed، Caddy یا Traefik استفاده کنید.
در ادامه دو روش Nginx و OpenLiteSpeed را بررسی می‌کنیم.
مرحله اول: بررسی وضعیت n8n روی سرور
قبل از اتصال دامنه باید مطمئن شوید n8n به‌درستی اجرا می‌شود.
اگر n8n را با Docker Compose نصب کرده‌اید، وارد پوشه پروژه شوید:
cd /opt/n8n
سپس وضعیت سرویس‌ها را بررسی کنید:
sudo docker compose ps
اگر سرویس فعال باشد، باید کانتینر n8n را مشاهده کنید.
برای بررسی پاسخ‌گویی برنامه:
curl -i http://127.0.0.1:5678/healthz
اگر پاسخ موفق دریافت کردید، می‌توانید مرحله بعد را ادامه دهید.
اگر درخواست ناموفق بود، ابتدا لاگ‌های n8n را بررسی کنید:
sudo docker compose logs --tail=100 n8n
نکته: تا زمانی که خود n8n روی سرور پاسخ نمی‌دهد، تغییر تنظیمات DNS مشکل را برطرف نخواهد کرد.
مرحله دوم: تنظیم رکورد DNS دامنه
اکنون باید زیردامنه موردنظر را به IP سرور متصل کنید.
وارد پنل مدیریت DNS دامنه شوید.
این پنل ممکن است متعلق به شرکت ثبت‌کننده دامنه، ارائه‌دهنده هاست یا سرویس‌هایی مانند Cloudflare باشد.
ایجاد رکورد A
فرض کنیم IP سرور برابر است با:
203.0.113.10
و قصد دارید از زیردامنه زیر استفاده کنید:
n8n.example.com
یک رکورد DNS با مشخصات زیر ایجاد کنید:
| فیلد | مقدار |
|---|---|
| Type | A |
| Name | n8n |
| IPv4 Address | 203.0.113.10 |
| TTL | Auto یا 300 |
پس از ذخیره رکورد، DNS باید زیردامنه را به IP سرور هدایت کند.
اتصال دامنه اصلی به n8n
اگر قصد دارید n8n روی دامنه اصلی اجرا شود، معمولاً باید رکورد A مربوط به دامنه اصلی را تنظیم کنید.
برای مثال:
example.com
در بسیاری از پنل‌های DNS از @ برای اشاره به دامنه اصلی استفاده می‌شود.
اما اگر روی دامنه اصلی وب‌سایت دیگری دارید، بهتر است برای n8n یک زیردامنه مستقل ایجاد کنید.
بررسی رکورد DNS
در سرور یا کامپیوتر خود اجرا کنید:
dig +short n8n.example.com A
اگر IP صحیح نمایش داده شود، رکورد A قابل Resolve شدن است.
برای بررسی از طریق یک DNS Resolver مشخص:
dig @1.1.1.1 n8n.example.com A +short
اگر خروجی با مقدار موردنظر متفاوت بود، تنظیمات DNS و وضعیت انتشار تغییرات را بررسی کنید.
بررسی رکورد IPv6
اگر دامنه دارای رکورد AAAA است، باید مطمئن شوید IPv6 نیز به سرور صحیح اشاره می‌کند.
برای بررسی:
dig +short n8n.example.com AAAA
وجود رکورد AAAA اشتباه می‌تواند باعث شود برخی کاربران هنگام اتصال به دامنه با مشکل مواجه شوند.
اگر از IPv6 استفاده نمی‌کنید، رکورد AAAA غیرضروری یا اشتباه را پس از بررسی حذف کنید.
مرحله سوم: تنظیم متغیرهای محیطی n8n
یکی از مهم‌ترین مراحل اتصال دامنه، تنظیم آدرس عمومی n8n است.
اگر n8n با Docker Compose اجرا می‌شود، معمولاً فایل تنظیمات در مسیر زیر قرار دارد:
/opt/n8n/.env
فایل را باز کنید:
nano /opt/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 را مشخص می‌کند.
N8N_HOST=n8n.example.com
کاربرد N8N_PROTOCOL
پروتکل آدرس عمومی را تعیین می‌کند.
N8N_PROTOCOL=https
اگر Reverse Proxy ارتباط HTTPS را مدیریت می‌کند، آدرس عمومی n8n می‌تواند HTTPS باشد، حتی اگر ارتباط داخلی Proxy با کانتینر از طریق HTTP انجام شود.
کاربرد N8N_EDITOR_BASE_URL
این متغیر آدرس عمومی محیط ویرایشگر n8n را مشخص می‌کند.
N8N_EDITOR_BASE_URL=https://n8n.example.com/
کاربرد WEBHOOK_URL
این متغیر یکی از مهم‌ترین تنظیمات هنگام استفاده از Webhook است.
WEBHOOK_URL=https://n8n.example.com/
با این تنظیم، n8n می‌تواند آدرس‌های Webhook را براساس دامنه عمومی ایجاد کند.
کاربرد N8N_PROXY_HOPS
این متغیر تعداد لایه‌های Reverse Proxy قابل اعتماد را در مسیر درخواست مشخص می‌کند.
N8N_PROXY_HOPS=1
در معماری‌ای که فقط یک Reverse Proxy مانند Nginx مستقیماً جلوی n8n قرار دارد، مقدار 1 معمولاً مناسب است.
اگر از چند لایه Proxy استفاده می‌کنید، باید مقدار آن را مطابق معماری واقعی و مرزهای اعتماد شبکه تنظیم کنید.
مرحله چهارم: اعمال متغیرهای محیطی در Docker Compose
یک نکته مهم وجود دارد: قرار دادن متغیرها در فایل .env به‌تنهایی به معنی ارسال خودکار تمام آن‌ها به کانتینر نیست.
اگر فایل Compose از متغیرها استفاده نمی‌کند، باید آن‌ها را به بخش environment سرویس n8n اضافه کنید.
برای مثال:
services:
n8n:
image: docker.n8n.io/n8nio/n8n:latest
ports:
- "127.0.0.1:5678:5678"
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}
این بخش صرفاً نمونه‌ای از تنظیمات مربوط به دامنه است؛ اگر فایل Compose شما شامل PostgreSQL، Volume و سایر متغیرهاست، آن تنظیمات را حفظ کنید.
پس از ذخیره فایل، ساختار Compose را بررسی کنید:
sudo docker compose config --quiet
سپس سرویس n8n را با تنظیمات جدید ایجاد کنید:
sudo docker compose up -d --no-deps n8n
برای اطمینان از اعمال تنظیمات:
sudo docker compose exec n8n printenv WEBHOOK_URL
اگر آدرس دامنه صحیح نمایش داده شد، متغیر به کانتینر منتقل شده است.
مرحله پنجم: اتصال دامنه به n8n با Nginx
در این روش از Nginx به‌عنوان Reverse Proxy استفاده می‌کنیم.
این روش برای سرورهایی مناسب است که Nginx روی آن‌ها نصب شده یا قصد دارید آن را به‌عنوان وب‌سرور اصلی استفاده کنید.
توجه: اگر OpenLiteSpeed یا وب‌سرور دیگری از قبل روی پورت‌های 80 و 443 اجرا می‌شود، نباید Nginx را بدون تغییر معماری روی همان پورت‌ها اجرا کنید.
نصب Nginx
در Ubuntu اجرا کنید:
sudo apt update
sudo apt install nginx -y
وضعیت سرویس را بررسی کنید:
sudo systemctl status nginx
ایجاد Virtual Host
فایل تنظیمات دامنه را ایجاد کنید:
sudo nano /etc/nginx/sites-available/n8n
محتوای زیر را وارد کنید:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
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 $connection_upgrade;
proxy_read_timeout 300s;
proxy_send_timeout 300s;
}
}
دستور map باید در محدوده http پیکربندی Nginx قرار بگیرد. در نصب معمول Ubuntu، فایل‌های sites-enabled داخل همین محدوده بارگذاری می‌شوند.
اگر ساختار Nginx شما متفاوت است، محل قرارگیری این دستور را بررسی کنید.
توضیح تنظیمات
server_name دامنه موردنظر را مشخص می‌کند.
proxy_pass درخواست‌ها را به n8n منتقل می‌کند.
X-Forwarded-Proto پروتکل درخواست اصلی را به برنامه منتقل می‌کند.
X-Forwarded-For اطلاعات مسیر IP درخواست را منتقل می‌کند.
هدرهای Upgrade و Connection برای پشتیبانی از ارتباط‌های Upgrade مانند WebSocket کاربرد دارند.
فعال‌سازی Virtual Host
فایل را فعال کنید:
sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/n8n
اگر لینک از قبل وجود دارد، از ایجاد نسخه تکراری خودداری کنید.
سپس صحت تنظیمات را بررسی کنید:
sudo nginx -t
اگر خطایی وجود نداشت:
sudo systemctl reload nginx
اکنون Nginx باید درخواست‌های HTTP دامنه را به n8n منتقل کند.
مرحله ششم: فعال‌سازی HTTPS با Let's Encrypt
پس از اتصال دامنه به Nginx باید HTTPS را فعال کنید.
برای این کار از Certbot استفاده می‌کنیم.
ابتدا نصب کنید:
sudo apt install certbot python3-certbot-nginx -y
سپس:
sudo certbot --nginx -d n8n.example.com
برای صدور موفق گواهی باید:
- دامنه به IP صحیح اشاره کند.
- پورت 80 از اینترنت قابل دسترسی باشد.
- Nginx برای دامنه به‌درستی تنظیم شده باشد.
- اعتبارسنجی Let's Encrypt موفق شود.
پس از صدور گواهی، Certbot می‌تواند تنظیمات HTTPS را به Virtual Host اضافه کند.
اکنون آدرس زیر را باز کنید:
https://n8n.example.com
بررسی تمدید خودکار SSL
برای آزمایش فرایند تمدید:
sudo certbot renew --dry-run
اگر آزمایش موفق باشد، تنظیمات تمدید در شرایط فعلی درست عمل می‌کنند.
مرحله هفتم: اتصال دامنه به n8n با OpenLiteSpeed
اگر روی سرور شما OpenLiteSpeed نصب است، نیازی نیست حتماً Nginx نصب کنید.
OpenLiteSpeed نیز می‌تواند به‌عنوان Reverse Proxy عمل کند.
در این روش فرض می‌کنیم:
- OpenLiteSpeed روی سرور فعال است.
- n8n روی
127.0.0.1:5678اجرا می‌شود. - دامنه به IP سرور اشاره می‌کند.
- دسترسی به پنل WebAdmin وجود دارد.
ورود به پنل OpenLiteSpeed
آدرس پنل مدیریت معمولاً به شکل زیر است:
https://SERVER_IP:7080
بهتر است دسترسی به پورت مدیریتی 7080 را فقط برای IPهای مجاز یا از طریق SSH Tunnel فراهم کنید.
ایجاد Virtual Host
در پنل OpenLiteSpeed به بخش زیر بروید:
Virtual Hosts
برای زیردامنه n8n یک Virtual Host اختصاصی ایجاد کنید یا Virtual Host موجود را انتخاب کنید.
سپس مطمئن شوید دامنه در تنظیمات Listenerهای HTTP و HTTPS به Virtual Host صحیح متصل شده است.
نکته: ساخت Virtual Host به‌تنهایی کافی نیست. اگر Listener Mapping وجود نداشته باشد، درخواست دامنه ممکن است به Virtual Host دیگری منتقل شود.
ایجاد External App
در تنظیمات Virtual Host به بخش External App بروید.
یک External App جدید از نوع Web Server ایجاد کنید.
مقادیر نمونه:
| تنظیم | مقدار |
|---|---|
| Type | Web Server |
| Name | n8n_backend |
| Address | 127.0.0.1:5678 |
| Max Connections | 100 |
مقدار Max Connections باید متناسب با منابع و بار واقعی سرور انتخاب شود.
در این مثال نام External App برابر n8n_backend است.
ایجاد Proxy Context
اکنون در تنظیمات همان Virtual Host به بخش Context بروید.
یک Context جدید از نوع Proxy ایجاد کنید.
تنظیمات:
| تنظیم | مقدار |
|---|---|
| Type | Proxy |
| URI | / |
| Web Server | n8n_backend |
با این تنظیم، درخواست‌های مسیر اصلی دامنه به Backend مربوط به n8n هدایت می‌شوند.
اگر در همان Virtual Host از قبل Context یا Rewrite Rule دیگری وجود دارد، باید تداخل احتمالی را بررسی کنید.
اعمال تغییرات
پس از ذخیره تنظیمات، از قابلیت Graceful Restart استفاده کنید.
سپس دامنه را آزمایش کنید.
اگر SSL از قبل روی Listener مربوطه تنظیم شده باشد، می‌توانید از HTTPS استفاده کنید.
در غیر این صورت باید گواهی SSL را نیز برای دامنه پیکربندی کنید.
روش جایگزین با Rewrite Rule
OpenLiteSpeed از Proxy کردن درخواست‌ها با Rewrite Rule نیز پشتیبانی می‌کند.
برای مثال، در شرایط مناسب می‌توان از یک Rule مانند زیر استفاده کرد:
RewriteEngine On
RewriteRule ^(.*)$ http://127.0.0.1:5678/$1 [P,L]
این Rule باید در محدوده درست تنظیمات Rewrite قرار گیرد و با سایر Ruleها تداخل نداشته باشد.
اگر Virtual Host از قبل برای یک سایت دیگر استفاده می‌شود، اعمال چنین Rule عمومی می‌تواند تمام درخواست‌های آن سایت را به n8n منتقل کند.
بنابراین برای n8n معمولاً بهتر است یک Virtual Host مستقل با Proxy Context اختصاصی داشته باشید.
بررسی ارتباط WebSocket در OpenLiteSpeed
بسته به نسخه n8n و تنظیمات Push Backend، محیط ویرایشگر ممکن است از WebSocket یا روش‌های ارتباطی دیگر برای دریافت رویدادهای زنده استفاده کند.
اگر صفحه n8n باز می‌شود اما وضعیت اجرای Nodeها یا اتصال زنده ویرایشگر به‌درستی کار نمی‌کند، تنظیمات Proxy مربوط به WebSocket و هدرهای Upgrade را بررسی کنید.
در این شرایط باید پشتیبانی WebSocket را متناسب با نسخه OpenLiteSpeed و ساختار Proxy فعال کنید.
مرحله هشتم: اتصال n8n به Cloudflare
اگر DNS دامنه خود را در Cloudflare مدیریت می‌کنید، می‌توانید از آن برای مدیریت رکوردها و در صورت نیاز Proxy کردن ترافیک استفاده کنید.
ایجاد رکورد DNS
در بخش DNS یک رکورد A ایجاد کنید:
Type: A
Name: n8n
Content: SERVER_IP
در Cloudflare معمولاً دو حالت برای رکورد وجود دارد:
DNS Only: درخواست کاربران مستقیماً به IP سرور هدایت می‌شود.
Proxied: درخواست‌ها ابتدا از شبکه Cloudflare عبور می‌کنند.
کدام حالت برای n8n بهتر است؟
برای عیب‌یابی اولیه، DNS Only معمولاً ساده‌تر است؛ زیرا یک لایه Proxy کمتر در مسیر وجود دارد.
پس از اطمینان از عملکرد دامنه و HTTPS می‌توانید حالت Proxied را نیز بررسی کنید.
تنظیم SSL/TLS در Cloudflare
اگر از حالت Proxied استفاده می‌کنید، بهتر است ارتباط Cloudflare تا سرور اصلی نیز با TLS معتبر محافظت شود.
حالت Full (strict) برای این سناریو مناسب است، مشروط بر اینکه گواهی معتبر و مورد قبول Cloudflare روی Origin تنظیم شده باشد.
از تنظیمات ناسازگار مانند ترکیب Redirect اجباری HTTPS روی Origin با حالت Flexible خودداری کنید؛ زیرا ممکن است باعث Redirect Loop شوند.
آیا Cloudflare روی Webhookها تأثیر دارد؟
بله، ممکن است.
اگر قوانین امنیتی، WAF، Bot Protection یا Rate Limiting فعال باشند، بعضی درخواست‌های Webhook ممکن است مسدود شوند.
برای مثال، اگر یک سرویس خارجی درخواست POST به مسیر زیر ارسال کند:
https://n8n.example.com/webhook/order-created
و Cloudflare آن را Challenge یا Block کند، درخواست ممکن است به n8n نرسد.
در این شرایط باید رویدادهای امنیتی Cloudflare را بررسی کنید و فقط برای مسیرها و فرستندگان مورد اعتماد، استثناهای محدود و امن تعریف کنید.
مرحله نهم: تست آدرس Webhook پس از اتصال دامنه
پس از اتصال دامنه، باید مطمئن شوید n8n آدرس‌های Webhook را صحیح تولید می‌کند.
ایجاد Workflow آزمایشی
در پنل n8n یک Workflow جدید ایجاد کنید.
سپس Webhook Node را اضافه کنید.
متد درخواست را روی POST قرار دهید.
برای مسیر Webhook مقدار زیر را انتخاب کنید:
test-domain
آدرس آزمایشی معمولاً به شکل زیر خواهد بود:
https://n8n.example.com/webhook-test/test-domain
اکنون در محیط ویرایشگر روی Listen for Test Event کلیک کنید.
از کامپیوتر یا یک سرور دیگر درخواست زیر را ارسال کنید:
curl -X POST \
https://n8n.example.com/webhook-test/test-domain \
-H "Content-Type: application/json" \
-d '{"message":"Hello n8n"}'
اگر درخواست به Workflow برسد، اطلاعات ارسالی در خروجی Webhook Node نمایش داده می‌شود.
آزمایش Production Webhook
برای استفاده دائمی، Workflow را فعال یا منتشر کنید.
سپس از آدرس Production استفاده کنید:
https://n8n.example.com/webhook/test-domain
آدرس Production باید براساس تنظیمات واقعی Webhook Node بررسی شود.
برای سرویس‌های خارجی، معمولاً باید همین آدرس را در تنظیمات Webhook آن سرویس ثبت کنید.
امنیت Webhook
درخواست‌های Webhook را صرفاً به دلیل داشتن یک URL عمومی معتبر فرض نکنید.
برای Workflowهای حساس، از روش‌هایی مانند اعتبارسنجی امضا، توکن محرمانه، احراز هویت یا بررسی فرستنده استفاده کنید.
مرحله دهم: بررسی تنظیمات OAuth پس از تغییر دامنه
اگر از n8n برای اتصال به سرویس‌هایی مانند Google استفاده می‌کنید، تغییر دامنه ممکن است روی Redirect URI تأثیر بگذارد.
برای مثال، ممکن است قبلاً n8n از طریق IP یا دامنه قدیمی اجرا شده باشد.
پس از تغییر دامنه باید آدرس OAuth Redirect نمایش‌داده‌شده در Credential مربوطه را بررسی کنید.
در صورت نیاز، همان آدرس دقیق را در پنل توسعه‌دهندگان سرویس مقصد ثبت کنید.
نکته: آدرس Redirect URI را حدس نزنید. مقدار صحیح را از تنظیمات Credential همان نسخه n8n بردارید.
مرحله یازدهم: جلوگیری از دسترسی مستقیم به پورت 5678
یکی از اقدامات مهم امنیتی این است که کاربران فقط از طریق Reverse Proxy به n8n دسترسی داشته باشند.
اگر n8n با Docker اجرا می‌شود، می‌توانید پورت را فقط روی localhost منتشر کنید:
ports:
- "127.0.0.1:5678:5678"
با این تنظیم، پورت 5678 از طریق IP عمومی سرور مستقیماً منتشر نمی‌شود.
برای بررسی:
sudo ss -lntp | grep 5678
در یک ساختار صحیح، انتظار داریم Bind مربوط به پورت منتشرشده روی آدرس localhost باشد.
اگر n8n روی سرور دیگری اجرا می‌شود، باید به‌جای localhost از شبکه خصوصی امن یا اتصال مناسب بین دو سرور استفاده کنید.
مرحله دوازدهم: رفع خطای 502 Bad Gateway
خطای 502 یکی از مشکلات رایج هنگام اتصال دامنه به n8n است.
این خطا معمولاً زمانی رخ می‌دهد که Reverse Proxy نتواند پاسخ معتبری از Backend دریافت کند.
بررسی اول: وضعیت n8n
sudo docker compose ps
بررسی دوم: پاسخ مستقیم Backend
curl -i http://127.0.0.1:5678/healthz
بررسی سوم: لاگ‌های n8n
sudo docker compose logs --tail=100 n8n
بررسی چهارم: لاگ‌های Nginx
اگر از Nginx استفاده می‌کنید:
sudo tail -n 100 /var/log/nginx/error.log
اگر از OpenLiteSpeed استفاده می‌کنید، مسیر Error Log مربوط به Virtual Host و لاگ اصلی LiteSpeed را بررسی کنید.
دلایل احتمالی
- کانتینر n8n متوقف شده است.
- پورت Backend اشتباه تنظیم شده است.
- Reverse Proxy به IP یا پورت اشتباه متصل می‌شود.
- ارتباط شبکه بین Proxy و کانتینر برقرار نیست.
- سرویس n8n هنگام پردازش درخواست دچار خطا شده است.
مرحله سیزدهم: رفع مشکل Too Many Redirects
اگر هنگام باز کردن دامنه با خطای ERR_TOO_MANY_REDIRECTS مواجه شدید، احتمالاً یک حلقه Redirect ایجاد شده است.
برای مثال:
HTTP → HTTPS → HTTP → HTTPS
این مشکل ممکن است ناشی از تنظیمات ناسازگار میان Cloudflare، Reverse Proxy و برنامه باشد.
موارد قابل بررسی
- وضعیت SSL/TLS در Cloudflare
- قوانین Redirect در Nginx یا OpenLiteSpeed
- متغیر
N8N_PROTOCOL - هدر
X-Forwarded-Proto - تنظیمات HTTPS در لایه‌های مختلف
برای مشاهده مسیر Redirect:
curl -IL --max-redirs 10 https://n8n.example.com
اگر Redirectها تکرار می‌شوند، باید مشخص کنید کدام لایه آن‌ها را ایجاد می‌کند.
از اضافه کردن چند قانون Redirect مشابه در لایه‌های مختلف بدون بررسی نتیجه خودداری کنید.
مرحله چهاردهم: چرا آدرس Webhook هنوز localhost است؟
گاهی اوقات با وجود اتصال دامنه، n8n همچنان آدرس Webhook را با localhost یا پورت 5678 نمایش می‌دهد.
برای مثال:
http://localhost:5678/webhook/example
این مشکل معمولاً به تنظیمات آدرس عمومی مربوط است.
ابتدا بررسی کنید مقدار WEBHOOK_URL صحیح باشد:
WEBHOOK_URL=https://n8n.example.com/
سپس مطمئن شوید این متغیر واقعاً به کانتینر منتقل شده است:
sudo docker compose exec n8n printenv WEBHOOK_URL
اگر مقدار صحیح نبود، تنظیمات Compose را اصلاح کنید.
سپس کانتینر را مجدداً ایجاد کنید:
sudo docker compose up -d --no-deps n8n
پس از راه‌اندازی، آدرس Webhook را دوباره بررسی کنید.
مرحله پانزدهم: رفع مشکل اتصال زنده ویرایشگر n8n
ممکن است پنل n8n باز شود، اما هنگام اجرای Workflow وضعیت Nodeها به‌درستی به‌روزرسانی نشود.
گاهی در Console مرورگر نیز خطاهای ارتباطی مشاهده می‌شود.
دلایل احتمالی:
- تنظیم نبودن WebSocket Proxy
- قطع شدن ارتباط توسط Reverse Proxy
- Timeout کوتاه
- تنظیمات نادرست HTTPS
- مسدود شدن درخواست توسط Cloudflare یا WAF
- مشکلات شبکه یا خود سرویس n8n
برای عیب‌یابی، در مرورگر بخش Developer Tools را باز کنید.
سپس درخواست‌های Network را بررسی کنید.
اگر ارتباط WebSocket استفاده می‌شود، وضعیت Handshake و پاسخ سرور را بررسی کنید.
همچنین لاگ‌های Reverse Proxy و n8n را هم‌زمان مشاهده کنید تا مشخص شود درخواست در کدام مرحله قطع می‌شود.
مرحله شانزدهم: اتصال چند دامنه به n8n
از نظر فنی می‌توانید چند دامنه را به یک Backend هدایت کنید.
برای مثال:
n8n.example.com
automation.example.com
اما بهتر است یک آدرس عمومی اصلی برای پنل و Webhookها انتخاب کنید.
دلیل این موضوع آن است که استفاده از چند آدرس عمومی ممکن است باعث پیچیدگی در موارد زیر شود:
- OAuth Redirect URI
- Webhook URL
- Cookieها
- تنظیمات CORS و Origin
- لینک‌های تولیدشده توسط n8n
اگر به چند دامنه نیاز دارید، بهتر است یک دامنه را به‌عنوان دامنه اصلی تعیین کنید و برای سایر دامنه‌ها Redirect مناسب در نظر بگیرید.
مرحله هفدهم: چک‌لیست نهایی اتصال دامنه
پس از انجام تنظیمات، موارد زیر را بررسی کنید:
- [ ] رکورد DNS به IP صحیح اشاره می‌کند.
- [ ] n8n روی سرور فعال است.
- [ ] Reverse Proxy به Backend صحیح متصل می‌شود.
- [ ] گواهی SSL معتبر است.
- [ ] آدرس پنل با HTTPS باز می‌شود.
- [ ] متغیر
WEBHOOK_URLصحیح است. - [ ] متغیر
N8N_EDITOR_BASE_URLصحیح است. - [ ] تعداد Proxyهای مورد اعتماد درست تنظیم شده است.
- [ ] Test Webhook کار می‌کند.
- [ ] Production Webhook کار می‌کند.
- [ ] ارتباط زنده محیط ویرایشگر برقرار است.
- [ ] پورت 5678 بدون ضرورت در اینترنت منتشر نشده است.
- [ ] تنظیمات OAuth پس از تغییر دامنه بررسی شده‌اند.
جمع‌بندی
در این مقاله یاد گرفتیم چگونه دامنه یا زیردامنه اختصاصی را به n8n متصل کنیم.
ابتدا رکوردهای DNS را تنظیم کردیم و سپس متغیرهای محیطی مهم مانند N8N_HOST، N8N_EDITOR_BASE_URL و WEBHOOK_URL را بررسی کردیم.
در ادامه نحوه اتصال دامنه با Nginx و OpenLiteSpeed را آموزش دادیم و روش فعال‌سازی HTTPS با Let's Encrypt را توضیح دادیم.
همچنین تنظیمات Cloudflare، آزمایش Webhook، بررسی OAuth و رفع خطاهای رایج مانند 502 و Redirect Loop را بررسی کردیم.
با اجرای صحیح این مراحل می‌توانید n8n را از طریق یک آدرس اختصاصی و امن در دسترس قرار دهید و از آن برای اجرای Workflowهای واقعی استفاده کنید.
سوالات متداول
آیا برای اتصال دامنه به n8n باید Docker داشته باشیم؟
خیر. اتصال دامنه از طریق Reverse Proxy انجام می‌شود و به روش نصب n8n محدود نیست. با این حال، Docker یکی از روش‌های رایج اجرای n8n است.
آیا می‌توان n8n را روی زیردامنه اجرا کرد؟
بله. می‌توانید از زیردامنه‌هایی مانند n8n.example.com یا automation.example.com استفاده کنید.
آیا برای اتصال دامنه به n8n باید پورت 5678 باز باشد؟
پورت باید برای Reverse Proxy قابل دسترسی باشد، اما معمولاً نیازی نیست آن را مستقیماً در اینترنت منتشر کنید.
آیا n8n با OpenLiteSpeed کار می‌کند؟
بله. OpenLiteSpeed می‌تواند درخواست‌های دامنه را از طریق Reverse Proxy به n8n منتقل کند.
آیا می‌توان از Cloudflare برای n8n استفاده کرد؟
بله. می‌توانید DNS دامنه را در Cloudflare مدیریت کنید و در صورت نیاز از قابلیت Proxy آن استفاده کنید. باید تنظیمات SSL و قوانین امنیتی را نیز بررسی کنید.
چرا Webhook در n8n آدرس localhost نمایش می‌دهد؟
معمولاً به این دلیل است که WEBHOOK_URL تنظیم نشده یا مقدار آن به کانتینر منتقل نشده است.
آیا اتصال دامنه باعث فعال شدن SSL می‌شود؟
خیر. اتصال DNS و فعال‌سازی SSL دو مرحله متفاوت هستند. برای HTTPS باید گواهی معتبر و تنظیمات وب‌سرور مناسب داشته باشید.
چرا n8n پس از اتصال دامنه خطای 502 می‌دهد؟
این خطا معمولاً به مشکل ارتباط Reverse Proxy با Backend مربوط است. باید وضعیت کانتینر، پورت و لاگ‌های وب‌سرور بررسی شود.
آیا می‌توان n8n را بدون Reverse Proxy به دامنه متصل کرد؟
از نظر فنی روش‌های دیگری نیز وجود دارد، اما برای محیط عملیاتی استفاده از Reverse Proxy با HTTPS معمولاً مدیریت امنیت و گواهی‌ها را ساده‌تر می‌کند.
آیا بعد از تغییر دامنه باید Workflowها را دوباره بسازیم؟
معمولاً خیر. اما باید آدرس‌های Webhook ثبت‌شده در سرویس‌های خارجی، تنظیمات OAuth و هر URL قدیمی که در Workflowها استفاده شده است را بررسی و در صورت نیاز اصلاح کنید.
