HTTP/3 UDP socket leak leads to local port exhaustion after 0-RTT rejected

[notr1ch]

I am running dnsproxy on Linux AMD64 as follows:

2026/07/17 15:38:38.355881 INFO dnsproxy starting version=v0.83.0 revision=d020fcc62cfd62958706295d7c9d9e82ae015f52 branch=v0.83.0 commit_time=1783069482

dnsproxy -l 127.0.0.6 -u h3://dns.google/dns-query -b 8.8.8.8:53

This setup has been working well for many months, however today I began to get 0-RTT rejected responses from Google DNS:

Jul 17 15:36:14 dnsproxy[436873]: 2026/07/17 15:36:14.221298 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";accounts.google.com.\tIN\t A" duration=26.777927ms err="exchanging: requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABCGFjY291bnRzBmdvb2dsZQNjb20AAAEAAQAAKQTQAACAAAAA\": http3: parsing frame failed: 0-RTT rejected"
Jul 17 15:36:14 dnsproxy[436873]: 2026/07/17 15:36:14.227267 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";history.l.google.com.\tIN\t HTTPS" duration=12.137872ms err="exchanging: requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABB2hpc3RvcnkBbAZnb29nbGUDY29tAABBAAEAACkE0AAAgAAAAA\": http3: parsing frame failed: 0-RTT rejected"
Jul 17 15:36:14 dnsproxy[436873]: 2026/07/17 15:36:14.423144 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";2-prod-dynamite-prod-02-us-signaler-pa.clients6.google.com.\tIN\t HTTPS" duration=16.508161ms err="exchanging: requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABJjItcHJvZC1keW5hbWl0ZS1wcm9kLTAyLXVzLXNpZ25hbGVyLXBhCGNsaWVudHM2Bmdvb2dsZQNjb20AAEEAAQAAKQTQAACAAAAA\": http3: parsing frame failed: 0-RTT rejected"
Jul 17 15:36:15 dnsproxy[436873]: 2026/07/17 15:36:15.542314 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";mail.google.com.\tIN\t A" duration=28.740321ms err="exchanging: requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABBG1haWwGZ29vZ2xlA2NvbQAAAQABAAApBNAAAIAAAAA\": http3: parsing frame failed: 0-RTT rejected"
Jul 17 15:36:15 dnsproxy[436873]: 2026/07/17 15:36:15.542355 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";mail.google.com.\tIN\t HTTPS" duration=28.834902ms err="exchanging: requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABBG1haWwGZ29vZ2xlA2NvbQAAQQABAAApBNAAAIAAAAA\": http3: parsing frame failed: 0-RTT rejected"

After such responses, dnsproxy seems to open / leak a number of new UDP sockets:

# lsof -p 436873
COMMAND     PID            USER  FD      TYPE             DEVICE SIZE/OFF      NODE NAME
dnsproxy 436873 dnsproxy-google cwd       DIR              254,1     4096         2 /
dnsproxy 436873 dnsproxy-google rtd       DIR              254,1     4096         2 /
dnsproxy 436873 dnsproxy-google txt       REG              254,1 11935906   8782474 /opt/dnsproxy/dnsproxy
dnsproxy 436873 dnsproxy-google   0r      CHR                1,3      0t0         4 /dev/null
dnsproxy 436873 dnsproxy-google   1u     unix 0x000000007c9226f4      0t0 365483103 type=STREAM (CONNECTED)
dnsproxy 436873 dnsproxy-google   2u     unix 0x000000007c9226f4      0t0 365483103 type=STREAM (CONNECTED)
dnsproxy 436873 dnsproxy-google   3r      REG               0,27        0    293214 /sys/fs/cgroup/system.slice/dnsproxy-google.service/cpu.max
dnsproxy 436873 dnsproxy-google   4u  a_inode               0,16        0        58 [eventpoll:5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21]
dnsproxy 436873 dnsproxy-google   5u  a_inode               0,16        0        58 [eventfd:5]
dnsproxy 436873 dnsproxy-google   6u     IPv4          365616831      0t0       UDP 127.0.0.6:domain
dnsproxy 436873 dnsproxy-google   7u     IPv4          365616836      0t0       TCP 127.0.0.6:domain (LISTEN)
dnsproxy 436873 dnsproxy-google   8u     IPv6          365979239      0t0       UDP *:42047
dnsproxy 436873 dnsproxy-google   9u     IPv6          366019813      0t0       UDP *:52678
dnsproxy 436873 dnsproxy-google  10u     IPv6          365946353      0t0       UDP *:34188
dnsproxy 436873 dnsproxy-google  11u     IPv6          365983107      0t0       UDP *:39381
dnsproxy 436873 dnsproxy-google  12u     IPv6          366008373      0t0       UDP *:57130
dnsproxy 436873 dnsproxy-google  13u     IPv6          366014604      0t0       UDP *:37532
dnsproxy 436873 dnsproxy-google  14u     IPv6          366011470      0t0       UDP *:49196
dnsproxy 436873 dnsproxy-google  15u     IPv6          366021273      0t0       UDP *:58625
dnsproxy 436873 dnsproxy-google  16u     IPv6          366025846      0t0       UDP *:34846
dnsproxy 436873 dnsproxy-google  17u     IPv6          366000931      0t0       UDP *:56331
dnsproxy 436873 dnsproxy-google  18u     IPv6          365892103      0t0       UDP *:46402
dnsproxy 436873 dnsproxy-google  19u     IPv6          366021275      0t0       UDP *:56870
dnsproxy 436873 dnsproxy-google  20u     IPv6          365892105      0t0       UDP *:49549
dnsproxy 436873 dnsproxy-google  21u     IPv6          365908932      0t0       UDP *:56892

