White and Gray IP Addresses in Mobile Networks: Differences, Verification, CGNAT, and Proxies

Introduction: Why This Topic Matters and What You Will Learn

If you’re working with mobile proxies, testing applications, engaging in legitimate scraping of public data, managing brand accounts on social media, or building a distributed infrastructure with 4G/5G modems, the question of white and gray IP addresses is inevitable. The type of IP affects the availability of incoming connections, session stability, address reputation, and the geographical signals seen by target services. By 2026, nearly all mobile users will be behind CGNAT by default, which means they will have a ‘gray’ address. But when and why is a ‘white’ IP necessary? How can you determine your IP type in just 3 minutes, and what options do you have if a white IP is critical? This guide serves as your universal reference, packed with theories, practicals, checklists, real-world cases, and tools. We will explore fundamental concepts, dive deep into operators' network architecture, and then walk step-by-step through strategies: how to check your IP type, in what schemes mobile proxies require a white address, how to obtain one on a modem, and stable solutions that work without a white IP. Throughout, you’ll find practical decision-making frameworks, common mistakes and how to prevent them, as well as references to the mobile service mobileproxy.space, which addresses some of these challenges out of the box.

Basics: What Are White and Gray IP Addresses?

White IP Address (public routable) is an address that is publicly routable on the global internet. It is unique on the internet, belongs to a specific autonomous system (AS), has a provider listed in WHOIS, and is potentially available for incoming connections if network policy and firewall allow it.

Gray IP Address (private/non-routable behind NAT) is an address from private or special ranges that are not routable on the global internet. To access the internet, these addresses are transformed (masked) into white ones via NAT by the provider. In mobile networks, this is often CGNAT—Carrier-Grade NAT.

Key Differences

• Routability: White—globally routable. Gray—not routable, visible only within the operator’s network or local subnet.
• Incoming Connections: White—possible with proper configuration. Gray—not possible directly from the internet.
• Control: White—more control over ports and services. Gray—depends on NAT and its rules.
• Reputation: White—the address is not shared with thousands of subscribers; reputation tends to be more predictable. Gray—many subscribers are behind one external IP, which can affect filtering and limits on the target services' side.
• Ranges: Gray—RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), CGN (100.64.0.0/10). White—any other IPv4 assigned by providers; for IPv6—global unified prefixes (2000::/3).
• Cost and Availability: White—the IPv4 shortage raises costs; white IPv6 is often more available. Gray—is default for most mobile subscribers.

Comparative Table: White vs. Gray IP

• Accessibility: White—accessible from the internet; Gray—not accessible from outside without a mediator.
• Outgoing Connections: White—unrestricted NAT; Gray—via address translation by the operator.
• Ports: White—can be opened/forwarded; Gray—cannot be managed at the CGNAT level.
• WHOIS and Geo: White—accurate records and geo; Gray—external address is shared, geo can vary based on the operator's cities.
• Stability: White—static ones are possible; Gray—dynamics are determined by the operator's policy and NAT pool.
• Cost and Complexity: White—more expensive/more complex in mobile networks; Gray—default, cheaper.

Deep Dive: CGNAT in Mobile Operators and Why Almost All IPs are Gray

CGNAT—Carrier-Grade NAT—is a multi-level NAT on the operator's side, allowing thousands of subscribers to share a pool of limited IPv4. Architecturally, this is often a NAT444 scheme: a private address on the subscriber's device → NAT in the operator’s backbone network → exit through a shared white IPv4 (sometimes with several layers of aggregation). The reasons for widespread CGNAT in mobile networks are obvious: IPv4 scarcity and mass mobile access.

Why Are Almost All IPs Gray?

