نصب Nginx روی اوبونتو
از صفحه‌ی آزمایشی تا Reverse Proxy

۱) پیش‌نیازها، DNS و تداخل پورت را بررسی کنید

قبل از نصب مشخص کنید Nginx قرار است سایت استاتیک سرو کند یا ترافیک را به یک برنامه‌ی محلی بدهد. رکوردهای A و در صورت استفاده AAAA دامنه باید به IP همین سرور اشاره کنند. انتشار DNS ممکن است زمان ببرد؛ مقدار فعلی را از خود سرور و یک شبکه‌ی بیرونی بررسی کنید.

lsb_release -ds
getent ahosts example.com
sudo ss -lntp | grep -E ':(80|443)[[:space:]]'

اگر Apache، Caddy یا سرویس دیگری روی 80/443 گوش می‌دهد، Nginx نمی‌تواند همان address/port را bind کند. سرویس موجود را بدون شناخت نقش آن متوقف نکنید؛ ابتدا فایل‌های سایت، TLS، reverse proxy و وابستگی‌ها را ثبت و برای مهاجرت برنامه داشته باشید.

برای صدور گواهی عمومی، دامنه باید از اینترنت به سرور برسد و معمولاً پورت 80 یا روش اعتبارسنجی جایگزین در دسترس باشد. اگر فقط IP دارید، ابتدا HTTP را آزمایش کنید و HTTPS دامنه را به بعد از تنظیم صحیح DNS موکول کنید.

۲) بسته‌ی Nginx را نصب و سرویس را محلی آزمایش کنید

مسیر ساده و سازگار با Ubuntu استفاده از بسته‌ی توزیع است. ابتدا فهرست بسته‌ها را تازه و سپس Nginx را نصب کنید:

sudo apt update
sudo apt install nginx
systemctl status nginx --no-pager
nginx -v
curl -I http://127.0.0.1

کد پاسخ HTTP نشان می‌دهد وب‌سرور محلی پاسخ می‌دهد؛ دیده‌نشدن سایت از اینترنت در این مرحله بیشتر به DNS، UFW یا firewall بالادستی مربوط است. وضعیت active (running) را با listener پورت 80 تطبیق دهید.

اگر به نسخه‌ای متفاوت از بسته‌ی Ubuntu نیاز دارید، مخزن رسمی nginx.org دستور نصب و کلید امضا دارد. مخزن شخص ثالث ناشناس یا یک دستور curl | shell را فقط برای گرفتن نسخه‌ی جدیدتر وارد production نکنید؛ منبع بسته و چرخه‌ی به‌روزرسانی بخشی از مدل امنیتی سرور است.

۳) یک server block مستقل برای سایت بسازید

در بسته‌ی Ubuntu، تنظیم هر سایت معمولاً در /etc/nginx/sites-available/ نگهداری و با symlink در sites-enabled فعال می‌شود. ابتدا یک document root تازه بسازید، مالک و مجوز آن را طوری تنظیم کنید که کاربر deploy بتواند بنویسد و کاربر Nginx فقط فایل عمومی را بخواند؛ کل home یا فایل‌های محرمانه را web-readable نکنید.

sudo install -d -m 0755 /srv/example.com/html
sudoedit /etc/nginx/sites-available/example.com

محتوای پایه‌ی فایل:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /srv/example.com/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

پس از قرارگرفتن یک index.html آزمایشی، سایت را فعال کنید. اگر symlink از قبل وجود دارد، فرمان را دوباره یا با اجبار اجرا نکنید؛ مقصد فعلی را با readlink بررسی کنید.

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
readlink -f /etc/nginx/sites-enabled/example.com
sudo nginx -t
sudo systemctl reload nginx

همیشه nginx -t را پیش از reload اجرا کنید. reload معتبر اتصال‌های جاری را مانند restart کامل قطع نمی‌کند. سایت پیش‌فرض را فقط بعد از اطمینان از match شدن server_name و ثبت مسیر بازگشت غیرفعال کنید.

۴) UFW و پاسخ دامنه را از داخل و بیرون آزمایش کنید

پیش از فعال‌سازی یا تغییر UFW، rule پورت SSH را حفظ کنید. برای وب عمومی TCP/80 و بعد از آماده‌شدن TLS، TCP/443 لازم است:

sudo ufw app info 'Nginx Full'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw status numbered

سپس match شدن virtual host را بدون انتظار برای DNS آزمایش کنید:

curl -I -H 'Host: example.com' http://127.0.0.1
curl -I http://example.com

اگر آزمون اول درست و دومی غلط است، تنظیم Nginx احتمالاً کار می‌کند و باید DNS یا مسیر شبکه را بررسی کنید. اگر صفحه‌ی سایت دیگری دیده می‌شود، server_name، default server و فایل‌های فعال را با sudo nginx -T بررسی کنید. خروجی کامل nginx -T ممکن است مسیرهای داخلی و تنظیمات حساس محیط را آشکار کند؛ پیش از اشتراک‌گذاری آن را بازبینی کنید.

۵) Nginx را به‌عنوان reverse proxy برنامه تنظیم کنید

بهتر است برنامه‌ی backend فقط روی loopback، مثلاً 127.0.0.1:3000، گوش دهد و Nginx ورودی عمومی را دریافت کند. پیش از تغییر Nginx مطمئن شوید backend محلی سالم است:

curl -I http://127.0.0.1:3000

سپس بخش location / سایت را متناسب با برنامه جایگزین کنید:

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;
}

بعد از nginx -t تنظیم را reload و هر دو endpoint محلی و عمومی را آزمایش کنید. خطای 502 Bad Gateway اغلب یعنی backend اجرا نیست، روی آدرس یا پورت دیگری bind شده، یا Nginx اجازه اتصال ندارد. افزایش timeout بدون شناخت علت، crash یا کندی backend را درمان نمی‌کند.

برای WebSocket یا upload بزرگ ممکن است directiveهای بیشتری لازم باشد؛ آن‌ها را بر اساس نیاز واقعی و مستندات module مربوط اضافه کنید، نه به‌صورت کپی عمومی برای همه‌ی سایت‌ها.

۶) HTTPS، لاگ‌ها و عیب‌یابی نهایی

پیش از درخواست گواهی، resolve شدن دامنه، پاسخ HTTP و بازبودن پورت‌ها را تأیید کنید. Ubuntu برای Let’s Encrypt استفاده از Certbot را مستند کرده است. Certbot می‌تواند فایل Nginx را تغییر دهد؛ از تنظیم فعلی نسخه‌ی مرجع بگیرید و پس از اجرا دوباره syntax و HTTPS را کنترل کنید.

sudo snap install --classic certbot
sudo certbot --nginx -d example.com -d www.example.com
sudo nginx -t
curl -I https://example.com

برای خطاهای سرویس و درخواست‌ها این منابع را کنار هم ببینید:

sudo journalctl -u nginx -n 100 --no-pager
sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 50 /var/log/nginx/access.log
sudo nginx -t

• bind() failed: پورت در اختیار پردازش دیگری است.
• 403: مجوز عبور از directoryها، مالکیت یا index را بررسی کنید.
• 404: root و URI مورد انتظار با هم سازگار نیستند.
• 502: backend، socket/port و لاگ برنامه را بررسی کنید.
• certificate error: نام دامنه، زنجیره، تاریخ و انتخاب server block را کنترل کنید.