Eventually, as further 0-RTT rejected errors accumulate, all local ports are exhausted and DNS resolution begins to fail:

Jul 17 14:31:06 dnsproxy[423785]: 2026/07/17 14:31:06.739988 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";5-prod-dynamite-prod-07-us-signaler-pa.clients6.google.com.\tIN\t A" duration=9.433834ms err="requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABJjUtcHJvZC1keW5hbWl0ZS1wcm9kLTA3LXVzLXNpZ25hbGVyLXBhCGNsaWVudHM2Bmdvb2dsZQNjb20AAAEAAQAAKQTQAACAAAAA\": listen udp 0.0.0.0:0: bind: address already in use"
Jul 17 14:31:06 dnsproxy[423785]: 2026/07/17 14:31:06.740656 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";5-prod-dynamite-prod-07-us-signaler-pa.clients6.google.com.\tIN\t HTTPS" duration=10.310516ms err="requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABJjUtcHJvZC1keW5hbWl0ZS1wcm9kLTA3LXVzLXNpZ25hbGVyLXBhCGNsaWVudHM2Bmdvb2dsZQNjb20AAEEAAQAAKQTQAACAAAAA\": listen udp 0.0.0.0:0: bind: address already in use"
Jul 17 14:31:07 dnsproxy[423785]: 2026/07/17 14:31:07.267416 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";storage.googleapis.com.\tIN\t A" duration=10.787386ms err="requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABB3N0b3JhZ2UKZ29vZ2xlYXBpcwNjb20AAAEAAQAAKQTQAACAAAAA\": listen udp 0.0.0.0:0: bind: address already in use"
Jul 17 14:31:07 dnsproxy[423785]: 2026/07/17 14:31:07.324147 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";prod-dynamite-prod-04-us-signaler-pa.clients6.google.com.\tIN\t HTTPS" duration=10.892828ms err="requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABJHByb2QtZHluYW1pdGUtcHJvZC0wNC11cy1zaWduYWxlci1wYQhjbGllbnRzNgZnb29nbGUDY29tAABBAAEAACkE0AAAgAAAAA\": listen udp 0.0.0.0:0: bind: address already in use"
Jul 17 14:31:07 dnsproxy[423785]: 2026/07/17 14:31:07.325076 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";prod-dynamite-prod-04-us-signaler-pa.clients6.google.com.\tIN\t A" duration=11.908636ms err="requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABJHByb2QtZHluYW1pdGUtcHJvZC0wNC11cy1zaWduYWxlci1wYQhjbGllbnRzNgZnb29nbGUDY29tAAABAAEAACkE0AAAgAAAAA\": listen udp 0.0.0.0:0: bind: address already in use"
Jul 17 14:31:07 dnsproxy[423785]: 2026/07/17 14:31:07.359561 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";prod-dynamite-prod-04-us-signaler-pa.clients6.google.com.\tIN\t A" duration=11.576853ms err="requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABJHByb2QtZHluYW1pdGUtcHJvZC0wNC11cy1zaWduYWxlci1wYQhjbGllbnRzNgZnb29nbGUDY29tAAABAAEAACkE0AAAgAAAAA\": listen udp 0.0.0.0:0: bind: address already in use"
Jul 17 14:31:07 dnsproxy[423785]: 2026/07/17 14:31:07.376394 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";ie_sla0.apple-dns.net.\tIN\t A" duration=11.355851ms err="requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABB2llX3NsYTAJYXBwbGUtZG5zA25ldAAAAQABAAApBNAAAIAAAAA\": listen udp 0.0.0.0:0: bind: address already in use"
Jul 17 14:31:07 dnsproxy[423785]: 2026/07/17 14:31:07.377400 ERROR exchange failed prefix=dnsproxy upstream=https://dns.google:443/dns-query question=";prod-dynamite-prod-04-us-signaler-pa.clients6.google.com.\tIN\t A" duration=7.240127ms err="requesting https://dns.google:443/dns-query: Get_0rtt \"https://dns.google:443/dns-query?dns=AAABEAABAAAAAAABJHByb2QtZHluYW1pdGUtcHJvZC0wNC11cy1zaWduYWxlci1wYQhjbGllbnRzNgZnb29nbGUDY29tAAABAAEAACkE0AAAgAAAAA\": listen udp 0.0.0.0:0: bind: address already in use"

[notr1ch]

I spent a little time trying to debug this with assistance from Claude Code. I believe this is an upstream quic-go bug, exacerbated by the custom Dial proxy used by dnsproxy. The following is an AI-generated summary of the debug session; I couldn't find any contributing guidelines mentioning AI so I hope this is OK to post here.

Investigation Summary: DoH3 QUIC Connection/Socket Leak on 0-RTT Rejection

Component: upstream/doh.go (dnsproxy HTTP/3 upstream), depends on github.com/quic-go/quic-go v0.60.0 (http3 subpackage)
dnsproxy version investigated: v0.83.0 (originally reported), reproduced against local master (commit f35ca3e)
quic-go version: v0.60.0 (latest tagged release; confirmed identical to current master for the relevant file — see §6)

1. Reported symptom

A long-running dnsproxy instance configured as dnsproxy -l 127.0.0.6 -u h3://dns.google/dns-query -b 8.8.8.8:53 began receiving 0-RTT rejected errors from dns.google (Google Public DNS), e.g.:

err="exchanging: requesting https://dns.google:443/dns-query: Get_0rtt \"...\": http3: parsing frame failed: 0-RTT rejected"

Following these errors, lsof showed a growing number of unconnected (UDP *:PORT) sockets held by the dnsproxy process. Over time this exhausted the local ephemeral port range, at which point all further QUIC dials failed with listen udp 0.0.0.0:0: bind: address already in use, taking down DNS resolution entirely.

2. Reproduction

Reproduced after restarting dnsproxy: after exactly 5 logged 0-RTT rejected errors, 14 UDP sockets remained open under the dnsproxy process. These persisted for 15+ minutes with no further errors logged, i.e. this is not sockets slowly draining after normal QUIC connection close/idle-timeout — they are permanently orphaned.

3. How dnsproxy dials QUIC connections

dnsproxy does not use http3.Transport's default dialing behavior. It supplies a custom Dial callback (upstream/doh.go:573-584) so that every connection targets the single IP address obtained from its own bootstrap resolver:

rt := &http3.Transport{
        Dial: func(ctx context.Context, _ string, tlsCfg *tls.Config, cfg *quic.Config) (*quic.Conn, error) {
                return quic.DialAddrEarly(ctx, addr, tlsCfg, cfg)
        },
        ...
}

quic.DialAddrEarly (client.go:42-61) allocates a new net.ListenUDP socket and a dedicated, single-use quic.Transport on every call:

func DialAddrEarly(ctx context.Context, addr string, tlsConf *tls.Config, conf *Config) (*Conn, error) {
        udpConn, err := net.ListenUDP("udp", &net.UDPAddr{IP: net.IPv4zero, Port: 0})
        ...
        tr, err := setupTransport(udpConn, tlsConf, true) // isSingleUse: true
        ...
}

