Reserved IP Blocks Explained: Private, CGNAT, and Loopback

Understand the most common reserved IP ranges (RFC1918 private IPs, CGNAT, loopback, link-local, and documentation ranges) and why they exist.

By Tudor Uzun

Founder and Senior Software Engineer, IP Trackers

Published June 3, 2026Updated August 26, 2026Editorial standards

Not every IP address is meant to be routed across the public internet. Large blocks are reserved for private networking, local testing, documentation, carrier translation, multicast, and other special purposes. Learning the reserved ranges saves time in troubleshooting because it lets you answer one of the first network questions quickly: is this address supposed to be public at all, or is it only meaningful inside a specific scope?

What reserved IP blocks actually are

Reserved IP blocks are address ranges that standards bodies and internet registries set aside for specific uses instead of normal public routing. Some are meant for local use only, such as the familiar private RFC 1918 ranges. Some are for documentation examples, so tutorials can show realistic addresses without pointing at real systems. Others exist because networking needs special behaviors like loopback, link-local configuration, carrier-grade NAT, multicast, or benchmarking.

The key idea is scope. An address can be perfectly valid inside one scope and meaningless or unroutable in another. A home router can use192.168.1.1 all day long, but that address should not appear on the open internet as your public identity. Once you learn the most common reserved ranges, many "why is this not working?" questions become easier immediately.

How to recognize what kind of address you have

The first step is simply to compare the address against known special ranges. On Windows you can inspect local interface addresses with:

ipconfig
route print
ping 127.0.0.1

On Linux or macOS, the equivalents are usually:

ip addr
ip route
ping 127.0.0.1

If the address belongs to a private, link-local, loopback, or CGNAT block, that already explains a lot. If it is a public-looking address, use our IP Address Lookup and ASN Lookup to see who owns it and where it sits in real routing context.

The most important reserved IPv4 ranges

• 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16: the private RFC 1918 ranges used inside homes, offices, labs, and VPNs.
• 100.64.0.0/10: shared address space for carrier-grade NAT, commonly seen when an ISP places subscribers behind a translation layer.
• 127.0.0.0/8: loopback, with 127.0.0.1 as the classic localhost address for testing services on the local machine.
• 169.254.0.0/16: IPv4 link-local addresses, often appearing when DHCP failed and a device self-assigned an APIPA address.
• 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24: documentation ranges from RFC 5737, intended for examples and guides.
• 198.18.0.0/15: benchmarking and inter-network device testing space, not for normal public use.
• 224.0.0.0/4: multicast space used for one-to-many traffic patterns and protocol discovery.

Two special values people overlook: 0.0.0.0 and broadcast

Not every important special-use address lives in a huge reserved block. The value 0.0.0.0 is often used to mean "unspecified" or "all interfaces," depending on context. You will see it in routing tables, service bindings, and startup states before a real address has been assigned.

Broadcast values matter too. In older IPv4 discussion you may see255.255.255.255 for limited broadcast, and subnet-specific broadcasts also exist within local networks. These are not ordinary host identities, which is why they should be read differently from a routable device address in logs or troubleshooting output.

Private addresses and why they exist

Private ranges are the reason millions of home networks can all use addresses like 192.168.0.1 without conflicting with one another. Inside a LAN, the router only needs the addresses to be unique within that private scope. When those devices access the internet, the router or firewall performs NAT so the outside world sees the public address instead.

That means a private IP tells you something about local topology, but not public identity. Seeing 192.168.1.20 in a screenshot does not tell you where on the internet that device lives. It only tells you the device is inside a local private network. If you want a clear comparison, read Public vs Private IP Addresses.

CGNAT ranges are special because they look routable to users

Carrier-grade NAT deserves separate attention because it confuses many users. The block 100.64.0.0/10 is not ordinary public space you control, but it may look unfamiliar enough that people assume it is a public address. In reality, ISPs use it to share a smaller pool of real public IPv4 addresses across many customers.

This matters for gaming, self-hosting, camera access, and port forwarding. If your WAN-side address falls in the CGNAT range, you likely do not have a directly reachable public IPv4 address even though the router still shows something that looks "outside" your private LAN. That is why our CGNAT IP Address Range and Port Forwarding Not Working Under CGNAT articles are so relevant in troubleshooting.

Loopback, link-local, and documentation blocks solve different problems

