[Dispatcharr] Logo cache URLs generated with wrong scheme (http) and internal port (9191) when behind a reverse proxy

[frontend-report[bot]]

Script: Dispatcharr

Reported by: @snorkrat

Guidelines

• Read and understood guidelines: yes
• Verbose mode used: yes

Issue occurs during: Initial Creation / Installation

Environment

• Linux distribution: Ubuntu
• Proxmox version: 8.4
• Default settings: Yes
• Advanced settings: No
• Exact command: bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/dispatcharr.sh)"

Description

When Dispatcharr is installed via the community script and accessed through a reverse proxy (e.g. Nginx Proxy Manager) via a domain name over HTTPS, the Django backend generates incorrect cache_url values for channel logos. Instead of using the external scheme and port, URLs are built using the internal values, producing broken URLs like:http://dispatcharr.yourdomain.com:9191/api/channels/logos/1/cache/
These URLs are then requested by the browser directly on port 9191, which is not externally accessible, resulting in ERR_CONNECTION_REFUSED errors for every logo and no logos displaying in the web UI and the URLs in the cached EPG XML contain the port.

The root cause is in /etc/nginx/sites-available/dispatcharr.conf. The internal nginx (which listens on 9191 and proxies to uWSGI on 5656) uses include proxy_params in the location / block. This overwrites the X-Forwarded-Proto header set by the upstream reverse proxy with $scheme (which is http on the internal connection), and passes no X-Forwarded-Port at all. Django's build_absolute_uri() therefore sees http and port 9191 when constructing absolute URLs.

Additionally, removing include proxy_params without care causes the Host header to be set twice (once by proxy_params and once explicitly), resulting in Django receiving a duplicated value (yourdomain.com, yourdomain.com) and rejecting all requests with a 400 Bad Request error.

Steps to reproduce

1. Install Dispatcharr using the community script into a Proxmox LXC
2. Place it behind a reverse proxy (e.g. Nginx Proxy Manager) with a domain name over HTTPS on port 443
3. Access the Dispatcharr web UI via the domain
4. Open browser DevTools → Network tab → find the logos/?no_pagination=true API response
5. Observe that cache_url for every logo contains http:// and :9191, e.g.:
   http://dispatcharr.yourdomain.com:9191/api/channels/logos/1/cache/
6. Observe ERR_CONNECTION_REFUSED errors in the Console tab for every logo request
7. No channel logos are displayed in the UI

Error output

n/a

Additional context

Fix - Part 1: LXC internal nginx config

Replace the contents of /etc/nginx/sites-available/dispatcharr.conf on the LXC with the following:

map $http_x_forwarded_proto $real_forwarded_proto {
    ""      $scheme;
    default $http_x_forwarded_proto;
}

map $http_x_forwarded_port $real_forwarded_port {
    ""      $server_port;
    default $http_x_forwarded_port;
}

server {
    listen 9191;
    server_name _;
    client_max_body_size 100M;

    # Serve static assets with correct MIME types
    location /assets/ {
        alias /opt/dispatcharr/frontend/dist/assets/;
        expires 30d;
        add_header Cache-Control "public, immutable";

        types {
            text/javascript js;
            text/css css;
            image/png png;
            image/svg+xml svg svgz;
            font/woff2 woff2;
            font/woff woff;
            font/ttf ttf;
        }
    }

    location /static/ {
        alias /opt/dispatcharr/static/;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    location /media/ {
        alias /opt/dispatcharr/media/;
    }

    location /ws/ {
        proxy_pass http://127.0.0.1:8001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $real_forwarded_proto;
    }

    # All other requests proxy to uWSGI
    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $real_forwarded_proto;
        proxy_set_header X-Forwarded-Port $real_forwarded_port;
        proxy_pass http://127.0.0.1:5656;
    }
}

Then restart nginx on the LXC:

systemctl restart nginx

---

Fix — Part 2: Reverse Proxy (e.g. Nginx Proxy Manager) config

Ensure your reverse proxy is explicitly sending X-Forwarded-Port to the LXC. Without this header, the LXC nginx has no way to know the external port and falls back to its internal port (9191).

Add proxy_set_header X-Forwarded-Port $server_port; to all location blocks in the reverse proxy config provided in the Dispatcharr docs. Since NPM listens on 443 for HTTPS, $server_port will correctly be 443:

---

Why this fixes it

The map blocks provide fallback behaviour that makes the config work correctly in both direct ip:port access and reverse proxy scenarios:

• If X-Forwarded-Proto is present (sent by the reverse proxy) → use it (https); otherwise fall back to $scheme (http) which is correct for direct access
• If X-Forwarded-Port is present (sent by the reverse proxy) → use it (443); otherwise fall back to $server_port (9191) which is correct for direct access

This means:

• Via reverse proxy domain: Django sees https and 443 → builds correct URLs like https://dispatcharr.yourdomain.com/api/channels/logos/1/cache/
• Via direct IP:port: Django sees http and 9191 → builds correct URLs like http://10.0.1.44:9191/api/channels/logos/1/cache/

Removing include proxy_params eliminates the Host header duplication issue. The proxy_params file sets Host $host, and having it set again explicitly in the location block caused nginx to concatenate them into yourdomain.com, yourdomain.com, which Django rejected with a 400 Bad Request error.

[michelroegl-brunner]

This is something way out of scope of our scripts. Not all users use a Proxy for starters. Second, we can not change any NPM or other proxy settings with our scritps.

I convert this to a discussion if anyone has this issue, but the script will not reflect this changes.

[snorkrat]

Thanks for the response. To clarify, I'm not asking the script to change any NPM or external proxy configuration. The fix I'm proposing is entirely within the LXC itself, specifically to /etc/nginx/sites-available/dispatcharr.conf which I believe is generated and owned by the community script? I was just providing additional context for the entire fix from start to finish.

It's simply chaning the content of dispatcharr.confto include a mapping at the top and replacing 3 lines in the location block(s) to ensure it is compatible for those using ip:port and those using a reverse proxy.

[snorkrat]

Additionally this issue is not present in the official Dispatcharr docker container, but only within the LXC.

[snorkrat]

@michelroegl-brunner Just adding to this - Dispatcharr's own Docker nginx config sets the following headers at the server block level

proxy_set_header X-Forwarded-Host $host:$server_port;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;

And so I think it's fair to expect the LXC to be reachable in the same way as the official docker image - either via IP:PORT or via a reverse proxy. The community script's generated /etc/nginx/sites-available/dispatcharr.conf does not set these headers at all, and uses include proxy_params which overwrites X-Forwarded-Proto with $scheme from the internal connection, and never passes X-Forwarded-Port.

Again, this is not a change to any external proxy configuration, it is purely a fix to the nginx config that the community script itself generates. It makes the LXC install behave similarly to the Docker install that Dispatcharr's own developers have already correctly configured, while remaining fully backwards compatible for users accessing Dispatcharr directly via IP:port without any reverse proxy.

[snorkrat]

@michelroegl-brunner any thoughts on the above, as I feel perhaps you confused my request for me asking to change NPM or other proxy settings which is not the case.

[asylumexp]

#15293