نصب Nginx روی Ubuntu؛ وب‌سرور و Reverse Proxy

Nginx چیست و چرا روی Ubuntu نصب می‌شود؟

Nginx (تلفظ: اِنجین‌اِکس) یک Web Server و Reverse Proxy پرکاربرد است که می‌تواند فایل استاتیک سرو کند، درخواست‌ها را به اپلیکیشن Backend بفرستد و در معماری‌های مختلف به‌عنوان HTTP Cache یا Load Balancer استفاده شود. Nginx به خاطر معماری Event-driven و غیرهمزمانش شناخته می‌شود که به آن اجازه می‌دهد تعداد بسیار زیادی اتصال همزمان را با مصرف حافظه پایین مدیریت کند.

در دنیای وب امروز، Nginx تقریباً همه‌جا حضور دارد. از سایت‌های کوچک شخصی تا بزرگ‌ترین پلتفرم‌های اینترنتی مثل Netflix، Cloudflare، WordPress.com و GitHub از Nginx استفاده می‌کنند. دلیلش ساده است: Nginx هم سریع است، هم سبک، و هم انعطاف‌پذیری بالایی دارد. اگر یک VPS دارید و می‌خواهید سایت، API یا اپلیکیشن خود را روی آن اجرا کنید، Nginx تقریباً همیشه بهترین انتخاب برای لایه ورودی است.

یکی از دلایل اصلی محبوبیت Nginx، توانایی آن در مدیریت تعداد بالای اتصالات همزمان با مصرف حافظه بسیار کم است. برخلاف Apache که برای هر اتصال یک Process یا Thread جداگانه می‌سازد، Nginx از یک معماری Event-driven استفاده می‌کند که در آن یک Worker Process می‌تواند هزاران اتصال را همزمان مدیریت کند. همین ویژگی است که Nginx را برای سایت‌های پربازدید و APIهای پرترافیک ایده‌آل می‌کند.

تاریخچه کوتاه Nginx

Nginx را یک مهندس روسی به نام Igor Sysoev در سال ۲۰۰۲ ساخت و در سال ۲۰۰۴ به‌صورت عمومی منتشر کرد. او در آن زمان روی سایتی با ترافیک بسیار بالا کار می‌کرد و Apache نمی‌توانست به‌خوبی از پس بار سنگین بربیاید. به همین دلیل Nginx را با معماری متفاوتی طراحی کرد که بتواند با منابع محدود، تعداد بسیار زیادی اتصال را مدیریت کند.

در سال ۲۰۱۱، شرکت Nginx Inc. تأسیس شد و در سال ۲۰۱۹ این شرکت توسط F5 Networks خریداری شد. با این حال، Nginx همچنان به‌صورت Open Source توسعه داده می‌شود و نسخه رایگان آن برای همه قابل استفاده است.

نصب Nginx از مخزن Ubuntu

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

sudo apt update sudo apt install nginx

بعد از نصب، Nginx به‌صورت خودکار اجرا می‌شود. اگر می‌خواهید نسخه نصب‌شده را ببینید:

nginx -v

برای دیدن نسخه کامل‌تر همراه با جزئیات Compile Options:

nginx -V

حرف بزرگ V اطلاعات بیشتری مثل نسخه OpenSSL، ماژول‌های کامپایل‌شده و مسیر فایل‌های کانفیگ را نشان می‌دهد.

تفاوت نسخه Stable و Mainline

Nginx دو شاخه اصلی دارد:

• Stable: نسخه پایدار که فقط Bugfix و Patch امنیتی می‌گیرد. برای Production مناسب است.
• Mainline: نسخه فعال که ویژگی‌های جدید هم به آن اضافه می‌شود. برای کسانی که می‌خواهند از آخرین قابلیت‌ها استفاده کنند.

در Ubuntu، بسته پیش‌فرض معمولاً نسخه Stable است. اگر می‌خواهید Mainline نصب کنید، باید مخزن رسمی Nginx را اضافه کنید:

sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/mainline/ubuntu $(lsb_release -cs) nginx" | sudo tee /etc/apt/sources.list.d/nginx.list sudo apt update sudo apt install nginx

بررسی سرویس

بعد از نصب، باید مطمئن شوید که سرویس Nginx درست کار می‌کند. از این دستورها استفاده کنید:

sudo systemctl status nginx curl -I http://127.0.0.1

دستور اول وضعیت سرویس را نشان می‌دهد. اگر Active: active (running) دیدید، یعنی Nginx در حال اجراست. دستور دوم یک درخواست HTTP به خود سرور می‌فرستد و باید پاسخ 200 OK بگیرید.

