The connection does not simply “drop”—one dependency changes state and then recovers
Intermittent failures are difficult because the network may look healthy by the time someone starts testing. The goal is to catch the first dependency that changes during the failure window. That can be a physical link, Wi-Fi association, DHCP state, gateway reachability, route, DNS resolver, VPN session, firewall/NAC role, or application session.
One endpoint, one room, one VLAN, one site, or everyone are different problems
One endpoint
Client adapter, cable, access port, VPN, roaming, power state, local software.
One group
Shared AP, switch, VLAN, trunk, gateway, or policy boundary.
Many users
Shared WAN, edge router, firewall, DHCP, DNS, or provider dependency.
The narrower the affected population, the more careful you should be before changing shared infrastructure.
Intermittent failures become easier when every artifact is tied to time
Record the exact start time, recovery time, affected task, and whether the user moved, connected a VPN, changed rooms, or performed another repeatable action. Then correlate those timestamps with device logs and monitoring.
That timeline moves the failure boundary above ordinary IP reachability.
Time correlation is only useful when the clocks are comparable
A switch may log in local time while a firewall logs UTC and an application uses another time zone. If the clocks are skewed, two events that happened together can appear unrelated. Record time zone and clock offset during the investigation.
A cable movement causes a 5-second drop
If the failure appears when a desk, patch cable, or connector moves, capture switch interface transitions and counters while reproducing the movement safely.
Substitute one component at a time and repeat the trigger. A cable replacement that removes the link transition across repeated tests is much stronger evidence than a reboot that changes many variables.
The link stays up but CRC errors climb during the failures
An interface can remain operational while frames are corrupted. Rising CRC/FCS errors during the complaint window point toward link integrity rather than a DNS or application problem.
Every client behind one access switch loses remote service together
If endpoint access links remain up but every attached client loses remote connectivity at the same instant, inspect the shared uplink and switch-to-distribution path.
A laptop drops for 20–30 seconds only when moving between rooms
Capture AP/BSSID association, band, channel, authentication state, roam timing, retry rate, and gateway probes while walking the same route. A roaming problem should produce evidence close to the transition between access points.
This is much stronger than saying “Wi-Fi is weak.” The artifact identifies the failed transition.
Strong RSSI does not eliminate RF or airtime problems
A stationary client can have strong signal and still suffer intermittent pauses from interference, channel contention, retries, or driver behavior.
The wired control keeps the server and much of the upstream path constant while isolating the wireless access medium.
Periodic addressing events can create repeatable interruptions
Compare the failure interval with DHCP lease timers, client renew/rebind events, scope capacity, and address-conflict logs. A recurring one-hour failure is not proof of DHCP, but the timing can justify capturing DHCP artifacts around that interval.
Competing IP ownership can make connectivity appear to come and go
If the same IPv4 address alternates between two MAC addresses, traffic can reach different devices at different times. Preserve ARP evidence instead of clearing it immediately.
Continuous gateway probes can separate local drops from higher-layer drops
During a recurring failure, run timestamped probes to the default gateway while separately testing a stable remote IP and the actual application.
| Gateway | Remote IP | Application | Stronger boundary |
|---|---|---|---|
| Fails | Fails | Fails | Local attachment/VLAN/gateway path |
| Works | Fails | Fails | Routing/WAN/NAT/firewall |
| Works | Works | Fails | DNS/VPN/proxy/application/session |
Swipe horizontally to see the control matrix.
Resolver failures should line up with name-resolution failures—not just general disconnects
If gateway and remote numeric IP remain healthy while DNS requests time out at the same moments, the resolver path becomes a strong candidate.
VPN rekey or authentication can reset sessions while the Internet remains healthy
A user may report “the network dropped” even though only the secure tunnel failed. Compare ordinary gateway/remote-IP controls with the VPN client log.
If the network controls remain stable, stop calling every session reset a network outage
When link, gateway, remote IP, and DNS are all stable, inspect TCP/TLS resets, application logs, proxy state, load balancer behavior, session expiration, or server-side resource limits.
Route churn can create destination-specific or short-lived loss
If only certain remote networks disappear while local services and other remote destinations remain healthy, inspect route changes for the affected prefix and next-hop state.
The destination-specific control prevents a broad WAN diagnosis.
NAC, firewall, and authentication state can change without a physical link drop
Dynamic network access can depend on session age, identity, posture, or authentication. A device may remain associated and addressed while its permitted role changes.
Recent changes define where to compare first, not what to blame automatically
New cabling, firmware, AP placement, VLAN edits, DHCP options, VPN updates, firewall rules, VM cloning, and power-management settings are useful starting points. But timing alone is not proof. Pair the change with an artifact that changes at the failure boundary.
A regular interval can reveal which subsystem deserves instrumentation
If the failure happens almost exactly every 60 minutes, compare that with lease timers, authentication lifetimes, VPN rekey intervals, scheduled tasks, and automated policy changes. If the failure occurs only during movement, instrument roaming. If it happens only under high load, instrument queueing, errors, and utilization.
Periodic
Lease, authentication, rekey, scheduled automation.
Movement-triggered
Cable movement or wireless roaming.
Load-triggered
Congestion, thermal, queue, or performance state.
Find the earliest column that changes consistently
| Time | Link | IP | Gateway | Remote IP | DNS | App |
|---|---|---|---|---|---|---|
| 10:00 | Up | Valid | OK | OK | OK | OK |
| 10:15 | Up | Valid | OK | OK | Timeout | Fail |
| 10:30 | Up | Valid | OK | OK | OK | OK |
Swipe horizontally to see the recurrence table.
In this example, DNS is the earliest consistently changing checkpoint.
Choose a working path that differs by one important variable
A wired control during Wi-Fi trouble changes the access medium while preserving the client and server. A working peer on the same VLAN changes the endpoint while preserving infrastructure. A second remote destination changes the destination while preserving the source path.
Broad resets can restore service while hiding the cause
A reboot may reset the adapter, renew DHCP, rebuild routes, reconnect Wi-Fi, reauthenticate VPN, and restart application state at the same time. If operational urgency allows, capture logs, counters, route state, ARP, association state, and timestamps before using a broad reset.
Challenge the same trigger or wait through the same recurrence interval
If the old failure happened during roaming, repeat the roam several times. If it happened every hour, monitor across several expected intervals. If it appeared only under backup load, recreate comparable load safely. Verification should attack the original failure mechanism.
Give the next team a timeline and boundary—not “the network is flaky”
Include source, destination, affected scope, exact timestamps, time zone, working controls, failed artifacts, recurrence pattern, suspected boundary, and changes already attempted.
One complaint, three different intermittent mechanisms
“The Internet keeps dropping” can describe at least three completely different failures:
Case A
Gateway probes fail and access port logs link-down events. Boundary: local physical link.
Case B
Gateway and remote IP stay healthy; DNS times out. Boundary: resolver path.
Case C
Gateway, remote IP, and DNS stay healthy; VPN reauth fails. Boundary: VPN/session layer.
The user's wording is identical. The artifacts determine the mechanism.
Similar user complaints create different artifact patterns
“It keeps disconnecting” is not a diagnosis. Compare the exact combination of link state, gateway reachability, remote IP reachability, DNS, and application state. The earliest changing column is usually the most useful boundary.
| Pattern | Likely boundary |
|---|---|
| Link down + gateway fails + app fails | Physical/access layer |
| Link up + gateway fails + remote fails | VLAN/ARP/gateway boundary |
| Gateway stable + remote IP fails | Routing/WAN/NAT/firewall |
| Remote IP stable + DNS fails | Resolver path |
| Gateway/DNS stable + VPN/app resets | Session/application/VPN layer |
Swipe horizontally to see the failure-signature matrix.
Capture where the uncertainty is—not automatically on the client
If the question is whether requests leave the access VLAN, capture near the gateway. If the question is whether the server sees the request, capture at or near the destination. If the question is whether the return path is broken, capture on both sides of the routing boundary. Packet captures are strongest when placed at the first unresolved dependency.
Client sleep and adapter power saving can mimic a network fault
One endpoint may drop after inactivity because the wireless or Ethernet adapter enters a low-power state, the driver resets, or the OS changes radio behavior. A working peer on the same switch or AP makes shared infrastructure less likely.
Verify by changing only the supported power-management setting and repeating the idle interval that previously triggered the drop.
Some intermittent faults appear only under sustained traffic
A transceiver, NIC, access point, or upstream link may behave normally at low load and fail when temperature, utilization, or queue pressure rises. Correlate utilization, errors, temperature, retransmissions, and latency with the exact outage window.
Periodic disconnects can be identity-state problems rather than transport failures
Wireless 802.1X, NAC, VPN, captive portal, and other authenticated access methods can expire or revalidate sessions. If the link remains up and gateway controls stay healthy while authentication logs show failure at the same time, the boundary is no longer the physical or IP layer.
The observation window should match the old failure pattern
A five-minute clean test cannot verify a fault that used to happen every 45 minutes. Likewise, a movement-triggered roaming failure should be verified by repeating the movement, not by leaving the device stationary.
Periodic fault
Observe through several expected recurrence intervals.
Movement fault
Repeat the same roam or cable movement several times.
Load fault
Recreate comparable load and inspect the original counters.
24 Intermittent Network Connection digital flashcards
Practice scope, timestamps, wired link events, CRC errors, wireless roaming, DHCP recurrence, duplicate addresses, gateway controls, DNS, VPN, routing, security state, evidence boundaries, and recurrence-based verification.