Packet loss is one of the most common—and sometimes most difficult—network problems to diagnose. It can cause slow browsing, interrupted downloads, frozen Remote Desktop sessions, poor VoIP calls, video conferencing problems, gaming lag, VPN disconnections, application timeouts, and unreliable communication between computers and servers.

A connection may even show a high Internet speed while still performing poorly because bandwidth and packet reliability are different measurements.

For example, a 500 Mbps Internet connection suffering from intermittent packet loss may feel considerably worse than a stable 50 Mbps connection.

This guide explains what packet loss is, how to identify where it is occurring, which Windows commands and diagnostic tools can help, and how to determine whether the problem originates from your computer, LAN, Wi-Fi, router, ISP, VPN, or remote server.

1. What Is Packet Loss?

Network communication is normally divided into small units of data called packets.

These packets travel through multiple network devices before reaching their destination.

A typical Internet connection may follow a path similar to:

Computer → Network Adapter → Ethernet/Wi-Fi → Switch → Router → ISP → Internet Routers → Destination Server

The destination then sends packets back through a return path.

Packet loss occurs when some packets fail to reach their intended destination.

For example:

Packets Sent:     100
Packets Received: 97
Packets Lost:     3

Packet loss is:

3%

The basic calculation is:

Packet Loss % = (Lost Packets / Sent Packets) × 100

Ideally, a healthy wired network should normally show:

0% packet loss

Occasional ICMP loss alone does not always prove that application traffic is being lost because some routers and servers intentionally deprioritize or block ping traffic. Therefore, packet-loss results must always be interpreted in context.

2. Common Symptoms of Packet Loss

Packet loss can appear in many different ways.

Common symptoms include:

• Websites loading partially or slowly
• Downloads stopping unexpectedly
• Uploads failing
• Remote Desktop freezing
• RDP sessions disconnecting
• VPN connections dropping
• VoIP calls breaking up
• Robotic or distorted voice
• Video conferencing freezing
• Online games lagging
• Cloud applications becoming unresponsive
• File transfers failing
• Network drives disconnecting
• Tally or other network applications becoming unstable
• "Request Timed Out" during ping
• Sudden latency spikes
• Intermittent Internet connectivity

Because these symptoms can also have other causes, packet loss should be measured rather than assumed.

3. What Causes Packet Loss?

Packet loss can occur at almost any point in the network path.

Common causes include:

Physical network problems

Examples include:

• Damaged Ethernet cable
• Loose RJ45 connector
• Poor cable termination
• Damaged network socket
• Faulty patch panel
• Defective switch port
• Faulty router port
• Bad USB-to-Ethernet adapter

Wireless problems

Wi-Fi packet loss can result from:

• Weak signal
• Distance from access point
• Walls and physical obstacles
• Channel congestion
• Radio interference
• Too many connected devices
• Poor access-point placement
• Driver problems

Network congestion

If network devices or links become overloaded, packets may be dropped.

Examples include:

• Large downloads
• Cloud backup
• Windows updates
• CCTV uploads
• File synchronization
• Torrent traffic
• Large file transfers
• Multiple simultaneous video calls

Hardware problems

Faulty equipment may cause intermittent packet loss.

Examples:

• Router
• Switch
• Network adapter
• Access point
• Modem/ONT
• SFP module
• Fiber media converter

Configuration problems

Examples include:

• Incorrect MTU
• Speed/duplex mismatch
• Faulty QoS rules
• VLAN configuration errors
• Firewall rules
• VPN configuration
• Routing loops

ISP problems

Packet loss may occur outside your premises due to:

• ISP congestion
• Fiber issues
• Wireless backhaul problems
• ISP router failure
• Routing problems
• Peering congestion
• International routing problems

4. Understand Latency, Jitter and Packet Loss

These three measurements are related but different.

Latency

Latency measures how long a packet takes to reach its destination.

For example:

Reply from 8.8.8.8: time=18ms

Lower latency is generally better.

Jitter

Jitter is the variation in latency.

For example:

18 ms
20 ms
19 ms
95 ms
17 ms
110 ms

Large variations can cause problems for real-time applications.

Packet Loss

Packet loss means packets are not successfully reaching the destination or returning.

For example:

Packets: Sent = 100, Received = 95, Lost = 5

That represents:

5% packet loss

5. Start with a Continuous Ping Test

On Windows, open:

Command Prompt

Run:

ping 8.8.8.8 -t

You may see:

Reply from 8.8.8.8: bytes=32 time=20ms TTL=117
Reply from 8.8.8.8: bytes=32 time=21ms TTL=117
Request timed out.
Reply from 8.8.8.8: bytes=32 time=19ms TTL=117

The timeout may indicate packet loss.

Stop the test with:

Ctrl + C

Windows will display statistics similar to:

Packets: Sent = 100, Received = 99, Lost = 1 (1% loss)

However, do not diagnose the network from one public ping target alone.

6. The Most Important Test: Find Where Packet Loss Starts

A better troubleshooting method is to test the network layer by layer.

Test:

1. Local computer
2. Default gateway
3. ISP
4. Public Internet
5. Destination server

This helps isolate the failure.

7. Step 1 – Ping the Loopback Address

Run:

ping 127.0.0.1

This tests the local TCP/IP stack.

You should normally receive:

0% loss

If this fails, investigate the local Windows networking configuration.

8. Step 2 – Find Your Default Gateway

Run:

ipconfig

Find:

Default Gateway

Example:

IPv4 Address . . . . . . : 192.168.1.100
Default Gateway . . . .  : 192.168.1.1

Now continuously ping the router:

ping 192.168.1.1 -t

If packet loss occurs here, the problem is likely inside the local network.

Possible causes include:

• Wi-Fi interference
• Ethernet cable
• Switch
• Router LAN interface
• NIC
• Network driver
• Local congestion

Do not immediately blame the ISP if packets are already being lost between the computer and local gateway.

9. Step 3 – Test a Public IP Address

Run:

ping 8.8.8.8 -t

You can also test another independent destination.

For example:

ping 1.1.1.1 -t

Suppose:

Gateway = 0% loss
8.8.8.8 = 5% loss

This strongly suggests the problem exists beyond your local LAN.

Possible areas include:

Router WAN
↓
ONT/modem
↓
ISP
↓
Upstream Internet

10. Step 4 – Test DNS Separately

Sometimes users describe a DNS problem as packet loss.

Try:

ping 8.8.8.8

Then:

ping google.com

If IP communication works but domain-name access fails, investigate DNS rather than assuming general packet loss.

Check DNS configuration with:

ipconfig /all

You can also test name resolution:

nslookup google.com

11. Use a Longer Ping Test

Four ping packets are not enough for diagnosing intermittent problems.

Run:

ping 8.8.8.8 -n 100

For a longer test:

ping 8.8.8.8 -n 500

At the end, Windows provides packet statistics.

Example:

Packets: Sent = 500, Received = 495, Lost = 5

Packet loss:

1%

Longer tests are particularly useful for intermittent network problems.

12. Test Multiple Destinations

Never depend on one server.

Test several destinations such as:

ping 192.168.1.1 -n 100
ping 8.8.8.8 -n 100
ping 1.1.1.1 -n 100

You can also test the actual server or service experiencing problems.

This helps distinguish between:

Local packet loss
ISP packet loss
Destination-specific packet loss

13. Use TRACERT to Find the Network Route

Windows includes the tracert command.

Run:

tracert 8.8.8.8

Example:

1    1 ms    1 ms    1 ms    192.168.1.1
2    5 ms    6 ms    5 ms    ISP Gateway
3    8 ms    9 ms    8 ms    ISP Router
4   20 ms   19 ms   21 ms    Upstream Router
5   22 ms   21 ms   20 ms    Destination

This shows the routers through which packets travel.

However, an asterisk such as:

* * *

does not automatically mean packet loss.

Some routers intentionally do not respond to traceroute probes while continuing to forward normal traffic.

14. Use PATHPING for Better Packet-Loss Analysis

