Connected but No Internet: A Layer-by-Layer Windows Troubleshooting Guide

“Connected but no internet” is a common support symptom on both Wi-Fi and Ethernet. It does not identify the failed component. A device can have a cable link or be associated with an access point while DHCP, the default gateway, DNS, routing, or another part of the network path is not working.

Troubleshoot from the connection outward. Each check should answer a specific question before you move to the next layer.

Step 1: Check the scope

Ask who and what is affected:

• One user or several users?
• One device or multiple devices?
• One office area?
• Everyone on one Wi-Fi network?
• Everyone on the network?

If a second device fails on the same connection, look upstream. If it works, focus on the original device. This first distinction prevents unnecessary changes.

Also ask about recent changes such as an update, new access point, router change, password change, desk move, VPN, or new security software.

Step 2: Follow the wired or wireless branch

Wired Ethernet

A wired connection depends on the network cable, wall jack, switch port, dock or adapter, network driver, and the services beyond the link.

Start with:

1. Check link lights.
2. Reseat the cable.
3. Try another known-good cable.
4. Try another permitted port.
5. Bypass the dock if possible.
6. Compare with a known-good device on the same connection.

If Ethernet fails through a dock but Wi-Fi works, testing a direct or USB Ethernet connection can help isolate the dock, cable, or switch port.

Wi-Fi

A wireless connection depends on the SSID and password, signal strength, access point, interference, adapter driver, VLAN or SSID mapping, and the same DHCP, gateway, and DNS services used by wired clients.

Start with:

1. Confirm the correct SSID.
2. Check signal strength.
3. Test nearer the access point if appropriate.
4. Disconnect and reconnect, or forget and reconnect when permitted.
5. Compare with another device on the same SSID.
6. Check whether every user on that access point has the same problem.

A device can associate with an access point even when the network behind it is misconfigured. If the issue began after a new AP installation, keep that scenario separate and use the focused new access-point troubleshooting guide.

Step 3: Inspect the Windows IP settings

Run ipconfig or ipconfig /all and identify the active adapter. Check:

• IP address.
• Subnet mask.
• Default gateway.
• DNS servers.
• DHCP status.

If the address begins with 169.254, investigate DHCP first. That result means Windows did not receive normal IP settings; it does not point first to the browser or DNS.

If there is a valid IP but the gateway is missing or incorrect, the device may reach local resources but not outside networks.

Step 4: Test the local gateway with ping

Use ping <gateway> where permitted to test local network reachability.

If it fails, return to the local path:

• For wired clients, check the cable, dock, adapter, port, driver, and VLAN.
• For wireless clients, check the SSID, signal, access point, driver, SSID-to-VLAN mapping, and whether other clients are affected.

A failed ping is a clue rather than final proof. Firewalls may block ping even when a system is available.

Step 5: Test permitted remote reachability

If the gateway responds, test a known internal server or approved external IP address where workplace policy allows it.

This separates local-gateway reachability from a wider routing or upstream problem. If local traffic works but remote traffic fails, the issue may sit beyond the client and its immediate connection.

Step 6: Test DNS with nslookup

Use nslookup with an allowed website or internal service name. This asks whether DNS can translate the name into an IP address.

If IP connectivity works but a name does not resolve, DNS may be part of the problem. nslookup tests name resolution; it does not by itself prove that the full internet connection works.

Do not change DNS immediately when the device has no valid IP address or gateway. Those earlier layers need attention first.

Step 7: Use tracert when the route matters

tracert shows the path traffic attempts to take to a destination. It can help when the local gateway works but a remote system does not.

Some hops may time out because devices do not reply to trace requests. Look for useful patterns rather than expecting every hop to respond.

Step 8: Compare, document, and escalate

Compare the result with a known-good device on the same cable, desk, SSID, access point, or VLAN.

Record:

• Who and what are affected.
• Wired or wireless connection.
• Active adapter and IP settings.
• Gateway, ping, DNS, and route results.
• Known-good comparisons.
• Recent changes.

If several users or a shared network segment are affected, escalate with this evidence rather than continuing to change one device.

What each command tells you

• ipconfig /all: Whether Windows has usable IP, gateway, DNS, DHCP, and adapter information.
• ping: Whether a permitted target replies; failure may also reflect firewall policy.
• nslookup: Whether DNS resolves a name.
• tracert: Which route traffic attempts to take and where replies stop appearing.

These commands provide clues, not automatic conclusions. Run each one with a question in mind.

Common mistakes

• Assuming “connected” means the complete path is healthy.
• Changing DNS before checking IP and gateway information.
• Treating wired and wireless connections as identical physical paths.
• Assuming failed ping proves a destination is offline.
• Restarting workplace network equipment without permission.
• Troubleshooting one laptop for too long when every user on the same access point is affected.

FAQ

Should I restart the router first?

Not in a workplace unless you have permission. Gather scope and evidence first.

Can DNS cause a connected-but-no-internet symptom?

Yes. If IP connectivity works but names do not resolve, DNS can make the connection appear broken.

Can a VPN cause the problem?

Yes. VPN clients can affect routes, DNS, and network access, so include recent VPN changes in the initial questions.

Which command should I run first?

Start with ipconfig or ipconfig /all, then choose the next test based on the IP settings and the layer you need to check.