NetBird update breaks routing peer connection

[yana-sdag]

Before posting

• I searched existing discussions and issues for similar questions.
• I reviewed the relevant NetBird documentation or troubleshooting guide.
• I removed or anonymized sensitive data from logs, screenshots, and configuration.

Topic

Self-hosting

Deployment type

Self-hosted - quickstart script

Operating system or environment

Linux, Docker

NetBird version

client 0.73.0, management 0.74.0

Question

We have a self-hosted NetBird setup with access to internal resources (including the NetBird vm) through a routing peer. Previous updates worked flawlessly. The latest update from 0.73.0 to 0.74.0 seemingly broke the routing peer's connection despite it showing as online in the dashboard.

I used a secondary backup VPN connection to access the routing peer and force a reconnect (and updates its client to 0.74.0 as well in the process). Without that second VPN I would've been completely locked out and unable to restore access.

My questions are:

1. Is this a new bug?
2. What would be the normal way to resolve such an issue with NetBird if one doesn't happen to have a secondary VPN set up?

Desired outcome

No response

What have you tried?

No response

Relevant environment details

No response

Logs or output

No response

Additional context

No response

[lnyamsurenn-rgb]

I encountered the same issue — in the new v0.74.0 version, lazy connection became enabled by default. This was causing problems with connections going through the routing peer.

1. Dashboard → Settings → Clients → Disable Lazy Connection
2. On the Routing Peer server: netbird down, netbird up, netbird status -d (verify that lazy-connection=false). Since this still didn't resolve the issue, I proceeded to step 3.
3. Restart the NetBird management server: docker restart netbird-server
4. Also restart the NetBird client and reconnect — after that, everything worked normally.

[securebitsorg]

I can also confirm this error.

After the update, all clients are displayed as Online in the management dashboard; even on systems running Netbird clients, entering netbird status shows them as Connected.

However, SSH connections can no longer be established, and services accessed via the Netbird reverse proxy are no longer reachable (Error 502).

The Netbird clients (version 0.74.0) work fine when used with the Netbird server stack 0.73.2, Management, and Dashboard v2.90.2.

The errors only occur after updating the server stack to Management version v0.74.0.

The workaround suggested by @lnyamsurenn-rgb might certainly work, but unfortunately it’s not practical with 300 clients. ;-)

P.S. Still, I'd like to thank the developers at Netbird for this excellent software.

[WithdewHua]

services accessed via the Netbird reverse proxy are no longer reachable (Error 502).

yes, I have also met this problem

[allxm4]

Can confirm the same thing @securebitsorg is describing. Did a bit of isolation testing on my end that might add some useful detail.

My setup: self-hosted combined server (management+signal+relay+STUN) + reverse-proxy, both normally pinned together. Upgraded both to 0.74.0, reverse-proxy services started returning 502, and peers still showed "connected"/online in the dashboard the whole time, so it wasn't visible as a health issue on the surface.

Logs from the reverse-proxy peer:
WARN client/internal/peer/worker_ice.go:163: ICE Agent is not initialized yet
WARN client/internal/peer/wg_watcher.go:152: WireGuard handshake timed out: 0001-01-01 00:00:00 +0000 UTC
WARN client/internal/peer/conn.go:674: WireGuard handshake timeout detected, closing current connection
ERRO client/iface/wgproxy/bind/proxy.go:190: failed to read from remote conn: rels://:443, use of closed network connection

This happened even with NB_FORCE_RELAY=true set on the client, which is supposed to skip ICE/STUN entirely, handshake still didn't complete.

What I found when testing:

• Downgrading only the reverse-proxy client to 0.73.2, keeping server on 0.74.0 → no change
• Downgrading the combined server to 0.73.2 to match the client → fixed it

So similar to what @securebitsorg found, it seems tied to the server side rather than the client.

On the lazy-connections idea from @lnyamsurenn-rgb, the release notes mention that's only enabled by default for new accounts, so probably not it for existing setups, but not 100% sure.

For what it's worth, one thing I noticed browsing the 0.74.0 changelog is PR #6626, which changes the order WG watcher does its initial handshake read relative to the peer being added to the interface. My logs also show wg_watcher.go:64: failed to read initial wg stats: peer ... not found in WireGuard endpoints, which lines up with that reordering. Not sure if it's related, just flagging it in case it's useful context.

Happy to share more logs if it'd help track this down.

[Y4m4k]

I am having similar odd issues with my iphone (as a client) connecting to my VPS netbird server after upgrading to 0.74. The connection type states “Relay” with no ICE candidate. I have an exit route through my VPS and a route for my local network. I am not able to access my local network when I am remote, however, can still access the internet via the VPS exit route. Everything was working fine until upgrading to 0.74.

[mertcangokgoz]

