نصب و پیکربندی مقدماتی Nginx

نصب و پیکربندی مقدماتی Nginx

تاریخ انتشار: ۷ ماه پیش

آخرین ویرایش: ۷ ماه پیش

سطح مقاله: پیشرفته

دسته:Nginx

بازدید: ...

مشاهده ی عناوین مهم این مقاله ساختار و سرتیتر های مقاله:

پیش نیاز

برای مطالعه ی این مقاله باید به صورت کلی با مباحث وب سرور ها (مثل ارسال درخواست به یک سرور، دریافت پاسخ از سرور و ...) و معماری غیرهمگام و مفاهیم thread و core آشنا باشید. همچنین باید دامنه ی خریداری شده رو روی سرور VPS خودتون تنظیم کنین. اگه دامنه رو از یک جا و سرور رو از یک جا خریدین باید دستی این کار رو انجام بدین. اول باید به سایتی برین که ازش سرور رو خریدین و DNS هاش رو پیدا کنین. اگه پیدا نکردین یه تیکت پشتیبانی بهشون بزنین و بگین آدرس های DNS رو بهتون بدن تا روی دامنه تون تنظیم کنین. دوم باید به سایتی که ازش دامنه خریدین برین و از قسمت DNS های دامنه، آدرس های DNS سرورتون رو وارد کنین (همونایی که تو مرحله ی اول گرفتین). فرآیند تنظیم شدن DNS هاتون (که بهش DNS Propagation میگن) بین ۲۴ تا ۴۸ ساعت طول میکشه و بعضی مواقع تا ۷۲ هم میره! دیگه خدا بده شانس.

Nginx (تلفظ به شکل engine-ex - به فارسی «اِنجین اِکس) یک وب سرور بسیار اوپن سورس و قدرتمنده که معمولا برای سِرو کردن (serve - به معنی ارسال یک مقدار یا فایل به عنوان پاسخ به یک درخواست) فایل های استاتیک استفاده میشه. اوایلی که Nginx اومده بود فقط یه وب سرور HTTP بود اما این روزا میتونه هزار تا کار دیگه مثل تبدیل شدن به یک پروکسی معکوس (reverse proxy) برای پروتکل های HTTP و HTTPS و SMTP و غیره رو انجام بده یا اینکه به عنوان تعدیل کننده ی بار (load balancer) جلوی یک سرویس قرار بگیره یا تبدیل به یک لایه ی کش بشه! اولین بار Nginx سال ۲۰۰۴ و توسط آقای Igor Sysoev ساخته شد تا مشکل C10k (ده‌هزار کانکشن همزمان) رو حل کنه اما تو این دوره زمونه ۱۰ هزار کانکشن همزمان جک حساب میشه و Nginx خیلی بیشتر از این حرف ها رو انجام میده چون معماری آسنکرون یا غیر همگام (asynchronous architecture) و همچنین رویداد محور هم داره.

اول از همه باید بدونیم Nginx چطوری کار می کنه. زمانی که شما یک درخواست برای باز کردن یک صفحه ی خاص (مثلا index.html) رو به سروری ارسال می کنید که Nginx روش نصبه، Nginx میره دنبال اون فایل میگرده و اگه اجازه داشت اون رو براتون ارسال می کنه. این ساده ترین حالت کار Nginx میشه که همون سرو کردن فایل های استاتیکه. اگه وب سرور های دیگه مثل Apache رو بشناسین می دونین که Apache برای هر درخواست یک رشته ی پردازشی (thread) جداگانه می سازه اما Nginx رویداد محور (event driven) و غیرهمگام هست بنابراین مثل Node.js عمل می کنه و رویداد ها رو مداوما پیگیری می کنه.

Nginx به دو قسمت worker process (پروسه های کارگر) و worker connections (اتصالات کارگر) تقسیم میشه. هر پروسه ی کارگر چند تا اتصال کارگر داره که مسئول رهگیری درخواست ها و پاسخ های لازم به کاربر هستن. هر زمانی که یک اتصال کارگر جواب کاربر رو پیدا کرد همه چیز رو با جواب برای پدرش، یعنی پروسه ی کارگر، میفرسته. باید بدونین که در حالت ایده ال هر پروسه ی کارگر حدود ۱۰۲۴ اتصال کارگر رو پوشش میده. در نهایت پروسه ی کارگر درخواست رو برای پروسه ی ارباب (master process) ارسال می کنه که رئیسشون حساب میشه و شخصا فقط به درخواست های غیر تکراری جواب میده.

از اونجایی که اکثر سرور های دنیا روی لینوکس سوار هستن من از Debian به عنوان نمونه برای نصب استفاده می کنم اما شما می تونین از راهنمای نصب رسمی Nginx هر دیستروی خاصی رو خواستین انتخاب کنین. برای نصب Nginx دو تا راه داریم. راه اول استفاده از ریپوزیتوری خود Debian یا Ubuntu هست که ساده است اما آخرین آپدیت رو نداره (همیشه یکم عقب تره). اگر از این راه می خواین برین کافیه دو تا دستور زیر رو توی ترمینال سرورتون اجرا کنین:

sudo apt update
sudo apt install nginx

به همین راحتی تمومه!

راه دوم اینه که از ریپوزیتوری مستقل nginx استفاده کنیم که همیشه آپدیت تر هست. از اینجا به بعد برای دوستانیه که میخوان از این روش استفاده کنن. از اینجا به بعد فقط برای Debian هست و اگر دیستروی دیگه ای دارید به جای دستورات زیر از همون وب سایت Nginx که بالاتر لینکش رو دادم، دستورات مربوط به خودتون رو پیدا کنین. خب! اول از همه باید مطمئن بشیم وابستگی های Nginx نصب شدن بنابراین دستور زیر رو داخل ترمینالتون اجرا کنین:

sudo apt install curl gnupg2 ca-certificates lsb-release debian-archive-keyring

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

curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
| sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

حالا دستور زیر رو اجرا کنین تا مطمئن بشیم فایل دانلود شده معتبره:

gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg

نتیجه ی این درخواست باید به شما دقیقا شناسه ی 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62 رو بده. دقت کنید که حتما یکی باشه. نتیجه ای هم که داخل ترمینال چاپ میشه اینه:

pub rsa2048 2011-08-19 [SC] [expires: 2024-06-14]
573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62
uid nginx signing key <signing-key@nginx.com>

اگر شناسه یکی نبود فایل رو کلا حذف کنین.

حالا باید ریپوزیتوری Nginx رو به لیست ریپوزیتوری های سرور اضافه کنیم تا به آپدیت هایی که بعدا منتشر میشه دسترسی داشته باشیم:

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/debian `lsb_release -cs` nginx" \
| sudo tee /etc/apt/sources.list.d/nginx.list

همونطور که اول گفتم خود ریپوزیتوری debian هم پکیج nginx رو داره واسه همین باید این ریپوزیتوری اضافه شده رو پین کنیم تا موقع نصب اولویت داشته باشه:

echo -e "Package: *\nPin: origin nginx.org\nPin: release o=nginx\nPin-Priority: 900\n" \
| sudo tee /etc/apt/preferences.d/99nginx

حالا با دو تا دستور زیر Nginx رو نصب کنین:

sudo apt update
sudo apt install nginx

چون ریپوزیتوری خود nginx رو به لیست ریپوزیتوری های سرور اضافه کردیم از این به بعد دیگه دستورات بالا از ریپوزیتوری debian استفاده نمیکنن.

هر برنامه ای که روی سرور شما باشه و بخواد با خارج از سرور ارتباط بگیره باید از سد فایروال (firewall) بگذره و برای گذشتن از این سد حتما باید اجازه داشته باشه. این مقاله درمورد فایروال نیست اما باید بدونین که سرورتون حتما باید فایروال داشته باشه وگرنه سرور نیست، مثل طویله ی بی در میشه که هر کی میخواد میاد و میره. توی لینوکس برای فایروال برنامه های مختلفی داریم. من از یک فایروال ساده و خیلی محبوب به اسم ufw استفاده می کنم که اگه ندارین میتونین با sudo apt install ufw نصبش کنین. اول از همه باید ببینیم وضعیت فایروال چطوریه:

sudo ufw app list

با اجرای این دستور گزارشی از برنامه هایی که یک پروفایل براشون داخل ufw تعریف شده براتون گزارش میشه. مثلا برای سرور من چنین نتیجه ای رو میده:

// کلی برنامه هست من فقط بخشی ازشون رو میارم
Mail submission
NFS
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH
// و ادامه ی لیست ...
نکته ی مهم

نکــــــته!

لیست بالا، لیست برنامه های مجاز به عبور از فایروال نیست بلکه لیست برنامه هاییه که یک پروفایل از خودشون برای ufw تعریف کردن! این پروفایل ها یه سری فایل ساده هستن که توی /etc/ufw/applications.d/ جا گرفتن. شما هم می تونین پروفایل های خودتون رو توی همین مسیر بسازین.

حالا چرا سه تا پروفایل برای Nginx داریم؟ معنیشون به ترتیب این شکلیه:

  • Nginx Full: یعنی Nginx هم به پورت ۸۰ (پورت عادی وب یا HTTP) و هم به پورت ۴۴۳ (پورت رمزنگاری شده یا HTTPS) دسترسی داشته باشه.
  • Nginx HTTP: فقط به پورت ۸۰ دسترسی داشته باشه.
  • Nginx HTTPS: فقط به پورت ۴۴۳ دسترسی داشته باشه.

شما به سلیقه ی خودتون از هر کدوم از این پروفایل ها می تونین استفاده کنین. من می خوام به Nginx دسترسی کامل بدم بنابراین دستور زیر رو اجرا می کنم:

sudo ufw allow 'Nginx Full'

با این کار به ufw میگیم به Nginx دسترسی به هر دو پورت ۸۰ و ۴۴۳ رو بده. حالا برای اینکه مطمئن بشین فایروالتون فعاله دستور زیر رو اجرا کنین:

sudo ufw status

اگر نتیجه اش Status: inactive بود یعنی هنوز فایروال رو فعال نکردین بنابراین با دستور زیر فعالش کنین:

sudo ufw enable

با این کار فعال میشه و لیست مجاز یا غیر مجاز رو نشون میده. یک مثال از نتیجه برای کسی که فقط به Nginx دسترسی به پورت ۸۰ رو داده این شکلیه:

Output
Status: active

To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)

اون OpenSSH یک پروفایل دیگه است برای ssh کردن به سرور که ربطی به Nginx نداره. توی ستون Action نوشته Allow که یعنی مجاز به فعالیته و تو ستون From نوشته درخواست ها از چه سورسی قابل قبول هستن که نوشته Anywhere یعنی از همه جا (هر آدرس IP که می خواد باشه) میتونه فعالیت کنه.

در نهایت بررسی می کنیم که Nginx در حال اجرا باشه:

sudo systemctl status nginx

نتیجه باید این شکلی باشه:

nginx.service - nginx - high performance web server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
Active: active (running) since Mon 2023-12-18 10:43:21 UTC; 3h 45min ago
Docs: https://nginx.org/en/docs/
Process: 2982 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
Main PID: 2983 (nginx)
Tasks: 3 (limit: 2353)
Memory: 2.7M
CPU: 24ms
CGroup: /system.slice/nginx.service
├─2983 "nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf"
├─2984 "nginx: worker process"
└─2985 "nginx: worker process"

مهم قسمت Active هست که نوشته باشه active (running) یعنی Nginx فعال و در حال اجرا است. حالا اگه به آدرس ip یا دامنه ی سرورتون برین باید یه صفحه ی ساده ی HTML ببینین:

صفحه ی خوش آمد گویی Nginx
صفحه ی خوش آمد گویی Nginx

این صفحه، صفحه ی خوش آمدگویی Nginx هست که یعنی Nginx فعال شده و کارتون رو درست انجام دادین!

نکته ی مهم

نکــــــته!

میتونین با دستور nginx -v نسخه ی نصب شده از nginx رو ببینین. همچنین برای اطمینان از اجرای خودکار Nginx بعد از هر بار ریستارت شدن سرور دستور sudo systemctl enable nginx رو اجرا کنین.

حالا که Nginx نصب شده باید بریم سراغ پیکربندیش. اولین مفهومی که باید بدونین server blocks ها هستن (دقیقا مشابه virtual host ها روی Apache) که به شما اجازه میدن اطلاعات هر دامنه رو یک جای جداگانه تنظیم کنین. با این روش حتی می تونین چند تا دامنه ی مختلف رو روی یک سرور بزارین (حقیقا فقر بد دردیه!). سوال اینجاست که ما اصلا server block نساختیم پس چطوری Nginx داره صفحه ی HTML خوش آمد گویی رو برامون نمایش میده؟ وقتی Nginx نصب میشه به صورت پیش فرض یه server block ساده رو درست می کنه تا محتوای داخل /var/www/html رو سرو کنه. اگه به این آدرس برین همون فایل خوش آمد گویی (به نام index.nginx-debian.html) رو میبینین!

