JDownloader: Route Downloads Through Tor (SOCKS5) on Ubuntu
JDownloader has no Tor integration of its own, but it does speak SOCKS5 — and a local Tor installation is, among other things, a SOCKS5 proxy listening on loopback. Connecting the two is a configuration job, not a plugin hunt: install Tor, confirm which port it listens on, and add that port as a proxy in JDownloader's Connection Manager.
This guide covers the Tor daemon installed from the Tor Project's own APT repository, because the version in the Ubuntu archive lags behind and Tor is one of the few packages where running an old build genuinely matters.
The Windows equivalent is documented separately in JDownloader via Tor on Windows, which also covers what the setup looks like in SOC telemetry.
What This Actually Gives You
Routing a download manager over Tor hides your IP address from the file host. That is the whole of it, and it is worth being precise about the limits before you spend time on the setup.
Tor is not a general-purpose download pipe
The Tor Project explicitly discourages using Tor for bulk transfers. The network is a volunteer-run, bandwidth-constrained resource shared by people who need it for censorship circumvention and source protection. Beyond the etiquette problem, there are three practical consequences: throughput is a fraction of your normal line speed, many file hosts block known exit-node addresses outright, and anonymity collapses the moment you log into an account — an authenticated session identifies you regardless of the IP it arrives from. Tor also protects only the traffic of applications configured to use it; everything else on the machine still goes out over your normal connection.
How It Works
Tor runs as a background service and opens a SOCKS5 listener on 127.0.0.1. Any application that can speak SOCKS5 hands its connections to that listener, and Tor forwards them through its circuit. The application never needs to understand Tor itself — it just needs a proxy setting.
There are two ports you may encounter, and picking the wrong one is the most common reason this setup appears to work and then stops:
| Port | Opened by | Available when |
|---|---|---|
9050 |
the tor daemon (installed via apt) |
always — it runs as a systemd service |
9150 |
Tor Browser | only while Tor Browser is open |
Both are ordinary SOCKS5 proxies and there is no functional difference between them. The distinction is ownership: Tor Browser deliberately ships on 9150 so it does not collide with a system-wide daemon on 9050.
For a download manager, use 9050. A queue that runs for hours should not depend on a browser window staying open, and closing Tor Browser mid-download would otherwise kill every transfer at once.
Pre-requisites
- Ubuntu 22.04 LTS (
jammy) or 24.04 LTS (noble) — these are the Ubuntu suites the Tor Project repository currently publishes sudoaccess- JDownloader 2 installed — download it from jdownloader.org; the native installer is preferable to the Snap or Flatpak build here, since sandboxed packages add a layer of network confinement you would otherwise have to reason about
Check your release codename before you start, since it goes into the repository definition:
Install the Tor Daemon
Add the signing key first
Order matters here. APT refuses to fetch from a repository whose signing key it does not already trust, so the key has to be in place before the repository is added — otherwise the first apt update fails with a NO_PUBKEY error.
The Tor Project publishes its signing key as an ASCII-armoured file. APT needs it in binary form, which is what gpg --dearmor produces:
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null
Add the repository
Modern APT reads the deb822 format from /etc/apt/sources.list.d/*.sources. The Signed-By line pins this repository to the key you just installed, so a compromise of some unrelated repository cannot be used to serve you a forged tor package:
sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -sc)
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
Use tee rather than a shell append (>>). Appending re-adds the block every time the command runs, and APT then complains about duplicate sources.
Install
The deb.torproject.org-keyring package keeps the signing key current as it rotates, so future key changes arrive as a normal package update instead of a broken apt update:
Verify
The Debian and Ubuntu packaging runs Tor as a systemd instance, so the unit to query is tor@default — plain systemctl status tor only shows a wrapper unit and will look inert even when Tor is running perfectly:
Confirm the SOCKS listener is actually bound:
The 127.0.0.1 is worth noticing: Tor binds to loopback only, so the proxy is reachable from this machine and not from your LAN. That is the correct default — an open SOCKS proxy on a network interface is an abuse vector.
Now confirm traffic genuinely exits through Tor:
Use --socks5-hostname, not --socks5. The plain flag resolves DNS locally and only then sends the connection through the proxy, which leaks the hostname you are visiting to your DNS resolver. The -hostname variant passes the name to Tor and lets the exit node resolve it. This distinction is the single most common way a "working" Tor proxy setup still leaks.
Configure JDownloader
JDownloader's proxy configuration lives in the Connection Manager:
- Open Settings → Connection Manager.
- Click Add and choose SOCKS5 as the proxy type.
- Set Host to
127.0.0.1and Port to9050. - Leave username and password empty — a stock Tor SOCKS listener does not authenticate.
- Save, then make sure the new entry is enabled in the connection list.
If you left your direct connection enabled alongside the new proxy, JDownloader will distribute downloads across both, and some of your traffic will bypass Tor entirely. Disable or remove the direct connection if the point of the exercise is that everything goes through Tor.
Confirm it from JDownloader's own perspective
Rather than trusting the settings dialog, queue a download from a URL that echoes the requesting IP — https://check.torproject.org/api/ip works and returns a few bytes of JSON. Open the resulting file: if IsTor is true, JDownloader's traffic is genuinely on the network. Verifying from inside the application is the only check that accounts for the possibility that the proxy entry was saved but not activated.
About Tor Browser
You do not need Tor Browser for any of the above — the daemon on 9050 is entirely independent of it. If you want it as well, install it from the official tarball at torproject.org/download, extract it, and register it with your desktop:
Avoid the torbrowser-launcher package from the Ubuntu archive. It downloads and signature-checks Tor Browser at first run using a signing key bundled in the package, and that key has repeatedly expired ahead of the distribution's package updates — producing a Signature verification failed error that has been reported against Ubuntu for years. The workarounds circulating for it involve hand-editing /usr/lib/python3/dist-packages/torbrowser_launcher/__init__.py, which is a poor trade: the edit is silently reverted by the next package upgrade, and patching a signature-verification routine to make an error go away defeats the purpose of the check. The official tarball is signed, current, and updates itself.
Troubleshooting
apt update fails with NO_PUBKEY — the repository was added before the keyring. Re-run the wget ... | gpg --dearmor command, then sudo apt update.
apt update reports the suite is not found — the Tor Project repository does not publish for every Ubuntu release. Check the available suites against your lsb_release -sc output. If yours is absent, stay on Ubuntu's own tor package until the Tor Project adds it.
JDownloader shows connection errors on every host — Tor is not running, or you configured 9150 while Tor Browser is closed. Confirm with ss -tlnp | grep 9050.
Downloads fail with HTTP 403 on a specific host — that host blocks Tor exit nodes. There is no configuration fix; the block is on their side and applies to the exit address, not to you.
Everything works but is extremely slow — expected. Traffic is relayed through three volunteer-run hops. Tor is not built for throughput, and no amount of tuning changes that.