راهنمای جامع لاگ‌های NGINX: Access Log و Error Log

کیانا1 روز پیش

0 6 خواندن این مطلب 12 دقیقه زمان میبرد

مقدمه

لاگ‌ها برای مانیتورینگ فعالیت‌های هر اپلیکیشنی—فراتر از ارائه اطلاعات ارزشمند هنگام عیب‌یابی‌اش—بسیار مفیدند. مثل هر اپلیکیشن دیگری، NGINX هم رویدادهایی مثل بازدیدکنندگان سایت‌تان، مسائلی که با آن‌ها روبه‌رو شده و موارد بیشتر را در فایل‌های لاگ ثبت می‌کند. این اطلاعات به شما امکان اقدام پیشگیرانه را می‌دهد—در صورتی که تخلفات جدی‌ای در رویدادهای لاگ متوجه شوید. این مقاله شما را با جزئیات درباره نحوه پیکربندی لاگینگ NGINX راهنمایی می‌کند تا بینش بهتری از فعالیت‌هایش داشته باشید.

نکات کلیدی

NGINX دو نوع لاگ اصلی را نگه می‌دارد: لاگ‌های Access همه درخواست‌های HTTP را با جزئیات کلاینت، کدهای پاسخ و زمان‌بندی ثبت می‌کنند؛ در حالی که لاگ‌های Error مسائل سمت سرور، مشکلات پیکربندی و هشدارها را ثبت می‌کنند.
پیکربندی لاگ انعطاف‌پذیر است: می‌توانید فرمت‌های لاگ را سفارشی کنید، سطوح شدت متفاوتی برای لاگ‌های Error تنظیم و فایل‌های لاگ جداگانه به ازای هر Virtual Host یا Location Block پیکربندی کنید.
سطوح شدت لاگ Error، میزان تفصیل (Verbosity) را کنترل می‌کنند: از debug (تفصیلی‌ترین) تا emerg (فقط بحرانی)؛ که به شما امکان تعادل بین جزئیات و مصرف دیسک بر اساس نیازهای محیط‌تان را می‌دهد.
فرمت‌های لاگ سفارشی، تحلیل پیشرفته را ممکن می‌کنند: با شامل کردن متغیرهایی مثل $request_time، $upstream_response_time و $gzip_ratio می‌توانید متریک‌های کارایی را ردیابی و گلوگاه‌ها را عیب‌یابی کنید.
چرخش لاگ و متمرکزسازی ضروری‌اند: از logrotate برای مدیریت فضای دیسک استفاده و با ابزارهایی مثل ELK Stack، Grafana یا BetterStack برای مانیتورینگ و تحلیل متمرکز بین چندین سرور یکپارچه شوید.

پیش‌نیازها

NGINX را با دنبال کردن راهنمای «نحوه نصب Nginx روی اوبونتو» در پارمین کلود نصب کرده‌اید.
اگر هنوز بین وب‌سرورها تصمیم می‌گیرید، می‌توانید مقایسه Apache در مقابل NGINX در پارمین کلود را بخوانید تا به انتخاب‌تان کمک کند.
آشنایی پایه با فایل‌های پیکربندی NGINX و خط فرمان.

لاگ‌ها در NGINX

به‌طور پیش‌فرض، NGINX رویدادهایش را در دو نوع لاگ می‌نویسد—لاگ Error و لاگ Access. در بیشتر توزیع‌های محبوب لینوکس مثل اوبونتو، CentOS یا دبیان، هر دو لاگ Access و Error را می‌توان در /var/log/nginx پیدا کرد؛ با فرض اینکه قبلاً لاگ‌های Access و Error را در فایل پیکربندی Core مربوط به NGINX فعال کرده باشید. بیایید بیشتر درباره لاگ Access و Error مربوط به NGINX و نحوه فعال‌سازی‌شان—اگر قبلاً این کار را نکرده‌اید—کشف کنیم.

لاگ Access مربوط به NGINX چیست؟

