deluge ignoring proxy settings

[rm]

Good day.

I fail to using deluge 1.3.5 in proxy environment (w/o autorization). It worked fine in 1.3.4 at the same site and I'm 100% that I didn't block anything in squid proxy server, all the applications like IM-clients, browsers etc successfully working via the same proxy. Here is how I tested it:

• removed ~/.config/deluge

Then just start it, go to Edit -> Preferences -> Proxy. Put in HTTP, proxyaddr:proxyport into all four fields and then just checking squid with sqstat - there is not even connections from deluge.

I also did another test: the settings are the same (proxy is turned on in deluge), and on default router's firewall I allowed direct connections with internets from my system - deluge successfully downloading the same torrent, but still not using proxy. So it looks like that it didn't ever try to use it.

If it make any difference, I'm using GTK-frontend of deluge 1.3.5 on FreeBSD. Related apps versions are:

boost-libs-1.48.0 boost-python-libs-1.48.0 libtorrent-rasterbar-0.16.2 py-libtorrent-rasterbar-0.16.2 (python binding) python 2.7.3

Please note once again that deluge working just fine another way. The problem is only appears when I try to use deluge via proxy. And there was no such problems with 1.3.4 in the same environment.

Here is what was added to my ~/.config/deluge/core.conf

  "proxies": {
    "peer": {
      "username": "", 
      "password": "", 
      "type": 4, 
      "port": 3128, 
      "hostname": "192.168.0.7"
    }, 
    "web_seed": {
      "username": "", 
      "password": "", 
      "type": 4, 
      "port": 3128, 
      "hostname": "192.168.0.7"
    }, 
    "tracker": {
      "username": "", 
      "password": "", 
      "type": 4, 
      "port": 3128, 
      "hostname": "192.168.0.7"
    }, 
    "dht": {
      "username": "", 
      "password": "", 
      "type": 4, 
      "port": 3128, 
      "hostname": "192.168.0.7"
    }
  }, 

I see in debug log:

[DEBUG   ] 15:27:06 config:197 Setting 'proxies' to {'peer': {'username': '', 'password': '', 'hostname': '', 'type': 0, 'port': 8080}, 'web_seed': {'username': '', 'password': '', 'hostname': '', 'type': 0, 'port': 8080}, 'tracker': {'username': '', 'password': '', 'hostname': '', 'type': 0, 'port': 8080}, 'dht': {'username': '', 'password': '', 'hostname': '', 'type': 0, 'port': 8080}} of <type 'dict'>

and later:

[DEBUG   ] 15:27:06 config:391 Config /home/rm/.config/deluge/core.conf version: 1.1 loaded: {'proxies': {u'peer': {u'username': u'', u'password': u'', u'type': 4, u'port': 3128, u'hostname': u'192.168.0.7'}, u'web_seed': {u'username': u'', u'password': u'', u'type': 4, u'port': 3128, u'hostname': u'192.168.0.7'}, u'tracker': {u'username': u'', u'password': u'', u'type': 4, u'port': 3128, u'hostname': u'192.168.0.7'}, u'dht': {u'username': u'', u'password': u'', u'type': 4, u'port': 3128, u'hostname': u'192.168.0.7'}}, }

So it looks like it set proxies before actually parsing core.conf?

[Calum]

Please test with libtorrent 0.15.

[ku]

Same with me, deluge 1.3.5-1 and libtorrent-rasterbar 0.16.2-1 and 0.16.3-1 under Arch Linux. I tried a proxy, was surprised by the high speed and then tried to type in bogus IPs, one starting with 255. etc. The torrents kept downloading. Then I started wireshark and noticed that all connections on deluge's port are to real peer addresses, not to the proxy address (well, obvious since it works with bogus IPs as a proxy). I used HTTP proxy on the port 3128. I used the GUI to set it up, but checked core.conf, too and it shows everything like it should be. Seems to me like the proxy option is broken now (if it ever worked).

[Calum]

See if clearing session.state helps: #2109

[ku]

No, still having direct connections with peers. I had the same problems with ktorrent and didn't find any proxy settings in transmission, only got it to work with utorrent under wine, which is horribly inconvenient.

[Calum]

Can you please try with qbittorrent as it uses the same 0.16 libtorrent library.

What the OP reports does not make sense (works 1.3.4 and not 1.3.5) as there have been no major changes and certainly not in the proxy code however the fact you are using lt 0.16 and not 0.15 (which is what 1.3 was designed for) could be a factor here whereas the OP's bug is likely related to #2109.

