NextTrace: a Go traceroute that annotates every hop with ASN and geolocation

What NextTrace adds to a plain traceroute

A vanilla traceroute prints a list of IP addresses and round-trip times. That list tells you a packet left your machine and where it stopped, but not who operates each hop or where that hop sits. NextTrace keeps the traceroute mechanics and attaches identity to each line: the repository lists asn-lookup, geoip, geolocation and as-path among its topics, and the Go module pulls in maxminddb-golang for reading MaxMind-format databases. The audience is narrow on purpose. If you are debugging why traffic from a Frankfurt VPS reaches a Tokyo endpoint through an unexpected transit provider, the AS number of hop seven is the fact you need, and NextTrace is built to print it. Someone who only wants to know whether a host is reachable should use ping, not this.

How the trace, lookup and printer layers fit together

The repository layout separates concerns more than a single-file traceroute clone would. Top-level directories include trace/, fast_trace/, tracelog/, tracemap/, printer/, ipgeo/, reporter/ and util/, with cmd/ holding command wiring and config/ plus nt_config.yaml holding configuration. That split suggests the trace engine emits hop records, the ipgeo layer resolves them against geolocation and ASN data, and the printer layer decides how they reach the terminal. The dependency list backs this reading: miekg/dns and the dnscrypt, odoh-go and go-dnsstamps packages point at DNS resolution options, gopacket and windivert-go point at raw packet capture, and charmbracelet/log plus fatih/color and rodaine/table point at terminal rendering. The Go module also depends on jsdelivr/globalping-cli and modelcontextprotocol/go-sdk, so the binary carries more than one output path. The README does not document the internal interfaces between these packages, so treat the directory names as a map of intent rather than a specification.

Installing NextTrace and running a first trace

On Debian and Ubuntu the README recommends the project's own APT repository, which supports amd64, i386, arm64, armel, armhf, loong64, mipsel, mips64el, ppc64el, riscv64 and s390x. The block below adds the signing key, registers the repository and installs the default package.

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL -o /tmp/nexttrace-archive-keyring.gpg https://github.com/nxtrace/nexttrace-debs/releases/latest/download/nexttrace-archive-keyring.gpg
sudo install -m 0644 /tmp/nexttrace-archive-keyring.gpg /etc/apt/keyrings/nexttrace.gpg
rm -f /tmp/nexttrace-archive-keyring.gpg
printf '%s\n' 'Types: deb' 'URIs: https://github.com/nxtrace/nexttrace-debs/releases/latest/download/' 'Suites: ./' 'Signed-By: /etc/apt/keyrings/nexttrace.gpg' | sudo tee /etc/apt/sources.list.d/nexttrace.sources >/dev/null
sudo apt update
sudo apt install nexttrace

After that, apt install nexttrace-tiny and apt install ntr add the other two flavors. The README states all three packages can be installed side by side and expose the commands nexttrace, nexttrace-tiny and ntr.

On Linux, macOS and BSD outside Debian, the one-click script installs the Full flavor by default. The flavor flag selects the others.

curl -sL https://nxtrace.org/nt | bash
curl -sL https://nxtrace.org/nt | bash -s -- --flavor tiny
curl -sL https://nxtrace.org/nt | bash -s -- --flavor ntr

macOS users can use Homebrew instead. The homebrew-core formula provides the Full flavor, while the nxtrace/nexttrace tap provides all three; the README notes the homebrew-core build may lag behind the repository's automated versioning.

brew install nexttrace
brew tap nxtrace/nexttrace
brew install nxtrace/nexttrace/nexttrace
brew install nxtrace/nexttrace/nexttrace-tiny
brew install nxtrace/nexttrace/ntr

On Windows, WinGet and Scoop both carry it.

winget install nexttrace
scoop bucket add extras && scoop install extras/nexttrace

For a first real run, trace a host you control rather than a random public address, so you can tell whether a missing ASN is your problem or the project's. The README's migration notice names the flags that matter: -k/--traceroute selects traditional traceroute, and --raw selects raw output. Because the default mode is scheduled to change, pass the mode explicitly from the start.

The default-mode change is the biggest thing to plan around