NGINX فعالیت‌های همه بازدیدکنندگان سایت‌تان را در لاگ‌های Access ثبت می‌کند. اینجا می‌توانید ببینید چه فایل‌هایی در حال دسترسی‌اند، NGINX چگونه به درخواستی پاسخ داد، کلاینت از چه مرورگری استفاده می‌کند، آدرس IP کلاینت‌ها و موارد بیشتر. امکان استفاده از اطلاعات لاگ Access برای تحلیل ترافیک و یافتن استفاده‌های سایت در طول زمان وجود دارد. علاوه بر این، با مانیتورینگ درست لاگ‌های Access، می‌توان فهمید که آیا کاربری در حال ارسال درخواست‌های غیرمعماری برای یافتن نقص‌ها در اپلیکیشن وبِ دیپلوی‌شده هست یا نه.

لاگ Error مربوط به NGINX چیست؟

از طرف دیگر، اگر NGINX با هر مشکل یا گلیچی روبه‌رو شود، این رویدادها را در لاگ Error ثبت می‌کند. این می‌تواند—مثلاً—وقتی رخ دهد که در فایل پیکربندی‌تان اشتباهی باشد. اگر NGINX نتواند شروع شود یا ناگهان اجرایش متوقف شود، چک کردن لاگ‌های Error به شما کمک می‌کند جزئیات بیشتری درباره مشکل پیدا کنید. ممکن است هم هشدارهایی در لاگ Error متوجه شوید—هرچند این‌ها همیشه مشکل فوری را نشان نمی‌دهند، اما می‌توانند نشانه مسائلی باشند که بعداً جدی می‌شوند. برای رویکرد گام-به-گام تشخیص و رفع خطاهای رایج NGINX با استفاده از لاگ Error، راهنمای «نحوه عیب‌یابی خطاهای رایج Nginx» در پارمین کلود را ببینید.

نحوه فعال‌سازی لاگ Access مربوط به NGINX

به‌طور کلی، لاگ Access را می‌توان با دایرکتیو access_log—چه در بخش http و چه در server—فعال کرد. آرگومان اول یعنی log_file الزامی است؛ در حالی که آرگومان دوم یعنی log_format اختیاری است. اگر هیچ فرمتی تعیین نکنید، لاگ‌ها در فرمت پیش‌فرض combined نوشته می‌شوند:

access_log log_file log_format;

لاگ Access به‌طور پیش‌فرض در context مربوط به http فایل پیکربندی Core مربوط به NGINX فعال است. یعنی لاگ Access همه Virtual Hostها در همان فایل ثبت خواهد شد:

http {
      ...
      ...
      access_log  /var/log/nginx/access.log;
      ...
      ...
}

همیشه بهتر است لاگ‌های Access همه Virtual Hostها را با ثبت‌کردن در فایل‌های جداگانه تفکیک کنید. برای این کار، لازم است دایرکتیو access_log تعریف‌شده در بخش http را با دایرکتیو access_log دیگری در context مربوط به server بازنویسی (Override) کنید:

http {
      ...
      ...
      access_log  /var/log/nginx/access.log;
    
         server {
                  listen 80; 
                  server_name domain1.com
                  access_log  /var/log/nginx/domain1.access.log;
                  ...
                  ...
                }
}

NGINX را برای اعمال تنظیمات جدید Reload کنید. برای دیدن لاگ‌های Access دامنه domain1.com در فایل /var/log/nginx/domain1.access.log، از دستور tail زیر در ترمینال استفاده کنید:

# tail -f /var/log/nginx/domain1.access.log

اعمال فرمت سفارشی در لاگ Access

فرمت لاگ پیش‌فرضِ استفاده‌شده برای ثبت رویدادی در لاگ Access، فرمت لاگ combined است. می‌توانید رفتار پیش‌فرض را با ساخت فرمت لاگ سفارشی خودتان و سپس تعیین نام فرمت سفارشی در دایرکتیو access_log بازنویسی کنید. مثال زیر فرمت لاگ سفارشی‌ای را با گسترش فرمت combined از-پیش-تعریف‌شده با مقدار نسبت فشرده‌سازی gzip پاسخ تعریف می‌کند. سپس فرمت با نشان دادن آن در دایرکتیو access_log اعمال می‌شود:

