JDownloader: Route Downloads Through Tor (SOCKS5) on Windows
Tor Browser is not only a browser. When it runs, it starts a Tor client in the background, and that client opens an ordinary SOCKS5 proxy on loopback. Any application on the machine that can speak SOCKS5 — JDownloader among them — can hand its connections to that proxy and reach the internet through the Tor network without knowing anything about Tor itself.
That makes this a useful teaching setup: there is no daemon to install and no service to configure. You install a browser, read one port number out of it, and type that port into another application. The interesting part is not the clicking — it is understanding what changes on the wire once you do, which is the last section of this article.
The Linux equivalent is documented separately in JDownloader via Tor on Ubuntu.
How It Works
A SOCKS5 proxy is a generic TCP relay. The application says "open a connection to this host and port," the proxy does it on the application's behalf, and bytes are passed back and forth. The application does not need to understand what happens on the other side — which is precisely why Tor exposes itself this way.
Two ports can appear on a Windows machine, and picking the wrong one is the usual reason this setup seems to work and then abruptly does not:
| Port | Opened by | Available when |
|---|---|---|
9150 |
Tor Browser | only while Tor Browser is running |
9050 |
standalone tor.exe from the Tor Expert Bundle |
whenever that process runs |
Both are plain SOCKS5 listeners with no functional difference. Tor Browser deliberately uses 9150 so it does not collide with a standalone client on 9050.
This guide uses 9150 — the port Tor Browser already provides. The Tor Expert Bundle exists for setups that need Tor without a browser, but it is a bare binary with no installer and no update mechanism, which is a poor trade when a browser window is an acceptable dependency.
Tor Browser has to stay open
Port 9150 belongs to Tor Browser. Close the browser and the listener disappears, taking every JDownloader connection with it — usually surfacing as a wave of simultaneous failures that looks like the file host blocked you. Leave the window open for as long as downloads are running. If you find yourself wanting to close it, that is the signal to move to the Expert Bundle instead.
Two things worth being clear about before you build this: Tor is a volunteer-run network with modest capacity, so throughput will be a fraction of your normal line speed and many file hosts refuse known Tor addresses outright. And the IP address is all that Tor hides — logging into any account identifies you again immediately, regardless of which exit node the request came from.
Pre-requisites
- Windows 10 or Windows 11
- Tor Browser for Windows — the regular installer, no special options
- JDownloader 2
Install Tor Browser
Download the Windows installer from torproject.org/download and run it. There is nothing to configure — accept the defaults.
Start Tor Browser and let it connect. When the browser window finishes loading a page, the background Tor client is running and the SOCKS proxy is live.
Confirm the listener from PowerShell:
Note LocalAddress: Tor binds to 127.0.0.1 only, so the proxy is reachable from this machine and from nowhere else on the network. That is the correct default — a SOCKS proxy exposed on a LAN interface is an open relay.
You can confirm which process owns it, which is also the first thing you would check when finding this port on a machine you did not set up yourself:
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 to9150. - Leave username and password empty — Tor's SOCKS listener does not authenticate.
- Save, then confirm the new entry is enabled in the connection list.
If the direct connection is left enabled alongside the proxy, JDownloader spreads downloads across both and part of the traffic never touches Tor. Disable or remove the direct entry if everything is supposed to go through the proxy. For a classroom demonstration this is worth doing deliberately — it is a compact illustration of why "we configured a proxy" and "our traffic uses the proxy" are different claims.
Verify
The meaningful test is from inside JDownloader, because it is the only one that proves the proxy entry was actually activated rather than merely saved. Add this URL as a download:
It returns a few bytes of JSON. Open the downloaded file:
IsTor: true means JDownloader's traffic genuinely left through an exit node, and the address shown is that exit node rather than your connection.
For a quick check outside JDownloader, Windows 10 and 11 ship with curl.exe:
Two Windows-specific traps here. Write curl.exe with the extension: in Windows PowerShell 5.1, bare curl is an alias for Invoke-WebRequest, which takes entirely different parameters and will fail with a confusing error about an unknown parameter. And Microsoft ships a deliberately reduced curl build, so if this particular flag is rejected on your machine, use the JDownloader check above — which is the more meaningful test regardless.
Use --socks5-hostname rather than --socks5. The plain flag resolves the hostname locally first and only then hands the connection to the proxy, which leaks the destination to your DNS resolver. The -hostname variant passes the name through and lets the exit node resolve it. Which brings us to the part that actually matters for SOC work.
What This Looks Like From the Defender's Side
Everything above is also a small, safe lab for a detection question: if a machine on your network did this, how would you know?
On the host, the giveaway is the listener itself. A process bound to 127.0.0.1:9150 or 9050 is a local proxy, and tor.exe owning it is unambiguous. In a managed environment the finding is usually not the port at all — it is that Tor Browser is installed and running on a corporate endpoint, which process telemetry answers directly without any network analysis.
On the network, the useful observation is what is missing. Because --socks5-hostname delegates name resolution to the exit node, the client never issues a DNS query for the site it is visiting. In your telemetry you see an established TCP session to an address that the host never looked up. That gap — a connection with no preceding resolution from the same host — is a generic tunnelling indicator rather than a Tor-specific one, which is exactly what makes it worth teaching: malware using a SOCKS proxy for command and control produces the same shape.
Identifying the traffic as Tor specifically means matching the outbound destination against the list of Tor relays. There is a subtlety here that catches people out. A Tor client connects to a guard relay, commonly on port 443, and never contacts an exit node directly — the exit sits at the far end of the circuit. So to detect an internal host using Tor, you need the full relay list, which the Tor Project publishes through its Onionoo directory API:
The more widely circulated list, https://check.torproject.org/torbulkexitlist, contains exit nodes only and answers the opposite question: is traffic arriving at my services from Tor. Both are legitimate detections; using the exit list to hunt for internal Tor clients simply will not match, because your users' machines never talk to those addresses.
Turn it into an exercise
Have trainees run the download once with the proxy disabled and once with it enabled, capturing traffic both times. The contrast makes the abstraction concrete: in the first capture there is a DNS query followed by a connection to the resolved address; in the second there is no query at all, and the single destination is a Tor guard on 443 no matter which site was requested.
Troubleshooting
Every download fails at once — Tor Browser was closed. The listener on 9150 disappears with it. Reopen it and confirm with Get-NetTCPConnection -LocalPort 9150 -State Listen.
Get-NetTCPConnection returns nothing while Tor Browser is open — the browser has not finished connecting to the network. Wait until it loads a page, then check again.
PowerShell reports a parameter error on the curl command — you invoked the Invoke-WebRequest alias. Use curl.exe with the extension.
A specific host returns HTTP 403 — that host blocks Tor exit addresses. There is no configuration fix; the block applies to the exit node, not to you.
Downloads work but are very slow — expected. Traffic passes through three volunteer-operated relays. Tor optimises for anonymity, not throughput.