#179 Subsonic 6.0 does not work behind a reverse proxy

[Anonymous]

Using an external player with Subsonic behind a reverse proxy does not work anymore as of 6.0-beta1. The same thing worked just fine with 5.x.
When attempting to set the external URL in Settings -> Network, it says:

Status: https://sub.mydomain.dk responded successfully, but could not authenticate it.

The setting seems to stick in the settings pane, but it never takes effect. The web player works, but when using an external playlist, the given track URL uses the internal address (http://sub.mydomain.dk:4040) instead of the externally accessible one, resulting in a playback error when not on the same network.
I don't know if this issue is only occurring when using HTTPS, but nowadays most people should be using that anyway. I have also tried the same URL with http:// (which in my case yields a 301 redirect), but exactly the same thing happened.

I'm using the following Nginx config for the reverse proxy:

server {
  listen 80;
  server_name sub.mydomain.dk sub;
  return 301 https://sub.mydomain.dk$request_uri;
}

server {
  listen 443 ssl;
  server_name sub.mydomain.dk;
  ssl_certificate /etc/letsencrypt/live/sub.mydomain.dk/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/sub.mydomain.dk/privkey.pem;
  keepalive_timeout 0;
  add_header Strict-Transport-Security max-age=31536000;

  access_log /var/log/nginx/subsonic-access_log main;
  error_log /var/log/nginx/subsonic-error_log;

  location / {
    proxy_pass http://10.22.22.6:4040;
    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 http;
    proxy_redirect http:// https://;
    proxy_max_temp_file_size 0;
  }
}

[Anonymous]

I should add that I am using the Android app both on my phone and in my car without any problems whatsoever. For some reason this issue only happens when grabbing .m3u files via the browser.

[Sindre Mehus]

Fixed (hopefully) in the next beta.

Thanks for the report!
Sindre

[Anonymous]

This is still an issue for me using the release version of Subsonic 6. Please let me know how I can help, happy to share any debug or config information you'd like.

[Anonymous]

I can confirm Subsonic isn't working properly behind a revers proxy with SSL.
My Subsonic server is working in HTTP behind a Nginx Reverse Proxy providing SSL for this server.
I don't want to activate SSL directly on my Subsonic server so this is perfectly intentional.
Problem is that Subsonic doesn't seem to understand it is in HTTPS mode and thus, using URLs in the HTTPS scheme and I didn't find a way to tell Subsonic to work that way.
Most of the app works pretty well in this configuration except a few URLs such as the "Playing" view and the calls to last.fm for the artists covers where I get this :

Mixed Content: The page at 'https://subsonic.mydomain.com/index.view' was loaded over HTTPS, but requested an insecure image 'http://img2-ak.lst.fm/i/u/174s/1eb194d3a56bdc8f1976eb279de62f74.png'. This content should also be served over HTTPS.

Mixed Content: The page at 'https://subsonic.mydomain.com/index.view' was loaded over HTTPS, but requested an insecure resource 'http://subsonic.mydomain.com/main.view?id=20579'. This content should also be served over HTTPS.

Would be nice if Subsonic would handle the X-Forwarded-Proto header or maybe an explicit configuration setting so that it would understand it has to replace every "HTTP" by "HTTPS" in its generated URLs (for internal links and external ones such as the links to Last.fm resources).

Regards.

[Anonymous]

This issue is not fixed. Could you please reopen and investigate?

[Anonymous]

Here i'm waiting for this too.

[Anonymous]

for me it works with:

        location /subsonic {
            proxy_pass http://localhost:4040/subsonic;
            proxy_set_header Host $host;
            proxy_buffering off;
        }

[Anonymous]

I also have this issue !

Please take the X-Forwarded-Proto request header into account when generating the links in responses from Subsonic, as per this RFC : https://tools.ietf.org/html/rfc7239

[Rian Goolaub]

This needs to be repopened as it is not fixed. Sindre, could you have a look please?

[Anonymous]

I would love for this to be functional, as I'm doing the same thing; nginx reverse proxy for SSL. I'm running Subsonic on an ARMv7, and its own SSL bindings cause security errors in modern browsers (whereas nginx does not have this problem). I am not using a subdirectory, just a port dedicated to Subsonic (the default 4043). The Subsonic web interface works fine, but the Android app and Jamstash do not. :(

[Nicolai Syvertsen]

I was able to make it work with SSL by also having Subsonic listen to SSL and using this nginx config:

server {

    # ssl
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name subsonic.example.com;

    ssl_certificate /etc/letsencrypt/live/subsonic.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/subsonic.example.com/privkey.pem;


    location / {
        proxy_pass https://subsonicvm:443;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
        proxy_set_header Host $host:443;
        proxy_set_header X-Forwarded-Proto https;
    }
}

[Will Timpson]

Nicolai, thank you so much for your post! I just spent the better part of an hour trying to figure this out. It was particularly frustrating since I have my nginx reverse proxy set up to 301 all http requests to https, which meant that subsonic wasn't even serving musicFolderSettings.view (the 'insecure' element that chrome was complaining about for me) over http anyway! I've seen a bunch of posts around the web explaining how to set up subsonic behind an nginx reverse proxy (and i've done it myself before, maybe chrome is just getting stricter about this type of thing?), but none of them mentioned this particular wrinkle. I know that subsonic has built-in https support, but I think that it would be useful to include an official write-up on setting up an nginx reverse proxy as well, since it is much easier to secure your install with letsencrypt that way!

[Anonymous]

Hi, setting up SSL on subsonic defeats the purpose. Connecting to Apache or Nginx over SSL, which then reverse proxies the encoded packets from subsonic and re-encodes them over another SSL is serious overhead.

With SSL enabled on the reverse proxy and standard 4040 enabled for local traffic, even the play button is not usable - it stays in a spinning gif. Settings pages are only available if the frame is placed in a new tab - not ideal.

Please can you take a look? If I have set up my custom domain as https://subsonic.mydomain.com in the subsonic network settings, perhaps this should be the basis of detecting reverse proxy setup?

Many thanks.

[Will Timpson]

Hey there Anonymous. As it happens, running encrypted connections on the internal network doesn't at all defeat the purpose. In fact, for many of the big players in the industry, encrypting internal network services is key to the purpose. Even if you don't need to, it certainly does not introduce "serious overhead" as you suggest. In fact, you almost certainly won't even notice it.

The behavior that you are experiencing is due to the fact that up-to-date browsers won't load http links on sites that profess to be https only. When Subsonic generates its pages, it uses http links
unless you explicitly turn https on. Thats why nothing works. If you look at the web page source you will see that the links to load the settings pane (for example) is included as http://subsonic.yourdomain.com/settings.view, which your browser will refuse to load. The player app is doing the same thing, that's why it won't play anything. If, however, you put that address directly into your browser, it will be redirected by nginx to https://subsonic.yourdomain.com/settings.view, which works fine. If you turn on https in your Subsonic config, and point nginx at the specified port, you will discover that Subsonic is now serving pages that include https links. This is totally cool by your browser and your site will work fine.

So, in summary, there is no reason not to run https on your internal network. If you do, you will find that Subsonic magically works. I only wish that this was documented in the official Subsonic documentation.

[Anonymous]

The correct solution is for Subsonic to honor the X-Forwarded-Proto HTTP header that a reverse proxy can pass to Subsonic and sends back correct URLs based on that.
My workaround works because when you enable SSL on Subsonic itself it does use correct URLs. On my server the overhead doesn't matter much. It is local traffic on the server anyways.

[Anonymous]

The internal URLs are still being re-written incorrectly. I am unsure why the URLs on the left panel need to be protocol specific at all. In the case of settings, I can actually get the page to render fine if I just call "showPage('musicFolderSettings.view');" directly in the console.

As far as the settings redirect is concerned, it looks like it's taking place in a controller somewhere and it should likely be changed to a relative URL.

The other links on the left side appear to redirect correctly.

[andocromn]

I found a solution to this setup here
https://serverfault.com/questions/372886/prevent-nginx-from-redirecting-traffic-from-https-to-http-when-used-as-a-reverse

The setting to fix this issue for me was
proxy_redirect http:// $scheme://;

[Anonymous]

[Anonymous]

[Anonymous]

This feels like a bit of a hack and probably doesn't really add any security but with my install, I am using Tomcat and didn't feel like setting up TLS on Tomcat itself. I modified my nginx config to put a 302 to the https page for /login and then forced everything back to http afterwards as I am mostly concerned about sending actual credentials in the clear; don't care as much about a token.

[Anonymous]