http {
            log_format custom '$remote_addr - $remote_user [$time_local] '
                           '"$request" $status $body_bytes_sent '
                           '"$http_referer" "$http_user_agent" "$gzip_ratio"';

            server {
                    gzip on;
                    ...
                    access_log /var/log/nginx/domain1.access.log custom;
                    ...
            }
}

وقتی فرمت لاگ بالا را در محیط‌تان اعمال کردید، NGINX را Reload کنید. حالا لاگ Access را tail کنید تا نسبت gzip را در انتهای رویداد لاگ ببینید:

# tail -f /var/log/nginx/domain1.access.log

47.29.201.179 - - [28/Feb/2019:13:17:10 +0000] "GET /?p=1 HTTP/2.0" 200 5316 "https://domain1.com/?p=1" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36" "2.75"

نحوه فعال‌سازی لاگ Error مربوط به NGINX

دایرکتیو error_log لاگینگ خطا را به فایل یا stderr یا syslog—با تعیین حداقل سطح شدت پیام‌های خطای ثبت‌شده—راه‌اندازی می‌کند. سینتکس دایرکتیو error_log این است:

error_log log_file log_level;

آرگومان اول یعنی log_file مسیر فایل لاگ را تعریف و آرگومان دوم یعنی log_level سطح شدت رویداد لاگی که ثبت شود را تعریف می‌کند. اگر log_level را تعیین نکنید، به‌طور پیش‌فرض فقط رویدادهای لاگ با سطح شدت error ثبت می‌شوند. مثلاً، مثال زیر سطح شدت پیام‌های خطای ثبت‌شده را روی crit تنظیم می‌کند. علاوه بر این، دایرکتیو error_log در context مربوط به http یعنی لاگ Error برای همه Virtual Hostها در فایل منفردی در دسترس خواهد بود:

http {
          ...
   error_log  /var/log/nginx/error_log  crit;
   ...
}

امکان ثبت لاگ‌های Error برای همه Virtual Hostها به‌صورت جداگانه با Override کردن دایرکتیو error_log در context مربوط به server هم وجود دارد. مثال زیر دقیقاً همین کار را با Override کردن دایرکتیو error_log در context مربوط به server انجام می‌دهد:

http {
       ...
       ...
       error_log  /var/log/nginx/error_log;
       server {
          listen 80;
          server_name domain1.com;
                 error_log  /var/log/nginx/domain1.error_log  warn;
                        ...
    }
       server {
          listen 80;
          server_name domain2.com;
                error_log  /var/log/nginx/domain2.error_log  debug;
                        ...
    }
}

همه مثال‌های توصیف‌شده بالا رویدادهای لاگ را در فایل ثبت می‌کنند. هم‌چنین می‌توانید دایرکتیو error_log را برای ارسال رویدادهای لاگ به سرور syslog پیکربندی کنید. دایرکتیو error_log زیر لاگ‌های Error را با آدرس IP یعنی 192.168.10.11 و فرمت debug به سرور syslog می‌فرستد:

error_log syslog:server=192.168.10.11 debug;

در برخی شرایط، ممکن است بخواهید لاگ Error را غیرفعال کنید. برای این کار، نام فایل لاگ را روی /dev/null تنظیم کنید:

error_log /dev/null;

سطوح شدت لاگ Error در Nginx

انواع زیادی از سطوح لاگ وجود دارد که با رویداد لاگی مرتبط‌اند و اولویت متفاوتی دارند. همه سطوح لاگ در زیر فهرست شده‌اند. در این سطوح لاگ، debug بیشترین اولویت را دارد و بقیه سطوح را هم شامل می‌شود. مثلاً، اگر error را به‌عنوان سطح لاگ تعیین کنید، رویدادهای لاگی که crit، alert و emergency برچسب‌خورده‌اند را هم ثبت خواهد کرد:

سطح لاگ	توضیح
emerg	پیام‌های اضطراری وقتی سیستم‌تان ممکن است ناپایدار باشد.
alert	پیام‌های هشدار مسائل جدی.
crit	مسائل بحرانی که باید فوراً رسیدگی شوند.
error	خطایی رخ داده. مشکلی حین پردازش صفحه پیش آمد.
warn	پیام‌های هشداری که باید بررسی کنید.
notice	اعلان‌های ساده لاگ که می‌توانید نادیده بگیرید.
info	پیام‌های اطلاعاتی که شاید خوب باشد بدانید.
debug	اطلاعات دیباگ برای تعیین محل خطاها استفاده می‌شود.

تغییر میزان تفصیل در NGINX

NGINX به شما اجازه کنترل میزان تفصیل لاگینگ خطا را از طریق سطوح شدت می‌دهد. می‌توانید دایرکتیو error_log را برای شامل کردن سطوح مختلف—بسته به نیازهای دیباگ‌تان—تغییر بدهید. مثلاً، حین توسعه یا عیب‌یابی مسائل، تنظیم سطح لاگ روی debug خروجی گسترده‌ای فراهم می‌کند که مدیریت درخواست، پارس پیکربندی و تعاملات ماژول را شامل می‌شود.

برای افزایش میزان تفصیل، پیکربندی‌تان را مثل زیر تنظیم کنید:

error_log /var/log/nginx/error.log debug;

بعد از این تغییر، NGINX را Reload کنید:

sudo systemctl reload nginx

در سیستم‌های پروداکشن، تنظیم سطح لاگ روی warn یا error رایج است تا میزان تفصیل کم و مصرف دیسک محدود شود. این سطوح فقط خطاهای قابل-اقدام را ثبت و از پر شدن لاگ‌ها با جزئیات بی‌خطر اجتناب می‌کنند. اما حین حوادث بحرانی یا ردیابی باگ‌های ظریف، سوییچ موقت به info یا debug می‌تواند دید ریزبینانه‌ای فراهم کند.

پیکربندی‌های پیشرفته ممکن است شامل استفاده از لاگینگ شرطی بر اساس متغیرها، یا پیکربندی سطوح لاگ متفاوت به ازای هر Virtual Host هم بشوند. مثلاً، می‌توانید ترافیک عمومی را در سطح warn و مسیرهای مشکوک یا حساس را به‌صورت انتخابی در سطوح info یا debug—با استفاده از چند دایرکتیو error_log در contextهای جداگانه—لاگ کنید.

برای کنترل حتی ظریف‌تر، لاگینگ debug را برای اتصالات خاصی با دایرکتیو debug_connection در بلاک events فعال کنید:

events {
    debug_connection 192.168.1.100;
}

این خروجی debug را فقط به کلاینت‌های مورد اعتماد محدود می‌کند و به‌ویژه هنگام عیب‌یابی پشت NAT یا Reverse Proxy مفید است.

استفاده از لاگ‌های NGINX برای عیب‌یابی مسائل کارایی و امنیت

لاگ‌های NGINX در شناسایی گلوگاه‌های بالقوه و رفتار مشکوک روی سرورتان نقش اساسی دارند. مثلاً، می‌توانید Endpointهای پرب-تأخیر را با فیلتر کردن لاگ‌های Access برای زمان‌های پاسخ طولانی—با استفاده از فرمت‌های لاگ سفارشی—تشخیص بدهید. ممکن است هم IPهای در حال تلاش برای حملات Brute-Force یا اسکن برای آسیب‌پذیری‌ها را با تحلیل الگوهای درخواست و کدهای وضعیتی مثل 403، 404 یا 500 کشف کنید.

رویکرد پایه شامل این‌هاست:

تحلیل کدهای وضعیت برای یافتن جهش‌های غیرمعمول در خطاها.
ردیابی آدرس‌های IP که ترافیک زیاد یا درخواست‌های ناموفق مکرر تولید می‌کنند.
چک کردن User-Agentها برای شناسایی بات‌ها.
مرور هدرهای Referer برای تشخیص ریدایرکت ترافیک از دامنه‌های مشکوک.
مقایسه $request_time و $upstream_response_time برای ایزوله کردن بک‌اندهای کند یا تأخیر دیتابیس.

نمونه فرمت لاگ سفارشی برای تنظیم کارایی:

log_format perf_monitor '$remote_addr [$time_local] "$request" $status '
                        '$request_time $upstream_response_time';

از ابزارهای خط فرمانی مثل awk، cut یا grep برای مرتب‌سازی و تحلیل درخواست‌های کند استفاده کنید:

awk '{print $NF}' /var/log/nginx/access.log | sort -nr | head -n 20

ممیزی امنیتی را می‌توان با اسکریپت‌های پارسر لاگ برای این موارد تقویت کرد:

شمارش تلاش‌های ورود ناموفق به /admin، /login، /wp-login.php
تشخیص هیت‌های تکراری به URLهای ناموجود (Probing)
علامت‌گذاری رشته‌های User-Agent غیرمعمول (مثلاً «curl»، «sqlmap»)
مصورسازی روندهای دسترسی با ابزارهایی مثل GoAccess یا Grafana

یکپارچه‌سازی لاگ‌های NGINX با ابزارهای مانیتورینگ و تحلیل

برای گرفتن بینش‌های عمیق‌تر و خودکارسازی مدیریت لاگ، می‌توانید لاگ‌های NGINX را با ابزارهای مانیتورینگ استاندارد-صناعت یکپارچه کنید:

Logrotate (برای چرخش و پاک‌سازی)

از logrotate برای مدیریت حجم فایل‌ها و جلوگیری از تورم دیسک استفاده کنید. چرخش درست، از مصرف کنترل‌نشده دیسک جلوگیری، دسترس‌پذیری بلندمدت لاگ‌ها را تضمین و از سیاست‌های ممیزی پیروی می‌کند. کانفیگ logrotate محکمی برای NGINX می‌تواند شبیه این باشد:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        systemctl reload nginx > /dev/null 2>/dev/null || true
    endscript
}

با افزودن دایرکتیو mail هشدارهای ایمیلی هنگام شکست را فعال کنید؛ یا وضعیت logrotate را برای ممیزی‌ها در /var/lib/logrotate/status لاگ کنید.

ELK Stack (برای تحلیل لاگ متمرکز)

ELK Stack (یعنی Elasticsearch، Logstash، Kibana) به‌طور گسترده برای Ingest، ذخیره و مصورسازی لاگ‌ها استفاده می‌شود:

Filebeat: ایجنت سبک برای جمع‌آوری لاگ‌های NGINX و Forward کردنشان.
Logstash: از الگوهای grok برای پارس لاگ‌ها و استخراج فیلدها استفاده کنید.
Elasticsearch: لاگ‌ها را در قالب ایندکس‌شده ذخیره و کوئری‌های زمان-واقعی را ممکن می‌کند.
Kibana: داشبورد برای تحلیل روندها، تشخیص ناهنجاری و Drill-Down.

پایپ‌لاین معمول:

Filebeat (هاست NGINX) → Logstash → Elasticsearch → Kibana

این راه‌اندازی می‌تواند جهش‌های 5xx را شناسایی، ترافیک Geo-IP را نگاشت، تأخیر را با مسیرهای خاص همبسته و ترافیک را بر اساس کشور یا مرورگر مصور کند.

Better Stack، Datadog و Loki

این ابزارها دیپلوی سریع و داشبوردهای مدیریت‌شده ارائه می‌دهند:

Better Stack: هشدار بصری، یکپارچه‌سازی Slack، سیاست‌های نگهداری، مانیتورینگ Uptime.
Datadog Logs: جستجوی Full-Text، مانیتورها، دسترسی مبتنی بر نقش، همبستگی APM.
Grafana Loki: تجمیع لاگِ مقیاس‌پذیر و هم‌راستا با Prometheus—برای محیط‌های Cloud-Native ایده‌آل.

لاگینگ syslog ریموت را برای ارسال مستقیم لاگ‌ها از NGINX فعال کنید:

access_log syslog:server=192.168.0.10:514,tag=nginx_access;
error_log syslog:server=192.168.0.10:514,tag=nginx_error;

برای ارسال امن لاگ به کلود، خروجی‌های امن‌شده با TLS یا Ingest از طریق HTTP API (مثلاً از طریق Fluentd یا Vector) را ترجیح دهید.

تجزیه متغیرهای فرمت لاگ NGINX

درک معنای هر متغیر در ورودی لاگ، با دیباگ و تحلیل کمک می‌کند. نمونه ورودی لاگ Access به این شکل است:

192.168.0.1 - - [10/May/2025:13:00:00 +0000] "GET /index.html HTTP/1.1" 200 1024 "-" "Mozilla/5.0"

اینجا تجزیه‌ای آمده:

متغیر	توضیح
$remote_addr	آدرس IP کلاینت.
$remote_user	کاربر احراز-هویت‌شده (در صورت وجود).
$time_local	تایم‌استمپ درخواست.
$request	خط کامل درخواست HTTP.
$status	کد وضعیت پاسخ HTTP.
$body_bytes_sent	حجم بدنه پاسخ.
$http_referer	صفحه‌ای که به منبع درخواستی لینک داده.
$http_user_agent	مرورگر یا باتِ استفاده‌شده.
$request_time	زمان صرف‌شده برای پردازش درخواست در سمت NGINX.
$upstream_response_time	زمان پاسخ سرور Upstream (بک‌اند/API).
$host	هدر Host ارسال‌شده توسط کلاینت.
$http_x_forwarded_for	IP فورواردشده توسط سرورهای Proxy (پشت لود بالانسرها مفید).
$scheme	پروتکل استفاده‌شده (http یا https).
$request_length	حجم درخواست ورودی از کلاینت.
$connection_requests	تعداد درخواست‌های انجام‌شده روی اتصال Keepalive.

این متغیرها را می‌توان در فرمت‌های پیچیده ترکیب، در پارسرهای لاگ سفارشی استفاده یا در پلتفرم‌های SIEM متمرکز برای همبستگی امنیتی و تحلیل رفتاری Ingest کرد.

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

۱. لاگ‌های Access و Error مربوط به NGINX کجا ذخیره می‌شوند؟

به‌طور پیش‌فرض، NGINX لاگ‌هایش را در دایرکتوری /var/log/nginx/ روی سیستم‌های مبتنی بر لینوکس ذخیره می‌کند. دو فایل لاگ اصلی access.log و error.log هستند؛ که به‌ترتیب ترافیک ورودی و خطاهای سمت سرور را ثبت می‌کنند. می‌توانید مسیرهای دقیق فایل لاگ را با چک کردن دایرکتیوهای access_log و error_log در پیکربندی NGINX خودتان (معمولاً در /etc/nginx/nginx.conf یا داخل /etc/nginx/sites-enabled/) تأیید کنید. روی macOS با Homebrew، لاگ‌ها ممکن است در /usr/local/var/log/nginx/ قرار داشته باشند. این مسیرهای پیش‌فرض را می‌توان در بلاک‌های server یا HTTP خودتان سفارشی کرد.

۲. چطور می‌توانم فرمت لاگ NGINX را تغییر بدهم؟

