Tech & AI, Explained

ip-addresses

12 min read

IP addresses

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: The numeric address of every device on the internet — like a phone number, but for computers. IPv4 is the old short-form (76.76.21.21); IPv6 is the new long-form (2606:4700::1); private addresses (192.168.1.x) live inside your home network.

In plain English

Every device that talks to other devices over a network needs an address. Computers don’t use names; computers use numbers. An IP address is that number.

Two flavors in use today:

  • IPv4 (since 1981) — a 32-bit number, written as four decimal numbers separated by dots, each 0-255. Example: 76.76.21.21 (Vercel’s edge servers).
  • IPv6 (since 1998, now widespread) — a 128-bit number, written as eight hex groups separated by colons. Example: 2606:4700:3032::ac43:bb01 (with :: shorthand for a run of zeros).

IPv4 has ~4.3 billion possible addresses. The internet ran out around 2011. IPv6 has 340 undecillion (3.4 × 10³⁸) addresses — effectively unlimited. Both run side-by-side in 2026: most devices have both, and the network uses whichever works.

You almost never deal with IP addresses directly. DNS translates names like vercel.com to IPs behind the scenes. You see them when:

  • DNS is broken (the browser shows the IP it tried)
  • You’re configuring DNS records (A for IPv4, AAAA for IPv6)
  • You’re debugging network issues (ping, traceroute)
  • You’re allowlisting / blocklisting (firewalls, rate limits)
  • You’re working with logs (every request comes with the client’s IP)

This entry covers the protocol view. For DNS resolution (how names become IPs), see DNS — deep dive and Domains and DNS.

Why it matters

Three concrete reasons IP knowledge pays off:

  1. It demystifies DNS, hosting, and firewalls. When you read “this domain has an A record pointing to 76.76.21.21,” knowing what that means turns black magic into mechanics.

  2. Geolocation and rate limiting use IPs. Per-IP request limits, “users from country X get redirected,” logs telling you who hit your API — all keyed by IP.

  3. Networking debug skills. “Ping doesn’t work but HTTPS does” is a routing question. “All my requests come from 192.168.x.x” is a NAT question. Knowing the layers helps.

The trade-off: IP addressing has decades of complexity (subnet masks, classes, CIDR, NAT, IPv6 transition mechanisms). For a webapp developer, ~10% of that is useful daily.

IPv4 — the classic

A 32-bit number in four octets:

192.168.1.42
└──┬─┘ └──┬───┘
   ↑       └── 32 bits total
   each octet is 0-255 (8 bits)

There are ~4.3 billion theoretical addresses, but huge ranges are reserved (private networks, loopback, multicast). Usable public addresses: ~3.7 billion. With billions of devices now connected, this is gone.

Reading “76.76.21.21” — that’s a SPECIFIC computer (or load-balancer endpoint) somewhere on the public internet. Anyone in the world can try to reach it.

Special IPv4 ranges

RangeWhat it’s for
10.0.0.0/8Private (large organizations)
172.16.0.0/12Private (medium)
192.168.0.0/16Private (home networks)
127.0.0.0/8Loopback (your own machine — 127.0.0.1 = “localhost”)
169.254.0.0/16Link-local (no DHCP, “self-assigned”)
0.0.0.0”All interfaces” — used when listening
255.255.255.255Broadcast
224.0.0.0/4Multicast

The /N syntax is CIDR notation — how many leading bits are fixed. /24 means “first 24 bits identify the network; last 8 are individual addresses.” Your home router uses 192.168.1.0/24 typically (256 possible local addresses).

IPv6 — the future (and present)

A 128-bit number, written as eight hex groups:

2606:4700:3032:0000:0000:0000:ac43:bb01

Shorthand rules:

  • Leading zeros in a group can be dropped: 0000 → 0
  • One sequence of all-zero groups can be replaced with :: (only once): 2606:4700:3032:0000:0000:0000:ac43:bb01 → 2606:4700:3032::ac43:bb01

URLs with IPv6 need brackets: https://[2606:4700:3032::ac43:bb01]/.

Special IPv6 ranges

RangeWhat it’s for
::1/128Loopback (IPv6’s 127.0.0.1)
fe80::/10Link-local
fc00::/7Unique local (IPv6’s private space)
::/0Default route
2000::/3Globally routable

In modern environments, the average user device has at least one IPv6 address — mobile carriers heavily use IPv6, Comcast and Verizon home connections often default to IPv6. Vercel, Cloudflare, AWS all serve over both.

For domain configuration, you set:

  • An A record for the IPv4 address
  • An AAAA record for the IPv6 address (called “quad-A” — four As to match four times the bits)

Modern hosts auto-set both for you.

A concrete example: what you see in real logs

A typical Vercel function log line:

[2026-06-19T14:32:01.234Z] GET /api/posts 200 - 234ms - IP: 2606:4700:3032::ac43:bb01

The IP: field is who hit your API. In this case, IPv6. Another request might show:

[2026-06-19T14:32:05.001Z] POST /api/comments 201 - 432ms - IP: 76.76.21.21

That’s IPv4. Both work; both are valid.

For rate limiting “max 100 requests per IP per hour,” you key by the address string. IPv6 makes “per IP” tricky — one user can have many IPv6 addresses (often a /64 block, which is 18 quintillion addresses). Rate-limit by /64 prefix for IPv6 instead of full address.

Private vs public

A private IP is one that’s only routable inside a local network. Your laptop’s 192.168.1.x address is private — no one outside your house can reach it directly. Your router has both a private inner address AND a public outer address.

NAT (Network Address Translation) bridges them: outgoing packets get the router’s public IP swapped in; incoming responses get translated back to the private IP. This is how a household with 20 devices shares ONE public IPv4 address.

NAT is also why a server inside your network isn’t reachable from the outside unless you explicitly open a port (port forwarding) or use a tunneling service (ngrok, Cloudflare Tunnel, Tailscale).

IPv6 mostly removes NAT — there are enough addresses for every device to have a globally unique one. But many ISPs still NAT IPv6 for legacy reasons.

Loopback — 127.0.0.1 and ::1

The special address that means “this same machine.” When you run npm run dev and visit http://localhost:3000, you’re hitting 127.0.0.1:3000 — your own computer.

Useful gotcha: localhost and 127.0.0.1 are usually the same, but on some systems they differ. localhost is a DNS name that resolves to a loopback IP. On most setups it’s 127.0.0.1 (IPv4), but on some IPv6-preferring systems it resolves to ::1 first. Subtle bugs when an app binds to one but the client tries the other.

How a device gets its IP

Two common mechanisms:

1. DHCP (Dynamic Host Configuration Protocol)

When your laptop joins WiFi, it asks the router “what IP can I use?” The router (DHCP server) assigns one from its pool (typically 192.168.1.100-192.168.1.200). The IP can change next time you connect.

2. Static assignment

A server in production usually has a fixed IP — explicitly configured, not assigned dynamically. Vercel functions, Supabase databases all have stable public IPs.

For typical webapp work, you don’t configure either. The cloud provider handles it.

Geolocation — where IPs map to places

Services maintain databases of “this IP range belongs to this country / city / ISP.” Cloudflare, MaxMind, ipinfo.io all sell or freely offer this data.

Accuracy:

  • Country — usually correct (~99%)
  • City — often correct (~80%); can be off by metro area
  • Street-level — generally NOT possible from IP alone

Common uses:

  • Show users their local timezone
  • Redirect to language-appropriate site
  • Block users from sanctioned regions (compliance)
  • Detect fraud (“login from a country you’ve never used”)

For Vercel: req.geo.country, req.geo.city are available in middleware automatically (powered by Vercel’s edge GeoIP). Similar in Cloudflare Workers via req.cf.country.

Caveats:

  • VPNs and proxies mask the real location. A user in Australia using a US VPN appears American.
  • Mobile IPs are noisy — a phone might be geolocated to its carrier’s HQ, not the user’s location.
  • Corporate networks route through their HQ — a remote employee may appear to be in the office’s city.

Never make critical decisions on GeoIP alone.

What IP YOU see depends on where you’re looking

A request as it travels:

User's device (private IP 192.168.1.5)
    ↓ (NAT to router's public IP 203.0.113.42)
Router
    ↓ (potentially through ISP-level CGNAT)
ISP
    ↓
Public internet
    ↓ (HTTPS to Cloudflare/Vercel edge)
Edge node (IP 76.76.21.21)
    ↓ (proxied to origin server)
Origin server (IP 100.64.x.x — internal cloud)

What “the user’s IP” looks like depends on which layer you’re at:

  • The user’s laptop sees its own IP as 192.168.1.5
  • The router records 192.168.1.5
  • The ISP sees 203.0.113.42
  • Cloudflare sees 203.0.113.42 (the real public IP)
  • Your origin function sees the EDGE’s IP unless headers are read

Origin servers behind a CDN need to read the X-Forwarded-For or CF-Connecting-IP header to learn the real client IP. Otherwise everyone looks like the CDN.

Common gotchas

  • req.ip is unreliable behind a proxy. Frameworks see the proxy’s IP, not the user’s. Read X-Forwarded-For (the trusted chain) or platform-specific headers (CF-Connecting-IP for Cloudflare, Vercel-Forwarded-For for Vercel).

  • X-Forwarded-For can be spoofed. A user can send this header in their original request. Only trust it if your CDN/proxy strips/replaces it before your origin. Vercel and Cloudflare do this; raw servers don’t.

  • IPv4 exhaustion is real. New cloud regions sometimes can’t get IPv4 addresses; some workloads are IPv6-only.

  • IPv6 is ::1-style; URLs need brackets. http://[::1]:3000, not http://::1:3000 (the latter is parsed as host ::1, port 3000 — works in some contexts, fails in others).

  • localhost may resolve to IPv6 first. A server bound to IPv4 (0.0.0.0:3000) but accessed via localhost might fail on systems that try ::1 first. Bind to both or use 127.0.0.1 explicitly.

  • Per-IP rate limiting is brittle. Many users share an IP (corporate NAT, mobile carriers). Some users have many IPs (mobile changing networks, IPv6 privacy extensions). Pure per-IP limits punish honest users while sophisticated abusers rotate IPs.

  • Cloudflare’s cf-connecting-ip is the canonical client IP behind Cloudflare. Use it; don’t trust X-Forwarded-For blindly.

  • Logging full IPs has GDPR implications. EU privacy rules treat IPs as personal data. Hash or truncate when logging if you don’t need the full address.

  • IPv6 privacy extensions mean a single device cycles through many addresses for privacy. The “permanent” address may not be what you see in a single session.

  • CGNAT (Carrier-Grade NAT) assigns multiple users to one public IPv4. From your server’s view, two users share an IP. Rate limiting per IP punishes both.

  • Public IPs change. A residential connection’s IP changes occasionally (when the modem reboots, when the lease expires). Don’t hardcode “user’s IP” as a long-term identifier.

  • The cloud SHARES IPs across customers. A blocked-by-someone IP may rotate to you. Most cloud providers handle this gracefully; some get incoming traffic meant for the previous tenant.

  • DNS-over-HTTPS (DoH) hides DNS from the network. Used by Firefox and Chrome by default in some markets. Means your DNS queries don’t traverse the local network. Doesn’t affect IP itself, but changes what intermediate routers see.

  • ping doesn’t always work — some servers block ICMP for security. “Can’t ping = down” is wrong. Use curl -I https://example.com for HTTP-layer connectivity.

  • traceroute may stop reporting mid-route. Many routers don’t respond to traceroute pings. The blanks aren’t necessarily problems.

  • A public IP doesn’t equal “reachable.” Even with a public IP, firewalls and security groups can block traffic. Cloud servers need explicit allow rules.

  • Multiple records per name are common. A domain often has many A/AAAA records (for load balancing). DNS rotates through them — each request might get a different IP. This is normal.

  • Reverse DNS (PTR records) is for IP-to-name lookups. Mostly used for email anti-spam (“this IP claims to be mail.example.com; is it really?”). Not relevant for webapp users.

  • CGN exit IPs are sometimes shared with VPNs. A user on a corporate network and a VPN user might have IPs from the same range. Don’t conflate.

  • IPv4 addresses look like dates / version numbers / phone numbers. 1.2.3.4 is an IP. 192.168.1.100 is an IP. Don’t accidentally treat them as version strings or natural numbers.

  • 0.0.0.0 listens on ALL interfaces. A server bound to 0.0.0.0 accepts connections from any network interface. 127.0.0.1 only loopback. 192.168.1.x only local network. Choose deliberately.

  • 255.255.255.255 is the broadcast. Used by DHCP to discover servers. Rarely seen in application code.

  • CIDR notation is concise but cryptic. 10.0.0.0/8 = “addresses 10.0.0.0 through 10.255.255.255.” 192.168.1.0/24 = “192.168.1.0 through 192.168.1.255.” Subnet calculators help when needed.

  • IPv6 link-local addresses start with fe80:. They’re per-interface; not routed. Used by IPv6 auto-configuration.

  • The internet routing protocol (BGP) sometimes breaks. Tier-1 ISP misconfigurations can route entire networks to wrong places. Rare but spectacular when it happens (e.g., Cloudflare’s June 2024 outage).

  • VPN exit nodes look like the user is elsewhere. A user appearing in Iceland via a Mullvad VPN is genuinely connecting from there at the IP layer. Geolocation reflects this.

  • whois can lookup the owner of an IP range. Useful for “is this traffic from AWS / a known bot operator / a residential ISP.”

  • The IP an LLM service sees is yours, including all calls from your code. Anthropic, OpenAI APIs see the IP of your server (Vercel function, your machine). For rate-limit purposes, the unit is “your origin,” not “the user’s browser.”

  • X-Real-IP is a legacy header, less standardized than X-Forwarded-For. Some nginx configs set it; most modern stacks prefer the latter.

  • Vercel’s preview deployments are accessible from any public IP. Don’t rely on “obscure preview URL” as security. Use Vercel’s password protection or auth gates if needed.

See also

Sources

Graph View

Backlinks