A notice near the top of the README states that NextTrace will switch the default operating and display mode of nexttrace and nexttrace-tiny to MTR no earlier than 2027, and that using --raw alone will switch to MTR RAW at the same time. Traditional traceroute and its raw output stay reachable through -k/--traceroute. The README explicitly tells downstream developers to adopt --traceroute or --traceroute --raw now, and says the release that flips the default will be announced separately. This is the clearest limitation in the project. Any script that parses nexttrace output without pinning a mode is building on a default that the maintainers have already said will move. The notice also says ntr remains MTR-only, so the three flavors do not share one behavior. If your pipeline cannot tolerate a format change, pin the flag today; if you cannot pin it, this is the wrong tool for that pipeline.

Two repositories, and which one you are actually reading

The README asks contributors to send pull requests to NTrace-dev rather than NTrace-core, and explains the split: all development happens in NTrace-dev, new versions appear there first, and after an undetermined period of stability a version is synchronized to NTrace-core. NTrace-dev is described as the beta or testing repository. There is a stated exception: if a NTrace-dev version hits a serious bug, NTrace-core skips it and synchronizes to the next version that fixes the issue. The practical consequence is that the release numbers on NTrace-core lag NTrace-dev by an unknown amount, and the README does not give a schedule. If you need the newest behavior, you are choosing to run what the project itself calls a testing version. If you need the synchronized one, you accept the lag. The README does not document a rollback path for either.

Where NextTrace is the wrong choice

NextTrace assumes it can send probe packets and receive replies, which is why the dependency list includes gopacket and, on Windows, windivert-go. On a host where you cannot get the privileges raw sockets need, or on a network that drops the ICMP and UDP responses traceroute relies on, the hop list will be short and the ASN annotations mostly absent. That is a property of probing, not a defect in the code, but it makes the tool useless for a purely passive question such as what routes a provider advertises. For that, you want a looking-glass or an MRT dump, not a traceroute. A second boundary is the licensing: the project is GPL-3.0, so redistributing a modified binary carries source obligations that a permissively licensed traceroute does not. Teams embedding route tracing inside a closed product should read the licence text before building on it. Finally, the README does not document a stable machine-readable schema for the human-facing output, which is exactly why the migration notice tells parsers to pin a mode.

How NextTrace differs from mtr and from Globalping

mtr is the obvious comparison, and the project's own roadmap concedes the point: the default mode is heading toward MTR. The difference today is the annotation layer. mtr is a long-running statistical view of loss and latency per hop; NextTrace is a one-shot trace whose value is the ASN, geolocation and AS-path attached to each hop. If your question is whether a link is flapping, mtr's continuous statistics answer it better. If your question is which autonomous system a hop belongs to, NextTrace is built for that and mtr is not. The second alternative is visible in the dependency list rather than the README: the Go module requires jsdelivr/globalping-cli, the client for Globalping, a distributed measurement network. Globalping runs the probe from machines you do not own and returns results from that vantage point; NextTrace runs from wherever you invoked it. If you need a view from a network you have no access to, a distributed measurement platform is the right shape, and a local CLI is not.

Maintenance, licence and what a version bump costs you

The last push to NTrace-core was on 2026-09-17, and the most recent release listed is v1.7.3 from 2026-08-26, following v1.7.2 on 2026-08-13 and v1.7.1 on 2026-06-16. The repository is not archived. Upgrades differ by channel: the APT repository and the nxtrace/nexttrace Homebrew tap are described as synchronized from the latest NTrace-core release, while the README warns that other package sources are maintained by open-source enthusiasts and that availability and timely updates are not guaranteed, telling users to contact the repository maintainers if problems arise. The homebrew-core build is called out as potentially lagging. That means your upgrade cost depends on which channel you chose, and the README gives no deprecation policy for flags beyond the migration notice. On licensing, GPL-3.0 governs the code; the README does not discuss commercial use or dual licensing, so anyone redistributing a modified build should read the licence text themselves rather than assume a permissive grant.

Editorial conclusion

Adopt NextTrace if you want hop-level ASN and geolocation without standing up a web UI: install it from the nexttrace-debs APT repository or Homebrew, then run it against a host you control. Skip it if you need a stable default output format for a parser you will not touch again, because the README states the default mode of nexttrace and nexttrace-tiny moves to MTR no earlier than 2027 and --raw follows it. Before wiring it into anything, run the same target twice, once with -k/--traceroute and once with --raw, and diff the two outputs so you know which shape your tooling depends on.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. nxtrace/NTrace-core on GitHub
3. Project website
4. README
5. Releases