MyIP.dogChecking…
Online traceroute
Inspect route hops to a public target from a named remote Globalping probe, including missing replies.
Checking…
Inspect route hops to a public target from a named remote Globalping probe, including missing replies.
Checking…
Checking…
This starts a remote Globalping measurement. Your target and results are public and may remain available for up to six months. Use a target you are authorized to test.
One remote probe. TCP uses port 443; UDP uses the provider’s default traceroute settings. Shared service limits apply.
No remote measurement has started.
An online traceroute asks a remote probe to collect replies associated with successive hops toward a public target. Enter an IP address or hostname, choose the address family, protocol, and probe region, then start the test. MyIP.dog uses one Globalping probe for each run. The resulting path starts at that probe's network. It does not describe the route from your browser, home router, or current VPN exit.
Use online traceroute when you need an external view of a destination's path. It can help compare observations from different regions or add route context to a reachability problem. Read the actual probe city, country, and network in the result. The requested continent is a selection constraint, while those returned fields identify the origin used for this particular measurement. A later run may use a different probe.
The online traceroute form accepts public IPv4 or IPv6 addresses and ordinary public hostnames. Do not include a URL scheme, port, path, or private network address. The example button fills a public resolver address without starting a test. Review the settings and public-results disclosure before submitting. Use a destination you are authorized to diagnose, and avoid putting confidential internal names into a public measurement workflow.
When you enter a hostname, our server resolves the chosen family through Google Public DNS. It follows the relevant alias chain, validates the matching address records, and selects one supported public address. Online traceroute then receives that literal address as its target. Both the entered name and tested address remain visible. This makes the selected destination explicit, although it may differ from an address chosen by your browser's resolver.
Select IPv4 for an IPv4 literal and IPv6 for an IPv6 literal. A name with no usable record in the chosen family cannot start this online traceroute. Check its A and AAAA records with DNS lookup before changing unrelated network settings. This service rejects unsupported special-use targets and a hostname response containing unsuitable addresses in the selected answer set rather than probing them opportunistically.
Online traceroute supports ICMP, TCP, and UDP. TCP uses port 443; UDP uses the provider's default traceroute settings. There is no arbitrary port control in this interface. Protocol choice affects how routers and destinations handle probes, so record it with your results. A path that returns more replies for one protocol does not automatically mean the other protocol is broken for ordinary application traffic.
Keep the target and protocol stable for a meaningful comparison. If you change the region, address family, and protocol simultaneously, a different online traceroute result has several possible explanations. The form uses one probe per run and does not continuously refresh or launch new measurements automatically. Start a new test only when it answers a specific question about the symptom you are investigating.
The result includes the entered target, tested address, selected protocol, target-resolution method, requested region, and latest timestamp. It identifies the actual probe network and provides a link to the public Globalping response. Keep this context attached to your online traceroute. A list of addresses without its origin, target, protocol, and time loses much of its diagnostic value.
Each online traceroute row represents a reported hop position. The table preserves positions that have no returned address or timing, instead of closing gaps and renumbering later replies. The hop number is not a distance in kilometers. Addresses can identify replying interfaces, and returned hostnames are operator-supplied labels. Neither establishes a router's precise location, ownership of every traversed link, or a complete physical topology.
The normal mechanism uses limited packet lifetimes and replies from devices along the route. For IPv4 this involves TTL; IPv6 uses a hop limit. However, an online traceroute only displays what the selected method and surrounding networks make observable. Tunnels, load balancing, filtering, and differing reply paths can complicate the picture. Avoid drawing a precise geographical line between every displayed address as if it had been directly measured.
The timing values in online traceroute are round trips between the remote probe and responding hops. They are not measured delays on the single link between adjacent rows. Subtracting one row from the next can be misleading because the replies can experience different handling or return paths. A later row can legitimately have a lower reported round-trip value than an earlier one.
For example, suppose a hypothetical online traceroute has a slow reply at an intermediate hop, followed by faster replies and a responsive destination. That observation alone does not show that the intermediate router delays forwarded application traffic by the same amount. It may handle diagnostic replies differently. Investigate persistent behavior at later hops and the application itself before attributing a fault to a specific router.
“No reply” in online traceroute means the corresponding evidence is absent from the received result. A router may forward traffic while declining, filtering, or rate limiting diagnostic responses. A gap can therefore appear before later responding hops. We retain that gap and describe it explicitly. We do not replace it with an invented address or declare the entire route unusable.
The interface also states whether the exact tested address appears among reported hops. If it has not appeared, online traceroute has not established that the target replied as a listed hop. This could reflect incomplete collection, filtering, measurement limits, or other conditions. It does not by itself establish a website outage. Check the collection and probe statuses before treating a partial path as the final result.
Online traceroute may return partial hop information while the provider continues measuring. The interface updates available results without submitting another test. A finished collection can contain a failed or unavailable probe, so read the probe outcome as well as the collection status. If an unsupported status appears, the interface preserves the source link and identifies the uncertainty instead of assigning a success label.
Local collection has a 50-second deadline after creation. Stop waiting ends that collection while preserving information already received. Clear result removes the visible report. Neither control cancels an online traceroute at Globalping or deletes its public result. If the submission response is interrupted, the remote job may still exist even when we cannot display its identifier. Do not assume that closing a tab retracts a submitted measurement.
An online traceroute is one remote observation, not a map of every user's path. Its probe can have different transit providers, peering arrangements, and policy from your own network. Even two probes in the same city can produce different observations. Use the actual network and address family when comparing reports. Repeating a broad continent selection does not guarantee a controlled experiment with a fixed origin.
A public service can use the same address at multiple deployments. Online traceroute from different regions can therefore reach different infrastructure without the IP literal changing. Routes and response policies can also change over time. Save the timestamp and intended question, and compare an appropriately small number of runs. Do not turn a single sample into a permanent statement about where a service is hosted.
Online traceroute does not directly measure the reverse path taken by application traffic, the bandwidth available on each link, or whether an HTTPS transaction succeeds. It cannot expose every hop inside a tunnel. It also cannot prove that a VPN protects every application. For browser-visible exit addresses, use IP comparison. For a short remote reply sample, use the ping test. Those observations complement rather than replace the route report.
Begin with the failing action, affected network, target hostname, and time. Check name resolution and identify the address your application actually uses. Run online traceroute toward that address in the relevant family, keeping the protocol explicit. Compare the remote origin with a local diagnostic when the problem affects your own connection. Preserve working observations as well as failures so another person can see the scope of the difference.
On Windows, the documented tracert command can collect a local route observation. Its behavior and settings need not match this online traceroute exactly. Clearly label which report came from your machine and which came from a remote probe. When asking an ISP or service operator for help, include the symptom and timing rather than presenting an isolated unanswered hop as definitive proof of their fault.
Globalping targets and results are public and may remain available for up to six months. An online traceroute can include router addresses, returned names, and network information. The entered hostname also reaches Google Public DNS when resolution is required. Read the disclosure before starting and review copied reports before sharing them. Clearing the local display does not remove upstream data or copies another person has already obtained.
This online traceroute has bounded requests and shared usage limits. If the service is busy, a region has no suitable probe, or a rate limit is reached, the interface reports the condition. It does not reinterpret provider unavailability as target failure. Wait before another attempt. Automatic creation retries are disabled because a request with an uncertain response may already have started a public measurement.
A public target's observed route can contain replies bearing private addresses. Rejecting private destinations does not mean every intermediate reply must carry a public address. Online traceroute preserves valid reported hop addresses to avoid deleting evidence. Such a row does not mean the tool scanned your home network, nor does it identify the private router as belonging to your device's connection.
No single row reliably identifies link capacity or forwarding delay. Online traceroute measures replies from its remote origin, and routers may prioritize those replies differently from forwarded packets. Investigate patterns across later hops, repeated controlled observations, and actual service behavior. A network operator may need counters, routing information, and application logs that a public browser tool cannot access.
Yes. Copy report preserves the collection state and any observations already received, along with the target, actual probe, and source link. Describe a stopped online traceroute as partial. The public source may later contain additional results, so distinguish the copied snapshot from the provider's current response. This allows another person to understand why two views of the same measurement differ.
Online traceroute here follows the Globalping measurement API and its response schemas. ICMP message behavior is defined in RFC 792 and RFC 4443. Hostname selection uses Google Public DNS. Read our methodology for evidence limits, or use ASN lookup to investigate a public address's observed routing context without assuming it identifies an individual subscriber.