The problem will either be that somehow Deluge is failing to pass the proxy settings to libtorrent or there is an issue in libtorrent itself which would require reporting upstream.

[rm]

Hi! I'm terribly sorry about the delay. Deluge 1.3.5 is indeed work via proxy with: libtorrent-rasterbar-0.15.9 py27-libtorrent-rasterbar-0.15.9

and ignores the proxy settings with libtorrent-rasterbar-0.16.x py27-libtorrent-rasterbar-0.16.x

So it's looks like libtorrent is the culprit. Dunno if it's an regression or some api change.

[Calum]

The only documented api change in ​proxy settings from 0.15 to 0.16 are the addition of proxy_hostnames and proxy_peer_connections for which the python bindings are missing and that may be the issue.

[rm]

Ok, so should I bug upstream or you can prepare more quality bug report to them (I didn't dig both deluge and libtorrent internals)? Would adding this functions into python bindings automagically fix deluge work behind proxy, or it should be modified too?

[rm]

And by the way #2109 is unrelated issue, but I was caught by it too. This is the reason why I remove ~/.config/deluge before testing. So just want to say, that "it annoys me too".

[arvid]

The proxy settings did change in libtorrent 0.16. There is now only a single proxy setting and the previous ones just forward to that one setting.

The reason why they were coalesced was that introducing uTP (which are peers over UDP), along with DHT (also over UDP) and UDP trackers. It didn't make much sense in ever separating by peer/not peer. It doesn't make sense to announce to the DHT or a UDP tracker via the proxy, and then not accept peer connections over the proxy.

There is a risk that if deluge is setting the proxy settings, and then setting some other proxy setting to nothing, that last one overrides the first ones. One of the assumptions in the backwards-compatibility logic was that you wouldn't overwrite a proxy setting with something you didn't want set.

It's possible something went wrong in the python binding as well. I'll take a look at that.

[Calum]

Thanks arvid, I think that is the crux of the issue and explains the weirdness I was seeing; all proxies details being identical, when testing earlier with simple lt client.

I didn't see any issue with settings values with the bindings so the only outstanding issue would be those missing options.

The code in pref manager certainly does cycle through every proxy and set it so the last one will override all others:

​http://git.deluge-torrent.org/deluge/tree/deluge/core/preferencesmanager.py#n431

rm and ku could you try setting all the proxies (dht, web, tracker & dht) to see if that works?

[rm]

Cas, I always set them all while testing/regular use - see the original message. It just didn't work.

[ku]

Hmmh. Somehow my comment from yesterday didn't get posted. First of all, I am setting all 4 proxies. Though the only bearable free anonymous proxy i found was HTTPS and I'm using HTTP (no HTTPS option in deluge). Are HTTPS proxies supported by deluge/libtorrent? I also tried to downgrade to libtorrent-rasterbar 0.15.10 yesterday (I can't find an older version, since Arch Linux' repos only hold the latest version of packages and I purged my package cache several months ago). Still direct connections to peers (first it wouldn't even start, some problem with the classic mode and wouldn't connect to the daemon, after deleting session.state it worked, but lost all the torrents' states). I also tried to install qbittorrent, but it wouldn't build from AUR. qbittorrent-bin wouldn't start because of a symbol lookup error (EDIT: managed it to start with libtorrent-rasterbar 0.16.3-1. Also no HTTPS option and also direct connections to peers).

Sorry for the off-topic, but are there any other torrent clients under linux, that suport HTTPS proxy and magnet links? Vuze only connects to one peer from 1600+ and has a direct connection to him, utorrent under wine crashes all the time and doesn't download from TPB's magnet links. I'd also like to try a free anonymous SOCKS proxy, but can't find one.

[ku]

Oops. I just found out where I was wrong. The whole time the daemon was running with 0.16-3 (Help->About). It doesn't start with 0.15.x at all. Googling showed that I might need boost-libs 1.48.0 for that to work, this would break other packages for me.

[ku]

Just tested in Ubuntu 10.4 in VirtualBox - both deluge 1.2.2 and qbittorrent 2.2.5 work with that proxy with libtorrent 0.14.10.0. I also tested fatrat (it also depends on libtorrent-rasterbar) with 0.16.3 and it didn't work, too. So indeed, it seems like something was changed or broken with libtorrent 0.16.x

[Calum]

Yep I looked again at the Deluge code and it will not overwrite if the proxy in set to None and testing with simple client and Deluge shows the Python bindings appear to get and set ok so this suggests a deeper issue in lt 0.16.

I would suggest moving the discussion to libtorrent bug tracker.

[arvid]

I notice that you're using an HTTP proxy.

I would expect the following:

• http trackers would use the proxy
• TCP bittorrent connections would use the proxy via CONNECT
• uTP bittorrent connections would _not_ use the proxy (since it doesn't support UDP)
• udp trackers would _not_ use the proxy
• DHT would _not_ use the proxy.

Is it possible that you see uTP traffic and expect it to go via the proxy? uTP support is new in 0.16.x.

It's possible to disable uTP support by setting session_settings::enable_incoming_utp and session_settings::enable_outgoing_utp to false (I don't think this is exposed in Deluge though).

Alternatively, you could use a SOCKS5 proxy instead, which does support UDP.

[shellsonthefloor]

I'm experiencing this same issue with libtorrent-rasterbar6 version .15.10-1+b1 and a socks5 proxy without authentication.

[shellsonthefloor]

Just wiped and went down to Debian Stable and installed Deluge from repositories (1.2.3, libtorrent-rasterbar 0.14.10) and Deluge is still ignoring proxy settings. It also ignores proxy settings when tsocks is used.

[arvid]

what are the symptoms you see to determine that Deluge ignores proxy settings?

Are you running netcat to listen on the proxy port and look for incoming connections? Do you wireshark the traffic to make sure the packets that look like bittorrent all goes to the proxy?

I have been trying to reproduce this without any success, and I'm looking for clues of differences in our setup. For instance, keep in mind that when you use an HTTP proxy, only some traffic can go through it.

[shellsonthefloor]

I'm using a socks5 proxy - using ssh -D 8081. I'm using a much simpler method to check if it works, so here's what I see:

1. Torrents will start downloading even when the ssh tunnel has not been started.
2. Torrents that start while the tunnel is active do not stop when the tunnel is killed.
3. The IP of my client in the swarm will either show up as being my "real" IP, or will only show the IP of the proxy for a short time before switching over to my "real" IP.

[sslx]

Deluge totaly ignores socks5 proxy. I'm trying to use socks5 with privateinternetaccess. My real ip shows up on the swarm, and Deluge starts downloading even if I put wrong username password. I tested on uTorrent, and it works as expected. If I put correct info, my real ip doesn't show up, and if I put wrong user/pass it doesn't work.

deluged: 1.3.10 libtorrent: 0.16.17.0

[Arthur R]

I just monitored Deluge with Wireshark and found that it's connecting directly to peers despite having a working proxy. However I have noticed some interesting behavior:

If I change one number in the proxy IP, for example, to a non-working proxy, no downloads work; everything is frozen. So Deluge will only download given a working proxy; it's just not using that proxy.

[WeissmanScore]

Woah. That's not good... So this is confirmed and there is no way to mitigate? I am going to kill every instance I have running until I hear this is resolved.

[thero]

Wow. How can a critical bug like this still be around 4 years later?

[DeadlyKnapsack]

This is absolutely ridiculous. You are playing around with other people's privacy. I will immediately stop using Deluge.

[dg7dg]

Tested on 3.1.13 on Windows, via an account with a VPS provider, and then checking access to a magnet link on ​http://ipmagnet.services.cbcdn.com/

This bug still occurs; the Socks5 proxy setting is ignored by Deluge.

[Calum]

Ok I think I see the issue, since libtorrent 0.16 there is only one proxy setting and the old way that Deluge sets the proxy settings using peer, web etc when applied are overwriting the previous values so if dht is empty that is likely to be the last item set which would clear the values.

The workaround for now is to set all the proxies peer, web, tracker, dht to the same values.

This definitely applies to lt 1.1. and 1.0.

libtorrent issue: ​https://github.com/arvidn/libtorrent/issues/1646

1.3-stable fix: [8565eccb3de9]

[arliweng]

tested 1.3.14 with libtorrent-rasterbar 1.1.1 and 1.1.3(from github) on archlinux, problem still, tracker proxy can't save

[INFO ] 17:37:39 main:130 Deluge ui 1.3.14 ... [DEBUG ] 17:37:39 preferencesmanager:496 Setting peer proxy settings: {u'username': u, u'password': u, u'type': 0, u'port': 8080, u'hostname': u} [WARNING ] 17:37:39 preferencesmanager:486 Using libtorrent >= 0.16 ignores proxy settings for tracker

[Calum]

Did you read my last comment? There is only one proxy now. So peer proxy values are now used for all proxies. See #2991

[DeadlyKnapsack]

Replying to Cas:

Did you read my last comment? There is only one proxy now. So peer proxy values are now used for all proxies. See #2991

And still the IP is leaked! Even with the latest version 1.3.15. No matter what I do. It doesn't have to do with the settings. I can clearly see my IP in the Torrent swarm, when checking from different client downloading the same torrent. Why aren't you giving this more attention? This should clearly be one of the highest priorities. The fact that I know it is leaking, prevents me from using Deluge, so I can be safe. But what about all the other users who perhaps unknowingly are unable to hide their IP in the swarm?!

[DeadlyKnapsack]

Replying to Cas:

Ok I think I see the issue, since libtorrent 0.16 there is only one proxy setting and the old way that Deluge sets the proxy settings using peer, web etc when applied are overwriting the previous values so if dht is empty that is likely to be the last item set which would clear the values.

The workaround for now is to set all the proxies peer, web, tracker, dht to the same values.

This definitely applies to lt 1.1. and 1.0.

libtorrent issue: ​https://github.com/arvidn/libtorrent/issues/1646

1.3-stable fix: [8565eccb3de9]

This is incorrect in my situation. Even with identical values for all the proxies, the IP is visible.

[dg7dg]

Let us be honest here :) This bug has been open for five years. It's not a stretch to say that you cannot trust Deluge with your privacy, now or in the future.

Under no circumstances I blame the developers for not fixing the bug. I do blame them for offering a no-working feature for five years.

[DeadlyKnapsack]

Replying to dg7dg:

Let us be honest here :) This bug has been open for five years. It's not a stretch to say that you cannot trust Deluge with your privacy, now or in the future.

