راه‌اندازی Nginx به‌عنوان پروکسی معکوس با HTTPS

۱. معماری پروکسی معکوس

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

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

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

۲. آماده‌سازی DNS و شبکه

رکورد A یا AAAA دامنه را به نشانی عمومی سرور اشاره دهید و از انتشار درست آن مطمئن شوید. صدور گواهی HTTP-01 معمولاً به دسترسی عمومی پورت ۸۰ نیاز دارد.

فایروال را برای ۸۰ و ۴۴۳ باز کنید، اما پورت ۳۰۰۰ برنامه را عمومی نکنید. بهتر است برنامه فقط روی loopback گوش دهد تا دورزدن کنترل‌های Nginx ممکن نباشد.

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

۳. نصب و بررسی سرویس Nginx

Nginx را از مخزن مناسب توزیع نصب کنید و پیش از تغییر تنظیمات از پیکربندی موجود نسخه بگیرید. ساختار sites-available و sites-enabled در توزیع‌های مبتنی بر دبیان رایج است.

وضعیت واحد systemd و نسخه نصب‌شده را ثبت کنید. نصب موفق بسته لزوماً به معنی گوش‌دادن درست روی پورت یا آزادبودن آن نیست.

اگر سرویس دیگری مانند Apache روی ۸۰ فعال است، پیش از راه‌اندازی تعارض را حل کنید. توقف شتاب‌زده سرویس قدیمی می‌تواند سایت فعال را قطع کند.

sudo apt update
sudo apt install nginx
nginx -v
sudo systemctl status nginx

دو خط نخست نصب را انجام می‌دهند؛ نسخه برای مستندسازی مفید است و status وضعیت فرایند و خطاهای آغاز به کار را نشان می‌دهد.

۴. تعریف upstream و عبور هدرها

در فایل سایت، server_name را دامنه واقعی و proxy_pass را نشانی برنامه قرار دهید. هدر Host برای مسیریابی برنامه و X-Forwarded-Proto برای تشخیص طرح اولیه درخواست اهمیت دارند.

هدرهای X-Forwarded-For را فقط در زنجیره پروکسی‌های مورد اعتماد تفسیر کنید. در برنامه، trusted proxies را دقیق تنظیم کنید تا کاربر نتواند IP دلخواه تزریق کند.

در نمونه زیر پیکربندی اولیه فقط HTTP است تا صدور گواهی ساده بماند. فایل را پس از بررسی مسیرها به سایت فعال پیوند دهید و نحو آن را بیازمایید.

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://127.0.0.1:3000;
        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;
    }
}

listen و server_name میزبان عمومی را تعیین می‌کنند؛ location همه مسیرها را می‌گیرد؛ proxy_pass مقصد داخلی است و چهار proxy_set_header زمینه درخواست اصلی را منتقل می‌کنند.

۵. صدور و تمدید گواهی TLS

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

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

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

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com
sudo certbot renew --dry-run

خط اول ابزار و افزونه را نصب می‌کند، خط دوم گواهی می‌گیرد و پیکربندی را تکمیل می‌کند؛ dry-run فرایند تمدید را بدون تغییر واقعی آزمایش می‌کند.

۶. تغییرمسیر HTTP و تنظیمات امنیتی

بعد از تأیید کارکرد HTTPS، درخواست‌های HTTP را به HTTPS هدایت کنید. ریدایرکت دائمی را فقط زمانی فعال کنید که همه دامنه‌ها و مسیرهای لازم در TLS درست کار کنند.

HSTS را با زمان کوتاه آغاز کنید و پس از اطمینان افزایش دهید، زیرا مرورگر را به استفاده اجباری از HTTPS وادار می‌کند. گزینه includeSubDomains را بدون بررسی همه زیردامنه‌ها فعال نکنید.

نسخه‌های قدیمی TLS را غیرفعال و تنظیمات رمزنگاری را مطابق راهنمای به‌روز توزیع نگه دارید. کپی‌کردن فهرست cipher قدیمی بدون توجه به نسخه OpenSSL می‌تواند سازگاری یا امنیت را کاهش دهد.

۷. زمان‌انتظار و اتصال‌های بلندمدت

برای درخواست‌های طولانی یا WebSocket، زمان‌انتظار پیش‌فرض ممکن است کافی نباشد. مقدارها را براساس رفتار واقعی برنامه انتخاب کنید، نه صرفاً برای پنهان‌کردن کندی بک‌اند.

برای WebSocket، هدرهای Upgrade و Connection باید به‌درستی به upstream برسند. آن را با یک اتصال واقعی آزمایش کنید؛ پاسخ HTTP عادی، سلامت WebSocket را ثابت نمی‌کند.

محدودیت اندازه بدنه درخواست را با نیاز بارگذاری فایل هماهنگ کنید. اگر Nginx قبل از برنامه پاسخ 413 دهد، افزایش محدودیت در خود برنامه به‌تنهایی مشکل را حل نمی‌کند.

location /socket/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 60s;
}

نسخه HTTP و دو هدر میانی ارتقای اتصال را ممکن می‌کنند؛ timeout زمان انتظار پاسخ upstream را کنترل می‌کند. این مسیر را فقط در صورت پشتیبانی واقعی برنامه اضافه کنید.

۸. آزمون پیکربندی و عیب‌یابی

پیش از هر reload، دستور nginx -t را اجرا کنید. بارگذاری مجدد معمولاً اتصال‌های جاری را حفظ می‌کند، اما پیکربندی ناسازگار همچنان باید پیش از استقرار شناسایی شود.

کدهای 502 و 504 اغلب به قطع‌بودن برنامه، نشانی upstream اشتباه یا زمان‌انتظار مربوط‌اند. هم‌زمان لاگ خطای Nginx و لاگ برنامه را با شناسه درخواست بررسی کنید.

با curl هم پاسخ HTTP، هم زنجیره ریدایرکت و هم گواهی HTTPS را کنترل کنید. تست از داخل سرور برای تشخیص مشکل شبکه عمومی کافی نیست؛ آزمون بیرونی نیز لازم است.

sudo nginx -t
sudo systemctl reload nginx
curl -I https://example.com
sudo journalctl -u nginx -n 50

آزمون نحو، اعمال بدون قطع سرویس، بررسی هدر پاسخ و مشاهده رخدادهای اخیر به‌ترتیب مسیر سریع عیب‌یابی را می‌سازند.

۹. بهره‌برداری و نگه‌داری امن

نرخ خطا، تأخیر upstream، انقضای گواهی و فضای دیسک لاگ را پایش کنید. هشدار انقضای گواهی باید زودتر از روز پایان اعتبار ارسال شود.

پیکربندی سایت را نسخه‌بندی کنید، اما کلیدهای خصوصی و اسرار را از مخزن دور نگه دارید. تغییرات را ابتدا در محیط آزمایشی با دامنه و مسیرهای مشابه امتحان کنید.

برنامه بازگشت داشته باشید: نسخه تنظیمات قبلی، روش reload و معیار تصمیم برای rollback را از پیش بنویسید. یک پروکسی قابل اتکا فقط با نصب گواهی ساخته نمی‌شود؛ نیازمند آزمون و نگه‌داری پیوسته است.

اگر Nginx سالم است ولی برنامه پشت آن پاسخ نمی‌دهد، مشکل را در هر دو لایه جداگانه اندازه‌گیری کنید؛ پاسخ 502 خودِ علت نیست.