Neqo's server is marked do not use in production

The client is in Firefox, the server carries a written warning

Neqo is the QUIC implementation used by Mozilla in Firefox and other products, written in Rust, providing a library for QUIC transport, HTTP/3 and QPACK. It is designed to be used in Firefox but can also be used standalone, and command line tools for testing and debugging are included, neqo-client and neqo-server. The status of those two tools is not equal, and the README is unusually direct about it. The server functionality is experimental, is not in production use at Mozilla, and is not as mature as the client functionality. It is intended to be standards-compliant when interoperating with a compliant client, but may not implement all optional protocol features and may not handle all edge cases. It is not optimized for performance or resource usage, and while it implements many necessary features for a server it does not include configuration of a number of options suited to a live deployment. The instruction at the end is in bold: do not use the neqo server code in production. The newest published build is v0.32.0 from 2026-09-25, after v0.31.1 in September and v0.31.0 in August.

The TLS backend is NSS, not a Rust TLS stack

The security backend is the Mozilla NSS library, the same one Firefox uses, and that single sentence decides who can build this. A Rust developer whose services use rustls, or who has no NSS development packages available, has an extra dependency to solve before anything compiles. The build instructions assume it in the simplest case: cargo build uses a system-installed NSS library if it is new enough, and there is a separate documented path for when NSS is not installed or is deemed too old. For anyone evaluating this as a general-purpose QUIC library rather than a Firefox component, that is the first question to answer, because the alternative is reimplementing or replacing the security backend, which is most of the work.

Building against a private NSS checkout takes five documented steps

The separate NSS and NSPR path is the longest part of the README and is worth following in order rather than improvising. First, clone NSS and NSPR into the same directory and export NSS_DIR pointing at NSS, for example NSS_DIR=$HOME/neqo-dependencies/nss. Second, if NSS has not been compiled separately you need Mercurial, and NSS builds require GYP and Ninja. Third, run cargo build in the neqo checkout, where the prior steps let the build use the existing NSS build or build it from the checkout if it has not been built yet. Fourth, and this is the step people miss, you then have to point the dynamic loader at the library you just built:

export LD_LIBRARY_PATH="$(find $NSS_DIR/.. -name libssl3.so -print | head -1 | xargs dirname | xargs realpath)"

on Linux, with the macOS equivalent using DYLD_LIBRARY_PATH and libssl3.dylib. Fifth, optionally set NSS_PREBUILT=1 so later cargo build invocations skip rebuilding NSS.

Six crates, patched into Gecko by path

Neqo is not one crate, and the README shows exactly which ones Gecko depends on. The patch block in a Gecko checkout root Cargo.toml lists neqo-bin, neqo-common, neqo-http3, neqo-qpack, neqo-transport and neqo-udp, each pointed at a local path:

[patch."https://github.com/mozilla/neqo"]
eqo-bin = { path = "/home/alice/git/neqo/neqo-bin" }
eqo-common = { path = "/home/alice/git/neqo/neqo-common" }
eqo-http3 = { path = "/home/alice/git/neqo/neqo-http3" }

The full example lists all six. After editing, you run ./mach vendor rust and then compile as usual with ./mach build. The caveat that follows is the one to keep in mind when experimenting with in-development code: using newer Neqo code with Gecko may also require changes, in neqo_glue, if something has changed. That coupling is the cost of working inside the browser's build, and it is why the patch approach is framed as trying in-development code rather than as a supported integration path.

Three debugging channels: qlog, key log, and RUST_LOG

QUIC problems surface in three different places, and the debugging section is split to match them. The first is QLOG generation, enabled with --qlog-dir on either tool, and the files can be uploaded to qvis to visualize the flows. To export QLOG for Neqo Simulator runs from test-fixture/src/sim you set the QLOGDIR environment variable instead, with the example QLOGDIR=/tmp/qlog cargo bench --bench min_bandwidth --features bench. The second is packet capture: setting SSLKEYLOGFILE to a filename tells NSS to dump keys in the standard format so Wireshark and other tools can decrypt the traffic. The third is Rust logging, where RUST_LOG selectively enables messages as documented in the env_logger documentation. It works for the command line tools and also when Neqo is incorporated into Gecko, although Gecko has to be built in debug mode for it.

Running the test tools against each other, and against Firefox

The simplest loop is the two binaries talking to each other. Build with cargo build, start the server on an address, then point the client at it:

./target/debug/neqo-server '[::]:12345'
./target/debug/neqo-client 'https://[::]:12345/'

The bracketed IPv6 form is what the README uses. To involve the real browser, you run the server with cargo run --bin neqo-server -- 'localhost:12345' and then set two Firefox preferences under about:config: network.http.http3.alt-svc-mapping-for-testing to localhost;h3=":12345", and the related preference that tells Firefox to enable HTTP/3. That pair is a testing override rather than a configuration a user would ever set, which is the point: it lets you point the shipping browser at a local server without touching its certificate trust or version negotiation behaviour.

Where Neqo is the wrong choice

Four cases. The first is a production QUIC server, which the README forbids in bold and backs up with three reasons: not in production use at Mozilla, not optimized for performance or resource usage, and missing the configuration options a live deployment needs. The second is a Rust service that already standardizes on rustls or another pure-Rust TLS stack, because Neqo requires NSS and that is a system dependency rather than a Cargo feature. The third is a developer who only needs HTTP/3 client behavior in tests. Neqo ships its own client, server, qlog export, key log integration and a browser patch workflow, which is a lot of machinery when an ordinary HTTP client with HTTP/3 support would answer the question. The fourth is a team that wants to stay current with QUIC without tracking Gecko. Neqo is a Firefox component first, and the coupling to neqo_glue means that in-development code can require changes on the Firefox side, so the dependency you inherit is on both.

Editorial conclusion

Neqo suits a Rust developer who needs to test or embed a QUIC and HTTP/3 client with the same stack Firefox uses, or a Firefox developer working inside a Gecko checkout with mach. It does not suit anyone looking for a production QUIC server, which the README rules out in bold. Before adopting, decide whether your build can link NSS, follow the separate NSS and NSPR checkout steps if you have no suitable system library, and stay on the client side unless you have read that experimental notice in full.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mozilla/neqo on GitHub
3. Project website
4. README
5. Releases