So kann man Lancache mit AdGuard Home statt lancache-dns betreiben. monolithic übernimmt den Cache, Wir erklären im Detail, wie das läuft.
Große Updates über Battle.net, etwa für World of Warcraft oder Call of Duty, muss man nicht jedes Mal wieder vollständig herunterladen. Das gilt ebenso für Spiele bei Steam. Wer AdGuard Home im Heimnetz bereits als DNS nutzt, kann das technische Setup Lancache so aufsetzen, dass der zusätzliche DNS-Container entfällt. AdGuard Home übernimmt die Umschreibungen, während die All-in-One-Containerlösung monolithic die Downloads lokal vorhält. Steam und Battle.net laufen damit zuverlässig. Ubisoft funktioniert nur eingeschränkt. Epic ebenfalls. Xbox und der Microsoft Store fielen dagegen raus.
Ein Patchtag ohne Doppeldownload
Ein eigener Spiele-Cache klingt erst einmal nach einer typischen nutzlosen Spielerei. Mit dem nächsten großen Patch ist das Thema dann doch auch auf einmal relevant, wenn die Kanne Kaffee leer ist und sich die Prozentanzeige des Downloads mal wieder ganz langsam nach oben quält. Dann geht es nicht mehr ums Basteln, sondern darum, denselben Download nicht immer wieder durch dieselbe Leitung zu schieben oder die Daten selbst für sein „Ein Rechner-Setup“ schon da zu haben.
Lancache speichert große Downloads lokal und liefert sie später wieder aus. Der erste Abruf bleibt in der Geschwindigkeit, wie es die eigene Leitung und die der Anbieter vorgeben. Alles danach kommt aus dem eigenen Netz. Das reicht oft schon für mehrere Rechner, frische Installationen, wiederkehrende Patches oder kleinere Anschlüsse.
AdGuard bleibt auch beim Lancache der DNS
Lancache als Speichersystem verschwindet in diesem Aufbau natürlich nicht. Der Cache bleibt bestehen, die Containerlösung monolithic ist der eigentliche Kern. Der Container speichert die Spieldaten lokal und liefert sie später wieder aus dem Heimnetz aus, sodass derselbe Download nicht jedes Mal neu aus dem Internet gezogen werden muss. Es fällt nur der Lancache-DNS weg, also der zusätzliche DNS-Container, der Clients normalerweise auf die IP des Zwischenspeichers der Daten der Spiele umleitet.
Diesen Teil übernimmt hier AdGuard Home*. Der Resolver läuft bei den meisten ohnehin schon im Netz, also bleibt er auch dort. Für Lancache braucht man keinen weiteren DNS-Dienst, der an derselben Stelle noch einmal dazwischengeht.
Warum Lancache-DNS rausflog
Wer AdGuard Home bereits im Netz nutzt, muss den DNS-Teil von Lancache nicht noch einmal neu aufbauen. Darin liegt der Reiz dieses Aufbaus wie wir als Tarnkappe ihn für euch gestaltet haben. Der Cache bleibt erhalten. Wir entfernen den zusätzlichen DNS-Container restlos, weil wir ihn nicht benötigen.
Der übliche Weg mit Lancache-DNS ist in so einem Setup ein massiver Rückschritt. Bei Lancache hängt der gesamte Weg am DNS. Dort fällt die Entscheidung, ob Anfragen im Cache landen oder daran vorbeilaufen.
Dazu kommt der Resolver selbst. Wer bereits mit AdGuard Home arbeitet, möchte diesen Teil nicht noch einmal aufreißen, nur um für einen einzelnen Zweck wieder bei einem zusätzlichen Resolver mit klassischem IPv4-DNS und Klartext zu landen. Ein zeitgemäßes Setup nutzt nun einfach DoH, DoT oder DoQ.
AdGuard Home bleibt also der Resolver, während monolithic den Teil übernimmt, für den der Container gedacht ist. Downloads lokal vorhalten und später wieder aus dem eigenen Netz an die über die mit dem DNS verbundenen Geräte ausliefern. Die Domainlisten dafür liefert das laufend gepflegte Projekt „cache-domains”. Dort stehen die Hostnamen, die ein solcher Spiele-Cache per DNS auf die Cache-IP umbiegt. Damit ihr die leider etwas verquere Syntax von Adguard dafür auf Anhieb trefft, empfehle ich euch, die KI eurer Wahl danach zu fragen, sie euch Copy&Paste-gerecht für AdGuard zu erstellen. Einfach einfügen und sie funktioniert danach auf Anhieb.
Warum AdGuard Home reicht
AdGuard Home ist nicht die einzige Lösung. Technitium DNS Server kann dieselbe Aufgabe ebenfalls übernehmen. Dort laufen solche Umschreibungen eher über Zonen. Ein Pi-hole funktioniert für einfache Fälle auch, stößt hier aber schnell an seine Grenzen, da sehr oft eine zusätzliche dnsmasq-Konfiguration erforderlich ist.
Einen laufenden AdGuard-Dienst dafür wieder herauszureißen, ergibt trotzdem wenig Sinn. Die Rewrites sitzen dort an der richtigen Stelle. Sie sorgen dafür, dass bestimmte Download-Domains nicht beim normalen Anbieter landen, sondern auf die eigene Cache-IP zeigen. So kommt der Traffic später auch wirklich bei Monolithic an. Technitium geht ebenfalls.
Auch monolithic benötigt DNS
AdGuard Home ersetzt nicht den DNS-Bedarf von monolithic. Es ersetzt lediglich den zusätzlichen DNS-Container für die Clients. Der Cache-Container selbst muss weiterhin in der Lage sein, Hostnamen aufzulösen, wenn Inhalte noch nicht lokal vorliegen.
Deshalb fragt der Client weiterhin AdGuard Home an und Monolith löst für seine eigenen Upstream-Verbindungen ganz normal die Hostnamen auf. Der Cache ersetzt keinen Resolver. Er ersetzt nur den zusätzlichen DNS-Umweg.
Alles auf einem Host
Für den Aufbau bleiben zwei Wege. Entweder laufen DNS und Cache getrennt auf mehreren Geräten. Oder alles sitzt vereint auf einem Host. Auf einem Windows-Server in Docker lief es ohne Umwege. Dort hingen AdGuard Home und Monolithic ebenso wie SteamPrefill und BattleNetPrefill. Der Cache lief also dort, wo später auch die Downloads ankamen.
Man benötigt ein zweites System dafür. Ein zusätzlicher Pi für das Prefill oder native Installationsversionen auf einem anderen Host sind nicht sinnvoll. Ein Pi spielt nur dann noch eine Rolle, wenn er zusätzlich andere Aufgaben übernimmt, etwa als Subnet-Router fürs Tailnet (VPN von Tailscale). Für Cache und Prefill ist er nicht nötig.
Der Aufbau bleibt aber nicht auf Windows beschränkt. Grundsätzlich läuft er genauso auf einem NAS, unter Proxmox, auf Unraid, auf einem Raspberry Pi mit externer SSD oder NVMe oder in einem Umbrel-System mit Portainer. Am Ende bleibt es leider immer dieselbe problematische Baustelle. Monolithic benötigt auf dem Host die Ports 80 und 443, AdGuard Home bleibt auf Port 53 und die Weboberfläche wird auf einen anderen Port gezogen. Eine vollständige Anleitung für jede dieser Varianten würde hier den Rahmen sprengen, aber ich habe sie weiter unten mit den ganzen Beispielen für euch zusammen gestellt.
Ports sauber trennen
Wenn AdGuard Home* und monolithic auf derselben Maschine laufen, muss der Cache die Host-Ports 80 und 443 erhalten. Über diese beiden Ports laufen später die eigentlichen Download-Anfragen. Wenn AdGuard diese Ports belegt, kommt es zu Konflikten mit dem Resolver.
AdGuard Home bleibt deshalb auf Port 53 für DNS. Das ist auch nicht verhandelbar, sondern für den normalen Standardrouter den wir zu Hause haben einfach ein Muss. Router, DHCP-Clients und viele andere Geräte erwarten den DNS genau dort. Zieht der Resolver von Port 53 weg, fängt der Ärger oft sofort an. Die Weboberfläche muss deshalb dann sofort auf einen anderen Host-Port, etwa 8080, verschieben. monolithic bekommt die Ports 80 und 443, AdGuard behält Port 53 und die Weboberfläche läuft daneben.
Die eigentlichen Compose-Beispiele für monolithic und AdGuard Home stehen separat bei den Skriptbeispielen. Im Artikel reicht die folgende Portverteilung: Monolithic benötigt die Ports 80 und 443, AdGuard Home bleibt auf Port 53 und die Weboberfläche wird auf Port 8080 oder einen anderen freien Host-Port gezogen.
AdGuard Home dokumentiert das offizielle Image sowie die persistenten Work- und Conf-Verzeichnisse.
Der Cache gehört auf die SSD
Bei 1 Gbit fällt das oft noch nicht so stark auf. Anders sieht es aus, wenn 2,5 Gbit im Netz liegen oder Geräte mit einem schnellen WLAN surfen. Dann bremst oft nicht mehr das Netz, sondern die klassische Festplatte den Transfer aus.
Eine HDD kann einen solchen Cache zwar problemlos speichern, er wird jedoch verlangsamt, sobald mehrere Downloads gleichzeitig laufen oder viele kleinere Dateistücke bedient werden müssen. Wer den Lancache nicht nur nebenbei mitlaufen lassen, sondern das eigene Netz auch wirklich ausreizen möchte, sollte den Cache besser auf einer SSD ablegen. Dies gilt für einen Windows-Server ebenso wie für ein NAS, Proxmox, Unraid, Umbrel oder einen Raspberry Pi. Die Plattform ist dabei nicht entscheidend, das Laufwerk aber schon. Wenn man den LAN-Cache über ein LAN bereitstellen möchte, ist man sogar auf ein SSD-RAID und weitere schnelle Infrastruktur angewiesen. Die meisten werden es aber nur im Heimsetting einsetzen, um sich oder die Familie zu bespaßen.
Was lief und was nicht
Steam und Battle.net liefen über den eigenen Cache zuverlässig durch Ubisoft lag dazwischen. Das wurde vor allem dann richtig brauchbar, wenn das Spiel bei Steam gekauft wurde und Ubisoft Connect am Ende nur noch zum Starten nötig war. Dann greift der eigentliche Download dort, wo das Cachesystem am besten funktioniert. In dem Fall bleibt Ubisoft eher das nervige Anhängsel für den Login.
Epic Games lief ebenfalls sauber über den Cache. Für das automatische Prefill reichten Steam und Battle.net aber auf dem Testsystem aus.
Bei GOG landet man dagegen eher bei den Offline-Installern auf dem NAS oder einem anderen Rechner im Netz. Dafür braucht es keinen eigenen Cache-Dienst. GOG bietet diese Offline-Installer offiziell an. Daher ist ein lokaler Installer-Bestand der einfache typische Oldschool-Weg.
Xbox und der Microsoft Store fielen dagegen raus. Downloads aus dem Store waren bei diesem Aufbau schlichtweg nicht nutzbar. Dazu kommt, dass man dafür ein Windows-Konto benötigt. Das allein dürfte für die wenigsten eine brauchbare Grundlage für eine Download-Automatik sein. Die wenigsten werden Windows ohne lokales Konto nutzen.
Bei Battle.net zeigt sich schnell der Nutzen. Das gilt vor allem für World of Warcraft. Große Updates ziehen sich dort gerne, die Übertragungsraten schwanken. Wirklich schnell ist das Laden aus dem Battle.net nur sehr selten. Über den lokalen Lancache läuft es deutlich schneller.
Wer Battle.net schon länger nutzt, kennt dieses Problem. Große Patches ziehen sich dort gerne hin, und ein Preload löst das Problem oft nur zur Hälfte. Wenn danach trotzdem noch etliche Gigabyte fehlen, hilft der Vorab-Download wenig, wenn am Abend viele gleichzeitig laden und die Server wie immer maßlos überlastet sind. Ein lokaler Cache verschiebt den Engpass beim Download von der Stelle im Internet, an der er entsteht, ins Heimnetz.
Prefill läuft im Container
Der Aufbau wird erst dann richtig super, wenn der Cache nicht nur passiv mitläuft, sondern gezielt vorgefüllt wird. Darin liegt der eigentliche Unterschied. Das lief auch in Docker auf dem Windows-Server. Parallel liefen Linux-Container für AdGuard Home, monolithic, SteamPrefill und BattleNetPrefill. Dafür braucht es keinen Extra-Host oder nackte Installationsversionen mit denen man umständlich hantieren muss.
Zunächst läuft einmal Select-Apps, damit die Auswahl der Spiele im persistenten Config-Verzeichnis landet. Danach übernehmen die eigentlichen Prefill-Durchgänge (hier der Link zum Guide) den Download der aktuellen Versionen der Games. Sie ziehen nicht jedes Mal alles neu, sondern nur das nach, was neu oder geändert wurde. Sowohl SteamPrefill als auch BattleNetPrefill dokumentieren den Docker-Weg mit –net=host und persistenten Config-Verzeichnis sowie anschließendem Select-Apps damit sie zuverlässig laufen ohne einen mit nervigen Fehlern und lästiger Nacharbeit zu konfrontieren. SteamPrefill merkt sich außerdem, was zuletzt vorgefüllt wurde. Es lädt bei späteren Läufen nur neuere Versionen nach, solange niemand die Option „–force” aktiviert. Bei Spielen wie Dota2 oder Counter Strike ist das eine tolle Sache.
Den ersten Login muss man trotzdem selbst durchführen. Das gilt für Steam genauso wie für Battle.net. Danach laufen die nächtlichen Jobs einfach durch.
Wer Docker unter Windows nutzt, sollte den nächsten Punkt nicht übersehen. Die Option –network host funktioniert bei Docker Desktop nicht immer automatisch, sondern erst mit der aktuellen Version und aktivierter Host-Networking-Funktion, welche man bei Docker in den Einstellungen aktivierten muss. Fehlt diese, sieht das wie in der Beispiel-Installtion zwar richtig aus, läuft aber beim Download einfach ins Leere. Weitere Informationen dazu findet man hier.
Der Spiele-Rechner muss dafür zum Glück als der Stromfresser schlechthin nicht 24/7 laufen. Der Server arbeitet die Prefills nachts ab, während der Rest einfach aus bleibt. Wenn am nächsten Morgen ein großes Update ansteht, liegt es oft schon im eigenen Cache. Gepatcht wird dann aus dem lokalen Netz, statt alles noch einmal mühselig zu ziehen.
Ohne Skripte macht Lancache nur halb so viel Sinn
Ganz ohne kleines Skript wird es auch mit Docker nicht so gut, wie es sein könnte. Die Container muss man einmal sauber einrichten. Man muss die Auswahl der Spiele festlegen und danach ist ein fester Ablauf für die Nacht erforderlich. SteamPrefill und BattleNetPrefill laufen deshalb am sinnvollsten zeitgesteuert statt jedes Mal manuell gestartet zu werden.
Die eigentlichen Skriptbeispiele stehen hier separat für euch samt Installationsanleitung. Dafür msus man einmal die Auswahl setzen, Prefill nachts zeitgesteuert starten und dann die Pfade, Laufwerke, den Netzwerkmodus und Laufzeiten an das eigene System anpassen.
DNS, Rewrites, Cache und Prefill müssen jedoch denselben Weg gehen. Ansonsten lädt man alles auf den falschen Pfad am Cache vorbei. Dann wäre außer Spesen nichts gewesen.
Die Beispielskripte kann man trotzdem nicht blind übernehmen. Sie müssen an das eigene Setup zwangsweise angepasst werden. Das gilt für Pfade, Volumes, den Netzwerkmodus, die Aufgabenplanung und die Spieleauswahl selbst.
Ein solcher Aufbau ist nicht in zehn Minuten zu realisieren. DNS, Rewrites, Monolith und Prefill müssen denselben Weg sehen. Erst dann zieht man die Daten zur richtigen Stelle. Und nur so wärmen die nächtlichen Download-Jobs auch wirklich den später benötigten Pfad vor.
Mit AdGuard Home und Monolithic bleibt der Aufbau am Ende schlanker als bei einem Umweg über einen zusätzlichen DNS-Container.
Steam Deck daheim und unterwegs
Der Aufbau endet nicht an der Wohnungstür. Er kann auch dann nützlich sein, wenn ein großes Update an einem anderen Ort festhängt. Gerade bei Battle.net ist das kein Einzelfall. Wenn bei einem Freund das nächste World-of-Warcraft-Update nur zäh läuft, kann ein bereits gefüllter Lancache am eigenen Anschluss mit genug Upload trotzdem noch helfen.
Das gilt nicht nur für einen zweiten Rechner, sondern genauso für ein Steam Deck. Liegt das Update zu Hause schon im Cache, muss das Handheld es nicht noch einmal komplett aus dem Internet herunterladen. Es lädt dann direkt aus dem eigenen Netz. Gerade bei großen Spielen oder mehreren Geräten im Haushalt ist diese Lösung echt ein Traum.
Unterwegs kann derselbe Aufbau ebenfalls hilfreich sein. Dann läuft es aber nicht einfach über die Tailscale-IP eines einzelnen Hosts. Man benötigt einen Subnet-Router, der das Heimnetz ins Tailnet freigibt. Der entfernte Client sieht somit nicht nur einen einzelnen Rechner, sondern das gesamte Heimnetz selbst. AdGuard Home bleibt der DNS-Server auf Port 53. Und der Cache bleibt unter seiner normalen, privaten Adresse erreichbar. So landen die Anfragen weiterhin im Lancache, anstatt daran vorbeizulaufen.
Wenn das Update bereits im Cache liegt, muss man es also nicht noch einmal vollständig transferieren. Dies funktioniert jedoch nur, wenn der entfernte Rechner oder das Steam Deck tatsächlich über das Tailnet ins freigegebene Heimnetz kommt, den richtigen DNS nutzt und der Heimanschluss über genügend Upload verfügt.
Fazit zum Thema Lancache
Lancache ohne Lancache-DNS bedeutet nicht, dass Lancache keinen Cache mehr hat, da „monolithic” weiterhin aktiv bleibt. Man ersetzt lediglich den zusätzliche DNS-Container, da AdGuard Home die Umschreibung der relevanten Hostnamen selbst übernehmen kann. Wer AdGuard Home bereits im Netz nutzt, sollte deshalb lieber gleich dabei bleiben. Wie gesagt, Technitium kann dieselbe Aufgabe ebenfalls abbilden. Pi-hole wirkt dagegen wie ein Umweg, bei dem es viele Fehlerquellen gibt. Das gilt insbesondere, wenn man es mit dem Netzwerkdienst DNSMasq realisieren möchte. Das soll jedoch nicht heißen, dass es nicht möglich wäre.
Bei Updates von Steam und Battle.net lief alles problemlos. Ubisoft funktioniert leider nur eingeschränkt. Epic geht gut. GOG sollte man hingegen direkt über den Offline-Installer nutzen. Xbox und der Microsoft Store fallen komplett hinaus, genauso wie das Playstation Network und das Nintendo Download CDN. Bei den Anbietern funktionieren die Updates mit diesem Aufbau schlichtweg nicht.
Seinen eigentlichen Wert zeigt so ein Aufbau im Hintergrund, wenn man am Abend nach der Arbeit einfach entspannen und eine Runde spielen möchte. Der Spiele-Rechner kann aus bleiben, während der Server nachts schon gearbeitet hat. Wenn Steam oder Battle.net ein großes Update ausrollen, liegt es am nächsten Morgen oft schon im eigenen Lancache. Gepatcht wird dann aus dem lokalen Netz, statt alles noch einmal vollständig neu laden zu müssen. Das gilt ebenso für ein Steam Deck zu Hause. Und wenn das Handheld oder das Notebook unterwegs ist, kann derselbe Cache per Tailnet das Update ebenfalls aus dem Heimnetz laden, statt die Daten ein weiteres Mal mühsam aus dem Internet zu holen.
Fazit: Das Ganze ist durchaus mit ein wenig Aufwand verbunden. Doch wenn das Setup einmal läuft, ist es sehr nützlich und komfortabel.
(*) Alle mit einem Stern gekennzeichneten Links sind Affiliate-Links. Wenn Du über diese Links Produkte oder Abonnements kaufst, erhält Tarnkappe.info eine kleine Provision. Dir entstehen keine zusätzlichen Kosten. Wenn Du die Redaktion anderweitig finanziell unterstützen möchtest, schau doch mal auf unserer Spendenseite oder in unserem Online-Shop vorbei.