• IPv4 Scarcity: The IPv4 address market is pricey, and mobile operators have tens of millions of subscribers. Providing each with a white IPv4 is not economically viable.
• Operational Simplicity: CGNAT centralizes traffic control, filtering, and security, simplifying compliance with regulators and internal policies.
• Trend Towards IPv6-Only: By 2026, mobile networks are increasingly adopting IPv6, often in IPv6-only mode for users, providing access to IPv4 via NAT64. While websites and services haven’t fully transitioned to IPv6, CGNAT remains a ‘bridge’ for IPv4.

What This Means Practically

• Direct Incoming Connections Are Not Possible: You cannot open a port on a device behind CGNAT, because the external white IPv4 belongs to the operator and is shared among all.
• Restrictions on Outgoing Ports and Protocols: The operator may apply policy at the CGNAT level (for instance, closing 'non-standard' ports or limiting new sessions per second).
• Reputation of the External Address: The same operator's white IP may be employed simultaneously by thousands of subscribers; some services react more severely to such addresses (greater risk of captchas, limits).
• IP 'Jumps' on Reconnection: Depending on the address pool and session 'stickiness,' the external IP may change with every network restart or even within a session.

Statistics and Trends for 2026

• Share of Subscribers Behind CGNAT: Industry estimates and targeted research suggest that in most countries, >95% of retail users are by default behind CGNAT.
• IPv6 in Mobile Networks: The share of traffic over IPv6 in mobile segments in developed markets often exceeds 40-60%. Many operators are launching IPv6-only profiles with NAT64, improving address space but not resolving reverse availability over IPv4 without additional mechanisms.
• Corporate Services with White IP: There’s a growing supply of M2M/eSIM profiles with dedicated static IPv4/IPv6 or private APNs routing to the customer network.

Practice 1: How to Check if You Have a White or Gray IP (Step-by-Step)

Here’s a reliable and quick verification procedure. We’ll break it down into three layers: local address, public address, availability of ports, and signs of CGNAT in tracing.

Step 1. Check the IP Assigned to the Device

• Smartphone: Go to network settings (mobile data → details). If you see an address from the ranges 10.x.x.x, 100.64.x.x–100.127.x.x, 172.16.x.x–172.31.x.x, or 192.168.x.x—this is a private address; you are behind NAT.
• 4G/5G Modem or LTE Router: Open the device's web interface (usually 192.168.8.1 or 192.168.1.1 for popular models). In the "Status" or "WAN" section, find "IP address." If it’s from the ranges mentioned above—it’s a gray address, CGNAT.

Step 2. Compare Your External Address

• Any IP Lookup Service: Find out what address the internet sees (for instance, open a page showing your public IP). Compare it with what is listed in the modem interface as "WAN IP." If the modem shows a private IP and the internet shows a different white one, you are definitely behind CGNAT.
• CLI on the Computer: Use network parameter viewing commands (ipconfig/ifconfig/ip addr)—they will show local addresses but not the external one. You’ll see the external only from the internet side (via a web service or your server log).

Step 3. Check Incoming Availability

• Quick Port Test: Launch a local service on an arbitrary port (e.g., 8080) on the device behind the modem. Try to connect to it from an external network using the public IP shown to you. If the connection fails and there's no option to configure port forwarding by the operator—this indicates CGNAT.
• Exclude Local Firewall: Temporarily make sure you’re not blocking incoming connections on the host (firewall off for a specific port, carefully and temporarily).

Step 4. Check the Tracing

• traceroute/tracert: Run a trace to a public node. A few "private" hops before reaching the internet will indicate NAT within the operator’s network. A noticeable "jump" from 10.x or 100.64/10 to the operator’s white address is typical of CGNAT.

Step 5. Check WHOIS and Ranges

• WHOIS of External IP: The external address visible to websites should belong to the operator. This is normal. But if your local WAN is private and the external one is the operator's white, then you are behind CGNAT.
• Remember Diagnostic Ranges: 10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12, 192.168.0.0/16—these are always gray. For IPv6, white are global (starting with 2xxx:), local are fe80::/10 (link-local) and fc00::/7 (ULA).

Quick Diagnostic Checklist (2-3 minutes)

