Wi-Fi tickets are dangerous because everyone says the same thing: “the internet is down.” That might mean weak signal, bad DHCP, DNS weirdness, captive portal nonsense, a blocked device, a dead access point, VPN issues, or one laptop clinging to the wrong network like it owes it money.

The short version: prove whether the problem is signal, device, network, or service. Do not reboot every access point because one person in the conference room has two bars. Start with scope, compare against a known-good device, then move through signal, association, IP address, DNS, captive portal, VPN, and access point health.

This checklist is for help desk and junior IT support work. It is not a full wireless engineering survey. It is the practical flow you use when a user cannot stay connected, cannot get internet after connecting, or says Wi-Fi is “slow” with no other details.

Pair this with the senior IT troubleshooting methodology, the VPN troubleshooting checklist, and the networking basics guide if you are using this as study practice.

Wi-Fi triage: identify the failure lane

Do not start in adapter settings. Start by naming the lane.

What the user saysFirst lane to check
”I cannot see the network”SSID visibility, adapter, range, policy
”It asks for a password again”Saved profile, password change, authentication
”It connects but says no internet”DHCP, gateway, DNS, captive portal
”It works for everyone except me”Device, driver, profile, account, MAC filtering
”Everyone in this room has issues”Access point, signal, interference, switch uplink
”Only VPN is broken on Wi-Fi”VPN route, DNS, captive portal, firewall, split tunnel
”It drops during calls”Roaming, signal quality, congestion, headset/CPU, Teams/Zoom path

The goal is to stop treating Wi-Fi as one giant fog machine. Pick the lane, then test that lane.

Step 1: Scope the problem before touching settings

Ask five boring questions. Boring questions save tickets.

  1. Is it one user, one device, one room, one SSID, or everyone?
  2. Did it ever work on this device and network?
  3. Does another device work from the same spot?
  4. Does the problem follow the user to another location?
  5. Is the issue Wi-Fi only, or does wired Ethernet fail too?

If one laptop fails while a phone works from the same desk, you probably have a device or profile problem. If multiple users fail in the same room, suspect the access point, switch port, VLAN, DHCP scope, interference, or a building issue.

Write the scope in the ticket. “Wi-Fi bad” is useless. “Three users in conference room B connect to CorpWiFi but receive 169.254 addresses” is evidence.

Step 2: Check signal without worshipping the bars

Signal bars are a clue, not a verdict. Two devices can show different bars in the same spot because of antenna design, driver behavior, band selection, and how optimistic the vendor felt that morning.

Still, start with the obvious:

  • Move closer to the access point or a known-good area.
  • Check whether the device is on 2.4 GHz or 5/6 GHz if your tools show it.
  • Look for common interference sources: microwave areas, crowded conference rooms, thick walls, metal shelving, elevators, and cheap USB docks.
  • Compare the failing device against a known-good device in the same location.
  • Ask whether the issue happens only during meetings, only at one desk, or only when the laptop is docked.

For help desk triage, you are not trying to design the wireless network. You are deciding whether this is a support ticket, an endpoint fix, or an escalation to the network team.

Step 3: Forget and rejoin the network when the profile is suspect

Saved wireless profiles go stale. Passwords change, certificates expire, SSIDs get migrated, and laptops keep trying the old thing because computers are very loyal to bad ideas.

Use this when the device sees the SSID but fails to connect, asks for credentials repeatedly, or works on other networks:

  1. Forget the network.
  2. Reboot only if the adapter is acting stuck, not as a ritual.
  3. Rejoin the correct SSID.
  4. Confirm the user is entering the current credentials.
  5. If enterprise Wi-Fi is used, verify the user’s account is active and allowed.
  6. If certificates are involved, check certificate validity and device compliance status.

On Windows, netsh wlan show profiles can show saved profiles. Do not delete every profile unless you understand what the device needs. Nuking all wireless settings may fix one ticket and create three new ones.

Step 4: Confirm the device received a real IP address

If the device connects but has no internet, check the IP configuration next.

Look for:

  • A valid IP address for the expected Wi-Fi network.
  • A default gateway.
  • DNS servers.
  • No 169.254.x.x APIPA address.
  • No weird static IP left over from a lab, hotel, or previous job.

On Windows, run:

ipconfig /all

Then test in this order:

ping <default-gateway>
ping 8.8.8.8
nslookup thisisanitsupportgroup.com

If the device cannot ping the gateway, stay local: signal, VLAN, access point, adapter, or network assignment. If it can ping an external IP but DNS fails, stop blaming Wi-Fi and check name resolution. The DNS troubleshooting guide is the next stop.

If the device gets a 169.254 address, DHCP probably failed or the device cannot reach the DHCP server. The DHCP guide explains the basics without turning it into packet-capture cosplay.

Step 5: Watch for captive portal and guest Wi-Fi traps

