Deluge proxy settings are applied by the daemon, not by whichever window you clicked them in. Deluge is split into a core, deluged, and thin clients (GTK, Web UI and console) that connect to it, and the client's source keeps the proxy preferences in the core, in deluge/core/preferencesmanager.py, before handing them to libtorrent. On a headless host that is exactly what you want: one place that decides what leaves the machine. It also means the person changing a checkbox on a laptop is changing the egress of a server, which belongs in the review.
Deluge 2.2.0 is the current release, dated 28 April 2025, and the project is slow-moving; the last commit is from March 2026. The facts below are read from Deluge's source on its develop branch and from libtorrent's documentation. We did not run Deluge for this article.
Approval comes before the daemon config
The questions for a deluged host on managed infrastructure:
- Is peer-to-peer traffic allowed out of this network, and has the owner of that policy said so in writing?
- What will the host distribute? Distribution images, open-source releases, Creative Commons media, research data. Record the sources.
- Who may change the daemon's preferences? Anyone who can connect a thin client to
delugedcan change its proxy. Treat daemon access as a privileged credential.
Our position on the traffic itself is plain: peer-to-peer for lawful content is fine on residential exits and on dedicated ISP and datacenter addresses with no traffic meter. Using a ProxyForge exit for unauthorised sharing is a breach of the acceptable use policy.
Limits the review should record
A proxied Deluge on our network behaves within these limits:
- Payload is metered in both directions of the transfer. Peers are proxied by default, so the download passes through the gateway, and so does every byte seeded afterwards. Plan the gigabytes against our published definition, and cap uploads or stop at a ratio.
- UDP will not get through. libtorrent can relay UDP inside a SOCKS5 association, but our SOCKS5 endpoints should be treated as TCP only, with UDP relay unverified. DHT, UDP trackers and uTP will not work through our proxy. With an HTTP proxy, libtorrent refuses those packets rather than sending them directly.
- Nothing is encrypted by the proxy itself, and RFC 1929 credentials cross in cleartext.
- Anything outside the proxy uses the host's address. With Deluge's defaults that is a short list, which is why the leak test below targets the tracker as well as the peers.
- For copyright exposure, a proxy is the wrong control. qBittorrent's wiki, describing the same engine, recommends a VPN to anyone with that concern. We would add that the only reliable control is the content itself.
If the host only needs the file once, the project's HTTPS mirror with its checksum avoids peer traffic entirely.
Seven proxy types, two with credentials
In the GTK client the page is Edit > Preferences > Proxy. The type list offers None, Socks4, Socks5, Socks5 Auth, HTTP, HTTP Auth and I2P. Authentication applies to the two "Auth" types. I2P is an overlay network rather than a proxy service and is not relevant to a ProxyForge exit.
For our gateways, which accept HTTP, HTTPS and SOCKS5, choose Socks5 Auth with the username and password from the dashboard, or Socks5 if the host is authenticated by IP allowlist. HTTP Auth works for TCP traffic too, but it rules out any UDP relay by construction. The protocol trade-offs are in SOCKS5 vs HTTP proxy.
What the checkboxes do
Five checkboxes sit under the type and address. Their defaults, from the source, and their effect:
| Checkbox | Default | Effect |
|---|---|---|
| Proxy Hostnames | On | Resolve tracker and peer names at the proxy, not on the host |
| Proxy Peers | On | Peer connections and web seeds go through the proxy |
| Proxy Trackers | On | Tracker connections go through the proxy |
| Force Proxy Use | Off | Maps to libtorrent's deprecated force_proxy |
| Hide Client Identity | Off | Maps to libtorrent's anonymous mode |
Three notes on that table:
- The defaults are safe for coverage. Selecting a type proxies peers, trackers and hostname lookups at once. If a review finds Proxy Peers unticked, someone turned it off.
- Force Proxy Use is a historical switch. libtorrent's changelog records "deprecated force_proxy setting (when set, the proxy is always used)" in 1.2.1. On modern builds, reading the source suggests the box adds nothing, because a configured proxy is already always used for what it covers. Do not count it as an extra control.
- Hide Client Identity is not routing. Its tooltip reads "Attempt to hide client identity and only use proxy for incoming connections." In libtorrent, anonymous mode sends a generic user agent and withholds the client version. It does not move traffic.
Incoming connections and the listen port
Because Deluge passes the proxy to libtorrent, libtorrent's rule applies: the listen interface "will not accept incoming TCP connections, will not map ports with any gateway and will not enable local service discovery", and the client announces listen port 1. Port forwarding on the host's router does nothing for a proxied daemon. It connects only to peers that accept incoming connections, so expect fewer peers and slower transfers than the same daemon without a proxy. Seeding still works over the connections it opens.
A tracker-side leak test
Peer coverage can be checked on the daemon host. Tracker coverage is easier to check from the other end, with a tracker you control. On a small machine outside your network, run a listener that logs every request with its source address:
python3 -m http.server 8080
On a Linux workstation with mktorrent installed, generate a throwaway file and a torrent that announces to that listener:
head -c 50M /dev/urandom > leaktest.bin
mktorrent -a http://TEST_HOST:8080/announce -o leaktest.torrent leaktest.bin
Add leaktest.torrent to Deluge. The listener logs a GET /announce?info_hash=... line, and its source address should be the exit address the gateway presents, not the deluged host's own address. The announce will fail with a 404, which is fine; the request is the evidence. The proxy checker gives you the exit address to compare against.
Then, on the daemon host, confirm that no established TCP connection points anywhere but the gateway:
ss -tnp | grep deluged
Remove the test torrent afterwards. It contains only random bytes, so it cannot distribute anything.
Checklist for the daemon
- Peer-to-peer egress approved; content sources recorded
- Daemon access restricted, because it controls the proxy
- Type Socks5 Auth or Socks5 with allowlisting; hostname, peer and tracker proxying all ticked
- Force Proxy Use and Hide Client Identity not cited as controls
- Tracker-side test shows the exit address, not the host
-
ssshows no established connection outside the gateway - Upload cap or ratio limit set; gigabyte estimate includes seeding
Deluge's engine is shared with qBittorrent, which starts with peer proxying off on a fresh install, and with Tribler, which applies a proxy to only some downloads. All fifteen clients are compared in torrent client proxy support compared.