So every *quic.Conn this callback returns owns exactly one dedicated OS UDP socket. This is significant for §7.

dnsproxy also sets KeepAlivePeriod: QUICKeepAlivePeriod on its quic.Config (upstream/doh.go:105-107), which causes every connection — including ones nothing is using anymore — to keep sending PING frames, which prevents the QUIC idle timeout from ever firing.

4. Root cause: http3.Transport.removeClient evicts without closing

http3.Transport.doRoundTripOpt (http3/transport.go:214-255) calls a connection's RoundTrip; on any error from an established connection (including the wrapped 0-RTT rejected failure — see §5), it evicts the connection from its internal client-pool map:

// http3/transport.go:230, :247
t.removeClient(hostname)

// http3/transport.go:419-426
func (t *Transport) removeClient(hostname string) {
        t.mutex.Lock()
        defer t.mutex.Unlock()
        if t.clients == nil {
                return
        }
        delete(t.clients, hostname)
}

removeClient only deletes the map entry. It never calls the entry's Close(). The only code path that actually closes the underlying *quic.Conn is:

// http3/transport.go:56-63
func (r *roundTripperWithCount) Close() error {
        r.cancel()
        <-r.dialing
        if r.conn != nil {
                return r.conn.CloseWithError(0, "")
        }
        return nil
}

…which is only invoked by Transport.Close() (http3/transport.go:474-494) and Transport.CloseIdleConnections() (http3/transport.go:529-538), and both of those only iterate the t.clients map. Once removeClient has deleted an entry, neither method can ever reach it again. The connection — and, in dnsproxy's case, its dedicated UDP socket — is permanently unreachable and never closed.

This is not specific to 0-RTT: removeClient runs for any RoundTrip error on an established connection, so any condition that causes quic-go to consider a connection broken (idle timeout races, GOAWAY, transport errors, etc.) leaks it the same way. 0-RTT rejection is simply what's currently triggering it for this reporter.

5. Why the connection isn't reclaimed by GC

This isn't merely "GC hasn't gotten to it yet" — the object is genuinely reachable and won't ever be collected. Go's net package does register a finalizer that would close an abandoned socket's fd once truly unreachable (src/net/fd_posix.go:44, runtime.SetFinalizer(fd, (*netFD).Close)), so in principle GC finalization could clean this up if the object graph became unreachable. It doesn't, because Transport.dial (http3/transport.go:344-398) spawns a goroutine that keeps a live reference to the connection forever:

// http3/transport.go:387-396
conn, err := dial(ctx, hostname, tlsConf, t.QUICConfig)
...
clientConn := t.newClientConn(conn)
go func() {
        for {
                str, err := conn.AcceptUniStream(context.Background())
                if err != nil {
                        return
                }
                go clientConn.handleUnidirectionalStream(str)
        }
}()

context.Background() is never cancelled, so this loop only exits once conn itself errors/closes — which, per §4, never happens for an evicted connection. quic-go's own per-connection state-machine goroutine (Conn.run()) is in the same position, kept alive to service the KeepAlivePeriod timer. Both goroutines permanently root the connection (and its netFD), so it is never eligible for GC, let alone finalization.

6. Confirmed present in the latest release and unreleased master

go list -m -versions github.com/quic-go/quic-go tops out at v0.60.0 — no newer release exists. A shallow clone of quic-go's master branch (17 commits ahead of the v0.60.0 tag at time of investigation) has a byte-for-byte identical http3/transport.go to the vendored v0.60.0 copy — removeClient is unchanged. No existing GitHub issue or PR against quic-go/quic-go referencing removeClient or this leak was found via GitHub's search API.

7. Why this manifests dramatically for dnsproxy but plausibly hasn't been widely reported

Two factors specific to dnsproxy's usage convert an otherwise-quiet leak into visible port exhaustion:

• Socket ownership: http3.Transport's default dial path (used when no custom Dial is supplied) allocates one shared, non-single-use quic.Transport/UDP socket for the transport's entire lifetime (http3/transport.go:157-163):

  if t.Dial == nil {
        udpConn, err := net.ListenUDP("udp", nil)
        ...
        t.transport = &quic.Transport{Conn: udpConn}
  }

  For a default-configuration caller, an evicted-but-unclosed connection still leaks (as a Go object + goroutine), but it does not consume an additional OS socket/port, since all connections share one fd. The symptom there is a slow goroutine/memory leak, not EADDRINUSE. dnsproxy's custom Dial (§3) instead allocates a dedicated single-use socket per connection, so the same quic-go bug produces one leaked fd per eviction instead of one leaked Go object.

