Proxy authentication by IP or by login: when to use which

How it looks from the proxy's side

With login authentication the client passes credentials in the connection itself and the proxy checks them against the plan. With address authentication there is nothing to pass: the proxy looks at which IP the connection came from and searches for it in the allowed list. Every further difference follows from that.

# Login authentication: credentials in the connection string
curl -sI -x http://LOGIN:PASSWORD@GATEWAY:PORT https://example.com | head -1

# IP authentication: the same string without credentials.
# Works only if this machine's address is in the whitelist.
curl -sI -x http://GATEWAY:PORT https://example.com | head -1

# Which external address this machine has — that is what goes in the whitelist
curl -s https://op-proxy.com/api/check

When a whitelist is the only option

A whole class of programs accepts only an address and a port, with no credentials field in the interface. Headless browsers are a separate story: Chromium ignores credentials passed in the launch argument and shows a native authentication dialog instead, which the driver will not fill in.

• Software with fields for host and port only.
• Puppeteer and other Chromium wrappers, where credentials need a separate call.
• Scheduled runs, where you would rather not keep a password in a config or environment.

When a login is safer

Exactly the opposite situation: when the machine's address is not fixed. Home and mobile connections almost always hand out a dynamic IP — it changes on reconnect, the whitelist stops matching, and the proxy responds as though the password were wrong.

• A laptop that moves between networks.
• An ISP with dynamic addressing.
• Several people running the work, each from their own address: whitelist slots will not stretch.

Both schemes at once is a working configuration

You do not have to pick one for the whole project. Here login and whitelist are active simultaneously, which maps neatly onto real infrastructure: a server that runs around the clock with a fixed address connects by whitelist without a password, while a developer's laptop and one-off scripts use the login.

A separate benefit is diagnosis. When something stops working, you check the same proxy the other way and immediately know where the problem is — credentials or address.

Whitelist risks worth knowing

• The address changed — access is gone, and the symptom looks like a wrong password.
• An entire office can sit behind one external address: allowing it allows anyone on that network.
• Whitelist slots are limited, and a dozen machines may not fit.

Diagnosis: which scheme actually worked

Both schemes fail similarly, and the symptom does not distinguish them: either way the proxy replies that it did not recognise the client. But you can test them in turn against the same proxy, and the result shows immediately where the problem is.

# Whichever address the proxy sees from your side is the one to whitelist.
# A machine's external address and the address in its network settings almost
# always differ.
curl -s https://op-proxy.com/api/check

# Testing both schemes in turn against the same proxy:
curl -sI -x http://LOGIN:PASSWORD@GATEWAY:PORT https://example.com | head -1  # by login
curl -sI -x http://GATEWAY:PORT               https://example.com | head -1  # by whitelist

# First works, second does not -> the address is not on the list.
# Second works, first does not -> wrong login and password.

The first thing to establish when access disappears is your current external address. It differs from the address in your machine's settings whenever a router or carrier NAT sits between you and the internet, which is nearly always.

What the target site sees

The authentication method does not affect this — the site does not know how you authenticated with the proxy. But there is an adjacent misconception worth clearing up, because people choose protocols and plans on the basis of it.

Proxies have service headers conventionally used to mark a proxied request: the originating client's address, an indication that an intermediary was involved, and a standardised version of the same. Proxies are sometimes graded as transparent, anonymous or elite on that basis.

• Working over https — there is physically nowhere to add headers that reveal a proxy.
• Working over http — check what actually reaches the server with an echo endpoint.
• Promises of elite proxies for HTTPS work describe a property that changes nothing there.