آموزش جامع راه‌اندازی Reverse Proxy با Nginx + (کانفیگ SSL و داکر)

راه‌اندازی ریورس پروکسی (Reverse Proxy) یکی از آن مهارت‌های کلیدی است که مرز بین یک ادمین معمولی و یک متخصص حرفه‌ای سرور را مشخص می‌کند. به زبان خیلی ساده، وقتی شما چندین سرویس یا اپلیکیشن (مثل نود جی‌اس یا پایتون) روی پورت‌های مختلف سرور دارید، نیاز به یک “ناظم” دارید که درخواست‌های کاربران را از پورت 80 یا 443 دریافت کرده و به دست سرویس مربوطه برساند. اینجاست که کلمه اصلی یعنی Reverse Proxy Nginx وارد میدان می‌شود.

در سال 2025 و 2026، با پیچیده‌تر شدن معماری‌های میکروسرویس و داکر، استفاده از یک لایه واسط برای مدیریت ترافیک دیگر یک انتخاب نیست، بلکه یک ضرورت است. بیایید نگاهی گذرا به مزایای این کار بیندازیم:

حتماً زمانی که این مقاله را باز کرده‌اید، به دنبال راهی هستید که اپلیکیشن‌های خود را با امنیت بالا و تحت پروتکل HTTPS در دسترس کاربران قرار دهید. اگر از گشتن میان آموزش‌های پراکنده خسته شده‌اید، این راهنمای گام‌به‌گام برای شماست. ما از نصب ابتدایی روی اوبونتو تا تنظیمات پیشرفته هدرها و داکر را با هم بررسی خواهیم کرد. پس همراه ما باشید… 😉

Nginx Reverse Proxy چیست؟

بیایید با یک تشبیه کاربردی شروع کنیم؛ تصور کنید وارد یک هتل بزرگ می‌شوید. شما مستقیماً به اتاق آشپزخانه یا بخش نظافت نمی‌روید؛ بلکه ابتدا با “پذیرش” صحبت می‌کنید. پذیرش درخواست شما را می‌شنود و شما را به بخش مربوطه هدایت می‌کند. در دنیای شبکه، Nginx Reverse Proxy همان بخش پذیرش است.

در واقع، کلاینت‌ها (کاربران شما) هرگز مستقیماً با اپلیکیشن شما (که مثلاً روی پورت 3000 اجرا می‌شود) صحبت نمی‌کنند. آن‌ها با Nginx روی پورت 80 صحبت کرده و Nginx درخواست را به پورت داخلی می‌فرستد.

نمودار ساختار پروکسی معکوس:

      اینترنت (کاربران)
           ⬇️
      [ Nginx Proxy ] (Port 80/443)
           ⬇️
    ┌──────┴──────┐
    ⬇️            ⬇️
[App 1: Node.js] [App 2: Python]
 (Port 3000)      (Port 8000)

چرا به راه‌اندازی ریورس پروکسی (Nginx Reverse Proxy) نیاز داریم؟

بسیاری از کاربران عادی می‌پرسند: “چرا مستقیماً پورت اپلیکیشن را باز نکنیم؟”. پاسخ در سه کلمه خلاصه می‌شود: امنیت، سرعت و سادگی.

• امنیت در ریورس پروکسی: سرور اصلی شما پشت Nginx مخفی می‌ماند؛ بنابراین هکرها نمی‌توانند مستقیماً به ساختار اپلیکیشن شما حمله کنند؛
• چگونه چند سایت را با یک IP بالا بیاوریم؟: این یکی از بزرگترین چالش‌هاست. با Nginx می‌توانید بی‌نهایت دامنه را روی یک آی‌پی داشته باشید و هر کدام را به یک پورت داخلی متصل کنید؛
• متمرکزسازی SSL: به جای اینکه روی هر اپلیکیشن جداگانه SSL نصب کنید، فقط یک بار روی Nginx تنظیمش می‌کنید؛
• فشرده‌سازی محتوا: Nginx می‌تواند قبل از ارسال اطلاعات به کاربر، آن‌ها را فشرده (Gzip) کند تا سرعت لود سایت افزایش یابد.

پیش‌نیازهای نصب Nginx روی اوبونتو

قبل از شروع آموزش Nginx در لینوکس، باید موارد زیر را آماده داشته باشید:

• یک عدد سرور مجازی (VPS) با سیستم‌عامل اوبونتو (ترجیحاً نسخه 22.04 یا 24.04)؛
• دسترسی کاربر root یا دسترسی sudo؛
• باز بودن پورت‌های 80 (HTTP) و 443 (HTTPS) در فایروال.

سرور مجازی وب داده