• Loopback is for talking to the local host itself. When you ping 127.0.0.1, you are testing the local TCP/IP stack, not the network cable or the router.
• Link-local is a fallback for local communication when DHCP or normal addressing is missing. It is often a symptom of a broken network path rather than a solution.
• Documentation space is for safe examples. If you see198.51.100.25 in a guide, it should be read as "this is a placeholder," not "this is a live host."

IPv6 has special-use ranges too

Even though this article focuses on the most commonly encountered IPv4 blocks, the same idea exists in IPv6. Link-local addresses under fe80::/10 are only valid on the local segment. Unique local addresses under fc00::/7 serve a private-network role similar in spirit to RFC 1918 space. Loopback still exists as ::1. So "special use" is not a historical IPv4 oddity; it is a normal part of how IP networking is organized across both protocol versions.

That matters when modern systems prefer IPv6 automatically. A user may think they are only dealing with ordinary private IPv4, while the host is also carrying IPv6 link-local or ULA addresses that affect discovery, routing, and troubleshooting.

Where reserved blocks matter in practice

• Home network troubleshooting. Knowing private vs public ranges helps you understand whether a device is visible only locally or actually reachable from outside.
• Router and firewall setup. NAT, port forwarding, and VPN configuration all depend on whether the relevant address is private, CGNAT, or truly public.
• Reading logs. If an application log shows127.0.0.1 or 169.254.x.x, that tells a very different story from a cloud-hosted public IP.
• Documentation and training. Reserved documentation ranges prevent examples from accidentally exposing or targeting real infrastructure.
• Security review. Distinguishing local-only addresses from internet-routable ones helps you prioritize exposure correctly.
• Abuse and fraud analysis. Shared address space, private ranges, and CGNAT all change how confidently you can associate activity with one subscriber or device.

Common mistakes and edge cases

• Assuming every unfamiliar address is public. Many troubleshooting errors start because a user sees a non-RFC 1918 range and assumes it must be globally routable.
• Confusing the router's WAN address with true public reachability. Under CGNAT, the router has an ISP-facing address that is still not directly yours on the public internet.
• Using real IPs in examples and screenshots. Documentation ranges exist so guides can stay realistic without accidentally naming a real server or customer.
• Treating 169.254.x.x as internet access. Link-local addressing often means the opposite: DHCP failed and the device never got normal upstream configuration.
• Forgetting IPv6 has its own special scopes. The same idea exists in IPv6 with unique local and link-local addressing, so "special use" is not only an IPv4 concept.
• Expecting multicast addresses to behave like host addresses. Multicast space is for group communication patterns, not ordinary device identity.

Useful IP Trackers tools for interpreting address ranges

• IP Address Lookup helps you confirm whether an address is truly public and what outside services see as your current identity.
• ASN Lookup shows which network is announcing a public block, which is useful when the address is not obviously reserved.
• WHOIS / RDAP Lookup adds registration context around a public prefix.
• Reverse DNS Lookup can reveal whether a public IP belongs to an ISP pool, cloud provider, or other managed infrastructure.
• Proxy Check helps classify whether the visible public IP looks like a VPN, proxy, or hosting environment rather than a normal consumer ISP address.

The classful history that explains the odd sizes

One detail bothers people once they notice it. The three private ranges are wildly different sizes and none of them is a round number: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. A /8, a /12, and a /16 look arbitrary. They are not. They are the shapes that made sense in the addressing system that existed when the reservation was written.

Before CIDR, IPv4 was divided into fixed classes, and the leading bits of an address determined both its class and its implied network size. Class A networks began 0 through 127 and carried a fixed 8-bit network part, giving 16 million hosts each. Class B ran 128 through 191 with a 16-bit network part and roughly 65,000 hosts. Class C ran 192 through 223 with a 24-bit network part and 254 usable hosts. Class D from 224 was multicast, and Class E from 240 was the reserved block discussed above. There were no prefix lengths to choose. The address itself told you its size.

Read the private ranges through that lens and the shapes resolve immediately. 10.0.0.0/8 is exactly one Class A network. 172.16.0.0/12 is exactly sixteen contiguous Class B networks. 192.168.0.0/16 is exactly 256 contiguous Class C networks. The reservation set aside one block of each class, sized in the units administrators of the day actually worked in, which is also why each range starts precisely where a class boundary sits.

Classful addressing was replaced by CIDR because it wasted enormous amounts of space. An organization needing 400 addresses was too large for a Class C and received a Class B, stranding 64,000 addresses. CIDR notation removed the fixed classes and let a prefix be any length, so that organization gets a /23 and nothing is wasted. The classes are gone from routing, but their fingerprints remain in the private ranges, in the habit of writing home networks as /24, and in the phrase "class C" still turning up in vendor documentation decades after it stopped meaning anything.