Having Lazy Connection enabled by default with the 0.74.0 server update is causing very frequent disconnections on connected peers. Also, a large number of "Server failed" errors are starting to occur on the DNS side.

There are no issues on gateway machines with client version 73.2, only the connections on the 74.0 version I updated are causing a lot of problems.

Everything was working fine until switching to version 0.74.

[mlsmaycon]

Hey folks, can you validate if 0.74.1 fixes the issue? We found a bug where relays were not sent to peers and fixed in this version

[allxm4]

I can confirm it works great on v0.74.1. Thank you!

[WithdewHua]

I upgraded to 0.74.1, but my reverse-proxy services still return 502 errors. Everything works fine for the first few minutes after startup, but then all requests start failing with 502 responses.

[nghialele]

No its not after updated the server and 2 proxy clusters to latest (0.74.1)

[securebitsorg]

I upgraded to 0.74.1, but my reverse-proxy services still return 502 errors. Everything works fine for the first few minutes after startup, but then all requests start failing with 502 responses.

You must Update the Netbird-Clients on the Proxy-Hosts, then restart the proxy-hosts and also the Management-Server.

That's definitely how it worked for us, and all the services behind the reverse proxy are accessible again

[WithdewHua]

I upgraded to 0.74.1, but my reverse-proxy services still return 502 errors. Everything works fine for the first few minutes after startup, but then all requests start failing with 502 responses.

You must Update the Netbird-Clients on the Proxy-Hosts, then restart the proxy-hosts and also the Management-Server.

That's definitely how it worked for us, and all the services behind the reverse proxy are accessible again

I upgraded as the following order:

1. upgraded the netbird clients on the server hosting proxy and management server;
2. then upgraded the netbird server;
3. finally upgraded the proxy server;

but, the 502 problem still exists. I executed netbird status -d on the backend services' server, I did not see the connection between the server and the proxy server. And downgraded to 0.73.2, the connection established and reverse-proxy works well.

[mrtn-roeder]

I am experiencing the exact same "502 Bad Gateway" issues mentioned in this thread since the 0.74.x updates. I'm just a home-labber playing around with some Raspberry Pis, so I'm not a networking expert, but I want to share a critical piece of debugging information that I found. It might help you guys pinpoint the exact root cause!

Since I am using the NetBird Managed Cloud, I cannot simply downgrade the management server to 0.73.2 as suggested above. My local clients (Raspberry Pis, Linux/arm64) are running on v0.74.4.

My Setup (Target Type: Peer):

• Device A: Nextcloud AIO (Docker)
• Device B: ntfy & Stirling PDF (Docker)
• Device C: TCP/IP Alarm Server

The Debugging & The "Smoking Gun":
To figure out what's going wrong, I ran a packet capture on my local routing peer (sudo tcpdump -i wt0 -n port ). When the 502 errors occur in the browser, absolutely zero packets arrive at the local interface. The connection is being dropped upstream within the NetBird proxy infrastructure, not by my local Pi. If I delete and recreate the reverse proxy service in the dashboard, traffic flows perfectly for a few minutes before dropping again.

However, I noticed a very specific pattern regarding which services fail:

• ​Stirling PDF (Device B) -> Works flawlessly 100% of the time.
• ​ntfy (Device B) -> Intermittent 502 Bad Gateway.
• ​Nextcloud AIO (Device A) -> Intermittent 502 Bad Gateway.
• TCP/IP Alarm Server (Device C) -> Experiences occasional timeouts.

Conclusion:
Both ntfy and Stirling PDF are hosted on the exact same routing peer, proving that the WireGuard tunnel itself is perfectly stable.

From my understanding, Stirling PDF relies on standard, stateless HTTP requests. ntfy and Nextcloud, on the other hand, heavily rely on WebSockets and Server-Sent Events (SSE) for push notifications (long-lived connections).

Could it be that the current NetBird L7 Proxy implementation (since 0.74.x) struggles to handle WebSockets or long-lived connections? It seems to time out and corrupt the routing path for those specific services, while standard stateless services continue to pass through without issue.

I’m still very new to this field and learning every day, so I hope my amateur sleuthing helps the team to isolate the bug! Let me know if you need any further logs.

[jeffdecoste]

I hit the same issue after updating my Raspberry Pi routing-peer clients to 0.74.6. I had already updated the self-hosted Management server, Dashboard, and proxy to the latest versions the previous day with no issues.

Peers remained shown as connected, but all reverse-proxy services returned 502/timeouts and no proxy traffic reached either routing peer.

The recovery that fixed it was:

1. Restart the Management server and reverse proxy.
2. Restart each routing-peer client.
3. Wait for the proxy peer WireGuard handshakes to re-establish.

After that, my reverse-proxy services recovered immediately.