راه اندازی Nginx Reverse Proxy یکی از سریع ترین و کم هزینه ترین روش ها برای قرار دادن چند سرویس پشت یک آدرس دامنه، مدیریت ترافیک ورودی، فعال سازی HTTPS و جداسازی لایه شبکه از برنامه است. در این راهنما با رویکرد عملی و قابل پیاده سازی، از نصب تا پیکربندی، امنیت، بهینه سازی عملکرد و استقرار در داکر و کوبرنتیس را پوشش می دهیم تا مسیر شما از محیط توسعه تا تولید استاندارد و پایدار باشد.

چرا معکوس پراکسی برای دیواپس حیاتی است

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

این الگو مدیریت گواهی های TLS، لاگینگ متمرکز، محدودسازی نرخ درخواست، اعمال هدرهای امنیتی و کش محتوا را یکپارچه می کند. در نتیجه، استقرارها ساده تر، خطاها قابل ردیابی تر و مهاجرت ها کم خطرتر می شوند.

پیش نیازها و معماری مرجع

برای پیاده سازی پایدار، چند پیش نیاز را آماده کنید: دامنه معتبر، رکورد DNS نوع A یا AAAA به سرور، دسترسی ریشه یا سودو، باز بودن پورت های 80 و 443 در فایروال و سرویس های پشت صحنه با پورت های داخلی مشخص.

یک معماری مرجع ساده شامل یک هاست لبه با Nginx، چند سرویس برنامه یا API روی پورت های داخلی و یک فضای ذخیره برای لاگ و گواهی های TLS است. هر سرویس با upstream جدا تعریف می شود و بر اساس دامنه یا مسیر، مسیریابی انجام می گیرد.

نصب و راه اندازی پایه

گام های زیر یک استقرار پایه روی لینوکس را نشان می دهد. پس از نصب، یک فایل پیکربندی جداگانه ایجاد و سرویس را بدون اختلال بارگذاری کنید.

  1. نصب بسته ها: 
    # Ubuntu/Debian
sudo apt update && sudo apt install -y nginx

# RHEL/CentOS
sudo yum install -y epel-release nginx

# راه اندازی و فعال سازی سرویس
sudo systemctl enable --now nginx
  2. ایجاد پیکربندی معکوس پراکسی: 
    # /etc/nginx/conf.d/app.conf
upstream app_backend {
    server 127.0.0.1:3000 max_fails=3 fail_timeout=10s;
    keepalive 32;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://app_backend;
        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_read_timeout 60s;
        proxy_connect_timeout 5s;
        proxy_send_timeout 60s;
    }
}
  3. تست و بارگذاری مجدد: 
    sudo nginx -t
sudo systemctl reload nginx

مسیریابی به چند سرویس و قواعد هدر

برای میزبانی چند سرویس، از دامنه های مختلف یا مسیرهای جدا استفاده کنید. نمونه زیر ترکیبی از مسیریابی بر اساس مسیر و دامنه را نشان می دهد.

# /etc/nginx/conf.d/multi.conf
upstream api_backend { server 127.0.0.1:4000; keepalive 32; }
upstream web_backend { server 127.0.0.1:3000; keepalive 32; }

server {
    listen 80;
    server_name api.example.com www.example.com example.com;

    # ریدایرکت عمومی به HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

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

    location /api/ {
        proxy_pass http://api_backend/;
        proxy_set_header Host $host;
        proxy_set_header X-Request-ID $request_id;
    }

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
    }
}

برای حفظ قابلیت ردیابی، یک شناسه درخواست به هدرها اضافه کنید. همچنین، اگر برنامه شما از وب سوکت استفاده می کند، هدرهای Upgrade و Connection را در لوکیشن مربوطه تنظیم کنید.

فعال سازی HTTPS با Let’s Encrypt

گواهی رایگان و خودکار باعث امنیت و اعتماد کاربران می شود. با Certbot می توانید دریافت و تمدید خودکار را راه اندازی کنید.

  1. نصب ابزار: 
    sudo apt install -y certbot python3-certbot-nginx
  2. دریافت گواهی و اعمال خودکار روی Nginx: 
    sudo certbot --nginx -d example.com -d www.example.com \
  --redirect --email admin@example.com --agree-tos --no-eff-email
  3. بررسی تمدید خودکار: 
    sudo systemctl status certbot.timer
sudo certbot renew --dry-run

لاگینگ، مانیتورینگ و عیب یابی

لاگ ها کلید عیب یابی سریع و مشاهده پذیری هستند. یک فرمت ساخت یافته برای تحلیل بهتر تعریف کنید و مسیرهای حساس را از لاگ خارج نکنید.

# /etc/nginx/nginx.conf (بخش http)
log_format json escape=json
  '{ "time":"$time_iso8601", "remote":"$remote_addr", "host":"$host", '
  '"req":"$request", "status":$status, "bytes":$body_bytes_sent, '
  '"referer":"$http_referer", "ua":"$http_user_agent", "reqid":"$request_id" }';

access_log /var/log/nginx/access.json json;
error_log  /var/log/nginx/error.log warn;