Why 192.168.x.x became the "home network" default everyone recognizes

RFC 1918 defines three private ranges of very different sizes, and all three are equally legal to use, but the world overwhelmingly settled on 192.168.x.x for home networks. The reason is historical accident plus consumer router defaults. Linksys, Netgear, TP-Link, D-Link, and most other consumer router brands shipped their first products with 192.168.0.1 or192.168.1.1 as the default gateway. Once those defaults reached tens of millions of homes, every other consumer router maker copied the same convention to avoid confusing customers.

The other two ranges have different practical uses. The10.0.0.0/8 block (16 million addresses) is the standard for medium-to-large corporate networks because it gives plenty of room for hundreds of subnets without renumbering. The172.16.0.0/12 block (1 million addresses) is less commonly seen by ordinary users but is used by some VPN clients, some Docker default networks, and some enterprise setups looking to avoid collision with the more popular ranges.

The full IANA special-purpose registry has more than you think

IANA maintains the authoritative list of special-purpose IPv4 and IPv6 ranges, and the IPv4 side currently contains over 25 entries — well beyond the famous private and loopback blocks. A few that are worth knowing because they show up in real logs and tools:

• 192.0.0.0/24: reserved for IETF protocol assignments, used by some tunneling and protocol experiments.
• 192.88.99.0/24: formerly used for 6to4 anycast relays, the old IPv6-over-IPv4 transition mechanism. The mechanism itself was deprecated in 2015, but you may still see the range referenced in older networking documentation.
• 240.0.0.0/4:the entire upper quarter of the IPv4 address space, marked "reserved for future use" since the 1980s. Periodically there are discussions about reclaiming it to extend IPv4's life, but it has never happened because too many old devices treat it as invalid.
• 233.252.0.0/24: a small piece of multicast space set aside for documentation examples, analogous to the IPv4 documentation ranges.

The point is not to memorize all of them. The point is to know that if you see an address that does not look like a normal public IP, the IANA special-purpose registry is the authoritative place to check what it means before you assume it is a typo or an error.

Why bogon filtering is a thing, and why it sometimes goes wrong

Network operators often configure their routers to drop traffic with source IPs in obviously invalid ranges — private RFC 1918 addresses, loopback, link-local, documentation ranges. These are called "bogon" filters and they exist to block spoofed traffic and misconfigured devices from leaking onto the public internet. A packet showing up at an ISP's border router claiming to be from 192.168.1.5 on the public side is nonsense and should be dropped.

The catch is that bogon lists need to be updated as IANA allocates previously unused ranges. There have been real cases — notably IPv4 ranges in the 100.x.x.x and 23.x.x.x space — where blocks were unreachable for some users for years after assignment because old bogon filters had never been updated to remove them. If a website works for everyone except a specific ISP, an out-of-date bogon filter on that ISP's border router is one of the more obscure but real possibilities.

Choosing a private range without creating a collision

All three RFC 1918 ranges are equally valid, so the choice looks arbitrary. It is not. The range you pick decides how much pain you feel the first time your network has to talk to somebody else's.

The problem is address overlap. NAT lets many networks reuse the same private addresses because those networks never meet. A VPN makes them meet. If your home LAN is 192.168.1.0/24 and you connect to an office VPN that also uses 192.168.1.0/24, your machine now has two plausible destinations for 192.168.1.50. It will pick one, almost always the local one, and the office resource at that address becomes silently unreachable while everything else works. The symptom is bizarre from the user side: the VPN reports connected, some internal sites load, one specific server never does.

This is why the popularity of 192.168.0.0/24 and 192.168.1.0/24 is a practical liability. They are the two most common home subnets on earth, so they are the two most likely to collide with whatever a remote worker is connecting from. Any network that expects inbound VPN users should avoid them on principle.

A few habits remove most of the risk:

• Pick a subnet from deep inside 10.0.0.0/8 with digits nobody would choose by accident, such as 10.83.140.0/24. There are 16 million addresses in that block and almost all of them are unused by consumer defaults.
• Avoid 172.17.0.0/16 specifically. Docker uses it as its default bridge network, and a LAN on the same range breaks container networking on every developer machine that joins it.
• Size the subnet for the site, not for the maximum. A /24 holds 254 hosts and keeps broadcast traffic contained. Handing an office a /16 because the block is free creates a single enormous broadcast domain for no benefit. Our guide to CIDR notation covers how prefix length maps to host count.
• Write the allocation down. Collisions usually happen because nobody recorded which ranges are already in use, not because the space ran out.

