عیب‌یابی شبکه سرور با ping، traceroute و mtr

«سرور کند است»، «سایت گاهی باز نمی‌شود» یا «لگ بازی زیاد است» جمله‌هایی‌اند که مشکل را می‌گویند اما محلش را نه. ممکن است اشکال از اینترنت خود کاربر باشد، از یک مسیر بین‌شهری یا بین‌المللی، از شبکه دیتاسنتر یا از خود سرور. با سه ابزار ساده ping، traceroute و mtr می‌توانید محل مشکل را پیدا کنید. در این راهنمای عیب یابی شبکه خروجی هر ابزار را خط‌به‌خط می‌خوانیم، اشتباه رایج تفسیر Packet Loss را توضیح می‌دهیم و یاد می‌گیریم چه گزارشی برای پشتیبانی بفرستیم.

روش کلی عیب‌یابی

1. دامنه مشکل را مشخص کنید: آیا فقط برای شما است یا همه؟ فقط یک سایت یا همه سرویس‌های سرور؟ فقط از یک اینترنت (مثلاً موبایل) یا از همه؟
2. DNS را جدا کنید: اگر با IP کار می‌کند اما با دامنه نه، مشکل DNS است؛ DNS چیست.
3. از دو طرف تست کنید: از کامپیوتر خودتان به سرور و از سرور به یک مقصد معتبر، تا جهت مشکل مشخص شود.
4. در زمان مشکل تست کنید: تست بعد از رفع موقت مشکل چیزی نشان نمی‌دهد.

ping: آیا مقصد در دسترس است؟

ping -c 50 203.0.113.10      # لینوکس و مک
ping -n 50 203.0.113.10      # ویندوز

نمونه خلاصه خروجی:

50 packets transmitted, 49 received, 2% packet loss
rtt min/avg/max/mdev = 11.8/14.2/48.5/5.1 ms

• packet loss: درصد بسته‌های بی‌پاسخ. صفر یا نزدیک صفر مطلوب است.
• avg: میانگین زمان رفت و برگشت (RTT). برای مقصد داخل کشور معمولاً ده‌ها میلی‌ثانیه است. مفهوم در پینگ و تأخیر چیست.
• mdev (Jitter): نوسان تأخیر. برای بازی و تماس صوتی، نوسان بالا از تأخیر بالا آزاردهنده‌تر است.

توجه: برخی سرورها و فایروال‌ها به ping پاسخ نمی‌دهند. عدم پاسخ ping به معنی خاموش بودن سرور نیست؛ پورت سرویس را هم تست کنید (بخش ابزارهای تکمیلی).

traceroute: بسته از کجا می‌گذرد؟

traceroute 203.0.113.10       # لینوکس (sudo apt install traceroute)
tracert 203.0.113.10          # ویندوز

traceroute روترهای میان راه (Hop) را یکی‌یکی نشان می‌دهد. هر خط یک روتر است با سه زمان پاسخ. علامت * * * یعنی آن روتر به بسته‌های تست پاسخ نداده؛ اگر خط‌های بعدی پاسخ دارند، این طبیعی است و مشکل نیست. traceroute یک‌بار اجرا می‌شود و برای مشکل‌های لحظه‌ای کافی نیست؛ به همین دلیل mtr مفیدتر است.

mtr: ترکیب هر دو

mtr به‌طور مداوم به همه Hopهای مسیر بسته می‌فرستد و آمار Loss و تأخیر هر Hop را جمع می‌کند.

sudo apt install -y mtr-tiny        # Ubuntu/Debian
mtr 203.0.113.10                    # حالت تعاملی
mtr -rwbz -c 200 203.0.113.10       # گزارش ۲۰۰ بسته‌ای برای ارسال

• -r: حالت گزارش (پس از پایان چاپ می‌کند)
• -w: نام کامل میزبان‌ها
• -b: نمایش هم‌زمان نام و IP
• -z: نمایش شماره AS (شبکه مالک هر Hop)
• -c 200: تعداد بسته؛ برای آمار قابل‌اعتماد حداقل ۱۰۰
• -T -P 443: تست با TCP روی پورت ۴۴۳، وقتی ICMP مسدود یا محدود است

در ویندوز معادل گرافیکی آن WinMTR است و دستور داخلی pathping هم آمار مشابهی می‌دهد.

خواندن درست خروجی mtr

یک نمونه گزارش:

HOST                         Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.1.1               0.0%   200    1.1   1.3   0.9   4.2   0.4
 2. 10.20.0.1                 0.0%   200    6.5   7.0   5.8  15.1   1.2
 3. core1.isp.example         0.0%   200    8.2   8.9   7.5  20.3   1.8
 4. 172.16.40.9              45.0%   200   12.4  13.1  11.9  30.2   2.6
 5. border.dc.example         0.0%   200   12.9  13.4  12.1  25.0   1.9
 6. 203.0.113.10              0.0%   200   13.2  13.7  12.4  24.8   1.7

قانون طلایی: Packet Loss فقط وقتی واقعی است که تا مقصد ادامه پیدا کند. در نمونه بالا، Hop شماره ۴، ۴۵٪ Loss دارد اما Hopهای ۵ و ۶ صفر درصد. یعنی این روتر به بسته‌های تست با اولویت پایین پاسخ می‌دهد (ICMP Rate Limiting)، اما ترافیک عبوری را بدون مشکل عبور می‌دهد. این یکی از رایج‌ترین اشتباه‌ها در گزارش مشکل است.

• Loss در Hop میانی و صفر در مقصد: مشکل نیست.
• Loss از یک Hop شروع و تا مقصد ادامه دارد: مشکل واقعی، احتمالاً در همان Hop یا لینک قبل از آن.
• Loss فقط در آخرین Hop (مقصد): ممکن است سرور مقصد ICMP را محدود کرده باشد؛ با -T -P 443 دوباره تست کنید.
• افزایش ناگهانی تأخیر که تا مقصد می‌ماند: نشانه لینک شلوغ یا مسیر طولانی (مثلاً عبور ترافیک داخلی از خارج یا مسیر بین‌الملل). اگر افزایش فقط در یک Hop است و بعدی‌ها عادی‌اند، باز هم اولویت پایین پاسخ ICMP است.
• Wrst و StDev بالا: نوسان شدید که برای بازی و ویدیو مشکل‌ساز است.

سناریوهای رایج

Loss در Hop اول یا دوم

مشکل در شبکه داخلی شما است: Wi-Fi ضعیف، مودم یا کابل. با کابل مستقیم به مودم دوباره تست کنید.

Loss در شبکه ISP شما

اگر Loss از روترهای ارائه‌دهنده اینترنت شما شروع شود و تا مقصد ادامه یابد، با پشتیبانی ISP خود تماس بگیرید و همان گزارش mtr را بفرستید.

کندی فقط به مقصدهای خارجی

اگر سرور به مقصدهای داخلی سریع است اما به خارج کند، احتمالاً محدودیت یا شلوغی مسیر بین‌الملل است. توضیح در ترافیک داخلی و بین‌الملل و راهکارها در پایداری سرور در قطعی اینترنت.

شبکه سالم است اما سایت کند است

اگر mtr تا سرور صفر Loss و تأخیر پایین دارد، مشکل در سمت سرور یا برنامه است: CPU، RAM، دیسک یا کد. ابزارهای htop، iostat و لاگ وب‌سرور را بررسی کنید؛ راهنمای مانیتورینگ سرور. مصرف پهنای باند خود سرور را هم در نمودار ترافیک سرور ببینید؛ شاید پورت سرور پر است.

قطعی کامل یا Loss شدید ناگهانی به سرور

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

ابزارهای تکمیلی

# تست باز بودن پورت سرویس
nc -vz 203.0.113.10 443
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.ir

# بررسی DNS
dig +short example.ir
dig example.ir @1.1.1.1

# مسیرهای باز و اتصال‌های سرور
ss -tunap | head

دستور curl بالا زمان هر مرحله (DNS، اتصال TCP، TLS و اولین بایت) را جدا نشان می‌دهد. اگر connect پایین اما ttfb بالا باشد، شبکه سالم و پردازش سمت سرور کند است. ابزارهای بیشتر لینوکس در دستورات پایه لینوکس.

گزارش مناسب برای پشتیبانی

گزارشی که سریع بررسی می‌شود این موارد را دارد:

• IP عمومی شما (از سایتی مثل ip.trusthost.co) و نام ارائه‌دهنده اینترنت
• IP سرور یا دامنه مقصد
• زمان دقیق وقوع مشکل و اینکه دائمی است یا گاه‌به‌گاه
• خروجی mtr -rwbz -c 200 از سمت شما به سرور، و در صورت امکان از سرور به IP شما
• اگر فقط یک سرویس مشکل دارد، خروجی curl با زمان‌بندی بالا

خروجی را به‌صورت متن بفرستید، نه عکس؛ تا بتوان IPها و شماره‌ها را بررسی کرد.

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