Regression in 0.75.0 client: ~2s delay reconnecting to relayed peer after short idle period

[kurthw]

Before posting

• I searched existing discussions and issues, including closed ones, and checked the relevant docs.
• I believe this is a product bug rather than a configuration or setup question.
• I can reproduce this issue, or for intermittent issues I've included trigger, frequency, and timing details below.
• I removed or anonymized sensitive data from logs, screenshots, and configuration.

Affected area

Client / Agent, Peer connectivity, Relay / Signal / NAT traversal

Deployment type

Self-hosted - advanced/custom deployment

Operating system or environment

Windows 10, macOS (Apple Silicon / M1) — reproduced independently on both

NetBird version and upgrade status

• Client (bug present): 0.75.0
• Client (bug absent): 0.74.7
• Management: 0.75.0 (self-hosted)
• Signal: 0.75.0 (self-hosted)
• Relay: 0.75.0 (self-hosted)

Did this work before?

Yes, this worked before

Regression details

• Last known working version: 0.74.7
• First known broken version: 0.75.0
• Recent changes: upgraded self-hosted management, signal, relay, and reverse-proxy cluster to 0.75.0, then upgraded clients to match. Downgrading only the client back to 0.74.7 (management/signal/relay left on 0.75.0) fully resolves the issue.

Summary

After upgrading the NetBird client to 0.75.0, the first request to a service behind a relayed (non-P2P) peer takes ~2 seconds longer than expected if the connection has been idle for roughly 3–4 minutes. Downgrading the client alone to 0.74.7, while leaving management/signal/relay on 0.75.0, completely eliminates the delay.

Current behavior

Accessing a service behind a relay-only peer (netbirdio/reverse-proxy cluster, no P2P/ICE candidates, no host networking) after a short idle period causes the first request to stall for roughly 2 seconds before completing. Subsequent requests within the same active window are fast. Client log shows the relay proxy being torn down and recreated right before each slow request:

INFO [peer: ] client/internal/peer/conn.go:575: created new wgProxy for relay connection: 127.1.x.x:51820
WARN client/iface/bind/activity.go:85: could not find record for address 127.1.x.x:51820

This appears tied to the WGWatcher handshake/idle check cycle (~3:30 min). Peers on an older client version (iOS/iPadOS) connecting to the same relayed peer do not exhibit this delay, which first drew our attention to a client-version-specific cause rather than a server/proxy issue.

Expected behavior

Either the relay proxy connection should be kept warm / re-established proactively in the background before it's needed again, or the teardown-and-recreate cycle should not introduce a multi-second, user-visible stall on the next request. This delay was not present (or not noticeable) on client 0.74.7 under the same server-side conditions.

Steps to reproduce

1. Set up a NetBird reverse-proxy cluster (relay-only by design, no network_mode: host, no open ports)
2. From a client on 0.75.0, access a service behind that relayed peer once, then leave it idle for more than ~3.5 minutes
3. Access the service again — first request takes ~2 seconds longer than expected
4. Repeat immediately — subsequent requests are fast
5. Downgrade only the client (not management/signal/relay) to 0.74.7 — delay disappears entirely, access remains functional
6. Compare against a peer still running an older client (e.g. iOS/iPadOS) connecting to the same relayed peer — no delay observed there either

Environment and topology

• Peer A: Windows 10 client / macOS (Apple Silicon M1) client, both tested independently
• Peer B: self-hosted reverse-proxy peer (Hetzner Cloud), relay-only connection (netbirdio/reverse-proxy image, intentionally no network_mode: host / no open UDP ports)
• Same LAN or different networks: different networks
• NAT/CGNAT/corporate firewall/mobile network: residential NAT on client side; relayed connection type (Connection type: Relayed, ICE candidates empty) for the affected peer specifically

Self-hosted details, if available

• Deployment method: Docker Compose
• Management/signal/relay versions: 0.75.0
• Reverse proxy: netbirdio/reverse-proxy image, deliberately without network_mode: host and without published ports (relay-only by design)
• IdP/provider: PocketID

Logs, status output, or debug evidence

Client log excerpt (client.log, 0.75.0), appearing immediately before each slow request:

INFO [peer: <redacted-pubkey>] client/internal/peer/conn.go:575: created new wgProxy for relay connection: 127.1.x.x:51820
WARN client/iface/bind/activity.go:85: could not find record for address 127.1.x.x:51820

Corresponding `netbird status -dA` output available on request; the affected peer shows:
  Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  Relay server address: rels://<redacted>:443

Related issues or discussions

• Related issue/discussion: PMTU blackhole between macOS client and self-hosted NetBird-Only reverse-proxy peer causes stalls #6923 (comment)
• Why this may be the same or different: different root cause (relay idle/reconnect handling vs. PMTU), but discovered during the same troubleshooting session and may share underlying client-side connection-management code paths

Impact

• Affected users/peers: 2 client devices tested directly (Windows 10, macOS M1), both confirmed; likely affects any client on 0.75.0 connecting to a relay-only peer
• Business or production impact: low/cosmetic — only affects the first request after an idle period, workaround available
• Workaround available: yes, downgrade client to 0.74.7 while leaving management/signal/relay on 0.75.0

Additional context

NetBird is still pre-1.0 / beta, so we understand regressions between minor versions are expected; reporting mainly so the relay-idle/reconnect handling change in 0.75.0 is on the radar. Happy to provide a full debug bundle (netbird debug for -A) if useful.