Reverse Proxy breaks other hostname-based Networks resources on the same routing peers when DNS-via-routing-peer is disabled

[Alabate]

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, Reverse Proxy, DNS, Routes / Exit nodes

Deployment type

NetBird Cloud

Operating system or environment

Linux, Kubernetes

NetBird version and upgrade status

• Client (user laptop): 0.76.3
• Routing peers: 0.76.3 (originally in 0.76.0 when the issue was first found)

Did this work before?

Yes, this worked before

Regression details

• Last known working: until ~2026-08-03 morning (before ~08:22 UTC / 10:22 CEST)
• First known broken: 2026-08-03 (TCP i/o timeouts to public destinations reached via domain network resources through the affected routing peers)
• Recent changes around that time:
  • Account already had a Reverse Proxy service targeting a domain network resource served by the same routing-peer group
  • Account setting routing_peer_dns_resolution_enabled = false (intentional; enabling it previously caused other side effects for us)
  • Routing peers were already on 0.76.0 before the incident. We tried to restart them, upgrade to 0.76.1 and also downgrade to 0.74.1 but the issue was still there.
• Suspected Cloud management change related to:
  [management] Force routing-peer DNS resolution for reverse-proxy domain targets #6872
  ("Force routing-peer DNS resolution for reverse-proxy domain targets")
• Reconfirmed today after upgrading both client and routing peers to 0.76.3: still broken

Summary

Enabling a Reverse Proxy service that targets a hostname-based Networks resource appears to break access to other hostname-based Networks resources served by the same routing peers, when account-level routing_peer_dns_resolution_enabled is false.

Example: with Reverse Proxy enabled for app.example.com, access to another hostname resource like api.example.com (routed through the same peers for fixed egress / IP allowlisting) starts timing out.

Disabling the Reverse Proxy service restores access immediately; re-enabling it breaks access again.
Still reproducible after upgrading client and routing peers to 0.76.3 today.

Current behavior

Setup:

• Networks resource A: address = api.example.com (hostname, not a CIDR), used so clients egress with the routing peer public IP (allowlisting)
• Networks resource B: address = app.example.com (hostname), used as Reverse Proxy backend target
• Both are on the same routing-peer group
• Account: routing_peer_dns_resolution_enabled = false

What happens:

1. Client resolves api.example.com, installs routes for the returned public IPs through NetBird.
2. Traffic appears to reach the routing peer, then fails with TCP i/o timeout.
3. On the routing peer during failure, local connect from the routing peer to the same public destination succeeded (node egress itself looks fine)
4. Toggle test:
   • Disable Reverse Proxy for app.example.com → api.example.com works again
   • Re-enable Reverse Proxy for app.example.com → api.example.com times out again
5. Workaround: add an explicit /32 Networks resource for the resolved IP of api.example.com (ACL matches IP prefix and no longer depends on the empty hostname ipset).

Expected behavior

Enabling Reverse Proxy for app.example.com should not break unrelated hostname-based Networks resources on the same routing peers (e.g. api.example.com used for fixed egress / IP allowlisting), especially when account routing_peer_dns_resolution_enabled is false.

Steps to reproduce

1. Set account routing_peer_dns_resolution_enabled = false
2. Create a Network with Linux routing peers (in our case agents in Kubernetes, but not operator)
3. Add Networks resource:
   • Name: public-api
   • Address: api.example.com # hostname / domain form, not 1.2.3.4/32
   • Policy: users → this resource
4. Verify https://api.example.com (or the needed TCP port) works through NetBird
5. Add another Networks resource:
   • Name: app-backend
   • Address: app.example.com
     on the SAME routing-peer group
6. Create/enable a Reverse Proxy service with target = app.example.com (that Networks resource)
7. Observe: access to api.example.com starts timing out (possibly after restarting the router node?)
8. Disable the Reverse Proxy service → api.example.com works again
9. Re-enable the Reverse Proxy service → api.example.com times out again

Environment and topology

• Peer A: user Linux laptop (NetBird client), freshly upgraded
• Peer B: routing peers = Linux NetBird agents in Kubernetes (same group used for public hostname resources / fixed egress). Not using NetBird Operator.
• Same LAN or different networks: different networks (remote users)
• NAT/corporate firewall: yes
• Other VPN software: no
• Routes/DNS/policies:
  • Hostname-based Networks resources (address like api.example.com) for fixed egress / allowlisting
  • Separate private CIDR resources on same routers
  • Account DNS-via-routing-peer disabled
  • At incident time, nameservers were not distributed to routing-peer groups (agents showed Nameservers: 0/0; NetBird-generated resolv.conf pointed at the peer itself)
• Reverse proxy: NetBird Cloud Reverse Proxy targeting a hostname-based Networks resource on the same routing-peer group
• IdP: N/A for this bug

Self-hosted details, if available

N/A — NetBird Cloud management. Only routing peers are self-operated.

Logs, status output, or debug evidence

Repro toggle confirmed (including after upgrading client + routing peers today):
- Reverse Proxy service disabled → hostname Networks resource access OK
- Reverse Proxy service enabled → same hostname Networks resource TCP timeout

On routing peer during failure:
- manual local connect from the routing peer to the public destination succeeded

Client:
- netbird networks list shows Resolved IPs for the hostname resource
- traceroute / WireGuard transfer counters show traffic reaching the routing peer, then blackholed

Debug artifacts:
- In the following debug bundle: for the first ~30s I repeatedly curl a service reached through a NetBird Networks hostname resource and get timeouts. At ~30s I disable an unrelated Reverse Proxy service in the NetBird Cloud dashboard. After that, the same curls succeed: f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/2d09970d-645d-46ae-af96-6c06c791834e

Related issues or discussions

• [management] Force routing-peer DNS resolution for reverse-proxy domain targets #6872
  Possibly related: the merge timing roughly matches when we first saw the regression. While investigating with an AI coding assistant, that PR looked like a plausible explanation for the Reverse Proxy toggle behavior; not confirmed on our side — sharing in case it helps triage.

Impact

• Multiple engineers lost access to a public API endpoint reached via a hostname-based NetBird Networks resource (TCP dial timeouts).
• Workaround: replace the hostname-based resource with an explicit IP (/32).
• Concern: attaching a Reverse Proxy target to another routing-peer group could break other public hostname resources on that group the same way. For some of those destinations the IP is not stable, so the /32 workaround is not viable.

Additional context

No response

[jrdemasi]

Did you ever find a workaround here or see the behavior revert or anything? I think I'm facing the same thing, albeit a few months later :-)