IP whitelisting for proxies means the proxy accepts connections from addresses you registered in advance, with no username and no password. Every other address is asked to log in. The address is the credential: the proxy reads it from the connection itself, so nothing secret crosses the network. It suits a server with a fixed public address. It breaks when your address changes, and it lets in everyone who shares your address.
We checked how this works on 10 October 2026. From our own server, we asked our proxy gateway what a client off the list receives. We also measured which public address one machine presents over IPv4 and over IPv6, since that address is what the list is checked against. The short definition sits in our glossary under IP whitelisting. This page shows the mechanism and the failures.
How does a proxy check your address?
It reads it from the connection. TCP identifies every connection by a pair of sockets, and a socket is an address plus a port. RFC 9293 (IETF, August 2022) defines a connection as "a logical communication path identified by a pair of sockets". So the proxy knows your source address before you send the first byte of HTTP or SOCKS.
If that address is on the list, the proxy serves the request without a login. If it is not, the proxy falls back to asking for one. How it asks depends on the protocol.
- HTTP proxies answer
407 Proxy Authentication Required. RFC 9110 (IETF, June 2022) says the proxy "MUST send a Proxy-Authenticate header field" with that status, and the client may repeat the request with aProxy-Authorizationheader. - SOCKS5 proxies negotiate a method first. The client lists the methods it supports:
X'00'for no authentication,X'02'for a username and password. RFC 1928 (IETF, March 1996) says that if the server answersX'FF', "none of the methods listed by the client are acceptable, and the client MUST close the connection".
What a client off the list receives
We sent our gateway, premium.hproxy.com, these requests from our server, whose address is on no list. The SOCKS5 tests sent only the greeting and never asked for a relay. The HTTP tests asked for a tunnel to 192.0.2.1:9, a documentation address that cannot be reached. So no traffic could flow, even by mistake.
| What our server sent | What the gateway answered | What the standard says it means |
|---|---|---|
SOCKS5 greeting 05 01 00: no authentication only | 05 ff | No acceptable method; the client must close (RFC 1928) |
SOCKS5 greeting 05 02 00 02: none, or a login | 05 02 | The server chose username and password (RFC 1929) |
HTTP CONNECT with no login | 407 Proxy Authentication Required with a Proxy-Authenticate: Basic challenge | The client must log in to use the proxy (RFC 9110) |
HTTP CONNECT with a wrong login | The same 177 bytes, byte for byte | Nothing tells it apart from a missing login |
The answers were the same in three runs, at 18:35, 18:46 and 18:47 UTC.
Why the error never says your address is missing
The last row matters most when you troubleshoot. A whitelist miss and a wrong password produced identical answers. The body of both read "Authentication error. Please check your authentication settings". Our error reference reads a gateway 407 the same way: the username or password is wrong, and "a whitelisted IP connects without credentials". So when a working setup suddenly answers 407, check your own public address before your password. Our guide to fixing a 407 error covers the password side.
Which address does the proxy see?
The proxy sees your public address, after every translation on the way. That is often not the address your computer shows you.
- PC at home192.168.1.20, a private address
- Home routerNAT: many devices, one address
- Proxy seesthe router's public IPv4
IPv4 behind a home router
- The same PCa temporary IPv6 address
- Home routerroutes the PC's own address
- Proxy seesthe temporary address, new each day
IPv6, when the proxy host has an IPv6 record
- Phone on mobile dataan address in 100.64.0.0/10
- Carrier NATmany subscribers, one address
- Proxy seesa carrier address shared with strangers
IPv4 behind carrier-grade NAT
Behind a home router
Addresses such as 192.168.1.20 are private. RFC 1918 (February 1996) reserves 10/8, 172.16/12 and 192.168/16 for private networks and says these addresses "have no global meaning". Your router translates them. RFC 3022 (January 2001) describes how "many network addresses and their TCP/UDP ports are translated into a single network address". The proxy sees that single address. Whitelisting 192.168.1.20 can never match.
That public address may also move. RFC 2131 (March 1997) says that in dynamic allocation, DHCP "assigns an IP address to a client for a limited period of time". When the lease ends with a new address, the whitelist stops matching. No primary source gives a typical lifetime for home addresses, so we give none.
Behind carrier-grade NAT
Some providers add a second NAT inside their own network. RFC 6888 (April 2013) describes a service "where a public IPv4 address would be shared by many subscribers". Your device then shows an address from 100.64.0.0/10, the range RFC 6598 reserves for carrier NAT. Whitelisting the carrier's public address admits other subscribers too. Our explainer on CGNAT covers the rest.
On IPv6
With IPv6, each device usually sends from its own global address. RFC 7368 (IETF, October 2014) describes IPv6 home networks as offering "global addressability through the use of globally unique addresses in the home". So the proxy sees your computer's own address, and desktops change it on purpose. RFC 8981 (February 2021) defines temporary addresses, with default lifetimes of one day preferred and two days valid. Deprecated ones "are not used to initiate new connections". RFC 6724 (September 2012) tells a system to prefer a temporary address over its stable one for outgoing traffic.
We read the settings of one Windows 11 desktop on 10 October 2026. Temporary addresses were on, with a maximum preferred lifetime of one day and a maximum valid lifetime of seven days. The PC held one stable address and two temporary ones. One was already deprecated. The other was preferred for about 19 more hours. A whitelist entry for that IPv6 address would stop matching within a day.
People meet this in practice. A Stack Overflow question from October 2021 describes an IPv4 address that never changed and an IPv6 address that kept changing, which locked the writer out of a whitelisted office network.
Which address family does your connection use?
A dual-stack machine has an address in each family, IPv4 and IPv6. A server sees whichever family the client picked for that connection. RFC 6724 sets the default. Its policy table prefers "communication using IPv6 addresses to communication using IPv4 addresses" when both are available. On Linux, the C library reads that preference from /etc/gai.conf, and one line changes it.
We tested this on our own server on 10 October 2026. It runs Ubuntu 24.04 with curl 8.5.0 and has one IPv4 and one IPv6 address. We asked our own echo endpoint, which returns the address it saw, three ways.
The -4 and -6 requests were seen as two different addresses. Plain curl used the IPv4 address, because our server carries the line precedence ::ffff:0:0/96 100. The glibc sample file says exactly that: "For sites which prefer IPv4 connections change the last line to" that line. We then ran plain curl once more with an empty gai.conf, inside a private mount namespace so the rest of the server was untouched. This time the echo saw the IPv6 address. The machine and the command were the same; only the public address changed.
Why the proxy hostname decides
If a proxy hostname has no IPv6 record, the proxy can only receive your connection over IPv4. On 10 October 2026, premium.hproxy.com had one IPv4 (A) record and no IPv6 (AAAA) record. So every connection to our gateway arrives over IPv4, and the IPv4 address is the one to whitelist. A "what is my IP" page reached over IPv6 can show you an address our gateway never sees.
Read the right one with the address family pinned. The curl manual says -4 makes curl "Request only IPv4 addresses when resolving hostnames". Run this on the machine that will connect:
curl -4 https://hproxy.com/api/free-proxy/echo
The ip field is the address to whitelist for an IPv4-only proxy. If your provider's hostname also has an AAAA record, run it with -6 as well, and add both addresses or pin your client to one family.
How do you set up IP whitelisting?
Four steps, the same with any provider:
- Find the public address the proxy will see. Run the
curl -4command above on the machine that will connect, not on your laptop. - Add the address to the list. Providers put the list in the dashboard, the API, or both. On our network, the list belongs to a Residential Premium plan and holds up to 150 addresses. Each entry must be a single IPv4 or IPv6 address, so a range such as
203.0.113.0/24is not accepted. - Connect without a username. Point your client at the proxy host and port and leave the login empty.
- Check the exit. Ask the echo endpoint again through the proxy. It should show the proxy's exit address, not yours.
Through our API, step 2 is one call. This is the documented form, with a documentation address:
curl -X POST https://hproxy.com/api/v1/plans/PLAN_ID/whitelist \
-H "X-API-Key: hpx_your_key_here" \
-H "Content-Type: application/json" \
-d '{"ips": [{"ip": "203.0.113.9", "description": "office"}]}'
The answer lists the addresses on the plan and the ceiling:
{
"planId": "PLAN_ID",
"max": 150,
"ips": [ { "ip": "203.0.113.9", "description": "office" } ]
}
Steps 3 and 4 then look like this, with no login in the proxy URL:
curl -x http://premium.hproxy.com:10000 https://hproxy.com/api/free-proxy/echo
A whitelisted connection carries no username, and on our network the username is where targeting lives. So it takes no country or city. Our plans documentation says it "rotates through any country on the rotating ports and holds one IP per sticky port". When you need a country, use the generated lines with the password.
Whitelist or username and password?
| IP whitelisting | Username and password | |
|---|---|---|
| What the proxy checks | The source address of the connection | A login sent in the request or the SOCKS5 handshake |
| What crosses the network | No secret | The login, as cleartext with Basic or SOCKS5 |
| When your address changes | Access stops until you update the list | Nothing changes |
| Behind a shared address | Everyone behind it gets in and spends your traffic | Only people with the login get in |
| Country or city targeting | None on our network | Carried in the username |
| Best for | A server with a fixed public address | Laptops, phones, home lines, cloud jobs |
The cleartext row comes from the standards. RFC 7617 (September 2015) says Basic is not a secure method unless TLS or a similar system protects it, "as the user-id and password are passed over the network as cleartext". RFC 1929 says the same of the SOCKS5 login. Our proxy authentication entry compares the two methods in more depth.
Where else is IP whitelisting used?
The same check appears well outside proxies. GitHub calls it an IP allow list. Its help page says "you can allow access to the private resources exclusively from the IP address of your office network". Unlike our proxy list, it accepts "a single IP address, or a range of addresses, using CIDR notation". IPv6 trips these lists as well. A Server Fault question from June 2012 describes Exchange servers that failed to relay mail because they talked over IPv6 and matched no whitelisted IPv4 rule.
What IP whitelisting is not
- Not encryption. It removes the login from the wire and adds nothing else. What you send through the proxy is protected only by TLS inside the tunnel, as with any proxy.
- Not a lock for one person. Our docs warn that "everything that connects from a whitelisted IP spends this plan's traffic". A shared office, VPN or cloud address is shared "with everyone behind it".
- Not a reputation list. Some proxy providers use "ISP whitelist" for exit addresses a target site is said to trust. Email senders use it for a mailbox provider's list of approved senders. Two of the eight ranking pages we read were about email. Neither meaning decides who may use your proxy.
- Not a way to choose a country. With no username, there is nothing to carry the targeting.
Where to go from here
To see the address and headers a website receives from your browser, use our proxy IP checker; on a dual-stack line it may show your IPv6 address. For the IPv4 and IPv6 side of proxies themselves, read IPv4 vs IPv6 proxies. On our network, IP whitelisting comes with every Residential Premium plan, for up to 150 addresses.
What this page could not check
We did not test the success path. No plan was bought or used, so what a whitelisted address receives comes from our documentation, not from a measurement. The address tests ran on one Linux server and one Windows 11 PC; macOS, Android and iOS were not measured. Other providers may accept ranges, or may answer a miss differently from our gateway. No primary source gives a typical lifetime for a home IPv4 address, so this page gives none. The gateway's DNS records, our list limit and operating-system defaults can change, so we will check this page again by 10 January 2027.
Sources
- RFC 9293, Transmission Control Protocol, IETF, August 2022.
- RFC 9110, HTTP Semantics, IETF, June 2022.
- RFC 7617, The Basic HTTP Authentication Scheme, IETF, September 2015.
- RFC 1928, SOCKS Protocol Version 5, IETF, March 1996.
- RFC 1929, Username/Password Authentication for SOCKS V5, IETF, March 1996.
- RFC 1918, Address Allocation for Private Internets, IETF, February 1996.
- RFC 3022, Traditional IP Network Address Translator, IETF, January 2001.
- RFC 2131, Dynamic Host Configuration Protocol, IETF, March 1997.
- RFC 6888, Common Requirements for Carrier-Grade NATs, IETF, April 2013.
- RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space, IETF, April 2012.
- RFC 8981, Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6, IETF, February 2021.
- RFC 6724, Default Address Selection for IPv6, IETF, September 2012.
- RFC 7368, IPv6 Home Networking Architecture Principles, IETF, October 2014.
- GNU C Library, sample gai.conf (posix/gai.conf), read 10 October 2026, and the gai.conf(5) manual page, Linux man-pages 6.7, October 2023.
- curl manual, options -4 and -6, curl project, read 10 October 2026.
- GitHub Docs, Managing allowed IP addresses for your organization, read 10 October 2026.
- HProxy documentation, plans (IP whitelist) and errors (gateway status codes), read 10 October 2026.
- Questions people asked, cited as examples and not as evidence: Stack Overflow, Whitelisting a IPv6, asked 21 October 2021; Server Fault, IPv6 Addresses causing Exchange Relay whitelists to fail, asked 10 June 2012.
- Our own measurements, 10 October 2026: gateway answers to a client on no list, the IPv4 and IPv6 address test on our server, and the temporary-address settings of one Windows 11 PC. Scripts and outputs are in the research folder for this page.
