عیبیابی پیشرفته خطای Server Not Found: متدولوژی لایهای از دیتاسنتر تا وبسرور
در مدیریت زیرساختهای مدرن، عیبیابی خطای server not found در زیرساخت سرور نیازمند نگاهی دقیق به لایههای مختلف شبکه و استوریج است. این خطا معمولاً ناشی از اختلال در مسیریابی شبکه، قطع اتصال استوریج یا عدم پاسخدهی وبسرور است، اما ریشه آن اغلب در تعامل نادرست بین پروتکلهای لایه ۲/۳، کنترلرهای هاردواری و سیاستهای دقیق فایروالهای سازمانی نهفته است. برای رفع آن، ابتدا اتصال فیزیکی و پورتهای Switch را با بررسی LEDهای وضعیت و لاگهای BMC دیباگ کنید، سپس سرویسهای VMware یا iLO را از طریق کنسول مدیریتی کنترل نمایید و در نهایت قوانین Firewall و وضعیت RAID را با استفاده از ابزارهای مانیتورینگ I/O تحلیل کنید تا ریشه مشکل از لایه زیرساخت تا اپلیکیشن با دقت شناسایی و خنثی شود. این رویکرد لایهای نه تنها زمان بازیابی را کاهش میدهد، بلکه از ایجاد خطاهای زنجیرهای در محیطهای کلیدی جلوگیری میکند.
فهرست مطالب
- خطای Server Not Found در معماری دادهسنتر
- بررسی پورتهای Switch و پیکربندی VLANها
- تاثیر قطع SAN/NAS و ارور RAID
- دیباگ لاگهای VMware و رابط iLO
- استراتژی فیلتر کردن ترافیک توسط Firewall
- مقایسه روشهای تشخیص در محیطهای مختلف
- چکلیست گامبهگام بازیابی سرویس
- سوالات متداول متخصصان
اصول و متدولوژی عیبیابی خطای server not found در زیرساخت سرور
خطای Server Not Found یک وضعیت HTTP/ICMP است که در آن درخواست از لایه اپلیکشن به دلیل عدم رسیدن به endpoint هدف یا ریجکت شدن در لایه زیرساخت، پاسخ ۴۰۴ یا Timeout دریافت میکند. اما چرا این خطا هرگز ذاتاً نرمافزاری نیست؟ زیرا لایه اپلیکیشن تنها زمانی پاسخ میدهد که دستورات TCP به درستی دستبهدست شوند (Handshake سه مرحلهای کامل شود). اگر مسیر فیزیکی یا منطقی قطع باشد، پکتها هرگز به stack شبکه سرور نمیرسند و کلاینت هیچ پاسخ HTTPای دریافت نمیکند. این خطا نشانهای از شکست در یک حلقه زیرساختی شامل مسیریابی لایه ۲/۳، پیکربندی Virtualization، وضعیت Storage Controller یا محدودیتهای امنیتی است.
بر درک عمیقتر، تصور کنید یک درخواست REST API به سرور ارسال میشود. DNS رکورد را رزولوشن میکند، لایه ۳ آدرس IP مقصد را در جدول مسیریابی جستجو میکند، لایه ۲ MAC آدرس را با ARP پیدا میکند و ترافیک به نیک کارت سرور میرسد. اگر هر یک از این حلقهها دچار تأخیر، ریجکت یا مسیریابی نادرست شود، خطای Server Not Found ظاهر میشود. تشخیص صحیح نیازمند تفکیک Intent بین قطع فیزیکی، از کار افتادن Hypervisor، Degraded State در استوریج یا Policy Block در دیوار آتش است. مهندسان زیرساخت باید بداند که این ارور تنها یک علامت ظاهری است و ریشه آن در عمق معماری دادهسنتر نهفته است. به عنوان مثال، در یک محیط ابری، این خطا میتواند ناشی از عدم sync شدن Health Check در Load Balancer با وضعیت واقعی VM باشد، در حالی که VM کاملاً سالم است.
بررسی پورتهای Switch و پیکربندی VLANها برای رفع مسدودیت لایه ۲ چگونه انجام میشود؟
پس از ردّ احتمال خرابی کابلکشی فیزیکی، اولین نقطه تمرکز عیبیابی، تجهیزات لایه ۲ شبکه است. بسیاری از خطاهای Server Not Found ناشی از پیکربندی نادرست VLAN، Flapping پورتها یا فعالشدن Storm Control در سوییچهاست. چرا لایه ۲ اینقدر حیاتی است؟ زیرا تمام پروتکلهای بالاتر (TCP/IP, SSH, HTTP) وابسته به صحت انتقال فریمهای Ethernet هستند.
برای بررسی صحیح، از دستور show interface status استفاده کنید و خطاهای CRC یا Alignment را در کابلهای DAC یا Fiber بررسی نمایید. CRC Error معمولاً نشاندهنده تداخل الکترومغناطیسی، کابل فرسوده یا ماژول SFP ناسازگار است، در حالی که Alignment Error به معنای ناهماهنگی در ساختار فریمهاست که اغلب ناشی از تفریق سرعت (Duplex Mismatch) بین Switch و سرور است. هرگونه افزایش در خطاهای فیزیکی نشاندهنده خرابی کابل، ماژول SFP ناسازگار یا مشکل در پورت فیزیکی است. همچنین، MAC Address Flapping را با دستور show mac address-table aging-time و پایش مداوم لاگهای Syslog دیباگ کنید؛ فلپینگ مداوم نشانه حلقه شبکه (Network Loop) یا پیکربندی نادرست Trunk است که میتواند با فعالسازی STP BPDU Guard یا PortFast به سرعت مدیریت شود.
کنترل Storm Control نیز حیاتی است. برخی سوییچها به صورت پیشفرض ترافیک Broadcast یا Multicast بیش از حد مجاز را بلاک میکنند و این موضوع میتواند ترافیک سرور مجاز را نیز تحت تأثیر قرار دهد. در سناریوهای واقعی، یک ماشین مجازی آلوده به مالور یا یک اسکریپت پایتون معیوب میتواند صدها پکت Broadcast تولید کند که کل Subnet را قفل میکند. در نهایت، پورتهای Trunk را دیباگ کرده و تطابق VLAN Tags را با پورتهای دسترسی (Access) بررسی کنید. هرگونه عدم تطابق باعث قطع مسیریابی داخلی و تولید خطای Server Not Found میشود. استفاده از show interface trunk و بررسی Native VLAN mismatch از جمله گامهای ضروری است.
تاثیر قطع SAN/NAS و ارور RAID بر عملکرد وبسرور چیست؟
وقتی کنترلر SAN یا NAS حالت Degraded یا Failed را فعال میکند، درخواستهای I/O تاخیر یافته شده و وبسرور قبل از زمان Timeout کلاینت، قادر به ارسال پاسخ HTTP نیست. این سناریو بهویژه در محیطهای مجازی رایج است زیرا تمام VMها به یک آرایه استوریج مشترک وابستهاند. چرا تاخیر استوریج مستقیماً به خطای اپلیکیشن تبدیل میشود؟ زیرا وبسرورها اغلب به صورت synchronous عمل میکنند؛ اگر دیتابیس یا فایل کَش روی استوریج پاسخ ندهد، Threadهای وبسرور قفل شده و Connection Pool پر میشود تا جایی که سرور دیگر قادر به پذیرش درخواست جدید نیست.
برای شناسایی این مشکل، لاگهای HBA و وضعیت Multipath I/O را بررسی کنید. اطمینان از دسترسی redundant به لایه استوریج پیش از شکست کامل ارتباط، کلید جلوگیری از downtime است. اگر Multipath از کار بیفتد، هرگونه نوسان در ارتباط SAN میتواند منجر به از دسترس خارج شدن ناگهانی سرور شود. با استفاده از دستور mpathconf --find-with-vendor-id یا ابزارهای مخصوص هر توزیع، میتوانید وضعیت Pathها را مانیتور کنید. همچنین، بررسی Firmwareهای HBA و Firmwareهای کنترلر استوریج برای پچهای شناختهشده مرتبط با Timeout و Queue Depth از ضروریات است.
همچنین، یک تست عملیاتی با جداسازی موقت VMهای سنگین و پیمایش پایش آرایههای RAID تحت بار انجام دهید. پدیده Write Penalty در RAID ۵ هنگام خرابی یک دیسک، کاهش شدیدی در IOPS ایجاد میکند و وبسرور به دلیل ناتوانی در خواندن/نوشتن دادهها، پاسخ نمیدهد. در این حالت، حتی اگر سرور از نظر فیزیکی روشن باشد، سرویس آن عملاً قطع شده و خطای Server Not Found نمایش داده میشود. سناریوی واقعی: در یک فروشگاه آنلاین، هنگام تخفیف ویژه، خرابی ناگهانی یک دیسک در RAID 5 باعث افزایش Latency از ۲ میلیثانیه به ۸۰۰ میلیثانیه شد. وبسرور نتوانست صفحات را رندر کند، Connection Timeouts رخ داد و کاربران خطای Server Not Found دریافت کردند. راهحل: جایگزینی فوری دیسک، راهاندازی مجدد Rebuild و تنظیم مجدد Queue Depth در استوریج.
دیباگ لاگهای VMware و رابط iLO برای شناسایی هیتفایلها (Halt) چگونه است؟
در محیطهای مجازی، خطای Server Not Found اغلب ناشی از از دسترس خارج شدن یک ماشین مجازی (VM Unreachable) است. فایلهای vmware.log و esx.conf را بررسی کنید تا خطاهای VMDK Mapping یا تداخل منابع در محیطهای مجازی را شناسایی نمایید. این خطاها منجر به Unreachable State ماشین مجازی شده و ترافیک ورودی را بدون هیچ پاسخ HTTPای ریجکت میکنند. چرا این اتفاق میافتد؟ زیرا vSphere وقتی به استوریج دسترسی پیدا نمیکند، VM را در حالت Suspended یا Unreachable قرار میدهد تا از خرابی دادهها جلوگیری شود.
اتصال مستقیم به کنسول iLO/iDRAC/LX برای دیباگ لاگهای iLO و RAID ضروری است. بسیاری از سرورها دچار Boot Loop ناشی از Firmware Corruption میشوند که در ظاهر سرور روشن است اما هیچ سرویسی پاسخدهی نمیکند. کدهای POST را با دقت بخوانید و در صورت مشاهده خطای Hardware، ماژول مربوطه را تعویض یا Firmware را ریفلش کنید. همچنین، بررسی دمای CPU، وضعیت فنها، سلامت PSU و لاگهای IPMI/Sel از روتینهای استاندارد عیبیابی سختافزاری است. سناریوی عملی: یک سرور HP ProLiant پس از بروزرسانی BIOS دچار Hang در مرحله Memory Training شد. ظاهر سرور سالم بود، اما vCenter آن را Unreachable نشان میداد. با ریفلش BIOS و Reset NVRAM از طریق iLO، مشکل حل شد.
از vCenter Health Dashboard برای مقایسه مصرف CPU و RAM با بنچمارکهای پیشفرض استفاده کنید. Bottleneckهای پنهان مانند Memory Pressure یا CPU Ready بالا قبل از قطع کامل سرویس، نشانههای اولیهای هستند که مهندسان زیرساخت باید قبل از وقوع خطای Server Not Found آنها را رصد کنند. همچنین، بررسی Snapshot Consistency و مدیریت دورهای آنها حیاتی است؛ Snapshotهای قدیمی باعث Fragmentation فایلهای VMDK و کاهش شدید Performance میشوند که مستقیماً به Timeout وبسرور تبدیل میشوند. استفاده از vim-cmd vmsvc/get.summary برای بررسی وضعیت دقیق VM و لاگهای /var/log/vmkernel.log برای تحلیل VMkernel networking از ضروریات است.
استراتژی فیلتر کردن ترافیک نادرست توسط Firewall در عیبیابی چیست؟
بسیاری از اوقات سرور و زیرساخت کاملاً سالم هستند، اما ترافیک ورودی توسط Firewall ریجکت میشود. بررسی Session Table و State Tracking برای حذف قوانین overly-permissive یا محدودیتهای Connection Rate ضروری است. این محدودیتها میتوانند ترافیک لایه ۷ را بدون ارسال پاسخ مناسب، بلاک کنند. چرا Stateful Firewallها گاهی فریب میخورند؟ زیرا پروتکلهای مدرن مانند HTTP/2 یا QUIC از Multiplexing و Connection Pooling استفاده میکنند که میتواند به صورت ناگهانی هزاران درخواست همزمان تولید کند و جدول Connection Tracking را اشباع نماید.
تست ایزوله با غیرفعالسازی موقت Zone-based Policies و تحلیل ترافیک با tcpdump یا Wireshark انجام دهید. مشاهده پکتهای RST یا ICMP Unreachable نشان میدهد که ترافیک به سرور میرسد اما توسط یک Policy امنیتی ریجکت شده است. برای دیباگ دقیق، فیلتر tcpdump -i eth0 port 80 or port 443 -n` را اجرا کنید و به دنبال SYN Flood یا ACK Without SYN بگردید. همچنین، بررسی Thresholdهای Conntrack Table در لینوکس (sysctl net.netfilter.nf_conntrack_max) و افزایش آن در صورت نیاز از اقدامات پیشگیرانه حیاتی است.
بهینهسازی Rule Order در Firewall برای جلوگیری از Shadowing نیز حیاتی است. اطمینان حاصل کنید که سرویسهای وب روی پورتهای ۸۰ و ۴۴۳ در Whitelist قرار دارند و هیچ قانون قدیمی یا ناسازگار ترافیک ورودی را مسدود نمیکند. در محیطهای Enterprise، استفاده از WAF (Web Application Firewall) یا DDoS Protection میتواند ترافیک Legitimate را به دلیل الگوریتمهای Heuristic مسدود کند. سناریو: یک بهروزرسانی API باعث تغییر User-Agent و Headerهای جدید شد. WAF آن را به عنوان Bot شناسایی کرد و ترافیک را Block نمود. با افزودن Rule اختصاصی برای مسیر API و بهروزرسانی Signatureها، سرویس بازگشت. همچنین، بررسی NAT Table و Port Forwarding rules در Gatewayها از جمله گامهای نادیدهگرفتهشده است.
مقایسه روشهای تشخیص خطای Server Not Found در محیط فیزیکی، مجازی و کلاد
| لایه زیرساخت | تمرکز عیبیابی | ابزارهای کلیدی | نشانههای خطای Server Not Found |
|---|---|---|---|
| لایه فیزیکی | تمرکز بر LED وضعیت Switch، کابلکشی و لاگهای BMC/iLO | show interface status, ipmitool, POST Logs | Link Down، CRC Error، Firmware Corruption، Duplex Mismatch |
| لایه مجازی | اولویت با vSphere Logs، DRS Migration Events و Snapshot Consistency | vmware.log, vCenter Health Dashboard, esx.conf | VM Unreachable، VMDK Mapping Error، Resource Contention، CPU Ready بالا |
| لایه کلاد/SOA | دیباگ Security Groups، Load Balancer Health Checks و API Rate Limiting | AWS CloudWatch, Azure Monitor, Terraform Plan | Security Group Block، Health Check Failure، Rate Limit Exceeded، DNS Propagation Delay |
| لایه اپلیکیشن | پایش Thread Pool، Connection Pool و لاگهای Web Server | ELK Stack, Prometheus, Nginx/Apache Logs | Thread Exhaustion، OOM Killer، Timeout تنظیمشده، Backend Service Down |
چکلیست گامبهگام بازیابی سرویس از لایه فیزیکی تا اپلیکیشن
برای رفع خطای Server Not Found بهصورت سیستماتیک، مراحل زیر را به ترتیب اجرا کنید:
- تست Ping و Traceroute از کلاینت تا Gateway جهت ردیابی دقیق نقطه قطع در مسیر شبکه. اگر Ping Timeout باشد اما TTL مشخص شود، احتمال Routing Loop یا ICMP Block وجود دارد.
- بررسی وضعیت پورتهای Switch و اطمینان از Link Up و عدم وجود VLAN Mismatch بین پورتهای دسترسی و Trunk. بررسی لاگهای STP و BPDU Guard برای حذف حلقههای پنهان.
- لاگبینی HBA/RAID Controller و تایید سلامت آرایه SAN/NAS؛ بررسی Multipath I/O و وضعیت دیسکها. استفاده از
smartctl -a /dev/sdXبرای چک Health دیسکها. - اتصال به کنسول iLO و بررسی POST Code؛ در صورت مشاهده خطای Hardware، ماژول مربوطه را تعویض یا Firmware را ریفلش کنید. بررسی Sel/BMC Logs برای خطاهای پنهان سختافزاری.
- بررسی لاگهای ESXi/vCenter و وضعیت VM؛ راهاندازی مجدد Guest OS اگر VM در حالت Running قرار دارد اما پاسخدهی نمیکند. بررسی Snapshotها و Free Space در datastoreها.
- بررسی Web Server Log (Nginx/Apache/IIS) و تست سلامت Backend API برای اطمینان از عملکرد لایه اپلیکیشن. پایش Connection Pool و Thread Count با ابزارهای مناسب.
- بررسی قوانین Firewall و Session Table؛ غیرفعالسازی موقت Zone Policies و تحلیل ترافیک با tcpdump یا Wireshark. افزایش Conntrack Max در صورت اشباع جدول.
سوالات متداول
بازبینیشده توسط تیم فنی HPE24 / Falnic
این مقاله در لابراتوار فنی تخصصی بررسی و با آخرین مستندات مرجع مطابقت داده شده است. برای تضمین پایداری و صحت دادهها، کلیه کدهای ساختاری و متدهای اجرایی این محتوا تحت نظارت مهندسین ارشد شبکه و زیرساخت ما ارزیابی شدهاند.
