How to Read a Traceroute: Every Hop, Every Asterisk, and When a Route Is Abnormal
2026-09-05 · undefined min
A traceroute answers the question that ping cannot: not just whether a destination is reachable, but which path the traffic takes to get there. It lists every router your packets pass through, one line at a time, with a round-trip time for each. The output looks like a simple numbered list, but each line is a clue about where on the internet your traffic slows down or stops.
The short version: read the latency, be skeptical of the asterisks, and notice when a hop looks private or repeats. Those three observations solve most routing questions.
1988
Traceroute is invented
Van Jacobson writes the first traceroute, using the TTL field to force routers to reveal themselves one hop at a time.
1990s
TTL-based probing becomes standard
The technique is formalized and built into every major OS, becoming the default tool for tracing network paths.
2000s
Modern networks complicate the picture
Load balancing, MPLS and tunnels make routes less linear, and many routers stop answering trace probes entirely.
Today
Reading routes with skepticism
Asterisks and silent hops are now so common that reading a traceroute means knowing which hops are trustworthy and which are not.
What each hop is telling you
Each numbered line is one router along the path. The first hops are almost always your own network - your router, then your ISP's edge. The middle hops are the long haul across the internet, and the final hops are the destination's network. The round-trip time on each line is how long a probe took to get to that router and come back.
Latency generally increases with distance, so a few extra milliseconds per hop is normal. A sudden jump - say, from 5ms to 90ms between two adjacent hops - often means the packets crossed a long distance, a congested peering point, or a different network entirely.
The asterisks: what a silent hop means
You will see asterisks (`* * *`) in place of a latency. This does not mean the route is broken. Many routers are configured to drop traceroute probes for security or to reduce load, so they simply do not answer. A missing reply is common and often tells you nothing about the health of the route.
A single asterisked hop between two responding hops is usually harmless. What matters is a pattern: if the destination itself returns asterisks but your traffic still works, the path is fine and the last router just does not answer probes. If the destination shows asterisks and traffic is broken, the silence is at the endpoint, not the path.
Traceroute reveals the path hop by hop, unlike a single ping which measures only the round trip to the destination.
Private, repeated and odd hops
You may see private addresses (like 192.168.x.x or 10.x.x.x) in the middle of a route. That is normal inside carrier networks using private addressing internally, or through a VPN. Seeing your own private address at the first hop is expected; seeing a private address deep in the route is a sign you are inside a tunnel or an ISP using carrier-grade NAT.
Repeated addresses are another clue. A router appearing twice in a row usually means load balancing between two paths, not a loop. A genuine loop - the same few addresses repeating endlessly until the traceroute hits its hop limit - is the real anomaly, and it means routing is broken.
When the route is actually abnormal
A traceroute is abnormal when the destination shows a high, consistent latency but the route between hops is clean, or when the route stops at a particular hop and never reaches the destination. The first case points to congestion or a slow server; the second points to a block or a failure at that specific hop.
The key is to compare the traceroute with the actual outcome. If the route looks clean but your connection is slow, the problem is not the path - it is the destination or your own network. If the route stops and traffic fails, the problem is at the last responding hop or beyond it.
সারসংক্ষেপ
A traceroute is a map, not a verdict. Read the latency for clues, distrust the asterisks, and use the path to narrow the problem. Combined with a ping to the destination, it will tell you whether the fault is yours, your provider's, or the destination's - and where exactly it lives.
আপনার পাবলিক IP ঠিকানা এবং নেটওয়ার্ক অবস্থান, স্বয়ংক্রিয়ভাবে সনাক্ত করা হয়েছে।
NetChecks খোলার সাথে সাথেই এটি স্বয়ংক্রিয়ভাবে লোড হয় — কোনো ইনপুট প্রয়োজন নেই। নেটওয়ার্ক বা VPN পরিবর্তনের পর রিফ্রেশ বাটন ব্যবহার করুন।
আপনার ব্রাউজার
অল-ইন-ওয়ান স্ক্যান
একটি IP বা হোস্টনেমের উপর একবারে সমস্ত প্রাসঙ্গিক পরীক্ষা চালায়: DNS, whois, ping, traceroute, পরিচিত পোর্ট স্ক্যান (1-1024), HTTP হেডার এবং SSL সার্টিফিকেট।
একটি ডোমেইন বা IP ঠিকানা লিখে চালান, যাতে DNS, whois, ping, traceroute, সাধারণ পোর্ট, HTTP হেডার এবং SSL সার্টিফিকেট একসাথে যাচাই করা যায়।
বেশিরভাগ পরীক্ষা সমান্তরালে চলে - সাধারণত প্রায় ৩০ সেকেন্ডে সম্পন্ন হয়, লক্ষ্য ধীর বা অপ্রাপ্য হলে আরও বেশি সময় লাগতে পারে।
উপরের সম্মতি চেকবক্স চেক করা হলেই কেবল পোর্ট স্ক্যান ধাপটি চলবে - অন্য সব পরীক্ষা যেভাবেই হোক চলবে।
পিং (Ping)
কোনো হোস্টের প্রাপ্যতা ও লেটেন্সি যাচাই করতে ICMP echo অনুরোধ পাঠায়।
একটি হোস্টনাম বা IP ঠিকানা লিখে ICMP ইকো অনুরোধ পাঠাতে ও রাউন্ড-ট্রিপ লেটেন্সি মাপতে Ping চাপুন।
সম্পর্কে আরও জানুন পিং (Ping)
এটি কী
পিং একটি হোস্টে ICMP Echo Request প্যাকেট পাঠায় এবং ICMP Echo Reply প্যাকেট ফেরত আসতে যে সময় লাগে তা পরিমাপ করে। এটি সবচেয়ে মৌলিক নেটওয়ার্ক কানেক্টিভিটি টেস্ট: এটি ঠিক একটি প্রশ্নের উত্তর দেয়, "এই মেশিনটি কি পৌঁছানো যায়, এবং কত দ্রুত?" ICMP প্রোটোকল (RFC 792) ১৯৮১ সালে বিশেষভাবে IP নেটওয়ার্কে কন্ট্রোল ও ডায়াগনস্টিক মেসেজ বহন করার জন্য ডিজাইন করা হয়েছিল, যেকোনো অ্যাপ্লিকেশন ট্র্যাফিক থেকে স্বাধীনভাবে - এবং পিং হলো এর সবচেয়ে সুপরিচিত ও সবচেয়ে সর্বজনীনভাবে উপলব্ধ বাস্তবায়ন, কার্যত প্রতিটি অপারেটিং সিস্টেম এবং নেটওয়ার্ক ডিভাইসে তার প্রাচীনতম সংস্করণ থেকে বিদ্যমান।
এটি কীভাবে কাজ করে
প্রতিটি ICMP প্যাকেট একটি TTL (Time To Live) ফিল্ড বহন করে যা এটি অতিক্রম করা প্রতিটি রাউটারে এক করে কমে যায়; যদি এটি গন্তব্যে পৌঁছানোর আগে শূন্যে পৌঁছায়, প্যাকেটটি ড্রপ করা হয় এবং প্রেরকের কাছে একটি এরর পাঠানো হয়। মিলিসেকেন্ডে পরিমাপ করা রাউন্ড-ট্রিপ টাইম (RTT) সম্পূর্ণ যাত্রা জুড়ে ক্রমবর্ধমান নেটওয়ার্ক রেসপন্স টাইম প্রতিফলিত করে, শুধুমাত্র গন্তব্যের কাছাকাছি শেষ অংশ নয় - প্রায়শই ভুল বোঝা একটি পয়েন্ট, কারণ একটি ধীর পিং ফলাফলের প্রকৃত কারণ পথের যেকোনো বিন্দুতে থাকতে পারে, পরীক্ষিত সার্ভারের কাছাকাছি অগত্যা নয়। একটি পিং সাধারণত একটির পরিবর্তে বেশ কয়েকটি প্যাকেট পরপর পাঠায়, যা একটি অস্থায়ী রেসপন্স টাইম বৃদ্ধি এবং একটি পুনরাবৃত্ত সমস্যার মধ্যে পার্থক্য করতে এবং নমুনায় প্যাকেট লস রেট গণনা করতে দেয়।
ফলাফল বোঝা
কম ও স্থিতিশীল রেসপন্স টাইম - একটি স্থানীয় নেটওয়ার্কে কয়েক মিলিসেকেন্ড, একই দেশের মধ্যে একটি গন্তব্যের জন্য ১০ থেকে ৫০ মিলিসেকেন্ড, একটি আন্তঃমহাদেশীয় সংযোগের জন্য অনেক বেশি - একটি স্বাস্থ্যকর সংযোগ নির্দেশ করে। এমনকি সামান্য প্যাকেট লস (১-২%-এর উপরে) VoIP বা রিয়েল-টাইম ইন্টারঅ্যাক্টিভ সেশনের মতো লেটেন্সি-সেনসিটিভ ব্যবহারের জন্য বিশেষভাবে ক্ষতিকর, যেখানে প্রতিটি হারানো প্যাকেট একটি শ্রবণযোগ্য গ্লিচ বা কাট হিসেবে প্রকাশ পায়। প্যাকেট থেকে প্যাকেটে একটি উল্লেখযোগ্য রেসপন্স টাইম ভিন্নতা (জিটার) এই একই ব্যবহারের জন্য প্রায়শই সম্পূর্ণ স্থিতিশীল কিন্তু উচ্চ রেসপন্স টাইমের চেয়ে বড় সমস্যা। "রিকোয়েস্ট টাইমড আউট" মানে নির্ধারিত সময়ের মধ্যে কোনো রিপ্লাই আসেনি - হোস্টটি প্রকৃতপক্ষে ডাউন থাকতে পারে, একটি ফায়ারওয়াল নীরবে ICMP ব্লক করতে পারে, অথবা পথে কোথাও একটি ভাঙা রুট থাকতে পারে; "ডেস্টিনেশন আনরিচেবল" ভিন্ন এবং আরও তথ্যপূর্ণ: একটি ইন্টারমিডিয়েট রাউটার স্পষ্টভাবে জানিয়েছে যে এটি প্যাকেটটি ফরোয়ার্ড করতে পারেনি, যা সমস্যাটি আরও সঠিকভাবে অবস্থিত করতে সাহায্য করে।
সাধারণ ভুল
সবচেয়ে সাধারণ ব্যাখ্যাগত ভুল হলো একটি পিং ব্যর্থ হলেই একটি হোস্ট "ডাউন" বলে উপসংহারে পৌঁছানো, অথচ বাস্তবে অনেক সার্ভার ও ডিভাইস - বিশেষ করে একটি ভালোভাবে কনফিগার করা ফায়ারওয়ালের পিছনে, বা প্রধান ক্লাউড প্রোভাইডারদের কাছে হোস্ট করা - নীতি হিসেবে ইচ্ছাকৃতভাবে ইনকামিং ICMP ব্লক করে, অথচ তাদের প্রকৃত সার্ভিস (HTTP, ডাটাবেস, ইত্যাদি) সম্পূর্ণ কার্যকরী ও পৌঁছানোযোগ্য থাকে। তাই একটি পিং রেসপন্সের অনুপস্থিতি শুধুমাত্র অন্য সূচকগুলোর সাথে মিলিয়ে ডাউনটাইমের একটি বৈধ প্রমাণ, যেমন অ্যাপ্লিকেশন নিজেও রেসপন্স না করা। বিপরীতভাবে, একটি সফল পিং কখনোই গ্যারান্টি দেয় না যে সেই মেশিনে হোস্ট করা অ্যাপ্লিকেশন সার্ভিস সঠিকভাবে কাজ করছে - এগুলো নেটওয়ার্ক স্ট্যাকে দুটি সম্পূর্ণ স্বাধীন স্তর।
কখন ব্যবহার করবেন
একটি টিকিট এসকেলেট করার আগে যাচাই করার প্রথম জিনিস: আরও তদন্তের আগে ডিভাইসটি আদৌ রেসপন্স করছে কিনা? একটি ফায়ারওয়াল রুল বা রাউটিং টেবিল পরিবর্তনের পর কানেক্টিভিটি নিশ্চিত করা, নিশ্চিত করতে যে পরিবর্তনটি অ্যাক্সেস ভাঙেনি। VoIP রোলআউট বা প্রোভাইডার লিঙ্ক ফেইলওভারের আগে একটি রেসপন্স টাইম বেসলাইন স্থাপন করা, পরে কল কোয়ালিটি সম্পর্কে অভিযোগ এলে একটি বস্তুনিষ্ঠ তুলনা পয়েন্ট প্রদান করতে। একাধিক ক্লায়েন্ট সাইট সমান্তরালে পর্যবেক্ষণ করা একটি MSP-এর জন্য নিয়মিত, হালকা স্বাস্থ্য চেক, সবসময় গভীর অ্যাপ্লিকেশন-স্তরের মনিটরিংয়ের পরিপূরক হিসেবে - কখনোই প্রতিস্থাপন হিসেবে নয়।
ট্রেসরুট (Traceroute)
গন্তব্য হোস্ট পর্যন্ত নেটওয়ার্ক পথ (হপ বাই হপ) ট্রেস করে।
একটি হোস্টনাম বা IP ঠিকানা লিখে চালান, যাতে এই সার্ভার ও গন্তব্যের মধ্যে প্রতিটি নেটওয়ার্ক হপ এবং তার লেটেন্সি দেখা যায়।
DNS লুকআপ (Nslookup)
DNS রেকর্ড কোয়েরি করুন: A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, CAA।
একটি ডোমেইন লিখুন, একটি রেকর্ড টাইপ বেছে নিন (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, বা CAA), তারপর অনুসন্ধান করুন।
Whois
কোনো ডোমেইন বা IP ঠিকানার নিবন্ধন তথ্য দেখুন।
কোনো ডোমেইন বা IP ঠিকানার নিবন্ধন তথ্য দেখতে সেটি লিখুন — রেজিস্ট্রার, মালিক প্রতিষ্ঠান ও গুরুত্বপূর্ণ তারিখ।
ব্ল্যাকলিস্ট চেক
কোনো IP ঠিকানা বা ডোমেইন সর্বজনীন স্প্যাম/অপব্যবহার ব্ল্যাকলিস্টে (DNSBL) তালিকাভুক্ত কিনা তা পরীক্ষা করে।
একটি IPv4 ঠিকানা বা ডোমেইন লিখে চালান, যাতে একসাথে ৭টি সর্বজনীন DNSBL/RBL ব্ল্যাকলিস্ট পরীক্ষা করা যায় - প্রতিটি তালিকাভুক্ত, তালিকাভুক্ত নয়, বা পরীক্ষা ব্যর্থ হিসেবে দেখানো হয়।
TCP পোর্ট স্ক্যান
কোনো হোস্ট বা IP-তে TCP পোর্ট খোলা আছে কিনা যাচাই করুন: সাধারণ পোর্ট, কাস্টম তালিকা, বা সম্পূর্ণ 1-65535 রেঞ্জ।
একটি হোস্ট বা IP লিখুন, সাধারণ পোর্ট, কাস্টম তালিকা বা সম্পূর্ণ রেঞ্জ বেছে নিন, তারপর কোন TCP পোর্ট সাড়া দেয় তা দেখতে স্ক্যান করুন।
সম্পূর্ণ রেঞ্জ স্ক্যানে প্রায় 100 সেকেন্ড পর্যন্ত সময় লাগতে পারে। বড় স্ক্যান (100টির বেশি পোর্ট, কাস্টম রেঞ্জ/তালিকা সহ) প্রতি ভিজিটর প্রতি মিনিটে 1 বার সীমিত।
খোলা পোর্ট (0)
HTTP হেডার ইন্সপেক্টর
কোনো URL-এর HTTP প্রতিক্রিয়া স্ট্যাটাস ও হেডার আনুন।
একটি URL লিখে তার HTTP প্রতিক্রিয়া স্ট্যাটাস কোড এবং সার্ভার থেকে পাঠানো সব রেসপন্স হেডার সংগ্রহ করুন।
SSL / TLS সার্টিফিকেট চেকার
কোনো হোস্টের TLS সার্টিফিকেট পরীক্ষা করুন: ইস্যুকারী, বৈধতার তারিখ এবং বাকি দিন।
একটি হোস্টনাম লিখে তার TLS সার্টিফিকেট পরীক্ষা করুন — ইস্যুকারী, বৈধতার তারিখ এবং মেয়াদ শেষ হওয়ার আগে বাকি দিন।
Geo-IP লুকআপ
কোনো IP ঠিকানার ভৌগোলিক অবস্থান ও নেটওয়ার্ক তথ্য দেখুন। নিজের পাবলিক IP দেখতে খালি রাখুন।
যেকোনো IP ঠিকানা লিখুন, অথবা নিজের ঠিকানা দেখতে খালি রাখুন, এর আনুমানিক অবস্থান ও নেটওয়ার্ক/ISP তথ্য দেখতে।
সম্পূর্ণভাবে আপনার ব্রাউজারে গণনা করা হয় — সার্ভারে কোনো ডেটা পাঠানো হয় না।
নেটওয়ার্ক রেঞ্জ, ব্রডকাস্ট ঠিকানা এবং ব্যবহারযোগ্য হোস্টের সংখ্যা তাৎক্ষণিকভাবে গণনা করতে একটি IP ঠিকানা ও CIDR প্রিফিক্স (যেমন 192.168.1.0/24) লিখুন।
স্পিড টেস্ট
এই সার্ভারের সাথে মৌলিক ডাউনলোড/আপলোড থ্রুপুট পরীক্ষা (নির্ভুলতা সার্ভারের নিজস্ব সংযোগের উপর নির্ভরশীল)।
এই সার্ভারের বিপরীতে ডাউনলোড ও আপলোড গতি মাপতে Start চাপুন। নির্ভুলতা এই সার্ভারের নিজস্ব সংযোগের উপর নির্ভর করে।
দেশের কোড অভিধান
ISO 3166-1 alpha-2 দেশের কোড — সম্পূর্ণভাবে আপনার ব্রাউজারে অনুসন্ধান করা হয়।
ISO 3166-1 alpha-2 দেশের কোডের তালিকা খুঁজুন বা ব্রাউজ করুন, যা সম্পূর্ণভাবে আপনার ব্রাউজারেই অনুসন্ধান করা হয়।
দেশ
ISO কোড
ফোন ডায়ালিং কোড অভিধান
দেশ অনুযায়ী আন্তর্জাতিক কলিং কোড — সম্পূর্ণভাবে আপনার ব্রাউজারে অনুসন্ধান করা হয়।
দেশ অনুযায়ী আন্তর্জাতিক ডায়ালিং কোড খুঁজুন বা ব্রাউজ করুন, যা সম্পূর্ণভাবে আপনার ব্রাউজারেই অনুসন্ধান করা হয়।
দেশ
ডায়ালিং কোড
বিশ্ব ঘড়ি
বর্তমান সময় দেখতে একটি টাইম জোন বেছে নিন — গ্লোব ঘোরাতে টেনে আনুন।
তালিকা থেকে একটি সময় অঞ্চল বেছে নিন, অথবা গ্লোব টেনে, সেখানকার বর্তমান সময় দেখুন।
ফরাসি অপারেটর অনুযায়ী মোবাইল অ্যান্টেনা ও ফাইবার বিভ্রাটের তথ্য ব্রাউজ করুন — কোনো ইনপুট প্রয়োজন নেই, ARCEP-এর সর্বজনীন তথ্য থেকে স্বয়ংক্রিয়ভাবে হালনাগাদ হয়।
উৎস: Arcep, "Sites indisponibles" ডেটাসেট, Licence Ouverte / Etalab 2.0-এর অধীনে প্রকাশিত - বাণিজ্যিক পুনঃব্যবহার স্পষ্টভাবে অনুমোদিত, আগে ব্যবহৃত IODA/CAIDA ডেটার বিপরীতে। Normal/Watch/Alert ব্যাজটি একটি নিজস্ব অনুমান (আজকের বিভ্রাটের সংখ্যা বনাম আগের দিনগুলোর মধ্যক), Arcep-এর সরকারি শ্রেণীবিভাগ নয়। উৎসের লিংক নিচে।
সর্বাধিক প্রভাবিত ডিপার্টমেন্ট
বর্তমানে বিকল বা রক্ষণাবেক্ষণাধীন সাইটের সংখ্যা, ডিপার্টমেন্ট অনুযায়ী। ফিল্টার করতে উপরে একটি অপারেটরে ক্লিক করুন।
অপারেটর অনুযায়ী ফাইবার (FTTH) নেটওয়ার্কের মান: রিপোর্ট করা বিভ্রাটের হার এবং সংযোগ ব্যর্থতার হার, Arcep-এর পাবলিক ডেটা থেকে। মাসিক সূচক, ৬ মাসের গড় - মোবাইল সেকশনের মতো লাইভ ফিড নয়।
উৎস: Arcep, "Qualité des réseaux en fibre optique" ডেটাসেট, Licence Ouverte / Etalab 2.0-এর অধীনে প্রকাশিত - বাণিজ্যিক পুনঃব্যবহার স্পষ্টভাবে অনুমোদিত। উৎসের লিংক নিচে।
অপারেটর অনুযায়ী (মূল কোম্পানি)
গত ৬ মাসের গড়, অবকামো অপারেটরের মূল কোম্পানি অনুযায়ী।
NetChecks শুধুমাত্র বৈধ নেটওয়ার্ক ডায়াগনস্টিকস এবং শিক্ষামূলক উদ্দেশ্যে প্রদান করা হয়েছে, শুধুমাত্র সেসব সিস্টেম, ডোমেইন এবং IP ঠিকানার উপর যা আপনার মালিকানাধীন বা পরীক্ষার জন্য স্পষ্টভাবে অনুমোদিত।
অনুমতি ছাড়া তৃতীয় পক্ষের সিস্টেমের বিরুদ্ধে পোর্ট স্ক্যান, DNS/whois লুকআপ, ট্রেসরুট বা অন্যান্য পরীক্ষা চালানো আপনার এখতিয়ারের কম্পিউটার অপব্যবহার আইন লঙ্ঘন করতে পারে (যেমন যুক্তরাষ্ট্রের Computer Fraud and Abuse Act, ফ্রান্সের "Loi Godfrain", বা সমতুল্য স্থানীয় আইন)। আপনি এখানে প্রবেশ করা যেকোনো লক্ষ্যবস্তু পরীক্ষা করার অধিকার আপনার আছে কিনা তা নিশ্চিত করার দায়িত্ব সম্পূর্ণভাবে আপনার।
এই সাইট এবং এর ফলাফল "যেমন আছে তেমন" প্রদান করা হয়, কোনো প্রকার ওয়ারেন্টি ছাড়াই। এই সাইটের পরিচালক এই সাইট ব্যবহারের ফলে উদ্ভূত কোনো প্রত্যক্ষ, পরোক্ষ বা পরিণামমূলক ক্ষতি, আইনি পরিণতি, বা অপব্যবহারের জন্য কোনো দায় গ্রহণ করেন না।
অপব্যবহার রোধ করতে অনুরোধের হার সীমিত করা হয়। এই ইনস্ট্যান্সের অপারেটর ঐচ্ছিকভাবে অনুরোধ-কার্যকলাপ লগিং সক্ষম করতে পারেন - যদি তাই হয়, প্রতিটি টুল অনুরোধ (আপনার আইপি ঠিকানা, সময়সীমা, ব্যবহৃত টুল এবং প্রবেশ করানো লক্ষ্য/প্রশ্ন) নিরাপত্তা, অপব্যবহার প্রতিরোধ এবং ব্যবহার-বিশ্লেষণের উদ্দেশ্যে একটি ডেটাবেজে রেকর্ড করা হতে পারে। এটি ডিফল্টরূপে নিষ্ক্রিয় থাকে। এই সাইট ব্যবহার করে আপনি এই শর্তাবলীতে সম্মত হচ্ছেন; আপনি সম্মত না হলে, এই সাইট ব্যবহার করবেন না।
এই সাইটের প্রোগ্রামেটিক (এপিআই) ব্যবহারও একই শর্তাবলীর অধীন, উপরের অনুমোদন শর্তসহ।
মতামত পাঠান
একটি সমস্যা রিপোর্ট করুন, মন্তব্য করুন, বা নতুন বৈশিষ্ট্যের পরামর্শ দিন।
এই সাইটটি বিজ্ঞাপন দেখায় এবং আপনি সম্মত হলে, হোস্টিংয়ের খরচ মেটাতে সহায়তার জন্য বিজ্ঞাপন-পার্টনার কুকি ব্যবহার করে। আপনি প্রত্যাখ্যান করতে পারেন এবং সমস্ত টুল বিজ্ঞাপনমুক্তভাবে ব্যবহার চালিয়ে যেতে পারেন।