AllBugsFeaturesChangelogSearchNew post
Sign in with Fluxer
Bugs

[Self-hosted] FLUXER_PUBLIC_PORT is ignored by several generated public endpoints when using a non-standard HTTPS port

(#700) Bug Fixed self-hosting voice
by RexSystem edited originally by @abramyangCN on GitHub

Summary

I'm self-hosting Fluxer behind Nginx Proxy Manager. My ISP blocks ports 80 and 443, so Fluxer is exposed on HTTPS port 4443. Configuration: 
FLUXER_PUBLIC_SCHEME=https
FLUXER_PUBLIC_PORT=4443
FLUXER_DOMAIN=chat.example.com
Some generated public endpoints correctly include :4443, while others ignore FLUXER_PUBLIC_PORT. For example, /.well-known/fluxer returns: api: https://chat.example.com:4443/api ✅ gateway: wss://chat.example.com:4443/gateway ✅ media: https://chat.example.com/media ❌ marketing: https://chat.example.com/ ❌ This also affects LiveKit. The client attempts to connect to: wss://chat.example.com/livekit ❌ instead of: wss://chat.example.com:4443/livekit As a result, voice channels cannot be joined when the instance is only exposed on the configured public port. I expected all generated public URLs to consistently respect FLUXER_PUBLIC_PORT.

Steps to reproduce

1. Deploy Fluxer with:
   - `FLUXER_PUBLIC_SCHEME=https`
   - `FLUXER_PUBLIC_PORT=4443`
2. Open `/.well-known/fluxer`.
3. Compare the generated endpoints.
4. Notice that some endpoints include `:4443`, while others do not.

Environment

Version: main (also reproduced on v1) Deployment: Docker Compose Reverse proxy: Nginx Proxy Manager OS: Ubuntu 24.04 Browser: Chrome

Logs or screenshots

Example response from /.well-known/fluxer: 
{
  "endpoints": {
    "api": "https://chat.example.com:4443/api",
    "gateway": "wss://chat.example.com:4443/gateway",
    "media": "https://chat.example.com/media",
    "marketing": "https://chat.example.com"
  }
}
Browser attempts to connect to: wss://chat.example.com/livekit image
  • 616818307-9bf07e14-4c06-4957-9963-052430387213.png

    616818307-9bf07e14-4c06-4957-9963-052430387213.png

    1145×592 | 266 kB

Merged posts

These posts were merged into this one. Their comments are now part of the conversation below, marked with where they came from.

Merged from #686 Voice calls and avatars do not work on non-default port

RexSystemoriginally by @naelstrof on GitHub

Report details

Summary

Attempting a voice call with FLUXER_PUBLIC_PORT set to 8080 accesses the address wss://chat.example.com/livekit/rtc/v1 instead of wss://chat.example.com:8080/livekit/rtc/v1, causing it to fail. Similarly avatars are attempted to be loaded by the same address, also failing.

Steps to reproduce

Follow the instructions at https://docs.fluxer.app/operator/get-started/ when prompted to customize .env, change FLUXER_PUBLIC_PORT to port 8080. Find that avatars, and VC do not function at this custom port.

Environment

Fluxer on Docker in an Arch VM on Proxmox.

Logs or screenshots

In this case my security policy blocked it, but only because it accesses the wrong website (wrong port) rather than it being caused by the security itself. image
  • 615078846-8be8574b-5cfb-47aa-ae73-01c02c4219ce.png

    615078846-8be8574b-5cfb-47aa-ae73-01c02c4219ce.png

    1155×300 | 115 kB

Merged from #692 Self-hosted: FLUXER_PUBLIC_PORT is ignored when generating public endpoints (HTTPS on non-standard port)

RexSystemoriginally by @abramyangCN on GitHub

Report details

Observed behaviour

Bootstrap configuration returned by the frontend: 
PUBLIC_BOOTSTRAP_API_ENDPOINT: "/api"
PUBLIC_BOOTSTRAP_API_PUBLIC_ENDPOINT: "https://chat.ayhex.com/api"
The configured port is omitted. The API container also reports: 
FLUXER_PUBLIC_SCHEME=https
FLUXER_PUBLIC_PORT=4443
However internally generated endpoints are: 
FLUXER_MARKETING_ENDPOINT=https://chat.ayhex.com
FLUXER_MEDIA_ENDPOINT=https://chat.ayhex.com/media
FLUXER_MEDIA_PROXY_UPLOAD_RELAY_ENDPOINT=https://chat.ayhex.com/media
None of them include :4443. As a result, the browser attempts to connect to: 
wss://chat.ayhex.com/...
instead of 
wss://chat.ayhex.com:4443/...
Voice channel connection therefore fails. Expected behaviour Generated public endpoints should include the configured port. For example: 
https://chat.ayhex.com:4443/api
https://chat.ayhex.com:4443/media
wss://chat.ayhex.com:4443/gateway
wss://chat.ayhex.com:4443/livekit

Details

Summary
When deploying a self-hosted Fluxer instance behind a reverse proxy on a non-standard HTTPS port (4443), FLUXER_PUBLIC_PORT appears to be ignored when generating public endpoints. As a result, the web application is accessible, but WebSocket/LiveKit connections fail because
Steps to reproduce
Additional information
The application itself is reachable via: 
https://chat.ayhex.com:4443
The issue only affects internally generated public URLs. Is deployment on a non-standard HTTPS port currently unsupported, or is this a bug where FLUXER_PUBLIC_PORT is not being used during endpoint generation?
Environment
Environment
  • Fluxer: v1 (ghcr.io/fluxerapp/*:v1)
  • Docker Compose (official self-host deployment)
  • Ubuntu 24.04
  • Reverse proxy: Nginx Proxy Manager
  • HTTPS exposed on port 4443
  • 80/443 are unavailable from the ISP
Configuration
FLUXER_BASE_DOMAIN=chat.ayhex.com
FLUXER_PUBLIC_SCHEME=https
FLUXER_PUBLIC_PORT=4443

3 comments

Sign in with Fluxer to comment and vote.
Comment by @abramyangCN
RexSystem 1 vote originally by @abramyangCN on GitHub OP
I managed to get Fluxer working behind Nginx Proxy Manager on a non-standard HTTPS port (4443). Until there's an official fix or recommendation, I had to update the public endpoint URLs in deploy/self-hosting/docker-compose.yml to include :${FLUXER_PUBLIC_PORT}. For example: 
FLUXER_MARKETING_ENDPOINT=${FLUXER_PUBLIC_SCHEME}://${FLUXER_DOMAIN}:${FLUXER_PUBLIC_PORT}
FLUXER_MEDIA_ENDPOINT=${FLUXER_PUBLIC_SCHEME}://${FLUXER_DOMAIN}:${FLUXER_PUBLIC_PORT}/media
FLUXER_MEDIA_PROXY_UPLOAD_RELAY_ENDPOINT=${FLUXER_PUBLIC_SCHEME}://${FLUXER_DOMAIN}:${FLUXER_PUBLIC_PORT}/media
...
I also set: 
FLUXER_LIVEKIT_URL=${FLUXER_PUBLIC_SCHEME}://${FLUXER_DOMAIN}:${FLUXER_PUBLIC_PORT}/livekit
This resolved the missing port issues in my deployment. I'm not sure if this is the intended configuration, but it may help anyone deploying behind a reverse proxy on a non-standard HTTPS port.
Permalink
Deleted comment
Removed by moderator Rex: Removed a general status note that was posted on many GitHub threads. It no longer applies here.
Deleted comment
Removed by moderator Rex: Removed a general status note that was posted on many GitHub threads. It no longer applies here.
Deleted comment
Removed by moderator Rex: Removed a duplicate of an identical comment the same author posted just before