یکی از اولین مراحل عیب‌یابی سایت روی Windows Server، بررسی IIS Logs است. این Logها اطلاعات هر Request مانند URL، HTTP Method، IP، Status Code، Substatus، Win32 Status و مدت زمان پاسخ را ثبت می‌کنند.

با بررسی IIS Log معمولاً می‌توان مشخص کرد که درخواست به IIS رسیده است یا خیر و خطاهایی مانند 403، 404، 500 و 503 دقیقاً با چه Substatusی برگشته‌اند.

Microsoft نیز بررسی IIS Logs و کدهای sc-status، sc-substatus و sc-win32-status را یکی از مراحل اصلی Troubleshooting خطاهای IIS معرفی می‌کند.

مسیر IIS Logs

مسیر پیش‌فرض Logهای IIS در نسخه‌های جدید IIS:

C:\inetpub\logs\LogFiles

است.

داخل این Directory معمولاً Folderهایی مانند موارد زیر مشاهده می‌شوند:

W3SVC1
W3SVC2
W3SVC5

هر Folder مربوط به یک Website در IIS است.

برای مثال:

C:\inetpub\logs\LogFiles\W3SVC5

مربوط به سایتی است که IIS Site ID آن برابر 5 است.

پیدا کردن Site ID

برای تشخیص اینکه کدام W3SVC مربوط به سایت موردنظر است:

1. IIS Manager را باز کنید.
2. وارد بخش:

Sites

شوید.
3. ستون:

ID

را بررسی کنید.

اگر ID سایت:

5

باشد، Logهای پیش‌فرض آن معمولاً در:

C:\inetpub\logs\LogFiles\W3SVC5

قرار دارند. Microsoft نیز از همین Site ID برای تشخیص Directory مربوط به هر Website استفاده می‌کند.

نام فایل‌های IIS Log

در حالت معمول فایل‌هایی مانند زیر مشاهده می‌شوند:

u_ex260827.log
u_ex260826.log
u_ex260825.log

هر فایل معمولاً مربوط به یک روز است.

برای عیب‌یابی بهتر است Log مربوط به زمانی که Error رخ داده است باز شود.

در W3C Logging، ساعت داخل Log به‌صورت UTC ثبت می‌شود. بنابراین هنگام مقایسه زمان Error با ساعت Local Server این اختلاف زمانی را در نظر بگیرید.

ساختار IIS Log

یک Entry ممکن است شبیه این باشد:

2026-08-27 06:42:15 192.0.2.10 GET /index.php - 443 - 203.0.113.20 Mozilla/5.0 200 0 0 125

در ابتدای فایل نیز خطی شبیه زیر وجود دارد:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken

خط #Fields مشخص می‌کند هر ستون چه اطلاعاتی دارد.

مهم‌ترین Fieldها برای Troubleshooting

سه ستون مهم در بیشتر خطاهای IIS عبارت‌اند از:

sc-status
sc-substatus
sc-win32-status

Status و Substatus را با هم بررسی کنید

مشاهده فقط:

404

برای پیدا کردن علت مشکل کافی نیست.

برای مثال:

404 0

با:

404 3

می‌تواند علت متفاوتی داشته باشد.

همین موضوع برای خطای 403 نیز مهم است.

برای مثال:

403 14

به شکل:

403.14

خوانده می‌شود و معمولاً به Directory Listing مربوط است.

بنابراین هنگام بررسی Log:

sc-status = 403
sc-substatus = 14

را باید به شکل:

403.14

در نظر گرفت.

Microsoft نیز برای عیب‌یابی خطاهای 4xx و 5xx توصیه می‌کند Status و Substatus با هم بررسی شوند.

مثال بررسی خطای 404

فرض کنید Entry زیر را داریم:

2026-08-27 07:10:12 192.0.2.10 GET /images/logo.png - 443 - 203.0.113.20 404 0 2 15

قسمت مهم:

404 0 2

است:

sc-status        = 404
sc-substatus     = 0
sc-win32-status  = 2

Win32 Error شماره 2 معمولاً به:

The system cannot find the file specified

اشاره دارد.

در این حالت بررسی File Path، Document Root و وجود فایل می‌تواند قدم بعدی باشد.

جزئیات این Error را در مقاله:

عیب‌یابی خطای 404 Not Found در IIS

بررسی خواهیم کرد.

مثال بررسی خطای 403

اگر Log شامل:

403 14 0

باشد، Error به شکل:

403.14

است.

Substatus باعث می‌شود به‌جای بررسی تمام علت‌های احتمالی 403، مستقیم‌تر روی علت مربوط به همان Error تمرکز کنیم.

برای Troubleshooting کامل:

عیب‌یابی خطای 403 Forbidden در IIS

را مطالعه کنید.

مثال بررسی خطای 503

ممکن است در Log با Entry شبیه زیر روبه‌رو شوید:

503 0 0

در خطای 503 فقط IIS Log کافی نیست.

باید موارد دیگری مانند:

Application Pool
Event Viewer
HTTPERR Logs
Hosting / Subscription Status