Windows provides a very useful tool called:

pathping

Run:

pathping 8.8.8.8

pathping combines characteristics of ping and traceroute.

It identifies intermediate hops and sends probes over time.

This can help determine whether packet loss appears at a particular stage of the route.

Allow the command enough time to complete.

15. Important: Do Not Misinterpret Intermediate-Hop Loss

Suppose PathPing shows:

Hop 1     0% loss
Hop 2     0% loss
Hop 3    60% loss
Hop 4     0% loss
Hop 5     0% loss

This does not necessarily mean Hop 3 is dropping 60% of actual traffic.

Routers may limit ICMP responses sent by the router itself while forwarding transit traffic normally.

A stronger indication of genuine path loss is when loss begins at one hop and continues through subsequent hops, including the destination.

For example:

Hop 1     0%
Hop 2     0%
Hop 3     5%
Hop 4     5%
Hop 5     5%
Destination 5%

This pattern deserves further investigation.

16. Check Ethernet Cable and Physical Connections

Physical-layer problems are common.

Inspect:

• Ethernet cables
• RJ45 connectors
• Patch panels
• Wall sockets
• Router ports
• Switch ports

Try replacing the Ethernet cable.

Also try moving the connection to another switch or router port.

If packet loss disappears, the physical component may have been faulty.

17. Check Network Adapter Link Speed

In PowerShell, run:

Get-NetAdapter

Review:

Status
LinkSpeed
InterfaceDescription

For example:

Ethernet   Up   1 Gbps

Unexpected negotiation, such as a Gigabit connection repeatedly operating at 100 Mbps, can indicate:

• Cable problems
• Connector problems
• Switch limitations
• NIC configuration problems

18. Check Network Adapter Errors

PowerShell can provide adapter statistics:

Get-NetAdapterStatistics

Look for abnormal increases in counters associated with discarded or erroneous traffic.

Run the command, generate traffic, and run it again.

Rapidly increasing error/discard counters can provide useful evidence of a local interface problem.

19. Check Speed and Duplex

Most modern Ethernet networks should use:

Auto Negotiation

A mismatch may cause serious performance problems.

For example:

PC = Full Duplex
Switch = Half Duplex

Possible symptoms include:

• Packet loss
• Poor throughput
• Retransmissions
• High latency
• Unstable connections

Avoid manually forcing speed and duplex unless required by the network design or equipment.

20. Update the Network Adapter Driver

Faulty or outdated network drivers can cause intermittent packet loss.

Open:

Device Manager
→ Network adapters
→ Your network adapter

Check the driver.

For important systems, preferably obtain drivers from the computer, motherboard, server, or NIC manufacturer's official support channel.

After changing the driver, restart the computer and repeat your packet-loss tests.

21. Test Wi-Fi Versus Ethernet

If packet loss occurs over Wi-Fi, temporarily connect the computer directly to the router using Ethernet.

Compare:

Wi-Fi = packet loss
Ethernet = no packet loss

If this happens, investigate the wireless network rather than the ISP first.

22. Common Causes of Wi-Fi Packet Loss

Wireless packet loss may be caused by:

• Weak signal
• Interference
• Overlapping channels
• Congested spectrum
• Too many clients
• Poor access-point placement
• Driver problems
• Power-saving settings
• Distance
• Walls
• Bluetooth or other radio interference

Check both:

2.4 GHz
5 GHz

where supported.

In suitable environments, 5 GHz may provide better performance and less interference, although its range through walls is generally shorter.

23. Check Wi-Fi Signal Information in Windows

Run:

netsh wlan show interfaces

Review information such as:

Signal
Channel
Radio type
Receive rate
Transmit rate

Very weak signal can contribute to retransmissions and packet loss.

24. Check Network Congestion

Packet loss can appear only during periods of high traffic.

For example:

Normal usage → 0% loss
Large upload → 5% loss
Cloud backup → 10% loss

This may indicate congestion or queueing problems.

Check whether any system is consuming excessive bandwidth through:

• Cloud backup
• OneDrive
• Google Drive
• Windows Update
• CCTV
• Large uploads
• Torrents
• File synchronization
• Remote backups

25. Understand Bufferbloat

Sometimes packet loss is accompanied by extremely high latency when the Internet connection is saturated.

Example:

Idle ping = 15 ms
During upload = 350 ms

This can occur because packets are waiting in oversized queues.

This behavior is commonly associated with bufferbloat.

Proper traffic management or modern queue-management mechanisms on compatible routers can improve performance.

26. Check Router CPU and Memory

Routers can become overloaded.

This is especially possible with:

• Many simultaneous users
• VPN encryption
• Firewall inspection
• IDS/IPS
• QoS
• Large numbers of sessions
• High-speed Internet traffic
• Heavy NAT workloads

Check the router's management interface for:

CPU usage
Memory usage
WAN errors
Interface errors
System logs
Uptime

27. Restart Network Equipment as a Diagnostic Test

A controlled restart can help identify temporary equipment problems.

Typical sequence:

ONT/modem
↓
Router
↓
Switch
↓
Access points

If restarting the equipment immediately eliminates packet loss but the problem later returns, investigate:

• Firmware
• Overheating
• Memory/resource exhaustion
• Hardware degradation
• Excessive sessions
• ISP-side instability

Repeated rebooting should not be considered a permanent fix.

28. Check Router Firmware

Router manufacturers periodically release firmware updates that may fix:

• Stability problems
• WAN issues
• Wi-Fi problems
• Security vulnerabilities
• NAT problems
• VPN problems

Before upgrading firmware, back up the configuration and follow the manufacturer's instructions carefully.

29. Check MTU Problems

MTU stands for:

Maximum Transmission Unit

An incorrect MTU can cause fragmentation or connectivity problems, particularly with:

• VPNs
• PPPoE
• Tunnels
• Certain WAN configurations

Windows can test packet sizes using ping.

For example:

ping 8.8.8.8 -f -l 1472

If fragmentation is required, reduce the payload gradually.

For IPv4 Ethernet with a 1500-byte MTU, a 1472-byte ICMP payload plus the usual 28 bytes of IPv4 and ICMP headers totals 1500 bytes.

MTU troubleshooting should be performed carefully, especially when VPNs or tunnels are involved.

30. Check for VPN-Related Packet Loss

If a VPN is being used, compare results:

VPN OFF

versus:

VPN ON

If the connection is stable without the VPN but unstable with it, investigate:

• VPN server
• VPN protocol
• MTU
• Encryption overhead
• VPN server load
• Routing
• Firewall
• ISP path to VPN server

31. Packet Loss and Remote Desktop

Packet loss can severely affect RDP sessions.

Symptoms include:

• Frozen screen
• Delayed typing
• Mouse lag
• Black screen
• Reconnection messages
• Session disconnects

Test both:

Client → Internet

and:

Server → Internet

Also test the route between the RDP client and server.

If possible, compare behavior from another ISP or network.

32. Packet Loss and VoIP

Voice traffic is particularly sensitive to network quality.

Packet loss may produce:

• Missing words
• Robotic voice
• One-way audio symptoms
• Audio gaps
• Call quality degradation

VoIP troubleshooting should evaluate:

Latency
Jitter
Packet loss
Bandwidth
QoS

33. Packet Loss and Online Gaming

Gaming requires relatively small bandwidth but highly consistent delivery.

A fast Internet connection can still perform poorly if it has:

Packet loss
High jitter
Latency spikes

Therefore, speed-test results alone do not determine gaming quality.

34. Packet Loss and Video Conferencing

Applications such as video conferencing platforms rely heavily on stable real-time communication.

Packet loss can cause:

• Frozen video
• Pixelation
• Broken audio
• Delayed conversation
• Temporary disconnection

For troubleshooting, compare wired and wireless connections and test during the exact period when problems occur.

35. Use Test-NetConnection in PowerShell

PowerShell provides:

Test-NetConnection

Example:

Test-NetConnection google.com

You can test a TCP port:

Test-NetConnection example.com -Port 443

