JDownloader über Tor auf Linux: Docker Compose mit gesperrtem Direktzugang

JDownloader 2 lädt Dateien von Hostern und Webseiten. Wer die Verbindungen über das Tor-Netzwerk leiten möchte, braucht mehr als einen Tor-Container daneben: Solange JDownloader selbst ins Internet kommt, genügt ein falscher Eintrag oder ein Neustart, und Downloads laufen wieder über die eigene IP-Adresse. Diese Anleitung baut deshalb auf einem Linux-Server mit Docker Compose einen Stack, in dem JDownloader überhaupt keinen direkten Weg nach draußen hat und nur über einen Tor-SOCKS5-Proxy kommunizieren kann. Jeder Schritt endet mit einer Prüfung, der letzte mit einem Leak-Test aus JDownloader selbst.

Voraussetzungen

• Linux-Server oder VPS mit Debian 12/13 oder Ubuntu 24.04, x86_64 oder ARM64 (alle drei Images gibt es für amd64 und arm64)
• 2 CPU-Kerne und 4 GB RAM; JDownloader bekommt im Beispiel höchstens 1 GB Java-Heap
• etwa 1 GB Speicher für Images und Konfiguration plus Platz für die Downloads
• Docker Engine mit Compose-Plugin v2 (getestet mit Docker 29.1.3 und Compose 2.40.3), Einrichtung siehe Docker-Installation
• SSH-Zugang mit Schlüssel; die Weboberfläche erreichen Sie später über einen SSH-Tunnel
• Ein abgesicherter Server mit Firewall, siehe VPS absichern mit UFW, SSH-Keys und Fail2Ban

Eckdaten

Dienst	Image und Tag	Ports	Volumes	Netze
tor	dockurr/tor:0.4.9.13	keine veröffentlicht (intern 9050 SOCKS5, 8118 HTTP)	./tor-data:/var/lib/tor	intern, extern
jdownloader	jlesage/jdownloader-2:v26.09.1	keine veröffentlicht (intern 5800 Web, 5900 VNC)	./config:/config, ./downloads:/output	nur intern
gui	nginx:1.30-alpine	127.0.0.1:5800	./gui.conf (nur lesend)	intern, frontend

Wichtige Umgebungsvariablen von JDownloader: USER_ID und GROUP_ID (Eigentümer der Dateien), TZ und JDOWNLOADER_MAX_MEM (Format wie 1G oder 768M). Die Tags sind festgeschrieben; dockurr/tor wurde zuletzt am 24.09.2026 gebaut, das früher verbreitete dperson/torproxy seit April 2021 nicht mehr.

Schritt 1: Projektordner und Benutzer-ID

Der Aufbau besteht aus drei Containern und drei Netzen. Das Netz intern ist mit internal: true vom Internet getrennt: Docker legt dafür weder eine Standardroute noch eine Namensauflösung nach außen an. JDownloader hängt nur in diesem Netz. Der Tor-Container hängt zusätzlich im Netz extern und baut von dort die Verbindung ins Tor-Netzwerk auf. Der Nginx-Container verbindet das interne Netz mit dem Netz frontend, damit Sie die Oberfläche erreichen.

mkdir -p ~/jdownloader-tor/{config,downloads,tor-data}
cd ~/jdownloader-tor
id -u; id -g

Notieren Sie die beiden Zahlen. Die Dateien in config und downloads gehören später diesem Benutzer.

Verifizieren: ls ~/jdownloader-tor zeigt config downloads tor-data, id -u liefert eine Zahl wie 1000.

Schritt 2: Compose-Datei und Nginx-Konfiguration

Legen Sie compose.yaml an und ersetzen Sie 1000 bei Bedarf durch Ihre Werte aus Schritt 1.

name: jdownloader-tor

services:
  tor:
    image: dockurr/tor:0.4.9.13
    restart: unless-stopped
    networks: [intern, extern]
    volumes:
      - ./tor-data:/var/lib/tor

  jdownloader:
    image: jlesage/jdownloader-2:v26.09.1
    restart: unless-stopped
    depends_on: [tor]
    networks: [intern]          # kein Internet, nur Tor erreichbar
    environment:
      USER_ID: "1000"
      GROUP_ID: "1000"
      TZ: Europe/Berlin
      JDOWNLOADER_MAX_MEM: 1G
    volumes:
      - ./config:/config
      - ./downloads:/output

  gui:
    image: nginx:1.30-alpine
    restart: unless-stopped
    depends_on: [jdownloader]
    networks: [intern, frontend]
    ports:
      - "127.0.0.1:5800:8080"   # nur lokal, Zugriff per SSH-Tunnel
    volumes:
      - ./gui.conf:/etc/nginx/conf.d/default.conf:ro

networks:
  intern:
    internal: true
  extern:
  frontend:

Warum ein eigener Nginx-Container? Docker veröffentlicht keine Ports eines Containers, der nur in einem internen Netz hängt. Im Test blieb ein ports:-Eintrag direkt bei JDownloader wirkungslos. Die Nginx-Konfiguration gui.conf folgt dem Reverse-Proxy-Beispiel aus der Image-Dokumentation und reicht auch WebSockets durch:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}
server {
    listen 8080;
    location / {
        proxy_pass http://jdownloader:5800;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_buffering off;
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
    }
}

Verifizieren: docker compose config --quiet gibt nichts aus und endet mit Exit-Code 0.

Schritt 3: Stack starten und Tor prüfen

docker compose up -d
docker compose logs tor | grep Bootstrapped | tail -1
docker compose ps

Tor braucht beim ersten Start etwa eine Minute für den Aufbau. Der eingebaute Healthcheck des Images meldet danach healthy; im Test dauerte das gut zwei Minuten. Zeilen wie „We have no usable consensus“ am Anfang sind normal.

docker compose exec jdownloader curl -s -x socks5h://tor:9050 https://check.torproject.org/api/ip

Verifizieren: Das Log endet mit Bootstrapped 100% (done): Done, docker compose ps zeigt tor als Up (healthy), und der curl-Aufruf liefert {"IsTor":true,"IP":"…"}. Dieser Test prüft nur Tor, noch nicht JDownloader.

Schritt 4: Direktweg gesperrt, Negativtest

Jetzt der entscheidende Nachweis: Ohne Proxy darf JDownloader nichts erreichen.

docker compose exec jdownloader curl -sS -m 10 https://check.torproject.org/api/ip
docker network inspect jdownloader-tor_intern --format '{{.Internal}}'
ss -ltn | grep -E ':5800|:9050|:8118'

Verifizieren: Der erste Befehl scheitert mit curl: (6) Could not resolve host: check.torproject.org (DNS server returned general failure), der zweite gibt true aus, und ss zeigt nur 127.0.0.1:5800. Die Tor-Ports 9050 und 8118 sind auf dem Host nicht veröffentlicht.

Schritt 5: Proxy im Verbindungsmanager eintragen

Öffnen Sie von Ihrem Arbeitsplatz aus einen SSH-Tunnel und rufen Sie die Oberfläche im Browser auf:

ssh -N -L 5800:127.0.0.1:5800 benutzer@ihr-server
# danach im Browser: http://127.0.0.1:5800

JDownloader startet, versucht Updates zu laden und scheitert zunächst, weil kein Weg nach draußen existiert. Das ist gewollt. Tragen Sie den Proxy ein, wie es der JDownloader-Support für Proxys vorsieht:

1. Settings öffnen, links Connection Manager wählen.
2. Add anklicken, im Dialog „Add new Proxy“ bei Type Socks5 wählen.
3. Host/Port: tor und 9050, Benutzer und Passwort leer lassen, mit Ok bestätigen.
4. In der Tabelle den Haken bei No Proxy entfernen und den neuen Eintrag aktiv lassen.

Der Hostname tor ist der Dienstname aus der Compose-Datei; Docker löst ihn im internen Netz auf. Die Namen der Downloadziele löst JDownloader in diesem Aufbau nicht selbst auf, sondern übergibt sie an Tor. Im Test stand im Log SEND tcp connect request to:check.torproject.org:443 by domain.

Verifizieren: Die Tabelle zeigt genau eine aktive Zeile Socks 5 Proxy | tor | 9050, „No Proxy“ ist deaktiviert. Nach einem Neustart mit docker compose restart jdownloader zeigt grep -rh "via \[" config/logs | tail -3 Update-Anfragen mit via [tor:9050 (Socks5 Proxy)].

Schritt 6: Leak-Test aus JDownloader

Der Test mit curl in Schritt 3 sagt nichts darüber, welchen Weg JDownloader wählt. Prüfen Sie deshalb mit JDownloaders eigenem HTTP-Client. Damit JDownloader Anfrage und Antwort vollständig protokolliert, schalten Sie vorübergehend das Debug-Logging ein:

docker compose stop jdownloader
sed -i -E 's/"debugmodeenabled" ?: ?false/"debugmodeenabled":true/' config/cfg/org.appwork.utils.logging2.LogConfig.json
docker compose start jdownloader

Klicken Sie dann im Tab LinkGrabber auf Add New Links, fügen Sie directhttp://https://check.torproject.org/api/ip ein und bestätigen Sie mit Continue. Der Eintrag erscheint als offline, weil die Antwort keine herunterladbare Datei ist. Das spielt keine Rolle, entscheidend ist das Log:

grep -rh '"IsTor"' config/logs/ | tail -1
grep -rh 'SOCKS5 Hello' config/logs/ | tail -1

Verifizieren: Die Ausgabe enthält {"IsTor":true,"IP":"…"} und SOCKS5 Hello to:tor/…:9050. Die IP ist die eines Tor-Exit-Knotens, nicht Ihre Server-IP. Schalten Sie das Debug-Logging danach auf dem gleichen Weg wieder ab, es erzeugt große Logdateien.

