Check-Host.cc

Advanced Settings
Show world map

Check MTR fi-hel-aluy.check-host.eu

Permanent link |
AL
Albania, Tirana Keminet SHPK · AS197706
AU
Australia, Sydney Onidel Pty Ltd · AS152900
BA
Bosnia and Herzegovina, Novi Travnik Globalhost · AS200698
BG
Bulgaria, Sofia Julian Achter(Aluy) · AS211507
CA
Canada, Montreal OVH SAS · AS16276
CH
Switzerland, Bern Julian Achter(Aluy) · AS211507
CL
Chile, Santiago Google LLC · AS396982
CN
China, Hohhot Alibaba Cloud · AS37963
DE
Germany, Nuernberg Hetzner Online GmbH · AS24940
DE
Germany, Frankfurt am Main GHOSTnet GmbH · AS12586
DE
Germany, Frankfurt am Main Lumaserv · AS200303
DE
Germany, Limburg OVH SAS · AS16276
DE
Germany, Frankfurt am Main Marc Fischer - Packets-Decreaser · AS214243
DE
Germany, Duesseldorf Justin Franke · AS204464
DK
Denmark, Glostrup Municipality Glesys AB · AS42708
ES
Spain, Bilbao 24racks Cloud S.L. · AS214340
FI
Finland, Helsinki Julian Achter(Aluy) · AS211507
FI
Finland, Helsinki FlokiNET ehf · AS200651
FR
France, Gravelines OVH SAS · AS16276
FR
France, Paris DataCamp Limited · AS212238
GB
United Kingdom, London ABR Hosting · AS203758
GE
Georgia, Tbilisi Cloud 9 Ltd. · AS57814
GR
Greece, Athens OTEnet · AS6799
HK
Hong Kong, Hong Kong Offshore LC · AS214472
HR
Croatia, Zagreb cyber_Folks d.o.o · AS201563
HU
Hungary, Budapest M247 Europe SRL · AS9009
ID
Indonesia, Jakarta Google LLC · AS396982
IL
Israel, Petach Tikwa CLOUD LEASE Ltd · AS206446
IL
Israel, Netanja CLOUD LEASE Ltd · AS206446
IN
India, New Delhi Google LLC · AS396982
IS
Iceland, Reykjavik (Miðborg) FlokiNET ehf · AS200651
IT
Italy, Como LAKENETWORKS · AS6517
KW
Kuwait, Kuwait City Gulfnet Communications · AS3225
LT
Lithuania, Pilaite Informacines sistemos.. · AS61272
LV
Latvia, Riga Orion Network Limited · AS41564
MD
Moldova, Chisinau Trabia SRL · AS43289
NL
Netherlands, Amsterdam Julian Achter(Aluy) · AS211507
NL
Netherlands, Amsterdam FlokiNET ehf · AS200651
NL
Netherlands, Amsterdam Trivox, NL · AS216078
NL
Netherlands, Amsterdam Joel Krause · AS200912
NO
Norway, Oslo ServeTheWorld AS · AS34989
PL
Poland, Warsaw F.N.S. HOLDINGS LTD · AS206092
RO
Romania, Bacău ITITAN HOSTING · AS214062
RO
Romania, Bucharest FlokiNET ehf · AS200651
RS
Serbia, Belgrade AltusHost B.V. · AS51430
RU
Russia, St Petersburg LLC Baxet · AS51659
SG
Singapore, Singapore FDCservers · AS30058
TR
Turkey, Istanbul Netlen Internet · AS44620
TW
Taiwan, Taipei Beidou LTD · AS152611
US
United States, Miami Ohz Digital SL · 202673
US
United States, Dallas Linceris International Cloud · AS201129
US
United States, Kansas City Advin Services LLC · AS22295
US
United States, Dallas Ipxo LLC · AS396993
ZA
South Africa, Johannesburg Google LLC · AS396982

Global MTR (My Traceroute) & Routing Diagnostic Tool

MTR works by sending packets with incrementing TTL values. The first packet expires at the first router, the second at the second, and so on — each router that drops a packet sends back an ICMP time-exceeded message that reveals its address and latency. The result is a hop-by-hop map from the probe node to your destination, with latency and packet loss measured at each step.

Hop-by-Hop Packet Loss and Latency

Ping only tells you whether the destination answered and how long it took. MTR shows you every router on the path in between. If the 8th hop out of 14 suddenly shows 40% packet loss and higher latency, and all subsequent hops look normal, the problem is almost certainly at that specific router or the link immediately after it — not at your server. That level of precision cuts diagnosis time significantly compared to ping alone.

BGP Routing and Suboptimal Paths

BGP selects routes based on AS path length and local policies, not physical distance or link speed. Traffic from one country to another sometimes crosses unexpected continents because of peering agreements between carriers. Running MTR from multiple locations reveals whether different ISPs take different paths to the same destination, and whether any of those paths are significantly longer or more congested than they should be.

Reverse DNS (PTR) Resolution

Each hop IP is resolved to a hostname via reverse DNS. Carrier hostnames often encode the location and provider — something like "ae-3.r21.frnkge04.de.bb.gin.ntt.net" tells you this is NTT's backbone in Frankfurt. This makes it straightforward to identify which transit provider owns each segment of the path. One thing to keep in mind: a hop showing 100% loss while subsequent hops respond normally is almost always ICMP rate-limiting, not a real outage — the router is forwarding traffic fine but deprioritizes generating TTL-exceeded replies.