build 6ddc7a35 | content blog-content@417154f · 338 posts | profiles 32 · corpus 315 | ● 0 skipped | format run

$ soultec get post/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself -o yaml$ soultec get post/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself -o json$ soultec get post/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself -o toml$ soultec get post/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself -o xml$ python3 how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.pyPS> ./how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.ps1$ go run how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.go$ node how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.js

apiVersion: soultec.ch/v1kind: Postmetadata: name: how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself locale: de labels: author: valentina-cicmak series: how-to capability/automation: 1.81 capability/network: 2.16 annotations: source: blog-content/posts/de/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md route: /de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/ schema: /nerd/schema/posts.json markdown: /de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.mdspec: title: >- Windows Server ohne Internet, weil die Default Route auf ihn selbst zeigt date: 2026-06-09 author: valentina-cicmak locale: de summary: >- Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Meistens ist es nicht DNS, sondern das Routing. capabilities: [automation, network] series: how-to hero: >- /blog-assets/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/hero.webp migrated: 2026-08-24 translationReviewed: false draft: false sections: - body: | Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Die IP-Adresse steht, die Subnetzmaske stimmt, DNS Server sind konfiguriert, und das Default Gateway zeigt scheinbar auf den Router. Lokale Geräte im selben Netz antworten auf Ping, aber ins Internet kommt der Server nicht. In dieser Situation liegt es oft nicht an DNS, sondern am Routing. ### Lösung Windows braucht eine Default Route für allen Verkehr ausserhalb des lokalen Subnetzes. Um das zu prüfen, öffnest du die Eingabeaufforderung oder PowerShell und führst aus: ```powershell route print ``` Sieh dir in der Ausgabe die IPv4 Route Table an und darin den Abschnitt Active Routes. Die Default Route ist die Zeile, in der Network Destination und Netmask beide 0.0.0.0 sind. Eine korrekte Default Route sieht üblicherweise so aus: ```powershell 0.0.0.0 0.0.0.0 10.177.192.1 ``` Dabei ist 10.177.192.1 der Router oder die Firewall. Dorthin muss der Internetverkehr. Das Problem taucht auf, wenn in der Routing-Tabelle eine Route wie diese steht: ```powershell 0.0.0.0 0.0.0.0 On-link 10.177.192.5 ``` oder wenn der Server seine eigene IP-Adresse als Gateway verwendet: ```powershell 0.0.0.0 0.0.0.0 10.177.192.5 ``` In diesem Beispiel ist 10.177.192.5 der Server selbst. Windows schickt den Internetverkehr also an sich selbst statt an den Router. Die Kommunikation im lokalen Netz funktioniert weiterhin, weil lokale Geräte direkt erreichbar sind. Der Internetzugang scheitert, weil der Verkehr nie beim echten Gateway ankommt. Danach testest du die Verbindung Schritt für Schritt: ```powershell ping 10.177.192.1 ping 8.8.8.8 nslookup google.com ``` Wenn das Gateway antwortet, 8.8.8.8 aber nicht, liegt es sehr wahrscheinlich am Routing. Wenn 8.8.8.8 funktioniert, google.com aber nicht, liegt es sehr wahrscheinlich an DNS. Um die kaputte Default Route zu entfernen, nimm diese Vorlage: ```powershell route delete 0.0.0.0 mask 0.0.0.0 ``` Zum Beispiel: ```powershell route delete 0.0.0.0 mask 0.0.0.0 10.177.192.5 ``` Damit ist die falsche Route weg, mit der der Server den Internetverkehr an sich selbst geschickt hat. Danach setzt du die Adapter-Konfiguration sauber neu. Der folgende Befehl ist nur eine Vorlage. Ersetz Adaptername, IP-Adresse, Subnetzmaske, Gateway und Metrik durch die Werte deines eigenen Netzes: ```powershell netsh interface ipv4 set address name="" static ``` Zum Beispiel: ```powershell netsh interface ipv4 set address name="Ethernet0" static 10.177.192.5 255.255.255.0 10.177.192.1 1 ``` Hier ist Ethernet0 der Netzwerkadapter, 10.177.192.5 die Server-IP, 255.255.255.0 die Subnetzmaske, 10.177.192.1 das echte Gateway und 1 die Metrik der Route. Nach dem Befehl prüfst du die Routing-Tabelle noch einmal: ```powershell route print ``` Die Default Route sollte jetzt auf das echte Gateway zeigen: ```powershell 0.0.0.0 0.0.0.0 10.177.192.1 ``` Warum das besser funktioniert, als dieselben Werte in den Windows-Netzwerkeinstellungen zu ändern: Die grafische Oberfläche kann korrekte Werte anzeigen, während in der Routing-Tabelle immer noch eine alte oder kaputte Route steht. Software, virtuelle Adapter, VPN Clients, Netzwerktreiber oder Management-Werkzeuge können die Routing-Tabelle beeinflussen. Die Kommandozeile setzt die Adapter-Konfiguration direkter neu und zwingt Windows, die Route sauber neu anzulegen. Die Lehre ist einfach: Wenn ein Windows Server das lokale Netz erreicht, aber nicht das Internet, prüf nicht nur die Felder für IP, DNS und Gateway. Sieh dir immer route print an. Wenn die Default Route auf den Server selbst zeigt, schickt Windows den Verkehr in die falsche Richtung. - heading:

Wie weiter

body: | Wenn du bis hierher gelesen hast, läuft es bei dir vermutlich immer noch nicht. [Melde dich bei uns](https://soultec.ch/contact-us/), wir helfen gerne.status: corpus: 315 alsoLike: - {ref: posts/how-to-fix-fix-static-windows-network-settings-reset-after-reboot, score: 0.54} - {ref: posts/vmware-software-defined-wan, score: 0.53} - {ref: solutions/vmware, score: 0.53} search: /de/search.json
{ "apiVersion": "soultec.ch/v1", "kind": "Post", "metadata": { "name": "how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself", "locale": "de", "labels": { "author": "valentina-cicmak", "series": "how-to", "capability/automation": 1.81, "capability/network": 2.16 }, "annotations": { "source": "blog-content/posts/de/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md", "route": "/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/", "schema": "/nerd/schema/posts.json", "markdown": "/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md" } }, "spec": { "title": "Windows Server ohne Internet, weil die Default Route auf ihn selbst zeigt", "date": "2026-06-09", "author": "valentina-cicmak", "locale": "de", "summary": "Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Meistens ist es nicht DNS, sondern das Routing.", "capabilities": [ "automation", "network" ], "series": "how-to", "hero": "/blog-assets/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/hero.webp", "migrated": "2026-08-24", "translationReviewed": false, "draft": false, "sections": [ { "body": "Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Die IP-Adresse steht, die Subnetzmaske stimmt, DNS Server sind konfiguriert, und das Default Gateway zeigt scheinbar auf den Router. Lokale Geräte im selben Netz antworten auf Ping, aber ins Internet kommt der Server nicht.\n\nIn dieser Situation liegt es oft nicht an DNS, sondern am Routing.\n\n### Lösung\n\nWindows braucht eine Default Route für allen Verkehr ausserhalb des lokalen Subnetzes. Um das zu prüfen, öffnest du die Eingabeaufforderung oder PowerShell und führst aus:\n\n```powershell\nroute print\n```\n\nSieh dir in der Ausgabe die IPv4 Route Table an und darin den Abschnitt Active Routes. Die Default Route ist die Zeile, in der Network Destination und Netmask beide 0.0.0.0 sind.\n\nEine korrekte Default Route sieht üblicherweise so aus:\n\n```powershell\n0.0.0.0 0.0.0.0 10.177.192.1\n```\n\nDabei ist 10.177.192.1 der Router oder die Firewall. Dorthin muss der Internetverkehr.\n\nDas Problem taucht auf, wenn in der Routing-Tabelle eine Route wie diese steht:\n\n```powershell\n0.0.0.0 0.0.0.0 On-link 10.177.192.5\n```\n\noder wenn der Server seine eigene IP-Adresse als Gateway verwendet:\n\n```powershell\n0.0.0.0 0.0.0.0 10.177.192.5\n```\n\nIn diesem Beispiel ist 10.177.192.5 der Server selbst. Windows schickt den Internetverkehr also an sich selbst statt an den Router. Die Kommunikation im lokalen Netz funktioniert weiterhin, weil lokale Geräte direkt erreichbar sind. Der Internetzugang scheitert, weil der Verkehr nie beim echten Gateway ankommt.\n\nDanach testest du die Verbindung Schritt für Schritt:\n\n```powershell\nping 10.177.192.1\nping 8.8.8.8\nnslookup google.com\n```\n\nWenn das Gateway antwortet, 8.8.8.8 aber nicht, liegt es sehr wahrscheinlich am Routing. Wenn 8.8.8.8 funktioniert, google.com aber nicht, liegt es sehr wahrscheinlich an DNS.\n\nUm die kaputte Default Route zu entfernen, nimm diese Vorlage:\n\n```powershell\nroute delete 0.0.0.0 mask 0.0.0.0\n```\n\nZum Beispiel:\n\n```powershell\nroute delete 0.0.0.0 mask 0.0.0.0 10.177.192.5\n```\n\nDamit ist die falsche Route weg, mit der der Server den Internetverkehr an sich selbst geschickt hat.\n\nDanach setzt du die Adapter-Konfiguration sauber neu. Der folgende Befehl ist nur eine Vorlage. Ersetz Adaptername, IP-Adresse, Subnetzmaske, Gateway und Metrik durch die Werte deines eigenen Netzes:\n\n```powershell\nnetsh interface ipv4 set address name=\"\" static\n```\n\nZum Beispiel:\n\n```powershell\nnetsh interface ipv4 set address name=\"Ethernet0\" static 10.177.192.5 255.255.255.0 10.177.192.1 1\n```\n\nHier ist Ethernet0 der Netzwerkadapter, 10.177.192.5 die Server-IP, 255.255.255.0 die Subnetzmaske, 10.177.192.1 das echte Gateway und 1 die Metrik der Route.\n\nNach dem Befehl prüfst du die Routing-Tabelle noch einmal:\n\n```powershell\nroute print\n```\n\nDie Default Route sollte jetzt auf das echte Gateway zeigen:\n\n```powershell\n0.0.0.0 0.0.0.0 10.177.192.1\n```\n\nWarum das besser funktioniert, als dieselben Werte in den Windows-Netzwerkeinstellungen zu ändern: Die grafische Oberfläche kann korrekte Werte anzeigen, während in der Routing-Tabelle immer noch eine alte oder kaputte Route steht. Software, virtuelle Adapter, VPN Clients, Netzwerktreiber oder Management-Werkzeuge können die Routing-Tabelle beeinflussen. Die Kommandozeile setzt die Adapter-Konfiguration direkter neu und zwingt Windows, die Route sauber neu anzulegen.\n\nDie Lehre ist einfach: Wenn ein Windows Server das lokale Netz erreicht, aber nicht das Internet, prüf nicht nur die Felder für IP, DNS und Gateway. Sieh dir immer route print an. Wenn die Default Route auf den Server selbst zeigt, schickt Windows den Verkehr in die falsche Richtung." }, { "heading": "

Wie weiter

",
"body": "Wenn du bis hierher gelesen hast, läuft es bei dir vermutlich immer noch nicht. [Melde dich bei uns](https://soultec.ch/contact-us/), wir helfen gerne." } ] }, "status": { "corpus": 315, "alsoLike": [ { "ref": "posts/how-to-fix-fix-static-windows-network-settings-reset-after-reboot", "score": "0.54" }, { "ref": "posts/vmware-software-defined-wan", "score": "0.53" }, { "ref": "solutions/vmware", "score": "0.53" } ], "search": "/de/search.json" }}
apiVersion = "soultec.ch/v1"kind = "Post"[metadata]name = "how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself"locale = "de"[metadata.labels]author = "valentina-cicmak"series = "how-to""capability/automation" = 1.81"capability/network" = 2.16[metadata.annotations]source = "blog-content/posts/de/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md"route = "/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/"schema = "/nerd/schema/posts.json"markdown = "/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md"[spec]title = "Windows Server ohne Internet, weil die Default Route auf ihn selbst zeigt"date = 2026-06-09author = "valentina-cicmak"locale = "de"summary = "Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Meistens ist es nicht DNS, sondern das Routing."capabilities = ["automation", "network"]series = "how-to"hero = "/blog-assets/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/hero.webp"migrated = 2026-08-24translationReviewed = falsedraft = false[[spec.sections]]body = '''Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Die IP-Adresse steht, die Subnetzmaske stimmt, DNS Server sind konfiguriert, und das Default Gateway zeigt scheinbar auf den Router. Lokale Geräte im selben Netz antworten auf Ping, aber ins Internet kommt der Server nicht.In dieser Situation liegt es oft nicht an DNS, sondern am Routing.### LösungWindows braucht eine Default Route für allen Verkehr ausserhalb des lokalen Subnetzes. Um das zu prüfen, öffnest du die Eingabeaufforderung oder PowerShell und führst aus:```powershellroute print```Sieh dir in der Ausgabe die IPv4 Route Table an und darin den Abschnitt Active Routes. Die Default Route ist die Zeile, in der Network Destination und Netmask beide 0.0.0.0 sind.Eine korrekte Default Route sieht üblicherweise so aus:```powershell0.0.0.0 0.0.0.0 10.177.192.1```Dabei ist 10.177.192.1 der Router oder die Firewall. Dorthin muss der Internetverkehr.Das Problem taucht auf, wenn in der Routing-Tabelle eine Route wie diese steht:```powershell0.0.0.0 0.0.0.0 On-link 10.177.192.5```oder wenn der Server seine eigene IP-Adresse als Gateway verwendet:```powershell0.0.0.0 0.0.0.0 10.177.192.5```In diesem Beispiel ist 10.177.192.5 der Server selbst. Windows schickt den Internetverkehr also an sich selbst statt an den Router. Die Kommunikation im lokalen Netz funktioniert weiterhin, weil lokale Geräte direkt erreichbar sind. Der Internetzugang scheitert, weil der Verkehr nie beim echten Gateway ankommt.Danach testest du die Verbindung Schritt für Schritt:```powershellping 10.177.192.1ping 8.8.8.8nslookup google.com```Wenn das Gateway antwortet, 8.8.8.8 aber nicht, liegt es sehr wahrscheinlich am Routing. Wenn 8.8.8.8 funktioniert, google.com aber nicht, liegt es sehr wahrscheinlich an DNS.Um die kaputte Default Route zu entfernen, nimm diese Vorlage:```powershellroute delete 0.0.0.0 mask 0.0.0.0```Zum Beispiel:```powershellroute delete 0.0.0.0 mask 0.0.0.0 10.177.192.5```Damit ist die falsche Route weg, mit der der Server den Internetverkehr an sich selbst geschickt hat.Danach setzt du die Adapter-Konfiguration sauber neu. Der folgende Befehl ist nur eine Vorlage. Ersetz Adaptername, IP-Adresse, Subnetzmaske, Gateway und Metrik durch die Werte deines eigenen Netzes:```powershellnetsh interface ipv4 set address name="" static```Zum Beispiel:```powershellnetsh interface ipv4 set address name="Ethernet0" static 10.177.192.5 255.255.255.0 10.177.192.1 1```Hier ist Ethernet0 der Netzwerkadapter, 10.177.192.5 die Server-IP, 255.255.255.0 die Subnetzmaske, 10.177.192.1 das echte Gateway und 1 die Metrik der Route.Nach dem Befehl prüfst du die Routing-Tabelle noch einmal:```powershellroute print```Die Default Route sollte jetzt auf das echte Gateway zeigen:```powershell0.0.0.0 0.0.0.0 10.177.192.1```Warum das besser funktioniert, als dieselben Werte in den Windows-Netzwerkeinstellungen zu ändern: Die grafische Oberfläche kann korrekte Werte anzeigen, während in der Routing-Tabelle immer noch eine alte oder kaputte Route steht. Software, virtuelle Adapter, VPN Clients, Netzwerktreiber oder Management-Werkzeuge können die Routing-Tabelle beeinflussen. Die Kommandozeile setzt die Adapter-Konfiguration direkter neu und zwingt Windows, die Route sauber neu anzulegen.Die Lehre ist einfach: Wenn ein Windows Server das lokale Netz erreicht, aber nicht das Internet, prüf nicht nur die Felder für IP, DNS und Gateway. Sieh dir immer route print an. Wenn die Default Route auf den Server selbst zeigt, schickt Windows den Verkehr in die falsche Richtung.'''[[spec.sections]]heading = "

Wie weiter

"
body = "Wenn du bis hierher gelesen hast, läuft es bei dir vermutlich immer noch nicht. [Melde dich bei uns](https://soultec.ch/contact-us/), wir helfen gerne."[status]corpus = 315search = "/de/search.json"[[status.alsoLike]]ref = "posts/how-to-fix-fix-static-windows-network-settings-reset-after-reboot"score = "0.54"[[status.alsoLike]]ref = "posts/vmware-software-defined-wan"score = "0.53"[[status.alsoLike]]ref = "solutions/vmware"score = "0.53"
<?xml version="1.0" encoding="UTF-8"?><manifest kind="Post"> <apiVersion>soultec.ch/v1</apiVersion> <metadata> <name>how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself</name> <locale>de</locale> <labels> <author>valentina-cicmak</author> <series>how-to</series> <entry key="capability/automation">1.81</entry> <entry key="capability/network">2.16</entry> </labels> <annotations> <source>blog-content/posts/de/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md</source> <route>/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/</route> <schema>/nerd/schema/posts.json</schema> <markdown>/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md</markdown> </annotations> </metadata> <spec> <title>Windows Server ohne Internet, weil die Default Route auf ihn selbst zeigt</title> <date>2026-06-09</date> <author>valentina-cicmak</author> <locale>de</locale> <summary>Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Meistens ist es nicht DNS, sondern das Routing.</summary> <capabilities> <item>automation</item> <item>network</item> </capabilities> <series>how-to</series> <hero>/blog-assets/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/hero.webp</hero> <migrated>2026-08-24</migrated> <translationReviewed>false</translationReviewed> <draft>false</draft> <sections> <section> <body>Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Die IP-Adresse steht, die Subnetzmaske stimmt, DNS Server sind konfiguriert, und das Default Gateway zeigt scheinbar auf den Router. Lokale Geräte im selben Netz antworten auf Ping, aber ins Internet kommt der Server nicht.In dieser Situation liegt es oft nicht an DNS, sondern am Routing.### LösungWindows braucht eine Default Route für allen Verkehr ausserhalb des lokalen Subnetzes. Um das zu prüfen, öffnest du die Eingabeaufforderung oder PowerShell und führst aus:```powershellroute print```Sieh dir in der Ausgabe die IPv4 Route Table an und darin den Abschnitt Active Routes. Die Default Route ist die Zeile, in der Network Destination und Netmask beide 0.0.0.0 sind.Eine korrekte Default Route sieht üblicherweise so aus:```powershell0.0.0.0 0.0.0.0 10.177.192.1```Dabei ist 10.177.192.1 der Router oder die Firewall. Dorthin muss der Internetverkehr.Das Problem taucht auf, wenn in der Routing-Tabelle eine Route wie diese steht:```powershell0.0.0.0 0.0.0.0 On-link 10.177.192.5```oder wenn der Server seine eigene IP-Adresse als Gateway verwendet:```powershell0.0.0.0 0.0.0.0 10.177.192.5```In diesem Beispiel ist 10.177.192.5 der Server selbst. Windows schickt den Internetverkehr also an sich selbst statt an den Router. Die Kommunikation im lokalen Netz funktioniert weiterhin, weil lokale Geräte direkt erreichbar sind. Der Internetzugang scheitert, weil der Verkehr nie beim echten Gateway ankommt.Danach testest du die Verbindung Schritt für Schritt:```powershellping 10.177.192.1ping 8.8.8.8nslookup google.com```Wenn das Gateway antwortet, 8.8.8.8 aber nicht, liegt es sehr wahrscheinlich am Routing. Wenn 8.8.8.8 funktioniert, google.com aber nicht, liegt es sehr wahrscheinlich an DNS.Um die kaputte Default Route zu entfernen, nimm diese Vorlage:```powershellroute delete 0.0.0.0 mask 0.0.0.0```Zum Beispiel:```powershellroute delete 0.0.0.0 mask 0.0.0.0 10.177.192.5```Damit ist die falsche Route weg, mit der der Server den Internetverkehr an sich selbst geschickt hat.Danach setzt du die Adapter-Konfiguration sauber neu. Der folgende Befehl ist nur eine Vorlage. Ersetz Adaptername, IP-Adresse, Subnetzmaske, Gateway und Metrik durch die Werte deines eigenen Netzes:```powershellnetsh interface ipv4 set address name="" static```Zum Beispiel:```powershellnetsh interface ipv4 set address name="Ethernet0" static 10.177.192.5 255.255.255.0 10.177.192.1 1```Hier ist Ethernet0 der Netzwerkadapter, 10.177.192.5 die Server-IP, 255.255.255.0 die Subnetzmaske, 10.177.192.1 das echte Gateway und 1 die Metrik der Route.Nach dem Befehl prüfst du die Routing-Tabelle noch einmal:```powershellroute print```Die Default Route sollte jetzt auf das echte Gateway zeigen:```powershell0.0.0.0 0.0.0.0 10.177.192.1```Warum das besser funktioniert, als dieselben Werte in den Windows-Netzwerkeinstellungen zu ändern: Die grafische Oberfläche kann korrekte Werte anzeigen, während in der Routing-Tabelle immer noch eine alte oder kaputte Route steht. Software, virtuelle Adapter, VPN Clients, Netzwerktreiber oder Management-Werkzeuge können die Routing-Tabelle beeinflussen. Die Kommandozeile setzt die Adapter-Konfiguration direkter neu und zwingt Windows, die Route sauber neu anzulegen.Die Lehre ist einfach: Wenn ein Windows Server das lokale Netz erreicht, aber nicht das Internet, prüf nicht nur die Felder für IP, DNS und Gateway. Sieh dir immer route print an. Wenn die Default Route auf den Server selbst zeigt, schickt Windows den Verkehr in die falsche Richtung. </body> </section> <section> <heading>

Wie weiter

</heading>
<body>Wenn du bis hierher gelesen hast, läuft es bei dir vermutlich immer noch nicht. [Melde dich bei uns](https://soultec.ch/contact-us/), wir helfen gerne.</body> </section> </sections> </spec> <status> <corpus>315</corpus> <alsoLike> <item> <ref>posts/how-to-fix-fix-static-windows-network-settings-reset-after-reboot</ref> <score>0.54</score> </item> <item> <ref>posts/vmware-software-defined-wan</ref> <score>0.53</score> </item> <item> <ref>solutions/vmware</ref> <score>0.53</score> </item> </alsoLike> <search>/de/search.json</search> </status></manifest>
# Code generated by the soultec.ch build. DO NOT EDIT.import jsonPAGE = { "apiVersion": "soultec.ch/v1", "kind": "Post", "metadata": { "name": "how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself", "locale": "de", "labels": { "author": "valentina-cicmak", "series": "how-to", "capability/automation": 1.81, "capability/network": 2.16, }, "annotations": { "source": "blog-content/posts/de/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md", "route": "/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/", "schema": "/nerd/schema/posts.json", "markdown": "/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md", }, }, "spec": { "title": "Windows Server ohne Internet, weil die Default Route auf ihn selbst zeigt", "date": "2026-06-09", "author": "valentina-cicmak", "locale": "de", "summary": "Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Meistens ist es nicht DNS, sondern das Routing.", "capabilities": ["automation", "network"], "series": "how-to", "hero": "/blog-assets/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/hero.webp", "migrated": "2026-08-24", "translationReviewed": False, "draft": False, "sections": [ { "body": ( "Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Die IP-Adresse steht, die Subnetzmaske stimmt, DNS Server sind konfiguriert, und das Default Gateway zeigt scheinbar auf den Router. Lokale Geräte im selben Netz antworten auf Ping, aber ins Internet kommt der Server nicht.\n" "\n" "In dieser Situation liegt es oft nicht an DNS, sondern am Routing.\n" "\n" "### Lösung\n" "\n" "Windows braucht eine Default Route für allen Verkehr ausserhalb des lokalen Subnetzes. Um das zu prüfen, öffnest du die Eingabeaufforderung oder PowerShell und führst aus:\n" "\n" "```powershell\n" "route print\n" "```\n" "\n" "Sieh dir in der Ausgabe die IPv4 Route Table an und darin den Abschnitt Active Routes. Die Default Route ist die Zeile, in der Network Destination und Netmask beide 0.0.0.0 sind.\n" "\n" "Eine korrekte Default Route sieht üblicherweise so aus:\n" "\n" "```powershell\n" "0.0.0.0 0.0.0.0 10.177.192.1\n" "```\n" "\n" "Dabei ist 10.177.192.1 der Router oder die Firewall. Dorthin muss der Internetverkehr.\n" "\n" "Das Problem taucht auf, wenn in der Routing-Tabelle eine Route wie diese steht:\n" "\n" "```powershell\n" "0.0.0.0 0.0.0.0 On-link 10.177.192.5\n" "```\n" "\n" "oder wenn der Server seine eigene IP-Adresse als Gateway verwendet:\n" "\n" "```powershell\n" "0.0.0.0 0.0.0.0 10.177.192.5\n" "```\n" "\n" "In diesem Beispiel ist 10.177.192.5 der Server selbst. Windows schickt den Internetverkehr also an sich selbst statt an den Router. Die Kommunikation im lokalen Netz funktioniert weiterhin, weil lokale Geräte direkt erreichbar sind. Der Internetzugang scheitert, weil der Verkehr nie beim echten Gateway ankommt.\n" "\n" "Danach testest du die Verbindung Schritt für Schritt:\n" "\n" "```powershell\n" "ping 10.177.192.1\n" "ping 8.8.8.8\n" "nslookup google.com\n" "```\n" "\n" "Wenn das Gateway antwortet, 8.8.8.8 aber nicht, liegt es sehr wahrscheinlich am Routing. Wenn 8.8.8.8 funktioniert, google.com aber nicht, liegt es sehr wahrscheinlich an DNS.\n" "\n" "Um die kaputte Default Route zu entfernen, nimm diese Vorlage:\n" "\n" "```powershell\n" "route delete 0.0.0.0 mask 0.0.0.0\n" "```\n" "\n" "Zum Beispiel:\n" "\n" "```powershell\n" "route delete 0.0.0.0 mask 0.0.0.0 10.177.192.5\n" "```\n" "\n" "Damit ist die falsche Route weg, mit der der Server den Internetverkehr an sich selbst geschickt hat.\n" "\n" "Danach setzt du die Adapter-Konfiguration sauber neu. Der folgende Befehl ist nur eine Vorlage. Ersetz Adaptername, IP-Adresse, Subnetzmaske, Gateway und Metrik durch die Werte deines eigenen Netzes:\n" "\n" "```powershell\n" "netsh interface ipv4 set address name=\"\" static\n" "```\n" "\n" "Zum Beispiel:\n" "\n" "```powershell\n" "netsh interface ipv4 set address name=\"Ethernet0\" static 10.177.192.5 255.255.255.0 10.177.192.1 1\n" "```\n" "\n" "Hier ist Ethernet0 der Netzwerkadapter, 10.177.192.5 die Server-IP, 255.255.255.0 die Subnetzmaske, 10.177.192.1 das echte Gateway und 1 die Metrik der Route.\n" "\n" "Nach dem Befehl prüfst du die Routing-Tabelle noch einmal:\n" "\n" "```powershell\n" "route print\n" "```\n" "\n" "Die Default Route sollte jetzt auf das echte Gateway zeigen:\n" "\n" "```powershell\n" "0.0.0.0 0.0.0.0 10.177.192.1\n" "```\n" "\n" "Warum das besser funktioniert, als dieselben Werte in den Windows-Netzwerkeinstellungen zu ändern: Die grafische Oberfläche kann korrekte Werte anzeigen, während in der Routing-Tabelle immer noch eine alte oder kaputte Route steht. Software, virtuelle Adapter, VPN Clients, Netzwerktreiber oder Management-Werkzeuge können die Routing-Tabelle beeinflussen. Die Kommandozeile setzt die Adapter-Konfiguration direkter neu und zwingt Windows, die Route sauber neu anzulegen.\n" "\n" "Die Lehre ist einfach: Wenn ein Windows Server das lokale Netz erreicht, aber nicht das Internet, prüf nicht nur die Felder für IP, DNS und Gateway. Sieh dir immer route print an. Wenn die Default Route auf den Server selbst zeigt, schickt Windows den Verkehr in die falsche Richtung." ), }, { "heading": "

Wie weiter

",
"body": "Wenn du bis hierher gelesen hast, läuft es bei dir vermutlich immer noch nicht. [Melde dich bei uns](https://soultec.ch/contact-us/), wir helfen gerne.", }, ], }, "status": { "corpus": 315, "alsoLike": [ { "ref": "posts/how-to-fix-fix-static-windows-network-settings-reset-after-reboot", "score": "0.54", }, { "ref": "posts/vmware-software-defined-wan", "score": "0.53", }, { "ref": "solutions/vmware", "score": "0.53", }, ], "search": "/de/search.json", },}if __name__ == "__main__": print(json.dumps(PAGE, indent=2, ensure_ascii=False))
# Code generated by the soultec.ch build. DO NOT EDIT.$Page = [ordered]@{ apiVersion = 'soultec.ch/v1' kind = 'Post' metadata = [ordered]@{ name = 'how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself' locale = 'de' labels = [ordered]@{ author = 'valentina-cicmak' series = 'how-to' 'capability/automation' = 1.81 'capability/network' = 2.16 } annotations = [ordered]@{ source = 'blog-content/posts/de/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md' route = '/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/' schema = '/nerd/schema/posts.json' markdown = '/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md' } } spec = [ordered]@{ title = 'Windows Server ohne Internet, weil die Default Route auf ihn selbst zeigt' date = '2026-06-09' author = 'valentina-cicmak' locale = 'de' summary = 'Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Meistens ist es nicht DNS, sondern das Routing.' capabilities = @('automation', 'network') series = 'how-to' hero = '/blog-assets/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/hero.webp' migrated = '2026-08-24' translationReviewed = $false draft = $false sections = @( [ordered]@{ body = @'Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Die IP-Adresse steht, die Subnetzmaske stimmt, DNS Server sind konfiguriert, und das Default Gateway zeigt scheinbar auf den Router. Lokale Geräte im selben Netz antworten auf Ping, aber ins Internet kommt der Server nicht.In dieser Situation liegt es oft nicht an DNS, sondern am Routing.### LösungWindows braucht eine Default Route für allen Verkehr ausserhalb des lokalen Subnetzes. Um das zu prüfen, öffnest du die Eingabeaufforderung oder PowerShell und führst aus:```powershellroute print```Sieh dir in der Ausgabe die IPv4 Route Table an und darin den Abschnitt Active Routes. Die Default Route ist die Zeile, in der Network Destination und Netmask beide 0.0.0.0 sind.Eine korrekte Default Route sieht üblicherweise so aus:```powershell0.0.0.0 0.0.0.0 10.177.192.1```Dabei ist 10.177.192.1 der Router oder die Firewall. Dorthin muss der Internetverkehr.Das Problem taucht auf, wenn in der Routing-Tabelle eine Route wie diese steht:```powershell0.0.0.0 0.0.0.0 On-link 10.177.192.5```oder wenn der Server seine eigene IP-Adresse als Gateway verwendet:```powershell0.0.0.0 0.0.0.0 10.177.192.5```In diesem Beispiel ist 10.177.192.5 der Server selbst. Windows schickt den Internetverkehr also an sich selbst statt an den Router. Die Kommunikation im lokalen Netz funktioniert weiterhin, weil lokale Geräte direkt erreichbar sind. Der Internetzugang scheitert, weil der Verkehr nie beim echten Gateway ankommt.Danach testest du die Verbindung Schritt für Schritt:```powershellping 10.177.192.1ping 8.8.8.8nslookup google.com```Wenn das Gateway antwortet, 8.8.8.8 aber nicht, liegt es sehr wahrscheinlich am Routing. Wenn 8.8.8.8 funktioniert, google.com aber nicht, liegt es sehr wahrscheinlich an DNS.Um die kaputte Default Route zu entfernen, nimm diese Vorlage:```powershellroute delete 0.0.0.0 mask 0.0.0.0```Zum Beispiel:```powershellroute delete 0.0.0.0 mask 0.0.0.0 10.177.192.5```Damit ist die falsche Route weg, mit der der Server den Internetverkehr an sich selbst geschickt hat.Danach setzt du die Adapter-Konfiguration sauber neu. Der folgende Befehl ist nur eine Vorlage. Ersetz Adaptername, IP-Adresse, Subnetzmaske, Gateway und Metrik durch die Werte deines eigenen Netzes:```powershellnetsh interface ipv4 set address name="" static```Zum Beispiel:```powershellnetsh interface ipv4 set address name="Ethernet0" static 10.177.192.5 255.255.255.0 10.177.192.1 1```Hier ist Ethernet0 der Netzwerkadapter, 10.177.192.5 die Server-IP, 255.255.255.0 die Subnetzmaske, 10.177.192.1 das echte Gateway und 1 die Metrik der Route.Nach dem Befehl prüfst du die Routing-Tabelle noch einmal:```powershellroute print```Die Default Route sollte jetzt auf das echte Gateway zeigen:```powershell0.0.0.0 0.0.0.0 10.177.192.1```Warum das besser funktioniert, als dieselben Werte in den Windows-Netzwerkeinstellungen zu ändern: Die grafische Oberfläche kann korrekte Werte anzeigen, während in der Routing-Tabelle immer noch eine alte oder kaputte Route steht. Software, virtuelle Adapter, VPN Clients, Netzwerktreiber oder Management-Werkzeuge können die Routing-Tabelle beeinflussen. Die Kommandozeile setzt die Adapter-Konfiguration direkter neu und zwingt Windows, die Route sauber neu anzulegen.Die Lehre ist einfach: Wenn ein Windows Server das lokale Netz erreicht, aber nicht das Internet, prüf nicht nur die Felder für IP, DNS und Gateway. Sieh dir immer route print an. Wenn die Default Route auf den Server selbst zeigt, schickt Windows den Verkehr in die falsche Richtung.'@ } [ordered]@{ heading = '

Wie weiter

'
body = 'Wenn du bis hierher gelesen hast, läuft es bei dir vermutlich immer noch nicht. [Melde dich bei uns](https://soultec.ch/contact-us/), wir helfen gerne.' } ) } status = [ordered]@{ corpus = 315 alsoLike = @( [ordered]@{ ref = 'posts/how-to-fix-fix-static-windows-network-settings-reset-after-reboot' score = '0.54' } [ordered]@{ ref = 'posts/vmware-software-defined-wan' score = '0.53' } [ordered]@{ ref = 'solutions/vmware' score = '0.53' } ) search = '/de/search.json' }}$Page | ConvertTo-Json -Depth 32
// Code generated by the soultec.ch build. DO NOT EDIT.package mainimport ( "encoding/json" "os")var page = map[string]any{ "apiVersion": "soultec.ch/v1", "kind": "Post", "metadata": map[string]any{ "name": "how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself", "locale": "de", "labels": map[string]any{ "author": "valentina-cicmak", "series": "how-to", "capability/automation": 1.81, "capability/network": 2.16, }, "annotations": map[string]any{ "source": "blog-content/posts/de/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md", "route": "/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/", "schema": "/nerd/schema/posts.json", "markdown": "/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md", }, }, "spec": map[string]any{ "title": "Windows Server ohne Internet, weil die Default Route auf ihn selbst zeigt", "date": "2026-06-09", "author": "valentina-cicmak", "locale": "de", "summary": "Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Meistens ist es nicht DNS, sondern das Routing.", "capabilities": []any{"automation", "network"}, "series": "how-to", "hero": "/blog-assets/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/hero.webp", "migrated": "2026-08-24", "translationReviewed": false, "draft": false, "sections": []any{ map[string]any{ "body": "Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Die IP-Adresse steht, die Subnetzmaske stimmt, DNS Server sind konfiguriert, und das Default Gateway zeigt scheinbar auf den Router. Lokale Geräte im selben Netz antworten auf Ping, aber ins Internet kommt der Server nicht.\n" + "\n" + "In dieser Situation liegt es oft nicht an DNS, sondern am Routing.\n" + "\n" + "### Lösung\n" + "\n" + "Windows braucht eine Default Route für allen Verkehr ausserhalb des lokalen Subnetzes. Um das zu prüfen, öffnest du die Eingabeaufforderung oder PowerShell und führst aus:\n" + "\n" + "```powershell\n" + "route print\n" + "```\n" + "\n" + "Sieh dir in der Ausgabe die IPv4 Route Table an und darin den Abschnitt Active Routes. Die Default Route ist die Zeile, in der Network Destination und Netmask beide 0.0.0.0 sind.\n" + "\n" + "Eine korrekte Default Route sieht üblicherweise so aus:\n" + "\n" + "```powershell\n" + "0.0.0.0 0.0.0.0 10.177.192.1\n" + "```\n" + "\n" + "Dabei ist 10.177.192.1 der Router oder die Firewall. Dorthin muss der Internetverkehr.\n" + "\n" + "Das Problem taucht auf, wenn in der Routing-Tabelle eine Route wie diese steht:\n" + "\n" + "```powershell\n" + "0.0.0.0 0.0.0.0 On-link 10.177.192.5\n" + "```\n" + "\n" + "oder wenn der Server seine eigene IP-Adresse als Gateway verwendet:\n" + "\n" + "```powershell\n" + "0.0.0.0 0.0.0.0 10.177.192.5\n" + "```\n" + "\n" + "In diesem Beispiel ist 10.177.192.5 der Server selbst. Windows schickt den Internetverkehr also an sich selbst statt an den Router. Die Kommunikation im lokalen Netz funktioniert weiterhin, weil lokale Geräte direkt erreichbar sind. Der Internetzugang scheitert, weil der Verkehr nie beim echten Gateway ankommt.\n" + "\n" + "Danach testest du die Verbindung Schritt für Schritt:\n" + "\n" + "```powershell\n" + "ping 10.177.192.1\n" + "ping 8.8.8.8\n" + "nslookup google.com\n" + "```\n" + "\n" + "Wenn das Gateway antwortet, 8.8.8.8 aber nicht, liegt es sehr wahrscheinlich am Routing. Wenn 8.8.8.8 funktioniert, google.com aber nicht, liegt es sehr wahrscheinlich an DNS.\n" + "\n" + "Um die kaputte Default Route zu entfernen, nimm diese Vorlage:\n" + "\n" + "```powershell\n" + "route delete 0.0.0.0 mask 0.0.0.0\n" + "```\n" + "\n" + "Zum Beispiel:\n" + "\n" + "```powershell\n" + "route delete 0.0.0.0 mask 0.0.0.0 10.177.192.5\n" + "```\n" + "\n" + "Damit ist die falsche Route weg, mit der der Server den Internetverkehr an sich selbst geschickt hat.\n" + "\n" + "Danach setzt du die Adapter-Konfiguration sauber neu. Der folgende Befehl ist nur eine Vorlage. Ersetz Adaptername, IP-Adresse, Subnetzmaske, Gateway und Metrik durch die Werte deines eigenen Netzes:\n" + "\n" + "```powershell\n" + "netsh interface ipv4 set address name=\"\" static\n" + "```\n" + "\n" + "Zum Beispiel:\n" + "\n" + "```powershell\n" + "netsh interface ipv4 set address name=\"Ethernet0\" static 10.177.192.5 255.255.255.0 10.177.192.1 1\n" + "```\n" + "\n" + "Hier ist Ethernet0 der Netzwerkadapter, 10.177.192.5 die Server-IP, 255.255.255.0 die Subnetzmaske, 10.177.192.1 das echte Gateway und 1 die Metrik der Route.\n" + "\n" + "Nach dem Befehl prüfst du die Routing-Tabelle noch einmal:\n" + "\n" + "```powershell\n" + "route print\n" + "```\n" + "\n" + "Die Default Route sollte jetzt auf das echte Gateway zeigen:\n" + "\n" + "```powershell\n" + "0.0.0.0 0.0.0.0 10.177.192.1\n" + "```\n" + "\n" + "Warum das besser funktioniert, als dieselben Werte in den Windows-Netzwerkeinstellungen zu ändern: Die grafische Oberfläche kann korrekte Werte anzeigen, während in der Routing-Tabelle immer noch eine alte oder kaputte Route steht. Software, virtuelle Adapter, VPN Clients, Netzwerktreiber oder Management-Werkzeuge können die Routing-Tabelle beeinflussen. Die Kommandozeile setzt die Adapter-Konfiguration direkter neu und zwingt Windows, die Route sauber neu anzulegen.\n" + "\n" + "Die Lehre ist einfach: Wenn ein Windows Server das lokale Netz erreicht, aber nicht das Internet, prüf nicht nur die Felder für IP, DNS und Gateway. Sieh dir immer route print an. Wenn die Default Route auf den Server selbst zeigt, schickt Windows den Verkehr in die falsche Richtung.", }, map[string]any{ "heading": "

