ping 192.168.1.1
)netsh winhttp reset proxy
. Proxy settings commonly break outbound internet even though local LAN works.sc query dhcp
and sc query dnscache
net start dhcp
/ net start dnscache
) and test again.All three quick checks passed.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)
Collect these outputs and paste them here if anything fails.
- 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.
- 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.
- 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 diagnostic outputs (paste these)
Quick targeted fixes (safe, do in this order)
- 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.
Advanced checks if the above don’t fix it
- 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.
- 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.- Check Windows services
- Commands:
sc query dhcp
andsc query dnscache
- Both DHCP Client and DNS Client should be RUNNING. If stopped, start them (
net start dhcp
/net start dnscache
) and test again.- 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.
- 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.
If nothing fixes 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.
What I need from you now
- 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.
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.
- 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)
- Tell me whether you have any VPNs, corporate/proxy settings, or third‑party firewall/AV installed.
I cannot browse.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”):
- Open a browser and go to Microsoft – AI, Cloud, Productivity, Computing, Gaming & Apps and https://www.google.com — do pages load?
(If they load, Windows is simply mis-reporting connectivity.)
3) Check NLA / network services and the active probing registry key
- In Command Prompt (Admin) run:
- curl http://www.msftncsi.com/ncsi.txt
- curl http://www.msftconnecttest.com/connecttest.txt
Each should return a short plain text string. If those fail while other sites work, something is blocking Microsoft’s probe URL (hosts file, firewall, or proxy).
If EnableActiveProbing = 0, re-enable it:
- 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.
4) Quick hosts / WinHTTP / firewall checks
- reg add "HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet" /v EnableActiveProbing /t REG_DWORD /d 1 /f
- Reboot.
5) If you want me to verify routing/DNS from the system, paste these outputs:
- 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.
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.
- ipconfig /all
- route print
- netsh interface show interface
- the results of the curl tests above (or copy/paste the error text)
Tell me the results of the browser + curl checks and paste the requested outputs and I’ll give the precise next step.
When I try to temporarily force a known public DNS I get the error:Thanks — that’s helpful. Two quick points before the steps:
Step A — gather a single diagnostic file (run as Administrator)
- “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.
mkdir C:\Temp 2>nul
- Open Command Prompt (Admin).
- Run this block (copy/paste the whole block into the admin prompt). It writes useful outputs to C:\Temp\netdiag.txt:
(
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
Step B — quick tests you can run now (one at a time)
- 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.
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).
- 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.
- 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.
- 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
Step C — quick hosts/proxy/firewall checks (you already did some)
Step D — services / known Windows regression check
- 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.
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.
- 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
If you can’t post text from that PC
What I need next (in order of usefulness)
- 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.
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.
- 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
- Tell me whether forcing DNS=8.8.8.8 (Step B) fixed browsing temporarily.
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.
I Set Google DNS and flushed the cashe but: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)
2) Set Google DNS (recommended method)
- Open PowerShell as Administrator and run:
Get-NetAdapter | Format-Table -Auto- Note the InterfaceAlias (example: "Ethernet" or "Wi‑Fi") you want to change.
(Forum guidance shows both netsh and PowerShell ways to change DNS — the PowerShell method above is less fragile and avoids name/quoting problems. )
- 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
3) If you prefer netsh, make sure the interface name is exact
4) If you need to revert to DHCP later
- 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.
5) If the Set‑DNS command is refused or you still see resolution issues
- PowerShell:
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses- Or netsh:
netsh interface ipv4 set dns name="Ethernet" source=dhcp
Run these checks (copy output to a file or photograph if you can’t paste):
6) Common causes and what to do next
- 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.
7) If you still can’t copy/paste from that PC
- 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.
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.
Get-NetAdapter | Format-Table -Auto > C:\Temp\net2.txt ;
ipconfig /all >> C:\Temp\net2.txt ;
nslookup google.com >> C:\Temp\net2.txt 2>&1 ;
Both nslookup checks pass.Thanks — good details. Two short notes first:
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.
- 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.
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
If you accidentally entered nslookup then typed the full command (and saw “Unrecognized command”), instead do this inside nslookup:
- 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.
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
5) If you still can’t resolve with your configured DNS but can with 8.8.8.8
- 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.
It means either:
6) Quick service & proxy checks
- 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.
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 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 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 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.
I am getting error: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)
Run the three quick tests first (one at a time)
- 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 these from an elevated Command Prompt (right‑click Start → Command Prompt (Admin) or Windows Terminal (Admin)).
1) Test HTTP by IP (bypasses name resolution)
2) Test HTTP(S) by name using PowerShell (non‑interactive):
- 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.
3) Test WinHTTP proxy and DNS client status
- 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.
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:
- 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.
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
B) If both HTTP by IP and HTTP by name fail
- 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.
C) If nslookup to public servers works but browsers still 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.
D) If DNS shows 127.0.0.1 in ipconfig/Get‑DnsClientServerAddress
- 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).
Other helpful steps (safe / reversible)
- 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.
When to do an in‑place repair
- 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.
If you want me to diagnose from the file
- 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.
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
Wrap up / reassurance
- 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.
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?
$_
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).n==== date/time ====
n" | Out-File $Out$
and braces inside a quoted -Command
string called from cmd.exe. Running them in PowerShell (Admin) runs the try/catch and $_
variable correctly.$
inside double quotes: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 callpowershell -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
If you prefer to stick to cmd.exe
- 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.
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 callpowershell -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
If you prefer to stick to cmd.exe
- 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.
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 — the photo helps a lot.
What I see
Interpretation (most likely)
- 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.
Next steps — please run these (Admin PowerShell). You can take photos of the outputs and upload them if you can’t copy/paste.
- 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.
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
Quick troubleshooting you can try now (safe)
- 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.
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.
- 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.
Tell me:
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).
- 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.