"What IP is this website on?" comes up constantly: you're writing a firewall rule, debugging why one office can't reach a service, checking whether DNS has propagated after a migration, or trying to work out who actually hosts a site. The lookup itself takes seconds. Interpreting the answer, especially in a world where most websites sit behind CDNs and load balancers, is where people get tripped up.
This guide covers the lookup, the interpretation, and the verification.
Step 1. Resolve the domain
Open the DNS Lookup tool, enter the hostname, and select the A record type. The A record maps a hostname to an IPv4 address; for "what's the IP," it's the record you want.
Note the distinction from the WHOIS guide: here you query the exact hostname users connect to. www.example.com and example.com can resolve to completely different IPs, and api.example.com different again. Look up the one you actually care about.
From a terminal, dig is the standard:
dig +short example.com A
93.184.215.14
+short strips the output down to the answers. Drop it when you also want the TTL and which server answered. (nslookup example.com works too and ships on Windows, but dig gives you more control; if you want the full tour of record types and flags, see how to perform a DNS lookup.)
Step 2. Check IPv6 as well
A records are IPv4 only. Many sites also publish AAAA records for IPv6:
dig +short example.com AAAA
2606:2800:21f:cb07:6820:80da:af6b:8b2c
If you're writing firewall rules and only allow the IPv4 address, dual-stack clients that prefer IPv6 will behave differently from what you expect. Check both, always.
If the A query returns nothing but the site clearly loads, query CNAME: the hostname may be an alias (www.example.com → example.com, or shop.example.com → shops.myshopify.com) and the A record lives at the target. dig without +short shows the full resolution chain, CNAME hops included.
Step 3. Expect multiple IPs, and understand why
A single hostname returning several A records is normal:
dig +short google.com A
142.250.187.206
142.250.187.174
...
Multiple records usually mean round-robin DNS load balancing: clients pick among the addresses, spreading load. Two consequences matter in practice:
- Firewall rules need every address, not just the first one you saw. Better still, ask the provider for a published IP range, because individual records change.
- Repeated lookups may return different answers: different orderings, or entirely different sets from different resolvers. That's load balancing and geo-DNS working as designed, not an inconsistency to debug.
To see whether different resolvers give different answers, query a few explicitly:
dig +short example.com @8.8.8.8 dig +short example.com @1.1.1.1
Differences here are also what you watch during a migration, and if you want to be told when records change rather than checking by hand, that's exactly what a DNS record drift monitor is for.
Step 4. Work out whether you're looking at a CDN
This is the big interpretation trap. If the site sits behind Cloudflare, Fastly, Akamai, or CloudFront (and a large share of the web does), the IP you resolved is the CDN's edge, not the origin server. Three checks reveal it quickly:
- Reverse DNS. Run the IP through the Reverse DNS Lookup tool, or
dig +short -x 93.184.215.14. A PTR record like...cloudfront.netor...fastly.netnames the CDN outright. - Geolocation/ownership. The IP Geolocation tool shows the network that owns the address. "Cloudflare, Inc." as the organisation means edge, not origin.
- CNAME chain. The full
digoutput often shows the hostname aliasing into a CDN domain.
Why it matters:
- Allowlisting a CDN edge IP is fragile. Edge IPs rotate and are shared across thousands of sites. Use the CDN's published ranges (Cloudflare, AWS, and Fastly all publish theirs) instead of whatever resolved today.
- You haven't found the host. "Who hosts this site" can't be answered from an edge IP; the origin is deliberately hidden behind it.
- Geolocation of an anycast edge is nearly meaningless for locating the actual server: anycast announces the same IP from many cities, and you'll geolocate whichever edge is nearest the lookup.
If the resolved IP belongs to a regular hosting provider (DigitalOcean, Hetzner, OVH, an AWS EC2 range without CloudFront in front), you're likely looking at the origin itself, and the IP is meaningfully stable.
Step 5. Verify connectivity to the IP
A DNS answer proves a record exists; it doesn't prove the address is reachable from where you stand. Close the loop with a ping test:
- Replies with sane latency: the address is up and routable from your vantage point.
- 100% packet loss: not necessarily down. Many production hosts and most CDNs drop or deprioritise ICMP. If ping fails but the site loads, the server is simply ignoring ping; test the actual port instead:
curl -sv --connect-timeout 5 https://example.com -o /dev/null nc -zv 93.184.215.14 443
A TCP connect to port 443 succeeding is the answer that actually matters for a web service.
One more verification trick: to test a specific IP behind a load-balanced or migrating hostname, pin it with curl's --resolve:
curl -sv --resolve example.com:443:93.184.215.14 https://example.com -o /dev/null
This sends a real HTTPS request to that exact IP with the right Host/SNI, the cleanest way to confirm a new server works before DNS cuts over.
Common mistakes
Looking up the apex when you mean www (or vice versa). They're independent records. Resolve the exact hostname from the URL.
Hardcoding a resolved IP. Records behind load balancers and CDNs change without notice. Use hostnames in configs wherever possible; where a literal IP is unavoidable, use published provider ranges and re-verify on a schedule.
Trusting your local cache during a migration. Your resolver may serve a cached answer for up to the record's TTL. Query an external resolver (@8.8.8.8) or use the DNS Lookup tool, which queries live, to see the current published value.
Reading CDN geolocation as server location. Anycast means the "location" of a Cloudflare IP is wherever the nearest edge is. Only origin IPs geolocate meaningfully.
Declaring an IP down because ping fails. ICMP is widely filtered. Test the service port with curl or netcat before escalating.
TL;DR
- Open the DNS Lookup tool (or
dig +short example.com A) and resolve the exact hostname. - Check AAAA for IPv6 too; check CNAME if A comes back empty.
- Multiple IPs = load balancing. Firewall rules need all of them, ideally the provider's published range.
- Run the IP through reverse DNS and geolocation; if it's a CDN edge, you haven't found the origin and shouldn't pin it.
- Verify with a ping test, and fall back to a TCP/HTTPS check when ICMP is filtered.