سطح: مقدماتی تا متوسط  |  مناسب برای: مدیران سرور، کاربران VPS، مدیران سایت، پشتیبان‌های فنی، مدیران شبکه و افرادی که می‌خواهند مشکل کندی، قطعی یا Packet Loss را در مسیر شبکه بررسی کنند

وقتی یک سایت، سرور یا سرویس اینترنتی کند باز می‌شود، قطع و وصل دارد یا بعضی کاربران از یک مسیر خاص مشکل اتصال گزارش می‌کنند، فقط دانستن اینکه «سرور بالا است» کافی نیست. گاهی مشکل از خود سرور نیست، بلکه در مسیر شبکه، روترهای بین راه، ارتباط دیتاسنتر، ISP کاربر یا حتی یک hop میانی رخ می‌دهد. در چنین شرایطی ابزار MTR یکی از بهترین ابزارها برای عیب‌یابی مسیر شبکه است.

MTR مخفف My Traceroute است و ترکیبی از قابلیت‌های ping و traceroute را ارائه می‌دهد. این ابزار مسیر رسیدن بسته‌ها از سیستم شما تا مقصد را نمایش می‌دهد و در هر hop، میزان packet loss، latency و تغییرات زمان پاسخ را نشان می‌دهد. به همین دلیل برای تشخیص مشکلاتی مثل packet loss، latency بالا، ناپایداری مسیر و اختلال بین کاربر و سرور بسیار کاربردی است.

در این آموزش، نحوه اجرای MTR در ویندوز با WinMTR و در لینوکس با ابزار mtr را بررسی می‌کنیم، روش نصب در توزیع‌های مختلف را می‌گوییم، خروجی MTR را تحلیل می‌کنیم و توضیح می‌دهیم چطور از نتیجه آن برای گزارش مشکل به شرکت هاستینگ، دیتاسنتر یا ISP استفاده کنید.

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

فهرست مطالب

MTR چیست؟

MTR یک ابزار تشخیص مسیر شبکه است که عملکرد traceroute و ping را ترکیب می‌کند. Traceroute مسیر رسیدن بسته از سیستم شما تا مقصد را نشان می‌دهد، اما معمولاً یک تصویر لحظه‌ای از مسیر می‌دهد. Ping هم زمان پاسخ مقصد را بررسی می‌کند، اما مسیر بین راه را نشان نمی‌دهد.

MTR این دو را ترکیب می‌کند؛ یعنی هم hopهای مسیر را نشان می‌دهد و هم به‌صورت پیوسته کیفیت ارتباط با هر hop را اندازه‌گیری می‌کند. به همین دلیل می‌توانید ببینید در کدام نقطه مسیر، تأخیر یا packet loss ایجاد می‌شود.

MTR برای این موارد کاربرد زیادی دارد:

  • بررسی کندی اتصال به سرور
  • تشخیص packet loss در مسیر شبکه
  • بررسی latency بالا بین کاربر و دیتاسنتر
  • مقایسه مسیر اتصال از چند اینترنت مختلف
  • تهیه گزارش فنی برای پشتیبانی هاستینگ یا ISP
  • عیب‌یابی مشکلات شبکه در سرورهای لینوکسی و ویندوزی

تفاوت MTR با Ping و Traceroute

برای درک بهتر MTR، بهتر است تفاوت آن با دو ابزار شناخته‌شده‌تر یعنی Ping و Traceroute را ببینیم.

ابزارکاربردمزیتمحدودیت
Pingبررسی پاسخ‌گویی مقصدساده و سریعمسیر بین راه را نشان نمی‌دهد
Tracerouteنمایش مسیر تا مقصدنمایش hopهای مسیرمعمولاً تحلیل پایداری در زمان نمی‌دهد
MTRتحلیل مسیر، packet loss و latencyترکیب ping و traceroute با نمونه‌گیری پیوستهنیاز به تحلیل درست خروجی دارد

