Windows 10 PC has no internet connection.

11010001

Member
Joined
Oct 17, 2025
Messages
27
I am on Windows 10 currently but am trying to upgrade to win11. Unfortunately, my pc is saying it is connected but that there is no internet access, on both wifi and ethernet. All other devices work fine, just this pc is giving me trouble.

I can still access the router settings page.

I have restarted the computer.

I have reset the router.

I have run the troubleshooter. It found nothing.

I have reset the network adapter and dns.

I have reinstalled the network adapter.

I am out of ideas.

Any help would be appreciated.
 

Thanks — good troubleshooting so far. Because you can open the router admin page from that PC, the NIC and local link are working, which narrows this to DNS/gateway/route, a Windows networking stack/service issue, or a firewall/proxy/VPN interfering on that Windows install. Below are targeted diagnostic steps (run in an elevated Command Prompt — right‑click Start, “Command Prompt (Admin)” or “Windows Terminal (Admin)”) and what to paste back so I can pinpoint the cause. Many of these are standard checks and resets recommended for this exact symptom.
Quick checks (do these first)
  1. Can Windows reach the router?
    • Command: ping <router IP> (usually ping 192.168.1.1)
    • Expected: replies. If this fails, check cable/adapter LEDs and try another cable/port. If it succeeds, the physical link to the router is fine.
  2. Can Windows reach the internet by IP (bypasses DNS)?
    • Command: ping 8.8.8.8
    • Expected: replies. If ping to 8.8.8.8 works but ping to google.com fails, it’s a DNS issue.
  3. DNS test
    • Command: nslookup google.com
    • Expected: it should show a DNS server and an IP for google.com. If nslookup times out or reports no servers, Windows isn’t using a valid DNS server.
Collect these outputs and paste them here if anything fails.
Collect diagnostic outputs (paste these)
  • ipconfig /all
  • route print
  • netsh interface ipv4 show config
  • netsh interface ipv6 show config
  • netsh interface ipv4 show dns
  • netsh interface show interface
  • sc query dhcp
  • sc query dnscache
    These show IPs, gateway, DNS servers, routing and whether DHCP/DNS services are running — the most helpful facts to diagnose this.
Quick targeted fixes (safe, do in this order)
  1. Reset Winsock, TCP/IP and flush DNS (if you haven’t already):
    • netsh winsock reset
    • netsh int ip reset
    • ipconfig /flushdns
    • ipconfig /release
    • ipconfig /renew
    • Reboot afterwards. These commands repair the network stack and often fix the “connected but no internet” state.
  2. Check for a proxy or WinHTTP proxy:
    • GUI: Settings > Network & Internet > Proxy → ensure “Use a proxy server” is Off.
    • Command: netsh winhttp show proxy
    • If a proxy is set but you don’t use one, clear it: netsh winhttp reset proxy. Proxy settings commonly break outbound internet even though local LAN works.
  3. Check Windows services
    • Commands: sc query dhcp and sc query dnscache
    • Both DHCP Client and DNS Client should be RUNNING. If stopped, start them (net start dhcp / net start dnscache) and test again.
  4. Disable firewall/AV temporarily
    • Temporarily disable Windows Defender Firewall and any third‑party security/AV and test. Some security suites or misconfigured firewall rules can block outbound traffic while allowing local LAN access.
  5. Safe Mode with Networking / Clean Boot
    • Boot to Safe Mode with Networking. If internet works there, a startup app/driver (VPN, virtual adapter, security software) is the culprit. Then perform a clean boot (msconfig) to isolate the offender.
Advanced checks if the above don’t fix it
  • Check hosts file: C:\Windows\System32\drivers\etc\hosts — ensure no entries blocking sites.
  • Remove virtual adapters (Hyper‑V, VPN clients, Hamachi, etc.) from Control Panel > Network Connections — virtual adapters can hijack routes/DNS.
  • Run SFC and DISM (repairs system files):
    • sfc /scannow
    • If SFC finds unfixable errors, run: DISM /Online /Cleanup-Image /RestoreHealth
      These can fix corrupted system networking components.
If nothing fixes it
  • Network Reset (Settings > Network & Internet > Network reset) — this reinstalls adapters and resets networking; you’ll lose saved Wi‑Fi passwords.
  • In‑place Repair (Windows repair install / “Reset this PC — Keep my files”) — repairs Windows without losing personal files and usually fixes stubborn network stack corruption. Use this only after collecting the diagnostic outputs above.
What I need from you now
  1. Run the quick checks and the diagnostic commands listed above and paste the outputs for:
    • ipconfig /all
    • route print
    • ping 192.168.1.1
    • ping 8.8.8.8
    • nslookup google.com
    • netsh winsock reset (and then reboot if you run it)
  2. Tell me whether you have any VPNs, corporate/proxy settings, or third‑party firewall/AV installed.
With those outputs I can tell you exactly whether it’s DNS, missing/default route, a proxy, a service that’s stopped, or corrupted network stack — and give the next precise step.
 

Thanks — good troubleshooting so far. Because you can open the router admin page from that PC, the NIC and local link are working, which narrows this to DNS/gateway/route, a Windows networking stack/service issue, or a firewall/proxy/VPN interfering on that Windows install. Below are targeted diagnostic steps (run in an elevated Command Prompt — right‑click Start, “Command Prompt (Admin)” or “Windows Terminal (Admin)”) and what to paste back so I can pinpoint the cause. Many of these are standard checks and resets recommended for this exact symptom.
Quick checks (do these first)
  1. Can Windows reach the router?
    • Command: ping <router IP> (usually ping 192.168.1.1)
    • Expected: replies. If this fails, check cable/adapter LEDs and try another cable/port. If it succeeds, the physical link to the router is fine.
  2. Can Windows reach the internet by IP (bypasses DNS)?
    • Command: ping 8.8.8.8
    • Expected: replies. If ping to 8.8.8.8 works but ping to google.com fails, it’s a DNS issue.
  3. DNS test
    • Command: nslookup google.com
    • Expected: it should show a DNS server and an IP for google.com. If nslookup times out or reports no servers, Windows isn’t using a valid DNS server.
Collect these outputs and paste them here if anything fails.
Collect diagnostic outputs (paste these)
  • ipconfig /all
  • route print
  • netsh interface ipv4 show config
  • netsh interface ipv6 show config
  • netsh interface ipv4 show dns
  • netsh interface show interface
  • sc query dhcp
  • sc query dnscache
    These show IPs, gateway, DNS servers, routing and whether DHCP/DNS services are running — the most helpful facts to diagnose this.
Quick targeted fixes (safe, do in this order)
  1. Reset Winsock, TCP/IP and flush DNS (if you haven’t already):
    • netsh winsock reset
    • netsh int ip reset
    • ipconfig /flushdns
    • ipconfig /release
    • ipconfig /renew
    • Reboot afterwards. These commands repair the network stack and often fix the “connected but no internet” state.
  2. Check for a proxy or WinHTTP proxy:
    • GUI: Settings > Network & Internet > Proxy → ensure “Use a proxy server” is Off.
    • Command: netsh winhttp show proxy
    • If a proxy is set but you don’t use one, clear it: netsh winhttp reset proxy. Proxy settings commonly break outbound internet even though local LAN works.
  3. Check Windows services
    • Commands: sc query dhcp and sc query dnscache
    • Both DHCP Client and DNS Client should be RUNNING. If stopped, start them (net start dhcp / net start dnscache) and test again.
  4. Disable firewall/AV temporarily
    • Temporarily disable Windows Defender Firewall and any third‑party security/AV and test. Some security suites or misconfigured firewall rules can block outbound traffic while allowing local LAN access.
  5. Safe Mode with Networking / Clean Boot
    • Boot to Safe Mode with Networking. If internet works there, a startup app/driver (VPN, virtual adapter, security software) is the culprit. Then perform a clean boot (msconfig) to isolate the offender.
Advanced checks if the above don’t fix it
  • Check hosts file: C:\Windows\System32\drivers\etc\hosts — ensure no entries blocking sites.
  • Remove virtual adapters (Hyper‑V, VPN clients, Hamachi, etc.) from Control Panel > Network Connections — virtual adapters can hijack routes/DNS.
  • Run SFC and DISM (repairs system files):
    • sfc /scannow
    • If SFC finds unfixable errors, run: DISM /Online /Cleanup-Image /RestoreHealth
      These can fix corrupted system networking components.
If nothing fixes it
  • Network Reset (Settings > Network & Internet > Network reset) — this reinstalls adapters and resets networking; you’ll lose saved Wi‑Fi passwords.
  • In‑place Repair (Windows repair install / “Reset this PC — Keep my files”) — repairs Windows without losing personal files and usually fixes stubborn network stack corruption. Use this only after collecting the diagnostic outputs above.
What I need from you now
  1. Run the quick checks and the diagnostic commands listed above and paste the outputs for:
    • ipconfig /all
    • route print
    • ping 192.168.1.1
    • ping 8.8.8.8
    • nslookup google.com
    • netsh winsock reset (and then reboot if you run it)
  2. Tell me whether you have any VPNs, corporate/proxy settings, or third‑party firewall/AV installed.
With those outputs I can tell you exactly whether it’s DNS, missing/default route, a proxy, a service that’s stopped, or corrupted network stack — and give the next precise step.
All three quick checks passed.
 

Thanks — that’s useful. Since ping to the router, ping 8.8.8.8 and nslookup all succeeded, your PC already has working IP routing and DNS — so this is likely the Network Connectivity Status Indicator (NCSI) / Windows connectivity detection, a blocked probe (proxy/firewall/hosts), or a service/config issue rather than a physical or ISP problem. That’s a common cause when Windows says “No internet” but pings and DNS succeed.
Please run these quick checks and paste back the outputs (or confirm) so I can tell you the exact fix.
1) Can you browse right now?
2) Test the NCSI probes (what Windows uses to detect “internet”):
3) Check NLA / network services and the active probing registry key
  • Run (Admin CMD):
    • sc query nlasvc
    • sc query netprofm
    • reg query "HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet" /v EnableActiveProbing
  • Expected:
    • nlasvc and netprofm should be RUNNING.
    • EnableActiveProbing should be 0x1 (decimal 1). If it’s 0, Windows won’t perform the active probe and may show No Internet.
If EnableActiveProbing = 0, re-enable it:
  • reg add "HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet" /v EnableActiveProbing /t REG_DWORD /d 1 /f
  • Reboot.
4) Quick hosts / WinHTTP / firewall checks
  • Hosts file: open C:\Windows\System32\drivers\etc\hosts and ensure no lines redirect or block msftncsi or msftconnecttest domains.
  • Show WinHTTP proxy: netsh winhttp show proxy
    • If a proxy is present you don’t expect, clear it: netsh winhttp reset proxy
  • Temporarily disable firewall (test only): netsh advfirewall set allprofiles state off
    • Test browsing/NCSI probes; then re‑enable: netsh advfirewall set allprofiles state on
  • Also temporarily disable any 3rd‑party AV/VPN and retry.
5) If you want me to verify routing/DNS from the system, paste these outputs:
  • ipconfig /all
  • route print
  • netsh interface show interface
  • the results of the curl tests above (or copy/paste the error text)
If those tests show the problem (for example NCSI probes fail or EnableActiveProbing = 0 or a proxy/firewall is blocking), I’ll give the exact command to fix it. If everything above looks normal but Windows still reports “No internet” despite browsing working, a Network Reset or re‑enabling NLA via registry + reboot normally clears the false negative.
Tell me the results of the browser + curl checks and paste the requested outputs and I’ll give the precise next step.
 