نیز بررسی شوند.

Microsoft نیز برای خطاهای 503 بررسی sc-substatus در IIS Log و s-reason در HTTPERR Log را پیشنهاد می‌کند.

برای بررسی کامل:

عیب‌یابی خطای 503 Service Unavailable در IIS

بررسی Requestهای کند

IIS Logs فقط برای Errorها نیستند.

Field:

time-taken

مدت زمان پردازش Request را بر حسب Millisecond نشان می‌دهد.

برای مثال:

200 0 0 75

یعنی Request موفق بوده و حدود:

75 ms

زمان برده است.

اما:

200 0 0 18500

یعنی همان Request حدود:

18.5 seconds

زمان برده است.

این اطلاعات برای پیدا کردن URLهای کند و مشکلات Performance کاربرد دارد.

پیدا کردن درخواست موردنظر در فایل بزرگ

IIS Log ممکن است صدها هزار Entry داشته باشد.

برای بررسی سریع می‌توان از PowerShell استفاده کرد.

برای پیدا کردن خطاهای 503:

Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC5\*.log" -Pattern " 503 "

برای جستجوی URL مشخص:

Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC5\*.log" -Pattern "/login"

در Logهای بسیار بزرگ، Microsoft استفاده از ابزارهایی مانند LogParser را نیز برای تحلیل سریع‌تر پیشنهاد می‌کند.

همچنین استفاده از find and replace در notepad++ در صورت وجود بر روی سرور نیز می‌تواند برای برخی sysadminها کاربردی باشد.

مشاهده و تغییر Logging از IIS Manager

برای مشاهده تنظیمات Logging:

1. IIS Manager را باز کنید.
2. Website موردنظر را انتخاب کنید.
3. وارد:

Logging

شوید.

در این بخش می‌توانید مواردی مانند:

Format
Directory
Log File Rollover
Fields

را مشاهده کنید.

Format رایج و پیش‌فرض IIS:

W3C

است. همچنین از گزینه Select Fields می‌توان Fieldهای موردنیاز برای Logging را انتخاب کرد.

قبل از تغییر Format یا Fieldهای Logging روی Server Production، دلیل تغییر و تأثیر آن روی حجم Log را در نظر بگیرید.

اگر هیچ Entry مربوط به Error در IIS Log وجود نداشت

وجود نداشتن Request در IIS Log خودش یک سرنخ مهم است.

ممکن است Request اصلاً به Website موردنظر نرسیده باشد.

مواردی مانند:

• DNS
• Binding
• IP / Port
• Firewall
• Load Balancer
• Reverse Proxy
• HTTP.sys
• اشتباه بودن Website مقصد

را بررسی کنید.

برای بعضی خطاها Request توسط HTTP.sys قبل از رسیدن به IIS Worker Process Reject می‌شود.

در این شرایط باید HTTPERR Logs را نیز بررسی کرد.

بررسی HTTPERR Logs

مسیر پیش‌فرض:

C:\Windows\System32\LogFiles\HTTPERR

است.

این Logها مخصوص Errorهایی هستند که توسط Windows HTTP Server API یا HTTP.sys ثبت می‌شوند.

اگر Browser خطای 4xx یا 503 نشان می‌دهد ولی Entry مرتبطی داخل W3SVC Log پیدا نمی‌کنید، HTTPERR یکی از محل‌های مهم بعدی برای بررسی است.

در HTTPERR فیلدی مانند:

s-reason

می‌تواند علت Reject شدن Request را مشخص کند.

Event Viewer را فراموش نکنید

IIS Log نشان می‌دهد Request چه نتیجه‌ای گرفته است، اما همیشه علت داخلی Application یا Application Pool را مشخص نمی‌کند.

برای Errorهای Application Pool، .NET، WAS و Worker Process بهتر است:

Event Viewer

را نیز بررسی کنید.

به‌خصوص:

Windows Logs
> Application

و:

Windows Logs
> System

می‌توانند اطلاعات تکمیلی ارائه دهند.

برای خطای 503، Crash شدن Application و Failureهای Application Pool این مرحله اهمیت بیشتری دارد.

چه زمانی از Failed Request Tracing استفاده کنیم؟

اگر IIS Log نشان دهد Request با Error برمی‌گردد اما علت دقیق مشخص نیست، می‌توان از:

Failed Request Tracing

یا:

FREB

استفاده کرد.

FREB جزئیات بیشتری از مراحل پردازش Request و Module یا Handler ایجادکننده Error ارائه می‌دهد.

Microsoft نیز برای خطاهایی که IIS Log اطلاعات کافی ارائه نمی‌دهد، استفاده از Failed Request Tracing را پیشنهاد می‌کند.

این موضوع برای عیب‌یابی پیشرفته‌تر مناسب است و لازم نیست برای هر Error از ابتدا FREB فعال شود.

بررسی Hosting و Subscription

اگر IIS بخشی از یک Hosting Environment باشد، علت Error الزاماً داخل Website یا IIS Configuration نیست.

