ریورس پروکسی Nginx؛ ۶ گام کانفیگ حرفه‌ای همراه با Let’s Encrypt و HTTP/۲

پیاده‌سازی ریورس پروکسی Nginx یکی از اساسی‌ترین گام‌های مهندسی زیرساخت برای محافظت، شتاب‌دهی و مدیریت ترافیک اپلیکیشن‌های تحت وب در محیط پروداکشن به شمار می‌رود. وب‌سرور Nginx به واسطه معماری رویدادمحور (Asynchronous Event-Driven) و مصرف بهینه حافظه، نقشی تعیین‌کننده به عنوان سپر دفاعی لایه ۷، توزیع‌کننده بار (Load Balancer)، موتور فشرده‌سازی محتوا و ترمینال رمزنگاری SSL ایفا می‌کند. در این راهنمای جامع از بلاگ تراست‌هاست، ۶ گام کلیدی و تست‌شده را برای کانفیگ استاندارد ریورس پروکسی Nginx همراه با صدور خودکار گواهینامه Let’s Encrypt، فعال‌سازی پروتکل پرسرعت HTTP/۲ و سخت‌سازی هدرهای امنیتی بررسی خواهیم کرد.

[System Context - TrustHost High Performance Nginx Reverse Proxy]
Role: Senior DevOps & Linux Infrastructure Engineer
Objective: Configure Nginx as an optimized Reverse Proxy with SSL (Certbot) and HTTP/2
OS Environment: Ubuntu 24.04 LTS / Debian 12
Upstream Service: Node.js/Python on 127.0.0.1:3000
Primary Directives Required:
- 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_http_version 1.1
- Connection upgrade headers for WebSocket
Security Hardening: HSTS (Strict-Transport-Security), X-Frame-Options, CSP, TLSv1.2/TLSv1.3
Instruction: Help me troubleshoot and deploy this reverse proxy setup on my TrustHost VPS. Keep instructions command-line focused.

معماری ریورس پروکسی Nginx و نقش حیاتی آن در پایداری سرور

در مدل‌های استقرار کلاسیک، برنامه‌های تحت وب (نظیر فریم‌ورک‌های Node.js Express، پایتون Django/FastAPI، گو Gin یا لاراول Octane) مستقیماً روی پورت‌های عمومی ۸۰ و ۴۴۳ گوش فرا می‌دادند. این شیوه معماری در سناریوهای بار ترافیکی بالا مخاطرات ساختاری ایجاد می‌کند؛ از جمله ناتوانی در مدیریت هم‌روندی بالای ۱۰ هزار کانکشن، آسیب‌پذیری در برابر حملات محروم‌سازی از سرویس (DoS) و اتلاف منابع CPU برای هندل کردن چرخه رمزنگاری TLS.

با استقرار ریورس پروکسی Nginx در لبه ورودی سرورهای مجازی لینوکس، تمامی اتصالات خارجی در لایه شبکه مدیریت و تجمیع می‌شوند. وظیفه اصلی ریورس پروکسی Nginx جداسازی محیط پردازش درخواست‌های کلاینت از برنامه‌های پس‌زمینه است. انجین‌اکس با بهره‌گیری از سیستم‌فراخوان epoll کرنل لینوکس، درخواست‌ها را با کمترین سربار پردازشی صف‌بندی کرده، استاتیک‌فایل‌ها را بدون دخالت اپلیکیشن از دیسک‌های پرسرعت NVMe بازمی‌گرداند و تنها درخواست‌های پردازشی پویا را به سرویس‌های پس‌زمینه پاس می‌دهد.

گام ۱: بهینه‌سازی پارامترهای هسته در فایل nginx.conf

پیش از تعریف بلاک‌های پروکسی، باید پارامترهای عمومی وب‌سرور در مسیر /etc/nginx/nginx.conf متناسب با تعداد هسته‌های پردازنده و سقف توصیف‌گرهای فایل (File Descriptors) سیستم‌عامل تنظیم گردند:

user www-data;
worker_processes auto;
worker_rlimit_nofile 65535;
pid /run/nginx.pid;

