Connected but No Internet? A 169.254 Address Points to DHCP, Not a Dead Laptop

A 169.254 address usually means the device could not obtain a normal IPv4 lease. Use this home and small-business DHCP decision tree before resetting the router, entering a random static address, or replacing working hardware.

Reader ratingRate this article

Loading reader rating…

Privacy-conscious voting uses a signed random browser identifier and a short-lived network hash; the rating tables contain no raw IP-address column.

Reader ratings require JavaScript; the article remains fully readable without it.

When Wi-Fi says “Connected” but the device has an IPv4 address beginning with 169.254, the wireless radio may be working while address assignment is not. Microsoft says Windows uses an Automatic Private IP Addressing (APIPA) address in the 169.254.0.0/16 range when a DHCP-configured client cannot obtain a normal IPv4 address. That is a troubleshooting clue—not proof that the laptop, Wi-Fi card, router, or internet service is dead. [1] [2]

Research checked: September 22, 2026. The safe sequence is to preserve network settings, determine whether one device or an entire segment is affected, verify the physical/Wi-Fi path, renew only after documenting the current lease, and move upstream to DHCP service, pool, VLAN, relay, and static-address checks.

The problem in plain English

Most home and small-business devices ask a DHCP service for an IPv4 address, subnet mask, default gateway, and DNS information. Microsoft describes the normal exchange as Discover, Offer, Request, and Acknowledgement. If that exchange does not complete, a Windows client can fall back to APIPA. Devices with only link-local addresses may communicate with certain neighbors on the same local segment, but they do not receive the ordinary gateway information needed for normal routed network access. [1] [2]

The costly mistake is to factory-reset the router, replace the computer, or type a random static address before locating the failed handoff. Microsoft’s server checklist includes exhausted scopes, unauthorized or stopped DHCP service, bad-address entries, unexcluded static addresses, incorrect bindings, blocked UDP ports, and relay problems. Cisco Meraki likewise lists an offline or misconfigured server, an exhausted pool, reservation mistakes, and missing DHCP traffic as common causes. [4] [7]

Stop before these expensive shortcuts

  • Do not factory-reset the router or firewall unless you have its current configuration, credentials, ISP settings, VLANs, VPNs, reservations, and a tested restoration plan.
  • Do not copy another device’s IPv4 address or invent one. A manual address must match the intended subnet, gateway, DNS, exclusion/reservation design, and conflict controls. Apple distinguishes DHCP from manual addressing and directs users to enter manual values only when supplied by the ISP or administrator. [6]
  • Do not disable APIPA in the registry as a repair. Removing the fallback symptom does not restore DHCP.
  • Do not release a working remote computer’s lease unless you have local or out-of-band access. A failed renewal can strand the session.

Who this guide is for—and who needs a different path

Covered here

  • Windows shows a 169.254.x.x IPv4 address or “Unidentified network.” [2]
  • A Mac or other client is connected to Wi-Fi or Ethernet but cannot obtain or renew a DHCP lease. [5]
  • New devices fail while existing devices still work, suggesting a pool, VLAN, relay, reservation, or client-specific problem. [4] [8]
  • Home and small-business networks where the owner can inspect—but not blindly erase—the router or DHCP service.

Use another path

  • The device has a normal address and gateway but websites alone fail; test DNS, routing, captive portal, VPN, proxy, and upstream service instead.
  • Wi-Fi is weak, slow, or dropping before association; use our interference and coverage guide. [10]
  • Remote access broke after a router change but local DHCP works; check double NAT or CGNAT. [11]
  • A managed enterprise, medical, industrial, or life-safety network requires its authorized network team and change controls.

First: read the address without publishing it

On Windows, open Settings → Network & internet → Wi-Fi or Ethernet → Hardware properties, or use ipconfig /all locally. Record the adapter name, IPv4 address, subnet mask, default gateway, DHCP enabled state, DHCP server, DNS servers, and lease times. Microsoft recommends examining client settings, event logs, adapter state, driver, DHCP Client service, and whether UDP ports 67 and 68 are blocked. [3]

On a Mac, open System Settings → Network → the active service → Details → TCP/IP. Apple documents both “Using DHCP” and manual modes and provides a Renew DHCP Lease control. [5] [6]

Do not post full screenshots containing Wi-Fi names, public IPs, device names, MAC addresses, VPN information, or customer network details. For support, share only the minimum needed through a trusted channel.

On a phone, swipe sideways to read the full table.

Evidence What it suggests Next branch
169.254.x.x, no ordinary gateway The Windows client did not obtain a normal DHCP IPv4 lease and used APIPA. [1] [2] Compare affected scope, then check client path and DHCP availability.
One device fails; neighbors on the same network work Client adapter, saved network, cable, driver, service, filtering, or reservation may be involved. Microsoft’s client checklist starts with cables, adapter, driver, service, filtering, and ports. [3] Follow Steps 2–4 before changing infrastructure.
New devices fail; already-connected devices work An exhausted address pool or lease/reservation problem becomes more plausible. Microsoft says to verify available leases; Meraki identifies an exhausted pool as a common DHCP failure. [4] [8] Administrator checks scope utilization and lease design.
Every device on one SSID or VLAN fails The DHCP server, relay, VLAN path, tunnel, or scope for that segment may be unavailable or misconfigured. [1] [8] Move upstream; do not keep resetting endpoints.
Normal address and gateway, but no internet DHCP completed; the fault may be DNS, routing, firewall, captive portal, VPN, or ISP. Test gateway reachability and name resolution separately.