اگر Nginx درست کار می‌کند، از مرورگر هم می‌توانید IP سرور را باز کنید و صفحه پیش‌فرض «Welcome to nginx!» را ببینید. اگر این صفحه را نمی‌بینید، ممکن است فایروال یا Security Group ابری شما پورت ۸۰ را باز نکرده باشد.

مدیریت سرویس Nginx

Nginx مثل بقیه سرویس‌های لینوکس با systemctl مدیریت می‌شود. این دستورها را یاد بگیرید:

sudo systemctl start nginx # اجرا sudo systemctl stop nginx # توقف sudo systemctl restart nginx # ری‌استارت (با قطعی کوتاه) sudo systemctl reload nginx # اعمال تغییرات بدون قطعی sudo systemctl enable nginx # اجرا در زمان بوت sudo systemctl disable nginx # عدم اجرا در زمان بوت

نکته مهم: بعد از هر تغییر در فایل‌های کانفیگ، به‌جای restart از reload استفاده کنید. Reload بدون قطع کردن اتصالات فعلی، تنظیمات جدید را اعمال می‌کند و کاربران شما متوجه هیچ تغییری نمی‌شوند.

اگر شک دارید که آیا Nginx در حال اجراست یا نه، از این دستور استفاده کنید:

systemctl is-active nginx systemctl is-enabled nginx

بازکردن HTTP و HTTPS در UFW

اگر از فایروال UFW استفاده می‌کنید، باید پورت‌های ۸۰ (HTTP) و ۴۴۳ (HTTPS) را باز کنید. Nginx یک Profile آماده برای UFW دارد:

sudo ufw app list sudo ufw allow 'Nginx Full'

گزینه Nginx Full هم HTTP و هم HTTPS را باز می‌کند. اگر فقط HTTP می‌خواهید، از Nginx HTTP استفاده کنید. برای بررسی وضعیت فایروال:

sudo ufw status verbose

مسیرهای مهم Nginx در Ubuntu

ساختار فایل‌های Nginx در Ubuntu کمی با سایر توزیع‌ها متفاوت است. این مسیرها را بشناسید:

• /etc/nginx/nginx.conf — فایل کانفیگ اصلی. تنظیمات Global مثل تعداد Worker Process و Connection Limit اینجاست.
• /etc/nginx/sites-available/ — کانفیگ‌های Server Block. فایل‌های اینجا تا وقتی لینک نشوند، فعال نیستند.
• /etc/nginx/sites-enabled/ — لینک‌های نمادین به فایل‌های فعال در sites-available.
• /etc/nginx/conf.d/ — محل جایگزین برای Snippetهای کانفیگ که خودکار Include می‌شوند.
• /etc/nginx/mime.types — فهرست MIME Typeها که Nginx برای تشخیص نوع فایل استفاده می‌کند.
• /etc/nginx/snippets/ — قطعه‌کدهای کانفیگ قابل استفاده مجدد.
• /var/www/html/ — Document Root پیش‌فرض.
• /var/log/nginx/access.log — لاگ تمام درخواست‌های ورودی.
• /var/log/nginx/error.log — لاگ خطاها و پیام‌های تشخیصی.

الگوی sites-available و sites-enabled به شما اجازه می‌دهد یک سایت را بدون حذف کانفیگ، غیرفعال کنید. کافی است لینک نمادین را از sites-enabled پاک کنید.

درک فایل nginx.conf

فایل اصلی /etc/nginx/nginx.conf ساختار سلسله‌مراتبی دارد. درک این ساختار برای عیب‌یابی و بهینه‌سازی ضروری است:

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

events {
worker_connections 768;
multi_accept on;
}

http {
sendfile on;
tcp_nopush on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
gzip on;
include /etc/nginx/conf.d/.conf;
include /etc/nginx/sites-enabled/;
}

بلوک events تنظیمات مربوط به اتصالات را کنترل می‌کند. worker_connections حداکثر تعداد اتصال همزمان هر Worker را تعیین می‌کند. بلوک http تنظیمات سراسری HTTP را در خود دارد و Server Blockها را Include می‌کند.

ساخت Server Block برای دامنه

Server Block در Nginx معادل Virtual Host در Apache است. با آن می‌توانید چند سایت را روی یک سرور میزبانی کنید. برای ساخت Server Block جدید:

sudo nano /etc/nginx/sites-available/example.com

محتویات فایل را به این صورت بنویسید:

server { listen 80; listen [::]:80; server_name example.com www.example.com; root /var/www/example.com; index index.html index.htm;

location / {
try_files uriuriuri/ =404;
}

location ~ /.ht {
deny all;
}
}

دستور listen می‌گوید Nginx روی پورت ۸۰ گوش بدهد. server_name دامنه‌ای است که این بلوک مسئول آن است. root مسیر فایل‌های سایت را مشخص می‌کند و try_files ترتیب جست‌وجوی فایل‌ها را تعیین می‌کند.

بعد از ساخت فایل، باید پوشه سایت را بسازید و یک فایل آزمایشی داخلش بگذارید:

sudo mkdir -p /var/www/example.com sudo chown -R $USER:$USER /var/www/example.com nano /var/www/example.com/index.html

برای فعال کردن Server Block، یک لینک نمادین در sites-enabled بسازید:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

اگر می‌خواهید Server Block پیش‌فرض را غیرفعال کنید:

sudo rm /etc/nginx/sites-enabled/default

تنظیم Server Block پیش‌فرض برای Catch-All

یک تکنیک حرفه‌ای این است که Server Block پیش‌فرض را طوری تنظیم کنید که هر درخواستی که به دامنه شما مربوط نیست را رد کند. این کار از حملات و اسکن‌های تصادفی جلوگیری می‌کند:

server { listen 80 default_server; listen [::]:80 default_server; server_name _; return 444; }

کد 444 یک کد مخصوص Nginx است که اتصال را بدون پاسخ می‌بندد. این کار باعث می‌شود اسکنرها و ربات‌های مخرب نتوانند اطلاعاتی از سرور شما به دست آورند.

تست کانفیگ قبل از Reload

قبل از هر Reload یا Restart، حتماً کانفیگ را تست کنید. Nginx یک دستور عالی برای این کار دارد:

sudo nginx -t sudo systemctl reload nginx

اگر خروجی syntax is okay و test is successful دیدید، کانفیگ سالم است و می‌توانید Reload کنید. اگر خطا داشت، Nginx دقیقاً می‌گوید کدام فایل و کدام خط مشکل دارد.

برای دیدن کانفیگ کامل بعد از Include همه فایل‌ها:

sudo nginx -T

حرف بزرگ T کانفیگ کامل را بعد از پردازش همه Includeها نشان می‌دهد. این برای عیب‌یابی تنظیمات پیچیده بسیار مفید است.

Nginx به‌عنوان Reverse Proxy

یکی از پرکاربردترین کاربردهای Nginx، Reverse Proxy است. در این حالت، Nginx درخواست‌های کلاینت را دریافت می‌کند و آن‌ها را به یک اپلیکیشن Backend (مثل Node.js، Python، PHP یا Java) می‌فرستد. مزیت اصلی این است که اپلیکیشن شما مستقیماً در معرض اینترنت نیست و امنیت بالاتر می‌رود.