169.254.169.254, the link-local address that is not like the others

Everything said above about link-local addresses treats them as a symptom: DHCP failed, the device gave itself an address, fix the DHCP. One address in that range breaks the rule completely, and it matters enough to be worth knowing on its own.

Cloud providers use 169.254.169.254 as the instance metadata endpoint. A virtual machine queries that address over plain HTTP and receives information about itself: its hostname, its region, its network configuration, and, critically, temporary credentials for the identity the instance runs as. The address was chosen precisely because it is link-local, so it never routes anywhere and every instance can use the identical address to reach its own metadata.

The security consequence is significant. Any code running on the instance can read those credentials with an ordinary HTTP request and no authentication. That turns server-side request forgery into a credential-theft primitive: if an application fetches a URL supplied by a user and does not restrict where that URL may point, an attacker submits http://169.254.169.254/and reads back the instance's credentials through the application. This class of attack has been behind some of the largest cloud breaches on record.

Two defenses follow directly. Any feature that fetches a user-supplied URL must resolve the hostname first and refuse the request if it lands in link-local, loopback, or private space, and it must re-check after every redirect rather than only on the original URL. Separately, current metadata services offer a session-token mode that requires a PUT request before any read, which defeats the simple SSRF case because a naive fetcher only issues GET requests. Enable it, and treat any reserved address appearing in an outbound-request log as worth investigating.

Multicast is a reserved block you use every day

The 224.0.0.0/4 entry looks like infrastructure trivia until you realize it is how most of the convenient things on a home network find each other. When a phone discovers a printer, a laptop finds a Chromecast, or a music app lists the speakers in the house, that is multicast traffic inside a reserved block.

A handful of addresses in that space carry almost all of the everyday traffic:

• 224.0.0.1 reaches every host on the local segment, and 224.0.0.2 reaches every router. Both are used by core protocol machinery rather than by applications.
• 224.0.0.251 carries mDNS, the protocol behind .local hostnames and most zero-configuration device discovery. 224.0.0.252 carries the equivalent Windows mechanism, LLMNR.
• 239.0.0.0/8 is administratively scoped multicast, the multicast analogue of RFC 1918 space. Organizations use it internally and routers are configured not to forward it beyond a defined boundary. IPTV distribution inside a network commonly lives here.

The practical point is about scope. Addresses in 224.0.0.0/24 are never forwarded by routers at all, by design. That is exactly why device discovery works flawlessly within one subnet and then mysteriously stops when a device is moved onto a guest network or a separate VLAN. Nothing is broken. The traffic is doing precisely what the reservation says it should, and the fix is a router feature that deliberately relays it across segments rather than a setting on the device.

Why 240.0.0.0/4 is still unusable

The reserved block that attracts the most recurring argument is 240.0.0.0/4. It is 268 million addresses, roughly one sixteenth of the entire IPv4 space, marked reserved in the 1980s and never used for anything since. With IPv4 addresses now traded as scarce assets, proposals to reclaim it resurface regularly.

The obstacle is not policy. It is that decades of code treats those addresses as invalid rather than as unallocated. Operating system network stacks reject them, embedded firmware refuses to accept them, and validation logic scattered across routers, load balancers, and applications rejects them before any routing decision happens. An address is only usable if every device along the path agrees it is usable, and here a very large number of devices disagree by default.

That makes reclamation a coordination problem with no realistic path. Even if every stack shipped a fix today, the long tail of embedded equipment that never receives another update would keep those addresses unreliable for many years. An address block that works for most of the internet but fails unpredictably for the rest has little commercial value, which is why it has never been worth anyone funding the effort.

The lesson generalizes beyond this one block. Reserved space is defined by what deployed equipment does with it, not only by what a registry says. That is the same dynamic behind stale bogon filters described above, and it is why the safest assumption about any unusual address is that some device somewhere will treat it differently than you expect.

Squatting on address space you do not own

A failure mode worth naming explicitly is using public address space internally that belongs to somebody else. It happens more often than it should, usually when a network grows past its original plan and an administrator picks a range that looked unused.

