[ GF.dev ] All Tools →

What is My IP? Understanding Public vs Private IP Addresses

Published 2026-03-29 · Last modified 2026-03-29

Every device on the internet needs an IP address, but not all IP addresses are created equal. Your laptop has one, your router has one, your web server has at least two — and they're almost certainly different. Understanding the distinction between public and private IP addresses is fundamental to network troubleshooting, firewall configuration, and server administration. Get it wrong and you'll write firewall rules that don't work, configure services that listen on the wrong interface, or debug connectivity problems for hours before realizing you're looking at the wrong address.

Public IP Addresses

A public IP address is globally unique and routable on the internet. When someone visits your website, their browser connects to your server's public IP address. When you visit a website, the remote server sees your public IP address. Check yours right now with our What Is My IP tool.

Key characteristics of public IPs:

For servers, your public IP is what DNS records point to. When you create an A record like example.com → 203.0.113.50, that's your server's public IP. If it changes (common with dynamic IPs), your site goes down until DNS is updated — which is why static IPs or elastic IPs are essential for production servers.

Private IP Addresses

Private IP addresses are reserved for use within local networks and are not routable on the public internet. The Internet Assigned Numbers Authority (IANA) designated three ranges for private use in RFC 1918:

Thousands of networks can reuse the same private IP ranges simultaneously because these addresses never appear on the public internet. Your home network's 192.168.1.100 is completely different from your neighbor's 192.168.1.100.

NAT: Bridging Public and Private

Network Address Translation (NAT) is the technology that allows devices with private IPs to communicate over the public internet. Your home router performs NAT continuously: it receives outgoing packets from devices on your local network (e.g., 192.168.1.100), rewrites the source address to your single public IP, and forwards them to the internet. When responses come back, the router reverses the translation and routes them to the correct internal device.

NAT is the reason that millions of devices can share a relatively small pool of public IPv4 addresses. It's also the reason you can't directly connect to a device behind NAT from the outside — the public IP belongs to the router, not the device. To make a service accessible from the internet, you need port forwarding (for home/small office setups) or a public IP assigned directly (for cloud servers).

NAT in Cloud Environments

Cloud providers add a layer of abstraction:

A common misconfiguration: binding your web server to the instance's private IP instead of 0.0.0.0. The server starts without errors but is unreachable from the internet because incoming traffic arrives via the NAT-mapped public IP, which doesn't match the bound private IP. If you're experiencing this, our Port Scanner will show the port as filtered or closed from the outside, even though ss -tlnp on the server shows the service is listening.

IPv4 vs IPv6

The public/private distinction exists primarily because of IPv4 address exhaustion. With only ~4.3 billion IPv4 addresses and far more connected devices, NAT and private addressing were necessary workarounds.

IPv6 solves this with a vastly larger address space (340 undecillion addresses), theoretically eliminating the need for NAT. In IPv6, every device can have a globally unique address. However, IPv6 adoption is still partial — as of 2026, roughly 45% of internet traffic uses IPv6. For now, you need to handle both:

Practical Applications for Sysadmins

Firewall Configuration

When writing firewall rules, always use the correct address type:

# Allow SSH from your office's public IP
ufw allow from 203.0.113.10 to any port 22

# Allow database access from application server (private IP)
ufw allow from 10.0.1.20 to any port 5432

DNS and Hosting

DNS A records must point to public IPs. Pointing an A record to a private IP like 10.0.1.45 means browsers will try to connect to that private address — which won't exist on their local network, resulting in an immediate connection failure. Verify your DNS configuration with the DNS Lookup tool.

Troubleshooting Connectivity

When a user reports they can't reach your server:

  1. Confirm your server's public IP with What Is My IP (from the server itself).
  2. Verify DNS resolves to that IP using DNS Lookup.
  3. Run a Ping Test to check basic reachability.
  4. Use the Port Scanner to verify ports 80/443 are open.
  5. If everything passes, run a TTFB test to check whether the server is responding slowly rather than not at all.

VPN and Remote Access

When connected to a VPN, your public IP changes to the VPN server's address. This is useful for accessing geo-restricted resources or appearing to be on a company's network, but it can also cause confusion during troubleshooting. Always verify your current public IP with What Is My IP before debugging access issues — you may be connecting from an IP your server's firewall doesn't recognize.

Summary

The public/private IP distinction is one of networking's most fundamental concepts, yet it's the root cause of a surprising number of server configuration problems. Remember: your server's public IP is what the world sees (and what DNS points to), while its private IP is for internal communication within your network or VPC. Never mix them up in firewall rules, server bindings, or DNS records.

For a complete guide to diagnosing server and network issues, including TTFB analysis, header inspection, server signature hardening, and ping and port scanning workflows, see our Web Server Performance Troubleshooting pillar guide.