quic-go keeps QUIC in the root package and HTTP/3 in http3/

The transport sits in the root package, HTTP/3 in http3/

quic-go implements QUIC (RFC 9000, RFC 9001, RFC 9002) and HTTP/3 (RFC 9114) in Go, with no cgo in the picture, so a service can depend on it without a C toolchain or a system QUIC library. It targets Go programs that need to be a QUIC client or a QUIC server: HTTP/3 origins, proxies, tunnels, anything that today opens TLS over TCP and wants a different transport underneath.

The split between the transport and the HTTP layer is visible in the file names at the repository root. connection.go, framer.go and buffer_pool.go carry the connection and the frame layer. flow_controller_base.go, flow_controller_connection.go and flow_controller_stream.go split credit accounting per connection and per stream, frame_sorter.go reassembles frames that arrive out of order, crypto_stream.go and crypto_stream_manager.go hold handshake material, conn_id_generator.go and conn_id_manager.go own connection identifiers, and datagram_queue.go serves the unreliable datagram path from RFC 9221. Everything HTTP/3 specific sits one directory down in http3/; the README lists QPACK (RFC 9204), the Extensible Prioritization Scheme (RFC 9218) and the capsule protocol (RFC 9297) as the other HTTP/3 specifications.

The products the README lists as users are mostly servers and tunnels that expose QUIC as one configuration choice: Caddy, Traefik, cloudflared, frp, syncthing, go-libp2p, RoadRunner, AdGuardHome, OONI Probe. That tells you what kind of dependency this is. Many teams only ever meet it through a web server, and touch the Go API directly when they are writing the endpoint themselves.

Import path and Go floor come straight from go.mod

quic-go is a library, so there is nothing to install system-wide. The module path and the toolchain floor are stated at the top of go.mod in the repository root:

module github.com/quic-go/quic-go

go 1.26.0

That module path is what your import statements use, and go 1.26.0 is the language version the module declares. A build running an older Go toolchain will not resolve the module without a toolchain upgrade, which is a heavier dependency move than a normal library bump.

The same file lists the direct dependencies:

require (
	github.com/quic-go/go-ossfuzz-seeds v0.1.0
	github.com/quic-go/qpack v0.6.0
	github.com/stretchr/testify v1.12.1
	go.uber.org/mock v0.5.2
	golang.org/x/crypto v0.54.0
	golang.org/x/net v0.56.0
	golang.org/x/sync v0.22.0
	golang.org/x/sys v0.47.0
)

Header compression for HTTP/3 is a separate module, github.com/quic-go/qpack, not code living in this repository, and the fuzzing seeds are a build-time dependency rather than runtime weight. Prose documentation is published at quic-go.net/docs/, with the package index at pkg.go.dev/github.com/quic-go/quic-go. Example programs exist under example/, split into example/main.go and separate example/client/ and example/echo/ directories, so treat the docs site as the place to find your first working call.

FIPS 140-3 mode needs Go 1.26 or newer

Support for FIPS 140-3 environments arrived in v0.60, and it is conditional in two directions at once. You need quic-go v0.60 or later, and you need to build with Go 1.26 or newer. Under those two conditions the QUIC code paths that matter in FIPS mode use Go standard library cryptography.

That second condition has a consequence for build pipelines. A project pinned to an older toolchain cannot use the documented FIPS-related behavior by upgrading the module alone; the toolchain moves first, and a toolchain move drags build images, CI runners and any cgo-dependent sibling service with it. quic-go does not seek separate FIPS 140-3 validation as a cryptographic module. If a compliance boundary is the reason you are here, read FIPS140.md and verify the deployment and validation scope rather than relying on version numbers alone. The README does not enumerate which code paths fall inside FIPS mode and which do not, so an auditor asking for the exact scope will not find the answer in the front page. Establish that scope before you commit to the library, because an implementation that is compliant on the transport and non-compliant on the side you added is not a partial success.

Two extension features still track drafts, not RFCs

