Last updated: March 22, 2026

Network issues kill remote work productivity. When your video call drops or VPN slows to a crawl, you need tools to diagnose fast without calling IT. This guide covers the essential diagnostic toolkit: from simple ping checks to traffic analysis, covering macOS, Linux, and Windows.

Table of Contents

Baseline - Know Your Normal Numbers

Run these on a good day and save the output for comparison:

Your public IP and ISP
curl -s https://ipinfo.io | jq '{ip, org, city, region}'

Baseline speed (use Speedtest CLI)
macOS/Linux
brew install speedtest-cli
speedtest-cli --simple
Download - 450 Mbps, Upload: 45 Mbps, Ping: 8ms

Baseline DNS latency
time dig @8.8.8.8 google.com
real 0m0.014s. under 50ms is good

Baseline to key servers
ping -c 10 8.8.8.8
Round trip time - avg 12ms. under 30ms for US

Layer 1 - Physical and Link

Check network interface stats (macOS)
networksetup -listallhardwareports
ifconfig | grep -A4 'en0:'

Check for packet errors or drops (Linux)
ip -s link show eth0
Look for - errors, dropped, overruns > 0

macOS: check WiFi signal strength
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I | grep -E 'SSID|RSSI|channel|lastTxRate'
RSSI - -65 dBm is good; below -75 dBm is problematic

WiFi channel utilization
airport -s  # Scan nearby networks, find congested channels

Layer 2 - Connectivity

Basic ping with statistics
ping -c 20 8.8.8.8
Key - avg < 30ms (local), < 80ms (regional), 0% packet loss

Ping multiple targets to isolate where loss starts
ping -c 10 192.168.1.1    # Router: should be < 2ms
ping -c 10 1.1.1.1        # ISP exit: if bad, ISP issue
ping -c 10 8.8.8.8        # Google: if good but above bad = ISP routing

Continuous ping (Ctrl+C to stop)
ping 8.8.8.8

macOS: network quality test (built-in since macOS 12)
networkQuality
Upload/download/responsiveness measured

Layer 3 - Traceroute

Standard traceroute
traceroute google.com

MTR - combines ping + traceroute, shows continuous loss per hop
Install
brew install mtr   # macOS
sudo apt install mtr  # Ubuntu

Run MTR (best for diagnosing routing issues)
sudo mtr --report --report-cycles=20 google.com
Look for - hop with suddenly high Loss% = problem node
Last hop 100% loss with no prior loss = firewall (normal)

MTR output example:
Host                     Loss%   Snt   Avg  Best  Wrst StDev
1. 192.168.1.1             0.0%    20   1.2   0.9   2.1   0.3  ← router: fine
2. 10.20.30.1              0.0%    20   8.4   7.1  12.0   1.1  ← ISP: fine
3. 72.14.215.100           0.0%    20  10.2   9.8  11.0   0.3  ← ISP backbone: fine
4. ???                     100%    20   0.0   0.0   0.0   0.0  ← filtered, normal
5. google.com              0.0%    20  11.3  10.9  12.0   0.3  ← destination: fine

Layer 4 - DNS Diagnostics

DNS failures cause apps to hang before any connection starts:

Check DNS resolution speed
time dig google.com
time dig @1.1.1.1 google.com   # Cloudflare
time dig @8.8.8.8 google.com   # Google
time dig @9.9.9.9 google.com   # Quad9

Check which DNS server you're actually using
cat /etc/resolv.conf   # Linux
scutil --dns | head -20  # macOS

Test DNS over TLS/HTTPS
dig @1.1.1.1 google.com +tls  # DNS-over-TLS
curl -s "https://cloudflare-dns.com/dns-query?name=google.com&type=A" \
  -H "Accept - application/dns-json" | jq '.Answer[].data'

Flush DNS cache
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder  # macOS
sudo systemd-resolve --flush-caches  # Linux (systemd)
ipconfig /flushdns  # Windows

Check for DNS hijacking (compare results)
dig @8.8.8.8 checkip.dyndns.org TXT +short
dig @1.1.1.1 checkip.dyndns.org TXT +short

VPN Diagnostics

Check if VPN is connected
ifconfig | grep -E "tun|tap|utun|wg"  # Look for tunnel interface

Check VPN routing
ip route | grep -E "tun|wg"  # Linux
netstat -rn | grep utun  # macOS

Verify traffic is going through VPN
curl -s https://ipinfo.io/ip  # Should show VPN exit IP

WireGuard status
sudo wg show
Look for - latest handshake < 3 minutes, transfer bytes increasing

OpenVPN log
sudo journalctl -u openvpn@client -n 50  # Linux
macOS: check Tunnelblick logs

MTR through VPN to internal host
sudo mtr --report 10.0.0.1  # Internal IP via VPN

Bandwidth and Latency Under Load

Install iperf3 for bandwidth testing
brew install iperf3  # macOS
sudo apt install iperf3  # Ubuntu

If you have an iperf3 server on your network:
Server side:
iperf3 -s

Client side:
iperf3 -c server-ip -t 30  # 30 second test
iperf3 -c server-ip -u -b 10M  # UDP test at 10 Mbps (good for VoIP simulation)
iperf3 -c server-ip --bidir  # Bidirectional test

Test during a video call to see real impact
iperf3 -c public-iperf3-server -p 5201
Public test servers - iperf.he.net, bouygues.iperf.fr

Port and Firewall Checks

Test if a port is reachable
nc -zv git.example.com 22    # SSH
nc -zv api.example.com 443   # HTTPS
nc -zv smtp.example.com 587  # SMTP

Scan local network for a host
nmap -sn 192.168.1.0/24  # Ping scan (find devices)
nmap -p 22,80,443,5432 192.168.1.10  # Port scan specific host

Check what's listening locally
ss -tulpn  # Linux (shows process names)
lsof -iTCP -sTCP:LISTEN  # macOS

Test HTTP connectivity
curl -v --max-time 10 https://api.example.com/health
Look for - TLS handshake time, TTFB, total time
curl -w "DNS: %{time_namelookup}s | Connect: %{time_connect}s | TLS: %{time_appconnect}s | Total: %{time_total}s\n" \
  -o /dev/null -s https://api.example.com

Packet Capture

When nothing else works, capture traffic:

macOS/Linux: tcpdump
sudo tcpdump -i en0 -n host 8.8.8.8 and port 53
sudo tcpdump -i en0 -n 'tcp port 443' -w /tmp/capture.pcap

Analyze with Wireshark
brew install --cask wireshark

Quick analysis - count by destination
sudo tcpdump -i en0 -n -c 1000 | awk '{print $5}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

Monitor bandwidth by process (macOS)
brew install nettop
sudo nettop -d  # Shows bytes in/out per process

Quick Diagnostic Checklist Script

#!/bin/bash
scripts/network-check.sh
echo "=== Remote Work Network Diagnostics ==="
echo "Date: $(date)"
echo ""

echo "--- External IP ---"
curl -s --max-time 5 https://ipinfo.io | jq -r '"IP: \(.ip) | ISP: \(.org)"'

echo ""
echo "--- Router Ping ---"
ROUTER=$(netstat -rn | grep 'default' | awk '{print $2}' | head -1)
ping -c 5 -q "$ROUTER" 2>&1 | tail -3

echo ""
echo "--- Google DNS ---"
ping -c 5 -q 8.8.8.8 2>&1 | tail -3

echo ""
echo "--- DNS Resolution ---"
time_ns=$(date +%s%N)
dig @8.8.8.8 google.com > /dev/null 2>&1
echo "DNS latency: $(( ($(date +%s%N) - time_ns) / 1000000 ))ms"

echo ""
echo "--- Speed Test ---"
speedtest-cli --simple 2>/dev/null || echo "speedtest-cli not installed"

echo ""
echo "=== Done ==="

chmod +x scripts/network-check.sh
./scripts/network-check.sh

Diagnosing Video Call Degradation Specifically

Packet loss under 1% is imperceptible on HTTP. For video calls, even 0.5% sustained packet loss causes visible artifacts. Jitter. variation in packet arrival timing. is often more disruptive than raw latency.

Measure Jitter and Packet Loss to Call Servers

Test against Zoom's media servers
Replace with your actual call platform's server range
sudo mtr --report --report-cycles=60 --interval=0.5 \
  zoom.us

For Google Meet, test against the STUN servers
ping -c 100 -i 0.2 stun.l.google.com
stddev > 10ms = jitter problem; any loss = call quality issue

Simulate VoIP packet profile with iperf3
Server side:
iperf3 -s

Client side - 100kbps UDP (typical audio codec bandwidth)
iperf3 -c server-ip -u -b 100k -l 160 -t 60
Look for - jitter > 20ms or packet loss > 0.5% = call will degrade

WiFi vs Ethernet Quick Test

If you suspect your WiFi is the issue, run this comparison:

Run while on WiFi
ping -c 50 -i 0.2 8.8.8.8 | tail -3
Note stddev

Plug in ethernet, disable WiFi
networksetup -setairportpower en0 off   # macOS
or
nmcli radio wifi off                    # Linux

ping -c 50 -i 0.2 8.8.8.8 | tail -3
Compare stddev. ethernet should be 0.1-0.5ms vs WiFi's 1-10ms

A stddev difference of more than 5ms between WiFi and ethernet points to RF interference or a congested wireless channel rather than ISP issues.

Reading ISP Problem Patterns

Different failure modes produce different diagnostic signatures. Use this as a reference:

SYMPTOM                         LIKELY CAUSE              CONFIRM WITH
-------------------------------------------------------------------
High ping to router (>5ms)      Bad cable / WiFi issue    Ethernet test
High ping past router           ISP congestion            MTR to 8.8.8.8
DNS slow, ping fine             DNS server issue          compare dig times
All traffic slow, VPN fine      ISP shaping               compare VPN vs direct
VPN connects, drops every 5min  UDP timeout               switch VPN protocol
Morning fine, afternoon slow    Neighborhood congestion   run at different times
Upload degraded, download fine  DOCSIS upstream issue     iperf3 bidir test

Logging Network Events Over Time

For intermittent issues, run a background logger to correlate dropouts with time of day:

#!/bin/bash
scripts/network-logger.sh
Run in background - nohup ./network-logger.sh &

LOG="network-events-$(date +%Y%m%d).log"

while true; do
  TS=$(date '+%Y-%m-%d %H:%M:%S')
  LOSS=$(ping -c 10 -q 8.8.8.8 2>&1 | grep -oE '[0-9]+% packet loss' | cut -d% -f1)
  LATENCY=$(ping -c 10 -q 8.8.8.8 2>&1 | grep 'avg' | awk -F'/' '{print $5}')

  if [ "$LOSS" != "0" ] || (( $(echo "$LATENCY > 100" | bc -l) )); then
    echo "$TS | ALERT | loss=${LOSS}% | avg_rtt=${LATENCY}ms" | tee -a "$LOG"
  else
    echo "$TS | OK | loss=${LOSS}% | avg_rtt=${LATENCY}ms" >> "$LOG"
  fi

  sleep 60
done

Run this during your work day for a week, then share the log with your ISP when requesting escalation. Concrete timestamps and loss percentages get faster resolution than “the internet is slow sometimes.”

Related Reading

Related Articles