VPS وب داده با حضور قدرتمند در بیش از 9 لوکیشن استراتژیک در سراسر جهان…

برای مشاهده موقعیت‌های
سرور های مجازی وب‌داده
روی دکمه زیر کلیک کنید

خرید سرور مجازی

آموزش عملی کانفیگ Nginx به عنوان پروکسی

در این بخش همراه تیم وب‌داده باشید تا به صورت عملی و تصویری، نحوه هدایت ترافیک را یاد بگیریم. فرض کنید یک اپلیکیشن داریم که روی پورت 3000 سرور در حال اجراست.

سناریوی آموزش:

• 🔸 هدف: هدایت دامنه example.com به localhost:3000
• 🔸 ابزار: Nginx + Ubuntu 24.04

1- نصب Nginx روی اوبونتو

ابتدا مخازن را آپدیت کرده و وب‌سرور را نصب می‌کنیم:

sudo apt update
sudo apt install nginx -y

sudo apt update
sudo apt install nginx -y

2- غیرفعال کردن سایت پیش‌فرض

قبل از ساخت کانفیگ جدید، سایت پیش‌فرض Nginx را غیرفعال کنید تا تداخلی ایجاد نشود:

sudo rm /etc/nginx/sites-enabled/default

sudo rm /etc/nginx/sites-enabled/default

3- تنظیمات اصلی با دستور proxy_pass

حالا باید یک فایل پیکربندی برای سایت خود بسازیم. از ویرایشگر nano استفاده می‌کنیم:

sudo nano /etc/nginx/sites-available/myapp

sudo nano /etc/nginx/sites-available/myapp

کدهای زیر را داخل فایل قرار دهید:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        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-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        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-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

توضیح هدرهای پروکسی (Proxy Headers):

• Host: نام دامنه اصلی درخواست را به اپلیکیشن منتقل می‌کند.
• X-Real-IP: آی‌پی واقعی کاربر را ارسال می‌کند.
• X-Forwarded-For: این هدر بسیار حیاتی است؛ چرا که آی‌پی واقعی کاربر را به اپلیکیشن شما می‌رساند. بدون این، اپلیکیشن شما فکر می‌کند همه کاربران آی‌پی 127.0.0.1 دارند!
• X-Forwarded-Proto: پروتکل اصلی (HTTP یا HTTPS) را مشخص می‌کند.
• Upgrade و Connection: برای پشتیبانی از اتصالات WebSocket ضروری هستند. بدون این هدرها، اپلیکیشن‌هایی مثل Socket.io یا چت بلادرنگ کار نخواهند کرد.

⚠️ نکته مهم درباره Trailing Slash در proxy_pass:

وجود یا نبود / در انتهای آدرس proxy_pass رفتار متفاوتی دارد:

# بدون اسلش انتهایی: مسیر کامل به backend ارسال می‌شود
# درخواست /api/users ➡️ backend دریافت می‌کند: /api/users
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

# با اسلش انتهایی: بخش location از مسیر حذف می‌شود
# درخواست /api/users ➡️ backend دریافت می‌کند: /users
location /api/ {
    proxy_pass http://127.0.0.1:3000/;
}

# بدون اسلش انتهایی: مسیر کامل به backend ارسال می‌شود
# درخواست /api/users ➡️ backend دریافت می‌کند: /api/users
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

# با اسلش انتهایی: بخش location از مسیر حذف می‌شود
# درخواست /api/users ➡️ backend دریافت می‌کند: /users
location /api/ {
    proxy_pass http://127.0.0.1:3000/;
}

این تفاوت ظریف یکی از رایج‌ترین دلایل باگ‌های 404 در ریورس پروکسی است. همیشه دقت کنید!

4- فعال‌سازی و تست

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo nginx -t       # تست سلامت کانفیگ
sudo systemctl restart nginx

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo nginx -t       # تست سلامت کانفیگ
sudo systemctl restart nginx

📌 نکته: همیشه بعد از تغییرات، دستور nginx -t را بزنید تا اگر غلط املایی داشتید، وب‌سرور از کار نیفتد.

راه‌اندازی SSL روی Nginx Reverse Proxy

یکی از جذاب‌ترین بخش‌ها، نصب گواهینامه SSL رایگان است. ما از Certbot استفاده می‌کنیم که تمام مراحل را به صورت خودکار انجام می‌دهد.

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.com

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.com