This is particularly useful when ping is blocked but you need to test whether a service is reachable.

36. Ping Is Not the Same as Application Traffic

This is an important troubleshooting concept.

Ping normally uses:

ICMP

Applications may use:

TCP
UDP
QUIC

A firewall or server may block ICMP while allowing HTTPS or other services.

Therefore:

Ping failure ≠ Internet failure

Likewise:

Successful ping ≠ every application is healthy

Use protocol-specific testing when necessary.

37. Use Wireshark for Advanced Troubleshooting

Wireshark can capture and analyze network traffic.

It can help identify issues such as:

• TCP retransmissions
• Duplicate acknowledgments
• Connection resets
• DNS problems
• TCP handshake failures
• Application communication problems

For TCP troubleshooting, retransmissions can be an important indicator.

However, TCP retransmissions do not automatically prove physical packet loss. Congestion, routing, server behavior, or capture location can also influence the result.

38. Use PingPlotter, WinMTR or MTR

For intermittent problems, continuous path-monitoring tools can be very useful.

Common tools include:

PingPlotter
WinMTR
MTR

They can help visualize:

Latency
Packet loss
Route changes
Problematic hops

Run tests long enough to capture the actual problem.

For intermittent connections, a 30-minute or multi-hour test may be more informative than a 30-second test.

39. Compare Different Devices

Suppose Computer A experiences packet loss.

Test Computer B on the same network.

Scenario A

Computer A = packet loss
Computer B = no packet loss

Investigate Computer A:

• NIC
• Driver
• Cable
• OS
• Security software
• Local configuration

Scenario B

Computer A = packet loss
Computer B = packet loss
Computer C = packet loss

Investigate shared infrastructure:

• Switch
• Router
• Access point
• WAN
• ISP

This comparison can dramatically reduce troubleshooting time.

40. Test Another Internet Connection

If possible, temporarily test using another connection.

For example:

Primary ISP
vs
Mobile hotspot
vs
Secondary ISP

Suppose:

Primary ISP → packet loss
Mobile hotspot → stable

The evidence points toward the primary connection or its network path.

41. Test at Different Times of Day

Packet loss that occurs primarily during peak hours can indicate congestion.

Record results such as:

08:00 AM → 0%
02:00 PM → 0%
08:00 PM → 6%
11:00 PM → 1%

This information is extremely useful when escalating a problem to an ISP.

42. Check Firewall and Security Software

Security products can sometimes interfere with traffic through:

• Web filtering
• HTTPS inspection
• Intrusion prevention
• VPN modules
• Network filtering drivers

For troubleshooting, review security software logs and configuration.

Do not permanently disable security controls merely to hide the symptom.

If temporary testing is necessary, perform it in a controlled environment and restore protection afterward.

43. Check Windows Network Configuration

Run:

ipconfig /all

Check:

• IP address
• Subnet mask
• Default gateway
• DNS servers
• DHCP status
• Adapter information

Incorrect configuration can produce connectivity problems that may resemble packet loss.

44. Reset the Windows Network Stack

If the problem appears limited to one Windows computer, network-stack repair may help.

Commands commonly used include:

ipconfig /flushdns
netsh winsock reset
netsh int ip reset

Restart Windows afterward.

Be aware that custom network configurations may need to be reapplied.

45. Check Route Table

Run:

route print

Review the active routes.

Incorrect routes can cause traffic to travel through an unexpected gateway or interface.

This is especially relevant on computers with:

• Multiple NICs
• VPNs
• Virtual adapters
• Multiple gateways
• Hyper-V
• VirtualBox
• VMware

46. Check for Duplicate IP Addresses

Duplicate IP addresses can cause intermittent communication problems.

Symptoms may include:

• Random disconnections
• Gateway problems
• ARP confusion
• Intermittent server access

Review DHCP assignments and static IP configurations.

You can inspect ARP information using:

arp -a

47. Check Switch Port Statistics

Managed switches may provide counters such as:

CRC errors
Input errors
Output errors
Drops
Discards
Link flaps