Wie weiter

",
"body": "Wenn du bis hierher gelesen hast, läuft es bei dir vermutlich immer noch nicht. [Melde dich bei uns](https://soultec.ch/contact-us/), wir helfen gerne.", }, }, }, "status": map[string]any{ "corpus": 315, "alsoLike": []any{ map[string]any{ "ref": "posts/how-to-fix-fix-static-windows-network-settings-reset-after-reboot", "score": "0.54", }, map[string]any{ "ref": "posts/vmware-software-defined-wan", "score": "0.53", }, map[string]any{ "ref": "solutions/vmware", "score": "0.53", }, }, "search": "/de/search.json", },}func main() { enc := json.NewEncoder(os.Stdout) enc.SetEscapeHTML(false) enc.SetIndent("", " ") if err := enc.Encode(page); err != nil { os.Exit(1) }}
// Code generated by the soultec.ch build. DO NOT EDIT.const page = { apiVersion: "soultec.ch/v1", kind: "Post", metadata: { name: "how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself", locale: "de", labels: { author: "valentina-cicmak", series: "how-to", "capability/automation": 1.81, "capability/network": 2.16, }, annotations: { source: "blog-content/posts/de/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md", route: "/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/", schema: "/nerd/schema/posts.json", markdown: "/de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md", }, }, spec: { title: "Windows Server ohne Internet, weil die Default Route auf ihn selbst zeigt", date: "2026-06-09", author: "valentina-cicmak", locale: "de", summary: "Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Meistens ist es nicht DNS, sondern das Routing.", capabilities: ["automation", "network"], series: "how-to", hero: "/blog-assets/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself/hero.webp", migrated: "2026-08-24", translationReviewed: false, draft: false, sections: [ { body: "Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Die IP-Adresse steht, die Subnetzmaske stimmt, DNS Server sind konfiguriert, und das Default Gateway zeigt scheinbar auf den Router. Lokale Geräte im selben Netz antworten auf Ping, aber ins Internet kommt der Server nicht.\n" + "\n" + "In dieser Situation liegt es oft nicht an DNS, sondern am Routing.\n" + "\n" + "### Lösung\n" + "\n" + "Windows braucht eine Default Route für allen Verkehr ausserhalb des lokalen Subnetzes. Um das zu prüfen, öffnest du die Eingabeaufforderung oder PowerShell und führst aus:\n" + "\n" + "```powershell\n" + "route print\n" + "```\n" + "\n" + "Sieh dir in der Ausgabe die IPv4 Route Table an und darin den Abschnitt Active Routes. Die Default Route ist die Zeile, in der Network Destination und Netmask beide 0.0.0.0 sind.\n" + "\n" + "Eine korrekte Default Route sieht üblicherweise so aus:\n" + "\n" + "```powershell\n" + "0.0.0.0 0.0.0.0 10.177.192.1\n" + "```\n" + "\n" + "Dabei ist 10.177.192.1 der Router oder die Firewall. Dorthin muss der Internetverkehr.\n" + "\n" + "Das Problem taucht auf, wenn in der Routing-Tabelle eine Route wie diese steht:\n" + "\n" + "```powershell\n" + "0.0.0.0 0.0.0.0 On-link 10.177.192.5\n" + "```\n" + "\n" + "oder wenn der Server seine eigene IP-Adresse als Gateway verwendet:\n" + "\n" + "```powershell\n" + "0.0.0.0 0.0.0.0 10.177.192.5\n" + "```\n" + "\n" + "In diesem Beispiel ist 10.177.192.5 der Server selbst. Windows schickt den Internetverkehr also an sich selbst statt an den Router. Die Kommunikation im lokalen Netz funktioniert weiterhin, weil lokale Geräte direkt erreichbar sind. Der Internetzugang scheitert, weil der Verkehr nie beim echten Gateway ankommt.\n" + "\n" + "Danach testest du die Verbindung Schritt für Schritt:\n" + "\n" + "```powershell\n" + "ping 10.177.192.1\n" + "ping 8.8.8.8\n" + "nslookup google.com\n" + "```\n" + "\n" + "Wenn das Gateway antwortet, 8.8.8.8 aber nicht, liegt es sehr wahrscheinlich am Routing. Wenn 8.8.8.8 funktioniert, google.com aber nicht, liegt es sehr wahrscheinlich an DNS.\n" + "\n" + "Um die kaputte Default Route zu entfernen, nimm diese Vorlage:\n" + "\n" + "```powershell\n" + "route delete 0.0.0.0 mask 0.0.0.0\n" + "```\n" + "\n" + "Zum Beispiel:\n" + "\n" + "```powershell\n" + "route delete 0.0.0.0 mask 0.0.0.0 10.177.192.5\n" + "```\n" + "\n" + "Damit ist die falsche Route weg, mit der der Server den Internetverkehr an sich selbst geschickt hat.\n" + "\n" + "Danach setzt du die Adapter-Konfiguration sauber neu. Der folgende Befehl ist nur eine Vorlage. Ersetz Adaptername, IP-Adresse, Subnetzmaske, Gateway und Metrik durch die Werte deines eigenen Netzes:\n" + "\n" + "```powershell\n" + "netsh interface ipv4 set address name=\"\" static\n" + "```\n" + "\n" + "Zum Beispiel:\n" + "\n" + "```powershell\n" + "netsh interface ipv4 set address name=\"Ethernet0\" static 10.177.192.5 255.255.255.0 10.177.192.1 1\n" + "```\n" + "\n" + "Hier ist Ethernet0 der Netzwerkadapter, 10.177.192.5 die Server-IP, 255.255.255.0 die Subnetzmaske, 10.177.192.1 das echte Gateway und 1 die Metrik der Route.\n" + "\n" + "Nach dem Befehl prüfst du die Routing-Tabelle noch einmal:\n" + "\n" + "```powershell\n" + "route print\n" + "```\n" + "\n" + "Die Default Route sollte jetzt auf das echte Gateway zeigen:\n" + "\n" + "```powershell\n" + "0.0.0.0 0.0.0.0 10.177.192.1\n" + "```\n" + "\n" + "Warum das besser funktioniert, als dieselben Werte in den Windows-Netzwerkeinstellungen zu ändern: Die grafische Oberfläche kann korrekte Werte anzeigen, während in der Routing-Tabelle immer noch eine alte oder kaputte Route steht. Software, virtuelle Adapter, VPN Clients, Netzwerktreiber oder Management-Werkzeuge können die Routing-Tabelle beeinflussen. Die Kommandozeile setzt die Adapter-Konfiguration direkter neu und zwingt Windows, die Route sauber neu anzulegen.\n" + "\n" + "Die Lehre ist einfach: Wenn ein Windows Server das lokale Netz erreicht, aber nicht das Internet, prüf nicht nur die Felder für IP, DNS und Gateway. Sieh dir immer route print an. Wenn die Default Route auf den Server selbst zeigt, schickt Windows den Verkehr in die falsche Richtung.", }, { heading: "

Wie weiter

",
body: "Wenn du bis hierher gelesen hast, läuft es bei dir vermutlich immer noch nicht. [Melde dich bei uns](https://soultec.ch/contact-us/), wir helfen gerne.", }, ], }, status: { corpus: 315, alsoLike: [ { ref: "posts/how-to-fix-fix-static-windows-network-settings-reset-after-reboot", score: "0.54", }, { ref: "posts/vmware-software-defined-wan", score: "0.53", }, { ref: "solutions/vmware", score: "0.53", }, ], search: "/de/search.json", },};console.log(JSON.stringify(page, null, 2));

# 132 lines · YAML · validated at build# 63 lines · JSON · validated at build# 144 lines · TOML · validated at build# 153 lines · XML · validated at build# 156 lines · Python · read back at build, equals the JSON record# 153 lines · PowerShell · read back at build, equals the JSON record# 166 lines · Go · read back at build, equals the JSON record# 151 lines · JavaScript · read back at build, equals the JSON record · served at /de/insights/how-to-fix-windows-server-internet-access-when-the-default-route-points-to-tself.md

How-To · 2026-06-09

Windows Server ohne Internet, weil die Default Route auf ihn selbst zeigt

Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Meistens ist es nicht DNS, sondern das Routing.

2026-06-09Datum
Valentina CicmakAutor
3Min. Lesezeit