اگر فقط می‌خواهید بدانید مقصد پاسخ می‌دهد یا نه، Ping کافی است. اگر می‌خواهید مسیر را ببینید، Traceroute مفید است. اما اگر می‌خواهید بدانید در طول زمان کدام hop دچار packet loss یا تأخیر است، MTR ابزار مناسب‌تری است.

چه زمانی باید از MTR استفاده کنیم؟

اجرای MTR زمانی مفید است که مشکل شبکه حالت مبهم دارد و نمی‌دانید اختلال دقیقاً از کجاست.

نمونه موقعیت‌های مناسب برای اجرای MTR:

  • سایت برای بعضی کاربران کند است اما برای شما خوب باز می‌شود.
  • سرور ping دارد اما اتصال SSH یا سایت ناپایدار است.
  • کاربران یک شهر یا یک ISP مشکل اتصال دارند.
  • احتمال packet loss در مسیر وجود دارد.
  • می‌خواهید مسیر ایران تا سرور خارج یا برعکس را بررسی کنید.
  • پشتیبانی دیتاسنتر یا هاستینگ از شما خروجی MTR خواسته است.
  • می‌خواهید تفاوت مسیر شبکه چند اینترنت را مقایسه کنید.

اگر مشکل به باز بودن پورت یا فایروال مربوط باشد، MTR به‌تنهایی کافی نیست. در این حالت باید پورت سرویس را هم جداگانه بررسی کنید. برای نمونه، مقاله آموزش باز کردن پورت در فایروال اوبونتو می‌تواند مکمل این تست باشد.

قبل از اجرای MTR چه نکاتی را بدانیم؟

قبل از اینکه خروجی MTR را تحلیل کنید، چند نکته مهم را در نظر بگیرید:

  • بهتر است تست را حداقل ۱۰۰ تا ۲۰۰ packet اجرا کنید.
  • یک بار از سیستم کاربر به سمت سرور تست بگیرید.
  • در صورت امکان، یک بار هم از سرور به سمت IP کاربر یا مقصد تست بگیرید.
  • اگر مشکل فقط در زمان خاصی رخ می‌دهد، MTR را همان زمان اجرا کنید.
  • Packet loss در hopهای میانی همیشه به معنی مشکل واقعی نیست.
  • اگر loss از یک hop شروع شود و تا مقصد ادامه داشته باشد، مهم‌تر است.
  • خروجی MTR را همراه با IP مبدا، IP مقصد، ساعت تست و نوع اینترنت ارسال کنید.

برای گزارش‌های فنی، خروجی MTR کوتاه و ناقص معمولاً کمک زیادی نمی‌کند. بهتر است خروجی report با تعداد packet کافی تهیه شود.

نصب و اجرای MTR در ویندوز با WinMTR

در ویندوز معمولاً از ابزار WinMTR استفاده می‌شود. مقاله قبلی هم به دانلود WinMTR، انتخاب نسخه ۳۲ یا ۶۴ بیت و اجرای فایل exe اشاره کرده بود. [oai_citation:1‡pouyasazan-urgent-posts-content.json](sediment://file_00000000d144724387f507937bc7ccc7)

مراحل اجرای WinMTR در ویندوز:

  1. آخرین نسخه WinMTR را از یک منبع معتبر دانلود کنید.
  2. فایل ZIP را Extract کنید.
  3. بسته به نسخه ویندوز، وارد پوشه 32-bit یا 64-bit شوید.
  4. فایل WinMTR.exe را اجرا کنید.
  5. در قسمت Host، دامنه یا IP مقصد را وارد کنید.
  6. روی Start کلیک کنید.
  7. اجازه دهید حداقل چند دقیقه اجرا شود یا تعداد کافی packet جمع شود.
  8. در پایان، روی Export Text یا Copy Text کلیک کنید و خروجی را ذخیره کنید.

برای مثال در قسمت Host می‌توانید یکی از این‌ها را وارد کنید:

example.com
8.8.8.8
SERVER_IP

بهتر است در تست‌های دقیق، هم دامنه و هم IP مقصد را در صورت نیاز بررسی کنید. اگر دامنه به IP اشتباه resolve شود، مشکل ممکن است از DNS باشد. برای درک بهتر این بخش، مقاله DNS چیست؟ را هم ببینید.

نصب MTR در لینوکس

در لینوکس می‌توانید ابزار mtr را از package manager نصب کنید. در نسخه قبلی مقاله، نصب در Ubuntu/Debian، CentOS/Fedora و Arch Linux توضیح داده شده بود. [oai_citation:2‡pouyasazan-urgent-posts-content.json](sediment://file_00000000d144724387f507937bc7ccc7)

نصب MTR در Ubuntu و Debian

sudo apt update
sudo apt install mtr -y

در بعضی توزیع‌ها، بسته ممکن است با نام mtr-tiny هم موجود باشد:

sudo apt install mtr-tiny -y

نصب MTR در CentOS، AlmaLinux و Rocky Linux

sudo yum install mtr -y

یا در نسخه‌های جدیدتر:

sudo dnf install mtr -y

نصب MTR در Arch Linux

sudo pacman -S mtr

بعد از نصب، با دستور زیر می‌توانید مطمئن شوید MTR نصب شده است:

mtr --version

اجرای MTR در لینوکس

ساده‌ترین روش اجرای MTR در لینوکس این است که دامنه یا IP مقصد را بعد از دستور وارد کنید:

mtr example.com

یا:

mtr 8.8.8.8

این حالت یک محیط تعاملی باز می‌کند و به‌صورت زنده مسیر، packet loss و latency را نشان می‌دهد.

اگر می‌خواهید به‌جای دامنه، IP سرور خود را تست کنید:

mtr SERVER_IP

برای خروج از محیط MTR می‌توانید کلید q را بزنید.

گرفتن خروجی report از MTR

برای ارسال گزارش به پشتیبانی، بهتر است از حالت report استفاده کنید؛ چون خروجی متنی و قابل ارسال تولید می‌کند. در مقاله قبلی هم به اجرای MTR با گزینه report اشاره شده بود. [oai_citation:3‡pouyasazan-urgent-posts-content.json](sediment://file_00000000d144724387f507937bc7ccc7)

دستور پیشنهادی:

mtr -rwzc 100 example.com

یا برای IP:

mtr -rwzc 100 SERVER_IP

معنی گزینه‌ها:

  • -r: خروجی report تولید می‌کند.
  • -w: خروجی wideتر و خواناتر می‌دهد.
  • -z: در بعضی نسخه‌ها ASN یا اطلاعات اضافی مسیر را نمایش می‌دهد.
  • -c 100: تعداد ۱۰۰ packet ارسال می‌کند.

اگر گزینه -z در نسخه شما پشتیبانی نشد، آن را حذف کنید:

mtr -rwc 100 example.com

برای ذخیره خروجی در فایل:

mtr -rwc 100 example.com > mtr-report.txt

گزینه‌های کاربردی MTR

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

گزینهکاربردمثال
-rخروجی reportmtr -r example.com
-cتعداد packetmtr -c 100 example.com
-wنمایش wide و خواناترmtr -rw example.com
-nنمایش IP بدون resolve کردن hostnamemtr -n example.com
-4اجبار به IPv4mtr -4 example.com
-6اجبار به IPv6mtr -6 example.com
-Tاستفاده از TCP به‌جای ICMP/UDP در بعضی نسخه‌هاmtr -T -P 443 example.com
-Pتعیین پورت برای TCP/UDPmtr -T -P 443 example.com

برای مشاهده جزئیات بیشتر گزینه‌های این ابزار، می‌توانید صفحه رسمی راهنمای mtr command را هم بررسی کنید.

برای مشاهده همه گزینه‌ها، می‌توانید از man page یا help استفاده کنید:

man mtr
mtr --help

آموزش خواندن خروجی MTR

خروجی MTR معمولاً چند ستون مهم دارد. بسته به نسخه و سیستم‌عامل، نام ستون‌ها ممکن است کمی متفاوت باشد، اما مفهوم کلی مشابه است.

ستونمعنی
Hostنام یا IP هر hop در مسیر
Loss%درصد packet loss در آن hop
Sntتعداد packetهای ارسال‌شده
Lastآخرین زمان پاسخ
Avgمیانگین زمان پاسخ
Bestبهترین یا کمترین زمان پاسخ
Wrstبدترین یا بیشترین زمان پاسخ
StDevمیزان نوسان زمان پاسخ

در تحلیل MTR، فقط یک ستون را نبینید. باید مسیر را به‌صورت کامل بررسی کنید. مثلاً loss در یک hop میانی اگر در hopهای بعدی ادامه پیدا نکند، معمولاً به معنی مشکل واقعی در مسیر نیست و ممکن است آن روتر فقط پاسخ ICMP را محدود کرده باشد.

Packet Loss در MTR را چطور تحلیل کنیم؟

Packet Loss یکی از مهم‌ترین مواردی است که در MTR بررسی می‌شود. اما تحلیل آن باید با دقت انجام شود.

چند سناریوی رایج:

Loss فقط در یک hop میانی دیده می‌شود

اگر یک hop میانی مثلاً ۳۰٪ loss نشان می‌دهد، اما hopهای بعدی و مقصد loss ندارند، معمولاً مشکل جدی نیست. بسیاری از روترها پاسخ به ICMP یا probeهای MTR را محدود می‌کنند، اما ترافیک عبوری را درست forward می‌کنند.

Loss از یک hop شروع می‌شود و تا مقصد ادامه دارد

اگر از یک hop به بعد، همه hopهای بعدی و مقصد هم loss مشابه نشان می‌دهند، احتمال وجود مشکل واقعی در همان بخش مسیر بیشتر است.

Loss فقط در مقصد دیده می‌شود

اگر فقط مقصد loss دارد، ممکن است مشکل از خود سرور، فایروال مقصد، محدودیت ICMP، مصرف منابع سرور یا شبکه دیتاسنتر باشد.

Loss در hop اول دیده می‌شود

اگر hop اول loss دارد، ممکن است مشکل از شبکه داخلی، مودم، روتر، Wi-Fi یا اینترنت مبدا باشد.

بنابراین نتیجه‌گیری درست این است: Packet Loss زمانی مهم‌تر است که از یک نقطه شروع شود و تا مقصد ادامه پیدا کند.

Latency و Jitter در MTR یعنی چه؟

Latency یعنی مدت زمانی که بسته از مبدا تا مقصد و برگشت طی می‌کند. در MTR معمولاً با مقادیر Last، Avg، Best و Worst دیده می‌شود.

Jitter یعنی نوسان latency. اگر Avg پایین است اما Worst خیلی بالا می‌رود یا StDev زیاد است، یعنی مسیر ناپایدار است و زمان پاسخ نوسان دارد.

برای مثال:

  • Avg پایین و StDev پایین: مسیر پایدار است.
  • Avg بالا اما ثابت: مسیر دور یا دارای تأخیر طبیعی است.
  • Avg متوسط ولی Wrst خیلی بالا: نوسان یا congestion وجود دارد.
  • Latency از یک hop به بعد ناگهان زیاد می‌شود: احتمال مشکل یا تغییر مسیر در همان بخش وجود دارد.

برای سایت‌ها و سرویس‌های عمومی، latency به محل کاربر، لوکیشن سرور، کیفیت مسیر اینترنت و نوع شبکه بستگی دارد. به همین دلیل انتخاب موقعیت سرور هم مهم است. برای مثال، در برخی پروژه‌ها انتخاب سرور مجازی ایران یا سرور مجازی آلمان می‌تواند تجربه متفاوتی برای کاربران ایجاد کند.

چرا گاهی باید MTR دوطرفه بگیریم؟

مسیر رفت و برگشت اینترنت همیشه یکسان نیست. ممکن است مسیر کاربر به سرور سالم باشد، اما مسیر سرور به کاربر از شبکه دیگری عبور کند و مشکل داشته باشد. به همین دلیل، در عیب‌یابی‌های جدی بهتر است MTR را از هر دو سمت بگیرید.

دو تست مهم:

  • از سیستم کاربر به سمت IP سرور
  • از سرور به سمت IP کاربر یا مقصد دیگر

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

اشتباهات رایج در تحلیل MTR

در تحلیل MTR چند اشتباه رایج وجود دارد:

  • دیدن loss در یک hop میانی و نتیجه‌گیری فوری درباره خرابی همان روتر.
  • اجرای تست با تعداد packet خیلی کم.
  • تست گرفتن در زمانی غیر از زمان وقوع مشکل.
  • استفاده از دامنه بدون بررسی اینکه به IP درست resolve می‌شود.
  • نادیده گرفتن تفاوت مسیر رفت و برگشت.
  • توجه نکردن به فایروال، ICMP rate limit یا محدودیت پاسخ‌دهی روترها.
  • مقایسه نکردن تست از چند اینترنت یا چند لوکیشن.

MTR ابزار قدرتمندی است، اما فقط وقتی نتیجه خوبی می‌دهد که خروجی آن درست تحلیل شود.

چطور خروجی MTR را برای پشتیبانی ارسال کنیم؟

اگر می‌خواهید خروجی MTR را برای پشتیبانی هاستینگ، دیتاسنتر یا ISP ارسال کنید، بهتر است فقط یک اسکرین‌شات کوتاه نفرستید. اطلاعات کامل‌تر باعث می‌شود مشکل سریع‌تر بررسی شود.

اطلاعاتی که همراه MTR ارسال کنید:

  • IP یا دامنه مقصد
  • IP مبدا یا نام ISP کاربر
  • زمان دقیق تست
  • کشور و شهر مبدا، اگر مرتبط است
  • خروجی MTR با حداقل ۱۰۰ packet
  • توضیح مشکل؛ مثلاً کندی سایت، قطعی SSH، packet loss یا timeout
  • اگر امکان دارد، خروجی MTR دوطرفه

نمونه دستور مناسب برای ارسال به پشتیبانی:

mtr -rwc 200 SERVER_IP > mtr-to-server.txt

اگر مشکل مربوط به دسترسی سایت است، علاوه بر MTR، تست‌هایی مثل curl، ping، traceroute و بررسی DNS هم می‌توانند کمک کنند. برای مشکلات DNS، مقاله DNS چیست؟ را بخوانید.

چک‌لیست سریع اجرای MTR

مرحلهاقدام پیشنهادی
انتخاب مقصددامنه یا IP درست را مشخص کنید
ویندوزاز WinMTR استفاده کنید
لینوکسبسته mtr را نصب کنید
تعداد packetحداقل ۱۰۰ packet برای گزارش فنی
خروجی reportmtr -rwc 100 destination
تحلیل lossببینید loss تا مقصد ادامه دارد یا فقط در hop میانی است
تحلیل latencyAvg، Wrst و StDev را بررسی کنید
تست دوطرفهدر مشکلات جدی از هر دو سمت MTR بگیرید
ارسال به پشتیبانیزمان تست، مبدا، مقصد و توضیح مشکل را همراه خروجی بفرستید

جمع‌بندی

MTR یکی از کاربردی‌ترین ابزارها برای عیب‌یابی مسیر شبکه است. این ابزار با ترکیب قابلیت‌های ping و traceroute، به شما نشان می‌دهد بسته‌ها از چه مسیرهایی عبور می‌کنند، در کدام hopها تأخیر بیشتر است و آیا packet loss تا مقصد ادامه دارد یا فقط در یک نقطه میانی دیده می‌شود.

در ویندوز می‌توانید از WinMTR استفاده کنید و در لینوکس با نصب بسته mtr، تست را از خط فرمان اجرا کنید. برای گزارش‌های فنی، بهتر است خروجی report با حداقل ۱۰۰ یا ۲۰۰ packet تهیه شود و همراه با اطلاعات مبدا، مقصد و زمان تست برای پشتیبانی ارسال شود.

نکته مهم این است که خروجی MTR باید درست تحلیل شود. packet loss در یک hop میانی همیشه به معنی خرابی مسیر نیست. زمانی loss مهم‌تر می‌شود که از یک hop شروع شود و تا مقصد ادامه پیدا کند. همچنین برای عیب‌یابی دقیق‌تر، مخصوصاً در مشکلات دیتاسنتری یا بین‌المللی، گرفتن MTR دوطرفه بسیار مفید است.

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

MTR چیست؟

MTR یا My Traceroute ابزاری برای عیب‌یابی شبکه است که قابلیت‌های ping و traceroute را ترکیب می‌کند و مسیر شبکه، packet loss و latency را نمایش می‌دهد.

تفاوت MTR با Traceroute چیست؟

Traceroute مسیر رسیدن به مقصد را نشان می‌دهد، اما MTR علاوه بر مسیر، به‌صورت پیوسته packet loss و latency هر hop را هم بررسی می‌کند.

در ویندوز چطور MTR اجرا کنیم؟

در ویندوز معمولاً از WinMTR استفاده می‌شود. آن را اجرا کنید، دامنه یا IP مقصد را در بخش Host وارد کنید و روی Start بزنید.

در لینوکس چطور MTR نصب کنیم؟

در Ubuntu و Debian از sudo apt install mtr -y، در CentOS/Rocky/AlmaLinux از sudo yum install mtr -y یا sudo dnf install mtr -y استفاده کنید.

دستور report در MTR چیست؟

برای گرفتن خروجی قابل ارسال می‌توانید از دستور mtr -rwc 100 example.com استفاده کنید. این دستور بعد از ۱۰۰ packet یک گزارش متنی تولید می‌کند.

Packet Loss در MTR یعنی چه؟

Packet Loss یعنی درصدی از بسته‌های ارسال‌شده پاسخی دریافت نکرده‌اند. اگر loss از یک hop شروع شود و تا مقصد ادامه داشته باشد، احتمال مشکل واقعی بیشتر است.

آیا packet loss در یک hop میانی همیشه مشکل است؟

خیر. اگر loss فقط در یک hop میانی دیده شود و در hopهای بعدی و مقصد ادامه نداشته باشد، معمولاً به معنی محدود کردن پاسخ ICMP توسط همان روتر است، نه مشکل واقعی در عبور ترافیک.

برای پشتیبانی چند packet در MTR کافی است؟

برای گزارش اولیه حداقل ۱۰۰ packet مناسب است. در مشکلات ناپایدار یا مقطعی، ۲۰۰ packet یا بیشتر بهتر است.

چرا باید MTR دوطرفه بگیریم؟

چون مسیر رفت و برگشت اینترنت همیشه یکسان نیست. ممکن است مسیر کاربر به سرور سالم باشد اما مسیر سرور به کاربر مشکل داشته باشد.

اگر MTR مقصد را نشان نمی‌دهد یعنی سرور قطع است؟

لزوماً نه. ممکن است ICMP یا probeهای MTR توسط فایروال مقصد یا روترهای میانی محدود شده باشند. باید سرویس اصلی، پورت‌ها و مسیر شبکه را هم جداگانه بررسی کنید.