A rapidly increasing CRC error count often points toward a Layer 1 problem such as:

Cable
Connector
Port
Transceiver

Switch statistics can therefore be extremely valuable in business networks.

48. Understand TCP Retransmission

TCP is designed to recover from missing data.

If a packet is lost, TCP can retransmit it.

This means a user may not see a complete connection failure, but performance may become slow.

Conceptually:

Packet sent
↓
Packet lost
↓
Acknowledgment missing
↓
TCP retransmission
↓
Additional delay

Heavy retransmission can significantly reduce effective throughput.

49. UDP Packet Loss

UDP does not provide TCP-style retransmission by default.

Applications using UDP may therefore be especially sensitive to packet loss.

Examples can include:

• VoIP
• Gaming
• Streaming
• DNS
• Some VPN traffic
• Real-time communication

The application itself may implement recovery mechanisms, but lost UDP datagrams are not automatically retransmitted by UDP.

50. How Much Packet Loss Is Acceptable?

For a well-functioning wired LAN, the target should normally be:

0%

Even small amounts of sustained loss can affect sensitive applications.

A practical interpretation might be:

0%        Excellent target
<1%       Investigate if persistent
1–2%      Noticeable for sensitive applications
2–5%      Significant
>5%       Serious

These are troubleshooting guidelines rather than universal standards. The effect depends on protocol, application, traffic pattern, latency, jitter, and where the loss occurs.

51. A Professional Packet-Loss Troubleshooting Workflow

Use this sequence:

PC
↓
Loopback
↓
Local NIC
↓
Ethernet/Wi-Fi
↓
Switch/AP
↓
Default Gateway
↓
Router WAN
↓
ONT/Modem
↓
ISP Gateway
↓
ISP Backbone
↓
Internet
↓
Destination Server

At each stage ask:

Where does packet loss first appear?

That is usually more useful than simply asking:

Is there packet loss?

52. Recommended Diagnostic Commands

Display network configuration

ipconfig /all

Ping gateway

ping 192.168.1.1 -n 100

Ping Internet

ping 8.8.8.8 -n 100

Continuous ping

ping 8.8.8.8 -t

Trace route

tracert 8.8.8.8

Analyze path

pathping 8.8.8.8

DNS test

nslookup google.com

View routes

route print

View ARP table

arp -a

PowerShell connectivity test

Test-NetConnection google.com -Port 443

Network adapter information

Get-NetAdapter

Adapter statistics

Get-NetAdapterStatistics

53. Quick Packet-Loss Diagnostic Matrix

Test Result	Likely Area to Investigate
Loss to 127.0.0.1	Local TCP/IP/OS
Loss to gateway	LAN/Wi-Fi/NIC/cable/router
Gateway stable, Internet unstable	WAN/ISP/upstream
One destination unstable	Destination/path-specific issue
Wi-Fi unstable, Ethernet stable	Wireless network
One PC affected	PC/NIC/driver/cable/configuration
All PCs affected	Router/switch/WAN/ISP
VPN only affected	VPN/server/MTU/routing
Peak-hours only	Congestion/capacity
Upload causes latency/loss	Congestion/bufferbloat
Errors increase on switch port	Cable/port/transceiver

54. How to Collect Evidence for Your ISP

Before contacting the ISP, collect:

Date
Time
Connection type
Gateway ping result
Public IP ping result
Packet-loss percentage
Traceroute
PathPing/MTR results
Duration of problem
Affected devices
Whether wired and Wi-Fi are both affected

Example:

Date: 19-Aug-2026
Time: 8:30 PM

Gateway:
192.168.1.1
0% loss

Public Internet:
8.8.8.8
7% loss

1.1.1.1
6% loss

Affected devices:
4 PCs

Ethernet:
Affected

Wi-Fi:
Affected

This is much stronger evidence than simply reporting:

"Internet is slow."

55. Common Packet-Loss Troubleshooting Mistakes

Avoid these mistakes:

Mistake 1: Running only a speed test

A speed test does not provide a complete picture of packet reliability.