• Trigger rate: the leak only accumulates when quic-go evicts connections. Under normal operation this is rare. This report's trigger — the upstream server rejecting 0-RTT on nearly every request for a sustained period — produces an unusually high eviction rate, causing the leak to become port-exhausting within minutes rather than over months.

• Code age: http3.Transport's current connection-pooling implementation (clients map[string]*roundTripperWithCount, getClient, removeClient) was introduced by a rename in commit 1db805c ("http3: improve the client API", 2024-10-14) — under two years old at time of writing. quic-go's "production-ready" track record is earned primarily by its core QUIC engine (used in production by, e.g., Caddy, for several years longer); this specific client-side connection-eviction path has had comparatively little exposure.

8. Related: 0-RTT rejection is never specially recovered by http3

*quic.Conn exposes NextConnection(ctx) (connection.go:3124-3141), documented as: "This should be called when the server rejects 0-RTT and the application receives [Err0RTTRejected] errors" — it waits for the real (1-RTT) handshake to complete and transitions the connection back to normal, reusable state. Searching the entire quic-go module for NextConnection shows it is referenced only in its own definition and in quic-go's internal integration test (integrationtests/self/zero_rtt_test.go:632) — it is never called anywhere inside the http3 package.

Concretely: ClientConn.roundTrip's response-reading failure (http3/stream.go:328, fmt.Errorf("http3: parsing frame failed: %w", err) wrapping quic.Err0RTTRejected, defined at interface.go:59 as errors.New("0-RTT rejected")) is returned via maybeReplaceError, not as *errConnUnusable. In canRetryRequest (http3/transport.go:257-286), only *errConnUnusable and *Error{ErrCodeRequestRejected} are treated as retryable-on-the-same-attempt; a 0-RTT-rejected frame-parse failure matches neither. The net effect: quic-go's own HTTP/3 client treats 0-RTT rejection as a generic terminal request failure — evict-and-redial (§4) — rather than the officially documented recovery path of calling NextConnection and retrying the same request over the same connection. This is a second, independent gap from the leak itself: even setting aside the leak, quic-go's http3 package does not use the API it exposes for exactly this situation.

9. Collateral finding: an existing dnsproxy test unintentionally depends on the leak

While validating a fix locally, TestUpstreamDoH_serverRestart/http3 (upstream/doh_internal_test.go:202-269) started failing when abandoned connections were closed promptly instead of left leaking. Investigation showed the test's "second_try" step (reconnecting after the DoH3 test server restarts on the same port) currently passes only because the leaked connection from the pre-restart server is left open long enough to complete its TLS handshake and deliver a fresh session ticket into the (never-reset) tls.Config.ClientSessionCache — which a subsequent reconnect attempt then uses to successfully resume 0-RTT within dnsproxy's retry budget (upstream/doh.go:172-180, up to 2 retries). Closing the abandoned connection promptly (as a correct fix would) removes that side channel and requires either more retry budget or an explicit fix to the reconnect logic to keep passing reliably. Anyone fixing the leak (in dnsproxy or by patching around it) should expect this test to need attention, since it currently encodes the buggy behavior as a passing assertion rather than the intended one.

10. Suggested disposition

• quic-go: removeClient (http3/transport.go:419-426) should close the evicted connection's entry before/instead of dropping it from the map. Separately, 0-RTT rejection could be handled via NextConnection + same-connection retry rather than unconditional eviction, consistent with the API's own documented intent (§8).
• dnsproxy: independent of the quic-go fix, dnsproxy's custom Dial (§3) is what turns this into an OS-resource-exhaustion bug rather than an in-process leak; a caller-side mitigation is possible without waiting on upstream.

[muzzy124]

does it create a memory leak too? i noticed that latest releases are very vulnerable to network issues. For example memory consumption of docker container with dnsproxy can fly from 30-40 MB to about 200 MB if simply internet connection is lost for an hour.

[notr1ch]

does it create a memory leak too?

Yes, as described in section 5, the connection object and its maintenance goroutine are also leaked, which would consume memory over time.