Under no circumstances I blame the developers for not fixing the bug. I do blame them for offering a no-working feature for five years.

Oh, I blame them for claiming the fix works. As a user, I should not be doublechecking the security.

[slajerek]

Wow, just tried Deluge for the first time... I did not expect that. 5 years already?? Guys, this is nonsense. Does not work for me either:

[INFO ] 23:59:01 daemon:124 Deluge daemon 1.3.10

It is completely ignoring my Proxy settings.

Time wasted, removing Deluge now. Thanks.

[andocromn]

try using the ltConfig plugin to set the anonymous_mode and force_proxy settings, this should accomplish what you want. references below

​http://forum.deluge-torrent.org/viewtopic.php?f=9&t=42887 ​http://www.libtorrent.org/reference-Settings.html

[alaneuler]

Socks5 proxy for tracker still doesn't work.

Output of deluge -v:

deluge: 1.3.15
libtorrent: 1.1.12.0

My use case is a little different, my tracker IP is banned from ISP. Feels bad about the bug existed for such a long time.

Maybe I have to give other BT client a try.

[dunedune]

I'm also having problems. Windows 10 fresh install, + Latest deluge 1.3.15

Setting Socks 5 proxy causes deluge to reset all preferences to default on next launch.

[xmpp is texting]

I am using 1.3.15 on windows 10 (pro, x64). I use SOCKS5 with authentication. "all preferences" not reset on next launch.