برای تغییر فرمت لاگ در NGINX، از دایرکتیو log_format داخل بلاک http فایل کانفیگ‌تان استفاده کنید. می‌توانید فرمت سفارشی‌ای را با تعیین متغیرهایی مثل $remote_addr، $status، $request_time و موارد دیگر تعریف کنید. وقتی تعریف شد، فرمت را به لاگ Accessای مثل این اختصاص بدهید: access_log /var/log/nginx/custom_access.log custom_format;. فرمت‌های سفارشی به شما کمک می‌کنند زمینه اضافی‌ای مثل نسبت فشرده‌سازی، زمان Upstream یا کوکی‌ها را برای تحلیل عمیق‌تر ثبت کنید. فراموش نکنید بعد از تغییرات، NGINX را Reload کنید (sudo systemctl reload nginx).

۳. سطوح لاگ Error در NGINX چیستند؟

لاگ‌های Error مربوط به NGINX چندین سطح شدت را پشتیبانی می‌کنند که میزان تفصیل لاگینگ را کنترل می‌کنند:

debug: حداکثر جزئیات، برای عیب‌یابی مفید
info و notice: پیام‌های اطلاعاتی
warn: هشدارهایی که اجرا را متوقف نمی‌کنند
error: خطاهای رایجِ مانع پردازش
crit، alert، emerg: مسائل بحرانی سطح-سیستم

هر سطح، پیام‌های شدت بالاتر را هم شامل می‌شود. مثلاً error، crit و alert و emerg را هم لاگ خواهد کرد. می‌توانید سطح موردنظر را در کانفیگ‌تان با error_log /path/to/error.log warn; تنظیم کنید.

۴. آیا می‌توانم لاگ‌های NGINX را در زمان-واقعی مانیتور کنم؟

بله، لاگ‌های NGINX را می‌توان با دستور tail در زمان-واقعی مانیتور کرد. مثلاً tail -f /var/log/nginx/access.log به‌طور پیوسته ورودی‌های لاگ Access را همان‌طور که نوشته می‌شوند استریم می‌کند. ابزارهایی مثل multitail یا less +F قابلیت‌های دیدنِ ارتقایافته‌ای فراهم می‌کنند. برای راه‌اندازی‌های پیشرفته‌تر، می‌توانید مانیتورینگ لاگ بلادرنگ را با پلتفرم‌های لاگینگ متمرکزی مانند ELK Stack، Graylog یا BetterStack یکپارچه کنید؛ که هشدارها، داشبوردها و جستجو بین چندین سرور را ممکن می‌سازد.

۵. چطور لاگینگ NGINX را برای فایل‌ها یا مسیرهای خاص غیرفعال کنم؟

می‌توانید لاگینگ در NGINX را با استفاده از access_log off; و error_log /dev/null; درون Location Block خاصی غیرفعال کنید. این برای دارایی‌های استاتیک (مثل CSS، JS، تصاویر) که لاگینگ لازم ندارند مفید است. مثال:

location /static/ {
    access_log off;
    error_log /dev/null crit;
}

این مصرف دیسک را کم و لاگ‌ها را با حذف ورودی‌های تکراری و کم-ارزش تمیزتر می‌کند.

۶. فرمت لاگ combined در NGINX چیست؟

فرمت لاگ combined، فرمت پیش‌فرضِ استفاده‌شده در لاگ‌های Access مربوط به NGINX است. شامل اطلاعاتی مثل IP کلاینت، تایم‌استمپ، متد HTTP، URI، وضعیت پاسخ و User Agent است. اینجا مثال معمولی آمده:

192.168.1.1 - - [22/May/2025:10:55:22 +0000] "GET /index.html HTTP/1.1" 200 2326 "http://referrer.com" "Mozilla/5.0"

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

۷. چطور لاگینگ debug را در NGINX فعال کنم؟

برای فعال‌سازی لاگینگ debug، دایرکتیو error_log را روی فایل لاگی تنظیم و سطح debug را بهش اختصاص بدهید. مثال:

error_log /var/log/nginx/error.log debug;

هم‌چنین باید NGINX را با فلگ --with-debug کامپایل کرده یا دیباگ را در ماژول‌های خاصی با debug_connection فعال کنید. محتاط باشید؛ چون لاگینگ debug می‌تواند خیلی پرحرف باشد و فضای دیسک قابل توجهی مصرف کند. بهتر است موقتاً حین عیب‌یابی استفاده شود.

