2
  • I have a Deluge client (in a docker container - that's likely irrelevant).
  • I want to be able to connect to the daemon from the outside world while having it behind a reverse proxy.
  • I don't necessarily need TLS, but I suspect http2 may require it.

What works:

  • connecting locally on the network to the Deluge RPC with a Deluge desktop, Android and WebUI client works well.
  • sending requests to the nginx server is OK (I can see logs as I hit nginx)
  • All the networking around (firewalls, port forwardings, DNS are fine)

What doesn't work:

  • Deluge client can't connect to the http server

nginx config:

server {
    
    server_name deluge.example.com;
    listen 58850;
 
    location / {
        proxy_pass grpc://localhost:58846;
    }

    ssl_certificate /etc/ssl/nginx/example.com.pem;
    ssl_certificate_key /etc/ssl/nginx/example.com.key;  

    proxy_request_buffering off;
    gzip off;
    charset utf-8;

    error_log  /var/log/nginx/nginx_deluge.log debug;

}

Major edit:

As it turns out, I believed the JSON RPC and gRPC are more similar than just the "RPC" in the name. Hence my "original" issue "nginx deluge rpc doesn't work", is no longer relevant. Unfortunately, the "same" issue still prevails. I still can't connect to the proxy even when using a regular HTTP proxy while I can make HTTP requests locally. I will surely post an update or even an answer should I figure it out in the next days...

When I try to connect with the Deluge client, I get this error message in the log file:--

2022/06/14 16:59:55 [info] 1332115#1332115: *7 client sent invalid method while reading client request line, client: <REDACTED IPv4>, server: deluge.example.com, request: " Fu�Uq���U����a(wU=��_`. a��¹�(���O����f�"
2022/06/14 16:59:55 [debug] 1332115#1332115: *7 http finalize request: 400, "?" a:1, c:1
2022/06/14 16:59:55 [debug] 1332115#1332115: *7 event timer del: 17: 243303738
2022/06/14 16:59:55 [debug] 1332115#1332115: *7 http special response: 400, "?"
2022/06/14 16:59:55 [debug] 1332115#1332115: *7 http set discard body
2022/06/14 16:59:55 [debug] 1332115#1332115: *7 HTTP/1.1 400 Bad Request
Server: nginx/1.22.0
Date: Tue, 14 Jun 2022 16:59:55 GMT
Content-Type: text/html
Content-Length: 157
Connection: close

When I change the line listen 58850; to listen 58850 http2;, as I probably should, I get the following error: (log verbosity set to "debug")

2022/06/14 15:04:00 [info] 1007882#1007882: *3654 client sent invalid method while reading 
client request line, client: <REDACTED IPv4>, 
server: deluge.example.com, request: "x�;x��;%157?O/3/-�@�D��"

The gibberish there is seemingly identical when trying to connect from a different network from a different device. It was Dx�;x��;%157?O/3/-�@�E�, (there is a D as first character now) but all other attempts are again without the leading D.

or this error: (log verbosity set to "info")

2022/06/14 17:09:13 [info] 1348282#1348282: *14 invalid connection preface while processing HTTP/2 connection, client: <REDACTED IPv4>, server: 0.0.0.0:58850

I tried decoding the gibberish between various encodings, in hoping it would be just bad encoding of a better error message or a lead to a solution. I looked through the first two pages of Google hoping the error messages were pointing me to a solution someone else has had to my problem.

environment:

  • Docker version 20.10.17, build 100c70180f
  • nginx version: nginx/1.22.0
  • deluged 2.0.5
  • libtorrent: 2.0.6.0
Dan
  • 175
  • 1
  • 13
  • 1
    Are you sure the deluge API speaks gRPC? As far as I can tell, it's using a bespoke protocol with rencode encoded payloads. https://deluge.readthedocs.io/en/latest/reference/rpc.html. You may want to try a different nginx configuration, not gRPC-specific. – drfloob Jun 22 '22 at 17:51
  • @drfloob yes, yes! As I was diving into the RPC rabbit hole, I knew something was off. You are right. the "JSON RPC" is not the gRPC which I was foolishly mistaking it for. What doesn't help, is that I have the exact same issue when setting nginx to a HTTP proxy. Thank you, and the investigation continues... – Dan Jun 25 '22 at 20:24

0 Answers0