The eight-step troubleshooting ladder

1

Define the blast radius

Test one known-good device on the same connection type and network. Then compare Wi-Fi versus Ethernet, employee versus guest network, and one room/access point versus another. If only one client fails, stay client-side. If all new clients fail while old leases survive, inspect pool availability. If an entire SSID or VLAN fails, escalate to the network path and DHCP service. [4] [8]

Record the time and what changed: router restart, switch replacement, new access point, VLAN change, server reboot, firewall update, VPN outage, or sudden influx of guest devices.

2

Verify link before blaming DHCP

Check the Ethernet cable and link lights, reconnect the cable at both ends, and try a known-good cable or port only if authorized. For Wi-Fi, confirm the correct SSID, remove airplane mode, and verify that the client actually associates. Microsoft’s client checklist begins with cable, adapter, driver, service, filtering, and firewall checks. [3]

A connected Wi-Fi icon proves radio association—not a successful DHCP lease, gateway, DNS, or internet path.

3

Preserve the current settings

Before forgetting a network, resetting an adapter, or renewing a lease, save the current adapter details. On a managed device, confirm whether IPv4 should use DHCP and whether VPN, security, or device-management software controls the adapter. Do not remove a corporate profile or certificate to fix a home-style network symptom.

If IPv4 is set manually without documentation, stop and ask the network owner. Apple’s guidance makes the boundary clear: use DHCP for automatic assignment; use manual settings when the ISP or administrator supplied the values. [6]

4

Renew once—then read the result

On Windows, after recording the current state and ensuring local access, disable/re-enable the adapter or use the supported release/renew workflow. Microsoft’s DHCP client guidance uses ipconfig /release and ipconfig /renew while collecting client/server evidence. [3]

On Mac, use Renew DHCP Lease in TCP/IP settings; Apple says renewing can resolve connection issues in some environments. [5] If the client immediately returns to 169.254, repeated renewals are not a strategy. Move to the next branch.

5

Check the local client branch

  • Try the same cable/port with a known-good device, or the same client on a known-good authorized network.
  • Verify the network adapter is enabled, its driver is current, and the DHCP Client service is running. [3]
  • Check whether MAC filtering, endpoint firewall, VPN software, or a security agent is blocking the required path. Microsoft calls out client UDP ports 67 and 68. [3]
  • Forget and rejoin Wi-Fi only after confirming the password and any enterprise authentication requirements.

If one client fails on multiple known-good networks, the adapter, driver, security stack, or device policy deserves attention. If many clients fail only on one network, stop rebuilding endpoints.

6

Check the DHCP service and pool

For a home router, verify DHCP is enabled, the LAN scope has free addresses, and the router did not lose its LAN settings after an update or reset. For Windows Server, Microsoft says to verify that the service is running and authorized, leases are available, bad-address entries are understood, static devices are excluded appropriately, bindings are correct, and no other service occupies the DHCP ports. [4]

Do not delete all leases merely to create movement. Identify active clients, lease duration, exclusions, reservations, guest-device growth, and whether a smaller subnet is still appropriate. Meraki recommends checking for pool exhaustion and increasing the pool when needed; in wireless environments it also identifies short leases, unreachable servers, and incorrect VLAN tags as relevant branches. [7] [8]

7

Trace VLAN, relay, and server reachability

When clients and DHCP service sit on different logical segments, a relay or IP helper must carry the broadcast exchange. Microsoft describes the relay’s role in forwarding DHCP traffic between segments. Meraki notes that a bridge-mode SSID depends on reaching the local DHCP server and can fail after a site, tunnel, firewall, or VLAN change. [1] [8]

A packet capture can show whether Discover leaves the client, Offer returns, Request follows, and Acknowledgement reaches the client. Microsoft and Meraki both use capture evidence to locate the missing stage. [1] [8] Capture only with authority and protect network identifiers.

8

Fix the owner—not just the symptom

If the pool is exhausted, resize the authorized pool or shorten lease duration only after evaluating subnet capacity and client behavior. If a static device conflicts with the pool, move it to a documented reservation or an excluded address rather than giving every endpoint a manual address. Our stable-address guide explains the reservation pattern for printers and cameras. [9]

After the fix, reconnect a test client, confirm a normal address, subnet mask, gateway, DNS, and lease, then test the gateway, a known public address, and a DNS name separately. Document the cause, changed setting, rollback, and remaining capacity.

Good diagnosis versus costly guessing

Good

  • Record the client address, gateway, DHCP state, and time before changes.
  • Separate one-device, new-device, and whole-segment failures.
  • Renew once and use the result as evidence. [3] [5]
  • Check free leases, service state, exclusions, bindings, VLANs, and relay. [4] [8]
  • Use a reservation for infrastructure that needs a stable address. [9]