• Opened the modem web interface and checked the WAN IP.
• Compared the WAN IP with the public address from the internet.
• If WAN is in 10.x/100.64–100.127/172.16–31/192.168—stop: this is CGNAT.
• Attempted an incoming connection on a test port—failed? Another point for CGNAT.
• Performed a traceroute—seeing private hops leading to the operator's white address—result confirmed.

Practice 2: Is a White IP Necessary for Mobile Proxies (Depends on the Architecture)

Answer: It depends on the architecture of your solution and business requirements. Let’s explore common scenarios.

Scenario A. Proxy on Modem, Clients Connect Directly from Outside

• Requirement: Needs a white (preferably static) IPv4 or white IPv6 with thoughtful reverse publishing to the IPv4 world, if clients and targets are IPv4.
• Why: Clients must establish incoming connections to your proxy. Behind CGNAT, this is impossible without a mediator.

Scenario B. Proxy on Modem, Access Outside via a "Cloud Mediator"

• Requirement: A white IP on the modem is not mandatory. The modem establishes a persistent outgoing connection to a node with a white IP (relay), and users connect to this node. The traffic is proxied to the modem through an already established outgoing channel.
• Why: CGNAT restricts incoming but not outgoing. A persistent outgoing session legally and predictably bypasses the restriction.

Scenario C. Outgoing Web Access from Applications without Incoming Connections to You

• Requirement: A white IP is often unnecessary. If your software simply makes outgoing HTTP(S) requests, then CGNAT doesn’t interfere as long as you are okay with the reputation of the operator's shared external IP.
• Risks: There may be increased checks and captchas on target services, as the address is common among many subscribers.

Scenario D. Geo and ASN-Sensitive Tasks

• Requirement: Depends on the objective. If a rare ASN or clear "city-operator" linkage is needed, a white IP from the desired pool will provide more predictability. On the other hand, mobile CGNAT addresses often send a strong "mobile" signal and the desired geography—this is a plus for several cases.

Decision-Making Framework

• Do you need incoming connections to the device? Yes—aim for a white (or architecture with an external relay). No—white is likely not essential.
• Is IP reputation and its 'uniqueness' critical? Yes—consider a dedicated white from the operator or a managed pool through a mobile proxy service like mobileproxy.space.
• Is address stability (staticness) needed? Yes—get a static white (IPv4/IPv6) from the operator or utilize a reliable external entry point from a proxy provider.

Practice 3: How to Get a White IP on a Mobile Modem

There are several legitimate paths. They differ in cost, complexity, and flexibility.

Approach 1. Special Plan/Service from the Operator: Static White IPv4/IPv6

• Essence: You connect to the operator’s service for "static public IP" (often a corporate option, M2M/eSIM profile). Sometimes it's a separate APN marked "public/static".
• Pros: Genuine white IP, simple model, minimum latency, control over ports (considering policy and firewall).
• Cons: Higher cost than retail tariffs, not always available to individuals, requires modem compatibility and proper APN configuration.
• Step-by-Step:
  1. Check with your operator about the availability of the "static IP" service for mobile SIM/M2M.
  2. Order the service and obtain the APN parameters (name, login/password if necessary).
  3. Create an APN profile in the modem and select it for connection.
  4. Check in the interface that you got a white IP, and confirm the incoming availability of selected ports (if necessary, configure the firewall).

Approach 2. White IPv6 from the Operator and Service Publishing with NAT64

• Essence: The operator provides a global IPv6. You access IPv4 resources through NAT64, and for incoming—use the publishing mechanisms supported by your stack (e.g., external relay or service load balancer if the target side operates via IPv6).
• Pros: IPv6 is often more accessible and cheaper from mobile operators; the address space is huge, and reputation is more predictable.
• Cons: Not all clients and targets are available via IPv6; IPv4 targets will still require NAT64; without an external relay, incoming from IPv4 clients is inaccessible.
• Step-by-Step:
  1. Ensure your operator supports IPv6 for your SIM and plan.
  2. Enable IPv6 in the modem/router settings; check the prefix and route.
  3. Check access to necessary resources via IPv6; for IPv4 resources, ensure that NAT64 is working correctly.
  4. If incoming is required—plan an external relay node with white IPv4/IPv6.

