IP Whitelists and Passwords Authenticate Different Things. One SOCKS5 Byte Explains Why.

The same IP and port works in a router firmware and fails in a browser extension with "authentication failed". The line is fine. What changed is which of two models the client and the server are speaking.

Vendors sell both under one product page and the choice looks cosmetic. It is not: one authenticates a network location, the other authenticates a secret.

Two models, one selection byte

A whitelist checks your source address before anything else happens. The proxy sees a TCP connection arriving from an IP it already has on file, allows it, and never asks for a credential. Nothing about the person is proven — only that the packets came from a known place.

Credentials work the other way. SOCKS5 carries them as a sub-negotiation, defined in RFC 1929 and selected by method code 0x02 in RFC 1928. HTTP proxies use Basic authentication (RFC 7617) and put the pair in a header. Either way the check is on what you present, not on where you are.

The practical consequence: the two failure modes point in opposite directions. A dead whitelist means your address moved. A dead password means the string you sent is wrong.

Ask the server which model it wants

You do not have to guess. Both models are negotiated in the first exchange, so a raw probe tells you what the server expects before you touch any config file. The client sends a greeting listing the methods it supports; the server replies with exactly one.

import socket GREETING = b"\x05\x02\x00\x02" # ver, nmethods, no-auth, user/pass def probe(host, port, user=None, pw=None): s = socket.create_connection((host, port), timeout=8) s.sendall(GREETING) ver, method = s.recv(2) if method == 0x00: print("no-auth accepted: this line is whitelisted for you") return s if method == 0xFF: print("no acceptable method: you are not whitelisted and sent no credentials") return None if method == 0x02 and user: u, p = user.encode(), pw.encode() s.sendall(bytes([1, len(u)]) + u + bytes([len(p)]) + p) if s.recv(2)[1] != 0x00: print("credentials rejected") return None print("authenticated by password") return s 

Method 0x00 means the server accepted you without a secret — a whitelist match, or a line open to anyone. Method 0x02 means it wants credentials. Method 0xFF means nothing on your list was acceptable — the reply most people misread as "the line is down".

Where each failure actually happens

Once you know which method the server selected, the error message stops being ambiguous. Almost every "cannot connect" ticket resolves into one row below.

The last two matter most. A TCP refusal never reaches authentication, so no credential edit will fix it. A silent drop after a successful handshake is a rate or session limit.

Whitelists break in three predictable ways

A whitelist is a binding to an address you do not control, and three situations dissolve it without any error message.

Home broadband redials. A reconnect or reboot often hands you a different public address, while the old entry stays in the backend looking valid. This is the most common cause of "it broke overnight".

Carrier-grade NAT shares your exit. When several subscribers sit behind one translated address, your entry may cover other people too, and some providers treat that as shared use.

Multiple devices behind one router present the same address. Only the router's egress is registered, so a second machine on the LAN is not automatically authorized.

Why one client works and another does not

Clients implement different subsets of the negotiation. Many browser extensions expose only a username and password field, so they send 0x02 and never offer 0x00. A router firmware usually supports both modes.

A second trap costs people entire evenings: the L2TP pre-shared key for tunnel setup and the account password for PPP authentication are separate fields. Putting the key in the password box fails at dial-up, before authentication is attempted.

Ask which model the client speaks, and whether the backend has a matching entry.

Common mistakes

• Registering a LAN address such as 192.168.x.x instead of the public egress the proxy actually sees.
• Copying credentials from a web dashboard and picking up a trailing space or a full-width colon.
• Assuming a whitelist entry updates itself when the ISP reassigns your address.
• Filling the L2TP pre-shared key into the password field.

FAQ

Can I enable a whitelist and a password at the same time?
Usually yes. The proxy accepts a match on either model. The risk is a stale whitelist entry that no longer matches anything — it does not error, it simply stops helping.

Why does my client demand a username when the dashboard says whitelisted?
The client only implements the credential method. Either extract a credential pair from the backend, or move that line to a client that supports no-auth.

Does switching Wi-Fi really require a different vendor?
No. It requires a different model. Home broadband and hotspot egress move constantly, so use credentials there and reserve whitelisting for fixed egress.

Are credentials tied to one device?
No. They are a secret, not a device fingerprint, so the same pair works on a laptop, a phone, and a router. What limits you is the provider's concurrent session cap, which shows up as a drop after connection, not a rejection.

If you want to test which model a line expects without buying anything, run a real handshake — the probe above, or the free checker at socks5ip.com.cn. A line answering 0x00 is whitelisted for your current address; one answering 0x02 needs the credential you were issued. The Chinese-language walkthrough of both models is at socks5ip.com.cn.