Bad

  • Factory-reset the router without a configuration backup.
  • Copy a coworker’s address or enter a random gateway.
  • Disable APIPA so the clue disappears.
  • Release the lease on a remote-only machine with no recovery path.
  • Rebuild every laptop when one SSID, VLAN, relay, or pool is failing.

Two realistic examples

One laptop after a desk move

A Windows laptop shows 169.254.x.x on Ethernet, but the neighboring computer works. The technician records the adapter details, swaps in a known-good cable, and finds the original wall port was patched to the wrong VLAN. The laptop receives a normal lease after the authorized switch-port correction. No operating-system reset or random static address was needed.

Guest devices fail after an event begins

Staff devices with existing leases work, but new guest phones cannot get online. The administrator finds the guest DHCP pool exhausted after attendance exceeded the design. They verify active leases and subnet policy, expand the authorized pool with rollback, reconnect a test client, and document new capacity. Microsoft and Meraki both direct administrators to verify available addresses in the relevant scope. [4] [8]

Frequently asked questions

Does 169.254 mean my Wi-Fi card is broken?

No. It means the client is using an APIPA address because it did not obtain a normal DHCP IPv4 lease. The radio, cable, adapter, driver, filter, DHCP service, pool, VLAN, relay, or upstream path could be responsible. [1] [2]

Can two APIPA devices talk to each other?

Microsoft says APIPA can support communication with other devices on the same LAN that also use compatible 169.254.x.y addressing and the link-local mask. That limited local communication does not prove the normal gateway, DNS, or routed network is available. [2]

Should I type a static address to get online?

Not unless the network owner or ISP provides the correct values and the address is documented outside the DHCP pool or properly reserved. A guessed address can conflict with another device or land on the wrong subnet. Apple’s guidance says manual values should come from the ISP or administrator. [6]

Why do old devices work while new ones fail?

Existing clients may still hold leases while the DHCP scope has no address available for newcomers. Pool exhaustion is one important branch, but reservations, filtering, VLAN assignment, and relay behavior also need verification. [4] [8]

Will rebooting the router fix it?

It may temporarily restart a failed service, but it can also erase evidence and interrupt working devices. Define the blast radius, capture settings, and verify pool/service state first. Avoid a factory reset unless you have a configuration backup and a restoration plan.

What if I have a normal address but no internet?

Then DHCP may have completed. Test the local gateway, DNS resolution, routing, captive portal, VPN/proxy, firewall, and ISP separately. Do not keep renewing a valid lease when the failure is farther upstream.

Related The IT Guys guides

Actionable next steps

  1. Record the affected adapter’s IPv4 address, gateway, DHCP state, and lease details.
  2. Determine whether one device, new devices, or an entire SSID/VLAN is affected.
  3. Verify cable/Wi-Fi association, adapter, driver, DHCP Client service, filtering, and required ports. [3]
  4. Renew once after preserving settings; if 169.254 returns, stop repeating and move upstream. [3] [5]
  5. Check DHCP service, available leases, reservations, exclusions, bindings, VLAN tags, and relay reachability. [4] [8]
  6. Do not factory-reset or enter a random static address.
  7. After correction, verify a normal lease, gateway, DNS, and routed access; document cause and capacity.

Need help finding the missing address handoff?

Practical referral: if a Treasure Coast home or small business has devices stuck on 169.254 or connected without usable network access, contact The IT Guys. Bring the device type, connection method, affected scope, router/firewall model, time the issue began, and a privacy-trimmed view of the adapter details. Never send passwords or a full network export.

Sources

  1. Microsoft Learn — Troubleshooting guide for DHCP (checked September 22, 2026).
  2. Microsoft Learn — How to use automatic TCP/IP addressing without a DHCP server (checked September 22, 2026).
  3. Microsoft Learn — Troubleshoot problems on the DHCP client (checked September 22, 2026).
  4. Microsoft Learn — Troubleshoot problems on the DHCP server (checked September 22, 2026).
  5. Apple Support — Renew your IP address from the DHCP server on Mac (checked September 22, 2026).
  6. Apple Support — Use DHCP or a manual IP address on Mac (checked September 22, 2026).
  7. Cisco Meraki Documentation — Troubleshooting DHCP and DNS issues (checked September 22, 2026).
  8. Cisco Meraki Documentation — Wireless issue resolution guide (checked September 22, 2026).
  9. The IT Guys — Printer or Camera Keeps Going Offline? Fix Its IP Address Without Creating a Conflict.
  10. The IT Guys — Wi-Fi Fast by the Router but Slow Elsewhere?.
  11. The IT Guys — Remote Access Broke After a Router Upgrade?.

Scope: General DHCP and APIPA diagnosis for ordinary home and small-business clients. Network design, VLANs, relays, authentication, lease policies, static-address plans, and safe change procedures vary. When the live network documentation or authorized administrator conflicts with this guide, preserve state and follow the controlled procedure.