A server is reached at one address and reaches out from another, and for most things running on the internet today, those two addresses aren’t even on the same machine.
Most of the time this never matters. The two addresses do their jobs quietly and you never have to think about either one. Then one day something checks the address your server leaves from — a firewall, an allow list — and the address you’d naturally reach for turns out to be the wrong one.
So it’s worth knowing there are two, where each comes from, and how to find the one that actually matters. None of this is complicated once you can see it.
Two doors, not one
Picture a building. People arrive through the front door. Deliveries and staff leave through a door round the back. Same building, two doors, and what’s written on each is not the same.
A server is like that. There’s the address people use to reach it, and there’s the address it uses when it goes out and talks to something else. We almost always look at the first one, because it’s the address we hand out — the one in the link, the one you’d look up. The second one we forget exists until it bites.
The way in
When someone visits your site, the first thing their computer does is look up the name. DNS — the internet’s phone book — turns a name like example.com into an address. The small tool people reach for to do this by hand is dig: you give it a name, it reads back the address.
Here’s the part that catches people out. For most modern sites, that address isn’t your server at all. It’s a CDN edge — think of it as a front desk that sits in front of your real machine and greets every visitor first. These front desks are scattered around the world, and they all answer to the same address; you simply reach whichever one is closest to you. (That trick — one address, many machines, you get the nearest — is called anycast.)
So when you look up a site and get back something like 104.18.0.1, you’re almost always looking at the front desk, not the building behind it.
The way out
Now turn it around. Your server wants to call someone else’s API, or pull down a file. This time it starts the conversation, and its request has to leave the building.
On most cloud setups it leaves through a shared back door called a NAT gateway. The gateway does one quietly important thing: it rewrites the “from” address on everything passing through, so the outside world sees the gateway, not the individual server behind it. A whole fleet of servers usually shares just a handful of these doors.
Which means the address the other side actually sees — the one stamped on your requests as they arrive — is the gateway’s. Not your server’s, and certainly not the front desk’s.
The address that gets checked
Plenty of systems only care about where you came from — the outbound address. The common ones:
| System | The address it looks at |
|---|---|
| IP allow list | the address your request arrives from |
| Firewall (incoming rules) | the same — the source of the connection |
| Access and audit logs | who connected, recorded by source address |
| Geolocation | where that source address sits in the world |
| Per-IP rate limits | counts kept against the source address |
The clearest example is an allow list — a service that only accepts connections from a set of approved addresses. The address it checks is the one on your packets as they land there, which is your gateway’s. The front-desk address you’d get from a name lookup plays no part in it.
This is why pasting the result of a name lookup into an allow list quietly does nothing useful: right name, wrong direction.
Finding the address that matters
So how do you get the outbound address — the one that actually gets checked?
The tempting move is to look up the hostname and copy what comes back. That hands you the way in — the front desk — which is the one address guaranteed not to help here.
Two ways that do work. The first: read it straight from the gateway. Your NAT gateway has a fixed set of outbound addresses in its configuration. That’s the source of truth — allow those.
The second: ask from the inside. Run a request from the server itself to a service that simply echoes back the address it saw.
curl https://api.ipify.org
# 34.120.0.1 ← the gateway, not the front desk
Run the same lookup as a plain dig from your laptop and you’ll get a different answer — the front desk. The gap between those two answers is the whole point.
One last thing worth carrying. The outbound address is often a set, not a single value. Bigger setups run several gateways — sometimes one per region — and your traffic might leave through any of them. When you fill in an allow list, you usually need all of them, not the first one you happened to find.
A name tells you where to knock. It says nothing about the door you’ll come out of.