Opened 5 years ago

Closed 4 months ago

#2149 closed bug (Fixed)

deluge ignoring proxy settings

Reported by: rm Owned by:
Priority: critical Milestone: 1.3.14
Component: libtorrent Version: 1.3.5
Keywords: proxy Cc: pterodactyle@…, shellsonthefloor@…


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": ""
    "web_seed": {
      "username": "", 
      "password": "", 
      "type": 4, 
      "port": 3128, 
      "hostname": ""
    "tracker": {
      "username": "", 
      "password": "", 
      "type": 4, 
      "port": 3128, 
      "hostname": ""
    "dht": {
      "username": "", 
      "password": "", 
      "type": 4, 
      "port": 3128, 
      "hostname": ""

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''}, u'web_seed': {u'username': u'', u'password': u'', u'type': 4, u'port': 3128, u'hostname': u''}, u'tracker': {u'username': u'', u'password': u'', u'type': 4, u'port': 3128, u'hostname': u''}, u'dht': {u'username': u'', u'password': u'', u'type': 4, u'port': 3128, u'hostname': u''}}, }

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

Change History (31)

comment:1 Changed 5 years ago by Cas

Please test with libtorrent 0.15.

comment:2 Changed 5 years ago by ku

  • Cc pterodactyle@… added
  • Keywords proxy added
  • Priority changed from major to critical
  • Version changed from other (please specify) to 1.3.5

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).

comment:3 Changed 5 years ago by Cas

  • Component changed from gtkui to core

See if clearing session.state helps: #2109

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by Cas

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.

comment:6 Changed 5 years ago by 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.

comment:7 Changed 5 years ago by Cas

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.

comment:8 Changed 5 years ago by 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?

comment:9 Changed 5 years ago by 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".

comment:10 follow-up: Changed 5 years ago by 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.

comment:11 in reply to: ↑ 10 Changed 5 years ago by Cas

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:

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

comment:12 Changed 5 years ago by rm

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

comment:13 Changed 5 years ago by 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.

comment:14 Changed 5 years ago by 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.

comment:15 Changed 5 years ago by 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 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

comment:16 Changed 5 years ago by Cas

  • Component changed from core to libtorrent

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.

comment:17 Changed 5 years ago by 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.

comment:18 Changed 5 years ago by shellsonthefloor

  • Cc shellsonthefloor@… added

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

comment:19 Changed 5 years ago by 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.

comment:20 Changed 5 years ago by 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.

comment:21 Changed 5 years ago by 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.

comment:22 Changed 5 years ago by Cas

  • Milestone changed from 1.3.6 to not applicable

comment:23 Changed 3 years ago by 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:

Last edited 3 years ago by sslx (previous) (diff)

comment:24 Changed 16 months ago by ajthemacboy

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.

comment:25 Changed 15 months ago by 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.

comment:26 Changed 9 months ago by thero

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

comment:27 Changed 8 months ago by DeadlyKnapsack

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

comment:28 Changed 6 months ago by dg7dg

Tested on 3.1.13 on Windows, via an account with a VPS provider, and then checking access to a magnet link on

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

Last edited 6 months ago by dg7dg (previous) (diff)

comment:29 follow-up: Changed 6 months ago by 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:

1.3-stable fix: [8565eccb3de9]

Last edited 6 months ago by Cas (previous) (diff)

comment:30 in reply to: ↑ 29 Changed 4 months ago by 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

comment:31 Changed 4 months ago by Cas

  • Milestone changed from not applicable to 1.3.14
  • Resolution set to Fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.