Windows Update fand neue Updates, zeigte sie an und meldete regelmässig seinen Status. Trotzdem blieb ein Download hängen. Weil der Zugang über einen Caddy-Reverse-Proxy lief, lag der erste Verdacht beim Proxy: Verbindungen, Zeitlimits, vielleicht ein Problem mit grösseren Dateien.
Die entscheidende Spur lag jedoch in der Adresse, die Windows tatsächlich für die Installationsdatei verwendete. Die Updatesuche lief bereits über den neuen HTTPS-Zugang. Der Dateiabruf versuchte weiterhin den bisherigen HTTP-Downloadzugang zu erreichen. Dieser Zugang antwortete beim Test nicht.
Wir haben den Fehler mit Graylog, dem Windows-Updateprotokoll und zwei vergleichbaren Dateiabrufen eingegrenzt. Die Korrektur bestand darin, den erreichbaren Proxy auch als alternativen Downloadserver einzutragen. Auf dem untersuchten Client wurden Download und Installation danach erfolgreich abgeschlossen.
Alle Hostnamen, Dateinamen und frei gewählten Pfade in den folgenden Beispielen sind Platzhalter. Der Artikel beschreibt die untersuchte Konfiguration und ihre Abnahme im Oktober 2026.
Warum Updatesuche und Download getrennt betrachtet werden müssen
Ein Update besteht aus Informationen über seine Anwendbarkeit und den eigentlichen Installationsdateien. Ein Client kann deshalb erfolgreich mit WSUS kommunizieren, ohne die benötigten Dateien erreichen zu können.
In unserem Aufbau war der öffentliche HTTPS-Zugang auf Caddy eingerichtet. Caddy leitete die Anfragen intern an den WSUS-Webserver weiter. Die Clientrichtlinie enthielt bereits den neuen Proxy-Namen für die Updatesuche und das Reporting. Für einen Download verwendete der Client dennoch eine Content-URL über den bisherigen HTTP-Downloadzugang.
Vereinfacht sah die Situation so aus:
Updatesuche und Reporting
Client -> https://updates-proxy.example.net:443 -> Caddy -> WSUS
Ergebnis: HTTP 200
Dateiabruf vor der Korrektur
Client -> bisheriger HTTP-Downloadzugang -> /Content/...
Ergebnis: Verbindungs-TimeoutDiese Trennung ist bei der Fehlersuche wichtig. Microsoft beschreibt für WSUS unterschiedliche Verbindungen für Metadaten und Update-Dateien. Eine erfolgreiche TLS-Verbindung zum Suchdienst belegt daher noch keinen funktionierenden Content-Zugang. Die konkrete URL muss am Client geprüft werden. Microsoft zur WSUS-Konfiguration
Zuerst den Proxyzustand prüfen
Zu Beginn aktualisierten wir das Caddy-Containerimage innerhalb der verwendeten Versionsreihe. Dabei blieben Konfiguration, Netzwerkzuordnung und persistente Mounts erhalten. Anschliessend zeigte Portainer den Stack mit aktuellem Imageindikator an.
Damit war der Softwarestand als Ausgangspunkt geklärt. Daraus folgte aber noch keine Erklärung für den Downloadfehler. Eine grüne Imageanzeige beschreibt den Imagezustand; sie prüft keine Update-Datei vom Client bis zum Ziel.
Wir stiessen deshalb auf einem betroffenen Client einen neuen Updateversuch an und untersuchten dessen Anfragen. So liessen sich aktuelle Meldungen vom allgemeinen Hintergrundverkehr trennen.
Was die Caddy-Zugriffe in Graylog zeigten
Die HTTP-Zugriffslogs von Caddy liefen bereits zentral in Graylog ein. Unsere Verarbeitung extrahiert unter anderem Hostname, Client-IP, URI, Statuscode, Antwortgrösse und Dauer aus dem JSON-Zugriffslog. Die folgenden Feldnamen stammen aus dieser eigenen Verarbeitung; andere Installationen können sie anders benennen.
Für den ersten Überblick verwendeten wir einen begrenzten Zeitraum rund um den Test und diese Suche:
http_host:"updates-proxy.example.net"Interessant waren dabei diese Felder:
timestamp
client_ip
http_uri
http_status
http_duration_ms
http_response_bytesWir exportierten zunächst alle Statuscodes. Wer sofort nur Fehler ab HTTP 400 betrachtet, übersieht möglicherweise Antworten, die bereits mit 200 oder 206 begonnen haben, deren Übertragung aber nicht vollständig war.
Der untersuchte Export enthielt 56 Anfragen. Davon wurden 36 mit HTTP 200 beantwortet. Weitere 20 erhielten HTTP 403 und gehörten zu einer anderen öffentlichen Quell-IP. Diese Ablehnungen passten zur vorgeschalteten IP-Freigabe im Caddy-Routing und blieben ein eigener Befund. Sie durften dem untersuchten Client nicht allein deshalb zugeordnet werden, weil sie im selben Zeitfenster auftraten.
Für den Standort des Testclients sahen wir erfolgreiche Aufrufe der WSUS-Webdienste. Im Export fehlten jedoch Anfragen nach Update-Dateien unter dem Content-Pfad. Das war der Anlass, das Windows-Updateprotokoll auf dem Client zu untersuchen. Der Export war auf den neuen Proxy-Namen gefiltert und konnte Zugriffe auf ein anderes Downloadziel nicht abbilden.
Das Clientprotokoll lieferte die tatsächliche Downloadadresse
Zunächst prüften wir Warnungen und Fehler im Windows-Update-Ereignisprotokoll. Im gewählten Zeitraum gab es keine passenden Einträge. Auch die Abfrage laufender BITS-Aufträge blieb leer.
Beides zusammen genügte nicht als Aussage über den Downloadzustand. Das ausführliche Windows-Updateprotokoll zeigte anschliessend, dass der betroffene Auftrag Delivery Optimization verwendete. Eine leere BITS-Liste erfasst diesen Auftrag nicht.
Das lesbare Protokoll erzeugten wir in einer administrativen PowerShell:
Get-WindowsUpdateLog -LogPath "$env:PUBLIC\WindowsUpdate-Diagnose.log"Darin fanden wir den fehlgeschlagenen Download einer WebView2-Installationsdatei. Der Fehlercode lautete 0x80D02002. Die Microsoft-Fehlerdefinition bezeichnet ihn als DO_E_DOWNLOAD_NO_PROGRESS: Innerhalb des vorgesehenen Zeitraums machte der Dateiabruf keinen Fortschritt. Das Protokoll zeigte rund 220 MB erwartete Daten und null übertragene Bytes. Microsoft-Definition der Delivery-Optimization-Fehler
Neben dem Fehlercode war die vollständige Datei-URL entscheidend. Sie zeigte auf den bisherigen HTTP-Downloadzugang. Auch der neu angestossene Auftrag verwendete dieses Ziel. Die Updatesuche nutzte dagegen bereits den neuen HTTPS-Proxy.
Damit hatten wir einen konkreten Ansatzpunkt: Dieselbe Datei über beide Zugänge testen, statt weitere allgemeine Änderungen an Caddy vorzunehmen.
Dieselbe Datei mit einem Range Request vergleichen
Für den Vergleich forderten wir nur die ersten 1024 Bytes der betroffenen Datei an. Die Beispiele verwenden einen neutralisierten Dateinamen; in einer eigenen Untersuchung müssen hier der exakte Pfad und die vollständige bisherige Download-URL aus dem Clientprotokoll eingesetzt werden.
$pfad = '/Content/AB/BEISPIELDATEI.exe'
$bisherigeDateiUrl = '<vollstaendige Download-URL aus dem Clientprotokoll>'
curl.exe --connect-timeout 10 --max-time 20 --range 0-1023 `
--dump-header - --output NUL $bisherigeDateiUrl
curl.exe --connect-timeout 10 --max-time 20 --range 0-1023 `
--dump-header - --output NUL "https://updates-proxy.example.net$pfad"Beim ersten Aufruf lief bereits der Verbindungsaufbau nach zehn Sekunden in einen Timeout. Über den neuen Proxy wurde dieselbe Datei mit HTTP 206 Partial Content beantwortet. Die Antwort enthielt Accept-Ranges: bytes, eine Content-Length von 1024 und einen dazu passenden Content-Range.
Die Range-Angabe ist eine Anforderung an den Server. Ein Server kann sie ignorieren und die gesamte Datei senden; deshalb begrenzten wir zusätzlich die Laufzeit und prüften die tatsächlichen Antwortheader. Bei unserem Test wurden genau die angeforderten 1024 Bytes übertragen.
Dieser Vergleich belegte die Erreichbarkeit der Datei über den Proxy und einen funktionierenden Teilabruf. Den vollständigen Download mussten wir anschliessend weiterhin mit Windows Update prüfen. Die genaue Sperrstelle am bisherigen Zugang war durch den Timeout allein ebenfalls noch nicht bestimmt.
Den Proxy als alternativen Downloadserver setzen
Die Korrektur nutzte die Windows-Update-Einstellung für einen alternativen Downloadserver. Sie weist den Updateclient an, die Dateien über den angegebenen Server zu beziehen. In unserem Fall konnte Caddy die vorhandenen Content-Pfade bereits korrekt weiterleiten. Microsoft zum alternativen Downloadserver
Für einen einzelnen Testclient sicherten wir zuerst den bestehenden Windows-Update-Richtlinienzweig. Danach ergänzten wir den Wert UpdateServiceUrlAlternate als REG_SZ. Der folgende Befehl zeigt die eigentliche Änderung mit einer Beispieladresse; die Eingabeaufforderung muss als Administrator laufen.
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v UpdateServiceUrlAlternate /t REG_SZ /d "https://updates-proxy.example.net" /fWir trugen die Basisadresse ein, ohne einen zusätzlichen Content-Pfad anzuhängen. Suche und Reporting behielten ihre bestehenden Adressen. Die Option FillEmptyContentUrls benötigten wir nicht: Die Metadaten enthielten bereits eine Datei-URL, deren Zugangsweg hier ersetzt werden sollte.
Nach der Änderung starteten wir den Windows-Update-Dienst auf dem Testclient neu und stiessen den Updateversuch erneut an. Der Download wurde vollständig abgeschlossen. Anschliessend lief auch die Installation erfolgreich durch. Damit ging die Abnahme über den vorherigen Teilabruf hinaus.
Die Einstellung dauerhaft verteilen
Für verwaltete Clients gehört diese Konfiguration in die zuständige Gruppenrichtlinie. In der Richtlinie zur Angabe des internen Microsoft-Updatedienstes lässt sich der alternative Downloadserver als zusätzlicher Wert hinterlegen. Wenn die verwendete Verwaltungsoberfläche dieses Feld nicht anbietet, kann derselbe Registrywert über eine Registrierungseinstellung der Gruppenrichtlinien-Einstellungen verteilt werden.
Wir wählten dafür die Aktion Aktualisieren, die Struktur HKEY_LOCAL_MACHINE, den Schlüssel SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate und den benannten Zeichenfolgenwert UpdateServiceUrlAlternate. Dabei muss tatsächlich der benannte Wert angelegt werden; der Standardwert des Schlüssels erfüllt diese Aufgabe nicht.
Für Geräte ausserhalb einer Domäne lässt sich der Wert lokal setzen. Entscheidend bleibt, dass deren übrige WSUS-Konfiguration und die Zugriffsfreigabe am Proxy ebenfalls passen. Der Eintrag allein richtet keinen vollständigen WSUS-Client ein.
Nach der Richtlinienaktualisierung kontrollierten wir den Wert mit:
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v UpdateServiceUrlAlternateEin bereits manuell korrigierter Pilotclient beweist dabei noch keine zentrale Verteilung. Dafür ist die Kontrolle auf einem weiteren Gerät erforderlich. Auch bestehende Downloadaufträge können noch die vorherige URL enthalten. Bleibt ein Auftrag hängen, prüfen wir deshalb dessen aktuelle Adresse erneut, bevor wir Caches oder Warteschlangen zurücksetzen.
Die beiden TLS Verbindungen unterscheiden
Bei einem Reverse-Proxy müssen die Verbindung zum Client und die Verbindung zum Backend getrennt betrachtet werden. Eine erfolgreiche HTTPS-Verbindung zum Proxy beschreibt zunächst nur die erste Strecke. Der Transport zum Backend wird unabhängig davon konfiguriert und geprüft.
Client -- HTTPS --> Caddy -- separate Backendverbindung --> WSUSDer Registryeintrag verschlüsselt nicht automatisch die zweite Strecke. Er wählt den Downloadzugang des Clients. Wer zusätzlich die Backendverbindung mit HTTPS betreiben möchte, muss dafür Zertifikat und Vertrauen auf Caddy einrichten. Die externen Clients sehen weiterhin nur das Frontendzertifikat des Proxys und brauchen deshalb nicht allein wegen dieses Backendwechsels die interne CA. Caddy zu HTTPS-Upstreams
Was wir bei der nächsten Umstellung prüfen
Eine erreichbare WSUS-Webservice-Seite ist ein sinnvoller Verbindungstest. Für die Abnahme einer Umstellung reicht sie uns künftig nicht mehr. Dazu gehören die tatsächliche Datei-URL auf dem Client, ein erfolgreicher Content-Abruf und ein vollständiger Update-Download mit anschliessender Installation.
In diesem Fall führte uns die Kombination der Werkzeuge zur Korrektur: Graylog zeigte funktionierende Webservice-Aufrufe und einen getrennten Freigabefehler. Das Clientprotokoll zeigte den Downloadauftrag und sein abweichendes Ziel. Der Vergleich derselben Datei machte den Unterschied der beiden Zugänge sichtbar.
Der Proxy konnte die Datei liefern. Windows musste diesen Zugang auch für den Download verwenden. Genau diese Lücke schloss der alternative Downloadserver auf dem getesteten Client.