How Proxy Servers and IP Addressing Work Together

Every connection your device makes to the internet carries your IP address as the return label on the packet. A proxy server intercepts that connection and substitutes its own IP, so the destination sees the proxy rather than you. Understanding exactly how that substitution happens, and where IP addressing enters the picture at each step, is the foundation for using proxies correctly in any context, from privacy-sensitive browsing to large-scale data collection.

Key Takeaways

• A proxy server acts as an intermediary by forwarding your request under its own IP address, hiding your origin from the destination server.
• Every device on the internet is identified by an IP address, a 32-bit number (IPv4) or 128-bit number (IPv6) assigned according to RFC 791 (Postel, 1981) and RFC 8200 (Deering and Hinden, 2017) respectively.
• HTTP, HTTPS (via CONNECT tunneling), and SOCKS5 (RFC 1928, Leech et al., 1996) are the three main proxy protocols, each handling IP substitution and connection forwarding differently.
• Transparent proxies do not modify the origin IP visible to the destination and are typically used for caching and content filtering rather than anonymity.
• Residential proxies route traffic through real ISP-assigned IPs and achieve a 3-5% detection rate versus 20-40% for datacenter proxies, according to Oxylabs benchmark data (2025).

An IP address is a numerical label assigned to every device participating in a network that uses the Internet Protocol. IPv4 addresses are 32-bit numbers written in dotted-decimal notation (for example, 203.0.113.45), providing approximately 4.3 billion unique addresses. IPv6 addresses are 128-bit numbers written in colon-separated hexadecimal groups, providing approximately 3.4 x 10^38 addresses, a space introduced specifically because IPv4 exhaustion became a practical operational problem by 2011 when IANA allocated the final IPv4 /8 blocks.

Every time your browser loads a page, it sends a TCP packet whose header contains a source IP field. That field carries your public IP address, the one assigned by your ISP on the WAN side of your router. The destination server logs it, uses it for rate limiting and geographic routing decisions, and can look up the ISP and approximate city of origin using regional internet registry (RIR) databases maintained by ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC.

Citation Capsule: The American Registry for Internet Numbers (ARIN) maintains the public WHOIS database for the ARIN service region. IP-to-ASN (Autonomous System Number) lookups resolve any IP to the organisation that registered its containing prefix. This is the mechanism anti-bot systems use to identify whether a connecting IP belongs to a known datacenter ASN, a residential ISP, or a mobile carrier.

Two addresses are particularly important for proxy configurations: the public IP (visible to remote servers) and the private IP (the RFC 1918 address on your local network, such as 192.168.x.x or 10.x.x.x). NAT (Network Address Translation) at your router translates between private and public. When traffic passes through a proxy, NAT at the proxy server performs the equivalent substitution at the WAN-internet boundary, but under the proxy's IP rather than yours.

[INTERNAL-LINK: anchor -> what-is-a-residential-proxy: link to the residential proxy explainer for readers who want to understand ISP-assigned IP addresses in more detail]

A proxy server replaces your IP address in outbound requests by terminating your connection at the proxy and opening a new, separate connection from the proxy to the destination server. The destination sees only the second connection, originated from the proxy's IP. Your original connection never reaches the destination. This two-hop architecture is the core mechanism of all proxy IP substitution.

The sequence for an HTTP request through a proxy:

1. Your client opens a TCP connection to the proxy server IP on port 8080 (or the configured proxy port).
2. Your client sends an HTTP request: GET http://target.com/page HTTP/1.1 with your IP as the TCP source in the packet header.
3. The proxy receives the request and strips or rewrites the X-Forwarded-For header (for anonymous proxies) or appends your IP to it (for transparent proxies).
4. The proxy opens a new TCP connection from its own IP to target.com on port 80.
5. The proxy forwards the HTTP request under its IP as the TCP source.
6. target.com responds to the proxy's IP. The proxy forwards the response back to your client.

The destination server's access logs record the proxy's IP, not yours. Whether your IP leaks depends on the proxy type and whether the proxy injects forwarding headers.

[UNIQUE INSIGHT] The X-Forwarded-For header is the most common source of unintentional IP exposure when using HTTP proxies. A proxy configured as "anonymous" omits this header entirely. A proxy configured as "transparent" or "distorting" may set X-Forwarded-For: or X-Forwarded-For: respectively. HTTPS connections via CONNECT tunneling prevent the proxy from reading or injecting headers inside the encrypted tunnel, so HTTPS with an anonymous proxy provides stronger IP concealment than HTTP. The distinction between proxy anonymity levels (transparent, anonymous, elite/high-anonymity) maps directly to which headers the proxy sends to the destination.

