عیب‌یابی افت پینگ و قطعی شبکه سرور با MTR و Traceroute
یک روز پینگ سروری که ماه‌ها بدون مشکل کار می‌کرد، از ۲۰ میلی‌ثانیه به ۲۰۰ میلی‌ثانیه می‌رسد یا هر چند دقیقه چند بسته گم می‌شود. اولین سوال همیشه این است: مشکل از اتصال خودمان است، از ISP، از مسیر بین‌المللی، یا از خود سرور؟ جواب این سوال را پینگ تنها نمی‌دهد؛ باید مسیر بسته‌ها را دید.
اول این‌ها را چک کن
قبل از باز کردن هر ابزاری، چند تست ساده جواب نصف سوال‌ها را می‌دهد.
از یک شبکه دیگر (مثلا موبایل با اینترنت همراه، نه وای‌فای همان دفتر) به همان سرور پینگ بزن. اگر مشکل فقط از یک شبکه دیده می‌شود، مسیر بین‌المللی یا خود سرور مقصر نیست؛ باید سراغ مودم، روتر یا ISP محلی بروی.
بعد پینگ خود سرور را به یک آی‌پی نزدیک و معروف (مثلا ۸.۸.۸.۸ یا یک سرویس بزرگ دیگر) از طریق SSH بزن. اگر از داخل سرور هم به بیرون پینگ بالا باشد، شک به سمت دیتاسنتر یا اتصال بالادستی سرور می‌رود، نه به اتصال خودت.
اگر این دو تست مشکل را مشخص نکرد، وقت traceroute و mtr است.
Traceroute چیست و چه می‌گوید
Traceroute مسیر بسته‌ها از دستگاه تو تا سرور مقصد را نشان می‌دهد؛ هر خط یک «هاپ» (hop) است، یعنی یک روتر میانی که بسته از آن رد شده. کنار هر هاپ، زمان رفت‌وبرگشت (RTT) به میلی‌ثانیه نوشته می‌شود.
traceroute -n 93.xxx.xxx.xxx
در ویندوز همین کار را tracert انجام می‌دهد. خروجی traceroute یک عکس لحظه‌ای است: هر هاپ را فقط چند بار (معمولا سه بار) تست می‌کند و بعد رد می‌شود. این برای دیدن مسیر کافی است، اما برای گفتن «کدام هاپ دقیقا افت پینگ دارد» کم است، چون یک نمونهٔ کوچک ممکن است تصادفی باشد.
MTR چیست و چرا دقیق‌تر از traceroute است
MTR (مخفف My Traceroute) همان کار traceroute را انجام می‌دهد، اما مدام و پشت‌سرهم، و برای هر هاپ درصد packet loss، میانگین، کمینه، بیشینه و نوسان (jitter) زمان پاسخ را نگه می‌دارد. به‌جای یک عکس، یک ویدیوی زنده از وضعیت مسیر می‌بینی.
| ویژگی | Traceroute | MTR |
|---|---|---|
| تعداد تست هر هاپ | معمولا ۳ بار | مداوم، صدها بار |
| نمایش packet loss | ندارد (یا محدود) | درصد دقیق برای هر هاپ |
| مناسب برای | دیدن سریع مسیر | عیب‌یابی افت پینگ و قطعی متناوب |
| خروجی زنده | نه | بله، آپدیت لحظه‌ای |
| نصب پیش‌فرض | بیشتر توزیع‌ها | باید نصب شود |
برای عیب‌یابی افت پینگ سرور، MTR ابزار اصلی است؛ traceroute بیشتر برای یک نگاه اول خوب است.
نصب و اجرای MTR
روی اوبونتو یا دبیان:
sudo apt install mtr
روی AlmaLinux یا Rocky:
sudo dnf install mtr
اجرای تست با گزارش متنی (برای کپی کردن و نشان دادن به ساپورت یا ISP):
mtr -rwc 100 8.8.8.8
این دستور ۱۰۰ بار (c 100) بسته می‌فرستد و یک گزارش (r) با فرمت کامل‌تر (w) چاپ می‌کند. هرچه تعداد بسته بیشتر باشد (مثلا ۲۰۰ یا ۳۰۰)، آمار loss قابل‌اعتمادتر است، چون افت‌های لحظه‌ای و گذرا بهتر خودشان را نشان می‌دهند.
اگر مقصد خود سرور است، MTR را هم از کلاینت به سمت سرور اجرا کن و هم از سرور به سمت یک آی‌پی بیرونی؛ این دو خروجی با هم مسیر رفت و برگشت را کامل می‌کنند.
خواندن خروجی: افت کجا اتفاق می‌افتد
نکتهٔ مهم: ستون Loss% در یک هاپ میانی، همیشه یعنی مشکل در همان هاپ است؟ نه. خیلی از روترهای میانی به‌عمد به بسته‌های ICMP (که ping و traceroute با آن کار می‌کنند) اولویت پایین می‌دهند یا نرخشان را محدود می‌کنند. اگر هاپ شمارهٔ ۵ مثلا ۳۰ درصد loss نشان بدهد، اما هاپ ۶ و هاپ‌های بعدی صفر درصد باشند و پینگ نهایی سالم باشد، آن ۳۰ درصد فقط مربوط به همان روتر است و روی ترافیک واقعی تاثیری ندارد.
افت واقعی وقتی است که loss از یک هاپ شروع می‌شود و تا مقصد نهایی ادامه پیدا می‌کند. اگر هاپ ۸ به بعد همه ۲۰ درصد loss دارند، احتمال زیاد مشکل همان‌جا یا قبل از آن است، نه در هاپ‌های بعدی که فقط آن را تکرار می‌کنند.
زمان پاسخ (RTT) هم همین‌طور باید خوانده شود. یک پرش ناگهانی در RTT بین دو هاپ معمولا یعنی یک لینک کند یا پرترافیک بین آن دو نقطه (مثلا یک کابل زیردریایی یا لینک بین دو کشور)، نه خرابی کامل.
مشکل از کجاست: ISP، مسیر بین‌المللی یا خود سرور؟
با توجه به اینکه loss از کدام هاپ شروع می‌شود، می‌توان منبع مشکل را تقریبا مشخص کرد.
| محل شروع افت | مقصر احتمالی | کاری که باید کرد |
|---|---|---|
| دو سه هاپ اول (نزدیک تو) | روتر یا ISP محلی | با ISP تماس بگیر، گزارش MTR را ضمیمه کن |
| هاپ‌های میانی، بین دو کشور | مسیر بین‌المللی/ترانزیت | معمولا باید منتظر ماند یا مسیر جایگزین (CDN و غیره) بررسی شود |
| هاپ آخر یا نزدیک به IP سرور | خود سرور یا دیتاسنتر | با پشتیبانی سرور تماس بگیر، گزارش را بفرست |
| همه هاپ‌ها سالم، فقط برنامه کند است | مشکل داخل سرور (CPU، دیسک، دیتابیس) | بار سرور را چک کن، نه شبکه |
اگر سطر آخر این جدول را دیدی -یعنی MTR از کلاینت تا سرور تمیز است ولی سایت یا سرویس هنوز کند است- دیگر مشکل شبکه نیست. آن‌جا باید سراغ مصرف CPU، RAM و دیسک خود سرور بروی، نه مسیر شبکه؛ دستور netstat هم برای دیدن اتصالات باز روی سرور کمک می‌کند.
اگر بعد از همهٔ این تست‌ها مشکل همچنان به خود سرور برمی‌گردد، تنظیمات شبکهٔ خود سرور لینوکس هم روی زمان پاسخ اثر دارد؛ فعال‌سازی TCP BBR و تنظیم sysctl یکی از مواردی است که ارزش بررسی دارد.
چند نکته برای عیب‌یابی سریع‌تر
مقصد پینگ را به یک آی‌پی ثابت و معروف انتخاب کن، نه یک دامنه؛ DNS خودش می‌تواند یک لایهٔ مشکل جدا باشد که نتیجه را گمراه‌کننده می‌کند.
اگر مشکل متناوب است (مثلا فقط شب‌ها)، MTR را روی یک بازهٔ طولانی و در حالت لاگ (mtr --report-cycles 500 -l) اجرا کن تا الگوی زمانی افت را هم ببینی، نه فقط یک لحظه.
گزارش MTR را همیشه با فرمت متنی (گزینهٔ -r) ذخیره کن، نه فقط اسکرین‌شات از حالت زنده؛ ISP و تیم‌های پشتیبانی برای بررسی به عدد خام نیاز دارند.
اگر روی سرور ابری اجرا می‌کنی و نتیجه نشان می‌دهد مشکل از قبل از رسیدن به دیتاسنتر است، داشتن یک سرور با شبکهٔ پایدار و لوکیشن مناسب نصف این دردسر را از همان اول کم می‌کند. سرور ابری آریانت روی زیرساخت با پینگ پایدار اجرا می‌شود و تست MTR را می‌توانی همان روز اول راه‌اندازی انجام بدهی.
جمع‌بندی
افت پینگ و قطعی شبکه همیشه یک دلیل ندارد و پینگ ساده آن را نشان نمی‌دهد. MTR با تست مداوم هر هاپ، نقطهٔ دقیق افت را مشخص می‌کند و تفاوت بین «مشکل گذرا در یک روتر میانی» و «افت واقعی تا مقصد» را روشن می‌کند. وقتی گزارش را داری، تماس با ISP یا پشتیبانی سرور هم خیلی سریع‌تر و دقیق‌تر جواب می‌گیرد.
سؤالات متداول
آیا پینگ بالا همیشه یعنی مشکل از سرور است؟ نه. خیلی وقت‌ها مشکل از مودم، وای‌فای یا ISP خود کاربر است. تست از یک شبکهٔ دیگر این را زود روشن می‌کند.
تفاوت اصلی MTR با traceroute چیست؟ Traceroute یک تست کوتاه و یک‌باره است؛ MTR همان مسیر را پشت‌سرهم تست می‌کند و برای هر هاپ درصد packet loss و آمار RTT نگه می‌دارد.
چرا بعضی هاپ‌ها در MTR صد درصد packet loss نشان می‌دهند ولی اتصال قطع نمی‌شود؟ چون آن روتر میانی پاسخ ICMP را محدود یا نادیده می‌گیرد، نه چون بسته‌های واقعی گم می‌شوند. اگر loss در هاپ‌های بعدی ادامه پیدا نکند، همین‌جا مشکل ساختگی است.
بعد از پیدا کردن محل افت پینگ باید با چه کسی تماس بگیرم؟ اگر افت در هاپ‌های اول است، با ISP محلی؛ اگر در هاپ‌های میانی بین‌المللی است، باید منتظر ماند یا مسیر جایگزین را بررسی کرد؛ اگر نزدیک آی‌پی سرور است، با پشتیبانی سرور یا دیتاسنتر، همراه با گزارش متنی MTR.