events {
    worker_connections 8192;
    use epoll;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    server_tokens off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # لاگ اختصاصی بهینه‌شده
    access_log /var/log/nginx/access.log combined buffer=64k flush=5s;
    error_log /var/log/nginx/error.log warn;
}

مقدار worker_processes auto تضمین می‌کند به ازای هر هسته پردازشی یک فرآیند کارگر مجزا اسپاون شود. همچنین worker_rlimit_nofile 65535 مانع از برخورد انجین‌اکس با محدودیت پیش‌فرض ۱۰۲۴ فایلی سیستم‌عامل تحت ترافیک سنگین خواهد شد.

گام ۲: پیکربندی هدرهای ریورس پروکسی Nginx و اتصال به Upstream

یکی از شایع‌ترین چالش‌ها پس از پیاده‌سازی ریورس پروکسی Nginx، مخدوش شدن IP واقعی کلاینت در لاگ‌های برنامه پس‌زمینه است؛ به طوری که تمام ترافیک ورودی با IP محلی 127.0.0.1 ثبت می‌شود. این نقص، عملکرد ماژول‌های امنیتی Rate Limiting و فایروال‌های وب (WAF) را مختل می‌سازد.

برای حل این چالش، یک فایل پیکربندی جدید در مسیر /etc/nginx/sites-available/app.conf ایجاد کرده و هدرهای استاندارد را تنظیم می‌نماییم:

upstream backend_nodes {
    server 127.0.0.1:3000 max_fails=3 fail_timeout=10s;
    keepalive 64;
}

server {
    listen 80;
    server_name example.trusthost.co;

    location / {
        proxy_pass http://backend_nodes;
        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 Connection "";

        # تنظیم تایم‌اوت‌های پروکسی
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        # بافرهای تبادل ترافیک
        proxy_buffers 8 16k;
        proxy_buffer_size 16k;
    }
}

در معماری ریورس پروکسی Nginx، دستور keepalive 64 در بلوک upstream باعث بازماندن کانکشن‌های TCP با اپلیکیشن محلی شده و از تکرار مداوم فرآیند پرهزینه Three-way Handshake به ازای هر ریکوئست کاربر جلوگیری می‌کند.

گام ۳: دریافت و تمدید خودکار گواهینامه SSL با Certbot

برای برقراری امنیت انتقال داده و پاسخ به استانداردهای مرورگرهای مدرن، ترکیب گواهی رایگان Let’s Encrypt با ریورس پروکسی Nginx راهکاری ایده‌آل و استاندارد است. با استفاده از ابزار متن‌باز Certbot که توسط بنیاد الکترونیک فرانتیر توسعه یافته، گواهینامه معتبر SSL صادر و خودکار روی وب‌سرور نصب می‌گردد.

برای مطالعه مستندات و پارامترهای پیشرفته سرت‌بات می‌توانید به وب‌سایت رسمی بنیاد EFF Certbot مراجعه کنید. فرآیند نصب در سیستم‌عامل اوبونتو ۲۴.۰۴ به صورت زیر است:

# به‌روزرسانی مخازن و نصب سرت‌بات و پلاگین رسمی Nginx
sudo apt update && sudo apt install -y certbot python3-certbot-nginx

# صدور خودکار گواهی، ریدایرکت خودکار ترافیک HTTP به HTTPS و ویرایش کانفیگ
sudo certbot --nginx -d example.trusthost.co

# آزمودن صحت تایمر سیستم‌دی (systemd timer) جهت تمدید اتوماتیک
sudo certbot renew --dry-run

گام ۴: فعال‌سازی پروتکل پرسرعت HTTP/۲ و فشرده‌سازی Gzip

فعال‌سازی پروتکل HTTP/۲ بر روی ریورس پروکسی Nginx تحولی بزرگ در شتاب لود صفحات وب ایجاد می‌کند. قابلیت Multiplexing به کلاینت اجازه می‌دهد ده‌ها فایل CSS، JS و تصاویر را هم‌زمان روی یک کانکشن واحد TCP دریافت کند و تاخیر Head-of-Line Blocking منسوخ گردد.

