Proxy Authentication Methods for Teams and Infrastructure

Credentials and IP whitelisting diverge once CI runners, NAT and staff churn arrive: how each scales, rotates, audits and fails.

A proxy has to decide, for every connection, whether the traffic behind it belongs to a paying account. There are two mechanisms for proving that it does: a credential the request carries with it, or a source address the account registered in advance. The setup steps for both are in the authentication guide, and this article deliberately does not repeat them. The interesting question is not how to configure either method; it is how each one behaves a year later, when "the team" is no longer one person with a laptop but a mix of employees, deployed services, containers and CI jobs that all need the same egress.

The short version: a credential is a secret, and inherits every property of secrets: it can be distributed, leaked, rotated, scoped and audited. A whitelist entry is a property of your network, and inherits every property of networks: effortless to use, invisible to the people relying on it, and exactly as coarse-grained as your topology. Most of the decisions below fall out of those two sentences.

Day one, when the difference is invisible

For a single developer, both modes cost about a minute. Paste a username and password into a client, or register your current public address and connect with no credentials at all. Either way the first request flows, and nothing about that experience predicts how differently the two approaches age. The divergence begins with the second person, and it compounds with every runner, container and contractor added after that.

It is worth noticing that whichever mode gets configured first tends to persist by pure inertia. The whitelist entry created for a prototype becomes the way production authenticates two years later, not because anyone weighed the trade-offs but because it already worked. Since the choice is going to harden into infrastructure either way, the cheap moment to make it deliberately is now, while changing course costs nothing.

How should a team share proxy credentials?

Ideally it should not have to. Give each consumer its own credential rather than passing one around, or authenticate by IP whitelist, where there is no secret to distribute in the first place.

The moment a credential serves more than one consumer, somebody has to move it around, and the moving is where things go wrong. The failure patterns are well worn: the password pasted into a chat channel that a departed contractor can still search, the wiki page titled "proxy login", the .env file that quietly reached version control. A proxy credential deserves the same handling as a database password: a secrets manager as the single source, injection into services at deploy time, masking in anything that logs.

The better structural answer is to stop sharing one credential at all. A node4 account on a paid plan can hold up to 5 distinct proxy credentials, which is enough to give the scraper fleet, the QA environment and the data team identities of their own. This is not ceremony. Separate identities are the thing that makes the rotation and audit sections below workable. A shared credential collapses every question of "who" into "everyone".

Before weighing the two, check that the choice is yours to make. On node4 the whitelist is offered on the static datacenter products (shared and dedicated) and on all three rotating gateways, because what you register is your own source address rather than the exit; residential accepts it too, with the caveat that a whitelisted residential connection carries no username and therefore no targeting. Most providers draw the line at static products only, which is worth knowing when you compare.

IP whitelisting has no distribution problem, because there is nothing to hand out. Register the office's static address, or the NAT gateway your servers leave through, and every machine behind it is authenticated implicitly. A new laptop, a new hire, a rebuilt container: zero onboarding steps. That silence is simultaneously the feature and the hazard. Nobody can mishandle a secret that does not exist, but nothing distinguishes the approved crawler from an unapproved side project, or from malware, on the same network. A whitelist entry authenticates a place, and everything currently standing in it.

How do I rotate a proxy credential without downtime?

Generationally. Create the replacement alongside the old credential, move consumers across at their own pace, watch traffic on the old one fall to zero, and only then delete it. Whitelist entries follow the same add-before-you-remove rule.

Secrets need replacing: an employee leaves, a laptop is stolen, a log turns out to have captured headers, or plain hygiene says it is time. With a single credential shared everywhere, rotation is a self-inflicted outage: the moment the password changes, every consumer fails authentication until it is redeployed, and you discover consumers you forgot existed by watching them break.

The workable pattern is generational. Create a second credential alongside the first, migrate consumers to it at their own pace, watch traffic on the old one fall to zero, and only then delete it. At no point does anything fail. This requires holding at least two valid credentials simultaneously, which is the practical reason multiple credential slots are a baseline need rather than a luxury. It is worth rehearsing the procedure once before the day a leak makes it urgent.

Whitelists rotate on a different trigger. There is no scheduled hygiene, because there is no secret to age; entries change when addresses change: an office moves ISP, a cloud NAT gateway is rebuilt, a datacenter migration lands. The discipline mirrors the credential pattern in one respect: add before you remove. Register the new address while the old one still works, move traffic across, confirm, then delete the stale entry. Removing first opens a window in which production traffic arrives unrecognized and is refused. Paid plans include 3 whitelist slots, which is what makes the overlap period possible without juggling.

Can I use IP whitelisting from a hosted CI runner?

No, not usefully. A hosted runner takes its address per job from a cloud provider's pool, so any entry wide enough to admit your own build is also wide enough to admit that provider's other tenants.

Hosted CI is where IP whitelisting stops being a candidate at all. A hosted runner draws its address per job from a cloud provider's pool, which spans ranges you do not control and share with every other tenant. There is no address to register, and registering the range would mean authenticating a slice of someone's cloud region: an open proxy with your billing attached.