ما به جای ویرایش server block پیش فرض یه پیکربندی جدا برای خودمون می سازیم. برای این کار باید توی آدرس sudo nano /etc/nginx/sites-available یه فایل پیکربندی بسازیم که کار راحتیه:

sudo nano /etc/nginx/sites-available/your_domain

به جای your_domain باید اسم دامنه ی خودتون رو بزارین. مثلا اگه دامنه ای که خریدین zouerami.dev باشه باید به جای your_domain بنویسین zouerami.dev. یک پیکربندی ساده ی Nginx این شکلیه:

server {
listen 80;
listen [::]:80;

root /home/zouerami;
index index.html index.htm index.nginx-debian.html;

server_name zouerami.dev www.zouerami.dev;

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

این پیکربندی چند تا بخش مهم داره:

  • بخش { ... } server یک server block رو تعریف می کنه. یعنی می خوایم یک پیکربندی برای یک دامنه ی خاص داشته باشیم.
  • بخش listen 80 میگه درخواست های HTTP به پورت ۸۰ رو برای آیپی های IPv4 زیر نظر بگیر و بخش listen [::]:80 هم همین رو واسه آیپی های IPv6 میگه.
  • بخش root /home/zouerami مسیر فایل های سایت شما رو مشخص میکنه. من مسیر home/zouerami رو روی سرور خودم دارم و Nginx برای دامنه ی من (zouerami.dev) فقط از همین پوشه استفاده می کنه و دیگه خارج از اون رو کاری نداره.
  • بخش index index.html index.htm index.nginx-debian.html داره میگه Nginx چه نوع فایل هایی رو سرو کنه. ما اینجا گفتیم اگر فایل های index.html و index.htm و index.nginx-debian.html وجود داشتن اونا رو سرو کن. چطوری؟ وقتی درخواست به دامنه ی شما میاد Nginx اول میگرده index.html رو پیدا کنه. اگه بود همونو میفرسته اگه نه دنبال index.htm میگرده و الی آخر. با این حساب ترتیب نوشتن این فایل ها مهمه.
  • بخش server_name zouerami.dev www.zouerami.dev آدرس دامنه ی شما رو مشخص می کنه که باید آدرس دامنه ی خودتون رو اینجا بنویسین. من دامنه رو با هر دو فرم «با www» و «بدون www» هم نوشتم.
  • بخش location مکان درخواست رو مشخص می کنه. یعنی چی؟ یعنی توی مسیر اصلی سایت ما (آدرس /) چه فایلی درخواست شده؟ مثلا اگه مسیر zouerami.dev/Q درخواست شد، Nginx چیکار کنه؟ ما داخلش نوشتیم try_files $uri $uri/ =404 که یعنی اول فایلی که کاربر درخواست داده رو پیدا کن و بهش بده (همون uri$ که یعنی آدرس درخواست شده - مثلا Q) اگه نشد دنبال فایلی بگرد که در آدرس /uri$ باشه و اگه نشد نهایتا خطای 404 بده.

البته توجه داشته باشین که این پیکربندی یه پیکربندی ساده برای سرو فایل های استاتیک (مثل index.html) هست اما اکثرا ما از برنامه های دیگه مثل express یا next.js و امثالهم استفاده می کنیم. اون موقع چی؟ من یه مثال از سروری میزنم که وب سایتش با Next.js ساخته شده و Nginx رو جلوش گذاشتیم:

server {
listen 80;
listen [::]:80;

server_name zouerami.dev www.zouerami.dev;

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

# SSL/TLS تنظیمات بیشتر برای
# اگر گواهیش رو دارین باید اینجا تنظیماتش رو انجام بدین

# اینجا هم لاگ های خطا و دسترسی رو داریم
access_log /var/log/nginx/zouerami.access.log;
error_log /var/log/nginx/zouerami.error.log;
}

من اینجا از پورت ۸۰ استفاده کردم ولی شما وقتی گواهی SSL گرفتین و دامنه ی خودتون رو HTTPS کردین باید از پورت ۴۴۳ استفاده کنین. همونطور که می دونین برنامه های Next.js روی پورت ۳۰۰۰ اجرا میشن و دامنه ی من هم zouerami.dev هست. با این حساب server block بالا داره میگه توی آدرس اصلی (مسیر /) باید یه سری کارا انجام بشه:

  • بخش proxy_pass http://localhost:3000 داره میگه تمام درخواست هایی که با دامنه ی ما میاد باید توسط Nginx به آدرس localhost:3000 فرستاده بشه (اصطلاحا میگن پراکسی بشه). برای همین به Nginx میگیم پراکسی معکوس!
  • بخش proxy_set_header میگه هدر Host (حتما با HTTP Header ها آشنا هستین دیگه!؟) که از سمت کلاینت میاد، حفظ بشه و به برنامه ی Next.js ما ارسال بشه.
  • بخش های دیگه (X-Real-IP و X-Forwarded-For و X-Forwarded-Proto) هم همین کار رو برای همین هدر ها انجام میده. اگه با این هدر ها آشنایی ندارین یه سرچ ساده بزنین چون ربطی به Nginx ندارن، فقط هدر های کلی توی پروتکل HTTP هستن. مطلب تا همینجا هم خیلی طولانی شده، نمی خوام موقع سال تحویل مقاله رو منتشر کنم!
  • تنظیم SSL یه داستان کاملا جدا است که باید گواهیش رو بگیرین و تنظیماتش رو اینجا بزارین. حقیقتا یه مقاله ی جدا می خواد که بعدا منتشر می کنم.
  • لاگ های دسترسی (Access Logs) جزئیات مربوط به هر درخواست رو ذخیره داخل فایل zouerami.access.log ذخیره می کنن. این اطلاعات شامل IP کاربر ها، آدرس هر درخواست انجام شده، کد های وضعیت، بایت های ارسال شده و غیره میشن.
  • لاگ های خطا (Error Logs) هم شامل جزئیات خطا ها میشن. یعنی هر جایی سرور به خطا برخورد کرد (مثل خطاهای ۵۰۰ یا ۴۰۴) جزئیاتش رو داخل فایل zouerami.error.log می نویسه.

پیکربندی ها خیلی زیاد هستن و انواع مختلفی دارن بنابراین باید کمی سرچ و مطالعه داشته باشین. حالا که پیکربندی خودمون رو نوشتیم باید با دستور زیر تستش کنیم:

sudo nginx -t

اگه پیکربندیتون مشکل داشته باشه این دستور بهتون میگه اما اگه سالم باشه شبیه این نتیجه رو می گیرین:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

اسم فایل پیکربندی بسته به اسمی که انتخاب کردین فرق میکنه. من اینجا دارم پیکربندی خود Nginx رو تست می کنم.

حالا این server block رو چجوری فعال کنیم؟ Nginx یه مسیر خاص به آدرس /etc/nginx/sites-available/ داره که داخلش پیکربندی های فعال رو قرار میده. روشش اینطوریه که Nginx ازتون می خواد یه symlink ساده از فایل پیکربندیتون رو داخل این آدرس بزارین (symlink تو لینوکس مثل shortcut توی ویندوز هست). برای انجام این کار:

sudo ln -s /etc/nginx/sites-available/zouerami.dev /etc/nginx/sites-enabled/

دقت کنین مسیر sites-available/ جاییه که پیکربندیمون رو داخلش نوشتیم (من اسم فایلم رو zouerami.dev گذاشته بودم) و مسیر sites-enabled/ برای ایجاد symlink و فعال کردن اون پیکربندی هست. اینطوری اگه خواستین یه دامنه رو غیر فعال کنین نیازی نیست کل پیکربندی رو حذف کنین، فقط همون symlink رو حذف می کنین و تامام! در حال حاضر دو تا server block روی سیستم ما هست: یکیش zouerami.dev و یکی دیگه همون پیکربندی پیش فرض یا default. اگر درخواستی که به سرور شما میاد به دامنه ی zouerami.dev و www.zouerami.dev نباشه، به پیکربندی پیش فرض منتقل میشه تا اونجا جوابش رو بدن.

هشدار

هشـــدار!

هر وقت فایل پیکربندی Nginx رو تغییر دادن حتما دستور sudo systemctl restart nginx رو اجرا کنین تا nginx یک بار ریستارت و تنظیمات اعمال بشه.

در ضمن یه مشکل شناخته شده ای تو Nginx هست (وقتی چند تا server name مختلف رو پیکربندی می کنین) که بهش میگن hash bucket memory problem و باعث میشه مموری برای Nginx کم بیاد. برای حل این مشکل بهتره همیشه به فایل پیکربندی اصلی Nginx برین:

sudo nano /etc/nginx/nginx.conf

و داخل این فایل دنبال همچنین مقداری بگردین: 

...
http {
...
server_names_hash_bucket_size 64;
...
}
...

احتمالا برای شما با علامت # کامنت شده. شما مثل من (مقدار بالا) با حذف # از کامنت درش بیارین. دوباره با دستور sudo nginx -t هم یه تست بکنین که مشکلی نباشه. در نهایت دستور sudo systemctl restart nginx رو اجرا کنین تا Nginx یک بار ریستارت بشه و تنظیمات جدید رو بارگذاری کنه. آقا وب سایت جدید رو تبریک می گم!

Nginx خیلی استفاده ها و تنظیمات دیگه ای داره واسه همین همیشه جای مطالعه هست. میتونین با کلیک روی دسته بندی Nginx (زیر تصویر مقاله - بالای همین صفحه) مقالات دیگه توی دسته ی Nginx رو هم مطالعه کنین.

خیلی از اوقات پیش میاد که Nginx به صورت پیش فرض پیکربندی خودش رو اولویت میدونه و پیکربندی شما کتفش هم حساب نمیشه و اصلا به مسیر etc/nginx/sites-enabled/ نگاه نمیکنه. چطور میشه فهمید؟ ساده ترین راهش اینه که فایل پیکربندیتون رو تغییر بدین تا یه فایل ساده (مثلا index.html) رو سرو کنه (یادتون نره nginx رو ریستارت کنین تا تغییرات اعمال بشه).  اگه بعدش به دامنه ی خودتون رفتین و بازم همون صفحه ی خوش آمد گویی Nginx رو دیدین یعنی مشکلی هست. اول از همه دستور زیر رو اجرا کنین:

sudo nginx -T

دقت کنین که از T بزرگ استفاده کردیم. این دستور فایل نهایی شده ی پیکربندی nginx (یعنی بعد اینکه همه ی پیکربندی های مختلف رو با هم ترکیب کرد) رو به شما نشون میده. اونجا ببینین فایل نهایی چی هست و کجا داره سرو میشه. بسته به نسخه ی Nginx محتوای پیکربندی فرق میکنه اما توی نسخه های جدید معمولا آخر فایل یه دستور include هست که مشخص می کنه کدوم فایل پیکربندی رو include کرده (یعنی لحاظ کرده یا شامل شده). حتما اون رو ویرایش کنین که به مسیر فایل پیکربندی خودتون (مثلا etc/nginx/sites-enabled/zouerami.dev.config) اشاره کنه. بقیه ی قسمت هاش رو هم بر اساس مطالبی که توی این مقاله گفتم چک کنین که مشکلی نباشه و مثلا به یه فایل html پیش فرض به جای پیکربندی شما اشاره نکنه.

شاید از این مقالات نیز خوشتان بیاید:

sample

ساخت هوک (hook) در React

در چند سال اخیر اکثر برنامه نویس های react از سمت کامپوننت های کلاسی دور شدن و به سمت کامپوننت های تابعی رفتن. به همین خاطر استفاده از hook هایی مثل useState و useEffect خیلی رایج شده اما آیا میشه خودمونم hook های شخصی بسازیم و توی برنامه های react ازشون استفاده کنیم؟ قطعا میشه و یکی از بهترین راه های ننوشتن کد اضافی در react همین کار هست. در...

sample

معرفی مقدماتی HTMX

HTMX چیست؟ بازم یه فریم ورک جاوا اسکریپتی دیگه؟! بله اما قول می دم این یکی دیگه فرق داره! در واقع HTMX یه فریم ورک جاوا اسکریپتیه که می خواد سر به تن جاوا اسکریپت نباشه! یه چیزی مقابل react و ادا اصول هاش! در این مقاله با هم با HTMX آشنا می شیم و می بینیم که نقاط قوت و ضعفش کجاست، جامعه ی آماریش چطوره و آیا میشه...