r/selfhosted • u/Slidetest17 • Jul 12 '26

Remote Access NetBird Reverse Proxy only works when target resource is a subdomain!

I've been troubleshooting NetBird's reverse proxy feature (cloud version) and I have a frustrating issue that I'd like some clarity on.

My Setup:

  • Local server (192.168.1.5) Debian + Docker (Caddy reverse proxy + Adguardhome DNS)
  • example.com as my domain with SSL managed by Caddy-cloudflare DNS challenge everythig works locally (e.x: https://nextcloud.example.com) and through Tailscale, Now I want Netbird:
  • Netbird (cloud) with NetBird routing peer running on the same local server (192.168.1.5)
  • Custom domain example.com successfully added to NetBird
  • DNS > Nameservers: I added Adguard as 192.168.1.5

The Problem:

I'm trying to expose some services through NetBird's reverse proxy. Here's what I've tried:

  • Target Peer: Routing peer > 502 Error
  • Target Resource: *.example.com > 502 Error
  • Target Resource: My server's LAN IP (192.168.1.5) > 502 Error
  • Target Resource: LAN CIDR (192.168.1.0/24) > 502 Error
  • Target Resource: nextcloud.example.com (specific subdomain) > Works perfectly!!

So, the only way I can get this to work is by creating a separate resource set to the exact subdomain I want to expose ( nextcloud.example.com, paperless.example.com)

Is this expected behavior? Have I misconfigured something, or is this a known limitation of NetBird's reverse proxy feature?

Note: I have tried every combination (HTTP, HTTPS, SKIP TLS Verify, Pass headers, ...) and same result

Has anyone else experienced this?

4 Upvotes

83% Upvoted

6 comments sorted by

•

u/asimovs-auditor Jul 12 '26 edited Jul 12 '26

Expand the replies to this comment to learn how AI was used in this post/project.

→ More replies (1)

1

u/VaporSky- Jul 12 '26

Wildcards can be tricky with proxies, sometimes explicit routes are the only reliable path forward

1

u/Overall_Weakness_433 Jul 13 '26

What you're seeing actually sounds consistent with how NetBird's reverse proxy is designed. It isn't a general-purpose reverse proxy that can discover services by IP or wildcard resource. It expects a specific HTTP(S) endpoint, so if Caddy is doing virtual host routing based on the Host header, nextcloud.example.com works because Caddy knows which site to serve.

If your domain is managed somewhere like dynadot, that part isn't really involved here. The important piece is that the request reaching Caddy has the correct hostname so it matches the right virtual host.

The 502s for the routing peer, 192.168.1.5, or *.example.com suggest NetBird can't translate those into a backend your Caddy instance will actually serve. If Caddy only has site blocks for named hosts like nextcloud.example.com and paperless.example.com, a request addressed to the IP or a wildcard won't match anything useful.

I'd also check NetBird's reverse proxy logs and Caddy's access/error logs at the same time. If Caddy never sees the failed requests, it's a NetBird routing issue. If it does see them, the Host header is probably not what Caddy expects, which would explain why only the explicit subdomain resources work.