۸. آیا می‌توانم لاگ‌های NGINX را به سرور ریموت بفرستم؟

بله، NGINX می‌تواند لاگ‌های Error را با استفاده از پروتکل syslog: به سرور syslog ریموت بفرستد. مثال:

error_log syslog:server=192.168.1.100:514,facility=local7,tag=nginx warn;

اما لاگ‌های Access به‌صورت نیتیو syslog را پشتیبانی نمی‌کنند. برای لاگ‌های Access، از ایجنت‌های ارسال لاگی مثل Filebeat، Fluentd یا Vector برای Forward کردن ورودی‌ها به سیستم‌های متمرکزی مانند ELK، Graylog یا BetterStack استفاده کنید. این تجمیع لاگ مقیاس‌پذیر بین چندین نود را ممکن می‌سازد.

۹. چطور لاگ‌های NGINX را بچرخانم؟

لاگ‌های NGINX خودکار چرخانده نمی‌شوند. از ابزاری مثل logrotate روی لینوکس برای مدیریت‌شان استفاده کنید. فایل کانفیگی زیر /etc/logrotate.d/nginx با دایرکتیوهایی مثل این اضافه کنید:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1`cat /var/run/nginx.pid
    endscript
}

این راه‌اندازی لاگ‌ها را روزانه چرخانده، فشرده کرده و به NGINX سیگنال Graceful می‌فرستد تا نوشتن در فایل جدید را شروع کند.

۱۰. چطور می‌توانم مسائل امنیتی را با لاگ‌های NGINX شناسایی کنم؟

لاگ‌های NGINX می‌توانند نشانه‌های حملات Brute-Force، Path Traversal و تلاش‌های Probing را آشکار کنند. مثلاً:

تلاش‌های ورود ناموفق متعدد از همان IP
متدهای HTTP غیرمعمولی مثل PUT یا DELETE
درخواست‌ها به /wp-admin یا /phpmyadmin روی سایت‌های غیر-CMS
حجم بالای خطاهای 404 یا 5xx

با بهره‌گیری از ابزارهای تحلیل لاگی مثل GoAccess یا AWStats—یا با یکپارچه‌سازی لاگ‌های NGINX خودتان با پلتفرم‌های امنیتی—می‌توانید الگوهای مشکوک را خودکار تشخیص و به تهدیدات بالقوه پاسخ بدهید. مرور منظم لاگ‌ها برای حفظ امنیت سرور ضروری است. علاوه بر این، امن کردن Instance مربوط به NGINX خودتان با SSL/TLS، قدم کلیدی در محافظت در برابر حملات رایج است. برای راهنمای گام-به-گام راه‌اندازی SSL با Let’s Encrypt، راهنمای «نحوه امن کردن Nginx با Let’s Encrypt روی اوبونتو» در پارمین کلود را ببینید.

نتیجه‌گیری

لاگ‌های Access و Error مربوط به NGINX برای مانیتورینگ فعالیت کاربران و ساده‌سازی فرایند دیباگ ضروری‌اند. هم‌چنین می‌توانید فرمت لاگ Access را برای ثبت جزئیات اضافیِ موردنیاز سفارشی کنید. فعال‌سازی هر دو لاگ Access و Error به‌شدت توصیه می‌شود؛ چون بینش‌های ارزشمندی برای نگهداری و عیب‌یابی سرور NGINX شما فراهم می‌کنند.

با پیکربندی فرمت‌های لاگ سفارشی، تنظیم سطوح شدت مناسب لاگ Error و یکپارچه‌سازی با ابزارهای مانیتورینگ، می‌توانید دید عمیق‌تری به کارایی و امنیت سرورتان به دست آورید. تحلیل منظم لاگ به شناسایی گلوگاه‌ها، تشخیص تهدیدات امنیتی و بهینه‌سازی پیکربندی NGINX شما کمک می‌کند.