Schritt 7: Betrieb, Updates und Sicherung

JDownloader aktualisiert sich innerhalb des Containers selbst, im Test ebenfalls über Tor. Neue Image-Versionen setzen Sie bewusst: Tags auf Docker Hub prüfen, in compose.yaml eintragen und neu starten.

docker compose pull
docker compose up -d
sudo tar czf jdownloader-tor-$(date +%F).tgz compose.yaml gui.conf config

Für die Sicherung reichen compose.yaml, gui.conf und der Ordner config, der die Proxy-Liste enthält. tor-data gehört nach dem Start dem Tor-Benutzer im Container, deshalb sudo. Tor legt die Daten beim nächsten Start neu an, eine Sicherung ist nicht nötig.

Verifizieren: Nach docker compose up -d zeigt docker compose ps alle drei Dienste als Up, und der Leak-Test aus Schritt 6 liefert weiterhin "IsTor":true.

Typische Fehler

• Weboberfläche nicht erreichbar, curl meldet Code 000: Der Port steht direkt bei JDownloader. Docker veröffentlicht keine Ports von Containern, die nur in einem internen Netz hängen; docker compose ps zeigt dann 5800/tcp ohne Host-Zuordnung. Lösung: Zugriff über den gui-Container.
• Log zeigt UnknownHostException: Could not resolve: -update.jdownloader.org<->update.jdownloader.org-: JDownloader versucht es direkt (via [Direct]). Das beweist die Sperre; tragen Sie den Proxy aus Schritt 5 ein.
• Tor bleibt bei health: starting: Der erste Healthcheck läuft erst nach etwa einer Minute. Prüfen Sie docker compose logs tor. Blockiert eine Firewall ausgehende Verbindungen des Servers, kommt Tor nicht über wenige Prozent hinaus.
• Proxy-Eintrag verschwindet wieder: JDownloader überschreibt seine JSON-Dateien beim Beenden. Bearbeiten Sie Dateien in config/cfg nur bei gestopptem Container.
• rm -rf tor-data scheitert mit Permission denied: Die Dateien gehören dem Tor-Benutzer im Container. Verwenden Sie sudo.

Häufige Fragen

Bin ich damit anonym?

Nein, nicht automatisch. Tor verhindert laut Tor Project, dass Zielserver Ihren Standort erfahren und dass Ihr Provider sieht, was Sie abrufen. Melden Sie sich aber mit einem Hoster-Konto an, weiß der Hoster, wer lädt. Der Exit-Knoten sieht unverschlüsselte HTTP-Inhalte. Zwischen JDownloader und dem Tor-Container läuft der Verkehr unverschlüsselt; das Tor Project weist ausdrücklich darauf hin, dass die Anonymität erst am Tor-Knoten beginnt.

Warum nicht einfach JAVA_TOOL_OPTIONS mit socksProxyHost?

Ob JDownloader Java-Systemeigenschaften für alle eigenen Verbindungen nutzt, ist nicht dokumentiert. Der Verbindungsmanager ist der vom Hersteller beschriebene Weg. Entscheidend ist ohnehin das interne Netz: Selbst ein falscher Proxy-Eintrag führt dann zu Fehlern, nicht zu Verbindungen über Ihre IP.

Warum dockurr/tor statt dperson/torproxy?

dperson/torproxy erhielt seit April 2021 keine neuen Images. dockurr/tor baut aktuelle Tor-Versionen auf Alpine, bringt einen Healthcheck mit und bietet SOCKS5 auf 9050 sowie einen HTTP-Tunnel auf 8118.

Wie schütze ich die Oberfläche zusätzlich?

Die Oberfläche hat standardmäßig keine Anmeldung. Die Bindung an 127.0.0.1 plus SSH-Tunnel reicht für einen Admin. Für mehrere Nutzer bietet das Image WEB_AUTHENTICATION, das eine HTTPS-Verbindung (SECURE_CONNECTION=1) voraussetzt.

Fazit

Der Schutz entsteht nicht durch den Tor-Container, sondern durch das interne Netz: JDownloader kann nur über Tor ins Internet oder gar nicht. Der Proxy im Verbindungsmanager macht Tor zum einzigen Weg, und der Leak-Test aus JDownloader heraus zeigt, dass es funktioniert. Wiederholen Sie diesen Test nach jedem Image-Update.

Weiterführende Anleitungen und Quellen

• JDownloader über Tor mit Portainer als Stack
• JDownloader über Tor auf der Synology mit Container Manager
• jlesage/docker-jdownloader-2: Dokumentation des Images
• dockur/tor: Tor-Container mit SOCKS5 und HTTP-Tunnel
• JDownloader Support: How to use a VPN/Proxy with JDownloader
• Docker Docs: Compose-Netze und Option internal
• Tor Project: Tor auf einem zentralen Server betreiben
• Tor Project: Welche Schutzwirkung Tor bietet