Free Download Manager proxy settings: what can and cannot be confirmed

A Free Download Manager proxy can be configured in one documented place, and that is most of what can be stated with confidence. FDM is a download accelerator first and a torrent client second, and its documentation describes the proxy setting for the application as a whole, without saying which proxy types it accepts or whether the torrent engine uses it. For a reviewer deciding what leaves a managed machine, that means the honest answer about FDM's torrent traffic is "not yet known", and this guide shows how to turn that into a measured answer instead of a guess.

The current release is FDM 6.34, dated 19 May 2026, for Windows, macOS, Linux and Android. We did not run it for this article.

What has to be approved first

Three things come before the proxy:

• The traffic. Whether peer-to-peer downloads are allowed on this network at all, decided by whoever owns egress.
• The content. What FDM will fetch: a distribution image, an open-source release, an Internet Archive item, a public dataset. Record the source.
• The software. FDM's website calls it "100% clean and open source" and promises "No adware, no malware, no spyware". We found no source repository for FDM 6, so the open-source claim is unverified. A software-intake review should ask the vendor for it rather than repeat it.

Peer-to-peer traffic for lawful content is allowed on ProxyForge residential exits and on our dedicated, unmetered ISP and datacenter addresses. Our acceptable use policy does not allow a ProxyForge exit to be used for sharing material without the right to distribute it.

Where the setting is

FDM's own tutorial site gives the path: open the main menu ("the menu can be revealed by clicking the icon showing 3 lines"), open Settings, then "Head to the Network panel and select the 'Configure manually' option."

That is all the primary documentation says. Not documented:

• which proxy types the manual configuration accepts;
• whether it takes a username and password;
• whether the setting reaches the torrent engine at all.

The history does not help. A 2016 reply on FDM's blog said SOCKS5 was "not supported", while a 2013 forum answer describes a per-download Proxy tab in FDM 3 and 5. Neither describes version 6.

Why the engine does not settle it

FDM's release notes for 6.29 say "Libtorrent updated to version 2.0.11", so its torrents run on the same library as qBittorrent and Deluge. libtorrent can proxy trackers and peers, and over SOCKS5 can attempt to relay UDP. It is tempting to conclude FDM does the same.

It does not follow. An application that embeds libtorrent decides what proxy settings to give it, and may give it none. qBittorrent, for instance, uses the same library and still leaves peer proxying off on a fresh install (our qBittorrent guide shows the source). Until FDM documents how its Network setting maps to libtorrent, the library's capabilities tell you what is possible, not what happens.

The limits that apply whatever FDM does

If the test below shows FDM does proxy peers, these apply on our network:

• Metered both ways round. The download crosses the gateway once and every seeded byte crosses it again, so a 4 GB image seeded to a ratio of 1.0 is at least 8 GB. Our gigabyte definition says how that is counted.
• No UDP. Treat our SOCKS5 endpoints as TCP only; UDP relay has not been verified. DHT, UDP trackers and uTP will not work through ProxyForge. An HTTP proxy cannot carry UDP.
• No encryption, and anything outside the proxy shows the machine's own address.
• Not a privacy tool. For copyright exposure, client projects point users to a VPN; qBittorrent's wiki is explicit. The control that works is fetching only what may be shared.

Settle it with three captures

FDM makes three kinds of connection worth separating: plain HTTP(S) downloads, torrent tracker requests and torrent peer traffic. Capture each on the machine itself, with the proxy configured, and hide the proxy connection so that only leaks remain. On Linux:

sudo tcpdump -ni any 'not (host PROXY_IP and tcp port PROXY_PORT) and not port 22 and not net 127.0.0.0/8'

On Windows or macOS, Wireshark with the display filter not (ip.addr == PROXY_IP and tcp.port == PROXY_PORT) does the same.

1. HTTP download. Fetch a file from a project's HTTPS mirror. A quiet capture means the Network setting covers FDM's own downloader.
2. Torrent, trackers. Add a lawful .torrent with an http:// or https:// tracker. A connection from the machine straight to the tracker's address means trackers are not proxied.
3. Torrent, peers and UDP. Let the torrent run. TCP connections to many addresses on arbitrary ports are peers going direct; UDP datagrams to many addresses are DHT or UDP trackers.

Record the result per row in the review. Then confirm the exit address with the proxy checker.

When the mirror is the better path

FDM's strength is HTTP downloading, and for most managed-infrastructure jobs that is the better tool. A distribution's HTTPS mirror delivers the image once, the published checksum proves it arrived intact, and nothing is seeded back through a metered exit. If policy requires that download to leave through an approved proxy, the first capture above is the only one that matters, and it is the part of FDM most likely to honour the setting. Reducing proxy bandwidth covers the other habits that keep a metered line's usage close to the payload.

Before FDM is approved

• Peer-to-peer traffic approved for this network, or torrent use ruled out
• Content source recorded
• Open-source claim either evidenced by the vendor or removed from the review
• Proxy type and authentication confirmed in the Network panel of the build in use
• Three captures recorded: HTTP download, torrent trackers, torrent peers and UDP
• Torrent use limited to what the captures show is proxied, or replaced by the HTTPS mirror
• Exit address recorded

For the clients whose proxy behaviour is documented or readable in source, see torrent client proxy support compared.