NextTrace: three flavors and an MTR default on the way

The default output becomes MTR, and not before 2027

The most consequential paragraph in the README is a migration notice addressed to downstream developers. NextTrace will switch the default operating and display mode of `nexttrace` and `nexttrace-tiny` to MTR no earlier than 2027. Using `--raw` alone will switch to MTR RAW at the same time. Traditional traceroute and its RAW output will remain available through `-k/--traceroute`, and programs relying on today's behaviour should adopt `--traceroute` or `--traceroute --raw` now.

Two details matter for planning. This release does not change the default, and the switching release will be announced separately, so there is no version number you can pin to find out. And `ntr` remains MTR-only, so the flavor you choose determines how much of this affects you.

The immediate action is cheap and the cost of doing it later is not: a script that parses today's default output will receive MTR output after the switch.

This repository lags on purpose, and development happens elsewhere

The README asks that pull requests go to NTrace-dev rather than NTrace-core, and then explains the relationship. Both repositories will largely remain consistent with each other. All development work is done within NTrace-dev, which releases new versions first, and after running stably for an undetermined period that version is synchronized into NTrace-core. In the project's own words, NTrace-dev serves as the beta or testing version.

There is an exception, and it is a sensible one. If a version of NTrace-dev encounters a serious bug, NTrace-core will skip that flawed version and synchronize directly to the next version that resolves the issue. So the stable repository is not simply the newer of the two; it is the first one with the bug removed.

The practical consequence for an adopter is that a version released in NTrace-dev may never appear in NTrace-core. The release record here shows v1.7.3 on 2026-08-26, v1.7.4 on 2026-10-11 and v1.7.5 on 2026-10-26, and the last push was on 2026-11-02 with the repository not archived.

Three flavors share one tag, and package managers name them separately

NextTrace is published in three flavors under the same tag, and the command names differ: `nexttrace` for the full build, `nexttrace-tiny` and `ntr`. The install script takes the flavor as an argument, so the full build is:

curl -sL https://nxtrace.org/nt | bash

and the tiny build is the same script with a flag:

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

Package managers expose the same three names, and the README notes that packages can be installed side by side on Debian and Ubuntu:

sudo apt install nexttrace-tiny
sudo apt install ntr

On macOS the Homebrew formula in homebrew-core provides only the Full flavor, `brew install nexttrace`, while the `nxtrace/nexttrace` tap provides all three. The README also warns that the homebrew-core build, maintained by chenrui333, may lag behind the repository's automatically tagged release. Whether you need the tap or the core formula is therefore a question about how current you need to be.

Twelve architectures in the APT repository, and one elsewhere

The Debian and Ubuntu route is the recommended one, and it is the only official package source. The `nexttrace-debs` APT repository supports `amd64`, `i386`, `arm64`, `armel`, `armhf`, `loong64`, `mipsel`, `mips64el`, `ppc64el`, `riscv64` and `s390x`, maintained by nxtrace and wcbing. Everything else in the install list is volunteer work, and the README says so: other package sources above are maintained by open-source enthusiasts, and availability and timely updates are not guaranteed.

The contrast is sharpest on Arch, where both AUR options are amd64 only, `yay -S nexttrace-bin` for a binary package and `yay -S nexttrace` to build from source, maintained by ouuan and huyz. So on Arch, a non-amd64 machine has no AUR option.

The remaining entries are one-liners: `apt install nexttrace` for deepin, `x env use nexttrace` for x-cmd, `pkg install root-repo` followed by `pkg install nexttrace` for Termux, and `opkg install nexttrace` for ImmortalWrt.

Windows support is experimental for a stated reason

The manual install section gives the reason plainly: some essential dependencies of this project are not fully implemented on Windows by Golang, so NextTrace is currently in an experimental support phase on the Windows platform.

That is a dependency problem rather than a policy decision, and it shapes the Windows story. Two package sources exist, `winget install nexttrace` maintained by Dragon1573, and `scoop bucket add extras && scoop install extras/nexttrace` maintained by soenggam, both under the caveat that community-maintained sources are not guaranteed to be available or up to date.

For everyone else the manual route is precompiled binaries from the downloads page, which the README says covers many systems and different architectures, with compiling it yourself as the fallback. The repository carries `.cross_compile.sh` at the root, so cross-compilation is part of the build rather than an afterthought.

A web interface and an MCP SDK are both direct dependencies

The dependency list is wider than a traceroute needs, and the directory list explains why. There is a `server/` directory, `gin-gonic/gin` and `gorilla/websocket` are direct dependencies, and `wshandle/` suggests the web side of that server.

Alongside them sit protocol libraries that show what the tool talks to: `quic-go` for QUIC, `miekg/dns` and `dnscrypt/v2` for DNS, `ameshkov/dnscrypt/v2` and `jedisct1/go-dnsstamps` for DNS stamps, `sthorne/odoh-go` for ODoH, and `jsdelivr/globalping-cli` for the Globalping measurement API. `modelcontextprotocol/go-sdk` at v1.8.0 is a direct dependency, which means this project speaks MCP rather than merely being adjacent to tools that do.

Platform and data libraries are there too: `xjasonlyu/windivert-go` for packet capture on Windows, `oschwald/maxminddb-golang` for GeoIP lookups, `google/gopacket` for packet handling, and `rodaine/table` for table rendering, with `natesales/q` also listed. `go.mod` names the module `github.com/nxtrace/NTrace-core` and requires go 1.27.3, with `benchstat` declared as a tool dependency.

The install script is a curl piped into bash, and one sponsor list pays for the probes

The one-click install on Linux, macOS and BSD has one shape: fetch a script from nxtrace.org and hand it to a shell. That is convenient and it means the trust decision is about the URL, not about a package signature.

For the Debian and Ubuntu route the trust story is better, because the APT repository is signed with a keyring you install into `/etc/apt/keyrings` and referenced by a `Signed-By` line in a `.sources` file written to `/etc/apt/sources.list.d/nexttrace.sources`. That is the route the README calls recommended.

The running costs are covered by sponsors rather than by users: DMIT, Misaka and SnapStack are thanked for providing the network infrastructure that powers the project. The repository root also carries `nt_config.yaml`, `nt_install.sh`, `geofeed.example.csv` and `ptr.example.csv`, which are the configuration and data files a route tracer needs for GeoIP and reverse delegation data.

Editorial conclusion

Adopt NextTrace if you want a visually rich traceroute with an MTR mode on the way and you want the official APT repository rather than a volunteer-maintained package. Do not adopt it if your scripts parse today's default output, because that changes no earlier than 2027. Before wiring anything up, add --traceroute or --traceroute --raw to anything that depends on classic traceroute behaviour, and note that Windows support is still experimental.

Frequently asked questions

Official sources

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