No Internet? Is It DHCP, DNS, or the Default Gateway?

No internet? Run ipconfig /all and stop at the first clue. A 169.254.x.x address points to DHCP. A blank default gateway points to IP or DHCP configuration. If the gateway cannot be reached, stay on the local network path. If an IP works but a hostname does not, check DNS.

Start with the settings Windows received

Run one command to inspect the active network adapter:

ipconfig /all

Find the adapter actually in use, then check its IPv4 address, subnet mask, default gateway, DNS servers, and whether DHCP is enabled.

Dynamic Host Configuration Protocol (DHCP) usually gives a client all four settings it needs: an IP address, subnet mask, default gateway, and DNS server addresses. DHCP may run on a router, firewall, or server, but the client only needs to receive a valid set of values.

If the address starts with 169.254, Windows has assigned an Automatic Private IP Addressing (APIPA) address because normal DHCP settings did not arrive. Do not troubleshoot DNS yet. Check the cable or Wi-Fi connection and whether another device on the same network receives a valid address. The focused APIPA guide covers that path without repeating it here.

A normal-looking IP address with no default gateway is also a stop sign. The device may still reach systems on its local subnet, but it normally cannot reach the internet or another network. Check for an incomplete DHCP lease or incorrect static settings.

Can the device reach its way out?

The default gateway is the router or firewall used to send traffic beyond the local subnet. Copy its address from ipconfig /all, then test the local path:

ping <default-gateway>

A reply shows that the adapter can reach the gateway. Move on to an approved remote IP test.

If the gateway does not reply, stay local. Compare another device on the same cable, Wi-Fi network, or VLAN, then check the adapter, dock, cable, access point, switch port, and gateway path as appropriate. Some networks block ping, so a timeout is a clue to compare, not proof that the gateway is offline.

Does the path work without DNS?

If your environment allows it, test a known remote IP address. This asks whether traffic can leave the local network without relying on a name:

ping <approved-remote-IP>

If the gateway replies but the remote IP does not, DNS is not the first suspect. Compare another device. One-device failures can involve a VPN, local firewall, or route; several-device failures point toward the router, internet service, or another shared upstream path.

If the remote IP replies, test a permitted hostname directly:

nslookup <hostname>

Domain Name System (DNS) turns hostnames into IP addresses. If the remote IP works but nslookup times out or returns an error, check the DNS server addresses in ipconfig /all and compare them with a working device. If nslookup returns an address, DNS answered; the remaining problem may be limited to a website, browser, proxy, VPN, or policy.

Use the scope to choose the next check

One affected device usually keeps the focus on that device or connection. Several devices with 169.254 addresses point to a shared DHCP or network-path problem rather than one Windows device. Several devices that can reach the gateway but not a remote IP point farther upstream.

For a full connection-by-connection workflow, use the connected-but-no-internet Windows guide. After any fix, repeat the check that failed first. That result is better evidence than the Windows “Connected” label.