← back to the section

You press "Place order", the page spins and says "Something went wrong". The developer opens the service log — empty: the request never arrived. The defect goes to payment, though things stopped a step earlier.

Between the button and the code lies a chain: a name becomes an address, a connection comes up to it, a request travels over it. You need that chain to name the step where things stopped.

browser DNS server 10.2.14.7:443 what address is shop.test? 10.2.14.7 TCP :443 — handshake channel is open GET /orders/42 200 · list of orders Network tab: one row, status 200 TCP :443 — packets leave no answer browser: site can't be reachedNetwork tab — not a single row with a statusthe application never saw the request

The successful path: the name becomes an address, a TCP connection comes up to the address-and-port pair, the request goes out over it and an answer with a status comes back. The second half breaks at step three: packets leave, nothing returns — the screen says the site can't be reached and the Network tab is empty. The service log is just as empty: the request never got there.

What actually leaves your machine

"It doesn't work for me" covers two defects with two owners: the application computed wrong, or nothing reached it.

No direct wire runs between the client (browser, mobile app, Postman) and the server — a process elsewhere that listens and answers. The request passes through a router, a corporate proxy, a load balancer, any of which may answer for the server or stay silent. Hence the first question before a bug report: was there an answer? Anything at all, even a 500, puts the cause in the code; no answer means fixing availability. The exchange itself is client-server and HTTP, a level above.

Address, port, name

Machines don't connect by name: shop.test is for people, a packet needs a number.

An IP address identifies the machine: 10.2.14.7 (IPv4 — four numbers from 0 to 255) or a long IPv6 one. A port, 0 to 65535, is the flat number in that building: which program gets the packet. Some are fixed by convention — 80 HTTP, 443 HTTPS, 5432 PostgreSQL, 22 SSH — so browsers fill 443 in for https:// and nobody types it.

DNS turns the name into an address. The system checks the local hosts file first (/etc/hosts, on Windows under System32\drivers\etc): a line there overrides everything. Otherwise it asks a name server and caches the answer for the record's TTL, usually minutes or hours — so a moved environment still opens at the old address for part of the team.

"The domain doesn't resolve" is this step: nslookup shop.test (or dig) comes back empty, and the application is not involved.

What an address is made of: URI, URL, URN

A link from the task breaks somewhere in its parameters and you can't say where, because it was never taken apart.

URI is the umbrella name for a resource identifier, in two kinds. A URL says where the resource lives and how to get it. A URN names it without saying where: urn:isbn:9785446104222 is a book, not an address to download it from. Daily work is URLs; URI shows up in API documentation.

https://shop.test:8443/orders/42?status=paid&page=2#items
scheme  host     port path      query string       fragment

The query string after ? feeds half your checks: filters, paging, sorting. The fragment after # never reaches the server — the browser handles it, so a defect behind an anchor is browser-side.

TCP against UDP: guarantee against speed

A page takes ten seconds to load; a call breaks into fragments. The complaints sound alike, the protocols underneath differ.

TCP is a connection with a guarantee. Before the first useful byte the sides exchange three messages — the handshake; after that every chunk is numbered and acknowledged, lost ones resent, out-of-order ones reordered. The price is a round trip for that handshake, so "the first request is slow, the rest are fast" is often not a defect. UDP has neither: send and forget, instant, no promises.

One criterion splits them: every byte matters — TCP; data goes stale fast — UDP. Pages, APIs, files and payments run over TCP; voice, video, games and telemetry over UDP, where waiting for a frame that already passed is pointless. DNS queries too.

For testing: choppy audio in a call is normal UDP behaviour under loss — reproduce it on a bad network, not office Wi-Fi. A page frozen for a minute is TCP waiting on retransmissions; put that wait in the bug report as a number.

Layers: which level to look at

"It doesn't work" has a dozen causes at different levels, so networks are described in layers: the academic OSI model gives seven, the working TCP/IP stack four. Learning them by heart is pointless; the value is assigning a symptom to a level:

  • application — HTTP and DNS: 404, 500, wrong data in the answer;
  • transport — TCP, UDP, ports: "connection reset", timeouts;
  • network — IP and routes: "host unreachable";
  • link and physical — Wi-Fi and cables: the internet is gone.

One rule follows: don't fix the top until the bottom is checked. Hence the jargon — an L4 balancer works with ports, an L7 one with URLs.

Proxies and VPNs

Your screen says the site can't be reached, your colleague opens the same address — the difference is how the machine reaches the network.

A proxy is an intermediary your requests pass through; on the far side a load balancer, not the application, accepts the connection. So some browser errors come from something else: 500 means the application fell over inside, while 502 and 504 usually come from the intermediary — "whoever was supposed to answer didn't".

A VPN is an encrypted tunnel into another network. Testers meet it twice: without it there is no route to an environment in a private network; and as a geography check, since language and currency follow the address you came out of. The flip side is a VPN left on: half the "floating" price and language defects come from that.

What to look at

No guessing needed — all of it is visible.

  • The Network tab in DevTools is the first stop: is there a row, what status, how long.
  • ping address — do packets reach the machine. Silence is not a verdict: probes are often blocked by policy while the service is alive.
  • curl -v telnet://10.2.14.7:8080 (or telnet 10.2.14.7 8080) — is anyone accepting connections there. Three outcomes, three diagnoses: Connected — the port is open; Connection refused — nobody is listening, the application didn't start; silence until the timeout — a firewall rule drops the packets.
  • Sniffers — Wireshark shows the traffic itself, Fiddler sits inside the HTTP exchange and rewrites requests.

Where half a day goes

  • Filing a defect against an application that never saw the request. No row in the Network tab, or one without a status — fix availability instead.
  • Looking at the wrong environment. The bookmarked address is left from the previous task; the tell is "the defect doesn't reproduce" — your build is a week old.
  • A cached name. The environment moved, your machine still goes to the old address: you have the old version, everyone else the new one. nslookup and hosts settle it.
  • Reading a 502 as a 500. "The server is not responding" on screen is often written by the intermediary.

In short

  • A connection comes up to an address-and-port pair; DNS turns the name into the address, and hosts comes first.
  • TCP guarantees delivery and order at the price of a handshake; UDP is fast and promises nothing — loss in voice and video is normal.
  • Layers exist so you don't fix the top before the bottom is checked.
  • The fragment after # never reaches the server: such a defect is always browser-side.
  • A 500 comes from the application; 502 and 504 usually from an intermediary.