An IP proxy is a proxy endpoint that relays supported traffic so a destination observes a proxy exit address instead of the client’s usual public address. The phrase is informal: it does not say whether the service uses HTTP or SOCKS, IPv4 or IPv6, a static or rotating exit, or private or shared access. Those properties must be specified separately.<\/p>\n
Scope:<\/strong> this guide focuses on address roles, families, and ownership evidence within the Proxy Basics hub<\/a>. Start with how a proxy server routes traffic<\/a> if the three-hop model is new, or use the access and rotation comparison<\/a> when address behavior is already clear.<\/p>\n The client public IP is the address from which the proxy receives a connection. The gateway is the host and port the client contacts. The exit is what the destination sees. A static endpoint may use one address for gateway and exit, while a load-balanced or rotating service may keep a stable gateway and select different exits. Record each identifier by role rather than calling all of them the proxy IP.<\/p>\n Expected observation:<\/strong> an exit-IP check should match the assigned family and expected country, but it need not match the gateway address. If the client address remains visible, inspect bypass rules and the actual application profile before blaming the endpoint.<\/p>\n IPv4 addresses are the familiar dotted numbers and remain broadly supported across clients and destinations. Their limited address space affects how networks allocate and reuse them, but an IPv4 label says nothing about exclusivity, reputation, or location accuracy. Test the real target rather than assuming compatibility guarantees acceptance.<\/p>\n Source-IP authentication must use the public address the provider observes, not a private LAN address such as 192.168.1.20. Home, mobile, VPN, and cloud egress addresses can change, causing an allowlist failure even when the proxy stays healthy.<\/p>\n IPv6 provides a much larger address space and uses colon-separated notation. RFC 8200 specifies IPv6<\/a>. The client, proxy network, DNS resolution, intermediate path, and destination must all support the required family. An IPv6 endpoint cannot by itself make an IPv4-only destination speak IPv6.<\/p>\n Check whether the application accepts bracketed IPv6 literals, whether the gateway hostname returns A or AAAA records, and which family the destination supports. Compatibility is an observed property of the complete route, not a conclusion drawn from the number of available addresses.<\/p>\n Regional internet registries publish allocation and registration data. ARIN’s RDAP documentation<\/a> explains how to query registration records. That evidence identifies the registered network or range; it does not prove that every address is physically in a claimed city or that one operator exclusively uses it.<\/p>\n Geolocation databases can disagree or update at different times. Account settings, language, billing address, cookies, and GPS may also affect regional experiences. The residential and datacenter guide<\/a> explains why network ownership is separate from observed location.<\/p>\n Credential and evidence limits:<\/strong> keep gateway inventories and authentication in protected configuration, redact authenticated URLs from logs, and name the registry or geolocation database and date used for every conclusion. No IP classification proves anonymity or permission.<\/p>\n A 403 or 429 from the destination is not proof that the proxy is offline. Compare gateway reachability, exit evidence, and destination response so replacement does not hide an authorization or rate-limit problem. The proxy testing guide<\/a> provides that layered sequence.<\/p>\n When the address family is part of the requirement, use the dedicated IPv4 vs IPv6 proxy comparison<\/a> to test destination support, dual-stack DNS, allowlists, and the observed exit instead of choosing from address supply alone.<\/p>\nIP proxy definition: gateway is not always exit<\/h2>\n
IPv4: broad compatibility and scarce space<\/h2>\n
IPv6: larger space with end-to-end requirements<\/h2>\n
Address ownership and location evidence<\/h2>\n
Verification: test address behavior over time<\/h2>\n
\n
Select a location only after defining the address requirement<\/h2>\n