Reverse Proxy چیست و چه کاربردی دارد؟

تقریباً هر سرویس وب جدی، از یک سایت وردپرسی تا یک API یا n8n، پشت یک Reverse Proxy اجرا می‌شود. Reverse Proxy سرور واسطی است که درخواست کاربران را دریافت می‌کند و به سرویس مناسب در پشت صحنه می‌رساند. در این مقاله توضیح می‌دهیم Reverse Proxy چیست، چه تفاوتی با Forward Proxy دارد، چه کاربردهایی دارد و چطور یک Reverse Proxy درست با Nginx راه‌اندازی کنیم.

Reverse Proxy چیست؟

Reverse Proxy سروری است که در جلوی یک یا چند سرویس قرار می‌گیرد. کاربران فقط با Reverse Proxy ارتباط دارند؛ Reverse Proxy درخواست را بررسی می‌کند، به سرویس مناسب در پشت (Backend یا Upstream) می‌فرستد و پاسخ را به کاربر برمی‌گرداند. از دید کاربر، فقط یک سایت وجود دارد؛ او نمی‌داند پشت آن یک سرویس است یا ده سرویس، و IP و پورت داخلی آن‌ها را نمی‌بیند.

تفاوت Reverse Proxy و Forward Proxy

۷ کاربرد Reverse Proxy

1. مدیریت HTTPS (SSL Termination): گواهی SSL یک جا روی Reverse Proxy نصب و تمدید می‌شود و سرویس‌های پشت آن لازم نیست درگیر TLS شوند.
2. انتشار چند سرویس روی یک IP: بر اساس نام دامنه یا مسیر، درخواست‌ها به سرویس‌های مختلف می‌روند؛ مثلاً example.com به وردپرس، n8n.example.com به n8n و /api به یک API.
3. پنهان کردن سرویس‌های داخلی: سرویس‌ها فقط روی 127.0.0.1 یا شبکه خصوصی گوش می‌دهند و از اینترنت مستقیماً قابل دسترسی نیستند.
4. توزیع بار (Load Balancing): تقسیم درخواست‌ها بین چند سرور برای ظرفیت و تحمل خرابی بیشتر.
5. کش: نگهداری پاسخ‌های تکراری و کاهش بار سرویس اصلی.
6. امنیت و کنترل دسترسی: محدودیت نرخ، محدودیت IP، احراز هویت ساده و WAF در یک نقطه.
7. فشرده‌سازی و HTTP/۲ و HTTP/۳: بهینه‌سازی ارتباط با کاربر بدون تغییر در اپلیکیشن.

ابزارهای رایج

• Nginx: رایج‌ترین انتخاب؛ سریع، سبک و همه‌کاره.
• Caddy: پیکربندی بسیار ساده و دریافت و تمدید خودکار گواهی SSL.
• Traefik: مناسب محیط‌های Docker و Kubernetes با کشف خودکار سرویس‌ها.
• HAProxy: متخصص توزیع بار با کارایی بسیار بالا.
• Apache: با ماژول mod_proxy نقش Reverse Proxy را هم ایفا می‌کند. مقایسه وب‌سرورها در LiteSpeed یا Apache.

CDNها هم در واقع Reverse Proxyهای توزیع‌شده جهانی هستند.

پیکربندی Reverse Proxy با Nginx

فرض کنید یک اپلیکیشن روی پورت ۳۰۰۰ همان سرور اجرا می‌شود و می‌خواهید آن را روی app.example.com با HTTPS منتشر کنید:

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    http2 on;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

    client_max_body_size 20m;

    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_read_timeout 120s;
    }
}

گواهی را با Certbot بگیرید و پیکربندی را بررسی و اعمال کنید:

sudo certbot certonly --nginx -d app.example.com
sudo nginx -t && sudo systemctl reload nginx

اپلیکیشن باید فقط روی 127.0.0.1:3000 گوش دهد، نه روی همه رابط‌ها. نمونه‌های واقعی این الگو را در نصب n8n روی VPS و ساخت API سازگار با OpenAI ببینید.

هدرهای مهم و IP واقعی کاربر

• Host: نام دامنه درخواست را به اپلیکیشن منتقل می‌کند.
• X-Forwarded-For و X-Real-IP: IP واقعی کاربر؛ بدون آن، اپلیکیشن همه درخواست‌ها را از ۱۲۷.۰.۰.۱ می‌بیند.
• X-Forwarded-Proto: به اپلیکیشن می‌گوید کاربر با HTTPS وصل شده تا لینک‌ها و ریدایرکت‌ها را درست بسازد.
• Upgrade و Connection: برای WebSocket.

اپلیکیشن باید تنظیم شود که فقط از Reverse Proxy مورد اعتماد این هدرها را بپذیرد؛ در غیر این صورت مهاجم می‌تواند IP خود را جعل کند.

توزیع بار بین چند سرور

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:3000 max_fails=3 fail_timeout=30s;
}

server {
    # ... بخش SSL مانند مثال قبل
    location / {
        proxy_pass http://app_backend;
    }
}

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

اشتباه‌های رایج

• باز ماندن پورت سرویس پشتی روی اینترنت: کل فایده Reverse Proxy از بین می‌رود. با Docker مراقب باشید؛ پورت‌های منتشرشده از UFW عبور می‌کنند. توضیح در امنیت Docker.
• فراموش کردن X-Forwarded-Proto: باعث حلقه ریدایرکت یا لینک‌های http در سایت HTTPS می‌شود.
• Timeout کوتاه: برای عملیات طولانی یا پاسخ‌های جریانی، proxy_read_timeout را افزایش دهید و برای Streaming، proxy_buffering off را تنظیم کنید.
• محدودیت حجم آپلود: مقدار پیش‌فرض client_max_body_size فقط ۱ مگابایت است و آپلودهای بزرگ‌تر با خطای ۴۱۳ رد می‌شوند.

سوالات متداول