HTTP, HTTPS (CONNECT method), and SOCKS5 are the three proxy protocols used in practice, and each handles IP routing and connection forwarding differently. Knowing which protocol is in use determines what level of IP protection is actually provided.

HTTP proxy. The client sends a full HTTP request to the proxy, including the destination hostname in the request line (GET http://target.com/page HTTP/1.1). The proxy reads the hostname, resolves it (DNS on the proxy side), opens a new TCP connection, and forwards the request. The proxy can read, log, modify, or inject headers in the request because the traffic is unencrypted. For plain HTTP sites, this is functional but provides no transport security. IP substitution occurs because the proxy opens the second connection from its own IP.

HTTPS via CONNECT tunneling. For HTTPS destinations, the client sends a CONNECT target.com:443 HTTP/1.1 request to the proxy. The proxy opens a TCP connection to target.com:443 and returns 200 Connection Established. The client then initiates a TLS handshake directly with target.com through the established TCP tunnel. The proxy cannot read the encrypted traffic. It only knows the hostname from the CONNECT request and the IPs at both ends. IP substitution still occurs because the TCP connection to target.com originates from the proxy's IP, but the proxy has no visibility into the request content.

SOCKS5 (RFC 1928, Leech et al., 1996). SOCKS5 operates at a lower level than HTTP. The client sends a connection request specifying the destination IP or hostname and port. With address type 0x03 (domain name) and the socks5h:// scheme, the hostname is forwarded to the proxy server for DNS resolution. SOCKS5 supports both TCP and UDP, works with any application protocol, and does not modify application-layer headers. IP substitution is identical to the HTTP case: the proxy opens a new TCP connection from its own IP to the destination.

Citation Capsule: RFC 1928 (Leech et al., 1996) defines the SOCKS5 handshake as a three-phase negotiation: authentication method selection, optional authentication, and the connection request. Address type byte 0x01 requests connection by IPv4, 0x04 by IPv6, and 0x03 by domain name. Choosing 0x03 with socks5h:// is the only configuration that routes DNS resolution to the proxy side, preventing DNS leaks.

Proxy IP addresses are not interchangeable. The origin of the IP address, who registered it with the regional internet registry, determines how anti-bot systems classify the connection. Three categories dominate the proxy market and each provides a different level of IP authenticity.

Datacenter IPs. These are IP addresses registered to cloud hosting providers, colocation facilities, or VPS services, identifiable by their ASN. Common examples include ASNs belonging to AWS, DigitalOcean, Hetzner, and OVH. Anti-bot systems maintain blocklists of known datacenter ASN ranges. Block rates on protected sites range from 20-40% according to Oxylabs benchmark data (2025). Datacenter proxies are fast and cheap but offer the weakest IP authenticity.

Residential IPs. These are IP addresses assigned by ISPs to home broadband or mobile subscribers, registered to ASNs such as Comcast, BT, or Jio. To a target server, traffic from a residential IP appears to come from a real consumer device. Residential proxies are sourced from peer-to-peer networks of opted-in device owners and route requests through those devices' real ISP connections. Detection and block rates drop to 3-5% on the same targets where datacenter proxies fail at 20-40%.

Mobile IPs. These are carrier-grade NAT addresses from mobile networks. Because mobile carriers assign a single public IP to large numbers of subscribers simultaneously (CGNAT), a block on a mobile IP would affect thousands of legitimate users. Anti-bot systems treat mobile IPs with considerably more tolerance. Mobile proxies are the most expensive category and are primarily used for ad verification, mobile app testing, and platforms where mobile traffic receives preferential treatment.

[INTERNAL-LINK: anchor -> guide-to-proxy-dns-leak-testing-and-mitigation: link to the DNS leak guide when explaining how residential proxy DNS routing affects IP authenticity]

Websites identify proxy traffic through several IP-layer signals that go beyond simple blocklists. Understanding these signals explains why IP type matters and why proxy rotation strategies are built around IP diversity rather than just IP volume.

ASN classification. Every IP address belongs to an Autonomous System registered with a regional internet registry. Anti-bot systems maintain constantly updated ASN classification databases that label each ASN as residential, mobile, datacenter, CDN, or proxy/VPN. A request from an IP in a known datacenter ASN triggers higher scrutiny regardless of other signals.

IP reputation scoring. IP reputation databases such as those maintained by Spamhaus, MaxMind GeoIP2, IPinfo, and commercial fraud detection providers assign risk scores to IP addresses based on observed behaviour across client networks. An IP that has been used for scraping, credential stuffing, or spam accumulates a high risk score and receives blocks or CAPTCHA challenges across all services that query the same reputation feed.

Rate limiting per IP. Even residential IPs receive blocks when a single IP generates an abnormally high request rate. A residential user generates perhaps a few hundred requests per hour across all sites. A scraper sending thousands of requests per minute from one IP produces a traffic fingerprint that rate-limiting logic catches regardless of IP type.

Geolocation consistency checks. Browser fingerprinting combines the IP's resolved geolocation with other signals including system timezone, Accept-Language header, and keyboard layout. A mismatch between IP geolocation (e.g., Germany) and browser locale settings (e.g., en-US, US timezone) is a weak signal that combined with others contributes to a bot score.

[PERSONAL EXPERIENCE] In a competitive price monitoring project across four e-commerce platforms, switching from datacenter proxies to residential proxies with session persistence reduced the CAPTCHA challenge rate from approximately 35% of requests to under 4%. The difference was entirely attributable to IP type: the datacenter ASNs were classified as proxy infrastructure in the target platforms' fraud detection stack, while the residential IPs from the same provider passed the ASN check. Request volume, rotation interval, and all other parameters remained identical between the two configurations.

Five networking concepts come up repeatedly in proxy documentation and support conversations. Each maps directly to a decision a proxy user makes in configuration.

Subnets and CIDR notation. A subnet is a range of IP addresses that share a common network prefix. CIDR notation (for example, 192.0.2.0/24) expresses this as the network address followed by the prefix length. A /24 block contains 256 addresses. Proxy providers often advertise their IP pool size in terms of subnets. For scraping tasks where subnet diversity matters (because target sites block entire /24 blocks after detecting one IP), this notation tells you how many distinct network segments are available.

Sticky sessions vs rotating IPs. Sticky session proxies maintain the same exit IP for a configured duration (typically 1-30 minutes), so multi-step workflows like authentication followed by checkout appear to come from the same IP across requests. Rotating proxies assign a new exit IP on each request or connection, maximising IP diversity at the cost of session continuity.

IP whitelisting vs username/password authentication. Proxy providers offer two authentication models. IP whitelisting authorises specific client IPs to use the proxy without credentials, which is simpler but requires a fixed outbound IP. Username/password (or token) authentication works from any IP but requires credential management in the application code.

IPv6 routing gaps. Most commercial proxy pools are IPv4-only. If your application or OS prefers IPv6 connections for dual-stack target servers, the IPv6 connection bypasses the proxy and goes direct, exposing your real IP. This is the most common category of proxy leak in environments where IPv6 is enabled on the client system. The operational fix is to disable IPv6 on the interface used for proxy traffic when the proxy provider does not support IPv6 tunneling.

Egress IP vs proxy IP. The proxy server address you configure in your application is not necessarily the IP that target servers see. Many commercial proxy services use a gateway address for the client-to-proxy connection but route outbound traffic through a separate pool of egress IPs. The configured proxy IP is the ingress to the service; the IP visible to the target is the egress IP assigned from the pool.

[INTERNAL-LINK: anchor -> proxy-authentication-methods: link to proxy authentication guide when discussing IP whitelisting and credential management in detail]

The correct proxy type depends on the IP authenticity requirement of the target, the session behaviour required, and the acceptable cost per IP. Matching these three axes to the proxy category eliminates most configuration problems before deployment.

| Requirement | Recommended proxy type | Why |

|---|---|---|

| Public data collection from unprotected APIs or sites | Datacenter rotating | Fast, cheap, sufficient for unprotected targets |

| Scraping sites with basic bot detection (ASN-level checks) | Residential rotating | Passes ASN classification; cost justified by higher success rate |

| Multi-step flows requiring session persistence (login, cart, checkout) | Residential sticky session | Same exit IP maintained across the session duration |

| Mobile app testing or platforms that favour mobile traffic | Mobile proxies | Carrier-grade NAT IPs receive highest tolerance from detection systems |

| Geo-restricted access for a specific country | Residential with geo-targeting | ISP-assigned IPs in the target country pass geolocation consistency checks |

| Internal network testing without exposing real IP | Datacenter / self-hosted SOCKS5 | No anonymity requirement; performance and cost are the deciding factors |

The relationship between proxy type, IP origin, and detection probability forms a cost-performance curve. Datacenter proxies are typically 5-20x cheaper than residential proxies per GB of traffic, but their higher block rates on protected targets can make the effective cost per successful request equal to or higher than the residential alternative when the target enforces ASN-level filtering.

[INTERNAL-LINK: anchor -> residential-proxy-use-cases: link to residential proxy use cases article when discussing scraping and geo-targeting decisions in more detail]