Approach 3. Private APN with Routing to Your Network

• Essence: The operator sets up a private APN through which devices receive addresses from your subnet (IPv4/IPv6) and are routed to your network via an agreed channel. As a result, you manage addressing up to white IPs if you have your own address space and edge router.
• Pros: Maximum control, isolation, SLA.
• Cons: Expensive, requires networking expertise, and time to implement.
• Step-by-Step:
  1. Formulate requirements for addressing, security, and throughput.
  2. Sign a contract with the operator for a private APN.
  3. Configure boundary routing and access policies.
  4. Connect devices and test reachability from both sides.

Approach 4. External Relay Node with White IP (Without Changing the Plan)

• Essence: The modem establishes a persistent outgoing connection to a cloud node with a white IP. External clients connect to this node, and the traffic follows to the modem through the already initiated channel. This approach is widely used by mobile proxy services (like mobileproxy.space).
• Pros: Works with any CGNAT, does not require a special tariff from the operator, scalable.
• Cons: Adds an additional node and minimal delay; depends on the quality of the connection to the cloud relay.
• Step-by-Step:
  1. Register the access point at the relay node with the chosen service.
  2. Install an agent on the router/PC near the modem or use firmware/connector that maintains the outgoing connection.
  3. Check access to the proxy through the entry point with the white IP of the relay.
  4. Configure authorization, allowed IP lists, and connection limits.

Practice 4: Mobile Proxy Architectures and Working Techniques

Architecture 1. "Direct Connection" (Requires White IP on Modem)

• Theory: Your modem or router gets a white (preferably static) IP from the operator. A proxy (HTTP/SOCKS) runs on it. Clients connect directly to this address and port.
• Practice:
  1. Get a static public IP and APN profile from the operator.
  2. Launch a proxy service on the device and enable authentication.
  3. Open/forward the required ports in the router's firewall.
  4. Check external access and log connections.
• Use Case: An application testing lab requiring direct access to the device by IP.

Architecture 2. "Cloud Relay" (Without a White IP on Modem)

• Theory: There’s a node with a white IP in the cloud. The modem from behind CGNAT establishes a persistent outgoing connection to the cloud. Clients connect to the cloud, which transparently proxies the traffic to the modem.
• Practice:
  1. Register the relay point with the service (e.g., mobileproxy.space).
  2. Install a connector or configure a built-in client on the router.
  3. Provide clients with the cloud entry address and credentials.
  4. Monitor line quality (jitter, loss), set up alerts.
• Use Case: Large-scale mobile proxy farms without corporate tariffs from the operator.

Architecture 3. IPv6-oriented Publication

• Theory: If your clients support IPv6 and the operator provides a white IPv6, you can run the proxy on IPv6. For IPv4 clients, use an external load balancer that speaks both IPv4 and IPv6.
• Practice:
  1. Enable IPv6 on the router and ensure a global prefix is obtained.
  2. Launch a proxy listening on :: and the appropriate ports.
  3. For IPv4 clients, use an external load balancer with dual-stack access.
  4. Test routing and compatibility of libraries.
• Use Case: Modern applications oriented towards IPv6 and regions with good IPv6 support from operators.

Architecture 4. Private APN with Routing to Your Network

• Theory: Devices find themselves "in your network" with white addressing and access policies, just like in a branch.
• Practice:
  1. Formulate a contract for a private APN with the operator.
  2. Set up transport to your network and routing.
  3. Manage addresses, publish services on the required ports.
  4. Enable centralized auditing and access control.
• Use Case: Critical systems, IoT and M2M, where control and predictability are important.

Practice 5: Checklists, Frameworks, and Test Scenarios

Checklist for Preparing the Modem for Proxy

• Update the modem/router firmware to the latest version.
• Check IPv6 support and enable if necessary.
• Determine if a white IP is needed: incoming or special reputation?
• Choose a strategy: white from the operator, cloud relay, or private APN.
• Configure APN, authorization, and encryption at the managed channel level.
• Enable logging and metrics (speed, loss, delays).
• Plan monitoring and rotation of SIM cards in case of channel degradation.

Architecture Choice Framework

• Need incoming? Yes → white IP or relay. No → CGNAT is acceptable.
• Need static? Yes → static white or stable cloud entry point.
• Budget limited? Yes → relay without changing the operator's tariff; later—upgrade.
• Need strict security control? Yes → private APN and corporate segmentation.

Quality Test Scenarios

• Session establishment check: 1000 attempts in 10 minutes—percentage successful.
• Latency measurement: average/95th percentile RTT to target services.
• IP stability: how often it changes on reconnection.
• Behavior under weak signal: speed degradation, increase in errors.
• Response of target services: frequency of additional checks and limits.

Practice 6: Techniques for Enhancing Stability and Address Reputation

• Use Dedicated Pools: Services at the level of mobileproxy.space have managed address pools and profiles for tasks, which reduces reputation variance.
• Stabilize Session: Long TCP sessions and maintaining connections through cloud relay reduce the frequency of new establishments and lessen the strain on CGNAT.
• Smart SIM/IP Rotation: Don’t abuse the frequency of rotation. Too aggressive IP changes can provoke unwanted reactions on the service side.
• Geo-Consistency: Choose an operator and region that matches your audience and case requirements.
• Security Policies: Strict authentication on the proxy, customer allowlist, logging, and limiting simultaneous connections.

Common Mistakes: What Not to Do

• Confusing Local and External IP: Seeing 10.x on the modem and thinking it’s a white address.
• Trying to Open a Port Behind CGNAT: This won't work because the external white address belongs to the operator and is shared among thousands of subscribers.
• Ignoring IPv6: Many tasks can be simplified with a white IPv6.
• Underrating Address Reputation: Common external IPs from operators may sometimes be flagged by target services as 'high risk' due to the volume of anonymous traffic.
• Leaving the Proxy Without Authorization: An open proxy is a security risk and violates service policies.
• Setting Too Short Timeouts: Mobile networks can be 'uneven'—allow some margin for timings and retries.
• Blindly Relying on 'Rotation as a Panacea': The key to stability is architecture quality, not speed of address changes.

Tools and Resources: What to Use

Network Diagnostics

• traceroute/tracert: Path analysis and NAT hops.
• whois: Provider, ASN, overall understanding of address ownership.
• nmap (non-aggressively): Minimal checks for port availability on your own nodes.
• Modem/Router Logs: Signal level, frequency, re-registers—affecting stability.

Proxy Practice

• Cloud Relay Connection Agents: Components that maintain an outgoing session to a node with a white IP.
• Monitoring: Availability, latency, authorization error metrics.
• Access Management: User authorization, allowlist, logs.

Services

• mobileproxy.space: Practical scenarios for working with mobile proxies: cloud entry points with white IPs, operator and city profiles, API for automation, scheduled rotation. See the sections Mobile Proxy Pricing and CGNAT: Analysis for detailed materials.

Use Cases and Outcomes: Real Application Examples

Case 1. Social Media Brand Management Agency

Task: Legitimate management of brand accounts, publishing and moderating content for local markets. Constraints: Access must come from the required region, stable sessions without 'jumping' IPs. Solution: "Cloud relay" architecture: modems in required cities, consistent outgoing connections to the entry point, strict authorization. Result: The share of successful sessions increased from ~78% to 96%, while the number of additional checks decreased by ~35% due to consistent profiles and careful rotation.

Case 2. QA Laboratory for a Mobile Application

Task: Testing functionality and content that depends on geo and operator. Solution: White IPv6 on several SIM profiles, publishing services on IPv6, for IPv4 targets—NAT64 and if necessary, an external load balancer. Result: Preparation time for the environment decreased by 40%, with connection refusal rates due to NAT issues reduced to nearly zero.

Case 3. Scraping Public Data with Owners' Consent

Task: Collecting open data (prices, product cards) within the permitted rules of platforms. Solution: Managed pools of mobile addresses from a service like mobileproxy.space, moderate rotation, load distribution, error monitoring. Result: Stable upload speed, with repeat request rate dropping by 22% due to reduced 'conflicts' on shared addresses.

FAQ: 10 Key Questions

1. Is a white IP mandatory for a mobile proxy?

No. If clients do not connect to your proxy from outside directly, use a cloud relay: the modem initiates an outgoing connection—and the task is solved. A white IP is needed when you want to accept incoming connections directly.

2. What is the difference between static white and dynamic white?

Static is tied to your SIM/service and does not change (or only changes at your request). Dynamic is issued from a pool and may change upon reconnection. For permanent integrations, static is more convenient.

3. Is IPv6 from the operator always 'white'?

Almost always—yes, it is a globally routable address. But incoming availability depends on policies and service publication. IPv4 will still require an additional node with dual-stack support.

4. Can a white IPv4 be requested from a mobile operator?

In many countries and with certain operators—yes, more often within corporate/M2M tariffs or private APNs. For retail SIMs—rarely and more expensive than usual.

5. Why does my external IP sometimes 'jump', even if I haven’t touched anything?

Policy on address pools and re-registration in the network. CGNAT may redistribute sessions, and the modem may reconnect due to radio parts. Signal monitoring and session retention through relays can mitigate this effect.

6. How can I tell if CGNAT is 'choking' me?

Signs include: non-opening of non-standard ports, instability of multiple parallel sessions, impossibility of incoming. Tracing shows private hops leading to the operator's external IP.

7. Is a PTR (reverse zone) needed for a white IP?

For some services, correct reverse records enhance trust. If taking a static white from the operator, ask about PTR setup possibilities. For cloud relay, the provider usually sets up PTR on their side.

8. Is it safe to host a proxy on a white IP?

Safe with the right configuration: authentication, client limiting, encryption of managed channels, firmware updates, and logging. Open proxies—serious risk; they should not be created.

9. How to deal with geolocation and city accuracy?

Depends on the operator's base and geodata. A white IP from the desired pool provides more predictability. In mobile CGNAT addresses, the city/region is often visible due to the operator's infrastructure—this is a plus for local tasks.

10. Are mobile proxies compatible with anti-detect browsers?

Technically—yes, if the browser supports HTTP/SOCKS, and you comply with target platform rules and legislation. The key is proper architecture and careful connection profiles.

Conclusion: Summary and Next Steps

White and gray IPs are not just theoretical labels but practical crossroads in the architecture of your mobile solutions. By 2026, almost every mobile user will be behind CGNAT, and that’s okay. A white IP is truly needed when you plan on directly accepting incoming connections or require unique reputation and stability. In all other cases, a cloud relay architecture works perfectly: the modem initiates an outgoing connection to a node with a white IP, and clients connect to this node. Want 'maximum control'—go for a corporate static white from the operator or a private APN. Want 'minimum friction'—use ready-made services where entry points, address pools, and monitoring are already thought through (like mobileproxy.space). What to do right now? 1) In 3 minutes, check your IP using our checklist. 2) Choose an appropriate architecture based on the framework: white on the modem, relay, or private APN. 3) Set up proxy, authorization, and monitoring. 4) Conduct quality tests and document the SLA. By following these steps, you will build a resilient mobile proxy infrastructure with clear manageability, predictable outcomes, and adherence to platform and legislative rules.