Browser-visible IP
The server reads request forwarding headers and prefers a public-looking IP when one is available. A VPN, proxy, IPv6 path, or unusual forwarding headers can affect this observation.
Methodology
How CGNATCheck Works
CGNATCheck compares the public IPv4 visible to this site with the WAN IPv4 you read from your router. This page documents the exact interpretation model, the evidence behind each result, and the conclusions the tool does not make.
The two observations
Router WAN IPv4
You manually enter the separately labelled WAN, Internet, Broadband, or External IPv4. The browser cannot inspect this field. A device LAN address or Default Gateway is not a substitute.
Classification model
Every result follows this decision table
The wording is intentionally cautious. An address range can reveal that a layer exists; it usually cannot identify who operates that layer without another observation.
| Observed input | Checker result | Why | Evidence needed next |
|---|---|---|---|
| WAN is 100.64.0.0/10 | Likely behind CGNAT | This block is shared address space intended for service-provider networks, so it is a strong upstream shared-NAT signal on a WAN interface. | Ask the ISP whether the exact line uses shared IPv4 and whether a public IPv4 option is available. |
| WAN is RFC1918 private space | Possible double NAT or upstream private NAT | A 10/8, 172.16/12, or 192.168/16 WAN proves another private layer exists, but it does not identify whether that layer belongs to a second home router or the provider. | Read the WAN value on the next upstream gateway. If that outer device is public, the first finding was local double NAT. |
| Public WAN exactly matches detected public IPv4 | Probably not behind CGNAT | The router appears to hold the same public IPv4 used by the browser request, so there is no strong standard IPv4 CGNAT signal in that path. | Test the listening service, protocol, forwarding target, and firewall. A matching address pair does not open a port. |
| Public WAN differs from detected public IPv4 | Possible upstream NAT mismatch | Something between the selected router and the web request may be translating or proxying traffic, or the WAN value may have come from the wrong device. | Compare each upstream gateway in order, then repeat without a VPN or proxy if one is active. |
| WAN is reserved or otherwise special-use | Cannot confirm | The value is not ordinary public IPv4 and is not the standard shared CGNAT block. The checker cannot confidently assign the network topology from it. | Recheck the labelled WAN field and ask the router vendor or ISP what that address represents. |
| Either side is IPv6, missing, or unsuitable for comparison | Cannot confirm or needs input | The current method is an IPv4 comparison. It does not infer an IPv4 NAT topology from IPv6 or from an address the server could not reliably obtain. | Find the router's WAN IPv4 if one exists, or verify the IPv6 and inbound-connectivity setup separately. |
Decision path
Range first, comparison second
- Normalize and classify the manually entered WAN address.
- Stop with a cautious result if it is shared, private, reserved, invalid, or IPv6.
- Only compare values when the WAN is public IPv4.
- Require an exact public-to-public match for the probably-not result.
- Treat a public mismatch as a clue to investigate, not proof of CGNAT.
Why private and shared space are not interchangeable
RFC1918 addresses are used throughout ordinary private networks. If your personal router receives one from an ISP gateway in the same home, the private WAN is expected even when that outer gateway has a public IPv4. By contrast, 100.64.0.0/10 was created as shared address space for service-provider use, so finding it on the WAN side is a more specific CGNAT signal.
See the address-range reference for exact boundaries, or use the topology guide to trace a second router.
Worked examples
What each observation proves and does not prove
These values are illustrative and are not customer records. The examples follow the same branches used by the checker.
Shared provider-space WAN
WAN 100.72.18.4 | visible: ordinary public IPv4
- What it supports
- The WAN value is inside 100.64.0.0/10, which is a strong shared-provider NAT signal.
- What it does not prove
- It does not describe every customer on the ISP or prove which paid workaround will support the application.
Private WAN behind another gateway
WAN 192.168.0.20 | visible: ordinary public IPv4
- What it supports
- At least one private NAT layer exists upstream of the router whose WAN field was read.
- What it does not prove
- It does not distinguish an ISP gateway in the home from carrier-grade NAT. The outer gateway must be checked.
Matching public pair
WAN: public IPv4 A | visible: public IPv4 A
- What it supports
- The two values match and provide no strong standard IPv4 CGNAT signal for this request path.
- What it does not prove
- It does not prove that a service is listening, a port is forwarded correctly, or inbound traffic is unfiltered.
Different public values
WAN: public IPv4 A | visible: public IPv4 B
- What it supports
- The selected router WAN and browser-visible public path do not currently agree.
- What it does not prove
- It does not identify the cause. Another gateway, VPN, proxy, stale status field, or upstream translation can produce the mismatch.
Special-use WAN value
WAN 192.0.2.10 | visible: ordinary public IPv4
- What it supports
- The entered WAN value is not an ordinary public IPv4 that the checker can compare as a normal internet address.
- What it does not prove
- It does not prove CGNAT. The WAN field and the meaning of the special-use address need verification.
Known limits of the browser check
- It cannot sign in to, scan, or inventory routers in your home.
- It cannot identify every translation, proxy, tunnel, or filtering layer.
- It cannot generalize one connection result to an ISP, plan, or region.
- It cannot infer an IPv4 NAT arrangement from IPv6 alone.
- It cannot verify whether a service or firewall is configured correctly.
Addressing is not reachability
A matching public pair removes one common blocker, but it does not open a port. The application still needs to listen on the expected TCP or UDP port, the forwarding rule must target the correct LAN device, and relevant firewalls must allow the traffic.
Continue with the controlled port-testing checklist or diagnose the likely root cause in why port forwarding fails.