Mistake 2: Testing only one destination

The destination itself may filter ICMP or have a routing issue.

Mistake 3: Assuming every traceroute timeout means loss

Routers frequently deprioritize diagnostic traffic.

Mistake 4: Immediately blaming the ISP

Always test the local gateway first.

Mistake 5: Ignoring Wi-Fi

Wireless interference is a common source of local packet loss.

Mistake 6: Testing for only a few seconds

Intermittent packet loss may require long-duration monitoring.

Mistake 7: Changing multiple settings simultaneously

Change one component at a time so you know which action actually fixed the problem.

56. Example Troubleshooting Case

Suppose a user reports:

RDP freezes several times every hour.

First test the gateway:

ping 192.168.1.1 -n 500

Result:

0% loss

Then:

ping 8.8.8.8 -n 500

Result:

4% loss

Test another destination:

ping 1.1.1.1 -n 500

Result:

4% loss

Now test another PC.

It shows similar results.

This indicates:

Local LAN likely stable
Multiple devices affected
Multiple Internet destinations affected

Investigation should therefore move toward:

Router WAN
ONT/modem
ISP circuit
ISP routing

This systematic approach avoids unnecessary Windows troubleshooting.

57. Advanced Troubleshooting Strategy

For difficult intermittent cases, run simultaneous monitoring against multiple network layers.

For example:

Window 1

ping 192.168.1.1 -t

Window 2

ping 8.8.8.8 -t

Window 3

ping 1.1.1.1 -t

When the problem occurs, compare all three windows.

Case A

Gateway timeout
8.8.8.8 timeout
1.1.1.1 timeout

Likely local LAN/router issue.

Case B

Gateway OK
8.8.8.8 timeout
1.1.1.1 timeout

Likely WAN/ISP problem.

Case C

Gateway OK
8.8.8.8 OK
Specific server timeout

Likely destination-specific routing or server problem.

This simple technique can be extremely effective.

58. Packet Loss Troubleshooting Checklist

When troubleshooting packet loss, verify:

• Physical cables and connectors
• Network adapter
• NIC driver
• Switch port
• Router port
• Wi-Fi signal
• Wi-Fi interference
• Gateway response
• Public Internet response
• Multiple Internet destinations
• Traceroute
• PathPing/MTR
• DNS separately
• Router CPU and memory
• WAN interface statistics
• Network congestion
• MTU
• VPN
• Firewall/security software
• Switch errors
• Alternate PC
• Alternate cable
• Alternate router/switch port
• Alternate Internet connection
• Peak versus off-peak performance

Frequently Asked Questions – FAQ

1. What is packet loss?

Packet loss occurs when network packets fail to reach their intended destination or fail to return successfully.

2. What is the ideal packet-loss percentage?

For a stable wired LAN, the normal target is 0% packet loss.

3. Is 1% packet loss bad?

Persistent 1% packet loss should be investigated, particularly for VoIP, gaming, RDP, VPN, and video conferencing.

4. Can packet loss make the Internet slow?

Yes. TCP may need to retransmit lost packets, reducing effective performance.

5. Can Wi-Fi cause packet loss?

Yes. Weak signals, interference, congestion, distance, and access-point problems are common causes.

6. Can a bad Ethernet cable cause packet loss?

Yes. Damaged cables and connectors can produce errors, retransmissions, or unstable links.

7. How do I test packet loss in Windows?

A simple test is:

ping 8.8.8.8 -n 100

For better diagnosis, also ping your default gateway and other destinations.

8. What does "Request Timed Out" mean?

It means a response was not received within the expected time. It can indicate packet loss, filtering, congestion, or a device that does not respond to ICMP.

9. Does a traceroute timeout prove packet loss?

No. Routers may intentionally ignore or rate-limit traceroute/ICMP traffic while forwarding normal traffic successfully.

10. What is PathPing?

PathPing is a Windows diagnostic utility that combines route discovery with packet-loss measurements over time.

11. Can an ISP cause packet loss?

Yes. Congestion, routing issues, line problems, faulty equipment, or upstream network problems can cause packet loss.