Guest Wi-Fi can look connected while blocking everything until the user accepts terms, enters a code, or gets redirected through a portal that the browser quietly hates.

Check for:

  • A captive portal page that did not open automatically.
  • DNS blocked until portal sign-in completes.
  • HTTPS redirects failing because the browser is trying to protect the user.
  • Guest network client isolation blocking printers, file shares, or internal apps.
  • Time/date wrong on the device, breaking certificate checks.

Quick test: open a plain HTTP site such as http://neverssl.com if your environment allows it. That often triggers the portal. If this is corporate guest Wi-Fi, also verify whether internal resources are supposed to work. Many guest networks intentionally block them.

Step 6: Separate Wi-Fi problems from VPN problems

A lot of “Wi-Fi” tickets are actually VPN tickets wearing a tiny fake mustache.

Ask:

  • Does normal browsing work before connecting VPN?
  • Does the issue begin only after VPN connects?
  • Does the user have the same problem on a hotspot?
  • Are internal resources failing while public sites work?
  • Is DNS changing after VPN connects?

If browsing works off VPN but internal tools fail on VPN, use the VPN troubleshooting checklist. Do not keep toggling Wi-Fi if the wireless path is already proven.

Step 7: Check adapter, driver, and power settings when one device keeps dropping

If one laptop drops repeatedly while nearby devices stay connected, check the endpoint.

Good first moves:

  • Disable and re-enable the Wi-Fi adapter.
  • Install pending vendor network driver updates.
  • Remove old wireless profiles for retired SSIDs.
  • Check power management settings that allow Windows to turn off the adapter.
  • Test with docking station disconnected.
  • Test from another user profile if policy or profile corruption is suspected.
  • Review Event Viewer for WLAN-AutoConfig events around the drop time.

This is where the Windows Event Viewer troubleshooting checklist helps. You are looking for repeated disconnect reasons around the actual time of failure, not every warning Windows has collected since the laptop was born.

Step 8: Escalate cleanly when it looks like access point or network trouble

Escalation is not failure. Bad escalation notes are failure.

Escalate to the network team when you can show one of these patterns:

  • Multiple users fail in the same location.
  • Devices connect but receive no DHCP lease.
  • Devices receive IP addresses from the wrong VLAN.
  • The SSID disappears in one area but works elsewhere.
  • Roaming fails between access points.
  • Speeds collapse only in one room or during busy periods.
  • Wired network works but the same subnet over Wi-Fi does not.

Include the useful evidence:

EvidenceExample
Scope”Four users affected in room 214, CorpWiFi only”
Time”Started around 9:20 AM after morning meeting began”
Device comparison”Known-good laptop also fails from same seat”
IP info”Client receives 169.254 address, no gateway”
SSID/BSSID if available”Connected to CorpWiFi, AP ending A4:19”
Tests run”Forgot/rejoined network, tested gateway ping, compared hotspot”

That gives the network team something to work with instead of a haunted ticket that says “wireless unstable.”

Quick Wi-Fi troubleshooting checklist

Use this when the queue is busy and you need the fast version:

  • Confirm one user vs many users.
  • Compare with a known-good device in the same location.
  • Confirm the correct SSID.
  • Check signal/location pattern.
  • Forget and rejoin if the saved profile may be stale.
  • Confirm valid IP, gateway, and DNS.
  • Test gateway ping, external IP ping, and DNS lookup.
  • Check captive portal if on guest/public Wi-Fi.
  • Disconnect VPN and retest normal browsing.
  • Update/check adapter driver if only one device drops.
  • Gather scope, time, location, IP details, and tests before escalation.

FAQ

Why does Wi-Fi connect but say no internet?

Usually the device associated to the access point but cannot reach something needed after that: DHCP, gateway, DNS, captive portal, firewall, or upstream internet. Start with IP configuration, then gateway ping, then external IP, then DNS.

Should help desk reboot the access point?

Not as a first move. If one user has trouble, prove scope first. Rebooting an access point can kick working users offline and hide evidence. Escalate with details unless your runbook specifically allows AP reboots.

Is 2.4 GHz or 5 GHz better for troubleshooting?

Neither is automatically better. 2.4 GHz can travel farther but is crowded. 5 GHz is usually faster and cleaner but has shorter range. Your job is to compare behavior by location and device, not memorize one magic band.

What should I document in a Wi-Fi ticket?

Document user, device, SSID, location, whether others are affected, IP/gateway/DNS results, whether VPN changes the symptom, what fixed it, and whether it needs network escalation. Future-you deserves nice things.

Next step

If you are studying for help desk work, practice this flow on your own laptop: connect to Wi-Fi, inspect IP settings, identify your gateway and DNS servers, and explain what each test proves. Then read the Network+ study guide alternatives if you want more scenario-based network practice.

Want practical IT career and troubleshooting notes without the corporate wallpaper paste? Join the IT Support Group newsletter and keep building the kind of support instincts that make tickets less awful.