Subsonic - 502 errors proxying to self-signed backend

Help
1

Hello!

I’m trying to set up a reverse proxy for Subsonic, to take advantage of caddy’s awesome automatic SSL support. I’m having a few issues, though.

I first set up the proxy to subsonic via http. This worked fine when I added the transparent keyword to my caddyfile. However, all links generated by the subsonic app were http, so firefox would refuse to load them due to being mixed content. (I presume they would have redirected to https versions if firefox HAD tried to load them, right?)

So after that I enabled subsonic’s https mode, which comes with a self signed cert. It’s running on port 8443, and if I tell wget to ignore the self signed cert, it can connect to localhost:8443 fine. When I told caddy to do the same:

        proxy / localhost:8443 {
        transparent
        insecure_skip_verify
        }

I just get http 502 errors.

Nothing seems to appear in the caddy logs when I load the page.

Here’s the entirety of my log file (these lines repeated):

Mar 27 00:23:25 hostname caddy[15112]: 2018/03/27 00:23:25 [INFO] Done checking OCSP staples
Mar 27 00:29:52 hostname caddy[15112]: 2018/03/27 00:29:52 [INFO] my.ip.here - No such site at :80 (Remote: someone.else, Referer: )

Any ideas? Thanks for your time!

EDIT: Hmm, just noticed that the initial redirect that subsonic does from / to /index.view DOES still happen, and after that I hit the 502.

2

Hi @ripdog - to help us find out what’s wrong, could you post:

  1. Your full Caddyfile
  2. The results of curl -kIL localhost:8443 from the Caddy host
3

Thanks for the reply.

Here’s the curl command (I had to add https:// to it or i got curl: (8) Weird server reply):

% curl -kIL https://localhost:8443
HTTP/1.1 302 Found
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=16vh5eky9c4ia;Path=/
Location: https://localhost:8443/login.view;jsessionid=16vh5eky9c4ia?
Content-Length: 0
Server: Jetty(6.1.x)

HTTP/1.1 200 OK
Content-Language: en
Content-Type: text/html; charset=utf-8
Content-Length: 0
Server: Jetty(6.1.x)

My caddyfile was basically all in the OP, but here it is, with my domain removed:

example.com {
        tls me@example.com
        proxy / localhost:8443 {
        transparent
        insecure_skip_verify
        }

}

import caddy.conf.d/*.conf

There’s nothing in caddy.conf.d.

The caddyfile is called caddy.conf because that’s the default in archlinux.

4

Try replicating this change to your Caddyfile.

Also, consider using the log and errors directives, the latter may be particularly helpful in cases of 502s since it can shed some light on why Caddy can’t talk to the upstream.

https://caddyserver.com/docs/log
https://caddyserver.com/docs/errors

5

Adding https sounded like a very promising suggestion, but sadly no dice. One thing I did learn was that the redirect from / to /index.view happens even when subsonic is not running. Does caddy do some kind of caching of that sort of thing?

After I added the log and error directives, though, caddy started failing to recieve the SAN bundle during startup.

EDIT: Excuse all that rubbish. I didn’t understand the caddyfile format and put log and error outside of my domain block. I put them inside and now caddy is working again.

Here’s the error: caddy[4071]: 28/Mar/2018:11:25:04 +1300 [ERROR 502 /index.view] dial tcp [::1]:8443: connect: connection refused

I noted that it was using ipv6, and perhaps the subsonic server was unhappy about that? So I changed localhost to 127.0.0.1 and no change:

caddy[4095]: 28/Mar/2018:11:27:53 +1300 [ERROR 502 /index.view] dial tcp 127.0.0.1:8443: connect: connection refused

It seems that Firefox was caching the redirect from / to /index.view, as it doesn’t appear in either access or error logs from caddy nor does it happen in a private browsing window. In either case, it doesn’t matter because / gives a 502 as well.

From access.log:

[28/Mar/2018:11:29:27 +1300] "GET / HTTP/2.0" 502 16

and the error on /:

caddy[4095]: 28/Mar/2018:11:30:23 +1300 [ERROR 502 /] dial tcp 127.0.0.1:8443: connect: connection refused

EDIT 2: Oh my god, subsonic had somehow closed its sockets while still running! How?! Why?! Anyway, I restarted it, and now it’s working. It must have been the https://. I’m going to make a pull request for the docs to add an example for using https:// on the backend specifier to help stop others like me falling into this trap.

Thank you so much for your help. You’re doing amazing work here.

1 Like
6

No worries. I had a hunch it was the case, but wasn’t 100% sure - you’re using a non-standard HTTPS port and didn’t specify scheme, which leaves behind a kind of “implicit HTTP”; naturally, talking HTTP to a HTTPS listener won’t get you far!

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.