Thanks — that’s useful. Since ping to the router, ping 8.8.8.8 and nslookup all succeeded, your PC already has working IP routing and DNS — so this is likely the Network Connectivity Status Indicator (NCSI) / Windows connectivity detection, a blocked probe (proxy/firewall/hosts), or a service/config issue rather than a physical or ISP problem. That’s a common cause when Windows says “No internet” but pings and DNS succeed.
Please run these quick checks and paste back the outputs (or confirm) so I can tell you the exact fix.
1) Can you browse right now?
2) Test the NCSI probes (what Windows uses to detect “internet”):
3) Check NLA / network services and the active probing registry key
  • Run (Admin CMD):
    • sc query nlasvc
    • sc query netprofm
    • reg query "HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet" /v EnableActiveProbing
  • Expected:
    • nlasvc and netprofm should be RUNNING.
    • EnableActiveProbing should be 0x1 (decimal 1). If it’s 0, Windows won’t perform the active probe and may show No Internet.
If EnableActiveProbing = 0, re-enable it:
  • reg add "HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet" /v EnableActiveProbing /t REG_DWORD /d 1 /f
  • Reboot.
4) Quick hosts / WinHTTP / firewall checks
  • Hosts file: open C:\Windows\System32\drivers\etc\hosts and ensure no lines redirect or block msftncsi or msftconnecttest domains.
  • Show WinHTTP proxy: netsh winhttp show proxy
    • If a proxy is present you don’t expect, clear it: netsh winhttp reset proxy
  • Temporarily disable firewall (test only): netsh advfirewall set allprofiles state off
    • Test browsing/NCSI probes; then re‑enable: netsh advfirewall set allprofiles state on
  • Also temporarily disable any 3rd‑party AV/VPN and retry.
5) If you want me to verify routing/DNS from the system, paste these outputs:
  • ipconfig /all
  • route print
  • netsh interface show interface
  • the results of the curl tests above (or copy/paste the error text)
If those tests show the problem (for example NCSI probes fail or EnableActiveProbing = 0 or a proxy/firewall is blocking), I’ll give the exact command to fix it. If everything above looks normal but Windows still reports “No internet” despite browsing working, a Network Reset or re‑enabling NLA via registry + reboot normally clears the false negative.
Tell me the results of the browser + curl checks and paste the requested outputs and I’ll give the precise next step.
I cannot browse.

The curl tests fail. (Could not resolve host)

The NLA/network services pass

I do not understand the open hosts step

There is no proxy server.

Diableing firewall doesn't help

I cannot copy/paste as I cannot post from the computer in question.
 

Thanks — that’s helpful. Two quick points before the steps:
  • “Could not resolve host” from curl + inability to browse means DNS resolution is failing right now (even though earlier nslookup succeeded). That usually means Windows is trying to use a DNS resolver that isn’t answering (local resolver, virtual adapter, or a blocked/changed DNS config), or a Windows network service/agent is interfering. Community reports point to exactly this class of problem (NCSI probes failing / WinHTTP / DNS client problems), and there’s a short checklist below that fixes most cases.
  • Because you said you can’t paste from that PC, I’ll give commands that save full diagnostics to a text file you can copy off the machine (USB/thumb drive or photograph and upload from another device). Do those first and either upload the file or tell me what you see.
Step A — gather a single diagnostic file (run as Administrator)
  1. Open Command Prompt (Admin).
  2. Run this block (copy/paste the whole block into the admin prompt). It writes useful outputs to C:\Temp\netdiag.txt:
mkdir C:\Temp 2>nul
(
echo ==== ipconfig /all ====
ipconfig /all
echo.
echo ==== route print ====
route print
echo.
echo ==== netsh interface ipv4 show dns ====
netsh interface ipv4 show dns
echo.
echo ==== netsh winhttp show proxy ====
netsh winhttp show proxy
echo.
echo ==== sc query dnscache ====
sc query dnscache
echo.
echo ==== sc query WinHttpAutoProxySvc ====
sc query WinHttpAutoProxySvc
echo.
echo ==== nslookup google.com ====
nslookup google.com 8.8.8.8
echo.
echo ==== nslookup google.com (default) ====
nslookup google.com
echo.
echo ==== type hosts ====
type C:\Windows\System32\drivers\etc\hosts
echo.
echo ==== curl msftncsi ====
curl -v http://www.msftncsi.com/ncsi.txt 2>&1
echo.
echo ==== ping tests ====
ping -n 3 192.168.1.1
ping -n 3 8.8.8.8
) > C:\Temp\netdiag.txt 2>&1
After it finishes, open the file with Notepad: notepad C:\Temp\netdiag.txt — then copy it to a USB stick or photograph the contents and upload it from your other device. If you can, attach that file here; if not, tell me the three key lines near the top: “DNS Servers” reported under the active adapter in ipconfig /all, and the lines from netsh winhttp show proxy and sc query dnscache.
Why these specific checks
  • ipconfig /all shows which DNS servers your NIC is actually using. If you see 127.0.0.1 (localhost) or an unexpected address, that’s the culprit (local resolver broken or a filtering app installed).
  • netsh winhttp show proxy ensures WinHTTP proxy isn’t set. You already said there is no proxy, but the command confirms WinHTTP’s proxy state.
  • sc query dnscache and sc query WinHttpAutoProxySvc check DNS Client and WinHTTP Auto‑Proxy service state; some Windows upgrades or local agents can disable these and break name resolution — the community workaround is to set services to automatic or remove a bad dependency. I can walk through that if those services are disabled.
Step B — quick tests you can run now (one at a time)
  1. Test an external DNS directly (this bypasses your local DNS):
    • nslookup google.com 8.8.8.8
    • If that succeeds, external DNS works and the problem is the resolver your NIC is using.
  2. Test local resolver (if ipconfig showed 127.0.0.1):
    • nslookup google.com 127.0.0.1
    • If that fails, the local DNS service/agent is broken.
  3. Temporarily force a known public DNS on the active interface (tests whether DNS is the issue):
    • Find adapter name: netsh interface ipv4 show interfaces
    • Set DNS (replace "Ethernet" with the adapter name or "Wi‑Fi"):
      netsh interface ipv4 set dns name="Ethernet" source=static addr=8.8.8.8
    • Then try: ping google.com and open a browser.
    • To undo (back to DHCP): netsh interface ipv4 set dns name="Ethernet" source=dhcp
If forcing Google DNS (8.8.8.8) makes browsing work, that proves the problem is whatever DNS your PC was using (local resolver, DNS filter, VPN, or DHCP-provided server).
Step C — quick hosts/proxy/firewall checks (you already did some)
  • Hosts file: open Notepad (Admin) → File → Open → paste C:\Windows\System32\drivers\etc\hosts and set filetype to All Files. If there are any lines referencing msftncsi.com or msftconnecttest.com or redirecting common domains to 127.0.0.1, remove them. (You said you don’t understand this step — that’s normal; open it and paste the short file here or take a picture. Typical default hosts file only has comments and no real entries.)
  • WinHTTP proxy: if netsh winhttp show proxy shows anything other than “Direct access (no proxy server).” run: netsh winhttp reset proxy.
Step D — services / known Windows regression check
  • Check service start values (Admin CMD):
    sc qc dnscache
    sc qc WinHttpAutoProxySvc
  • If either service Start type is set to disabled (Start= disabled), set them temporarily to automatic/demand and start:
    sc config dnscache start= auto
    sc config WinHttpAutoProxySvc start= demand
    net start dnscache
    net start WinHttpAutoProxySvc
Community reports show WinHttpAutoProxySvc / WcmSvc + DNS client interactions can cause name resolution to stop after upgrades — if services won’t start or keep getting disabled, there’s a safe registry/workaround I can give you (it removes a dependency) but I’ll only ask you to run it after you post the diagnostic file so I can confirm it’s necessary.
If you can’t post text from that PC
  • Copy C:\Temp\netdiag.txt to a USB drive and upload it from your phone or another computer to the forum. Or take photos/screenshots of the top ~30 lines (ipconfig /all section showing the active adapter and DNS Servers) and the sc query dnscache output — those are the most important lines.
What I need next (in order of usefulness)
  1. The C:\Temp\netdiag.txt file you created (or at minimum):
    • The “DNS Servers” line under your active adapter from ipconfig /all.
    • Output of: netsh winhttp show proxy
    • Output of: sc query dnscache
    • Result of: nslookup google.com 8.8.8.8
  2. Tell me whether forcing DNS=8.8.8.8 (Step B) fixed browsing temporarily.
If you prefer, tell me what you see and I’ll give the exact next commands (including the registry/workaround to fix WinHTTP/NLA/DNS problems) — I’ll only recommend that registry change once the diagnostics confirm it’s needed.
If you want, here’s a very quick test you can run now (Admin CMD) that doesn’t change anything permanently and will tell us if DNS is the problem:
nslookup google.com 8.8.8.8
nslookup google.com
If the first succeeds and the second fails, your NIC’s configured DNS (or a local resolver) is the problem — force 8.8.8.8 as above to confirm, then send me the diagnostic file and I’ll provide the permanent fix.
I’ll wait for the C:\Temp\netdiag.txt file (or the key lines). Once I see those I’ll give the exact, low‑risk fix.
 

Thanks — that’s helpful. Two quick points before the steps:
  • “Could not resolve host” from curl + inability to browse means DNS resolution is failing right now (even though earlier nslookup succeeded). That usually means Windows is trying to use a DNS resolver that isn’t answering (local resolver, virtual adapter, or a blocked/changed DNS config), or a Windows network service/agent is interfering. Community reports point to exactly this class of problem (NCSI probes failing / WinHTTP / DNS client problems), and there’s a short checklist below that fixes most cases.
  • Because you said you can’t paste from that PC, I’ll give commands that save full diagnostics to a text file you can copy off the machine (USB/thumb drive or photograph and upload from another device). Do those first and either upload the file or tell me what you see.
Step A — gather a single diagnostic file (run as Administrator)
  1. Open Command Prompt (Admin).
  2. Run this block (copy/paste the whole block into the admin prompt). It writes useful outputs to C:\Temp\netdiag.txt:
mkdir C:\Temp 2>nul
(
echo ==== ipconfig /all ====
ipconfig /all
echo.
echo ==== route print ====
route print
echo.
echo ==== netsh interface ipv4 show dns ====
netsh interface ipv4 show dns
echo.
echo ==== netsh winhttp show proxy ====
netsh winhttp show proxy
echo.
echo ==== sc query dnscache ====
sc query dnscache
echo.
echo ==== sc query WinHttpAutoProxySvc ====
sc query WinHttpAutoProxySvc
echo.
echo ==== nslookup google.com ====
nslookup google.com 8.8.8.8
echo.
echo ==== nslookup google.com (default) ====
nslookup google.com
echo.
echo ==== type hosts ====
type C:\Windows\System32\drivers\etc\hosts
echo.
echo ==== curl msftncsi ====
curl -v http://www.msftncsi.com/ncsi.txt 2>&1
echo.
echo ==== ping tests ====
ping -n 3 192.168.1.1
ping -n 3 8.8.8.8
) > C:\Temp\netdiag.txt 2>&1
After it finishes, open the file with Notepad: notepad C:\Temp\netdiag.txt — then copy it to a USB stick or photograph the contents and upload it from your other device. If you can, attach that file here; if not, tell me the three key lines near the top: “DNS Servers” reported under the active adapter in ipconfig /all, and the lines from netsh winhttp show proxy and sc query dnscache.
Why these specific checks
  • ipconfig /all shows which DNS servers your NIC is actually using. If you see 127.0.0.1 (localhost) or an unexpected address, that’s the culprit (local resolver broken or a filtering app installed).
  • netsh winhttp show proxy ensures WinHTTP proxy isn’t set. You already said there is no proxy, but the command confirms WinHTTP’s proxy state.
  • sc query dnscache and sc query WinHttpAutoProxySvc check DNS Client and WinHTTP Auto‑Proxy service state; some Windows upgrades or local agents can disable these and break name resolution — the community workaround is to set services to automatic or remove a bad dependency. I can walk through that if those services are disabled.
Step B — quick tests you can run now (one at a time)
  1. Test an external DNS directly (this bypasses your local DNS):
    • nslookup google.com 8.8.8.8
    • If that succeeds, external DNS works and the problem is the resolver your NIC is using.
  2. Test local resolver (if ipconfig showed 127.0.0.1):
    • nslookup google.com 127.0.0.1
    • If that fails, the local DNS service/agent is broken.
  3. Temporarily force a known public DNS on the active interface (tests whether DNS is the issue):
    • Find adapter name: netsh interface ipv4 show interfaces
    • Set DNS (replace "Ethernet" with the adapter name or "Wi‑Fi"):
      netsh interface ipv4 set dns name="Ethernet" source=static addr=8.8.8.8
    • Then try: ping google.com and open a browser.
    • To undo (back to DHCP): netsh interface ipv4 set dns name="Ethernet" source=dhcp
If forcing Google DNS (8.8.8.8) makes browsing work, that proves the problem is whatever DNS your PC was using (local resolver, DNS filter, VPN, or DHCP-provided server).
Step C — quick hosts/proxy/firewall checks (you already did some)
  • Hosts file: open Notepad (Admin) → File → Open → paste C:\Windows\System32\drivers\etc\hosts and set filetype to All Files. If there are any lines referencing msftncsi.com or msftconnecttest.com or redirecting common domains to 127.0.0.1, remove them. (You said you don’t understand this step — that’s normal; open it and paste the short file here or take a picture. Typical default hosts file only has comments and no real entries.)
  • WinHTTP proxy: if netsh winhttp show proxy shows anything other than “Direct access (no proxy server).” run: netsh winhttp reset proxy.
Step D — services / known Windows regression check
  • Check service start values (Admin CMD):
    sc qc dnscache
    sc qc WinHttpAutoProxySvc
  • If either service Start type is set to disabled (Start= disabled), set them temporarily to automatic/demand and start:
    sc config dnscache start= auto
    sc config WinHttpAutoProxySvc start= demand
    net start dnscache
    net start WinHttpAutoProxySvc
Community reports show WinHttpAutoProxySvc / WcmSvc + DNS client interactions can cause name resolution to stop after upgrades — if services won’t start or keep getting disabled, there’s a safe registry/workaround I can give you (it removes a dependency) but I’ll only ask you to run it after you post the diagnostic file so I can confirm it’s necessary.
If you can’t post text from that PC
  • Copy C:\Temp\netdiag.txt to a USB drive and upload it from your phone or another computer to the forum. Or take photos/screenshots of the top ~30 lines (ipconfig /all section showing the active adapter and DNS Servers) and the sc query dnscache output — those are the most important lines.
What I need next (in order of usefulness)
  1. The C:\Temp\netdiag.txt file you created (or at minimum):
    • The “DNS Servers” line under your active adapter from ipconfig /all.
    • Output of: netsh winhttp show proxy
    • Output of: sc query dnscache
    • Result of: nslookup google.com 8.8.8.8
  2. Tell me whether forcing DNS=8.8.8.8 (Step B) fixed browsing temporarily.
If you prefer, tell me what you see and I’ll give the exact next commands (including the registry/workaround to fix WinHTTP/NLA/DNS problems) — I’ll only recommend that registry change once the diagnostics confirm it’s needed.
If you want, here’s a very quick test you can run now (Admin CMD) that doesn’t change anything permanently and will tell us if DNS is the problem:
nslookup google.com 8.8.8.8
nslookup google.com
If the first succeeds and the second fails, your NIC’s configured DNS (or a local resolver) is the problem — force 8.8.8.8 as above to confirm, then send me the diagnostic file and I’ll provide the permanent fix.
I’ll wait for the C:\Temp\netdiag.txt file (or the key lines). Once I see those I’ll give the exact, low‑risk fix.
When I try to temporarily force a known public DNS I get the error:

The configured DNS server is incorrect or does not exist.
 

Thanks — that error message just means Windows rejected the DNS address you tried to write. Common causes are: wrong interface name, bad command syntax, using the wrong IP family (IPv6 vs IPv4), or the adapter being managed (DHCP/Group Policy/virtual adapter) so the change is refused. Let’s fix it step‑by‑step.
Short plan
1) Verify the exact adapter name or index.
2) Set DNS using PowerShell (clear, reliable).
3) Test resolution.
4) Undo (restore DHCP) if needed.
If that fails, run a few checks I asked for earlier so we can see why the system refuses DNS changes. (I’ve included the commands below.)
1) Find the adapter name (one simple command)
  • Open PowerShell as Administrator and run:
    Get-NetAdapter | Format-Table -Auto
  • Note the InterfaceAlias (example: "Ethernet" or "Wi‑Fi") you want to change.
2) Set Google DNS (recommended method)
  • In the same elevated PowerShell run (replace InterfaceAlias with the name you found):
    Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("8.8.8.8","8.8.4.4")
  • This is the modern, reliable way to set DNS on Windows. If it succeeds, flush cache:
    ipconfig /flushdns
  • Test with:
    nslookup google.com
    nslookup google.com 8.8.8.8
(Forum guidance shows both netsh and PowerShell ways to change DNS — the PowerShell method above is less fragile and avoids name/quoting problems. )
3) If you prefer netsh, make sure the interface name is exact
  • List interfaces and names:
    netsh interface ipv4 show interfaces
  • Then set DNS using the exact name shown (example):
    netsh interface ipv4 set dns name="Wi‑Fi" source=static addr=8.8.8.8
  • If netsh returns “The configured DNS server is incorrect or does not exist,” it usually means the name didn’t match an interface or the address was malformed (or the interface is locked by DHCP/GPO/virtual adapter). Using PowerShell avoids those problems.
4) If you need to revert to DHCP later
  • PowerShell:
    Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses
  • Or netsh:
    netsh interface ipv4 set dns name="Ethernet" source=dhcp
5) If the Set‑DNS command is refused or you still see resolution issues
Run these checks (copy output to a file or photograph if you can’t paste):
  • Check which DNS the adapter is using:
    Get-DnsClientServerAddress
    (or) ipconfig /all — look for the “DNS Servers” line under the active adapter.
  • Check DNS Client service:
    sc query dnscache
  • Check WinHTTP proxy:
    netsh winhttp show proxy
  • Test external DNS directly:
    nslookup google.com 8.8.8.8
  • If nslookup to 8.8.8.8 works but the system default nslookup fails, the adapter’s configured resolver (or a local resolver) is the issue.
6) Common causes and what to do next
  • Interface name mismatch / quoting problems — solved by using PowerShell Get-NetAdapter then Set‑DnsClientServerAddress.
  • Adapter managed by DHCP or Group Policy — you’ll get a refusal; confirm with ipconfig /all and gpresult if you suspect policies. If managed, change must come from DHCP/GPO or you must disable the policy.
  • A local DNS proxy/agent (some security suites or VPNs) set DNS to 127.0.0.1 — check ipconfig /all for 127.0.0.1. If present, that local resolver may be broken.
  • Virtual adapters / VPN clients — they sometimes hijack DNS. Disable/uninstall them temporarily and retry.
7) If you still can’t copy/paste from that PC
Create a diagnostic output file (I suggested this earlier) and move it off the PC (USB or photo). The file should include ipconfig /all, netsh winhttp show proxy, sc query dnscache, and a couple of nslookup tests — those lines tell us why DNS changes are refused. I can then point to the exact fix. (I wrote the exact diagnostic block previously — use that if useful.)
If you want, do this now
1) Run in Admin PowerShell:
Get-NetAdapter | Format-Table -Auto
Get-DnsClientServerAddress
Set-DnsClientServerAddress -InterfaceAlias "<your adapter>" -ServerAddresses ("8.8.8.8","8.8.4.4")
ipconfig /flushdns
nslookup google.com
2) Tell me whether any command returned an error, or paste (or upload) the top lines of ipconfig /all showing “DNS Servers” and the output of sc query dnscache and netsh winhttp show proxy.
I’ll walk you through whatever the results show.
 

Thanks — that error message just means Windows rejected the DNS address you tried to write. Common causes are: wrong interface name, bad command syntax, using the wrong IP family (IPv6 vs IPv4), or the adapter being managed (DHCP/Group Policy/virtual adapter) so the change is refused. Let’s fix it step‑by‑step.
Short plan
1) Verify the exact adapter name or index.
2) Set DNS using PowerShell (clear, reliable).
3) Test resolution.
4) Undo (restore DHCP) if needed.
If that fails, run a few checks I asked for earlier so we can see why the system refuses DNS changes. (I’ve included the commands below.)
1) Find the adapter name (one simple command)
  • Open PowerShell as Administrator and run:
    Get-NetAdapter | Format-Table -Auto
  • Note the InterfaceAlias (example: "Ethernet" or "Wi‑Fi") you want to change.
2) Set Google DNS (recommended method)
  • In the same elevated PowerShell run (replace InterfaceAlias with the name you found):
    Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("8.8.8.8","8.8.4.4")
  • This is the modern, reliable way to set DNS on Windows. If it succeeds, flush cache:
    ipconfig /flushdns
  • Test with:
    nslookup google.com
    nslookup google.com 8.8.8.8
(Forum guidance shows both netsh and PowerShell ways to change DNS — the PowerShell method above is less fragile and avoids name/quoting problems. )
3) If you prefer netsh, make sure the interface name is exact
  • List interfaces and names:
    netsh interface ipv4 show interfaces
  • Then set DNS using the exact name shown (example):
    netsh interface ipv4 set dns name="Wi‑Fi" source=static addr=8.8.8.8
  • If netsh returns “The configured DNS server is incorrect or does not exist,” it usually means the name didn’t match an interface or the address was malformed (or the interface is locked by DHCP/GPO/virtual adapter). Using PowerShell avoids those problems.
4) If you need to revert to DHCP later
  • PowerShell:
    Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses
  • Or netsh:
    netsh interface ipv4 set dns name="Ethernet" source=dhcp
5) If the Set‑DNS command is refused or you still see resolution issues
Run these checks (copy output to a file or photograph if you can’t paste):
  • Check which DNS the adapter is using:
    Get-DnsClientServerAddress
    (or) ipconfig /all — look for the “DNS Servers” line under the active adapter.
  • Check DNS Client service:
    sc query dnscache
  • Check WinHTTP proxy:
    netsh winhttp show proxy
  • Test external DNS directly:
    nslookup google.com 8.8.8.8
  • If nslookup to 8.8.8.8 works but the system default nslookup fails, the adapter’s configured resolver (or a local resolver) is the issue.
6) Common causes and what to do next
  • Interface name mismatch / quoting problems — solved by using PowerShell Get-NetAdapter then Set‑DnsClientServerAddress.
  • Adapter managed by DHCP or Group Policy — you’ll get a refusal; confirm with ipconfig /all and gpresult if you suspect policies. If managed, change must come from DHCP/GPO or you must disable the policy.
  • A local DNS proxy/agent (some security suites or VPNs) set DNS to 127.0.0.1 — check ipconfig /all for 127.0.0.1. If present, that local resolver may be broken.
  • Virtual adapters / VPN clients — they sometimes hijack DNS. Disable/uninstall them temporarily and retry.
7) If you still can’t copy/paste from that PC
Create a diagnostic output file (I suggested this earlier) and move it off the PC (USB or photo). The file should include ipconfig /all, netsh winhttp show proxy, sc query dnscache, and a couple of nslookup tests — those lines tell us why DNS changes are refused. I can then point to the exact fix. (I wrote the exact diagnostic block previously — use that if useful.)
If you want, do this now
1) Run in Admin PowerShell:
Get-NetAdapter | Format-Table -Auto
Get-DnsClientServerAddress
Set-DnsClientServerAddress -InterfaceAlias "<your adapter>" -ServerAddresses ("8.8.8.8","8.8.4.4")
ipconfig /flushdns
nslookup google.com
2) Tell me whether any command returned an error, or paste (or upload) the top lines of ipconfig /all showing “DNS Servers” and the output of sc query dnscache and netsh winhttp show proxy.
I’ll walk you through whatever the results show.
I Set Google DNS and flushed the cashe but:

Nslookup google.com returns "*** google.com can't find nslookup: no response from server"

While

Nslookup google.com 8.8.8.8 retuns "Unrecognizex command: nslookup google.com 8.8.8.8"
 

Thanks — good details. Two short notes first:
  • The nslookup responses you posted mean two different things:
    • "*** google.com can't find nslookup: no response from server" — your system tried to resolve with the default configured DNS and that DNS didn’t answer.
    • "Unrecognized command: nslookup google.com 8.8.8.8" — means you were inside the interactive nslookup prompt (you started nslookup then typed the full command). To query a specific server from the shell you must either run nslookup with the server on the same command line from cmd/powershell, or inside nslookup first switch server with the server command. I’ll show both ways below.
Next steps — run these checks (easy, copy/paste into an elevated PowerShell or Command Prompt). They will tell us whether the DNS change actually applied, whether you hit the right interface, and whether the public DNS is reachable.
1) Quick confirm what the adapter and DNS settings actually are
Open PowerShell (Admin) and run:
Get-NetAdapter | Format-Table -Auto
Get-DnsClientServerAddress -AddressFamily IPv4
These show the adapter name(s) and the IPv4 DNS server(s) each adapter is using. If you set DNS on the wrong adapter (Wi‑Fi vs Ethernet) it will look unchanged here. The PowerShell method is the recommended way to set DNS.
2) Test DNS resolution from the shell (non‑interactive)
Run these in PowerShell (Admin) or Command Prompt (Admin):
nslookup google.com 8.8.8.8
nslookup google.com
  • The first asks Google’s DNS (8.8.8.8) directly. The second uses your system’s configured DNS.
  • If the first succeeds and the second fails, your machine’s configured resolver is still the problem.
If you accidentally entered nslookup then typed the full command (and saw “Unrecognized command”), instead do this inside nslookup:
server 8.8.8.8
google.com
(or just run the one-line versions above from the normal shell).
3) If the default DNS still fails, try Test‑NetConnection (PowerShell)
Test-NetConnection -DnsName google.com -Server 8.8.8.8 -InformationLevel Detailed
This verifies you can reach the DNS server and shows transport results.
4) If Set-DnsClientServerAddress succeeded but resolution still fails
  • Restart the adapter (replace InterfaceAlias with the name from step 1):
    Disable-NetAdapter -Name "Ethernet" -Confirm:$false
    Enable-NetAdapter -Name "Ethernet" -Confirm:$false
  • Or reboot the PC.
5) If you still can’t resolve with your configured DNS but can with 8.8.8.8
It means either:
  • Your adapter still points at a local/incorrect resolver (e.g., 127.0.0.1) or the router’s DNS (which may be blocked),
  • Or a local resolver/agent or VPN/security product is hijacking DNS. Check for 127.0.0.1 in Get-DnsClientServerAddress or ipconfig /all.
6) Quick service & proxy checks
In PowerShell (Admin) or CMD (Admin) run:
sc query dnscache
netsh winhttp show proxy
DNS Client (Dnscache) should be RUNNING and WinHTTP should show "Direct access (no proxy server)" if you have no proxy.
7) If you can’t paste from that PC — save outputs to a file and move it off the PC
Run this in an elevated shell to create a single diagnostic file you can copy to USB or photograph:
mkdir C:\Temp 2> $null ; Get-NetAdapter | Format-Table -Auto > C:\Temp\net2.txt ;
Get-DnsClientServerAddress -AddressFamily IPv4 >> C:\Temp\net2.txt ; ipconfig /all >> C:\Temp\net2.txt ;
nslookup google.com 8.8.8.8 >> C:\Temp\net2.txt 2>&1 ; nslookup google.com >> C:\Temp\net2.txt 2>&1 ;
sc query dnscache >> C:\Temp\net2.txt ; `
netsh winhttp show proxy >> C:\Temp\net2.txt
Then open C:\Temp\net2.txt in Notepad and copy it to a USB or take a photo of the top ~30 lines (we mainly need the InterfaceAlias and DNS Servers lines).
What I expect from your results
  • If Get-DnsClientServerAddress shows 8.8.8.8/8.8.4.4 for the adapter you’re using and nslookup google.com 8.8.8.8 works but nslookup google.com (default) fails, something else is still overriding DNS for regular queries (local resolver or policy). If the adapter doesn’t show 8.8.8.8 then the Set command didn’t apply to the correct interface — re-run Set‑DnsClientServerAddress with the exact InterfaceAlias you saw.
If you post (or upload) the small outputs requested (Get-NetAdapter and Get-DnsClientServerAddress, plus the two nslookup results and sc query dnscache), I’ll tell you the exact corrective command (or the registry/workaround if a local service is blocking DNS).
If you want, paste the exact command you used to set DNS and the InterfaceAlias shown from Get-NetAdapter and I’ll confirm whether it was applied to the correct interface.
 

Thanks — good details. Two short notes first:
  • The nslookup responses you posted mean two different things:
    • "*** google.com can't find nslookup: no response from server" — your system tried to resolve with the default configured DNS and that DNS didn’t answer.
    • "Unrecognized command: nslookup google.com 8.8.8.8" — means you were inside the interactive nslookup prompt (you started nslookup then typed the full command). To query a specific server from the shell you must either run nslookup with the server on the same command line from cmd/powershell, or inside nslookup first switch server with the server command. I’ll show both ways below.
Next steps — run these checks (easy, copy/paste into an elevated PowerShell or Command Prompt). They will tell us whether the DNS change actually applied, whether you hit the right interface, and whether the public DNS is reachable.
1) Quick confirm what the adapter and DNS settings actually are
Open PowerShell (Admin) and run:
Get-NetAdapter | Format-Table -Auto
Get-DnsClientServerAddress -AddressFamily IPv4
These show the adapter name(s) and the IPv4 DNS server(s) each adapter is using. If you set DNS on the wrong adapter (Wi‑Fi vs Ethernet) it will look unchanged here. The PowerShell method is the recommended way to set DNS.
2) Test DNS resolution from the shell (non‑interactive)
Run these in PowerShell (Admin) or Command Prompt (Admin):
nslookup google.com 8.8.8.8
nslookup google.com
  • The first asks Google’s DNS (8.8.8.8) directly. The second uses your system’s configured DNS.
  • If the first succeeds and the second fails, your machine’s configured resolver is still the problem.
If you accidentally entered nslookup then typed the full command (and saw “Unrecognized command”), instead do this inside nslookup:
server 8.8.8.8
google.com
(or just run the one-line versions above from the normal shell).
3) If the default DNS still fails, try Test‑NetConnection (PowerShell)
Test-NetConnection -DnsName google.com -Server 8.8.8.8 -InformationLevel Detailed
This verifies you can reach the DNS server and shows transport results.
4) If Set-DnsClientServerAddress succeeded but resolution still fails
  • Restart the adapter (replace InterfaceAlias with the name from step 1):
    Disable-NetAdapter -Name "Ethernet" -Confirm:$false
    Enable-NetAdapter -Name "Ethernet" -Confirm:$false
  • Or reboot the PC.
5) If you still can’t resolve with your configured DNS but can with 8.8.8.8
It means either:
  • Your adapter still points at a local/incorrect resolver (e.g., 127.0.0.1) or the router’s DNS (which may be blocked),
  • Or a local resolver/agent or VPN/security product is hijacking DNS. Check for 127.0.0.1 in Get-DnsClientServerAddress or ipconfig /all.
6) Quick service & proxy checks
In PowerShell (Admin) or CMD (Admin) run:
sc query dnscache
netsh winhttp show proxy
DNS Client (Dnscache) should be RUNNING and WinHTTP should show "Direct access (no proxy server)" if you have no proxy.
7) If you can’t paste from that PC — save outputs to a file and move it off the PC
Run this in an elevated shell to create a single diagnostic file you can copy to USB or photograph:
mkdir C:\Temp 2> $null ; Get-NetAdapter | Format-Table -Auto > C:\Temp\net2.txt ;
Get-DnsClientServerAddress -AddressFamily IPv4 >> C:\Temp\net2.txt ; ipconfig /all >> C:\Temp\net2.txt ;
nslookup google.com 8.8.8.8 >> C:\Temp\net2.txt 2>&1 ; nslookup google.com >> C:\Temp\net2.txt 2>&1 ;
sc query dnscache >> C:\Temp\net2.txt ; `
netsh winhttp show proxy >> C:\Temp\net2.txt
Then open C:\Temp\net2.txt in Notepad and copy it to a USB or take a photo of the top ~30 lines (we mainly need the InterfaceAlias and DNS Servers lines).
What I expect from your results
  • If Get-DnsClientServerAddress shows 8.8.8.8/8.8.4.4 for the adapter you’re using and nslookup google.com 8.8.8.8 works but nslookup google.com (default) fails, something else is still overriding DNS for regular queries (local resolver or policy). If the adapter doesn’t show 8.8.8.8 then the Set command didn’t apply to the correct interface — re-run Set‑DnsClientServerAddress with the exact InterfaceAlias you saw.
If you post (or upload) the small outputs requested (Get-NetAdapter and Get-DnsClientServerAddress, plus the two nslookup results and sc query dnscache), I’ll tell you the exact corrective command (or the registry/workaround if a local service is blocking DNS).
If you want, paste the exact command you used to set DNS and the InterfaceAlias shown from Get-NetAdapter and I’ll confirm whether it was applied to the correct interface.
Both nslookup checks pass.
 

Good — thanks for the update. If both nslookup tests now succeed, that tells us DNS is working now. The problem is most likely not routing/DHCP anymore but something blocking or intercepting HTTP(S) name lookups for regular apps (browser/curl) — common causes: a local DNS proxy/agent (security/VPN/WARP), WinHTTP/WinHTTP Auto‑Proxy settings, a broken network stack (Winsock/LSP), or a browser/proxy configuration. I’ll give focused tests you can run (single commands or a single diagnostic file you can copy off the PC), what each result means, and the safest fixes to try.
Quick summary (what we know)
  • You can ping the router and 8.8.8.8 and nslookup works. Good — IP routing + DNS at the CLI level are OK. .
  • Yet browsers/curl still say “could not resolve host” or fail to load pages — that points at either (A) apps using a different resolver/WinHTTP proxy, (B) a local DNS proxy/agent (127.0.0.1) that’s broken, or (C) HTTP/HTTPS blocked by a security product or service.
Run the three quick tests first (one at a time)
Run these from an elevated Command Prompt (right‑click Start → Command Prompt (Admin) or Windows Terminal (Admin)).
1) Test HTTP by IP (bypasses name resolution)
  • Command:
    powershell -Command "try {Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8 | Select-Object StatusCode; } catch { \$_.Exception.Message }"
  • Expected:
    • If you get a numeric HTTP status or at least a response string, HTTP by IP works → name resolution or DNS proxy for apps is the issue.
    • If this fails, HTTP outbound or port 80 is being blocked.
2) Test HTTP(S) by name using PowerShell (non‑interactive):
  • Command:
    powershell -Command "try {Invoke-WebRequest -Uri 'https://www.google.com' -UseBasicParsing -TimeoutSec 8 | Select-Object StatusCode;} catch { \$_.Exception.Message }"
  • Expected:
    • Success = HTTP(S) reachable from core OS APIs; failure will show an error string we can interpret.
3) Test WinHTTP proxy and DNS client status
  • Commands:
    netsh winhttp show proxy
    sc query dnscache
  • Expected:
    • netsh should show “Direct access (no proxy server)” if there is no system/WinHTTP proxy.
    • dnscache should be RUNNING. If not, start it and test again.
If you prefer to run one command that collects everything (recommended since you said you can’t paste) — create a diagnostics file you can copy to USB or photograph:
Full diagnostic block (run as Admin — writes C:\Temp\webdiag.txt)
1) Open Admin Command Prompt and paste the whole block:
mkdir C:\Temp 2>nul
(
echo ==== date/time ====
date /T & time /T
echo.
echo ==== ipconfig /all ====
ipconfig /all
echo.
echo ==== Get adapter + DNS (PowerShell) ====
powershell -Command "Get-NetAdapter | Format-Table -Auto"
powershell -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-List"
echo.
echo ==== netsh winhttp show proxy ====
netsh winhttp show proxy
echo.
echo ==== sc query dnscache ====
sc query dnscache
echo.
echo ==== nslookup google.com 8.8.8.8 ====
nslookup google.com 8.8.8.8
echo.
echo ==== nslookup google.com (default) ====
nslookup google.com
echo.
echo ==== Invoke-WebRequest by IP (http) ====
powershell -Command "try {Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8 | Out-String} catch { 'ERROR: ' + \$.Exception.Message }"
echo.
echo ==== Invoke-WebRequest by name (https) ====
powershell -Command "try {Invoke-WebRequest -Uri 'https://www.google.com' -UseBasicParsing -TimeoutSec 8 | Out-String} catch { 'ERROR: ' + \$
.Exception.Message }"
echo.
echo ==== tracert google.com ====
tracert -d -h 8 google.com
echo.
echo ==== netstat -rn (routing) ====
netstat -rn
) > C:\Temp\webdiag.txt 2>&1
Then open Notepad: notepad C:\Temp\webdiag.txt — copy that file to a USB stick or take a photo of the top ~50 lines (we mainly need the adapter/DNS lines, netsh winhttp output, sc query dnscache and the two PowerShell Invoke‑WebRequest outputs). Upload the file or photos from another device and I’ll interpret them. (If you want, run just the three quick tests above and report results instead.)
What each outcome tells us and immediate fixes
A) If HTTP by IP works but HTTPS/name fails
  • Meaning: outbound TCP/HTTP works but name resolution for apps is being intercepted or the app uses a different resolver (WinHTTP/WinINet/Browser proxy). Check WinHTTP proxy and the hosts file (no entries should block msftncsi, msftconnecttest or common domains). Reset WinHTTP proxy if anything unexpected: netsh winhttp reset proxy.
B) If both HTTP by IP and HTTP by name fail
  • Meaning: outbound HTTP/HTTPS blocked by firewall/AV or network driver. Try:
    • Temporarily disable any third‑party security / VPN / Cloudflare WARP and retest. Many security/VPN agents hijack DNS or filter traffic.
    • Reset Winsock & TCP/IP and reboot:
      netsh winsock reset
      netsh int ip reset
      ipconfig /flushdns
      restart the PC. These often fix corrupted LSPs or stack issues.
C) If nslookup to public servers works but browsers still fail
  • Meaning: browsers may be using a proxy setting or a system/WinHTTP proxy is set. Check:
    • Internet Options → Connections → LAN settings — ensure no proxy is set.
    • netsh winhttp show proxy (and netsh winhttp reset proxy if needed).
D) If DNS shows 127.0.0.1 in ipconfig/Get‑DnsClientServerAddress
  • Meaning: a local DNS proxy (security software or a DNS resolver like Pi‑hole local agent) is installed but not responding. Either stop/uninstall that agent or reconfigure it. If you find 127.0.0.1 and it’s not something you expect, uninstall the agent or set adapter DNS to public DNS and restart the adapter: Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("8.8.8.8","8.8.4.4"). If Set‑DNS refused earlier, confirm you use the exact InterfaceAlias from Get‑NetAdapter.
Other helpful steps (safe / reversible)
  • Safe Mode with Networking — if the web works there, a startup app/driver is the culprit → perform a Clean Boot to isolate it.
  • Run SFC and DISM if network stack commands don’t fix it:
    sfc /scannow
    DISM /Online /Cleanup-Image /RestoreHealth.
  • Network Reset (Settings → Network & Internet → Network reset) — does reinstall adapters and clear config (you’ll lose saved Wi‑Fi passwords). Use before a repair install.
When to do an in‑place repair
  • If the diagnostics show DNS/DNScache service stopped and it won’t start or the network stack commands fail to fix it, an in‑place Repair/“Reset this PC — Keep my files” usually repairs system components without data loss. Do this only after collecting diagnostics and trying the non‑destructive steps above.
If you want me to diagnose from the file
1) Run the diagnostic block that writes C:\Temp\webdiag.txt (above).
2) Copy C:\Temp\webdiag.txt to USB or photograph and upload.
3) Tell me which security/VPN products are installed (ESET, Sophos, CrowdStrike, WARP/Cloudflare, Cisco AnyConnect, etc.). If you have none, say so.
If you want quick next action right now
  • Run the three quick tests (Invoke‑WebRequest by IP and by name, and netsh winhttp show proxy + sc query dnscache) and tell me their exact outputs (or as a minimum tell me whether the IP test succeeded and whether netsh shows a proxy). If the HTTP‑by‑IP test succeeds but name tests fail, run: netsh winhttp reset proxy and reboot — then retry the browser.
Wrap up / reassurance
You’re close — DNS at CLI level is healthy, so this is a localized app/resolver/proxy or stack problem that we can isolate with the tests above. Run the diagnostic block and either upload the created file or paste the three short test results (HTTP by IP, HTTP by name, netsh winhttp show proxy / sc query dnscache). I’ll read those and give the exact command to fix it (often a single netsh or service tweak).
Which do you want to run now — the single quick tests, or the full diagnostic file so you can upload it?
 

Good — thanks for the update. If both nslookup tests now succeed, that tells us DNS is working now. The problem is most likely not routing/DHCP anymore but something blocking or intercepting HTTP(S) name lookups for regular apps (browser/curl) — common causes: a local DNS proxy/agent (security/VPN/WARP), WinHTTP/WinHTTP Auto‑Proxy settings, a broken network stack (Winsock/LSP), or a browser/proxy configuration. I’ll give focused tests you can run (single commands or a single diagnostic file you can copy off the PC), what each result means, and the safest fixes to try.
Quick summary (what we know)
  • You can ping the router and 8.8.8.8 and nslookup works. Good — IP routing + DNS at the CLI level are OK. .
  • Yet browsers/curl still say “could not resolve host” or fail to load pages — that points at either (A) apps using a different resolver/WinHTTP proxy, (B) a local DNS proxy/agent (127.0.0.1) that’s broken, or (C) HTTP/HTTPS blocked by a security product or service.
Run the three quick tests first (one at a time)
Run these from an elevated Command Prompt (right‑click Start → Command Prompt (Admin) or Windows Terminal (Admin)).
1) Test HTTP by IP (bypasses name resolution)
  • Command:
    powershell -Command "try {Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8 | Select-Object StatusCode; } catch { \$_.Exception.Message }"
  • Expected:
    • If you get a numeric HTTP status or at least a response string, HTTP by IP works → name resolution or DNS proxy for apps is the issue.
    • If this fails, HTTP outbound or port 80 is being blocked.
2) Test HTTP(S) by name using PowerShell (non‑interactive):
  • Command:
    powershell -Command "try {Invoke-WebRequest -Uri 'https://www.google.com' -UseBasicParsing -TimeoutSec 8 | Select-Object StatusCode;} catch { \$_.Exception.Message }"
  • Expected:
    • Success = HTTP(S) reachable from core OS APIs; failure will show an error string we can interpret.
3) Test WinHTTP proxy and DNS client status
  • Commands:
    netsh winhttp show proxy
    sc query dnscache
  • Expected:
    • netsh should show “Direct access (no proxy server)” if there is no system/WinHTTP proxy.
    • dnscache should be RUNNING. If not, start it and test again.
If you prefer to run one command that collects everything (recommended since you said you can’t paste) — create a diagnostics file you can copy to USB or photograph:
Full diagnostic block (run as Admin — writes C:\Temp\webdiag.txt)
1) Open Admin Command Prompt and paste the whole block:
mkdir C:\Temp 2>nul
(
echo ==== date/time ====
date /T & time /T
echo.
echo ==== ipconfig /all ====
ipconfig /all
echo.
echo ==== Get adapter + DNS (PowerShell) ====
powershell -Command "Get-NetAdapter | Format-Table -Auto"
powershell -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-List"
echo.
echo ==== netsh winhttp show proxy ====
netsh winhttp show proxy
echo.
echo ==== sc query dnscache ====
sc query dnscache
echo.
echo ==== nslookup google.com 8.8.8.8 ====
nslookup google.com 8.8.8.8
echo.
echo ==== nslookup google.com (default) ====
nslookup google.com
echo.
echo ==== Invoke-WebRequest by IP (http) ====
powershell -Command "try {Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8 | Out-String} catch { 'ERROR: ' + \$.Exception.Message }"
echo.
echo ==== Invoke-WebRequest by name (https) ====
powershell -Command "try {Invoke-WebRequest -Uri 'https://www.google.com' -UseBasicParsing -TimeoutSec 8 | Out-String} catch { 'ERROR: ' + \$
.Exception.Message }"
echo.
echo ==== tracert google.com ====
tracert -d -h 8 google.com
echo.
echo ==== netstat -rn (routing) ====
netstat -rn
) > C:\Temp\webdiag.txt 2>&1
Then open Notepad: notepad C:\Temp\webdiag.txt — copy that file to a USB stick or take a photo of the top ~50 lines (we mainly need the adapter/DNS lines, netsh winhttp output, sc query dnscache and the two PowerShell Invoke‑WebRequest outputs). Upload the file or photos from another device and I’ll interpret them. (If you want, run just the three quick tests above and report results instead.)
What each outcome tells us and immediate fixes
A) If HTTP by IP works but HTTPS/name fails
  • Meaning: outbound TCP/HTTP works but name resolution for apps is being intercepted or the app uses a different resolver (WinHTTP/WinINet/Browser proxy). Check WinHTTP proxy and the hosts file (no entries should block msftncsi, msftconnecttest or common domains). Reset WinHTTP proxy if anything unexpected: netsh winhttp reset proxy.
B) If both HTTP by IP and HTTP by name fail
  • Meaning: outbound HTTP/HTTPS blocked by firewall/AV or network driver. Try:
    • Temporarily disable any third‑party security / VPN / Cloudflare WARP and retest. Many security/VPN agents hijack DNS or filter traffic.
    • Reset Winsock & TCP/IP and reboot:
      netsh winsock reset
      netsh int ip reset
      ipconfig /flushdns
      restart the PC. These often fix corrupted LSPs or stack issues.
C) If nslookup to public servers works but browsers still fail
  • Meaning: browsers may be using a proxy setting or a system/WinHTTP proxy is set. Check:
    • Internet Options → Connections → LAN settings — ensure no proxy is set.
    • netsh winhttp show proxy (and netsh winhttp reset proxy if needed).
D) If DNS shows 127.0.0.1 in ipconfig/Get‑DnsClientServerAddress
  • Meaning: a local DNS proxy (security software or a DNS resolver like Pi‑hole local agent) is installed but not responding. Either stop/uninstall that agent or reconfigure it. If you find 127.0.0.1 and it’s not something you expect, uninstall the agent or set adapter DNS to public DNS and restart the adapter: Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("8.8.8.8","8.8.4.4"). If Set‑DNS refused earlier, confirm you use the exact InterfaceAlias from Get‑NetAdapter.
Other helpful steps (safe / reversible)
  • Safe Mode with Networking — if the web works there, a startup app/driver is the culprit → perform a Clean Boot to isolate it.
  • Run SFC and DISM if network stack commands don’t fix it:
    sfc /scannow
    DISM /Online /Cleanup-Image /RestoreHealth.
  • Network Reset (Settings → Network & Internet → Network reset) — does reinstall adapters and clear config (you’ll lose saved Wi‑Fi passwords). Use before a repair install.
When to do an in‑place repair
  • If the diagnostics show DNS/DNScache service stopped and it won’t start or the network stack commands fail to fix it, an in‑place Repair/“Reset this PC — Keep my files” usually repairs system components without data loss. Do this only after collecting diagnostics and trying the non‑destructive steps above.
If you want me to diagnose from the file
1) Run the diagnostic block that writes C:\Temp\webdiag.txt (above).
2) Copy C:\Temp\webdiag.txt to USB or photograph and upload.
3) Tell me which security/VPN products are installed (ESET, Sophos, CrowdStrike, WARP/Cloudflare, Cisco AnyConnect, etc.). If you have none, say so.
If you want quick next action right now
  • Run the three quick tests (Invoke‑WebRequest by IP and by name, and netsh winhttp show proxy + sc query dnscache) and tell me their exact outputs (or as a minimum tell me whether the IP test succeeded and whether netsh shows a proxy). If the HTTP‑by‑IP test succeeds but name tests fail, run: netsh winhttp reset proxy and reboot — then retry the browser.
Wrap up / reassurance
You’re close — DNS at CLI level is healthy, so this is a localized app/resolver/proxy or stack problem that we can isolate with the tests above. Run the diagnostic block and either upload the created file or paste the three short test results (HTTP by IP, HTTP by name, netsh winhttp show proxy / sc query dnscache). I’ll read those and give the exact command to fix it (often a single netsh or service tweak).
Which do you want to run now — the single quick tests, or the full diagnostic file so you can upload it?
I am getting error:

"The term '\$_.Exception.Message' is not recognized as the name of a cmdlet, function, script file, or operable program."
 

That error happened because PowerShell's $_ and the try/catch block were sent inside a command string in the wrong shell/with the wrong quoting — Windows interpreted the $_.Exception.Message text literally (or you were already inside an interactive nslookup prompt). The easiest fix is: open PowerShell (Admin) and run the commands directly (no need to call powershell -Command from cmd). Below are exact, copy‑ready PowerShell commands you can run (run them from an elevated PowerShell window).
If you want the quick tests (recommended first)
Open PowerShell as Administrator and run these three commands one at a time:
1) Test HTTP by IP (bypasses DNS)
Try { (Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $_.Exception.Message }
2) Test HTTPS by name
Try { (Invoke-WebRequest -Uri 'https://www.google.com' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $_.Exception.Message }
3) Check WinHTTP proxy and DNS Client
netsh winhttp show proxy
sc query dnscache
Tell me the exact output for each (or take a photo of the window). If HTTP-by-IP succeeds but HTTPS/name fails, we focus on WinHTTP/proxy or a local DNS/agent. If they both fail, we look at firewall/AV or stack corruption.
If you want the full diagnostic file (if you can't paste results)
Run this entire PowerShell block (Admin). It gathers everything to C:\Temp\webdiag.txt and opens it in Notepad:
$Out='C:\Temp\webdiag.txt'
New-Item -Path C:\Temp -ItemType Directory -Force | Out-Null
"n==== date/time ====n" | Out-File $Out
"==== ipconfig /all ====" | Out-File $Out -Append
ipconfig /all | Out-File $Out -Append
"==== Get-NetAdapter ====" | Out-File $Out -Append
Get-NetAdapter | Format-Table -Auto | Out-File $Out -Append
"==== Get-DnsClientServerAddress (IPv4) ====" | Out-File $Out -Append
Get-DnsClientServerAddress -AddressFamily IPv4 | Format-List | Out-File $Out -Append
"==== netsh winhttp show proxy ====" | Out-File $Out -Append
netsh winhttp show proxy | Out-File $Out -Append
"==== sc query dnscache ====" | Out-File $Out -Append
sc query dnscache | Out-File $Out -Append
"==== nslookup google.com 8.8.8.8 ====" | Out-File $Out -Append
nslookup google.com 8.8.8.8 | Out-File $Out -Append
"==== nslookup google.com (default) ====" | Out-File $Out -Append
nslookup google.com | Out-File $Out -Append
"==== Invoke-WebRequest by IP (http) ====" | Out-File $Out -Append
Try { (Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode | Out-File $Out -Append } Catch { ('ERROR: ' + $.Exception.Message) | Out-File $Out -Append }
"==== Invoke-WebRequest by name (https) ====" | Out-File $Out -Append
Try { (Invoke-WebRequest -Uri 'https://www.google.com' -UseBasicParsing -TimeoutSec 8).StatusCode | Out-File $Out -Append } Catch { ('ERROR: ' + $
.Exception.Message) | Out-File $Out -Append }
"==== tracert google.com ====" | Out-File $Out -Append
tracert -d -h 8 google.com | Out-File $Out -Append
"==== netstat -rn ====" | Out-File $Out -Append
netstat -rn | Out-File $Out -Append
notepad $Out
After Notepad opens you can copy the file to a USB stick or photograph it and upload it from another device.
Why this fixes the quoting error
  • Running the PowerShell commands directly avoids the messy escaping you need when embedding $ and braces inside a quoted -Command string called from cmd.exe. Running them in PowerShell (Admin) runs the try/catch and $_ variable correctly.
If you prefer to stick to cmd.exe
Use this exact one‑line (cmd) — note the backslashes for escaping the $ inside double quotes:
powershell -NoProfile -Command "Try { (Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { `$_.Exception.Message }"
But I strongly recommend opening PowerShell (Admin) and running the simpler forms above instead.
Next step
Run the three quick PowerShell tests I gave at the top, tell me their outputs (or upload C:\Temp\webdiag.txt). I’ll read them and give the exact fix (usually one of: reset WinHTTP proxy, stop/uninstall a DNS proxy/VPN agent, reset Winsock, or reconfigure the adapter DNS properly). Reference: standard Windows network diagnostic steps and network reset/Winsock fixes.
Which do you want to run now — the three quick tests or the full diagnostic script?
 

That error happened because PowerShell's $_ and the try/catch block were sent inside a command string in the wrong shell/with the wrong quoting — Windows interpreted the $_.Exception.Message text literally (or you were already inside an interactive nslookup prompt). The easiest fix is: open PowerShell (Admin) and run the commands directly (no need to call powershell -Command from cmd). Below are exact, copy‑ready PowerShell commands you can run (run them from an elevated PowerShell window).
If you want the quick tests (recommended first)
Open PowerShell as Administrator and run these three commands one at a time:
1) Test HTTP by IP (bypasses DNS)
Try { (Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $_.Exception.Message }
2) Test HTTPS by name
Try { (Invoke-WebRequest -Uri 'https://www.google.com' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $_.Exception.Message }
3) Check WinHTTP proxy and DNS Client
netsh winhttp show proxy
sc query dnscache
Tell me the exact output for each (or take a photo of the window). If HTTP-by-IP succeeds but HTTPS/name fails, we focus on WinHTTP/proxy or a local DNS/agent. If they both fail, we look at firewall/AV or stack corruption.
If you want the full diagnostic file (if you can't paste results)
Run this entire PowerShell block (Admin). It gathers everything to C:\Temp\webdiag.txt and opens it in Notepad:
$Out='C:\Temp\webdiag.txt'
New-Item -Path C:\Temp -ItemType Directory -Force | Out-Null
"n==== date/time ====n" | Out-File $Out
"==== ipconfig /all ====" | Out-File $Out -Append
ipconfig /all | Out-File $Out -Append
"==== Get-NetAdapter ====" | Out-File $Out -Append
Get-NetAdapter | Format-Table -Auto | Out-File $Out -Append
"==== Get-DnsClientServerAddress (IPv4) ====" | Out-File $Out -Append
Get-DnsClientServerAddress -AddressFamily IPv4 | Format-List | Out-File $Out -Append
"==== netsh winhttp show proxy ====" | Out-File $Out -Append
netsh winhttp show proxy | Out-File $Out -Append
"==== sc query dnscache ====" | Out-File $Out -Append
sc query dnscache | Out-File $Out -Append
"==== nslookup google.com 8.8.8.8 ====" | Out-File $Out -Append
nslookup google.com 8.8.8.8 | Out-File $Out -Append
"==== nslookup google.com (default) ====" | Out-File $Out -Append
nslookup google.com | Out-File $Out -Append
"==== Invoke-WebRequest by IP (http) ====" | Out-File $Out -Append
Try { (Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode | Out-File $Out -Append } Catch { ('ERROR: ' + $.Exception.Message) | Out-File $Out -Append }
"==== Invoke-WebRequest by name (https) ====" | Out-File $Out -Append
Try { (Invoke-WebRequest -Uri 'https://www.google.com' -UseBasicParsing -TimeoutSec 8).StatusCode | Out-File $Out -Append } Catch { ('ERROR: ' + $
.Exception.Message) | Out-File $Out -Append }
"==== tracert google.com ====" | Out-File $Out -Append
tracert -d -h 8 google.com | Out-File $Out -Append
"==== netstat -rn ====" | Out-File $Out -Append
netstat -rn | Out-File $Out -Append
notepad $Out
After Notepad opens you can copy the file to a USB stick or photograph it and upload it from another device.
Why this fixes the quoting error
  • Running the PowerShell commands directly avoids the messy escaping you need when embedding $ and braces inside a quoted -Command string called from cmd.exe. Running them in PowerShell (Admin) runs the try/catch and $_ variable correctly.
If you prefer to stick to cmd.exe
Use this exact one‑line (cmd) — note the backslashes for escaping the $ inside double quotes:
powershell -NoProfile -Command "Try { (Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { `$_.Exception.Message }"
But I strongly recommend opening PowerShell (Admin) and running the simpler forms above instead.
Next step
Run the three quick PowerShell tests I gave at the top, tell me their outputs (or upload C:\Temp\webdiag.txt). I’ll read them and give the exact fix (usually one of: reset WinHTTP proxy, stop/uninstall a DNS proxy/VPN agent, reset Winsock, or reconfigure the adapter DNS properly). Reference: standard Windows network diagnostic steps and network reset/Winsock fixes.
Which do you want to run now — the three quick tests or the full diagnostic script?
 

Thanks — you’re very close. Based on what you’ve already done and the logs we collected, this is now most often either (A) an app/WinHTTP/proxy or local DNS‑proxy intercepting lookups for programs (so CLI nslookup works but browser/curl fail), or (B) a corrupted network stack/LSP or security/VPN agent filtering DNS/HTTP. The next steps will quickly tell which and give the low‑risk fix. (Commands below are for an Administrator PowerShell / Admin Command Prompt.)
1) Quick checks — run these first (one at a time)
  • Open PowerShell as Administrator and run exactly:
    Try { (Invoke-WebRequest 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $_.Exception.Message }
    Try { (Invoke-WebRequest 'https://www.google.com' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $_.Exception.Message }
    netsh winhttp show proxy
    sc query dnscache
What to read:
  • If the first (HTTP by IP) returns a numeric status (eg. 200) but the second (HTTPS by name) fails → DNS/proxy/WinHTTP or a local DNS agent is the likely cause. If both fail → firewall/AV or stack issue. If netsh shows anything other than “Direct access (no proxy server)” or dnscache is not RUNNING, that’s actionable.
2) If HTTP-by‑IP works but name lookups from apps fail
  • Reset the WinHTTP proxy (safe, reversible) and reboot:
    netsh winhttp reset proxy
    Restart-Computer
  • Then retry a browser/curl. If that fixes it, great — a system/WinHTTP proxy was interfering. If not, keep going.
3) If both HTTP-by‑IP and name fail (or resetting winhttp didn’t help)
  • Reset Winsock / TCP/IP and reboot:
    netsh winsock reset
    netsh int ip reset
    ipconfig /flushdns
    Restart-Computer
This fixes corrupt LSPs / network stack issues that can break app‑level name resolution.
4) Check whether a local resolver/agent is hijacking DNS
  • Run:
    Get-DnsClientServerAddress -AddressFamily IPv4
    ipconfig /all
Look for “DNS Servers” showing 127.0.0.1 (or another unexpected local address). If you see 127.0.0.1 a local DNS proxy (VPN, WARP/Cloudflare, security product, Pi‑hole agent) is installed but not responding — either stop/uninstall that software or reconfigure it to use an upstream DNS. If you’re not sure which service, list installed security/VPN apps (ESET, Sophos, CrowdStrike, Cloudflare WARP, AnyConnect) and disable them temporarily.
5) If you can’t paste text from the PC — create one diagnostic file (copy to USB / photograph)
  • Run as Admin (single block — copies many outputs to C:\Temp\webdiag.txt):
mkdir C:\Temp 2> $null
(
echo ==== ipconfig /all ====
ipconfig /all
echo.
echo ==== Get-NetAdapter ====
powershell -Command "Get-NetAdapter | Format-Table -Auto"
echo.
echo ==== Get-DnsClientServerAddress (IPv4) ====
powershell -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-List"
echo.
echo ==== netsh winhttp show proxy ====
netsh winhttp show proxy
echo.
echo ==== sc query dnscache ====
sc query dnscache
echo.
echo ==== nslookup google.com 8.8.8.8 ====
nslookup google.com 8.8.8.8
echo.
echo ==== nslookup google.com ====
nslookup google.com
echo.
echo ==== Invoke-WebRequest by IP ====
powershell -Command "Try { (Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { 'ERROR: ' + \$.Exception.Message }"
echo.
echo ==== Invoke-WebRequest by name ====
powershell -Command "Try { (Invoke-WebRequest -Uri 'https://www.google.com' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { 'ERROR: ' + \$
.Exception.Message }"
) > C:\Temp\webdiag.txt 2>&1
  • Then: notepad C:\Temp\webdiag.txt → copy the file to USB or photograph the top ~40 lines and upload from your phone. Those lines are the ones I need to diagnose precisely.
6) If a DNS change was refused earlier when you tried to force 8.8.8.8
  • Confirm the interface name and set DNS via PowerShell (more reliable):
    Get-NetAdapter | Format-Table -Auto
    Set-DnsClientServerAddress -InterfaceAlias "Wi‑Fi" -ServerAddresses ("8.8.8.8","8.8.4.4")
    ipconfig /flushdns
(Replace "Wi‑Fi" with the InterfaceAlias shown by Get‑NetAdapter.) If Set‑DNS fails, that means the adapter is managed (DHCP/GPO) or a local agent is preventing changes — share ipconfig /all and I’ll point to the right workaround.
7) If nothing above fixes it
  • Try Safe Mode with Networking; if internet works there, do a Clean Boot to isolate the startup item (likely VPN/agent). If services won’t start or the DNS client is disabled and cannot be started, an in‑place Repair (Reset this PC — Keep my files) usually restores the Windows networking stack. Use Network Reset only as a near‑last step (it removes saved Wi‑Fi profiles).
What I need from you next
  • Pick one: run the three quick PowerShell tests (Invoke‑WebRequest IP/name + netsh winhttp show proxy + sc query dnscache) and tell me the exact outputs, OR run the full diagnostic block to C:\Temp\webdiag.txt and upload that file (or a photo) here. If you’re unsure how to copy the file off the machine, say so and I’ll give step‑by‑step instructions for using a USB stick.
If you want, I can paste the exact one‑line PowerShell/CMD commands again (safe, copy‑pasteable). Which would you like to run now — the quick tests or the full diagnostic file?
 

That error happened because PowerShell's $_ and the try/catch block were sent inside a command string in the wrong shell/with the wrong quoting — Windows interpreted the $_.Exception.Message text literally (or you were already inside an interactive nslookup prompt). The easiest fix is: open PowerShell (Admin) and run the commands directly (no need to call powershell -Command from cmd). Below are exact, copy‑ready PowerShell commands you can run (run them from an elevated PowerShell window).
If you want the quick tests (recommended first)
Open PowerShell as Administrator and run these three commands one at a time:
1) Test HTTP by IP (bypasses DNS)
Try { (Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $_.Exception.Message }
2) Test HTTPS by name
Try { (Invoke-WebRequest -Uri 'https://www.google.com' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $_.Exception.Message }
3) Check WinHTTP proxy and DNS Client
netsh winhttp show proxy
sc query dnscache
Tell me the exact output for each (or take a photo of the window). If HTTP-by-IP succeeds but HTTPS/name fails, we focus on WinHTTP/proxy or a local DNS/agent. If they both fail, we look at firewall/AV or stack corruption.
If you want the full diagnostic file (if you can't paste results)
Run this entire PowerShell block (Admin). It gathers everything to C:\Temp\webdiag.txt and opens it in Notepad:
$Out='C:\Temp\webdiag.txt'
New-Item -Path C:\Temp -ItemType Directory -Force | Out-Null
"n==== date/time ====n" | Out-File $Out
"==== ipconfig /all ====" | Out-File $Out -Append
ipconfig /all | Out-File $Out -Append
"==== Get-NetAdapter ====" | Out-File $Out -Append
Get-NetAdapter | Format-Table -Auto | Out-File $Out -Append
"==== Get-DnsClientServerAddress (IPv4) ====" | Out-File $Out -Append
Get-DnsClientServerAddress -AddressFamily IPv4 | Format-List | Out-File $Out -Append
"==== netsh winhttp show proxy ====" | Out-File $Out -Append
netsh winhttp show proxy | Out-File $Out -Append
"==== sc query dnscache ====" | Out-File $Out -Append
sc query dnscache | Out-File $Out -Append
"==== nslookup google.com 8.8.8.8 ====" | Out-File $Out -Append
nslookup google.com 8.8.8.8 | Out-File $Out -Append
"==== nslookup google.com (default) ====" | Out-File $Out -Append
nslookup google.com | Out-File $Out -Append
"==== Invoke-WebRequest by IP (http) ====" | Out-File $Out -Append
Try { (Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode | Out-File $Out -Append } Catch { ('ERROR: ' + $.Exception.Message) | Out-File $Out -Append }
"==== Invoke-WebRequest by name (https) ====" | Out-File $Out -Append
Try { (Invoke-WebRequest -Uri 'https://www.google.com' -UseBasicParsing -TimeoutSec 8).StatusCode | Out-File $Out -Append } Catch { ('ERROR: ' + $
.Exception.Message) | Out-File $Out -Append }
"==== tracert google.com ====" | Out-File $Out -Append
tracert -d -h 8 google.com | Out-File $Out -Append
"==== netstat -rn ====" | Out-File $Out -Append
netstat -rn | Out-File $Out -Append
notepad $Out
After Notepad opens you can copy the file to a USB stick or photograph it and upload it from another device.
Why this fixes the quoting error
  • Running the PowerShell commands directly avoids the messy escaping you need when embedding $ and braces inside a quoted -Command string called from cmd.exe. Running them in PowerShell (Admin) runs the try/catch and $_ variable correctly.
If you prefer to stick to cmd.exe
Use this exact one‑line (cmd) — note the backslashes for escaping the $ inside double quotes:
powershell -NoProfile -Command "Try { (Invoke-WebRequest -Uri 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { `$_.Exception.Message }"
But I strongly recommend opening PowerShell (Admin) and running the simpler forms above instead.
Next step
Run the three quick PowerShell tests I gave at the top, tell me their outputs (or upload C:\Temp\webdiag.txt). I’ll read them and give the exact fix (usually one of: reset WinHTTP proxy, stop/uninstall a DNS proxy/VPN agent, reset Winsock, or reconfigure the adapter DNS properly). Reference: standard Windows network diagnostic steps and network reset/Winsock fixes.
Which do you want to run now — the three quick tests or the full diagnostic script?
 

Attachments

  • 17607310483538748779331210189743.webp
    17607310483538748779331210189743.webp
    1,001.7 KB · Views: 0
Thanks — the photo helps a lot.
What I see
  • Invoke‑WebRequest http://216.58.214.14 → "The operation has timed out."
    -> TCP to the remote web server (port 80) is not succeeding from this PC.
  • Invoke‑WebRequest https://www.google.com → "The remote name could not be resolved"
    -> PowerShell/WinHTTP couldn't resolve the hostname, even though you previously ran nslookup successfully from the CLI.
  • netsh winhttp show proxy → "Direct access (no proxy server)."
    -> WinHTTP proxy is not set.
  • sc query dnscache appears blank in the photo (either you didn't capture the output or it returned nothing visible). DNS Client service status is still worth confirming.
Interpretation (most likely)
  • DNS at the CLI level works (you said nslookup passed) but PowerShell/curl/browser requests either cannot reach remote TCP ports (timeout) or are failing name resolution inside the app layer. Because HTTP by IP timed out, this points toward a transport-level block (local firewall/AV, third‑party network filter, or a bad network driver) rather than an ISP/router-wide block (other devices are fine). The WinHTTP proxy is clear, so a system proxy is not the cause.
Next steps — please run these (Admin PowerShell). You can take photos of the outputs and upload them if you can’t copy/paste.
1) Test TCP connectivity to Google IP (checks port 80 and 443)
Test-NetConnection -ComputerName 216.58.214.14 -Port 80 -InformationLevel Detailed
Test-NetConnection -ComputerName 216.58.214.14 -Port 443 -InformationLevel Detailed
2) Test DNS server reachability (TCP/UDP port 53)
Test-NetConnection -ComputerName 8.8.8.8 -Port 53 -InformationLevel Detailed
3) Repeat the PowerShell web tests (copy exact output)
Try { (Invoke-WebRequest 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $.Exception.Message }
Try { (Invoke-WebRequest 'https://www.google.com' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $
.Exception.Message }
4) Basic system/network info to check what might be filtering
ipconfig /all
route print
netsh advfirewall show allprofiles
5) List network adapters and active virtual/VPN adapters
Get-NetAdapter | Format-Table -Auto
netsh interface ipv4 show interfaces
What to look for in those results
  • If Test‑NetConnection to 216.58.214.14 port 80/443 shows “TcpTestSucceeded : False” or “Filtering: True” → a local firewall/AV or network filter is blocking outbound TCP.
  • If Test‑NetConnection to 8.8.8.8:53 fails → DNS traffic is being blocked at UDP/TCP 53 (common with some security products).
  • If ipconfig shows DNS = 127.0.0.1 → a local DNS proxy is installed (Cloudflare WARP, Pi‑hole agent, security product).
  • netsh advfirewall show allprofiles will show whether Windows Firewall is ON. Even if you disabled it earlier, we need the current state shown.
Quick troubleshooting you can try now (safe)
  • Temporarily disable/uninstall any third‑party security / VPN / WARP / DNS‑filtering app. (Even if “off”, some drivers/filters remain.) Reboot and test the PowerShell web test again.
  • Boot into Safe Mode with Networking and try browsing — if it works there, a startup app/driver is the culprit.
If you prefer I can create one command that writes all the above outputs to C:\Temp\webdiag.txt (you can copy that file to USB or photograph it). Say “create diag file” and I’ll paste that single command for you to run.
Tell me:
  • The outputs (photos or text) of the Test‑NetConnection commands and netsh advfirewall show allprofiles.
  • Whether you have any security software (name), VPN client, or Cloudflare WARP installed.
With those results I’ll give the precise next action (usually: uninstall the offending filter/agent or reset Winsock + reboot if it’s a corrupted LSP).
 

Thanks — the photo helps a lot.
What I see
  • Invoke‑WebRequest http://216.58.214.14 → "The operation has timed out."
    -> TCP to the remote web server (port 80) is not succeeding from this PC.
  • Invoke‑WebRequest https://www.google.com → "The remote name could not be resolved"
    -> PowerShell/WinHTTP couldn't resolve the hostname, even though you previously ran nslookup successfully from the CLI.
  • netsh winhttp show proxy → "Direct access (no proxy server)."
    -> WinHTTP proxy is not set.
  • sc query dnscache appears blank in the photo (either you didn't capture the output or it returned nothing visible). DNS Client service status is still worth confirming.
Interpretation (most likely)
  • DNS at the CLI level works (you said nslookup passed) but PowerShell/curl/browser requests either cannot reach remote TCP ports (timeout) or are failing name resolution inside the app layer. Because HTTP by IP timed out, this points toward a transport-level block (local firewall/AV, third‑party network filter, or a bad network driver) rather than an ISP/router-wide block (other devices are fine). The WinHTTP proxy is clear, so a system proxy is not the cause.
Next steps — please run these (Admin PowerShell). You can take photos of the outputs and upload them if you can’t copy/paste.
1) Test TCP connectivity to Google IP (checks port 80 and 443)
Test-NetConnection -ComputerName 216.58.214.14 -Port 80 -InformationLevel Detailed
Test-NetConnection -ComputerName 216.58.214.14 -Port 443 -InformationLevel Detailed
2) Test DNS server reachability (TCP/UDP port 53)
Test-NetConnection -ComputerName 8.8.8.8 -Port 53 -InformationLevel Detailed
3) Repeat the PowerShell web tests (copy exact output)
Try { (Invoke-WebRequest 'http://216.58.214.14' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $.Exception.Message }
Try { (Invoke-WebRequest 'https://www.google.com' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $
.Exception.Message }
4) Basic system/network info to check what might be filtering
ipconfig /all
route print
netsh advfirewall show allprofiles
5) List network adapters and active virtual/VPN adapters
Get-NetAdapter | Format-Table -Auto
netsh interface ipv4 show interfaces
What to look for in those results
  • If Test‑NetConnection to 216.58.214.14 port 80/443 shows “TcpTestSucceeded : False” or “Filtering: True” → a local firewall/AV or network filter is blocking outbound TCP.
  • If Test‑NetConnection to 8.8.8.8:53 fails → DNS traffic is being blocked at UDP/TCP 53 (common with some security products).
  • If ipconfig shows DNS = 127.0.0.1 → a local DNS proxy is installed (Cloudflare WARP, Pi‑hole agent, security product).
  • netsh advfirewall show allprofiles will show whether Windows Firewall is ON. Even if you disabled it earlier, we need the current state shown.
Quick troubleshooting you can try now (safe)
  • Temporarily disable/uninstall any third‑party security / VPN / WARP / DNS‑filtering app. (Even if “off”, some drivers/filters remain.) Reboot and test the PowerShell web test again.
  • Boot into Safe Mode with Networking and try browsing — if it works there, a startup app/driver is the culprit.
If you prefer I can create one command that writes all the above outputs to C:\Temp\webdiag.txt (you can copy that file to USB or photograph it). Say “create diag file” and I’ll paste that single command for you to run.
Tell me:
  • The outputs (photos or text) of the Test‑NetConnection commands and netsh advfirewall show allprofiles.
  • Whether you have any security software (name), VPN client, or Cloudflare WARP installed.
With those results I’ll give the precise next action (usually: uninstall the offending filter/agent or reset Winsock + reboot if it’s a corrupted LSP).
 

Attachments

  • 1760731565195771449161507259087.webp
    1760731565195771449161507259087.webp
    1.2 MB · Views: 0
  • 17607319912661312250250558493544.webp
    17607319912661312250250558493544.webp
    1.1 MB · Views: 0
  • 17607320270637265949916584254695.webp
    17607320270637265949916584254695.webp
    1.5 MB · Views: 0
  • 176073208692895832640716525653.webp
    176073208692895832640716525653.webp
    1.5 MB · Views: 0
  • 17607321608886641857500114712666.webp
    17607321608886641857500114712666.webp
    1.4 MB · Views: 0
  • 17607322879895197728983971097660.webp
    17607322879895197728983971097660.webp
    1.1 MB · Views: 0
Thanks — the photos are perfect. Quick summary of what they show and what it means:
  • Test‑NetConnection to 216.58.214.14 ports 80 and 443: TcpTestSucceeded = True.
  • Test‑NetConnection to 8.8.8.8:53: TcpTestSucceeded = True.
  • ipconfig /all shows the PC has IP 192.168.50.216 and DNS servers 8.8.8.8 / 8.8.4.4.
  • netsh winhttp show proxy => Direct access (no proxy).
  • netsh advfirewall show allprofiles shows Firewall state OFF.
    => Network routing and DNS at the transport/CLI level are working and outbound TCP is allowed. Yet PowerShell/Invoke‑WebRequest and your browser still report name resolution / “no internet”.
That pattern strongly points to a local app / network‑filtering driver or corrupted Windows network stack (LSP/Winsock) or a DNS‑intercepting local agent (VPN, WARP, security product) that affects app APIs but not raw nslookup/Test‑NetConnection.
Next (safe, in order). Run each step, reboot when requested, and tell me what changes (or take photos of any outputs you can’t paste):
1) Restart DNS Client and flush DNS (quick, non‑destructive)
  • Open PowerShell (Admin) and run:
    sc stop dnscache
    sc start dnscache
    ipconfig /flushdns
  • Then retry a browser and run in PowerShell:
    Try { (Invoke-WebRequest 'https://www.google.com' -UseBasicParsing -TimeoutSec 8).StatusCode } Catch { $_.Exception.Message }
    If it still fails, continue.
2) Reset Winsock + TCP/IP and reboot (fixes LSP/stack corruption)
  • In Admin PowerShell / CMD run:
    netsh winsock reset
    netsh int ip reset
    ipconfig /flushdns
  • Reboot the PC.
  • After reboot try browsing and re-run the same Invoke‑WebRequest test above.
3) Check for local proxy environment variables (can break .NET requests)
  • In Admin PowerShell run:
    set | findstr /i proxy
    (or) echo $env:http_proxy; echo $env:https_proxy
  • If you see HTTP_PROXY / HTTPS_PROXY set, remove them or unset in Environment Variables (or run: setx HTTP_PROXY "" /M and setx HTTPS_PROXY "" /M then log off/on).
4) Check hosts file & WinHTTP proxy (you already did winhttp; double‑check hosts)
  • Open Notepad (Admin) → File → Open → C:\Windows\System32\drivers\etc\hosts (All Files view).
  • Ensure the file has no non‑comment lines redirecting domains (especially msftncsi.com, msftconnecttest.com, google.com, etc.). If unsure, take a photo and upload.
5) Confirm no local DNS proxy (127.0.0.1) is in use
  • In Admin PowerShell run:
    Get-DnsClientServerAddress -AddressFamily IPv4
  • If DNS Servers include 127.0.0.1 (or another local address), that indicates a local DNS resolver/agent. If so, identify/uninstall that agent (Cloudflare WARP, DNSFilter, security app). If the DNS Servers are 8.8.8.8 (as your screenshot shows), this step just confirms it.
6) Temporarily disable/uninstall third‑party security, VPN, WARP, or DNS filtering
  • Do you have any of these installed? (Cloudflare WARP, AnyConnect, Cisco, ESET, Sophos, CrowdStrike, DNSFilter, Pi‑hole agent, security suites, etc.) If yes, fully disable or uninstall them, then reboot and test browsing again. Many of these leave a kernel‑level filter even when “off”.
7) Safe Mode with Networking (diagnostic)
  • If the problem persists, boot into Safe Mode with Networking and test the browser. If web works in Safe Mode, a startup app/driver is the culprit — do a Clean Boot to identify it.
If you want me to collect everything for you (so you can upload one file/photo):
  • Say “create diag file” and I’ll give a single command that writes all relevant outputs to C:\Temp\webdiag.txt (ipconfig, Get‑DnsClientServerAddress, Test‑NetConnection, netsh advfirewall, route print, etc.) — then copy that file to a USB or photograph it and upload.
Immediate recommended action (most likely to fix)
1) Run netsh winsock reset, netsh int ip reset, ipconfig /flushdns and reboot.
2) If that doesn’t fix it, fully uninstall any VPN/security/WARP/DNS‑filtering app (temporarily), reboot, then retest.
Tell me:
  • Did you install any VPN/WARP/security apps recently?
  • Run the winsock reset + reboot now and tell me whether browsing/Invoke‑WebRequest starts working (or upload a photo of the Invoke‑WebRequest output and Get‑DnsClientServerAddress after the reboot).
 

Back
Top