The consequence is precise and confusing. Traffic to that range never leaves the local network, because the local routing table claims it. So the organization loses access to whatever real internet service actually holds those addresses, and only that service, while everything else works normally. Diagnosing it is unpleasant because the failure looks like the remote site is down, and it is down, but only from inside one building.

The classic example is 1.1.1.1. Before it was assigned to a public resolver, that address was used internally by a surprising number of networks and appliances as a placeholder, precisely because it was easy to type and appeared to belong to nobody. When it went into service as a real, heavily used address, those networks could not reach it, and some vendors had to ship firmware updates to stop generating traffic toward it.

The rule is simple and has no exceptions worth taking: internal networks use RFC 1918 space, or the shared space in 100.64.0.0/10 if a carrier-scale deployment genuinely needs the room. Address space that is not reserved belongs to somebody, even when it currently answers nothing, and assignments change without warning you.

Checking an address against the registry yourself

The tables above cover the blocks that account for nearly everything you will meet, but the registries hold more entries than any article should reproduce, and they change. When an address does not match anything familiar, the sequence for identifying it is short.

Start by asking whether it is reserved at all. If it falls inside one of the ranges above, you have your answer and no lookup will add to it. Public registries hold no ownership record for reserved space, so a WHOIS query against 192.168.1.1 returns nothing useful, which is itself a reliable signal rather than a failed query.

If the address looks public, the useful question is who announces it. An ASN lookup names the network operator carrying it, which distinguishes a residential ISP from a hosting provider or a cloud region far more reliably than a geolocation label. WHOIS and RDAP add the registry allocation, including which regional registry issued the block and when. Reverse DNS often supplies the last piece, because operators encode role and location in hostname patterns even when no other record does.

One caution applies throughout. An address being reserved describes only how it should be routed, not who sent the packet in front of you. A log entry showing a private source address on a public-facing service means something is wrong with either the packet or your logging, not that you have identified an internal user. Source addresses can be forged, and reserved ones are the easiest to forge precisely because no registry ties them to anybody.

BCP 38: filtering reserved space at the edge

Bogon filtering, described above, is the informal practice. The formal version has a name, and it is one of the few pieces of internet engineering guidance that has stayed unchanged and unimplemented for decades in roughly equal measure.

BCP 38, published as RFC 2827, says that a network should not forward a packet whose source address could not legitimately have originated from the direction it arrived. A packet entering an ISP from a customer connection should carry a source address from the range assigned to that customer. If it claims to come from 192.168.1.5, or from a documentation range, or from an address block belonging to a network on another continent, it is either misconfigured or forged, and the correct action is to drop it at the first router that can tell.

The reason this matters is amplification. Attacks that reflect traffic off open services depend entirely on forged source addresses: the attacker sends a small query with the victim's address as the source, and the service sends a much larger answer to the victim. Every one of those attacks becomes impossible at any network that filters its own outbound traffic properly. The difficulty is that filtering protects everyone except the network doing the filtering, which is a poor incentive structure and the reason adoption remains incomplete after twenty-five years.

Two practical implications follow for anyone reading logs. First, a packet arriving from outside with a reserved source address is not a mystery to be researched, it is a packet that should have been dropped upstream, and the useful response is to drop it and move on rather than to attribute it. Second, the source address on any single unsolicited packet is not evidence of origin. Established TCP connections are different, because completing a handshake requires receiving the response, but a lone UDP packet proves nothing about who sent it.

Renumbering a network off a range you should not be using

The two failure modes described above, colliding with a VPN and squatting on somebody else's public space, share a remedy nobody enjoys: renumbering. It has a reputation for being catastrophic, which is deserved only when it is done all at once.

The work that actually causes pain is not changing the addresses. It is finding everything that has an address written into it. DHCP hands most devices their configuration and those follow automatically, but the exceptions are exactly the things that matter: firewall rules, ACLs, static routes, printer configurations, NAS mount points, monitoring checks, backup targets, license servers tied to an IP, and hardcoded addresses inside applications whose authors have long since left. An inventory of those before touching anything is the difference between a planned migration and a weekend outage.

The approach that works is to run both ranges at once rather than to switch. Add the new subnet alongside the old one, give routers an interface in both so traffic passes between them, and move hosts in small groups while everything stays reachable either way. Shorten the DHCP lease time well in advance so clients pick up the new configuration in minutes instead of days once the pool changes. Move the least critical segment first, confirm nothing broke, and only then continue.