Ein Windows Server kann den Internetzugang verlieren, obwohl die Netzwerkeinstellungen korrekt aussehen. Die IP-Adresse steht, die Subnetzmaske stimmt, DNS Server sind konfiguriert, und das Default Gateway zeigt scheinbar auf den Router. Lokale Geräte im selben Netz antworten auf Ping, aber ins Internet kommt der Server nicht.

In dieser Situation liegt es oft nicht an DNS, sondern am Routing.

Lösung

Windows braucht eine Default Route für allen Verkehr ausserhalb des lokalen Subnetzes. Um das zu prüfen, öffnest du die Eingabeaufforderung oder PowerShell und führst aus:

route print

Sieh dir in der Ausgabe die IPv4 Route Table an und darin den Abschnitt Active Routes. Die Default Route ist die Zeile, in der Network Destination und Netmask beide 0.0.0.0 sind.

Eine korrekte Default Route sieht üblicherweise so aus:

0.0.0.0 0.0.0.0 10.177.192.1

Dabei ist 10.177.192.1 der Router oder die Firewall. Dorthin muss der Internetverkehr.

Das Problem taucht auf, wenn in der Routing-Tabelle eine Route wie diese steht:

0.0.0.0 0.0.0.0 On-link 10.177.192.5

oder wenn der Server seine eigene IP-Adresse als Gateway verwendet:

0.0.0.0 0.0.0.0 10.177.192.5

In diesem Beispiel ist 10.177.192.5 der Server selbst. Windows schickt den Internetverkehr also an sich selbst statt an den Router. Die Kommunikation im lokalen Netz funktioniert weiterhin, weil lokale Geräte direkt erreichbar sind. Der Internetzugang scheitert, weil der Verkehr nie beim echten Gateway ankommt.

Danach testest du die Verbindung Schritt für Schritt:

ping 10.177.192.1
ping 8.8.8.8
nslookup google.com

Wenn das Gateway antwortet, 8.8.8.8 aber nicht, liegt es sehr wahrscheinlich am Routing. Wenn 8.8.8.8 funktioniert, google.com aber nicht, liegt es sehr wahrscheinlich an DNS.

Um die kaputte Default Route zu entfernen, nimm diese Vorlage:

route delete 0.0.0.0 mask 0.0.0.0

Zum Beispiel:

route delete 0.0.0.0 mask 0.0.0.0 10.177.192.5

Damit ist die falsche Route weg, mit der der Server den Internetverkehr an sich selbst geschickt hat.

Danach setzt du die Adapter-Konfiguration sauber neu. Der folgende Befehl ist nur eine Vorlage. Ersetz Adaptername, IP-Adresse, Subnetzmaske, Gateway und Metrik durch die Werte deines eigenen Netzes:

netsh interface ipv4 set address name="" static

Zum Beispiel:

netsh interface ipv4 set address name="Ethernet0" static 10.177.192.5 255.255.255.0 10.177.192.1 1

Hier ist Ethernet0 der Netzwerkadapter, 10.177.192.5 die Server-IP, 255.255.255.0 die Subnetzmaske, 10.177.192.1 das echte Gateway und 1 die Metrik der Route.

Nach dem Befehl prüfst du die Routing-Tabelle noch einmal:

route print

Die Default Route sollte jetzt auf das echte Gateway zeigen:

0.0.0.0 0.0.0.0 10.177.192.1

Warum das besser funktioniert, als dieselben Werte in den Windows-Netzwerkeinstellungen zu ändern: Die grafische Oberfläche kann korrekte Werte anzeigen, während in der Routing-Tabelle immer noch eine alte oder kaputte Route steht. Software, virtuelle Adapter, VPN Clients, Netzwerktreiber oder Management-Werkzeuge können die Routing-Tabelle beeinflussen. Die Kommandozeile setzt die Adapter-Konfiguration direkter neu und zwingt Windows, die Route sauber neu anzulegen.

Die Lehre ist einfach: Wenn ein Windows Server das lokale Netz erreicht, aber nicht das Internet, prüf nicht nur die Felder für IP, DNS und Gateway. Sieh dir immer route print an. Wenn die Default Route auf den Server selbst zeigt, schickt Windows den Verkehr in die falsche Richtung.

Wie weiter

Wenn du bis hierher gelesen hast, läuft es bei dir vermutlich immer noch nicht. Melde dich bei uns, wir helfen gerne.

Passt ausserdem