[BUG] [GUESS] Login to Server behind reverse-proxy problematic

[9SMTM6]

So, I can use this application only one way: If I'm in my local network and use SERVER_IP:HTTP_PORT to find the application (does NOT work with the HTTPS port apparently) (its run as a docker container, its an Unraid-server and its running your version with usual community template and no modifications from me). The moment I use the URL - from the local network or remote - I cant login. Take note that that works with the Website both on Android and a Laptop in both local network and remote. Even the FireTV application works - though due to its UI only with "visible" Accounts?.

So, since that is hard to extract from the Paragraph, and theres still Information missing:

Setup:

• Unraid Server
• Official Docker-Container with the Community Template - default port settings (exposed 1900/UDP, 8096/TCP, 8920/TCP)
• on a custom network with letsEncrypt docker (443/TCP:1443 and 80/TCP:180 forwarded, the base ports conflict with the Unraid webgui).
• Letsencrypt validates my dynamicdns subdomains, config is from the templates with adjusted subdomain, I'll append the config further down, but AFAIK it simply matches the subdomains and forwards the traffic on the jellyfish subdomain to jellyfish:8096 on the docker network. It does this for a few other applications too btw.
• on my router I forward 443/TCP:1443 and 80/TCP:180 to my server
• in the jellyfin settings I followed the advise in the letsencrypt template and tried to adjust the "Public HTTPS port number" to both 443 or 1443 (because of the port-switcheroo between the router and the letsencrypt I'm not sure what would be correct). IIRC both worked fine for remote website access, none worked for the Android app. I also set "Secure connection mode" to "Handled by reverse proxy"
• Versionen: Android-App v 0.9.9 (latest on the Play-Store), Jellyfin v 10.5.0 (current latest tag on docker).

# letsencrypt/nginx/proxy-confs/jellyfin.subdomain.conf

# make sure that your dns has a cname set for jellyfin
# if jellyfin is running in bridge mode and the container is named "jellyfin", the below config should work as is
# if not, replace the line "set $upstream_app jellyfin;" with "set $upstream_app <containername>;"
# or "set $upstream_app <HOSTIP>;" for host mode, HOSTIP being the IP address of jellyfin
# in jellyfin settings, under "Advanced/Networking" change the public https port to 443, leave the local ports as is,
# and set the "Secure connection mode" to "Handled by reverse proxy"

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name [my jellyfin subdomain].*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app jellyfin;
        set $upstream_port 8096;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_set_header Range $http_range;
        proxy_set_header If-Range $http_if_range;
    }

    location ~ (/jellyfin)?/socket {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app jellyfin;
        set $upstream_port 8096;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $http_connection;
   }
}

Works:

• Any combination of Visible and Invisible Account using the Webclient to LOCAL_SERVER_IP:HTTP_PORT (within the local network) or my Url (local or remote) on Desktop and Android.
• The FireTV client when using the Visible Account using the URL from the local network (i didnt try the IP address nor from remote networks, dont think that would tell me anything of worth)
• The Android client using LOCAL_SERVER_IP:HTTP_PORT in the local network (only tried that with an invisible account)

Doesn't work:

• LOCAL_SERVER_IP:HTTPS_PORT on both the webclient and Android client doesnt connect to the server (that should not work anyways I believe?)
• URL on both remote and the local network CONNECTS to the client, and even shows the visible accounts, but when you try to login in with either a visible or an invisible account it fails with an connection error (the same error pops up when I use fake credentials)

Concluding thoughts

First of all I want to highlight that letsEncrypt is, at least from my understanding, not generating "self-signed" certificates, but itself/using a trusted CA for its certificates, so this should not be connected to the issues #217, #193.

Then, I will experiment further to fix these issues, but at this point, even if the issues can be fixed with a better Setup, I would say that, especially considering that the website and the FireTV apps work fine, this Issue should be looked into and be fixed, unless there's a good reason.

Finally, I'm not an expert on these topics, so sorry If I misrepresented something, I usually know just enough of that stuff to get around, never had a formal introduction.

[nielsvanvelzen]

Even the FireTV application works - though due to its UI only with "visible" Accounts?.

The FireTV/AndroidTV app supports hidden users but the UI doesn't make this clear enough, we're working on this.

URL on both remote and the local network CONNECTS to the client, and even shows the visible accounts, but when you try to login in with either a visible or an invisible account it fails with an connection error (the same error pops up when I use fake credentials)

Did you check the "Allow remote connections to this Jellyfin Server." checkmark in the profiles for the users and the same checkbox in the (advanced) networking settings?

[9SMTM6]

Did you check the "Allow remote connections to this Jellyfin Server." checkmark in the profiles for the users and the same checkbox in the (advanced) networking settings?

Otherwise it should not be able to connect via Webbrowser from remote. But yeah, I checked again, to be sure, and it's set everywhere. The (currently 2) accounts and the networking settings.

[Nazar78]

Think there's a misconfiguration on your conf at the socket upstream which is being used for the authentication. Correct one below:

proxy_pass $upstream_proto://$upstream_app:$upstream_port/socket;

[9SMTM6]

@Nazar78 Sorry for the slow reaction, couldn't find time for it immediately and then forgot about it.

You're not wrong that the path does get changed there (it would potentially be slightly already anyways, as that's pretty rough matching from my understanding), but when I interpreted your comment right in targeting the block

location ~ (/jellyfin)?/socket

then no, this unfortunately didn't change anything in my testing.

BTW, the iPhone App can be added to the Client's that work without issue.

[Nazar78]

@9SMTM6 No problem.

I'm not referring to the location path but the upstream path. From the config that you've posted, you passed the incoming socket to the upstream root instead of root/socket. As stated in the official docs, see the "/socket" (remove the quotes) below which you missed out. I've no issue with my reverse-proxy setup https(443)->https(nginx:1443)->http(jellyfin:8096) and even added pull CDN to serve the webp images.

location ~ (/jellyfin)?/socket {
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;
    set $upstream_app jellyfin;
    set $upstream_port 8096;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port"/socket";

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
}

[9SMTM6]

@Nazar78 thanks for the explanation, but it seems I was a little to sparse in my explanation now, as that is what I did. My text meant to explain that I changed that line in the mentioned block and not in the location / block that is (with the error) identical.