Proxy list vs proxy gateway: what each model makes you own, the per-IP against per-GB break-even formula, and why pool size is not a purchase criterion.
· 17 min read · Fundamentals
Proxy list vs proxy gateway, which is better: the question is really about which system you are agreeing to operate, and it decides more of your architecture than the price per unit does. A list hands you N endpoints and the entire lifecycle that comes with them: health checks, retirement, rotation, credentials, reputation. A gateway hands you one hostname and takes that lifecycle away, along with your visibility into it. Everything else — the billing model, the failure modes, what you can debug — follows from that one difference.
The comparison articles that rank for this usually put two prices side by side without naming the models they belong to. Here are the models.
Neither, categorically. The honest answer is a function of three variables: how many gigabytes each address carries per month, how many distinct geographies you need, and whether a fixed identity is part of what you are buying.
| Proxy list | Proxy gateway | |
|---|---|---|
| What you receive | N host:port pairs, often with per-IP credentials | One hostname, one credential |
| Rotation | You build it | Selected by port or parameter |
| Health checking | Yours | Upstream's |
| Geography | Fixed at purchase | Per request |
| Typical billing | Per IP, per month | Per gigabyte |
| Scaling up | Buy more IPs, redeploy config | Send more requests |
| Scaling down | Cancel at renewal | Stop sending requests |
| Visibility into exits | Total | Only what you observe |
| Fixed identity per address | Yes | Only within a sticky window |
| Configuration surface | N entries to keep current | One endpoint |
Read the last row as an operational cost, not a convenience. A list of 500 proxies is 500 pieces of state your code has to hold opinions about.
You buy addresses. You get a file, or an API endpoint that returns a file, and each line is a host, a port, and usually a username and password scoped to that one address. From that moment, everything downstream of "which address should this request use" is your code.
That is not a criticism. Owning the list means owning the decisions, and for some workloads the decisions are the point.
Dead-IP detection and retirement. Addresses stop working. Not with an error you can catch cleanly — with timeouts, with TLS handshake failures, with 403s that look like a target block but are actually a burned address. You need a health check that distinguishes "this address is dead" from "this target is hostile today," and getting that wrong in either direction is expensive. Too aggressive and you retire good capacity; too lenient and you keep sending traffic into a hole.
Per-IP credentials. Some lists issue one credential per address. Now your secret store has N entries instead of one, and rotation is N operations instead of one.
Uneven reputation. The addresses in a list did not arrive with equal history. Some are clean on your target, some were burned by a previous customer on a target that shares an anti-abuse vendor with yours. You will discover which is which empirically, per target, and the answer decays.
Subnet clustering. Lists are frequently allocated in contiguous blocks. A target that blocks by /24 rather than by /32 takes out a large slice of your list in one action, and if you did not check the distribution before you bought, you find out during an incident. Count distinct /24s in the list, not distinct addresses.
A rotation scheduler. Round-robin is the naive answer and it is wrong for anything stateful, because request N+1 of a session lands on a different address than request N. So you write session affinity, then a cooldown per address per target, then a backoff, then a way to drain an address you are retiring without dropping in-flight work. That is a real subsystem. It needs tests, and it needs an on-call owner.
One hostname. Behavior selected by which port you connect to and by parameters encoded in the username.
# Rotating, HTTP/HTTPS
curl -x "http://login:[email protected]:823" https://api.ipify.org/
# Rotating, SOCKS5
curl -x "socks5h://login:[email protected]:824" https://api.ipify.org/
# Sticky — any port in 10000-20000
curl -x "http://login:[email protected]:10000" https://api.ipify.org/
The whole configuration surface is visible in those three lines. Rotation is the port. Session identity is the port. Protocol is the port. Geography, ASN and pool type are parameters in the username. There is nothing else to hold in memory, and nothing to redeploy when capacity changes.
Note the h on the SOCKS5 line. Without it your client resolves hostnames
locally and hands the gateway an IP, which leaks every hostname to your own
resolver and steers you to the CDN edge nearest you rather than nearest your
exit — see socks5 against
socks5h.
You stop managing addresses. No health checks, no retirement policy, no per-address credentials, no scheduler. Capacity is a property of the endpoint rather than a list you maintain, so scaling up is sending more requests and scaling down is sending fewer.
You also stop seeing addresses, and that changes how you debug.
On a list, a failure has an obvious first question: which address, and is it dead? On a gateway you do not choose the exit, so that question is unavailable. You debug by shape instead of by address. Log the exit address you observed with every request — echo it once per session and attach it to your records — and your failure analysis becomes distributional: this ASN fails more than that one, this country degrades at this hour, these two exits appeared 40 times each in an hour when the rest appeared twice.
Build that instrumentation on day one. Without it, a gateway is a black box and every incident becomes a support ticket. With it, a gateway gives you better data than a list does, because you are measuring the population rather than the sample you happened to buy.
The second thing a gateway hides is composition. You cannot enumerate the exits, so you cannot audit them directly. What you can do is measure the ones you actually receive, which is the section on pool size below.
The models bill differently because they sell different things. A list sells capacity reserved for you, so it bills by the reservation: per IP, per month, whether or not you use it. A gateway sells traffic through shared capacity, so it bills by the traffic.
The break-even is a single division. Let:
P = price per IP per month on the listG = price per gigabyte on the gatewayT = gigabytes per month you push through one addressA list is cheaper for that address when T × G > P, which rearranges to:
T* = P / G
Above T* gigabytes per address per month, the list wins on headline price.
Below it, the gateway wins. That is the whole comparison, and writing it as a
formula rather than a table means it survives the next price change on either
side.
AnonEdge's per-gigabyte rates as of 2026-08-06 are $0.99 for datacenter, $1.99 for residential and $3.99 for mobile; the current numbers are on the pricing section. Substituting a list price you have actually been quoted:
List price per IP/month (P) |
Break-even at $0.99/GB | at $1.99/GB | at $3.99/GB |
|---|---|---|---|
| $1.00 | 1.01 GB | 0.50 GB | 0.25 GB |
| $2.00 | 2.02 GB | 1.01 GB | 0.50 GB |
| $5.00 | 5.05 GB | 2.51 GB | 1.25 GB |
| $10.00 | 10.10 GB | 5.03 GB | 2.51 GB |
Read a cell as: if each address on your list carries more than this many gigabytes per month, the list is cheaper per gigabyte at that rate.
Three corrections that the headline arithmetic omits, all of which move the break-even in the list's disfavor.
Utilization. You do not use every address every month. If a fraction u of
the list carries meaningful traffic, your effective per-IP cost is P / u. A
500-address list where 300 addresses do the work is a 1.67× multiplier on P
before you compare anything.
Dead capacity. Addresses that stopped working are still on the invoice
until renewal. Subtract them from u, not from P.
Peak-shaped demand. A list is sized for your peak and paid for at that size every month. A per-gigabyte gateway is paid for at your actual volume. If your load is a weekly burst, you are paying the peak price for the troughs. This is usually the largest term and it never appears in a price comparison.
Against that, one correction in the list's favor: per-gigabyte billing counts
bytes you did not intend to fetch — images, fonts, analytics beacons, retries
after a failure. What per-GB billing actually
counts is a
separate question worth answering before you model anything, because a
30% overhead on G moves every cell in that table.
Run the formula with your own numbers. Do not run it with the vendor's.
A fixed identity is the product. Account management, long-lived logins, anything where a target has learned to expect one address from you. A gateway's sticky window is a binding, not a lease — it holds for a period and it is best-effort. If your requirement is "this account always egresses from this address, for months," buy the address.
Whitelist-only environments. Some targets allowlist your addresses. That requires you to be able to tell them what your addresses are, permanently, which a rotating gateway by definition cannot. The mirror-image constraint — authenticating to a proxy by address rather than by credential — is covered in IP whitelisting against username and password auth.
Very high, very steady utilization on few geographies. The formula above, read from the top. If ten addresses in one country each carry tens of gigabytes every month, month after month, the reservation model is priced for you.
You want the address list itself. For compliance, for audit, for a customer contract that requires you to disclose egress. A list is enumerable. A gateway is not.
Variable load. Nothing to size, nothing to cancel, no renewal date to manage against a forecast you do not have.
Many geographies. 195 countries and regions from one endpoint, selected per request. Buying equivalent coverage as a list means buying addresses in every country you might need and paying for all of them every month, including the ones you touch twice a year.
Sessions created on demand. Sticky ports in the 10000–20000 range allocate a session slot per port — two workers on port 10000 share an exit, a worker on 10001 gets a different one. You allocate ports rather than negotiating tokens. Sessions on a single endpoint is the reference, and rotating against sticky covers the trade in full.
Capacity that does not expire. Traffic is purchased per gigabyte and does not expire, there is no contract, no minimum commitment, and you can cancel at any time. A month where you run nothing costs nothing, which is the exact opposite of a per-IP reservation. AnonEdge also publishes a 7-day money-back guarantee on all plans.
One thing to configure. The gateway model's most underrated property: your proxy configuration is a hostname and a credential, and it is the same in development, in CI, and in production.
Every provider in this category publishes a headline pool number. None of them publishes a measurement method.
Think about what the number would have to mean to be comparable. Unique addresses seen in the last 24 hours, or the last 30 days, or ever? Addresses currently online, or addresses in the registry? Counted per address, or per address per country, so that a single dual-homed device counts twice? Including addresses that are online but never selected for a customer request? Including the upstream networks a provider resells, which may also be counted by the provider they resell from?
Each of those choices moves the answer by an order of magnitude, and none of them is disclosed. A number that can vary tenfold on definitional grounds alone is not a specification. It is a marketing unit.
This is structural, not an accusation about any particular vendor. The category has no shared definition, no independent audit, and no mechanism by which a buyer could check. Numbers on the same vendor's own pages routinely disagree, which tells you what kind of number it is. Do not use it as a purchase criterion, from anyone, including us.
Contrast a country count, which survives the same test. Ask for the list, pick ten entries, open a session in each and read the exit back. It is enumerable and it is falsifiable in an afternoon. A pool count is neither, and the difference is not a matter of degree.
Measure what you will actually receive instead. The metric that matters is unique exits observed per hour on your own targeting profile — because it is scoped to the geography, pool and ASN filters you will really use, and because you can compute it yourself.
#!/usr/bin/env bash
# unique-exits.sh — count distinct exits on YOUR targeting profile.
# Substitute your own credential, including any targeting parameters.
CRED="login:password"
PORT=823
N=${1:-500}
for i in $(seq 1 "$N"); do
curl -s --max-time 10 \
-x "http://${CRED}@gw.anonedge.com:${PORT}" \
https://api.ipify.org/
echo
done | sort > /tmp/exits.txt
echo "requests: $(wc -l < /tmp/exits.txt)"
echo "unique exits: $(sort -u /tmp/exits.txt | wc -l)"
echo "unique /24s: $(cut -d. -f1-3 /tmp/exits.txt | sort -u | wc -l)"
echo
echo "top repeats:"
uniq -c /tmp/exits.txt | sort -rn | head -10
Four numbers come out of that, and all four beat a headline figure.
Unique exits per N requests tells you the churn you will actually get. Unique /24s tells you how concentrated it is, which is what a subnet-blocking target cares about. Repeat rate tells you how quickly you come back to an address, which is what a rate-limiting target cares about. And the shape over time — run it hourly for a day — tells you whether the pool is deep at 03:00 in your target country or only at 20:00.
Run the same script against every provider you are evaluating, with the same targeting profile and the same request count, on the same day. That is a comparison. A pair of headline numbers is not.
One honest caveat: this measures the intersection of the pool and your filters, which is exactly the thing you are buying and exactly not the thing the headline number describes. Narrow the targeting and the number drops, correctly. That is the metric working.
What to ask a provider about its pool covers the sourcing and disclosure questions that sit alongside the measurement.
A gateway hostname resolves to infrastructure that changes. Addresses behind
gw.anonedge.com can be added, retired or moved, and the documentation is
direct about it: connect by hostname, because direct IPs change and pinning one
means maintaining it (connecting to the
gateway).
Pinning an IP is how you get a silent outage. It works, for weeks, until the address behind it is retired and your jobs start failing with a connection error that looks like a network problem on your side. Nothing in your configuration changed, which is what makes it slow to diagnose.
Concretely: no IP literals in proxy URLs, no /etc/hosts entries for the
gateway, no --resolve pins in curl, no baked-in address in an image layer.
Resolve gw.anonedge.com at connection time and let DNS do its job.
The related check is which ports you are allowed to reach through the tunnel. The default open set and the restricted set are documented at port access, and a target on a non-default port is a support request, not a configuration change.
Five changes. Most of them are deletions.
400 NO_RAY when no exit matches. See
how the pools are delivered.Two things to keep from the list era. Keep the per-target cooldown logic — a gateway rotates exits, it does not know your target's rate limit. And keep the health check, pointed at the endpoint rather than at addresses; you still want to know when the path is down.
Run both in parallel for one full duty cycle before you cancel the list. Compare success rate on the same targets, at the same volume, and only then turn off the renewal.
A single hostname and port that fronts an entire pool of exit addresses. Instead of connecting to a specific proxy, you connect to the gateway and it selects an exit for you. Behavior is chosen by which port you connect to — rotating or sticky, HTTP or SOCKS5 — and by parameters encoded in the username, such as country, ASN or session identity. One configuration entry replaces a list.
It depends entirely on gigabytes per address per month. Divide the per-IP monthly price by the per-gigabyte price to get the break-even: above that many gigabytes per address, the list is cheaper on headline price. Then adjust for the addresses you pay for and do not use, the dead ones still on the invoice, and the fact that a list is sized for your peak and billed at that size every month.
Not as a published number. There is no shared definition of what counts — unique in 24 hours or 30 days, online or registered, per address or per address per country — so two headline figures are not comparable even when both are sincere. Measure unique exits per hour on your own targeting profile instead, against every provider you are evaluating, with the same request count on the same day.
By hostname, always. The addresses behind a gateway hostname change as capacity
is added and retired, and pinning one produces an outage weeks later that looks
like a network fault because nothing in your configuration changed. Resolve the
hostname at connection time; no /etc/hosts entries, no --resolve pins, no
addresses baked into images.
Not permanently. A sticky session binds you to one exit for a window — on AnonEdge, 1 to 120 minutes, defaulting to 30 — which covers logins, carts and paginated reads behind a session. It is a best-effort binding, not a lease: if the underlying peer leaves the network the exit changes. If you need the same address for months, that is a list requirement, not a gateway one.
Nothing. Traffic is purchased per gigabyte and does not expire, there is no contract and no minimum commitment, and you can cancel at any time. A month with no jobs costs nothing. That is the structural difference from a per-IP reservation, which bills at your peak size whether or not you send a request.
Pick the model that matches your load shape, not the one with the bigger number on the homepage. If your addresses each carry a lot of traffic every month and your geography is fixed, buy addresses. If your load is variable, your geographies are many, or you would rather not own a rotation scheduler, buy traffic.
Start routing on gw.anonedge.com:823, run the
exit-measurement script above on your own targeting profile in the first hour,
and check the per-GB rates against your
break-even.