لاگ سرور، جعبه سیاه سایت شماست: هر اتفاقی که ظاهرش را در مرورگر می‌بینید (کندی، خطای ۵۰۲، فرم ناموفق، حملهٔ بات) قبلش با جزئیات کامل در لاگ نوشته شده. دو خانوادهٔ اصلی دارد: access log که می‌گوید چه کسی، کی، چه چیزی خواست و چه جوابی گرفت؛ و error log که می‌گوید وقتی کار خراب شد، دقیقاً چرا. سوادِ خواندن همین دو فایل، نیمی از عیبیابی سرور است و برخلاف تصور، به چیزی بیش از چند فرمان ساده و شناخت الگوها نیاز ندارد؛ همین مقاله قرار است همان چند فرمان و همان الگوها باشد.
آناتومی access log؛ یک خط را کامل بخوانیم
یک خط نمونه از access log وب‌سرور (قالب مرسوم که مستند nginx و مستند Apache تعریفش کردهاند):
203.0.113.7 - - [14/Oct/2026:21:14:20 +0330] "GET /checkout HTTP/2" 502 1842 "-" "Mozilla/5.0 ..."از چپ به راست: آدرس IP بازدیدکننده، زمان دقیق با منطقهٔ زمانی، درخواست (متد و مسیر)، کد وضعیت پاسخ، حجم پاسخ به بایت، و در انتها User-Agent یعنی مرورگر یا باتی که درخواست را فرستاده. همین شش قطعه، سه سوال اصلی عیبیابی را جواب می‌دهد: چه کسی آمد، دنبال چه بود، و چه تحویل گرفت. کدهای وضعیت را هم در ده ثانیه میشود مرور کرد: خانوادهٔ ۲ یعنی موفق، ۳ یعنی ریدایرکت، ۴ یعنی مشکل از درخواست (۴۰۴ ناموجود، ۴۰۳ مسدود) و ۵ یعنی خودِ سرور خراب کرده؛ خانوادهٔ آخر همان است که مشتری‌هایتان را می‌پراند.
دو قطعهٔ کمتردیده‌شدهٔ همین خط هم ارزش خواندن دارند. حجم پاسخ، وقتی برای یک مسیر ثابت ناگهان چند برابر میشود، یعنی چیزی در آن صفحه عوض شده (تصویری بی‌بهینه، خروجی اضافه) و پهنای باند دارد همان‌جا می‌سوزد. و فیلد Referer (که در قالب کامل، قبل از UA می‌آید) می‌گوید بازدیدکننده از کدام صفحه رسیده: هم منبعِ لینک‌های ورودی واقعی را نشان می‌دهد، هم هات‌لینک را لو می‌دهد؛ یعنی سایت‌هایی که تصویرهای شما را مستقیم در صفحهٔ خودشان نمایش میدهند و پهنای باند شما را خرج ویترین خودشان میکنند.
error log؛ وقتی ۵xx دیدید، قصهٔ کامل این‌جاست
access log فقط می‌گوید «خطای ۵۰۲ دادیم»؛ دلیلش را error log می‌گوید، با جمله‌هایی مثل upstream timed out (اپلیکیشن دیر جواب داد)، connect() failed (سرویس PHP پایین است) یا پیام‌های خطای خود PHP با نام فایل و شمارهٔ خط. روال درست عیبیابی همیشه همین ترتیب است: در access log ببینید چه زمانی و روی کدام مسیرها خطا شروع شده، بعد همان بازهٔ زمانی را در error log پیدا کنید تا دلیل را بخوانید. برای درمانِ خطاهای رایج، راهنمای جداگانه داریم: رفع خطای ۵۰۲، خطای ۵۰۰ وردپرس و خطای ۵۰۳؛ نقش لاگ این است که بگوید سراغ کدام راهنما بروید.
وردپرس لاگ مخصوص خودش را هم دارد: با فعال کردن WP_DEBUG_LOG در wp-config، خطاهای PHP قالب و افزونه‌ها در فایل debug.log داخل پوشهٔ wp-content جمع میشود؛ برای شکار افزونهٔ خراب، این فایل از error log سرور هم مستقیم‌تر است. فقط یادتان باشد این حالت را روی سایت تست روشن کنید، نه روی سایت زنده، و بعد از کار خاموشش کنید.
لاگ‌ها کجا هستند؟
روی سرور مجازی یا اختصاصی با دسترسی روت، خانهٔ اصلی لاگ‌ها مسیر var/log است: وب‌سرور در زیرپوشهٔ nginx یا apache2، و باقی سرویس‌ها هرکدام فایل خودشان را دارند. در هاست اشتراکی، همین داده‌ها از پنل در دسترس است: cPanel بخش Metrics (شامل Errors و Raw Access) و DirectAdmin بخش لاگ‌های سایت را دارد؛ یعنی برای خواندن لاگ، لازم نیست حتماً سرور شخصی داشته باشید. اگر هم چند سایت روی یک سرور دارید، هر vhost معمولاً جفت لاگ جداگانهٔ خودش را دارد و اولین قدم نظم، همین جداسازی است.
جدول عیبیابی؛ از علامت تا سطرِ درست لاگ
| علامت | کجا را ببینید | دنبال چه بگردید |
|---|---|---|
| سایت کند شده | access log | زمان پاسخ‌های بالا و مسیرهای پرتکرار؛ بعد گلوگاه را با پایش منابع تأیید کنید |
| خطای ۵۰۲/۵۰۴ گاه‌به‌گاه | error log همان دقیقه | upstream timed out یا connect failed؛ درمان در راهنمای ۵۰۲ |
| صفحهٔ سفید بعد از آپدیت | debug.log وردپرس | Fatal error با نام افزونه یا قالب در مسیر فایل |
| سرور مدام ری‌استارت میشود | لاگ سیستم و error log | پیام کمبود حافظه؛ مکمل دلایل crash سرور |
| ترافیک مشکوک | access log | IPهای پرتکرار روی wp-login و xmlrpc؛ الگوهای بخش بعد |
| دیسک ناگهان پر شد | حجم خود فایل‌های لاگ | لاگِ چرخش‌نشده؛ بخش بهداشت لاگ را ببینید |
سه فرمان، پنج الگوی پرتکرار
برای ۹۰ درصد کارها همین سه فرمان کافی است: tail برای دیدن زنده، grep برای فیلتر، و ترکیب awk و sort و uniq برای شمارش. چند نمونهٔ آماده:
tail -f access.log # تماشای زنده
grep " 502 " access.log | tail -20 # آخرین ۵۰۲ها
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head # پرتکرارترین IPهاو الگوهایی که بعد از مدتی لاگ‌خوانی، با یک نگاه می‌شناسید:
- موج ۴۰۴ روی مسیرهای عجیب: درخواست‌های پشتسرهم به فایل‌هایی که ندارید (env، پوشه‌های بکاپ، مسیرهای phpmyadmin)؛ بات‌های اسکنر دنبال درِ باز می‌گردند. خطرناک تا وقتی نیست که همان فایل‌ها واقعاً روی سرور نباشند؛ همین الگو را یادآورِ این بگیرید که بکاپ را هرگز داخل وب‌روت نگذارید.
- POSTهای مکرر به wp-login و xmlrpc: تلاش برای حدس رمز. درمان: محدودسازی تلاش ورود و مسدودسازی خودکار؛ نرخ بالا یعنی وقت فایروال و قاعدهٔ جدی‌تر است.
- یک IP، هزاران درخواست در دقیقه: یا خزندهٔ تهاجمی یا حملهٔ ساده؛ با UA و الگوی مسیرها تشخیص بدهید و در سطح وب‌سرور مسدود یا محدود کنید.
- spike ناگهانی روی یک URL مشخص: اگر کمپین فرستاده‌اید، خبر خوب است و باید طبق راهنمای ترافیک ناگهانی آماده باشید؛ اگر نفرستاده‌اید، بررسی کنید چه کسی و چرا.
- سکوت غیرعادی: فاصلهٔ زمانی خالی در لاگی که همیشه شلوغ است، یعنی سرویس در آن بازه پایین بوده؛ دقیقهٔ شروع سکوت را در error log و لاگ سیستم دنبال کنید تا دلیل سقوط پیدا شود.
تمرین اولین جلسهٔ لاگ‌خوانی؛ ده دقیقه، سه کشف
اگر تا حالا لاگ سرورتان را باز نکرده‌اید، همین امروز این سه تمرین را انجام بدهید؛ هرکدام یک مهارت پایه می‌سازد و تقریباً همیشه یک کشف واقعی هم دارد:
- کشف اول، باتها: پرتکرارترین IPهای دیروز را با همان فرمان شمارش بالا دربیاورید و UAهایشان را ببینید. تقریباً همیشه غافلگیر می‌شوید که سهم بزرگی از «بازدید» سرور شما، ماشین‌ها هستند: از خزندهٔ موتورهای جستجو تا اسکنرهای بی‌نام.
- کشف دوم، ۴۰۴ها: درخواست‌های ۴۰۴ دیروز را فیلتر کنید. چیزی که پیدا می‌کنید دو دسته است: مسیرهای اسکن بات (بی‌اهمیت) و لینک‌های شکستهٔ واقعی سایت خودتان (مهم؛ هر کدام یک بازدیدکنندهٔ گم‌شده است که باید با اصلاح لینک یا ریدایرکت نجاتش بدهید).
- کشف سوم، ساعت اوج: با شمارش درخواست‌ها به تفکیک ساعت، پیک واقعی سایتتان را پیدا کنید. این عدد، زمانبندی به‌روزرسانی و بکاپ (ساعت خلوت) و آمادگی منابع (ساعت شلوغ) را از حدس به داده تبدیل میکند.
همین سه تمرین، لاگ را از یک فایل ترسناک به ابزار روزمره تبدیل میکند؛ از این‌جا به بعد، الگوهای بخش قبل را هم کم‌کم با چشم می‌بینید.
قصهٔ تکراری تیکت‌ها؛ دیسکِ پر از لاگ
الگویی که در پشتیبانی زیاد می‌بینیم: سایت ناگهان پایین است، دیتابیس بالا نمی‌آید و بررسی نشان می‌دهد دیسک پر شده؛ نه از بکاپ و نه از آپلود، از یک error log چند گیگابایتی. ریشه، یک خطای تکراری بوده (افزونه‌ای که هر چند ثانیه یک هشدار می‌نوشته) و ماه‌ها کسی لاگ را نخوانده تا صدای این چکهٔ دائمی را بشنود. درمان فوری، آزاد کردن فضا و ری‌استارت سرویس‌هاست؛ درمان واقعی دوتاست: رفع خطای ریشه (که متن همان لاگ دقیقاً می‌گوید کجاست) و چرخش درست لاگ‌ها که بخش بعد توضیح می‌دهد. و درس بزرگ‌تر: هشدار «دیسک رو به پر شدن» باید قبل از این روز، از سامانهٔ پایش رسیده باشد؛ لاگ‌خوانی و مانیتورینگ، مکمل هم‌اند، نه جایگزین.
بهداشت لاگ؛ سه قاعدهٔ کوتاه
اول، چرخش: ابزار logrotate (که در اکثر توزیع‌ها از قبل فعال است) فایل‌ها را روزانه یا هفتگی می‌بندد و فشرده میکند؛ فقط مطمئن شوید برای لاگ‌های سفارشی خودتان هم قاعده دارد، چون لاگِ چرخش‌نشده همان چیزی است که یک شب دیسک را پر میکند و سایت را می‌خواباند. دوم، نگهداری: برای عیبیابی، چند هفته کافی است و برای تحلیل امنیتی، چند ماه؛ آرشیو قدیمی‌تر را فشرده به فضای بکاپ منتقل کنید، با همان نظمی که در استراتژی بکاپ چیدیم. سوم، حریم خصوصی: آدرس IP، دادهٔ شخصی است؛ دسترسی به لاگ را مثل دسترسی به دادهٔ مشتری محدود کنید و در گزارش‌های عمومی، آن را ناشناس کنید.
سوالات متداول دربارهٔ لاگ سرور
فرق لاگ سرور با آمار گوگل آنالیتیکس چیست؟
دو زاویهٔ متفاوت از یک واقعیت: آنالیتیکس سمت مرورگر اجرا میشود و فقط بازدیدکنندههایی را میبیند که اسکریپتش را اجرا کردهاند؛ یعنی باتها، خطاهای قبل از بارگذاری صفحه و کاربرانِ مسدودکنندهٔ ردیاب از چشمش پنهاناند. لاگ سرور همهچیز را میبیند، چون در خودِ در ورودی نشسته. برای تحلیل رفتار بازاریابی، آنالیتیکس؛ برای عیبیابی فنی و امنیت و خزش، لاگ. هر دو را داشته باشید و عددهایشان را با هم مقایسه نکنید؛ تعریف «بازدید»شان متفاوت است.
در هاست اشتراکی هم به لاگ دسترسی داریم؟
بله؛ پنلهای رایج، هم خطاهای اخیر را نشان میدهند هم فایل خام access log را برای دانلود میدهند. عمق نگهداری در هاست اشتراکی معمولاً کوتاهتر است، پس اگر مشکلی تکرارشونده دارید، لاگ را همان روزِ بروز مشکل بردارید و نگه دارید؛ منتظر جمعشدن شواهد نمانید.
لاگ را چند وقت نگه داریم؟
برای عیبیابی فنی، دو تا چهار هفتهٔ فعال کافی است؛ برای پیگیری حادثهٔ امنیتی، آرشیو فشردهٔ چندماهه طلاست. تصمیم را یکبار بگیرید و به logrotate بسپارید؛ سیاستِ نانوشته عملاً یعنی «تا وقتی دیسک پر شود».
ابزار گرافیکی بهتر است یا همین فرمانها؟
برای شروع، فرمانها؛ چون همهجا هستند و چیزی برای نصب و نگهداری ندارند. ابزارهای تجمیع و داشبورد وقتی میارزند که چند سرور دارید یا تیمی هستید که باید لاگ مشترک ببیند؛ در آن مقیاس، جستجوی مرکزی و هشدار خودکار، ارزش هزینهٔ راهاندازی را دارد.
لاگ ارسال ایمیل کجاست؟
سرویس ایمیل، لاگ جداگانهٔ خودش را دارد (در سرورهای لینوکسی معمولاً فایل لاگ میل در همان var/log و در سرویس‌های میزبانی‌شده، از پنل مدیریت). برای تشخیص این‌که ایمیل سایت چرا نمی‌رسد، همان بحث تحویل‌پذیری است که در مقایسهٔ میل‌سرور و سرویس ایمیل باز کردیم؛ لاگ میل نشان می‌دهد پیام از سمت شما رفته یا همان‌جا گیر کرده.
لاگ به درد سئو هم می‌خورد؟
بسیار؛ access log تنها جایی است که رفتار واقعی خزندهٔ گوگل را می‌بینید: کدام صفحه‌ها را چقدر می‌خزد، به کدام خطا می‌خورد و وقتش را کجا هدر می‌دهد. اگر سهم بزرگی از خزش، صرف صفحات بی‌ارزش (فیلترها، آرشیوهای تکراری) میشود، بودجهٔ خزش صفحات پولساز شما دارد آن‌جا می‌سوزد؛ همین تحلیل ساده، ورودی مستقیم تصمیم‌های فنی سئوست.
از کجا بفهمم یک بات، گوگل واقعی است یا جعلی؟
User-Agent بهتنهایی قابل جعل است؛ راه درست، استعلام معکوس IP است که باید به دامنهٔ رسمی خزنده برسد. قاعدهٔ عملی سادهتر: بات واقعی گوگل robots.txt را رعایت میکند و نرخ منطقی دارد؛ باتی که با UA گوگل، پشتسرهم به wp-login میزند، جعلی است؛ بدون تردیدِ بیشتر مسدودش کنید.
میشود لاگ را خودکار پایش کرد، بدون ابزار سنگین؟
بله، با همان ابزارهای موجود: یک اسکریپت چندخطی که با زمانبندی cron اجرا شود، تعداد ۵xxهای ساعت گذشته را بشمارد و اگر از آستانهٔ شما بیشتر بود، ایمیل یا پیام هشدار بفرستد. برای ورودها هم ابزارهایی مثل fail2ban دقیقاً همینطور کار میکنند: لاگ را میخوانند و الگوی تکرار را خودکار مسدود میکنند. وقتی تعداد سرورها یا حجم کار از این سطح گذشت، آنوقت سراغ سامانهٔ تجمیع لاگ بروید.
برای سرور پرترافیک، لاگ کامل سنگین نمیشود؟
میشود، و راه درستش چرخش فشرده و نگهداری کوتاهتر است، نه حذف لاگ؛ در صورت نیاز، نمونهبرداری فقط برای مسیرهای ایستا. لاگِ مسیرهای حیاتی (پرداخت، ورود، فرمها) را هرگز قطع نکنید؛ همانجایی است که روز حادثه بیشترین سوال را دارید و در فروشگاههای پرسفارش (ووکامرس در مقیاس بالا) این تفکیک از روز اول باید در طراحی دیده شود.
