Reverse proxy for Transmission

Help
1

I’m trying to configure Caddy 1.0-beta1 to act as a reverse proxy to Transmission 2.94, running in a separate jail in my FreeNAS server. It works for several other applications (Sonarr, Radarr, NZBGet, etc.), but when I try to load Transmission, I get this instead:

image
image736×281 20 KB

The relevant section in my Caddyfile reads:

proxy /transmission http://192.168.1.15:9091 {
        transparent
}

I found an earlier thread mentioning this error, but I’m afraid I don’t understand the resolution:

What am I missing?

2

Looks like the other poster’s configuration actually this:

proxy /transmission http://localhost:9091/transmission/web {
  transparent
}

They said that they had this issue until they navigated manually to /transmission/web because it wasn’t redirecting to it properly.

I wonder if it would be prudent to try something like this:

redir /transmission /transmission/web
proxy /transmission/web http://192.168.1.15:9091/transmission/web {
  transparent
}
3

That’s now giving me 404s. Relevant section of Caddyfile:

redir /transmission /transmission/web
proxy /transmission/web http://192.168.1.15:9091/transmission/web {
        transparent
}

…and the access.log:

192.168.1.147 - - [17/Apr/2019:19:47:15 -0400] "GET /transmission/ HTTP/2.0" 404 38
192.168.1.147 - - [17/Apr/2019:19:48:05 -0400] "GET /transmission/ HTTP/2.0" 301 77
192.168.1.147 - - [17/Apr/2019:19:48:05 -0400] "GET /transmission/web/ HTTP/2.0" 404 108

It’s looking like the 404 is actually coming from the Transmission instance, though:
image
I say that because nothing in the Caddy configuration is pointing to /usr/local/share/anything–its root is in /usr/local/www.

4

Ahh, yeah… Try without /transmission/web on the upstream.

5

OK, making progress. The Transmission GUI now loads, but I immediately get this dialog:
image
When I click on the Details button, I get this:
image

That block in my Caddyfile currently looks like:

redir /transmission /transmission/web
proxy /transmission/web http://192.168.1.15:9091 {
        transparent
}
6

Hmm, this is familiar… I actually wrote a bit about this on these forums in the past.

The important points to take away from what we discovered previously:

  1. The RPC endpoint is different to the web endpoint, so this strategy of proxying /transmision to /transmission/web isn’t going to work at all, I think.

  2. I’d strongly recommend seeing if jpillora/cloud-torrent will meet your requirements as a replacement for Transmission.

7

Interesting. If I’m understanding the linked thread correctly, this could work if I set up a separate host for Transmission, but it doesn’t look doable in the way that I’ve been trying. I could set up a separate host, but maybe I’ll investigate other client options first. Thanks for all the help.

1 Like
8

Dan, same message, same error here.
Set up Deluge just fine, but Transmission is simply stubborn :wink:

9

This is how it works for me:

http://transmission.test.com:8963 {
import gzipconf
import addheader
proxy / http://192.168.1.176:9091 {
keepalive 32
transparent
websocket
}
}

10

Hey @giopas, what’s in your gzipconf and addheader snippets you’re importing into that one?

One other significant difference might be the fact that you’re proxying an entire subdomain from the webroot instead of trying to put Transmission in a subfolder.

11

This is what I have:

(gzipconf) {
gzip {
ext *
level 7
min_length 1
}
}

(addheader) {
header / {
Strict-Transport-Security “max-age=31536000;”
X-XSS-Protection “1; mode=block”
X-Content-Type-Options “nosniff”
X-Frame-Options “DENY”
Referrer-Policy “strict-origin-when-cross-origin”
-Server
}
}

For info, I am using Caddy and Transmission on a qnap Nas (actually, each on a different nas), using a community based repository.

12

Yeah, seems super straightforward. My guess is that the lack of subfolder is probably key.

13

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