برای بررسی سریع، از tail و grep استفاده کنید و به کدهای 502 و 504 حساس باشید. برخی خطاهای رایج و ریشه های آنها:

  • 502 Bad Gateway: سرویس پشت صحنه خاموش یا پورت اشتباه، یا عدم سازگاری نسخه های TLS بین سرور و بک اند.
  • 504 Gateway Timeout: زمان پاسخ طولانی، نیاز به افزایش proxy_read_timeout یا بهینه سازی کوئری های پایگاه داده.
  • Connection refused: فایروال یا SELinux مانع اتصال به پورت داخلی شده است.

برای سنجش سلامت، بلوک وضعیت را محدود شده فعال کنید:

location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}

بهینه سازی عملکرد و کش

بهبودهای ساده ای مانند keepalive، فشرده سازی و کش محتوای ایستا تا حد زیادی مصرف پهنای باند و زمان پاسخ را کاهش می دهد.

# /etc/nginx/conf.d/perf.conf
gzip on;
gzip_types text/plain text/css application/javascript application/json image/svg+xml;
gzip_min_length 1024;

# کش محتوای ایستا
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, max-age=2592000";
    try_files $uri =404;
}

# کش پاسخ های API با احتیاط
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:10m
                 max_size=1g inactive=10m use_temp_path=off;

location /api/ {
    proxy_pass http://api_backend;
    proxy_cache api_cache;
    proxy_cache_bypass $http_cache_control;
    add_header X-Cache-Status $upstream_cache_status;
}

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

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

لایه امنیتی را در سطح وب سرور جدی بگیرید. از محدودسازی نرخ، هدرهای امنیتی و احراز هویت پایه برای مسیرهای مدیریتی استفاده کنید.

# محدودسازی نرخ بر اساس IP
limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s;

server {
    listen 443 ssl http2;
    # ...

    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Content-Security-Policy "default-src 'self'" always;

    location /admin/ {
        limit_req zone=perip burst=10 nodelay;
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://web_backend;
    }

    location /internal/health {
        allow 10.0.0.0/8;
        deny all;
        proxy_pass http://web_backend/health;
    }
}

فایل htpasswd را با ابزار استاندارد ایجاد کنید و به صورت امن نگهداری کنید. اگر پشت یک لودبالنسر خارجی هستید، به هدر X-Forwarded-Proto و X-Forwarded-For اعتماد سنجیده داشته باشید.

استقرار در داکر و کوبرنتیس

کانتینری کردن پیکربندی، حمل پذیری و تکرارپذیری را بالا می برد. در داکر از حجم های فقط خواندنی برای کانفیگ و گواهی ها استفاده کنید.

version: "3.8"
services:
  nginx:
    image: nginx:stable
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./nginx/certs:/etc/letsencrypt
      - ./nginx/cache:/var/cache/nginx
    restart: unless-stopped

در کوبرنتیس بهتر است از کنترلر Ingress NGINX استفاده کنید تا قوانین مسیریابی را با منابع Ingress مدیریت کنید.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
spec:
  tls:
  - hosts: [ "example.com" ]
    secretName: example-tls
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80
محیط نکته کلیدی
Docker Compose سادگی و کنترل مستقیم روی فایل های کانفیگ و گواهی ها
Kubernetes Ingress مقیاس پذیری، رول های پویا و ادغام با سرویس ها و سکرет ها

اتوماسیون و بهترین رویه ها

پیکربندی را در گیت نگهداری و با CI تست کنید. هر تغییر قبل از استقرار در تولید باید با nginx -t اعتبارسنجی و سپس reload بی وقفه شود.

# اعتبارسنجی و بارگذاری بدون قطعی
sudo nginx -t && sudo systemctl reload nginx
  • از قالب های متغیرپذیر برای محیط های مختلف استفاده کنید و با ابزارهایی مثل Ansible یا Terraform استقرار را خودکار کنید.
  • نسخه Nginx را به روز نگه دارید و ماژول های غیر ضروری را غیرفعال کنید.
  • به صورت دوره ای لاگ ها و معیارهای عملکرد را بازبینی و حدود منابع را تنظیم کنید.

نکات عیب یابی پیشرفته

برای درخواست های مشکل دار، موقتا سطح لاگ را روی debug در بلوک سرور بگذارید و ترافیک را در بازه کوتاه بررسی کنید. همچنین از ابزار curl برای بازتولید درخواست با هدرهای لازم استفاده کنید.

# نمونه تست
curl -I https://example.com/api/ -H "X-Request-ID: test123" -L -k -v

اگر پشت پراکسی یا شبکه سازمانی هستید، MTU و Fragmentation می تواند باعث time out شود. در چنین مواردی، فعال کردن http2 و تنظیم tcp_nodelay و tcp_nopush می تواند بهبود ایجاد کند.

کاربردهای رایج و الگوهای مسیریابی

چند الگوی پرکاربرد عبارتند از مسیریابی بر اساس مسیر برای جداسازی وب و API، مسیریابی بر اساس زیردامنه برای نسخه بندی سرویس ها و مسیریابی قاعده محور بر اساس هدر برای اجرای A/B تست.

در پروژه های میکروسرویسی، تعریف upstream های متعدد و health check خارج از Nginx توصیه می شود تا منطق سلامت سرویس ها در ارکسترایزر باقی بماند. در عین حال، هدر X-Request-ID مسیر ردیابی را در هر سرویس حفظ می کند.

جمع بندی

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