Skip to content

Comments

Reverse proxy support#1373

Closed
tbshfr wants to merge 4 commits intobitaxeorg:masterfrom
tbshfr:feat/reverse-proxy
Closed

Reverse proxy support#1373
tbshfr wants to merge 4 commits intobitaxeorg:masterfrom
tbshfr:feat/reverse-proxy

Conversation

@tbshfr
Copy link

@tbshfr tbshfr commented Nov 19, 2025

This allows the web ui / API to be accessed behind a reverse proxy with https. It also enables access by hostname (when the hostname resolves to a private IP address via LAN/DNS. This change does not add mDNS support).

It uses the standard X-Forwarded-For header behind a reverse proxy.
This header can be spoofed but this must be handled by the proxy (validating or stripping), not here.
The reverse proxy (immediate peer) must be on a private network and the client IP (from X-Forwarded-For) must also be from a private network.
This enables typical setups where https terminates at the proxy and the proxy forwards requests to the device over the local network. I tested it behind traefik and nginx.

Unfortunately i cant test swarm mode, but from what i saw in other PRs, I dont think swarm mode will work behind a reverse proxy if other devices are on an older firmware version.
ipv6 only proxies are not supported but ipv6 only networks are also not supported currently, so this should not be a regression.

@tbshfr
Copy link
Author

tbshfr commented Nov 19, 2025

Just noticed that this also breaks the swarm view for a single bitaxe - it no longer detects itself. I will look into how to fix this

@WantClue WantClue requested a review from eandersson November 19, 2025 20:47
@tbshfr
Copy link
Author

tbshfr commented Nov 20, 2025

The swarm page should now work again, with some limitations:

  • older device versions may not be addable if the ui is accessed via hostname or behind a proxy (ip should still work, if someone could test this would be great)
  • if its accessed by hostname or proxy, auto scanning is disabled
  • if the ui is accessed over https, you can only add other devices to the swarm if they are also accessible over https (mixed content blocking), I added warnings for this in the ui

The swarm page still needs some cleanup. I think it would be best to only allow adding devices via ip addresses when the ui is accessed by ip to keep the old behavior and avoid confusion.

Would appreciate quick feedback / input before I proceed with cleanup.

@mutatrum
Copy link
Collaborator

mutatrum commented Dec 2, 2025

We currently have #1240, which is planned for v2.13. If that is added, is this PR then still valid?

@tbshfr
Copy link
Author

tbshfr commented Dec 8, 2025

According to the last comment it only covers .local, so this wont work behind a reverse proxy with a subdomain on a normal domain. I will close this PR and wait until the other one is merged, if this is still relevant I will open a new one based on the other PR.

@tbshfr tbshfr closed this Dec 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants