Check Your NAT Type Instantly

This is the public IPv4 address reported during the test. A router or ISP may translate a private address before traffic reaches the internet, so several devices or subscribers can share a public address.

An address alone does not confirm CGNAT or Double NAT. A VPN can also change the public address seen by the test.

When a port is available, the number after the colon in the IPv4 result is a UDP port observed for this browser test. For example, 203.0.113.10:62000 shows an address and the reported port 62000.

It is not a game port, a port-forwarding rule, or proof that a service is reachable at that address. Mappings can change between tests or destinations, especially with Symmetric NAT.

This describes the IPv4 UDP behavior observed on the tested path. NAT 1 is Full Cone, NAT 2 is Restricted Cone, NAT 3 is Port-Restricted Cone, and NAT 4 is Symmetric. Open Internet is a separate result for a path where no NAT was observed.

These are NAT Checker’s labels for the RFC 3489 categories. PlayStation, Xbox and other platforms use their own labels and tests. NAT type does not measure download speed or guarantee that every game can connect to every peer. Select “How we classify NAT” to see the decision logic.

This is a global IPv6 address exposed by your browser during the IPv6 check. Local-only addresses are excluded. IPv6 discovery runs separately from the IPv4 NAT check.

An address alone does not prove external connectivity. “IPv6 not detected” means this test found no global IPv6 address; it does not establish that your ISP or device cannot support IPv6.

“External connectivity confirmed” means our IPv6 test service reported a successful WebRTC/UDP connection on this test path. Finding an IPv6 address is not enough to produce this result.

“External connectivity not confirmed” means that path did not succeed. Firewall rules, a VPN, browser restrictions or network conditions may affect the check. Normal IPv6 browsing can still work because it uses different connections and protocols. A timeout or service error means the check did not complete.

Blocked is a result returned by the NAT test server when this UDP test path cannot be established. It does not identify which device or setting caused the failure.

Timeout means no final classification arrived within the test window. An error or service-unavailable message means the test could not complete. These outcomes are not confirmed NAT 1-4 classifications. Retry, then check browser restrictions, VPNs and firewall settings before assuming a router or ISP fault.

RFC 3489 distinguishes NATs by comparing public IP-and-port mappings and checking which reply sources can reach the same local UDP socket. Changing a reply’s source and changing a request’s destination test different behaviors.

1. Test I: send a normal STUN Binding Request. The reply reports MAPPED-ADDRESS, the public IP and UDP port observed by the server. Compare both with the local socket’s address and port to determine whether translation occurred.
2. Test II: ask for a reply from a different server IP address and port. Receiving it shows that an external sender the client has not contacted can reach the mapping.
3. Alternate-destination Test I: send a normal request from the same local socket to the alternate server endpoint identified by CHANGED-ADDRESS. Compare the new public IP and port with the first mapping to detect destination-dependent mapping.
4. Test III: ask for a reply from the original server IP address but a different port. This separates an IP-only incoming filter from a filter that requires both the IP address and port to match.

These are the RFC’s classification checks. Our browser test gathers the public mapping with STUN and uses server-assisted WebRTC connectivity checks to return the corresponding behavior category.

1. Test I receives a reply, and the mapped public IP or port differs from the local socket endpoint, so NAT is present.
2. Test II receives a reply from a different server IP and port, even though the client has not sent traffic to that reply source.
3. In RFC 3489’s decision tree, this is Full Cone NAT, which we label NAT 1.

Once a UDP mapping exists, other external senders can reach that mapping without prior contact. This generally makes direct peer connections easier; it does not mean every port is open.

1. NAT is present, but Test II gets no reply from the changed IP and port.
2. A new Test I to the alternate destination returns the same mapped public IP and port as the first request. The mapping does not change with that destination.
3. Test III receives a reply from the original server IP at a different port. Prior contact with that IP is sufficient; prior contact with the reply’s exact port is not required.

This is Restricted Cone NAT, our NAT 2. Incoming UDP traffic is allowed from external IP addresses the client has already contacted.

1. NAT is present, and Test II gets no reply from the changed IP and port.
2. Test I to the alternate destination returns the same mapped public IP and port, ruling out destination-dependent mapping in this comparison.
3. Test III also gets no reply when only the server’s source port changes. In the RFC model, incoming traffic must match an IP address and port the client has already contacted.

This is Port-Restricted Cone NAT, our NAT 3. The mapping stays the same in the comparison, but the incoming filter is stricter than NAT 2.

1. NAT is present, and Test II gets no reply from the changed IP and port.
2. Repeat Test I from the same local UDP socket to the alternate server endpoint.
3. If the mapped public IP or port differs from the first mapping, the RFC decision tree identifies Symmetric NAT, our NAT 4.

For example, one destination might see 203.0.113.10:62000 and another 203.0.113.10:62001. A port change is enough; the public IP does not also have to change. An endpoint learned from one server may therefore be unsuitable for another peer, and some applications may need a relay.

If Test I gets no response, RFC 3489’s discovery flow reports UDP Blocked. In a browser test, a failed or incomplete UDP path can also be affected by browser settings, VPNs, firewalls, service availability or packet loss; it does not by itself locate the cause.

If Test I succeeds and the mapped IP and port both equal the local socket endpoint, no NAT is observed. Test II succeeding then identifies Open Internet. If Test II fails on that no-NAT path, the RFC calls it a Symmetric UDP Firewall. That is a filtering condition without address translation, not Symmetric NAT, and must not be confused with NAT 4.

Our result labels do not expose a separate Symmetric UDP Firewall category. An incomplete test or service error is also separate from a confirmed NAT category.

STUN, documented in RFC 8489, lets the browser learn a public address and UDP port observed outside the local network. ICE, documented in RFC 8445, uses connectivity checks to establish a path between endpoints.

RFC 3489 defines the Full Cone, Restricted Cone, Port-Restricted Cone and Symmetric categories, along with the mapping-and-reply tests that separate them. We use that classification logic with our browser and test servers; IPv6 address discovery and external connectivity are separate checks.

The result describes this browser’s tested UDP path. VPNs, firewalls and browser restrictions can affect it, and a real network can combine mapping and filtering behaviors that historical NAT labels do not fully describe.

The test does not confirm CGNAT or Double NAT, verify every application port, or guarantee a console’s NAT label or every peer connection. A public IPv6 address is not proof of external UDP connectivity.

RFC 3489 also notes that repeating a discovery with the same local socket can reuse earlier NAT bindings and distort the result. A fresh discovery uses a new local endpoint or waits for old bindings to expire; results describe the network at the time of that check.