• 127.0.0.1, nicknamed localhost, always means "this machine," never any other device.


• Traffic sent to it loops back inside your own computer. It never reaches your network card, your router, or the internet.


• The whole 127.0.0.0/8 block is reserved for this, but 127.0.0.1 is the address everyone actually uses.


• localhost is just a hostname your computer resolves to 127.0.0.1 on its own, no network lookup involved.

This is why a local web server (VS Code's Live Server, or anything running at http://localhost:3000) is only reachable from the same machine it runs on. Nobody else on your network, or the internet, can reach it at that address.

• Assigned locally by your router (via DHCP) to every device that joins the network: laptop, phone, printer, smart speaker.


• Only has to be unique inside your own network, not unique in the world. Millions of home routers all hand 192.168.1.14 to somebody.


• Not routable on the open internet. A private address by itself cannot be reached from outside the network it belongs to.

• Globally unique. No two devices on the internet hold the same public IP at the same moment.


• Assigned by your ISP to your router, not to any single device inside your home.


• This is the address a website actually sees when you visit it. Every device behind your router shares it.

NAT is the trick that lets many private addresses share one public address.

• Outgoing: the router swaps your private address and port for its own public address and a new port, and writes the swap down in a translation table.


• Incoming: a reply arrives addressed to that public address and port. The router checks the table and forwards it to the right device inside.

• The problem: one origin server in, say, Virginia is slow to reach from Tokyo or Sao Paulo. Distance and network hops add delay.


• The fix: copies of a site's files (images, video, scripts, cached pages) are stored on many servers spread around the world, called edge servers.


• Your request gets routed to the nearest edge server instead of the original origin, so most of what you load never has to travel far.


• Also spreads out load and adds resilience: the origin server is not hit directly by every visitor on earth.


• Examples: Cloudflare, Akamai, Fastly, Amazon CloudFront.

Pinging www.sfc.keio.ac.jp (Keio University, Japan) from a laptop in the US:

PING dh9uikqsvnji3.cloudfront.net (18.172.170.14): 56 data bytes
64 bytes from 18.172.170.14: icmp_seq=0 ttl=245 time=5.661 ms
64 bytes from 18.172.170.14: icmp_seq=1 ttl=245 time=4.509 ms
64 bytes from 18.172.170.14: icmp_seq=2 ttl=245 time=4.166 ms
64 bytes from 18.172.170.14: icmp_seq=3 ttl=245 time=4.407 ms
64 bytes from 18.172.170.14: icmp_seq=4 ttl=245 time=4.191 ms
--- dh9uikqsvnji3.cloudfront.net ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.166/4.587/5.661/0.552 ms

• Keio's DNS record for www.sfc.keio.ac.jp is a CNAME alias pointing at dh9uikqsvnji3.cloudfront.net, Amazon's auto-generated hostname for their CloudFront distribution.


• ping follows that chain and reports the CloudFront hostname it lands on, then the edge server's IP, not a machine physically on Keio's campus.


• The ~4–5 ms round trip is telling. It is far too fast for a real trip to Japan (which typically runs 100–150 ms from the US west coast). The reply is coming from a nearby CloudFront edge location instead.

To see the DNS chain directly: dig www.sfc.keio.ac.jp. To see CDN headers on the real HTTP response: curl -I https://www.sfc.keio.ac.jp.

% dig www.sfc.keio.ac.jp
...

;; QUESTION SECTION:
;www.sfc.keio.ac.jp.        IN  A

;; ANSWER SECTION:
www.sfc.keio.ac.jp.     10800 IN CNAME dh9uikqsvnji3.cloudfront.net.
dh9uikqsvnji3.cloudfront.net. 60 IN A   3.163.24.7
dh9uikqsvnji3.cloudfront.net. 60 IN A   3.163.24.126
dh9uikqsvnji3.cloudfront.net. 60 IN A   3.163.24.49
dh9uikqsvnji3.cloudfront.net. 60 IN A   3.163.24.107

;; Query time: 168 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

• The ANSWER SECTION is the whole alias chain resolved in one shot: the CNAME first, then four separate A records (real IP addresses) for the CloudFront hostname it points to.


• Four IP addresses for one name is DNS-level load balancing and redundancy: the resolver hands back several addresses, and a client can fall back to another if one does not respond. This is not anycast, these are four distinct addresses, not one address announced from everywhere.


• The two TTLs (10800 and 60). The CNAME's TTL is 10800 seconds (3 hours): Keio's alias to CloudFront almost never changes. The A records' TTL is only 60 seconds: Amazon wants to reshuffle which edge machines answer for that hostname quickly, without waiting hours for old answers to expire.


• Query time: 168 msec, SERVER: 8.8.8.8 is the cost of the DNS lookup itself, done against Google's public resolver, separate from and before any actual connection to a web server.

A cached edge response can look perfectly healthy even if the real origin server is completely offline. ping alone cannot tell the difference.

• Check cache headers: curl -I https://www.sfc.keio.ac.jp and look for x-cache: Hit from cloudfront (served from cache, tells you nothing about origin) versus x-cache: Miss from cloudfront (the edge just contacted origin and got an answer).


• Add a cache-busting query string, e.g. ?nocache=12345, to force a request the edge is unlikely to have cached, so it has to check the origin.


• A 5xx response (502, 503, 504) from the CDN generally means the edge tried to reach the origin and failed.


• For real monitoring, a multi-region uptime checker (probing from several places at once) beats a single ping from your own machine.

%curl -I https://www.sfc.keio.ac.jp
...
HTTP/2 301
server: CloudFront
content-length: 0
location: https://www.keio.ac.jp/ja/sfc/
x-cache: Hit from cloudfront
via: 1.1 ac695892d6ed07904483819bdb88134e.cloudfront.net (CloudFront)
x-amz-cf-pop: HIO52-P2
x-amz-cf-id: J_1ub4-jF8LdPNN16ptRAnb813nqBCojomRayElIFFdTxJ0wh4unMg==
age: 17
...

• HTTP/2 301 means the site is not answering with a page at all, it is redirecting www.sfc.keio.ac.jp to www.keio.ac.jp/ja/sfc/. content-length: 0 follows: a redirect carries no body.


• x-cache: Hit from cloudfront means this exact redirect response was already sitting in the edge's cache. CloudFront did not need to ask Keio's origin anything to answer this request, so this response says nothing about whether the origin is currently up.


• age: 17 is how many seconds this response has been cached since it was last fetched or generated. Small means recently cached; a large number would mean it has sat there unrefreshed for a while.


• x-amz-cf-pop: HIO52-P2 is the edge location's Point-of-Presence code. HIO is the airport code for Hillsboro/Portland, most likely what the earlier ~4–5 ms ping time implied: the reply came from an edge node near Portland, not from Japan.

Keio is not unusual. MIT and most universities with a global audience sit behind a CDN too.

• Global, spiky audience: admissions season, a viral research story, a registration deadline. Traffic surges from every time zone at once, and the CDN absorbs it instead of the university's own servers.


• DDoS and security: public .edu sites are constantly scanned and occasionally targeted. CDNs bundle DDoS mitigation, a web application firewall, TLS termination, and bot filtering.


• Cost and staffing: a university IT team cannot out-build Amazon's, Akamai's, or Cloudflare's edge network. Renting it is far cheaper than building it.


• Reputation and reach: universities recruit internationally. A page that loads in milliseconds instead of a few hundred, for an applicant anywhere in the world, is part of the impression the institution makes.


• Resilience: caching shields the origin from load and from most short outages, so a hiccup on campus infrastructure does not necessarily take the public site down with it.

• Normally, one IP address points to one physical machine in one place.


• With anycast, the exact same IP address is announced from many locations at once, using the routing protocol that connects networks together (BGP).


• The network itself decides which announcement is closest and sends your request there. No lookup or redirect on your end.


• Used for CDNs, DNS root servers, and DDoS resilience, since attack traffic gets spread across every announcing location instead of overwhelming one.

The internet has 13 lettered root servers, A through M. Every one of them is a real example of anycast running today.

• Most of the 13 letters are anycast: the same IP address is announced from hundreds of physical sites around the world, not one machine per letter.


• This is arguably the original, foundational anycast deployment, in production long before CDNs adopted the same trick.


• It is how a literal handful of "root server" addresses can serve the entire internet's DNS lookups from hundreds of physical sites, without any single site being overwhelmed.

Long before anycast routing existed, artists were already drawing what it feels like: the same identity, held open in more than one place at once, folding a part that contains into a part that is contained.

• Your private IP gets you onto your home network. NAT turns that into one shared public IP the rest of the internet can see.


• A VPN does not change any of that locally, it just relocates the public IP the destination sees, further down the path.


• Once a request reaches the internet, a CDN decides which physical server should actually answer it, usually one geographically close to you.


• Anycast is often the mechanism that makes that choice automatic: many servers, one address, the network itself routes you to the nearest one.