JDownloader über Tor auf der Synology: Container Manager mit gesperrtem Direktzugang
JDownloader 2 und Tor als Projekt im Synology Container Manager: JDownloader läuft in einem internen Netz ohne Internetzugang, nutzt nur den Tor-SOCKS5-Proxy und ist über den DSM-Reverse-Proxy erreichbar.
Geprüft am 30.09.2026 · für jdownloader-2 26.09.1, tor 0.4.9.13
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu

JDownloader 2 läuft auf einer Synology als Container im Container Manager. Wer die Downloads über das Tor-Netzwerk leiten möchte, muss verhindern, dass JDownloader am Proxy vorbei direkt ins Internet geht. Ein Tor-Container im selben Projekt reicht dafür nicht, solange JDownloader in einem normalen Netz mit Internetzugang hängt. Diese Anleitung richtet ein Container-Manager-Projekt ein, in dem JDownloader nur in einem internen Docker-Netz ohne Internetzugang läuft und ausschließlich den Tor-SOCKS5-Proxy erreicht. Die Einrichtung erfolgt über die DSM-Oberfläche, der Zugriff über den Reverse Proxy von DSM.
Voraussetzungen
- Synology NAS mit x86_64- oder ARM64-Prozessor, auf dem der Container Manager verfügbar ist (alle drei Images gibt es für amd64 und arm64)
- DSM 7.2 oder neuer mit installiertem Container Manager; Grundlagen siehe Container Manager: Docker-Compose-Projekt anlegen
- mindestens 4 GB RAM in der NAS; JDownloader erhält im Beispiel höchstens 1 GB Java-Heap
- etwa 1 GB freier Speicher auf dem Volume für Images und Konfiguration plus Platz für Downloads
- Shared Folder
dockerauf/volume1, Administratorzugang zu DSM - einmalig SSH-Zugang, nur um die Benutzer-ID zu ermitteln (DSM zeigt die numerische ID in der Oberfläche nicht an)
Eckdaten
| Dienst | Image und Tag | Ports | Ordner unter /volume1/docker/jdownloader-tor | Netze |
|---|---|---|---|---|
| tor | dockurr/tor:0.4.9.13 | keine veröffentlicht (intern 9050) | tor-data | intern, extern |
| jdownloader | jlesage/jdownloader-2:v26.09.1 | keine veröffentlicht (intern 5800) | config, downloads | nur intern |
| gui | nginx:1.30-alpine | 127.0.0.1:5800 | gui.conf | intern, frontend |
Das in älteren Anleitungen verwendete dperson/torproxy erhielt seit April 2021 keine neuen Builds. dockurr/tor wurde zuletzt am 24.09.2026 gebaut und bringt einen Healthcheck mit.
Schritt 1: Projektordner in der File Station
Der Container Manager legt fehlende Host-Ordner nicht zuverlässig an. Erstellen Sie deshalb in der File Station unter docker den Ordner jdownloader-tor und darin config, downloads und tor-data.
Erstellen Sie auf Ihrem Rechner eine Textdatei gui.conf mit folgendem Inhalt und laden Sie sie in jdownloader-tor hoch. Sie folgt dem Reverse-Proxy-Beispiel aus der Image-Dokumentation:
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: Die File Station zeigt in /docker/jdownloader-tor die drei Ordner und die Datei gui.conf mit einer Größe von einigen Hundert Byte.
Schritt 2: Benutzer-ID ermitteln
JDownloader schreibt Konfiguration und Downloads als der Benutzer, dessen ID Sie in USER_ID und GROUP_ID angeben. Aktivieren Sie SSH kurz unter Systemsteuerung, Terminal & SNMP, melden Sie sich an und lesen Sie die IDs des Benutzers aus, dem die Downloads gehören sollen:
id ihr-benutzer
Deaktivieren Sie SSH danach wieder, wenn Sie es sonst nicht brauchen.
Verifizieren: Die Ausgabe hat die Form uid=1026(ihr-benutzer) gid=100(users) …. Notieren Sie uid und gid.
Schritt 3: Projekt im Container Manager anlegen
Öffnen Sie im Container Manager Projekt, Erstellen. Projektname jdownloader-tor, Pfad /docker/jdownloader-tor, Quelle docker-compose.yml erstellen. Fügen Sie ein und ersetzen Sie 1026 und 100 durch Ihre Werte:
services:
tor:
image: dockurr/tor:0.4.9.13
restart: unless-stopped
networks: [intern, extern]
volumes:
- /volume1/docker/jdownloader-tor/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: "1026"
GROUP_ID: "100"
TZ: Europe/Berlin
JDOWNLOADER_MAX_MEM: 1G
volumes:
- /volume1/docker/jdownloader-tor/config:/config
- /volume1/docker/jdownloader-tor/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 auf der NAS selbst
volumes:
- /volume1/docker/jdownloader-tor/gui.conf:/etc/nginx/conf.d/default.conf:ro
networks:
intern:
internal: true
extern:
frontend:
Den Webportal-Schalter für Web Station lassen Sie aus. Der Nginx-Dienst ist nötig, weil Docker keine Ports eines Containers veröffentlicht, der nur in einem internen Netz hängt. Im Test blieb ein Port-Eintrag direkt bei JDownloader ohne Wirkung.
Verifizieren: Das Build-Fenster endet mit Exit Code: 0. Unter Container stehen drei Container mit Status „Wird ausgeführt“.
Schritt 4: Tor und Sperre prüfen
Öffnen Sie beim Tor-Container unter Details das Protokoll. Nach etwa einer Minute erscheint Bootstrapped 100% (done): Done; der Healthcheck meldet im Test nach gut zwei Minuten healthy.
Wählen Sie dann den JDownloader-Container, Aktion, Terminal öffnen und führen Sie in der Shell beide Befehle aus:
curl -s -x socks5h://tor:9050 https://check.torproject.org/api/ip
curl -sS -m 10 https://check.torproject.org/api/ip
Verifizieren: Der erste Befehl liefert {"IsTor":true,"IP":"…"}. Der zweite scheitert mit curl: (6) Could not resolve host: check.torproject.org (DNS server returned general failure): Ohne Tor gibt es keinen Weg nach draußen.
Schritt 5: Zugriff über den DSM-Reverse-Proxy
Die Oberfläche lauscht nur auf der NAS selbst. Sie machen sie über den Reverse Proxy von DSM im Heimnetz erreichbar. Legen Sie zuerst unter Systemsteuerung, Anmeldeportal, Erweitert, Zugangskontrollprofil ein Profil an, das nur Ihr lokales Netz zulässt. Dann Reverse Proxy, Erstellen:
- Quelle: Protokoll
HTTPS, Hostname z. B.jd.nas.lan, Port5443, Zugangskontrollprofil auswählen - Ziel: Protokoll
HTTP, Hostnamelocalhost, Port5800 - Unter Benutzerdefinierter Header, Erstellen, WebSocket wählen
Die Oberfläche von JDownloader hat standardmäßig keine eigene Anmeldung. Leiten Sie den Port 5443 deshalb nicht im Router weiter und geben Sie ihn in der DSM-Firewall nur für das lokale Netz frei, siehe DSM-Firewall: Ports für Docker-Container freigeben.
Verifizieren: https://jd.nas.lan:5443 öffnet im Browser die JDownloader-Oberfläche. Ein Zugriff von außerhalb des freigegebenen Netzes wird abgewiesen.
Schritt 6: Proxy im Verbindungsmanager
JDownloader scheitert beim ersten Start an Updates, weil kein direkter Weg existiert. Das ist gewollt. Tragen Sie den Proxy ein, wie es der JDownloader-Support beschreibt:
- Settings, links Connection Manager.
- Add, im Dialog „Add new Proxy“ bei Type
Socks5wählen. - Host/Port:
torund9050, Benutzer und Passwort leer, Ok. - Den Haken bei No Proxy entfernen.
Die Namen der Downloadziele löst JDownloader dabei 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 eine aktive Zeile Socks 5 Proxy | tor | 9050. Nach einem Neustart des JDownloader-Containers liefert grep -rh "via \[" /config/logs | tail -3 im Container-Terminal Zeilen mit via [tor:9050 (Socks5 Proxy)].
Schritt 7: Leak-Test aus JDownloader
Der curl-Test aus Schritt 4 prüft nur Tor. Den Weg von JDownloader selbst prüfen Sie mit dessen HTTP-Client. Damit die Antwort im Log steht, aktivieren Sie vorübergehend das Debug-Logging: Container beenden, in der File Station config/cfg/org.appwork.utils.logging2.LogConfig.json öffnen, zum Beispiel mit dem Paket Text-Editor, "debugmodeenabled" auf true setzen, speichern und den Container starten. Bei laufendem Container würde JDownloader die Änderung beim Beenden überschreiben.
Öffnen Sie im Tab LinkGrabber den Dialog Add New Links, fügen Sie directhttp://https://check.torproject.org/api/ip ein und bestätigen Sie mit Continue. Der Eintrag wird als offline angezeigt, weil keine Datei zurückkommt. Im Container-Terminal:
grep -rh '"IsTor"' /config/logs/ | tail -1
Verifizieren: Die Ausgabe lautet {"IsTor":true,"IP":"…"} mit der IP eines Tor-Exit-Knotens. Stellen Sie debugmodeenabled danach auf dem gleichen Weg wieder auf false.
Schritt 8: Aktualisieren und sichern
JDownloader aktualisiert sich im Container selbst, im Test ebenfalls über Tor. Für neue Images ändern Sie im Projekt unter YAML-Konfigurationen die Tags und speichern; der Container Manager implementiert das Projekt mit den neuen Einstellungen. Sichern Sie den Ordner /docker/jdownloader-tor ohne tor-data mit Hyper Backup; darin liegen Proxy-Liste und Projektdatei.
Verifizieren: Unter Container zeigen alle drei Container die neuen Image-Tags und laufen, der Leak-Test aus Schritt 7 liefert weiterhin "IsTor":true.
Typische Fehler
- Oberfläche nicht erreichbar: Der Port wurde bei JDownloader statt bei
guieingetragen. Im Container Manager erscheint dann bei JDownloader kein Port-Mapping. Die Weiterleitung muss über dengui-Container laufen. - Nginx startet nicht,
gui.confist ein Ordner: Die Datei fehlte beim ersten Start. Docker legt für einen fehlenden Bind-Mount-Pfad ein Verzeichnis an. Ordner löschen, Datei hochladen, Projekt neu erstellen. - Log zeigt
UnknownHostException: Could not resolve: -update.jdownloader.org<->update.jdownloader.org-: JDownloader versucht es direkt. Die Sperre wirkt; tragen Sie den Proxy aus Schritt 6 ein. - Keine Schreibrechte in
downloads:USER_IDoderGROUP_IDpassen nicht zum Besitzer des Ordners. Werte aus Schritt 2 prüfen. - Oberfläche bleibt grau oder trennt sofort: Der WebSocket-Header im Reverse Proxy fehlt.
Häufige Fragen
Bin ich damit anonym?
Nicht automatisch. Laut Tor Project verhindert Tor, dass Zielserver Ihren Standort und Ihr Provider Ihre Ziele erfahren. Ein Hoster-Konto identifiziert Sie trotzdem, und der Exit-Knoten sieht unverschlüsselte HTTP-Inhalte. Zwischen JDownloader und dem Tor-Container läuft der Verkehr unverschlüsselt; die Anonymität beginnt laut Tor Project erst am Tor-Knoten.
Funktioniert das auch mit dem alten Docker-Paket?
Die Anleitung beschreibt den Container Manager ab DSM 7.2. Das Projekt verwendet nur Standard-Compose-Optionen, getestet ist es aber nicht mit älteren Paketen.
Warum nicht JAVA_TOOL_OPTIONS?
Dass JDownloader Java-Proxy-Eigenschaften für alle eigenen Verbindungen nutzt, ist nicht dokumentiert. Der Verbindungsmanager ist der vom Hersteller beschriebene Weg, und das interne Netz verhindert ohnehin jeden Direktweg.
Fazit
Auf der Synology entsteht der Schutz durch das interne Netz im Projekt, nicht durch den Tor-Container allein. JDownloader erreicht nur Tor oder nichts, die Oberfläche liegt hinter dem DSM-Reverse-Proxy mit Zugangskontrolle. Wiederholen Sie den Leak-Test nach jedem Update.
Weiterführende Anleitungen und Quellen
- JDownloader über Tor auf Linux mit Docker Compose
- JDownloader über Tor als Portainer-Stack
- Synology: Container Manager, Projekt
- Synology: Anmeldeportal, Reverse Proxy und Zugangskontrollprofil
- jlesage/docker-jdownloader-2
- dockur/tor
- JDownloader Support: VPN/Proxy mit JDownloader
- Tor Project: Welche Schutzwirkung Tor bietet


