Zeigt Windows eine IPv4-Adresse wie 169.254.37.112 an, hat der Computer in der Regel keine reguläre Adresse vom Router oder einem anderen DHCP-Server erhalten. Windows weist sich dann selbst eine sogenannte APIPA-Adresse zu. APIPA steht für Automatic Private IP Addressing und verwendet den reservierten Bereich von 169.254.0.0 bis 169.254.255.255. Die Adresse ist daher nicht die eigentliche Ursache des Problems, sondern ein deutliches Symptom: Der Netzwerkadapter funktioniert zumindest so weit, dass Windows ihn verwenden kann, doch die automatische Vergabe einer gültigen Netzwerkkonfiguration ist fehlgeschlagen. Microsoft beschreibt APIPA ausdrücklich als Ersatzmechanismus für den Fall, dass ein auf automatische Adressvergabe eingestellter Rechner keinen DHCP-Server erreicht.
Weshalb mit 169.254 meistens kein Internet funktioniert
Eine APIPA-Adresse ermöglicht grundsätzlich eine begrenzte Kommunikation mit anderen Geräten, die sich im selben lokalen Adressbereich befinden. Sie enthält jedoch normalerweise weder ein passendes Standardgateway noch eine brauchbare Verbindung zum Router. Ohne Standardgateway weiß der Computer nicht, wohin er Daten senden soll, deren Ziel außerhalb des eigenen lokalen Netzes liegt. Webseiten, Cloud-Dienste und externe Server bleiben deshalb unerreichbar. Das Problem lässt sich auch nicht allein durch einen anderen DNS-Server beheben. DNS übersetzt lediglich Namen wie beispiel.de in IP-Adressen. Fehlt bereits der Weg zum Router, hilft weder 1.1.1.1 noch 8.8.8.8 als manuell eingetragener DNS-Server.
Die Adresse mit ipconfig eindeutig erkennen
Die aktuelle Netzwerkkonfiguration lässt sich über das Windows-Terminal oder die Eingabeaufforderung überprüfen. Nach dem Befehl ipconfig /all erscheint für jeden Netzwerkadapter ein eigener Abschnitt. Entscheidend sind die Zeilen „IPv4-Adresse“, „DHCP aktiviert“, „Standardgateway“ und „DHCP-Server“. Steht als IPv4-Adresse eine Nummer mit 169.254 am Anfang und fehlt gleichzeitig das Standardgateway, verwendet Windows eine automatisch erzeugte Ersatzadresse. Bei einem üblichen Heimnetz wäre stattdessen beispielsweise eine Adresse aus den Bereichen 192.168.x.x, 10.x.x.x oder 172.16.x.x bis 172.31.x.x zu erwarten. Microsoft führt ipconfig /all als vorgesehenes Werkzeug zur Anzeige der vollständigen TCP/IP-Konfiguration aller Netzwerkadapter auf.
Zuerst klären, ob nur ein Gerät betroffen ist
Bevor Einstellungen verändert werden, sollte ein zweites Gerät am selben Netzwerkanschluss getestet werden. Funktionieren Smartphone, Tablet und ein anderer Computer über denselben Router weiterhin, arbeitet der DHCP-Dienst des Routers wahrscheinlich grundsätzlich. Die Suche kann dann auf den betroffenen Rechner, dessen Kabel, WLAN-Verbindung oder Netzwerkadapter eingegrenzt werden. Erhalten dagegen mehrere Geräte gleichzeitig keine reguläre IP-Adresse, liegt die Ursache eher beim Router, Switch, Access Point oder zentralen DHCP-Server. Diese Unterscheidung verhindert, dass Windows zurückgesetzt wird, obwohl tatsächlich der Router keine Adressen mehr verteilt.
Bei Ethernet zuerst Kabel und Port kontrollieren
Eine 169.254-Adresse kann auch entstehen, obwohl Windows den Ethernet-Adapter als verbunden anzeigt. Ein beschädigtes Kabel, eine fehlerhafte Netzwerkdose oder ein instabiler Switch-Port kann noch einen elektrischen Link herstellen, aber die für DHCP erforderliche Kommunikation verhindern. Der Rechner sollte deshalb testweise mit einem kurzen, sicher funktionierenden Patchkabel direkt an einen anderen LAN-Port des Routers angeschlossen werden. Zwischenstücke wie Powerline-Adapter, kleine Switches, Wanddosen und Dockingstationen werden für diesen Test vollständig umgangen. Microsoft nennt funktionierende Kabel, einen aktivierten Netzwerkadapter und einen korrekt arbeitenden Treiber ausdrücklich als grundlegende Prüfpunkte bei DHCP-Problemen.
Im WLAN ist „verbunden“ nicht immer wirklich verbunden
Bei einer drahtlosen Verbindung bedeutet die Anzeige „Verbunden“ lediglich, dass der Rechner eine WLAN-Verbindung zu einem Zugangspunkt aufgebaut hat. Sie beweist nicht, dass der Access Point den Datenverkehr korrekt zum Router weiterleitet. Besonders bei Repeatern, Mesh-Knoten und Gastnetzwerken kann die Funkverbindung bestehen, während die Verbindung zwischen Zugangspunkt und Router unterbrochen ist. Ein sinnvoller Test besteht darin, sich in unmittelbarer Nähe des Hauptrouters direkt mit dessen WLAN zu verbinden. Erhält der Computer dort sofort eine reguläre Adresse, liegt der Fehler wahrscheinlich beim Repeater, Mesh-Knoten oder dessen Rückkanal. Bleibt es bei 169.254, sollte das gespeicherte WLAN-Profil entfernt und die Verbindung mit dem korrekten Kennwort neu eingerichtet werden.
Eine neue DHCP-Anfrage gezielt auslösen
Windows kann eine bestehende Adresszuweisung freigeben und anschließend eine neue Konfiguration anfordern. Dazu wird das Terminal als Administrator geöffnet. Mit ipconfig /release verwirft Windows die aktuelle DHCP-Konfiguration, während ipconfig /renew eine neue Adresse vom DHCP-Server anfordert. Der zweite Befehl kann einige Sekunden benötigen. Erscheint anschließend erneut eine 169.254-Adresse oder eine Meldung, dass der DHCP-Server nicht erreichbar sei, ist das Problem nicht durch einen veralteten Eintrag entstanden. Die Anfrage erreicht den DHCP-Server entweder nicht oder dessen Antwort kommt nicht beim Computer an. Microsoft dokumentiert /release und /renew ausdrücklich für Computer, die ihre Netzwerkkonfiguration automatisch beziehen.
Warum ipconfig flushdns hier selten hilft
Der häufig empfohlene Befehl ipconfig /flushdns leert den lokalen DNS-Auflösungsspeicher. Das kann sinnvoll sein, wenn einzelne Webseiten unter einer falschen oder veralteten Adresse aufgerufen werden. Eine fehlgeschlagene DHCP-Vergabe behebt der Befehl jedoch nicht. Hat der Rechner eine 169.254-Adresse und kein Standardgateway, besteht das Problem bereits vor der Namensauflösung. Das Leeren des DNS-Caches verändert weder die eigene IPv4-Adresse noch den DHCP-Server oder die Verbindung zum Router. Microsoft ordnet /flushdns der Bereinigung des DNS-Resolver-Caches zu, während /renew für die Erneuerung einer automatisch bezogenen IP-Konfiguration zuständig ist.
Automatische IP-Vergabe in Windows überprüfen
Eine alte manuelle Konfiguration kann verhindern, dass Windows die passende Adresse vom Router übernimmt. Über ncpa.cpl lassen sich die klassischen Netzwerkverbindungen öffnen. Nach einem Rechtsklick auf den verwendeten Adapter werden dessen Eigenschaften und anschließend „Internetprotokoll, Version 4 (TCP/IPv4)“ ausgewählt. In einem gewöhnlichen Heimnetz sollten sowohl „IP-Adresse automatisch beziehen“ als auch „DNS-Serveradresse automatisch beziehen“ aktiviert sein. Wurden dort früher feste Werte eingetragen, können sie nach einem Routerwechsel oder in einem anderen Netzwerk unbrauchbar geworden sein. Nach der Umstellung sollte der Adapter kurz deaktiviert und wieder aktiviert oder der Rechner neu gestartet werden.
Den DHCP-Clientdienst nicht mit dem DHCP-Server verwechseln
Windows besitzt einen lokalen Dienst mit der Bezeichnung „DHCP-Client“. Dieser Dienst verteilt selbst keine Adressen, sondern verarbeitet die automatische Konfiguration des Computers. Über services.msc lässt sich prüfen, ob der Dienst ausgeführt wird. Ist er beendet oder deaktiviert, kann der Rechner keine normale DHCP-Lease beziehen. Der Starttyp sollte üblicherweise nicht manuell auf „Deaktiviert“ gesetzt werden. Microsoft nennt einen gestarteten DHCP-Clientdienst als einen der grundlegenden Prüfpunkte bei der Diagnose fehlgeschlagener Adressvergaben.
Ein Routerneustart sollte vollständig erfolgen
Ein kurzes Aus- und Einschalten über einen Taster startet nicht bei jedem Router sämtliche Netzwerkfunktionen neu. Für einen vollständigen Neustart wird das Gerät von der Stromversorgung getrennt und nach einer kurzen Unterbrechung wieder angeschlossen. Danach muss abgewartet werden, bis Internetverbindung, LAN und WLAN vollständig betriebsbereit sind. Ein Routerneustart ist besonders sinnvoll, wenn mehrere Geräte betroffen sind oder der Fehler nach längerer Laufzeit plötzlich auftritt. Vorhandene Einstellungen werden dadurch normalerweise nicht gelöscht. Ein Zurücksetzen auf Werkseinstellungen ist etwas völlig anderes und sollte erst erfolgen, wenn Zugangsdaten, Telefoniekonfiguration und individuelle Netzwerkeinstellungen gesichert wurden.
Ein voller DHCP-Adresspool kann neue Geräte aussperren
Der Router verteilt Adressen nur aus einem festgelegten Bereich. Reicht dieser beispielsweise von 192.168.1.100 bis 192.168.1.120, stehen maximal 21 Adressen innerhalb dieses Pools zur Verfügung. Viele Smartphones, Fernseher, Kameras, Sprachassistenten und Smart-Home-Geräte können einen kleinen Bereich vollständig belegen. Neu hinzukommende Geräte erhalten dann möglicherweise keine Adresse mehr. In der Routeroberfläche sollte deshalb geprüft werden, wie groß der DHCP-Bereich ist und wie viele aktive oder reservierte Einträge existieren. Alte Reservierungen, die dauerhaft Adressen blockieren, können ebenfalls eine Rolle spielen. Der Bereich darf erweitert werden, sofern die neuen Adressen nicht mit manuell vergebenen IP-Adressen anderer Geräte kollidieren.
Gastnetzwerke und Zugangsbeschränkungen als Ursache
Einige Router und Access Points verweigern unbekannten Geräten den Netzwerkzugang oder stellen neue WLAN-Teilnehmer zunächst in ein eingeschränktes Netz. Funktionen wie MAC-Adressfilter, Kindersicherung, Gerätefreigabe und Netzwerkzugangskontrolle können verhindern, dass ein DHCP-Austausch erfolgreich abgeschlossen wird. Das betrifft besonders Geräte mit zufälliger beziehungsweise privater MAC-Adresse. Verwendet Windows bei jeder Verbindung eine andere Hardwareadresse, kann der Router den Computer als neues Gerät behandeln. Testweise lässt sich die zufällige Hardwareadresse für das betreffende WLAN deaktivieren. Gleichzeitig sollte in der Routeroberfläche geprüft werden, ob das Gerät blockiert ist oder erst freigegeben werden muss.
Virtuelle Adapter können die Diagnose verwirren
Virtualisierungsprogramme, VPN-Clients, Container-Plattformen und Sicherheitssoftware installieren häufig zusätzliche Netzwerkadapter. Auch diese Adapter können Adressen aus ungewöhnlichen Bereichen besitzen. Eine 169.254-Adresse auf einem ungenutzten virtuellen Adapter muss deshalb nicht das aktive Problem darstellen. Bei ipconfig /all ist entscheidend, welcher Abschnitt zum tatsächlich verwendeten Ethernet- oder WLAN-Adapter gehört. Ein virtueller Adapter sollte nicht allein wegen seiner Adresse gelöscht werden. Sinnvoller ist es, VPN-Software vorübergehend zu beenden und zu prüfen, ob Filtertreiber oder Netzwerkbrücken die physische Verbindung beeinflussen. Die aktive Verbindung lässt sich in PowerShell zusätzlich mit Get-NetAdapter identifizieren.
Firewallregeln können DHCP blockieren
DHCP verwendet für IPv4 die UDP-Ports 67 und 68. Normalerweise berücksichtigt die Windows-Firewall diesen Verkehr automatisch. Fremde Sicherheitssoftware, besonders restriktive Firewallprogramme oder fehlerhafte Unternehmensrichtlinien können die Kommunikation jedoch unterbrechen. Microsoft nennt blockierte UDP-Ports 67 und 68 ausdrücklich als mögliche Ursache, wenn ein Client keine Adresse erhält. Ein kurzfristiger Test ohne eine zusätzlich installierte Firewall kann deshalb sinnvoll sein, sofern der Rechner währenddessen nicht ungeschützt direkt mit einem öffentlichen Netz verbunden wird. Die Windows-Firewall sollte nicht dauerhaft deaktiviert werden.
Wann ein Netzwerkreset sinnvoll wird
Windows bietet unter den erweiterten Netzwerkeinstellungen einen Netzwerkreset an. Dabei werden Netzwerkadapter entfernt, neu eingerichtet und zahlreiche zugehörige Einstellungen auf Standardwerte zurückgesetzt. Diese Maßnahme kann beschädigte Adapterkonfigurationen, fehlerhafte Protokollbindungen oder hartnäckige Softwareprobleme beseitigen. Sie sollte aber nicht am Anfang der Diagnose stehen. Gespeicherte Netzwerke, VPN-Konfigurationen, virtuelle Adapter und individuelle Einstellungen können anschließend neu eingerichtet werden müssen. Bleibt die 169.254-Adresse auch bei einer direkten Kabelverbindung zu einem funktionierenden Router bestehen, während ein anderer Computer am selben Kabel sofort eine korrekte Adresse bekommt, wird ein Netzwerkreset plausibler.
Eine feste IP-Adresse ist nur ein Diagnosetest
Eine manuell eingetragene IP-Adresse kann vorübergehend zeigen, ob die grundlegende Verbindung zum Router funktioniert. Verwendet der Router beispielsweise 192.168.1.1, könnte testweise eine garantiert freie Adresse aus demselben Netz mit passender Subnetzmaske und dem Router als Gateway eingetragen werden. Funktioniert damit der Zugriff auf die Routeroberfläche, während DHCP weiterhin scheitert, ist die physische Verbindung wahrscheinlich intakt und das Problem liegt bei der automatischen Adressvergabe. Eine beliebig ausgewählte feste Adresse ist jedoch keine dauerhafte Lösung. Ist sie bereits vergeben, entsteht ein IP-Adresskonflikt. Außerdem funktionieren Gateway, DNS und Netzwerkzugriff nur, wenn sämtliche Werte zum vorhandenen Netz passen.
Die Ereignisanzeige liefert Hinweise bei hartnäckigen Fehlern
Bei wiederkehrenden Problemen kann die Windows-Ereignisanzeige zeigen, weshalb die Adressvergabe fehlschlägt. Relevante Einträge befinden sich unter den Anwendungs- und Dienstprotokollen im Bereich der Microsoft-Windows-DHCP-Client-Ereignisse. Dort können Zeitüberschreitungen, abgelehnte Anfragen und Probleme mit dem Netzwerkadapter protokolliert sein. Microsoft empfiehlt bei der professionellen DHCP-Fehlersuche ausdrücklich die Protokolle „DHCP Client Events/Operational“ und „DHCP Client Events/Admin“. Besonders hilfreich ist es, unmittelbar nach einem fehlgeschlagenen ipconfig /renew nach neuen Einträgen zu suchen.
Die schnellste Reihenfolge zur eindeutigen Fehlerquelle
Eine effiziente Diagnose beginnt mit ipconfig /all und der Prüfung, ob tatsächlich der aktive Adapter eine 169.254-Adresse besitzt. Danach wird festgestellt, ob weitere Geräte betroffen sind. Bei Ethernet folgen ein anderes Kabel, ein anderer Router-Port und eine direkte Verbindung ohne Zwischenkomponenten. Bei WLAN wird die Verbindung zum Hauptrouter statt zu einem Repeater getestet. Anschließend werden automatische IPv4-Einstellungen, DHCP-Clientdienst und Routerkonfiguration kontrolliert. Erst danach sind Treiberneuinstallation, Netzwerkreset oder eine feste Testadresse sinnvoll. Die 169.254-Adresse muss dabei nicht bekämpft oder gelöscht werden. Sobald Windows wieder eine gültige Antwort vom DHCP-Server erhält, wird die Ersatzadresse automatisch durch eine reguläre Netzwerkkonfiguration ersetzt.