• برای ادامه این مراحل را انجام دهید:
• وارد کردن ایمیل: یک ایمیل معتبر (مثلاً ایمیل شخصی خودتان) را تایپ کنید و کلید Enter را بزنید. این ایمیل برای اطلاع‌رسانی در مورد زمان انقضای گواهینامه و مسائل امنیتی استفاده می‌شود.
• تایید قوانین: در پاسخ به سوال (Y)es/(N)o که در انتهای تصویر می‌بینید، کلید Y را تایپ کنید و Enter بزنید.
• اشتراک در خبرنامه: بعد از تایید قوانین، احتمالاً از شما پرسیده می‌شود که آیا می‌خواهید ایمیلتان با بنیاد EFF به اشتراک گذاشته شود؟ پیشنهاد می‌کنم کلید N را بزنید و Enter کنید.
• انتخاب دامنه: در مرحله آخر، Certbot لیست دامنه‌هایی که در فایل کانفیگ Nginx (بخش چهارم مقاله) تعریف کرده‌اید را به شما نشان می‌دهد. اگر فقط یک دامنه دارید، کافیست عدد 1 را بزنید یا مستقیماً Enter کنید.

پس از اتمام این مراحل:

• خروجی ترمینال باید پیامی مبنی بر Congratulations! به شما نشان دهد.
• فایل کانفیگ Nginx شما به صورت خودکار توسط Certbot آپدیت می‌شود تا ترافیک را از HTTP به HTTPS هدایت کند.
• حالا می‌توانید سایت خود را با https:// باز کنید و از امنیت آن لذت ببرید!

با این کار، Nginx شما به صورت خودکار ترافیک HTTP را به HTTPS هدایت می‌کند. حالا اپلیکیشن شما که روی پورت 3000 بود، با امنیت کامل و نماد قفل سبز در دسترس است.

sudo systemctl status certbot.timer

sudo systemctl status certbot.timer

تنظیمات پیشرفته و توازن بار (Load Balancing)

اگر سایت شما شلوغ شد و یک سرور پاسخگو نبود، می‌توانید از توازن بار (Load Balancing) با Nginx استفاده کنید. در این حالت ترافیک بین چند سرور پخش می‌شود.

نمونه کانفیگ Upstream:

upstream my_backend {
    least_conn;  # الگوریتم: ارسال به سروری که کمترین اتصال فعال را دارد
    server 192.168.1.10:3000 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:3000 max_fails=3 fail_timeout=30s;
    keepalive 64;  # نگه داشتن اتصالات برای عملکرد بهتر
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://my_backend;
        proxy_http_version 1.1;

        # هدرهای پروکسی (در Load Balancing هم ضروری هستند!)
        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;

        # پشتیبانی از WebSocket
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeout
        proxy_connect_timeout 10s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

upstream my_backend {
    least_conn;  # الگوریتم: ارسال به سروری که کمترین اتصال فعال را دارد
    server 192.168.1.10:3000 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:3000 max_fails=3 fail_timeout=30s;
    keepalive 64;  # نگه داشتن اتصالات برای عملکرد بهتر
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://my_backend;
        proxy_http_version 1.1;

        # هدرهای پروکسی (در Load Balancing هم ضروری هستند!)
        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;

        # پشتیبانی از WebSocket
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeout
        proxy_connect_timeout 10s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

📌 توضیح پارامترهای upstream:

• least_conn: ترافیک به سروری می‌رود که کمترین اتصال فعال را دارد (مناسب برای درخواست‌های سنگین).
• max_fails=3: اگر 3 بار پشت سر هم خطا بدهد، سرور موقتاً غیرفعال می‌شود.
• fail_timeout=30s: مدت زمان غیرفعال بودن سرور خراب.
• keepalive 64: نگه داشتن 64 اتصال فعال به backend برای کاهش سربار ایجاد اتصال جدید.

اتصال Nginx به Docker با ریورس پروکسی

اگر از داکر استفاده می‌کنید، Nginx Reverse Proxy بهترین روش برای مدیریت کانتینرهای متعدد است بدون اینکه نیاز باشد پورت‌های آن‌ها را به بیرون باز کنید.

روش 1: Nginx روی هاست + اپلیکیشن در داکر

فرض کنید یک اپلیکیشن Node.js در داکر روی پورت 3000 اجرا می‌شود:

docker run -d --name myapp -p 127.0.0.1:3000:3000 node-app

docker run -d --name myapp -p 127.0.0.1:3000:3000 node-app

کانفیگ Nginx دقیقاً مثل بخش چهارم خواهد بود (proxy_pass به http://127.0.0.1:3000).

روش 2: Nginx و اپلیکیشن هر دو در Docker Compose

# docker-compose.yml
version: "3.8"

services:
  app:
    image: node-app
    container_name: myapp
    expose:
      - "3000"        # فقط داخل شبکه داکر باز می‌شود، نه روی هاست
    networks:
      - webnet

  nginx:
    image: nginx:latest
    container_name: nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
      - ./certs:/etc/letsencrypt:ro
    depends_on:
      - app
    networks:
      - webnet

networks:
  webnet:

# docker-compose.yml
version: "3.8"

services:
  app:
    image: node-app
    container_name: myapp
    expose:
      - "3000"        # فقط داخل شبکه داکر باز می‌شود، نه روی هاست
    networks:
      - webnet

  nginx:
    image: nginx:latest
    container_name: nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
      - ./certs:/etc/letsencrypt:ro
    depends_on:
      - app
    networks:
      - webnet

networks:
  webnet:

فایل nginx.conf برای این سناریو:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://app:3000;  # نام سرویس در docker-compose
        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-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://app:3000;  # نام سرویس در docker-compose
        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-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

عیب‌یابی خطاهای رایج در Nginx Reverse Proxy

اگر در هنگام کار با ریورس پروکسی با خطا مواجه شدید، نگران نباشید. این‌ها رایج‌ترین‌ها هستند:

خطای 502 Bad Gateway در Nginx:

• علت: اپلیکیشن شما (مثلاً نود جی‌اس) خاموش است یا روی پورت اشتباه اجرا شده.
• راه حل: وضعیت سرویس اپلیکیشن خود را چک کنید:

# چک وضعیت اپلیکیشن
curl http://127.0.0.1:3000
# چک لاگ Nginx
sudo tail -f /var/log/nginx/error.log

# چک وضعیت اپلیکیشن
curl http://127.0.0.1:3000
# چک لاگ Nginx
sudo tail -f /var/log/nginx/error.log

خطای 504 Gateway Timeout:

• علت: سرور داخلی بیش از حد طول می‌کشد تا پاسخ دهد.
• راه حل: زمان‌های timeout را در کانفیگ افزایش دهید:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 30s;   # زمان برقراری اتصال
    proxy_send_timeout 120s;     # زمان ارسال درخواست
    proxy_read_timeout 120s;     # زمان دریافت پاسخ
}

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 30s;   # زمان برقراری اتصال
    proxy_send_timeout 120s;     # زمان ارسال درخواست
    proxy_read_timeout 120s;     # زمان دریافت پاسخ
}

خطای 403 Forbidden:

• علت: پرمیشن‌های فایل‌ها یا تنظیمات دسترسی در Nginx مشکل دارد.

خطای 404 ناشی از مسیردهی:

• علت: وجود یا نبود / در انتهای proxy_pass. به بخش چهارم مراجعه کنید.

معرفی خدمات وب‌داده؛ میزبان حرفه‌ای شما

برای اجرای یک Nginx Reverse Proxy پایدار، شما به سروری با پورت شبکه قوی و آپتایم بالا نیاز دارید. وب‌داده با ارائه سرورهای مخصوص میزبانی، بهترین تجربه را برای شما رقم می‌زند.

• ✅ آپتایم 99.9٪ واقعی برای پروکسی‌های حساس
• ✅ پشتیبانی 24 ساعته در صورت بروز مشکلات کانفیگ
• ✅ ارائه آی‌پی‌های تمیز و اختصاصی
• ✅ پهنای باند نامحدود برای توازن بار سنگین

سرور مجازی وب داده

VPS وب داده با حضور قدرتمند در بیش از 9 لوکیشن استراتژیک در سراسر جهان…

برای مشاهده موقعیت‌های
سرور های مجازی وب‌داده
روی دکمه زیر کلیک کنید

خرید سرور مجازی

نتیجه‌گیری؛ راه‌اندازی Reverse Proxy با Nginx

راه‌اندازی ریورس پروکسی با استفاده از Nginx نه تنها مدیریت سایت‌های شما را آسان‌تر می‌کند، بلکه امنیت لایه‌های داخلی شبکه شما را به طرز چشم‌گیری افزایش می‌دهد. در این مقاله یاد گرفتیم که چطور با دستور proxy_pass ترافیک را هدایت کنیم، چطور SSL نصب کنیم، چطور ترافیک را بین چند سرور تقسیم کنیم و چطور Nginx را با Docker Compose ترکیب کنیم.

فراموش نکنید که Nginx یک ابزار بسیار قدرتمند است و تنظیماتی که امروز یاد گرفتید، فقط نوک کوه یخ بود! با کمی تمرین، می‌توانید معماری‌های بسیار پیچیده‌ای را به تنهایی مدیریت کنید.

در صورتی که در هر مرحله از نصب یا کانفیگ با سوالی مواجه شدید، حتماً در بخش نظرات با ما در ارتباط باشید؛ کارشناسان وب‌داده آماده پاسخگویی به شما هستند. امیدوارم این مقاله از بلاگ وب‌داده برای شما مفید بوده باشد. 🚀

سوالات متداول از راه‌اندازی Reverse Proxy با Nginx