location / { proxy_pass http://127.0.0.1:8000; 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; }

این هدرها حیاتی هستند. بدون X-Real-IP و X-Forwarded-For، اپلیکیشن شما IP واقعی کاربر را نمی‌بیند و همه درخواست‌ها از IP لوکال (127.0.0.1) به نظر می‌رسند. این یعنی Logging، Rate Limiting و Geolocation همه از کار می‌افتند.

برای WebSocket، این هدرها را هم اضافه کنید:

proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";

تنظیم Timeout و Buffer در Reverse Proxy

در پروکسی کردن، تنظیمات Timeout و Buffer اهمیت زیادی دارند. مقادیر پیش‌فرض ممکن است برای اپلیکیشن شما مناسب نباشند:

proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 300s; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k;

proxy_connect_timeout حداکثر زمان برای برقراری اتصال به Backend است. proxy_read_timeout حداکثر زمان انتظار برای پاسخ Backend. اگر اپلیکیشن شما کوئری‌های سنگین دارد یا فایل‌های بزرگ تولید می‌کند، این مقادیر را افزایش دهید.

تفاوت Reverse Proxy و Load Balancer

این دو مفهوم اغلب با هم اشتباه گرفته می‌شوند. یک Reverse Proxy درخواست‌ها را از کلاینت دریافت و به یک یا چند سرور Backend هدایت می‌کند. یک Load Balancer این کار را برای توزیع بار بین چند سرور انجام می‌دهد.

تفاوت کلیدی این است: Reverse Proxy می‌تواند فقط با یک سرور Backend کار کند، اما Load Balancer برای منطقی بودن به حداقل دو سرور نیاز دارد. Nginx هر دو نقش را همزمان ایفا می‌کند.

برای راه‌اندازی Load Balancing با Nginx، از بلوک upstream استفاده کنید:

upstream backend_servers { least_conn; server 127.0.0.1:8001; server 127.0.0.1:8002; server 127.0.0.1:8003; }

server {
location / {
proxy_pass http://backend_servers;
}
}

Nginx به‌طور پیش‌فرض از روش Round-Robin (چرخشی) استفاده می‌کند. اگر می‌خواهید سروری که کمتر مشغول است درخواست بگیرد، least_conn را اضافه کنید. برای IP Hash (که هر کاربر همیشه به همان سرور برود):

upstream backend_servers { ip_hash; server 127.0.0.1:8001; server 127.0.0.1:8002; }

Health Check و Failover در Load Balancing

Nginx می‌تواند سرورهای خراب را از چرخه خارج کند. با تنظیمات max_fails و fail_timeout:

upstream backend_servers { server 127.0.0.1:8001 max_fails=3 fail_timeout=30s; server 127.0.0.1:8002 max_fails=3 fail_timeout=30s; server 127.0.0.1:8003 backup; }

سرور backup فقط زمانی استفاده می‌شود که همه سرورهای اصلی از کار افتاده باشند. این یک لایه محافظت عالی برای Production است.

Caching در Nginx

Nginx می‌تواند پاسخ‌های Backend را کش کند تا درخواست‌های تکراری سریع‌تر پاسخ داده شوند. برای فعال‌سازی Cache:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;

server {
location / {
proxy_cache my_cache;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating;
add_header X-Cache-Status $upstream_cache_status;
proxy_pass http://127.0.0.1:8000;
}
}

هدر X-Cache-Status به شما می‌گوید که پاسخ از Cache آمده (HIT) یا از Backend (MISS). این برای عیب‌یابی عالی است.

Compression با Gzip

فعال‌سازی 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/xml+rss text/javascript image/svg+xml; gzip_min_length 1000;

توجه: فایل‌های تصویری (JPEG، PNG، WebP) و ویدیویی از قبل فشرده هستند و Gzip روی آن‌ها تأثیر زیادی ندارد.

Rate Limiting برای محافظت از سرور

Nginx می‌تواند تعداد درخواست‌های هر IP را محدود کند. این برای جلوگیری از Brute Force و DDoS بسیار مفید است:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {
location /login {
limit_req zone=mylimit burst=20 nodelay;
proxy_pass http://127.0.0.1:8000;
}
}

این کانفیگ می‌گوید هر IP حداکثر ۱۰ درخواست در ثانیه می‌تواند بفرستد، اما تا ۲۰ درخواست اضافی در صف نگه داشته می‌شود.

امن‌سازی با HTTPS و Let’s Encrypt

بعد از راه‌اندازی سایت، مرحله بعدی فعال‌سازی HTTPS است. بهترین راه استفاده از Let’s Encrypt و ابزار Certbot است که گواهی SSL رایگان و خودکار ارائه می‌دهد.

نصب Certbot:

sudo apt install certbot python3-certbot-nginx

دریافت و نصب خودکار گواهی برای دامنه:

sudo certbot --nginx -d example.com -d www.example.com

Certbot به‌طور خودکار کانفیگ Nginx را برای HTTPS تغییر می‌دهد، ریدایرکت HTTP به HTTPS را فعال می‌کند و گواهی را نصب می‌کند. گواهی‌های Let’s Encrypt هر ۹۰ روز منقضی می‌شوند، اما Certbot یک تایمر خودکار برای تمدید تنظیم می‌کند.

برای تست تمدید خودکار:

sudo certbot renew --dry-run

تنظیم ریدایرکت HTTP به HTTPS

اگر می‌خواهید همه ترافیک HTTP به HTTPS منتقل شود، این کانفیگ را در Server Block خود اضافه کنید:

server { listen 80; listen [::]:80; server_name example.com www.example.com; return 301 https://$server_name$request_uri; }

کد 301 یعنی ریدایرکت دائمی و به مرورگر می‌گوید از این به بعد مستقیم HTTPS را باز کن.

تنظیم Security Headers

برای امنیت بیشتر، این هدرها را به کانفیگ HTTPS اضافه کنید:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Content-Security-Policy "default-src 'self'" always;

هدر Strict-Transport-Security یا HSTS به مرورگر می‌گوید برای مدت مشخصی فقط از HTTPS استفاده کند. این یک لایه امنیتی مهم است.

خطاهای رایج و راه‌حل آن‌ها

502 Bad Gateway

این خطا یعنی Nginx نمی‌تواند به Backend وصل شود. اولین قدم بررسی لاگ خطاست:

tail -f /var/log/nginx/error.log | grep -E "502|upstream|connect"

اگر Connection refused دیدید، یعنی Backend روی پورت مورد نظر گوش نمی‌دهد. با ss -tlnp | grep :8000 بررسی کنید. اگر Backend در حال اجراست اما باز هم خطا می‌گیرید، ممکن است مشکل از فایروال یا SELinux باشد.

504 Gateway Timeout

Backend پاسخ نمی‌دهد یا خیلی کند است. Timeoutها را در کانفیگ Nginx افزایش دهید:

proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 300s;

413 Request Entity Too Large

فایل آپلودی از حد مجاز بزرگ‌تر است. محدودیت را افزایش دهید:

client_max_body_size 100m;

این را می‌توانید در بلوک http، server یا location تنظیم کنید.

Port Already in Use

اگر خطای bind() to 0.0.0.0:80 failed گرفتید، یعنی سرویس دیگری (مثل Apache) روی پورت ۸۰ کار می‌کند. با sudo lsof -i :80 پیدا کنید و متوقفش کنید.

خطای Permission در مسیر سایت

اگر Nginx نمی‌تواند فایل‌های سایت را بخواند، مالکیت و دسترسی پوشه را بررسی کنید. Nginx معمولاً با کاربر www-data اجرا می‌شود.

sudo chown -R www-data:www-data /var/www/example.com sudo chmod -R 755 /var/www/example.com

404 Not Found

فایل مورد نظر پیدا نمی‌شود. مسیر root و فایل‌های موجود در آن را بررسی کنید. همچنین try_files را چک کنید.

403 Forbidden

دسترسی به فایل یا پوشه رد شده. معمولاً به خاطر Permission یا تنظیمات deny در کانفیگ است.

Nginx اصلاً شروع نمی‌شود

با sudo nginx -t خطای کانفیگ را پیدا کنید. اگر خطای Syntax نبود، ممکن است پورت اشغال باشد یا فایل لاگ قابل نوشتن نباشد.

مانیتورینگ و لاگ‌ها

لاگ‌های Nginx منبع طلایی برای عیب‌یابی و تحلیل ترافیک هستند. دو فایل اصلی:

• /var/log/nginx/access.log — هر درخواست ورودی با IP، زمان، مسیر، کد وضعیت و User-Agent.
• /var/log/nginx/error.log — خطاها و هشدارها.

برای دیدن خطاهای اخیر:

sudo tail -f /var/log/nginx/error.log

برای دیدن پرترددترین IPها:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

تنظیم Log Rotation

لاگ‌های Nginx می‌توانند خیلی سریع بزرگ شوند. Ubuntu به‌صورت پیش‌فرض logrotate را برای Nginx تنظیم کرده است، اما بهتر است تنظیمات آن را بررسی کنید:

cat /etc/logrotate.d/nginx

این فایل معمولاً لاگ‌ها را روزانه چرخش می‌دهد و ۱۴ نسخه قدیمی را نگه می‌دارد.

بهینه‌سازی عملکرد Nginx

برای سایت‌های پرترافیک، این تنظیمات را در نظر بگیرید:

worker_processes auto; worker_rlimit_nofile 65535;

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

http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
keepalive_requests 1000;
open_file_cache max=10000 inactive=30s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
}

این تنظیمات به Nginx اجازه می‌دهد فایل‌های پرتکرار را کش کند و تعداد فایل‌های باز همزمان را افزایش دهد.

Nginx در مقابل Apache

Nginx به‌عنوان HTTPS Forward Proxy

علاوه بر Reverse Proxy، Nginx می‌تواند به‌عنوان Forward Proxy هم استفاده شود. این برای سناریوهایی است که کلاینت‌ها از طریق یک سرور واسط به اینترنت وصل می‌شوند:

server { listen 8888; resolver 8.8.8.8; location / { proxy_pass http://$http_host$request_uri; } }

اجرای Nginx در Docker

اگر از Docker استفاده می‌کنید، Nginx یک Image رسمی دارد:

docker run -d --name nginx -p 80:80 -p 443:443 -v /path/to/nginx.conf:/etc/nginx/nginx.conf:ro nginx

برای محیط Production، بهتر است از Docker Compose استفاده کنید و فایل‌های کانفیگ و لاگ را Volume کنید.

سؤالات متداول

منابع و مستندات