12. How do I know whether packet loss is from my ISP?

If the local gateway remains stable while multiple external destinations show persistent loss, the WAN/ISP path becomes a likely area for investigation.

13. Can packet loss affect RDP?

Yes. Packet loss can cause RDP lag, freezing, poor responsiveness, reconnections, and disconnections.

14. Can packet loss affect VPN connections?

Yes. VPNs can be affected by underlying packet loss, MTU problems, congestion, routing, and overloaded VPN servers.

15. Why does packet loss happen only at night?

Peak-hour congestion may be responsible if loss consistently appears during high-usage periods.

16. Can packet loss occur even with 1 Gbps Internet?

Yes. Bandwidth capacity and packet reliability are different characteristics.

17. Can DNS cause packet loss?

DNS problems can cause symptoms that resemble connectivity failure, but DNS failure and packet loss are different problems.

18. Can firewall software cause packet loss?

Network-filtering or inspection components can sometimes affect traffic. Logs and controlled testing should be used to determine whether security software is involved.

19. What is the best tool for long-term packet-loss monitoring?

Tools such as PingPlotter, WinMTR, MTR, or dedicated network-monitoring systems can be useful for extended monitoring.

20. Can Wireshark detect packet loss?

Wireshark can reveal indicators such as TCP retransmissions and duplicate acknowledgments, but the capture must be interpreted carefully.

21. What should I ping first?

Start with your default gateway. This helps determine whether the problem exists inside your local network.

22. Why does ping show packet loss but browsing works?

The destination or intermediate routers may deprioritize ICMP while allowing normal application traffic.

23. Can high CPU usage on a router cause packet loss?

Yes. An overloaded router may be unable to process packets quickly enough under heavy workloads.

24. Can MTU cause packet-loss-like problems?

Yes. Incorrect MTU settings can cause fragmentation or communication failures, particularly with VPNs and tunnels.

25. Should I replace my router if I have packet loss?

Not immediately. First isolate whether loss occurs between your device and router, beyond the router, or only toward a particular destination.

Conclusion

Packet loss should be diagnosed systematically rather than by randomly restarting devices or changing network settings.

The most effective approach is to identify where the loss begins:

Computer
↓
NIC
↓
Cable / Wi-Fi
↓
Switch
↓
Gateway
↓
Router
↓
ONT / Modem
↓
ISP
↓
Internet
↓
Destination

Start by testing the local gateway. Then test multiple public destinations. Use longer ping tests, tracert, pathping, PowerShell, interface statistics, and advanced tools such as Wireshark or MTR when required.

Remember:

A fast connection is not necessarily a stable connection.

Bandwidth measures how much data a connection can carry, while packet loss, latency, and jitter determine how reliably and responsively that data travels.

For business networks, Remote Desktop, VPN, VoIP, cloud applications, gaming, and video conferencing, even relatively small amounts of persistent packet loss can significantly degrade the user experience.

The objective should therefore not simply be to prove that packet loss exists, but to determine:

Where does the packet loss start, under what conditions does it occur, and which network component is responsible?

Once those questions are answered, packet-loss troubleshooting becomes far more precise and effective.

#Tags

#PacketLoss #PacketLossTroubleshooting #NetworkTroubleshooting #NetworkDiagnostics #InternetTroubleshooting #FixPacketLoss #NetworkPerformance #InternetProblems #WiFiTroubleshooting #EthernetTroubleshooting #LAN #WAN #Networking #Ping #PingTest #Traceroute #Tracert #PathPing #WinMTR #MTR #Wireshark #NetworkMonitoring #Latency #Jitter #NetworkCongestion #InternetSpeed #RouterTroubleshooting #SwitchTroubleshooting #ISP #ISPTroubleshooting #WindowsNetworking #Windows11 #Windows10 #WindowsServer #PowerShell #TestNetConnection #NetworkAdapter #NIC #WiFi #Ethernet #VPN #RDP #RemoteDesktop #VoIP #GamingNetwork #DNS #MTU #TCP #UDP #ITSupport