[GH-ISSUE #4090] [INFRA] configure.sh regression on rels:// relay URI in case of reverse proxy (should be 443, not 33080) #8689

Open
opened 2026-08-05 01:19:11 -04:00 by saavagebueno · 4 comments
Owner

Originally created by @TomGudman on GitHub (Jul 2, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/4090

Describe the problem
A PR was made to ease the reverse proxy setup with configure.sh.
Unfortunately a regression was made a few days later which now breaks the relay URI if we use a reverse proxy. rels://FQDN:33080 is incorrect, rels://FQDN:443 is correct in a reverse proxy scenario.

My comment on line #173 in the diff is probably easier to understand in context.

To Reproduce
Steps to reproduce the behavior:

  1. Set up as a reverse proxy setup your setup.env (no letsencrypt, port set to 443 for 33073 and 10000)
  2. Run ./configure.sh
  3. Grep for rels:// and look at the output. You'll find something like: rels://netbird.domain.tld:33080/relay

Expected behavior
It should be set to rels://netbird.domain.tld:443/relay

"Workaround"
Use port 443 instead of 33080 in the rels:// URI in a reverse proxy scenario. However I didn't deep dive to study the logic and why the change was reverted. What is clear though is that in a reverse proxy scenario port 33080 is not exposed on the traefik side so there isn't any port open to accept any connection other than 443, and the coturn ports.

docker-compose.yml

  # Relay
  relay:
    image: netbirdio/relay:0.49.0
    restart: unless-stopped
    environment:
    - NB_LOG_LEVEL=info
    - NB_LISTEN_ADDRESS=:33080
    - NB_EXPOSED_ADDRESS=rels://netbird.domain.tld:443/relay
    - NB_AUTH_SECRET=......
...

management.json

  "Relay": {
    "Addresses": [
      "rels://netbird.domain.tld:443/relay"
    ],
    "CredentialsTTL": "24h",
    "Secret": "...."
  },

Are you using NetBird Cloud?
No. I use Netbird Selfhosted with traefik as reverse proxy

NetBird version
0.49.0 management suite selfhosted

Additional context
A netbird client status like: netbird status --detail would highlight the issue and when it does work
BEFORE

OS: darwin/amd64
Daemon version: 0.49.0
CLI version: 0.49.0
Management: Connected to https://netbird.domain.tld:443
Signal: Connected to https://netbird.domain.tld:443
Relays: 
  [rels://netbird.domain.tld:33080/relay] is Unavailable, reason: relay client not connected

AFTER: with port 443

OS: darwin/amd64
Daemon version: 0.49.0
CLI version: 0.49.0
Management: Connected to https://netbird.domain.tld:443
Signal: Connected to https://netbird.domain.tld:443
Relays: 
  [stun:netbird.domain.tld:3478] is Available
  [turn:netbird.domain.tld:3478?transport=udp] is Available
  [rels://netbird.domain.tld:443/relay] is Available

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting (if applicable)
  • Checked for newer NetBird versions
  • Searched for similar issues on GitHub (including closed ones)
  • Restarted the NetBird client
  • Disabled other VPN software
  • Checked firewall settings
Originally created by @TomGudman on GitHub (Jul 2, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/4090 **Describe the problem** A [PR](https://github.com/netbirdio/netbird/pull/3696/commits/c20ca5dde670ea077f28104fd63abcb666534a5f) was made to ease the reverse proxy setup with `configure.sh`. Unfortunately a regression was made a few days later which now breaks the relay URI if we use a reverse proxy. `rels://FQDN:33080` is incorrect, `rels://FQDN:443` is correct in a reverse proxy scenario. My comment on[ line #173 in the diff](https://github.com/netbirdio/netbird/commit/b56f61bf1b093afaed242a22f861475a40eafe1d#diff-eace7271a8b7cfe659b16be9f3dcf9f5ad8b47d448ba16ea3e8ef3252c2b0452L173) is probably easier to understand in context. **To Reproduce** Steps to reproduce the behavior: 1. Set up as a reverse proxy setup your `setup.env` (no letsencrypt, port set to 443 for 33073 and 10000) 2. Run ./configure.sh 3. Grep for rels:// and look at the output. You'll find something like: `rels://netbird.domain.tld:33080/relay` **Expected behavior** It should be set to `rels://netbird.domain.tld:443/relay` **"Workaround"** Use port 443 instead of 33080 in the rels:// URI in a reverse proxy scenario. However I didn't deep dive to study the logic and why the change was reverted. What is clear though is that in a reverse proxy scenario port 33080 is not exposed on the traefik side so there isn't any port open to accept any connection other than 443, and the coturn ports. _**docker-compose.yml**_ ```... # Relay relay: image: netbirdio/relay:0.49.0 restart: unless-stopped environment: - NB_LOG_LEVEL=info - NB_LISTEN_ADDRESS=:33080 - NB_EXPOSED_ADDRESS=rels://netbird.domain.tld:443/relay - NB_AUTH_SECRET=...... ... ``` _**management.json**_ ``` "Relay": { "Addresses": [ "rels://netbird.domain.tld:443/relay" ], "CredentialsTTL": "24h", "Secret": "...." }, ``` **Are you using NetBird Cloud?** No. I use Netbird Selfhosted with traefik as reverse proxy **NetBird version** 0.49.0 management suite selfhosted **Additional context** A netbird client status like: `netbird status --detail` would highlight the issue and when it does work _**BEFORE**_ ``` OS: darwin/amd64 Daemon version: 0.49.0 CLI version: 0.49.0 Management: Connected to https://netbird.domain.tld:443 Signal: Connected to https://netbird.domain.tld:443 Relays: [rels://netbird.domain.tld:33080/relay] is Unavailable, reason: relay client not connected ``` _**AFTER: with port 443**_ ``` OS: darwin/amd64 Daemon version: 0.49.0 CLI version: 0.49.0 Management: Connected to https://netbird.domain.tld:443 Signal: Connected to https://netbird.domain.tld:443 Relays: [stun:netbird.domain.tld:3478] is Available [turn:netbird.domain.tld:3478?transport=udp] is Available [rels://netbird.domain.tld:443/relay] is Available ``` **Have you tried these troubleshooting steps?** - [ ] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [x] Checked for newer NetBird versions - [x] Searched for similar issues on GitHub (including closed ones) - [ ] Restarted the NetBird client - [ ] Disabled other VPN software - [ ] Checked firewall settings
saavagebueno added the bugself-hosting labels 2026-08-05 01:19:11 -04:00
Author
Owner

@jordantrujillo-hl commented on GitHub (Jul 11, 2025):

Tom is right, that PR has an error.

<!-- gh-comment-id:3064160708 --> @jordantrujillo-hl commented on GitHub (Jul 11, 2025): Tom is right, that PR has an error.
Author
Owner

@CustomIcon commented on GitHub (Sep 23, 2025):

this works suprisingly

<!-- gh-comment-id:3325186024 --> @CustomIcon commented on GitHub (Sep 23, 2025): this works suprisingly
Author
Owner

@markcst commented on GitHub (Dec 5, 2025):

I've found this to be true, even after recent updates. I've changed port from 33080 in rels:// in management.json and it started working again, whether before that it didn't anymore (especially the sheer VPN feature and the ability to connect from outside the LAN. Hope they can fix it. More love for the reverse proxy/Traefik files and configs, pls 🥹

<!-- gh-comment-id:3619135454 --> @markcst commented on GitHub (Dec 5, 2025): I've found this to be true, even after recent updates. I've changed port from `33080` in `rels://` in `management.json` and it started working again, whether before that it didn't anymore (especially the sheer VPN feature and the ability to connect from outside the LAN. Hope they can fix it. More love for the reverse proxy/Traefik files and configs, pls 🥹
Author
Owner

@im-ikao commented on GitHub (Feb 9, 2026):

I believe this behavior is intentional.
Using 443 in the rels:// relay URI makes sense in reverse proxy setups, where external access always goes through the standard HTTPS port, while the internal service may run on a different port (e.g. 33080).

In this case, the relay URI should reflect the external endpoint rather than the internal service port; otherwise, it breaks a typical proxy / load balancer configuration. So the current behavior looks like a deliberate design choice for better reverse proxy compatibility, not a bug.

<!-- gh-comment-id:3870374306 --> @im-ikao commented on GitHub (Feb 9, 2026): I believe this behavior is intentional. Using 443 in the rels:// relay URI makes sense in reverse proxy setups, where external access always goes through the standard HTTPS port, while the internal service may run on a different port (e.g. 33080). In this case, the relay URI should reflect the external endpoint rather than the internal service port; otherwise, it breaks a typical proxy / load balancer configuration. So the current behavior looks like a deliberate design choice for better reverse proxy compatibility, not a bug.
Sign in to join this conversation.
No Label bug self-hosting
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#8689