نصب Nginx روی Ubuntu 24.04 یکی از اولین کارهایی است که بعد از آمادهکردن یک سرور لینوکسی برای میزبانی وب انجام میشود. اگر میخواهید یک وبسرور سبک، پایدار و قابلکنترل داشته باشید و اولین سایت خود را با ساختاری تمیز راهاندازی کنید، این مسیر انتخاب مناسبی است. در این مقاله فقط به نصب یک بسته بسنده نمیکنیم؛ از بررسی پیشنیازها و فعالبودن سرویس گرفته تا ساخت ریشه وب، تعریف server block، تست تنظیمات و رفع خطاهای رایج را مرحلهبهمرحله پیش میبریم تا در پایان، یک سایت واقعی و مستقل از صفحه پیشفرض Nginx در اختیار داشته باشید.

این راهنما رویکردی کاملاً عملی دارد. ابتدا نصب Nginx را انجام میدهیم، سپس وضعیت سرویس را بررسی میکنیم، در صورت نیاز دسترسی HTTP را در فایروال باز میکنیم، برای سایت یک مسیر مستقل میسازیم، پیکربندی آن را تعریف میکنیم و در پایان با چند روش ساده مطمئن میشویم که درخواستها واقعاً به سایت خودتان میرسند. در کنار این مراحل، محدودیتها و نکات مهم را هم میبینید؛ مثلاً اینکه چرا بهتر است از همان ابتدا برای هر سایت ساختار جدا داشته باشید، چرا تست پیکربندی پیش از reload ضروری است و چطور خطاهای مربوط به مجوز، پورت یا نام دامنه را پیدا کنید.
فرض میکنیم به یک سیستم Ubuntu 24.04 با دسترسی کاربری دارای مجوز sudo دسترسی دارید. همچنین فرض بر این است که هدف شما در این مرحله، راهاندازی یک سایت ساده استاتیک یا یک صفحه آزمایشی است تا پایه وبسرور را درست بنا کنید. این پایه بعداً برای HTTPS، دامنه واقعی یا حتی اجرای برنامههای پویا هم بهکار میآید. اگر از همان ابتدا بهصورت منظم پیش بروید، توسعه مراحل بعدی بسیار سادهتر خواهد بود.
پیشنیازهای نصب Nginx روی Ubuntu 24.04
پیش از نصب Nginx، چند مورد را بررسی کنید تا در میانه کار با خطاهای قابلپیشگیری روبهرو نشوید. این موارد سادهاند، اما معمولاً همان بخشهایی هستند که بعداً باعث اتلاف وقت میشوند:
- سیستم Ubuntu 24.04 به مخازن بستهها دسترسی داشته باشد.
- کاربر شما امکان اجرای
sudoرا داشته باشد. - اگر فایروال UFW فعال است، اجازه دسترسی به HTTP را تنظیم کنید.
- اگر سرویس دیگری روی پورتهای
80یا443در حال اجراست، قبل از نصب وضعیت آن را مشخص کنید. - برای تست دامنه محلی، بدانید که ممکن است نیاز باشد نامی مانند
example.localرا در فایلhostsکلاینت تعریف کنید.
بهتر است ابتدا فهرست بستهها را بهروز کنید:
sudo apt update
اگر قصد دارید بستههای نصبشده سیستم را هم بهروز کنید، میتوانید این دستور را هم اجرا کنید:
sudo apt upgrade
در سرورهای تازهراهاندازیشده، این کار معمولاً قبل از نصب Nginx مفید است. با این حال اگر روی سرور شما سرویسهای فعال دیگری وجود دارد، بهروزرسانی را با دقت انجام دهید تا تغییری ناخواسته در سرویسهای موجود ایجاد نشود.
نکته مهم دیگر این است که فایلهای پیکربندی Nginx به خطاهای نحوی حساس هستند. یک اشتباه کوچک مثل جا انداختن سمیکالن یا بستهنشدن آکولاد میتواند باعث شود بارگذاری تنظیمات شکست بخورد. به همین دلیل، بعد از نصب Nginx هم هر بار که فایل تنظیمات را تغییر میدهیم، از دستور تست پیکربندی استفاده خواهیم کرد.
نصب Nginx و بررسی سرویس
برای نصب Nginx از مخازن استاندارد Ubuntu، کافی است دستور زیر را اجرا کنید:
sudo apt install nginx
پس از نصب Nginx، معمولاً سرویس بهصورت خودکار ایجاد و اجرا میشود. برای اطمینان، وضعیت آن را بررسی کنید:
sudo systemctl status nginx
اگر همهچیز درست باشد، باید سرویس را در حالت فعال ببینید. در همین مرحله بهتر است بعد از نصب Nginx چند دستور مدیریتی پایه را هم بشناسید، چون در ادامه زیاد به آنها نیاز خواهید داشت:
sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl reload nginx
sudo systemctl enable nginx
بین restart و reload تفاوت مهمی وجود دارد. در reload، Nginx تلاش میکند بدون توقف کامل، تنظیمات تازه را بارگذاری کند. برای بیشتر تغییرات پیکربندی، این گزینه مناسبتر است. اما اگر سرویس اصلاً بالا نیامده یا در وضعیت غیرعادی قرار دارد، گاهی restart لازم میشود.
بررسی پاسخ وبسرور
برای اینکه مطمئن شوید نصب Nginx واقعاً وبسرور را در حال پاسخگویی قرار داده است، میتوانید این دستور را روی خود سرور اجرا کنید:
curl http://127.0.0.1
اگر خروجی HTML صفحه پیشفرض را دیدید، یعنی نصب Nginx در بخش پایه درست انجام شده است. همچنین اگر از مرورگر به IP سرور بروید، معمولاً صفحه پیشفرض Nginx نمایش داده میشود. این صفحه فقط نشان میدهد نصب درست بوده و هنوز سایت اختصاصی شما نیست.
اگر در همین مرحله پاسخی دریافت نمیکنید، معمولاً مشکل به یکی از این بخشها مربوط است: سرویس اجرا نشده، فایروال دسترسی را مسدود کرده یا سرویس دیگری پورت موردنظر را اشغال کرده است. بعد از نصب Nginx، در ادامه هر سه مورد را بررسی میکنیم.
تنظیم فایروال برای دسترسی HTTP
اگر UFW روی سیستم فعال باشد، بعد از نصب Nginx باید اجازه دسترسی به سرویس وب را بدهید. ابتدا پروفایلهای شناختهشده را ببینید:
sudo ufw app list
برای شروع، اگر فقط HTTP لازم دارید، این قانون کافی است:
sudo ufw allow 'Nginx HTTP'
وضعیت فعلی فایروال را هم بررسی کنید:
sudo ufw status
اگر بعداً HTTPS را هم فعال کردید، باید قانون مناسب همان سناریو را اضافه کنید. نکته مهم این است که فقط پورتها و سرویسهایی را باز بگذارید که واقعاً به آنها نیاز دارید. باز بودن بیدلیل پورتها هم سطح حمله را بیشتر میکند و هم تشخیص مشکل را سختتر.
اگر با وجود فعال بودن Nginx هنوز از بیرون سرور به سایت دسترسی ندارید، قبل از هر چیز وضعیت UFW را دوباره بررسی کنید. این یکی از رایجترین جاهایی است که در تست اولیه نادیده گرفته میشود.
ساخت ریشه وب برای اولین سایت
برای اینکه سایت شما از فایلهای پیشفرض سیستم جدا باشد، بهتر است یک ریشه وب مستقل ایجاد کنید. در این مثال از دامنه محلی example.local استفاده میکنیم. اگر دامنه واقعی دارید، همان را جایگزین کنید.
sudo mkdir -p /var/www/example.local/html
سپس مالکیت این مسیر را به کاربر فعلی بدهید تا بعد از نصب Nginx بتوانید بدون کار با حساب ریشه، محتوای سایت را مدیریت کنید:
sudo chown -R $USER:$USER /var/www/example.local/html
مجوزهای متداول را هم تنظیم کنید:
sudo chmod -R 755 /var/www/example.local
اکنون یک فایل ساده برای صفحه اصلی سایت بسازید:
nano /var/www/example.local/html/index.html
محتوای نمونه:
<!doctype html>
<html lang="fa" dir="rtl">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>اولین سایت با Nginx</title>
</head>
<body>
<h2>سایت فعال شد</h2>
<p>اگر این صفحه را میبینید، تنظیمات اولیه Nginx برای این سایت درست است.</p>
</body>
</html>
این صفحه عمداً بسیار ساده است. دلیلش این است که در این مرحله فقط میخواهیم مطمئن شویم لایه وبسرور بعد از نصب Nginx درست کار میکند. اگر از همان ابتدا فایلهای متعدد، قالب پیچیده یا کد سمت سرور وارد کنید، تشخیص منبع خطا دشوارتر میشود. راه درست این است که ابتدا وبسرور را با یک صفحه حداقلی تأیید کنید و بعد سراغ توسعه بیشتر بروید.
نصب Nginx و پیکربندی server block برای سایت
در Nginx هر سایت معمولاً در یک فایل پیکربندی جدا تعریف میشود. در Ubuntu، الگوی رایج این است که فایل در مسیر /etc/nginx/sites-available/ قرار بگیرد و بعد با یک پیوند نمادین در /etc/nginx/sites-enabled/ فعال شود.
ابتدا فایل پیکربندی سایت را بسازید:
sudo nano /etc/nginx/sites-available/example.local
نمونه پیکربندی پایه:
server {
listen 80;
listen [::]:80;
server_name example.local www.example.local;
root /var/www/example.local/html;
index index.html index.htm;
access_log /var/log/nginx/example.local.access.log;
error_log /var/log/nginx/example.local.error.log;
location / {
try_files $uri $uri/ =404;
}
}
هر بخش این فایل نقش مشخصی دارد:
listen 80مشخص میکند سایت روی HTTP پاسخ بدهد.server_nameنامهایی را تعیین میکند که این بلاک باید به آنها پاسخ بدهد.rootمسیر فایلهای سایت را مشخص میکند.indexترتیب فایلهای پیشفرض را تعیین میکند.access_logوerror_logکمک میکنند عیبیابی سایت شما از لاگهای عمومی جدا باشد.try_filesبرای سایتهای استاتیک انتخاب مناسبی است و فقط به فایل یا پوشه موجود پاسخ میدهد.
حالا سایت را فعال کنید:
sudo ln -s /etc/nginx/sites-available/example.local /etc/nginx/sites-enabled/
برای جلوگیری از تداخل صفحه پیشفرض، فایل پیشفرض فعال را غیرفعال کنید:
sudo rm /etc/nginx/sites-enabled/default
قبل از بارگذاری تنظیمات، حتماً نحو پیکربندی را آزمایش کنید:
sudo nginx -t
اگر خروجی موفق بود، تغییرات را اعمال کنید:
sudo systemctl reload nginx
این ترتیب را همیشه رعایت کنید: ویرایش، تست، سپس reload. اگر بدون تست تغییرات را بارگذاری کنید، ممکن است با یک خطای کوچک کل فرایند بارگذاری تنظیمات شکست بخورد و زمان بیشتری صرف تشخیص آن شود.
اگر دامنه واقعی ندارید
برای تست محلی، میتوانید نام دامنه آزمایشی را در فایل hosts سیستم کلاینت تعریف کنید. ساختار معمول به این شکل است:
192.0.2.10 example.local www.example.local
بهجای 192.0.2.10، آدرس IP واقعی سرور خود را قرار دهید. این روش فقط برای تست محلی است و جایگزین DNS عمومی نیست. اگر این مرحله را انجام ندهید و در مرورگر نام دامنه را وارد کنید، ممکن است اصلاً درخواست به سرور شما نرسد.
تست عملی سایت و اطمینان از انتخاب درست server block
در این مرحله باید بتوانید با IP یا نام دامنه تعریفشده، سایت خود را مشاهده کنید. اگر هنوز صفحه پیشفرض Nginx نمایش داده میشود، معمولاً یکی از این حالتها رخ داده است:
- فایل پیشفرض هنوز در
sites-enabledفعال است. server_nameبا نامی که در مرورگر وارد میکنید یکسان نیست.- مرورگر به سرور یا IP دیگری متصل شده است.
- تغییرات پس از تست، reload نشدهاند.
برای بررسی، این دستورها کمک میکنند:
ls -l /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
اگر بخواهید مستقل از DNS یا فایل hosts بررسی کنید که Nginx دقیقاً کدام server block را انتخاب میکند، از curl با هدر میزبان استفاده کنید:
curl -H "Host: example.local" http://127.0.0.1
این روش بسیار کاربردی است، چون نشان میدهد انتخاب server block بر اساس server_name درست انجام میشود یا نه. اگر پاسخ همین صفحهای بود که خودتان ساختهاید، یعنی بخش انتخاب میزبان درست کار میکند.
در مقابل، اگر با IP مستقیم صفحهای متفاوت میبینید، لزوماً به معنی خراببودن تنظیمات نیست؛ ممکن است برای IP مستقیم، server block دیگری بهعنوان پیشفرض انتخاب شود. بنابراین همیشه بین تست با IP و تست با نام دامنه تفاوت قائل شوید.
شناخت ساختار فایلهای پیکربندی Nginx
برای نگهداری بهتر سرور، شناخت چند مسیر اصلی Nginx ضروری است:
/etc/nginx/nginx.confفایل اصلی پیکربندی سراسری/etc/nginx/sites-available/محل تعریف فایلهای سایت/etc/nginx/sites-enabled/محل فعالسازی سایتها/var/log/nginx/محل لاگهای دسترسی و خطا/var/www/محل رایج فایلهای وب
جدا نگهداشتن هر سایت در فایل مستقل، هم نگهداری را سادهتر میکند و هم احتمال اشتباه را کاهش میدهد. این ساختار از همان زمان نصب Nginx مفید است و وقتی بعداً چند سایت روی یک سرور داشته باشید، باعث میشود سریعتر متوجه شوید هر تنظیم به کدام دامنه و کدام مسیر مربوط است.
همچنین بهتر است نام فایل تنظیمات، پوشه سایت و فایلهای لاگ تا جای ممکن همراستا باشند. مثلاً وقتی نام دامنه در همه این بخشها تکرار میشود، عیبیابی سریعتر و خواناتر خواهد شد.
عیبیابی خطاهای رایج
بیشتر خطاها در فرایند راهاندازی اولین سایت با Nginx به چند دسته مشخص تقسیم میشوند. شناخت این دستهها کمک میکند بهجای حدسزدن، سریعتر به ریشه مشکل برسید.
خطای نحوی در فایل پیکربندی
اگر بعد از ویرایش فایل سایت، تست پیکربندی خطا داد، ابتدا خروجی همان دستور را با دقت بخوانید:
sudo nginx -t
این خروجی معمولاً شماره خط و نوع خطا را مشخص میکند. خطاهای رایج شامل سمیکالن جاافتاده، آکولاد بستهنشده یا قرار گرفتن دستور در محل نامناسب است. تا زمانی که این تست موفق نشده، از reload یا restart استفاده نکنید.
مشکل مجوز دسترسی به فایلها
اگر فایلها وجود دارند اما پاسخ مناسب دریافت نمیشود، مجوزها را بررسی کنید. فرایند Nginx باید بتواند پوشهها را پیمایش و فایلهای لازم را بخواند. برای بررسی سطحبهسطح مسیر:
namei -l /var/www/example.local/html/index.html
این دستور مشخص میکند آیا در یکی از پوشههای میانی، دسترسی لازم وجود ندارد یا نه. گاهی فایل نهایی درست است، اما یکی از پوشههای والد مجوز لازم برای عبور را ندارد و همین باعث شکست درخواست میشود.
نکته مهم این است که بالا بردن بیحساب مجوزها راهحل درست نیست. دادن مجوزهایی مانند 777 فقط مشکل را پنهان میکند و از نظر امنیتی انتخاب خوبی نیست.
اشغال بودن پورت 80
اگر Nginx بالا نمیآید، ممکن است سرویس دیگری روی پورت 80 در حال گوشدادن باشد:
sudo ss -tulpn | grep ':80'
در این حالت باید مشخص کنید کدام سرویس باید روی آن پورت فعال بماند. همزمانی چند سرویس روی یک پورت ممکن نیست، مگر اینکه یک لایه دیگر برای مدیریت ترافیک بین آنها قرار داده باشید.
بررسی لاگها
وقتی پاسخ غیرمنتظره دریافت میکنید، لاگها سریعترین مسیر تشخیص هستند:
sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log
اگر برای سایت خود لاگ اختصاصی تعریف کردهاید، همان فایلها را بررسی کنید:
sudo tail -f /var/log/nginx/example.local.error.log
sudo tail -f /var/log/nginx/example.local.access.log
لاگ دسترسی نشان میدهد چه درخواستی رسیده و با چه کد وضعیتی پاسخ گرفته است. لاگ خطا بیشتر برای تشخیص مشکلات مجوز، مسیر فایلها یا رفتار غیرعادی پیکربندی مفید است.
برای مثال، اگر در لاگ دسترسی درخواست ثبت میشود اما کد وضعیت مناسب نیست، یعنی درخواست به Nginx رسیده ولی در مرحله پیدا کردن فایل یا انتخاب تنظیمات مشکلی وجود دارد. اگر اصلاً در لاگ دسترسی اثری از درخواست نیست، باید مسیر رسیدن درخواست تا سرور، مثل DNS، فایل hosts، فایروال یا IP مقصد را بررسی کنید.
نکات امنیتی اولیه بعد از راهاندازی
بالا آمدن سایت پایان کار نیست. حتی برای یک سایت ساده استاتیک هم رعایت چند نکته پایه مهم است.
حداقلسازی سطح دسترسی
فایلهای سایت را با حساب ریشه مدیریت نکنید مگر زمانی که واقعاً لازم است. بهتر است محتوای سایت در اختیار کاربر مدیریتی شما باشد و فقط عملیات سیستمی را با sudo انجام دهید. این کار هم از اشتباهات ناخواسته جلوگیری میکند و هم ساختار مدیریت فایلها را روشن نگه میدارد.
قرار ندادن فایلهای حساس در ریشه وب
ریشه وب باید فقط شامل فایلهایی باشد که واقعاً باید از طریق مرورگر در دسترس باشند. فایلهای پشتیبان، تنظیمات خصوصی، کلیدها، نسخههای موقت یا اطلاعات داخلی را خارج از root نگه دارید. این اشتباه ساده میتواند باعث شود محتوایی که برای انتشار عمومی نیست، ناخواسته قابل دسترسی شود.
کمکردن افشای اطلاعات غیرضروری
بهصورت کلی بهتر است پاسخهای سرویس تا جای ممکن اطلاعات غیرضروری درباره ساختار داخلی را آشکار نکنند. این مورد بهتنهایی امنیت ایجاد نمیکند، اما از افشای بیهوده جزئیات جلوگیری میکند و در سیاست کلی سختگیری بیشتر مفید است.
حرکت به سمت HTTPS
در این مقاله تمرکز روی نصب، راهاندازی و تحویل اولین سایت بود. اما اگر سایت قرار است خارج از شبکه محلی در دسترس باشد، مرحله بعدی طبیعی، استفاده از HTTPS است. این کار برای رمزنگاری ارتباط ضروری است و باید در برنامه بعدی شما قرار بگیرد.
یک پیکربندی کمی بهتر برای سایت استاتیک
بعد از اینکه سایت پایه بهدرستی کار کرد، میتوانید پیکربندی را کمی منظمتر کنید. نمونه زیر هنوز ساده است، اما برای برخی درخواستهای متداول، لاگهای بیفایده را کمتر میکند:
server {
listen 80;
listen [::]:80;
server_name example.local www.example.local;
root /var/www/example.local/html;
index index.html;
access_log /var/log/nginx/example.local.access.log;
error_log /var/log/nginx/example.local.error.log;
location / {
try_files $uri $uri/ =404;
}
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
log_not_found off;
access_log off;
}
}
این پیکربندی همچنان برای سایت ساده مناسب است و بدون پیچیدهکردن بیدلیل تنظیمات، رفتار تمیزتری ارائه میدهد. با این حال از افزودن بخشهایی که دقیقاً نمیدانید چه میکنند خودداری کنید. یکی از خطاهای رایج این است که تنظیمات آماده از منابع مختلف کپی شوند، بدون اینکه با نیاز واقعی سرور هماهنگ باشند.
مدیریت تغییرات بدون بههمریختگی
برای هر تغییر، این روال ساده را حفظ کنید:
- ویرایش فایل پیکربندی یا محتوای سایت
- آزمایش با
sudo nginx -t - بارگذاری تنظیمات با
sudo systemctl reload nginx
اگر چند سایت روی یک سرور دارید، این نظم اهمیت بیشتری پیدا میکند. همچنین پیش از تغییر فایلهای حساس، داشتن یک نسخه پشتیبان ساده از همان فایل مفید است:
sudo cp /etc/nginx/sites-available/example.local /etc/nginx/sites-available/example.local.bak
این روش جایگزین سامانه مدیریت نسخه نیست، اما برای تغییرات کوچک و بازگشت سریع مفید است. مهمتر از خود نسخه پشتیبان، داشتن عادت ثبت و اعمال منظم تغییرات است؛ چون بیشترین خطاها نه از پیچیدگی فنی، بلکه از تغییرات عجولانه و بدون تست ایجاد میشوند.
اگر بعداً بخواهید فراتر از سایت استاتیک بروید
اولین سایت معمولاً استاتیک است، اما همین ساختاری که ساختید پایه خوبی برای مراحل بعدی محسوب میشود. وقتی بخواهید یک برنامه واقعی را پشت Nginx قرار دهید، باز هم همین اصول به کار میآیند: جداسازی سایتها، تعریف لاگ مستقل، تست پیکربندی، مدیریت مجوزها و کنترل دسترسی فایروال.
به بیان دیگر، ارزش اصلی این راهنما فقط بالا آوردن یک صفحه HTML نیست؛ بلکه ساختن یک چارچوب تمیز برای مدیریت وبسرور است. اگر این چارچوب درست باشد، اضافهکردن دامنه واقعی، HTTPS یا اتصال به یک برنامه سمت سرور سادهتر و کمخطاتر خواهد بود.
جمعبندی عملی
نصب Nginx روی Ubuntu 24.04 وقتی ارزشمند است که نتیجه آن فقط نمایش صفحه پیشفرض نباشد، بلکه به راهاندازی یک سایت مستقل و قابلنگهداری منتهی شود. مسیر درست شامل این مراحل است: بهروزرسانی بستهها، نصب سرویس، بررسی وضعیت، تنظیم فایروال در صورت نیاز، ساخت ریشه وب جداگانه، تعریف server block، تست پیکربندی و در نهایت بارگذاری تنظیمات.
اگر در پایان این مقاله سرویس Nginx فعال است، یک پوشه مستقل برای سایت دارید، فایل پیکربندی جداگانه ساختهاید، لاگهای اختصاصی تعریف کردهاید و صفحه آزمایشی خودتان بهجای صفحه پیشفرض سیستم نمایش داده میشود، یعنی پایه کار را درست انجام دادهاید. این دقیقاً همان نقطهای است که از «فقط نصب وبسرور» به «راهاندازی اولین سایت» میرسید.
بعد از این مرحله، مسیر طبیعی توسعه شامل افزودن HTTPS، اتصال دامنه واقعی، بهینهسازی بیشتر پیکربندی و در صورت نیاز، قرار دادن برنامههای سمت سرور پشت Nginx است. اما برای شروع، همین ساختار ساده، تمیز و قابلفهم بهترین نقطه آغاز است.




دیدگاهها