همچنین با استناد به راهنمای رسمی معماری Nginx، فعال‌سازی ماژول فشرده‌سازی ngx_http_gzip_module حجم داده‌های متنی ارسالی به کلاینت را تا ۷۰ درصد کاهش می‌دهد:

server {
    listen 443 ssl http2;
    server_name example.trusthost.co;

    ssl_certificate /etc/letsencrypt/live/example.trusthost.co/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.trusthost.co/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # فشرده‌سازی هوشمند Gzip
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css text/xml application/json application/javascript application/rss+xml image/svg+xml;
    gzip_min_length 1024;
}

گام ۵: پشتیبانی بدون قطعی از اتصالات زنده WebSocket

در پروژه‌های مدرن که از سوکت‌های بلادرنگ (مثل Socket.io، چت‌روم‌ها، نوتیفیکیشن‌ها یا معاملات لحظه‌ای) استفاده می‌کنند، اگر انجین‌اکس درخواست تغییر پروتکل (Upgrade) را نشناسد، سشن سوکت بلافاصله قطع می‌شود.

برای هندل پایدار وب‌سوکت در لایه ریورس پروکسی Nginx، کافیست نگاشت متغیرها را در بلوک اصلی http قرار داده و در بلوک location پاس دهیم:

# در فایل nginx.conf داخل بلوک http
map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

# داخل فایل کانفیگ سایت در بلوک server
location /socket.io/ {
    proxy_pass http://backend_nodes;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header Host $host;

    # مهلت زمان قطع کانکشن زنده (۲۴ ساعت)
    proxy_read_timeout 86400s;
    proxy_send_timeout 86400s;
}

گام ۶: سخت‌سازی امنیتی سرور با هدرهای HSTS و ضد نفوذ

امنیت لایه انتقال باید در تمام تبادلات تضمین شود. افزودن هدرهای زیر در بلوک سرور، خطرات حملات Man-in-the-Middle، سرقت سشن و Clickjacking را به صفر نزدیک می‌کند:

# الزام مرورگر به اتصال دائمی رمزنگاری‌شده تا ۱ سال
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# جلوگیری از اجرای اسکریپت در تگ‌های iframe دیگر سایت‌ها
add_header X-Frame-Options "SAMEORIGIN" always;

# جلوگیری از حدس‌زدن نوع فایل توسط مرورگر و محافظت در برابر MIME Spoofing
add_header X-Content-Type-Options "nosniff" always;

# کنترل سیاست ارسال هدر ارجاع‌دهنده
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# مسدودسازی دسترسی به فایل‌های مخفی گیت و دات‌فایل‌ها
location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
}

جدول مقایسه پارامترهای کلیدی ریورس پروکسی Nginx در پروداکشن

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

عیب‌یابی خطاهای رایج در ریورس پروکسی Nginx

در عملکرد روزمره ریورس پروکسی Nginx، مواجهه با خطاهای سری ۵۰۰ نیازمند بررسی ریشه‌ای است:

• خطای ۵۰۲ Bad Gateway: انجین‌اکس فعال است اما پورت یا سوکت مقصد (مثلاً 127.0.0.1:3000) پاسخ نمی‌دهد. سرویس بک‌اند کرش کرده یا متوقف شده است.
• خطای ۵۰۴ Gateway Timeout: سرویس بک‌اند زنده است، اما کوئری پردازشی آن بیش از سقف تعیین‌شده در proxy_read_timeout طول کشیده و انجین‌اکس ارتباط را قطع کرده است.

پیش از اعمال هرگونه تغییر در تنظیمات ریورس پروکسی Nginx، سینتکس فایل‌ها را تست کرده و سپس سرویس را بدون داون‌تایم ریلود فرمایید:

# تست جامع صحت فایل‌های پیکربندی Nginx
sudo nginx -t

# ریلود نرم و بدون افت کانکشن سرویس
sudo systemctl reload nginx

# بررسی زنده آخرین خطاهای رخ‌داده
sudo tail -f /var/log/nginx/error.log

سوالات متداول پیرامون ریورس پروکسی Nginx