So CI authenticates with credentials, held in the CI system's secret store and masked in job output. Scope matters more here than anywhere else: dedicate a credential to CI and to nothing else, because CI logs are one of the most common places secrets leak, and a dedicated credential turns that event into a one-line revocation instead of a production incident.

If your policy genuinely requires whitelisting for CI, the option is to build the stable egress yourself: self-hosted runners, or jobs routed through a NAT instance with a fixed address you register once. It works, and plenty of teams run it, but you have converted an authentication question into an infrastructure component with its own uptime, patching and cost. Make that trade knowingly.

Containers behind NAT

Container platforms invert the CI situation. A cluster of fifty pods typically leaves through one NAT address or a small handful, so a single whitelist entry covers the entire fleet: no secret mounts, no rotation plumbing, no library configuration. Operationally this is lovely. It is also maximally coarse: every pod on the cluster is authenticated, including the compromised one, and the proxy-side usage data cannot say which workload consumed what.

Running credentials inside shared egress restores the granularity. Give each deployment its own credential through the platform's secret mechanism and you get per-service attribution and per-service revocation back, at the cost of managing those secrets. A middle path that works well: a small egress service or sidecar holds the proxy credential, and application containers talk to it: the secret exists in one place, application code never sees it, and swapping it touches one deployment.

Which authentication mode gives the better audit trail?

Credentials, provided you issue a separate one per consumer. Whitelisting stops attributing at the source address, and behind NAT that is one number for the whole building.

At the end of the month, someone asks which system consumed the bandwidth, or why usage doubled on the 14th. What you can answer depends entirely on the authentication mode you chose months earlier.

With credentials you at least have distinct identities to reason about, but be precise about what the dashboard shows you: the breakdown is per proxy, not per credential. On gateway products, where a credential corresponds closely to the endpoint it uses, that lines up well enough to answer "which workload was the spike". On static plans with several credentials sharing a pool of proxies, it does not: you can see which addresses were busy, not which credential drove them. If per-team accounting matters to you, separate the proxies as well as the credentials.

With whitelisting, attribution stops at the source address, and behind NAT the source address is one number for the whole building. This is not a reporting deficiency anyone can fix later; the information never existed at the edge. On metered plans, where bandwidth is the bill, that difference is money: an anomaly you can attribute is an anomaly you can stop the same day. The features page shows what per-account usage reporting exposes; how the totals turn into charges is on pricing.

What is the blast radius when a proxy credential leaks?

Exactly the set of systems sharing it, which is why per-purpose credentials matter here more than credential strength does.

The two modes fail in opposite directions, and the comparison is worth making explicitly.

A leaked credential works from anywhere on earth. The first symptom is usually traffic you do not recognize: odd hours, unfamiliar targets, bandwidth climbing against your cap. The response is revocation, and the blast radius is exactly the set of systems sharing that credential: with per-purpose credentials, one team re-deploys; with a single shared credential, everything you run authenticates through the thing you just revoked, and rotation becomes an org-wide fire drill. If the first symptom you see is authentication suddenly failing, the 407 guide separates a revoked credential from the mundane causes.

Detection deserves a habit of its own, whichever mode you run. Establish what normal looks like (which identities are active, at what hours, against roughly what volume) and glance at the per-proxy usage breakdown on a schedule rather than waiting for the invoice to surprise you. Compromise announces itself in that data days before it announces itself anywhere else, and the announcement is only legible if you know your own baseline.

A whitelist cannot leak, because there is no secret; the risk relocates into the machines. An attacker who compromises any whitelisted host acquires your proxy access with zero credentials required, and the traffic is indistinguishable from yours at the edge. Subtler and more common: address recycling. Release a cloud elastic IP without deleting its whitelist entry, and the address's next tenant, a stranger, silently inherits authenticated access. Stale whitelist entries are the exact analogue of unrotated passwords, and the countermeasure is the same discipline on a calendar: review the list, delete anything you cannot name a current owner for. IP whitelisting best practices covers the review procedure.

A defensible default

No single mode wins outright, and the strongest setups run both, each where its failure properties are acceptable:

Humans on a stable office network: whitelist the office egress. Zero friction, and departures are handled by the fact that leavers are no longer in the building or on the VPN.
Production services: per-service credentials from a secrets manager. Attribution and small-radius revocation are worth the plumbing.
CI: a dedicated credential per pipeline system, or self-managed stable egress if policy demands addresses.
Everything: a recurring calendar entry that reviews both the credential list and the whitelist, because both accumulate entries nobody remembers creating.

Dashboard API keys (the n4k_ tokens that drive the management API) are a separate secret class with their own handling rules; API key security treats them properly.

Both modes are available on every plan, including the free tier, which carries 1 credential and 1 whitelist entry, enough to trial each mode against your real infrastructure before deciding which one your team standardizes on. If you are still choosing what sits behind the authentication, the datacenter guide covers picking the proxy itself.