مقدمه

Healthy بودن Nginx به معنی سالم‌بودن برنامه نیست. Reverse Proxy باید timeout، شناسه درخواست، TLS معتبر و آزمون مستقل upstream داشته باشد تا خطای 502 قابل پیگیری شود.

مثال عملی

برنامه داخلی روی loopback اجرا می‌شود و کاربران فقط به TLS proxy دسترسی دارند. ابتدا یک VM canary و سپس load balancer تغییر می‌کند.

پیش‌نیازها

Ubuntu Server 24.04 LTS، Bash 5، systemd؛ package patch را پیش از تغییر با dpkg-query ثبت کنید.

سخت‌افزار و ظرفیت: نمونه ۲ vCPU و ۲ GiB RAM؛ worker و file descriptor با load test تعیین شوند. backend آماده روی 127.0.0.1:8080 لازم است.

نرم‌افزار و دسترسی: sudo، nginx، curl و DNS برای app.example.com؛ این نام placeholder است. گواهی و کلید معتبر باید از PKI سازمان در مسیرهای زیر فراهم شوند.

Architecture / Design

Client → TCP/443 Nginx → HTTP loopback:8080 → Application. در چند میزبان upstream به subnet خصوصی و firewall محدود منتقل شود؛ forwarding header از proxyهای ناشناس پذیرفته نشود.

Installation / Configuration

ابتدا backend را تست و تنظیم موجود را حفظ کنید. نصب package از repository سیستم انجام می‌شود.

sudo apt-get update
sudo apt-get install -y nginx curl
nginx -v
curl --fail --max-time 5 http://127.0.0.1:8080/health
sudo cp -a /etc/nginx /root/nginx-before-change

در موفقیت health باید کد 200 و payload مورد انتظار برنامه بدهد. پیش از نوشتن config گواهی chain و private key را در مسیرهای زیر نصب و مالکیت root/600 برای key اعمال کنید.

sudo tee /etc/nginx/sites-available/enterprise-app >/dev/null <<'EOF'
server {
    listen 80;
    server_name app.example.com;
    return 301 https://app.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name app.example.com;
    ssl_certificate /etc/nginx/tls/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    location / {
        proxy_pass http://127.0.0.1:8080;
        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 X-Request-ID $request_id;
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
}
EOF
sudo ln -s /etc/nginx/sites-available/enterprise-app /etc/nginx/sites-enabled/enterprise-app
sudo nginx -t
sudo systemctl reload nginx
curl --fail --max-time 10 https://app.example.com/health

symlink فقط در نخستین نصب ساخته شود؛ اگر موجود است محتوا و مقصدش را بررسی کنید. انتظار nginx -t: syntax is ok و test is successful. در canary، DNS یا --resolve به IP همان VM اشاره کند. اگر default virtual host یا همان server_name از قبل وجود دارد تعارض را پیش از reload رفع کنید.

Security Hardening

backend روی public IP bind نشود. key گواهی خواندنی برای کاربر عمومی نباشد. firewall به مسیر مدیریت و 443 محدود شود؛ 80 فقط برای redirect یا ACME لازم است. HSTS ابتدا با max-age کوتاه و بدون includeSubDomains آزمایش شود. rate limit بر اساس مسیر و ترافیک واقعی تنظیم شود، نه عدد کپی‌شده.

Monitoring

Prometheus exporter فقط از شبکه monitoring خوانده شود. نرخ 5xx، latency upstream، handshake failure و عمر گواهی پایش شوند. آستانه نمونه 5xx بالاتر از ۱٪ برای ۵ دقیقه به baseline وابسته است. Grafana درخواست کل و درخواست موفق را کنار هم نشان دهد؛ log شامل request ID باشد.

Troubleshooting

502: اتصال یا پاسخ نامعتبر upstream؛ 504: timeout؛ 403: permission یا policy. ابتدا upstream مستقیم را امتحان کنید.

curl --verbose --max-time 5 http://127.0.0.1:8080/health
sudo ss -lntp
sudo tail -n 80 /var/log/nginx/error.log
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -T

connect() failed با Connection refused نشان‌دهنده listener backend است. permission denied ممکن است از socket یا AppArmor باشد؛ chmod 777 راه‌حل نیست. -T ممکن است اطلاعات حساس config را نمایش دهد؛ فقط در محل امن ثبت کنید.

Backup / Recovery

از /etc/nginx، certificate chain و secret با کنترل دسترسی backup بگیرید؛ محتوای برنامه و database خارج از scope Nginx است. در rollback فایل enterprise-app را با نسخه قبلی جایگزین کنید، nginx -t بگیرید و reload کنید. اگر اولین استقرار است symlink جدید را خارج کنید و تنظیم قبلی را validate کنید. قطع سرویس با stop/start روش عادی rollback نیست.

Best Practices

Reload فقط پس از syntax test، آزمون health و معیار مشخص پذیرش انجام شود. تغییر global worker را با limit سرویس و benchmark هماهنگ کنید.

نسخه‌های قدیمی و Compatibility

این نمونه از listen 443 ssl برای سازگاری package Ubuntu استفاده می‌کند؛ syntax HTTP/2 در شاخه‌های Nginx متفاوت است. نمونه قبلی دارای سه‌نقطه، config اجرایی نیست و فقط در بخش تاریخی حفظ شده است.

پرسش‌های متداول

آیا nginx -t سلامت برنامه را تأیید می‌کند؟

خیر؛ فقط config را بررسی می‌کند و health check برنامه جدا لازم است.

برای 504 باید timeout را زیاد کرد؟

ابتدا latency و وابستگی‌های upstream را بررسی کنید؛ افزایش timeout می‌تواند صف را بزرگ‌تر کند.

منابع رسمی

تاریخ بررسی منابع: 2026-09-30. اعتبارسنجی عملی روی محیط هدف باید پیش از انتشار تغییر زیرساخت انجام شود.

Share