برای مثال روی Serverهایی که توسط Hosting Panel مدیریت می‌شوند موارد زیر را نیز بررسی کنید:

• Subscription فعال باشد.
• Hosting برای Domain غیرفعال نشده باشد.
• Website به Site یا Subscription صحیح متصل باشد.
• Application Pool توسط Panel یا Automation متوقف نشده باشد.
• Disk Quota یا Resource Limit سرویس به سقف نرسیده باشد.
• Account یا Subscription غیرفعال نشده باشد.
• Log Directory توسط Hosting Panel به مسیر دیگری تغییر داده نشده باشد.

برای مثال در خطای 503 ممکن است Application Pool متوقف باشد، اما علت اصلی توقف آن Resource Limit یا Suspended Subscription باشد.

در چنین شرایطی Restart کردن Application Pool بدون بررسی علت اصلی ممکن است فقط به‌صورت موقت Error را برطرف کند.

نکته درباره Hosting Panelها

در محیط‌هایی مانند Plesk ممکن است:

• مسیر Log برای هر Subscription متفاوت باشد.
• Logها از داخل Hosting Panel نیز قابل مشاهده باشند.
• Website و Application Pool توسط Panel مدیریت شوند.
• بعضی تنظیمات IIS توسط Subscription یا Hosting Plan محدود شده باشند.

بنابراین قبل از تغییر مستقیم Configuration سرور مشخص کنید Website به‌صورت Manual در IIS ساخته شده است یا توسط Hosting Panel مدیریت می‌شود.

Workflow پیشنهادی برای بررسی IIS Logs

برای بیشتر مشکلات Website این ترتیب مناسب است:

1. Reproduce the error
        ↓
2. Record exact time and URL
        ↓
3. Find IIS Site ID
        ↓
4. Open W3SVC log
        ↓
5. Find the request
        ↓
6. Check:
   sc-status
   sc-substatus
   sc-win32-status
   time-taken
        ↓
7. Check Application Pool / Event Viewer
        ↓
8. If required, check HTTPERR / FREB
        ↓
9. Check hosting/subscription/resource layer

این روش کمک می‌کند قبل از تغییر Configuration، محل واقعی Failure مشخص شود.

اشتباهات رایج

بررسی فقط Status Code

دیدن:

403

یا:

404

به‌تنهایی کافی نیست.

همیشه:

sc-substatus

و در صورت وجود:

sc-win32-status

را نیز بررسی کنید.

بررسی Log سایت اشتباه

در Serverهایی که تعداد زیادی Website دارند، ابتدا Site ID را مشخص کنید و سپس وارد W3SVC<ID> صحیح شوید.

نادیده گرفتن UTC

Timestamp در W3C Log معمولاً UTC است.

اگر Error ساعت 14:00 Local رخ داده، ممکن است Entry آن با ساعت متفاوتی در Log ثبت شده باشد.

نتیجه‌گیری اینکه مشکل حتماً از IIS است

ممکن است Error ناشی از:

Application
Database
Filesystem
Hosting Panel
Subscription
Resource Limits
Reverse Proxy
HTTP.sys

باشد.

IIS Log نقطه شروع Troubleshooting است، نه همیشه پاسخ نهایی.

مطالعه بیشتر

پس از یادگیری بررسی IIS Logs، مقالات زیر مستقیماً مرتبط هستند:

• عیب‌یابی خطای 503 Service Unavailable در IIS
• عیب‌یابی خطای 403 Forbidden در IIS
• عیب‌یابی خطای 404 Not Found در IIS
• آموزش نصب و فعال‌سازی URL Rewrite در IIS
• آموزش راه‌اندازی Reverse Proxy در IIS با ARR

مستندات رسمی Microsoft:

• HTTP Status Code Overview — Microsoft Learn
• W3C Logging — Microsoft Learn
• IIS Logging Configuration — Microsoft Learn
• Troubleshoot 4xx and 5xx HTTP Errors — Microsoft Learn

جمع‌بندی

مسیر پیش‌فرض IIS Logs:

C:\inetpub\logs\LogFiles

است و هر Website معمولاً Directory جداگانه‌ای بر اساس Site ID دارد:

W3SVC<ID>

برای عیب‌یابی بیشتر Errorها سه Field زیر اهمیت ویژه‌ای دارند:

sc-status
sc-substatus
sc-win32-status

و برای Performance نیز:

time-taken

مفید است.

اگر Request داخل IIS Log وجود ندارد یا اطلاعات آن برای تشخیص علت کافی نیست، بررسی HTTPERR، Event Viewer و در مرحله بعد Failed Request Tracing می‌تواند اطلاعات بیشتری ارائه دهد.

در Hosting Environment نیز قبل از تغییر IIS Configuration، وضعیت Website، Subscription، Application Pool و Resource Limitهای سرویس را بررسی کنید؛ زیرا Error ممکن است از لایه Hosting ایجاد شده باشد نه از خود Website. همچنین log file در یک محیط hosting احتمالا در محیط متفاوتی که مربوط به خود وبسایت است قرار گرفته است.