Two details are worth planning explicitly. DNS records pointing at old addresses need their time-to-live reduced before the migration, not during it, or clients will keep the stale answer long after the host has moved. And the old range should be kept routed but empty for a period afterward, because something always turns out to have the old address written down somewhere, and a working network that logs the attempt is far easier to debug than a silent failure. Verify from outside as you go, using DNS lookup to confirm records resolve to the addresses you intend and the port checker to confirm services that should be reachable still are.

DNS rebinding: when a public name answers with a private address

The metadata-endpoint problem above involves a server fetching a URL it should not. There is a matching attack aimed at browsers, and it works by making a name the browser already trusts resolve to a reserved address.

The sequence is short. An attacker controls a domain and publishes records with a very low time-to-live. A victim opens a page on that domain, and the first lookup returns the attacker's real server, so the page loads normally and its scripts run. Seconds later the record expires, the browser resolves the same name again, and this time the answer is 192.168.1.1 or 127.0.0.1. The page is still running, its origin has not changed as far as the browser is concerned, so the same-origin policy permits it to make requests to that address. Script the attacker wrote is now talking to the victim's router admin interface or to a service listening only on localhost, from inside the network, with the browser as the bridge.

The targets are the things nobody expected to need authentication because they were only ever reachable locally: router configuration pages still on default credentials, development servers, printers, media servers, database consoles bound to loopback, and IoT devices with unauthenticated HTTP APIs. The reserved address is not incidental to the attack. It is the whole point, because those services are exposed precisely to the addresses the reservations describe.

Defense happens in two places. Resolvers can refuse to return private or loopback addresses in answers for public names, which is what the "DNS rebind protection" setting in consumer routers and filtering resolvers does, and it is worth leaving enabled. Services can validate the Host header on every request and reject anything that does not match a name they expect, which breaks the attack even when the resolver cooperates. The broader habit is the durable one: treat anything listening on a private or loopback address as reachable by something you did not authorize, and put authentication on it anyway.

Why loopback is an entire /8

A small oddity worth closing on. Loopback needs one address, and it received 16.7 million. The reservation covers all of 127.0.0.0/8 because it was made when addresses came in class-sized units, and the smallest unit available at that position was an entire Class A network. Nobody has reclaimed it since, for the same compatibility reasons that keep 240.0.0.0/4 frozen.

The spare addresses are genuinely useful, though. On Linux the whole block is bound to the loopback interface by default, so 127.0.0.2, 127.0.0.3, and everything above them already work. That lets you run several test services on the same port, each on its own loopback address, without conflicts or a reverse proxy in between. macOS binds only 127.0.0.1 by default and needs the extra addresses added explicitly as interface aliases, which is a common cause of a setup working on one developer machine and not another.

Frequently asked questions

Is 192.168.x.x a real IP address? Yes, but only within a private local network. It is not supposed to identify your connection globally on the public internet.

What does 100.64.x.x mean? It usually means you are in carrier-grade NAT shared space controlled by the ISP, not using a directly assigned public IPv4 address.

Why do tutorials use 203.0.113.x and similar ranges? Because those blocks are reserved for documentation, so examples stay realistic without pointing to real users or servers.

Does 127.0.0.1 mean I am connected to the internet? No. It only means the local TCP/IP stack can talk to itself.

Is 169.254.x.x normal on a working home network? It is more often a sign that DHCP failed and the device self-assigned a link-local address.

Can I port-forward through CGNAT? Usually not in the normal direct way. You typically need a public IP, IPv6, a VPN with port forwarding, or another relay approach.

What is 169.254.169.254? It is the instance metadata endpoint used by cloud providers. Unlike the rest of the link-local range it is not a sign of a DHCP failure, and it returns credentials to anything running on the instance, which is why it is a frequent target of server-side request forgery.

Can I use 240.x.x.x on my own network? In practice no. Most operating systems and network devices still reject the block outright, so addresses in it fail unpredictably even on equipment you control entirely.

Why does my public-facing server log a private source IP? Either a proxy or load balancer in front of it is the real client and the original address is in a forwarded header, or the packet was forged and should have been filtered upstream. It is not a public user you can identify.

Which private range should I pick for a new network? Prefer an unusual subnet inside 10.0.0.0/8. Avoid 192.168.0.0/24 and 192.168.1.0/24 because they collide with home networks over VPN, and avoid 172.17.0.0/16 because Docker uses it by default.

Continue with Public vs Private IP Addresses, CIDR Explained, CGNAT IP Address Range, and What Is My IP Address?