If I change the ip address first octet to 255, pause torrent, restart, there is no traffic as expected. Worryingly there is no popup error shown. Tracker status has an error, "socket operation was attempted to an unreachable network"

Restoring the correct address BUT also entering improper credentials does not resume data as expected. Again only pause restart updates the tracker error message, "error SOCKS authentication error"

Restoring correct credentials does not resume data until torrent paused and resumed.

Aside from requisite pause/restart this is the expected behavior.

--

Similar testing done with qBitTorrent as suggested in this thread 7 years ago.

[xmpp is texting]

I wanted comment 42. Also: thanks for all the fish!

[John Smith]

Hi, adding to this. I have the latest version of Deluge running and all latest libraries from Deluge sources VS Ubuntu. It runs perfectly EXCEPT this bug being tracked here.

1. I can setup my Proxy Credentials just fine.
2. I can check the two boxes, or just one box. But it doesn't stick
3. Is there a way to do this another way? From CLI?

See the two attachments for the Version Number and the Error.

Any help on this would be appreciated.

[John Smith]

Deluge Version

[John Smith]

The Proxy Settings Dialog

[Tim]

evidence of Deluge not using proxy 2021/06/27

[Tim]

Just thought I'd reply here to add that deluge 1.3.15 does not appear to be using my proxy settings These settings have been in place since I installed deluge months ago, all of those downloads are from within the last 24h. Surely my IP would not be showing up on iknowwhatyoudownload.com were it using the proxy? Pretty damn concerning tbh. ​https://dev.deluge-torrent.org/attachment/ticket/2149/deluge%20not%20using%20proxy.png