Most of the specification surface here is settled: RFC 9000 for the transport, RFC 9001 for TLS, RFC 9221 for unreliable datagrams, RFC 8899 for DPLPMTUD, RFC 9369 for QUIC Version 2, and on the HTTP side RFC 9114, RFC 9204, RFC 9218 and RFC 9297.

Two areas are still drafts. Connection event logging uses the qlog drafts, draft-ietf-quic-qlog-main-schema and draft-ietf-quic-qlog-quic-events. Stream resets with partial delivery are listed against two revisions of one draft, draft-ietf-quic-reliable-stream-reset-07 and draft-ietf-quic-reliable-stream-reset-09. Citing both revision numbers tells you the draft moved between them, and nothing here states which revision the current code follows.

If you plan to ingest qlog output from quic-go into a production pipeline, or you intend to rely on partial stream resets to recover a stalled transfer without tearing down the stream, you are depending on text that can still change under you. Confirm the revision against the code and against the upstream draft before you build tooling or an on-call runbook on top of either feature.

quic-go names no congestion controller and no UDP buffer size

Two questions come up in every evaluation of a QUIC library, which congestion control algorithm it uses and what UDP receive buffer size to set. Check quic-go.net/docs and config.go for both.

The tuning surface appears to live in config.go, and the detailed documentation is on quic-go.net/docs.

The consequence is that capacity planning cannot be done from the front page of the project. A UDP path that loses throughput to a too-small receive buffer presents as a broken QUIC stack, and application code is the first place engineers go looking, which wastes days before anyone checks the socket. Size the buffer in the host network stack yourself, read config.go before you benchmark, and treat any throughput number you see in a blog post as unverified until you have matched the kernel and socket settings.

Every release is 0.x and no support window is published

Three recent tags are v0.64.0 on 2026-10-16, v0.64.1 on 2026-10-19 and v0.65.0 on 2026-11-03, so new versions arrive every few weeks. The last push was on 2026-11-02, the repository is not archived, and the licence is MIT.

A cadence this fast means bug fixes and specification work arrive quickly, and it also means churn lands in your go.mod often. The recent tags are all 0.x.

So a team pinning v0.64.1 should set its own upgrade deadline, and a team tracking master inherits a dependency update every few weeks plus whatever behaviour change rode along with it. Write the policy down instead of assuming one: name the release line you are on, the date you will move it, and how you will hear about a security fix. SECURITY.md exists in the repository, so a reporting path is there.

WebTransport, CONNECT-UDP and CONNECT-IP live in other repositories

Some things that sound like part of QUIC are not in this repository. WebTransport over HTTP/3 is implemented in webtransport-go, CONNECT-UDP (RFC 9298) in masque-go, and CONNECT-IP (RFC 9484) in connect-ip-go. All three sit under the same organisation and all three are listed as related projects. Choosing quic-go because your product needs WebTransport means choosing two libraries and taking two dependency updates.

The other side of the comparison is what runs on top of quic-go. Caddy and Traefik expose HTTP/3 through their own configuration and. cloudflared, frp, Hysteria, nodepass, gost and v2ray-core treat QUIC as one transport among several inside a proxy or tunnel. Pulling quic-go in directly means you configure the QUIC layer yourself instead of through a product's settings.

That trade pays off when QUIC has to be the default transport for your own protocol, or when you need an extension such as datagrams or QUIC Version 2 that the product above has not exposed. It does not pay off when a maintained web server or tunnel daemon already gives you the QUIC path you needed, and you would only be inheriting its tuning problems with none of its integration work removed.

Editorial conclusion

Adopt quic-go when your Go service has to speak HTTP/3 or QUIC natively and you can follow a fast release train. Skip it if you need a documented stability guarantee or a toolchain below Go 1.26. Before the first line of code, read config.go for the tuning surface and confirm your build runs Go 1.26 or newer, because that is what gates FIPS 140-3 support from v0.60.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes