Networking

Trace a request from your laptop to a website

Follow one web request hop by hop, and learn the one command that tests each stage.

  • Beginner
  • About 30 minutes
  • Command line
  • Simulation + real-world
  • Published 26 October 2026

The scenario

You type an address and a page appears. In between, your laptop finds the gateway, resolves the name, connects, checks a certificate and asks for the page. If any step fails, nothing loads.

Before you start

  • A Windows, macOS or Linux computer connected to a network you are allowed to test from
  • A terminal (PowerShell on Windows, Terminal on macOS or Linux)
  • No admin rights needed

Tools

  • ip / ipconfig
  • ping
  • dig / nslookup / Resolve-DnsName
  • nc / Test-NetConnection
  • curl
  • traceroute / tracert

You'll be able to

You can name each stage of a web request, test each one with a single command, and say which stage is broken from the result.

Try it

Browser simulation. Runs entirely in your browser. Nothing connects to real systems.

Network diagram: your laptop connects through a switch and a router to the internet, which leads to a DNS resolver and a web server. A request to app.example.com finds the gateway, resolves the name, opens a TCP connection, checks the TLS certificate and receives HTTP 200.

Step 1 of 6

Check your own settings

Before anything leaves the laptop, it needs four things, usually handed out by DHCP when it joins the network: an IP address, a subnet mask, a default gateway and a DNS server.

The mask (/24) tells the laptop which addresses are local. app.example.com will turn out not to be, so traffic has to go via the gateway.

If this step fails: No address, or one starting 169.254, means DHCP did not answer. Check the cable or Wi-Fi first, then the DHCP server.
Simulated output
$ ip -br addr show wlan0 && ip route && resolvectl dns wlan0
wlan0   UP   192.168.1.20/24
default via 192.168.1.1 dev wlan0 proto dhcp metric 600
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.20
Link 3 (wlan0): 198.51.100.53

Step 2 of 6

Find the gateway

On the local network, frames are delivered by hardware (MAC) address, not IP. The laptop broadcasts an ARP request asking which device owns 192.168.1.1.

The switch floods the broadcast to every port. The router answers with its MAC address, and the laptop caches it so it does not have to ask again for a while.

If this step fails: An entry stuck at FAILED or INCOMPLETE points to the gateway being down, a wrong gateway address, or client isolation on the Wi-Fi.
Simulated output
$ ip neigh show 192.168.1.1
192.168.1.1 dev wlan0 lladdr 00:00:5e:00:53:01 REACHABLE

Step 3 of 6

Ask DNS for the address

Computers connect to IP addresses, not names. The laptop asks its configured resolver for the A record of app.example.com.

If the resolver has no cached answer, it works it out by asking the root servers, then the .com servers, then the servers responsible for example.com. The answer comes back with a TTL: how many seconds it may be cached.

If this step fails: A timeout points at the resolver or the path to it. NXDOMAIN means the name does not exist. A wrong answer suggests a stale cache, a hosts-file entry or split DNS on a VPN.
Simulated output
$ dig +noall +answer app.example.com
app.example.com.   300   IN   A   203.0.113.10

Step 4 of 6

Open a connection

HTTPS runs over TCP port 443. The laptop sends SYN, the server answers SYN-ACK, and the laptop finishes with ACK: the three-way handshake.

On the way out, the router translates the private source address 192.168.1.20 into its public address (NAT). The firewall remembers the connection, which is why the reply is allowed back in.

If this step fails: A timeout means something is silently dropping packets, often a firewall rule. "Connection refused" means you reached the host but nothing is listening on that port.
Simulated output
$ nc -vz app.example.com 443
Connection to app.example.com (203.0.113.10) 443 port [tcp/https] succeeded!

Step 5 of 6

Check who's answering

Before any page data moves, TLS proves the server is who it claims to be. The server presents a certificate, and the laptop checks three things: the name matches, it has not expired, and it chains up to an authority the laptop already trusts.

Both sides then agree on keys, and everything after this point is encrypted.

If this step fails: An expired certificate, a name mismatch or an untrusted issuer stops the connection here, even though the network itself is fine.
Simulated output
$ curl -sv -o /dev/null https://app.example.com
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=app.example.com
*  expire date: Mar 14 23:59:59 2027 GMT
*  SSL certificate verify ok.

Step 6 of 6

Get the page

Inside the encrypted connection, the browser finally asks for the page and the server replies with a status code and the content.

Every step before this one had to work. That is why troubleshooting from the bottom up (settings, gateway, DNS, port, certificate, application) finds faults so quickly.

If this step fails: A 5xx code is a server-side problem. A 4xx is usually the request or permissions. If the page loads but looks broken, open the browser’s network tab.
Simulated output
$ curl -sI https://app.example.com
HTTP/2 200
content-type: text/html; charset=utf-8
cache-control: max-age=300

What this lab shows

A web request is not one action but a chain of small ones, and each depends on the one before. Troubleshooters work through that chain from the bottom up. Once you can see the chain, “the internet is down” turns into a specific, testable question.

The simulation above uses documentation-only addresses (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) and the reserved name app.example.com. In the hands-on part below you will use example.com, a real domain that exists purely for examples and documentation, so it is safe to test against.

Step 1: Read your own network settings

Find the four values your device needs: its IP address, subnet mask, default gateway and DNS server.

# Windows
ipconfig /all
# Linux
ip -br addr
ip route
resolvectl status   # on systems using systemd-resolved

On macOS, ifconfig shows the address and netstat -rn shows the default route. Look for the default gateway (often ending in .1 or .254 on home networks) and the DNS servers.

Read it like a troubleshooter: an address beginning 169.254. means the device gave itself an address because DHCP never answered. Fix that before anything else.

Step 2: Prove the gateway answers

ping -c 4 192.168.1.1     # Linux and macOS: use your own gateway address
ping -n 4 192.168.1.1     # Windows

Replies mean your device can reach the edge of its network. No replies can mean a cable, Wi-Fi or gateway problem, but be careful: some routers are configured to ignore ping. A failed ping is a clue, not a verdict.

Step 3: Resolve the name

dig example.com +short                 # Linux and macOS
nslookup example.com                   # any platform
Resolve-DnsName example.com            # Windows PowerShell

You should get one or more IP addresses back. Note which server answered. If names fail but everything else works, you have found a DNS problem, and the next lab, Can’t reach the service, is about exactly that.

Step 4: Test the port, not just ping

Ping uses ICMP, which tells you nothing about whether a web server is listening. Test the actual port instead.

nc -vz example.com 443                 # Linux and macOS
Test-NetConnection example.com -Port 443   # Windows

A success message (or TcpTestSucceeded : True) means a TCP connection to port 443 opened. A timeout suggests a firewall is dropping traffic. “Connection refused” means you reached the host, but nothing is listening on that port.

Step 5: Check the certificate and the response

curl -sSI https://example.com

curl resolves the name, connects, completes the TLS handshake (including certificate checks) and makes the HTTP request. A status line such as HTTP/2 200 means every stage worked. Add -v to watch the handshake and certificate details scroll past.

Step 6 (optional): See the path

traceroute example.com    # Linux and macOS (you may need to install it)
tracert example.com       # Windows

Each line is a router your traffic passes through. Lines of * * * are normal: many routers simply do not reply to these probes.

Expected result

You should be able to fill in this table for your own connection:

Stage Command Working looks like
Local settings ipconfig /all or ip -br addr A real address, a gateway and a DNS server
Gateway ping your gateway Replies (unless the router ignores ping)
DNS dig, nslookup or Resolve-DnsName One or more IP addresses
TCP port nc -vz or Test-NetConnection -Port 443 Connection succeeded
TLS and HTTP curl -sSI A status line such as HTTP/2 200

Why the order matters

Each stage depends on the ones below it. Testing from the bottom up means the first failure you find is very likely the real fault. That habit, more than any single command, is what makes troubleshooting fast.

Key lessons

  • A web request is a chain: local settings, gateway, DNS, TCP, TLS and HTTP. Each link can be tested on its own.
  • Ping only proves ICMP reachability. Test the actual port before blaming the network.
  • Work bottom-up: the first stage that fails is usually the real fault.

Keep going

Automation and scripting

Automate the checks: a reusable connectivity script

Turn the manual checks into one script that tests gateway, DNS, TCP and HTTPS in order. Bash and PowerShell versions included.

BeginnerAbout 25 minutesCommand lineReal-world lab
  • scripting
  • Bash
  • PowerShell
  • troubleshooting