Nginx returning file download

[engiqueering]

I've set up and configured a Jellyfin server and am able to access the web portal by visiting localhost:8096 and when I opened the Roku app on a device connected to my local network it found the server immediately.

I want to share access to this with some family so I set up an nginx server and am trying to connect it to a subdomain (I had someone check that the DNS records are fine), however I am running into an error where nginx is trying to serve a downloadable file when I attempt to open the web portal at both localhost and the subdomain address. I can still access the Jellyfin server so the issue seems to be with the nginx configuration (changes at the bottom of this post)

Is this a common error, and if so does anyone have a suggestion on how to fix it?

jellyfin.conf:

Code:

# Uncomment the commented sections after you have acquired a SSL Certificate
server {
    listen 80 http2;
    listen [::]:80 http2;
    # server_name DOMAIN_NAME;

    # Uncomment to redirect HTTP to HTTPS
    # return 301 https://$host$request_uri;
#}

#server {
    # listen 443 ssl;
    # listen [::]:443 ssl;
    server_name [color=#000000][REDACTED][/color];

    ## The default `client_max_body_size` is 1M, this might not be enough for some posters, etc.
    client_max_body_size 20M;

    # Uncomment next line to Disable TLS 1.0 and 1.1 (Might break older devices)
    # ssl_protocols TLSv1.3 TLSv1.2;

    # use a variable to store the upstream proxy
    # in this example we are using a hostname which is resolved via DNS
    # (if you aren't using DNS remove the resolver line and change the variable to point to an IP address e.g `set $jellyfin 127.0.0.1`)
    set $jellyfin jellyfin;
    resolver 127.0.0.1 valid=30s;

    #ssl_certificate /etc/letsencrypt/live/DOMAIN_NAME/fullchain.pem;
    #ssl_certificate_key /etc/letsencrypt/live/DOMAIN_NAME/privkey.pem;
    #include /etc/letsencrypt/options-ssl-nginx.conf;
    #ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
    #add_header Strict-Transport-Security "max-age=31536000" always;
    #ssl_trusted_certificate /etc/letsencrypt/live/DOMAIN_NAME/chain.pem;
    #ssl_stapling on;
    #ssl_stapling_verify on;

    # Security / XSS Mitigation Headers
    # NOTE: X-Frame-Options may cause issues with the webOS app
    #add_header X-Frame-Options "SAMEORIGIN";
    #add_header X-Content-Type-Options "nosniff";

    # COOP/COEP. Disable if you use external plugins/images/assets
    #add_header Cross-Origin-Opener-Policy "same-origin" always;
    #add_header Cross-Origin-Embedder-Policy "require-corp" always;
    #add_header Cross-Origin-Resource-Policy "same-origin" always;

    # Permissions policy. May cause issues on some clients
    add_header Permissions-Policy "accelerometer=(), ambient-light-sensor=(), battery=(), bluetooth=(), camera=(), clipboard-read=(), display-capture=(), document-domain=(), encrypted-media=(), gamepad=(), geolocation=(), gyroscope=(), hid=(), idle-detection=(), interest-cohort=(), keyboard-map=(), local-fonts=(), magnetometer=(), microphone=(), payment=(), publickey-credentials-get=(), serial=(), sync-xhr=(), usb=(), xr-spatial-tracking=()" always;


    # Content Security Policy
    # See: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
    # Enforces https content and restricts JS/CSS to origin
    # External Javascript (such as cast_sender.js for Chromecast) must be whitelisted.
    # NOTE: The default CSP headers may cause issues with the webOS app
    #add_header Content-Security-Policy "default-src https: data: blob: http://image.tmdb.org; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' https://www.gstatic.com https://www.youtube.com blob:; worker-src 'self' blob:; connect-src 'self'; object-src 'none'; frame-ancestors 'self'";

    location = / {
        return 302 http://$host/web/;
        #return 302 https://$host/web/;
    }

    location / {
        # Proxy main Jellyfin traffic
        proxy_pass http://$jellyfin:8096;
        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 $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;

        # Disable buffering when the nginx proxy gets very resource heavy upon streaming
        proxy_buffering off;
    }

    location /socket {
        # Proxy Jellyfin Websockets traffic
        proxy_pass http://$jellyfin:8096;
        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 $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
    }
}

[TheDreadPirate]

Remove the 302 redirect block.

And I'm assuming that Nginx is running on the same host as Jellyfin?

[engiqueering]

I commented out this part:

Code:

#location = / {
    #    return 302 http://$host/web/;
        #return 302 https://$host/web/;
    #}

and restarted nginx, however I'm still getting the same results when trying to open localhost

Did I need to comment out any of the proxy-set-header lines as well?

---

Also yes, I'm running nginx on the same machine as jellyfin

[TheDreadPirate]

Try changing this line

Code:

set $jellyfin jellyfin;

To

Code:

set $jellyfin 127.0.0.1;

[engiqueering]

Tried and restarted nginx, no luck.

[TheDreadPirate]

You are linking your config in sites-enabled, correct?

Here is my config for reference (https).

https://sourceb.in/yTuuEsQHFw

[engiqueering]

I created a symlink from /etc/nginx/conf.d/jellyfin.conf to /etc/nginx/sites-enabled/jellyfin.conf, is that sufficient? Some of this is new territory for me

[TheDreadPirate]

Generally your actual config files are in sites-available. Then you symlink your active sites to sites-enabled. Don't think it matters, but that is the standard practice.

[engiqueering]

After messing around with it for a while, I copy/pasted your config over mine and made adjustments for it to work with my domain, network, and SSL cert and it seems to be working perfectly fine now

I appreciate the help. I never figured out why it was doing what it was sending files, but a solution is a solution!