Supports MTR, flyingroutes and of course, traceroute.
The existing solutions were too limited so I made that.
Let me know if you have any feedback
Its already kind of nebulous, what with MPLS no-decrement-ttl and tunneling protocols.
Add to that geo ip is often fantastically wrong. Especially if the ISP has no need for it for its own troubleshooting. They might not go out of their way to update geoip correctly, relying on the routers hostname for information.
Blowing it up to display it on a map and pretend like the data returned from traceroute is aligned with reality rubs me the wrong way.
I manage approximately 1,200 PoPs that are part of IPinfo's ProbeNet platform, which is used to generate our internet measurement data. We, in turn, use this data to produce the IP geolocation data you utilize. The issue is that the servers we manage can be moved to different locations or not be in the advertised locations. We operate these PoPs across 500 cities.
Whenever the PoP fails to meet certain physical location checks, I run basic diagnostic tests to determine where the server is located and where it is not. Aside from running ping and traceroute operations to the target servers, I can run traceroutes to certain IP addresses whose paths I am familiar with. A traceroute visualizer provides a visual interface, information on the ASN, the geolocation, and the time measurements. This provides an intuitive view of where the server "could not be" located rather than could be located. We use several techniques to run basic diagnostic tests. This traceroute visualizer isn't an official test of IPinfo; it is something I vibe-coded together. There are far better internal tools, such as running ping and traceroutes across all of our ~1,200 servers simultaneously.
It is a network diagnostic tool. I think based on your comment, it is not just a tool, it is more of an abstraction of a tool! But it is somewhat useful I thinkl.
I am happy to hear your thoughts. I manage these servers and we are trying our best to improve our data consistently. So, any ideas or even random thoughts you might have can help us improve.
And for whatever reason, copy and paste on the page is flakey and required several retries on my iPhone running iOS 26.
Should be noted that IPInfo doesn't get blocked with tracking protection set to "standard". Users have to set tracking protection to "strict" to run into this issue. When they do this, they get warned that this setting may break sites.
I don't think Mozilla/Disconnect will make an exception because privacy-infringement is a potential risk with a service like yours if used by malicious websites. I wouldn't put too much effort into this, the people affected by this are a fraction of a fraction of the general web audience and they've already seen a warning that websites may break because of their choice.
edit: They updated from phishing to "computer and internet info" , no longer blocked.
auto-detected my IPv4 addy, but my tracert to google.com went over IPv6.
I'm pretty skeptical about being able to geolocate router interfaces from IP addresses, so I was curious about the output. My expectations were low but they were too high. Oh well.
You can even use a whole bunch of fuzzy rough estimations for endpoints in a region to get progressive increments in resolution until you're happy with a precise location. You can also use educated guesses about the type of router at each hop, then use response times and behaviors for pings coming from different directions at different times. If you can arrange to traverse a node and pump traffic over it, you can use behavior with different types of traffic to elicit the type of router, the policies in place, and so on.
It's a good idea to turn off responses to pings and minimize the amount of information available, even if it seems mostly harmless. The amount of information you can get from the public internet, just in terms of basic network utility functions and behaviors, is probably a lot more than most people ever consider.
You could do the long list of things you listed. Has anyone done a high-quality implementation of those things? And checked the results? I’d be interested in seeing that.
I think the cable company is a bit more refined, I see cities in traceroutes that don't make sense for the whole metro area to route through, so it's likely that you can determine county, and possibly more specific. But you won't get any useful information from trying to ping outside resources; ISP networks all interconnect at the local internet exchange (or there about), when I had access to a DSL, a cable, and a local fiber ISP all in the same city, pings all went back to the IX. Maybe if you have a lot of presence in an ISP, you can gather a bit more data about users in that ISP, but it won't help you gather data about users on other ISPs.
Disabling pings is nice and all, but if you exchange any traffic, round trip times are pretty easy to gather from that. Delayed ack ads a bit of a challenge, but not much.
Of course, many isps offer geofeeds for their IPs. That's pretty reasonable to use if offered.
For IPv4, the geolocation information is quite limited (city-level) so if you live close to a major data center, you'll have a distance of 0 on the map.
Still, seeing the routes on the map is kind of fun. I don't think it provides anything useful in terms of troubleshooting that mtr doesn't provide already, but there's a fun novelty to see your traces on a map like in a 90s hacker movie.
If you're looking to trace to something far away when doing a demo we've got servers in ~280 cities around the world so <random large city>.wonderproxy.com works. e.g. taipei.wonderproxy.com or santiago.wonderproxy.com, berlin, newyork, etc.
edit: edited my windows traceroute to match the linux format and it works nicely. great tool.
