What a Static IP Actually Gets You, and What It Does Not

Strip away the marketing and a static address is a persistent identifier. The remote server writes your address into its logs, its rate limiter, its session table, its fraud model and its firewall rules, and tomorrow it reads the same value back.

Persistence is neutral. It helps when the remote side is trying to recognise you, and it hurts when the remote side is trying to catch you. That single sentence decides almost every static versus rotating purchase, and it is why the honest answer to "are static proxies better?" is a question about who benefits from being recognised.

Three things follow, and none of them appear on a pricing page:

• Static is an identity commitment, not a quality upgrade. A fixed address is neither faster nor cleaner than a pooled one. It is simply attributable.
• You inherit the address's past. Whatever the previous holder did from that address is now part of your history on every site that keeps a record, and you will never be told what that was.
• The premium is priced per address, so your bill scales with the number of identities you hold rather than with how much traffic you push. If your workload is traffic-heavy and identity-light, static pricing is the wrong shape for it.

Support queues are full of people who bought one of these and wanted a different one. They are four independent properties, and a product can carry any combination of them.

Static

The address does not change over time. That is the whole definition. It says nothing about who else uses the address, which network it sits in, or how long your session lasts.

Sticky

The same address is held for the duration of a session, then released back to a pool. A sticky session is a time-boxed lease, not ownership. SparkProxy exposes this on port 11002 of gateway.sparkproxy.io while port 11000 rotates per request, and the proxy plans also apply a 5 minute auto rotation. Sticky is the right tool for a multi-step checkout or a paginated crawl that must look like one visitor. It is the wrong tool for an account you will log back into next week.

Dedicated

Nobody else is issued the same address. Dedication is about exclusivity, not permanence, although in practice most dedicated products are also static. The distinction matters when you are diagnosing a block: a shared address can be poisoned by a stranger, a dedicated one can only be poisoned by you. Our breakdown of shared vs dedicated datacenter proxies covers where that line falls.

Residential or ISP

This is about which organisation the address is registered to, not about how it behaves. An address inside a consumer ISP's allocation looks like a household to any system that scores networks. That property is what people are usually buying when they say "static residential", and it is a separate purchase from staticness. Our explainer on ISP proxies covers the product that bundles the two together.

Say all four out loud before you buy: do you need permanence, session continuity, exclusivity, or a consumer registration? Most buyers who ask for "static residential" need two of the four and are paying for all four.

A fixed address is available from at least five places at wildly different prices, and the differences that matter are the registered network and the billing shape rather than the staticness itself.

Two observations from that table. First, the cheapest static address for a firewall allowlist is usually a reserved address on a cloud instance you already run, not a proxy at all. Second, the expensive tier is expensive because of the ISP registration, not because of the persistence. If your target does not score networks, you are paying for a property that changes nothing about your results.

Vendors publish these in different units and the rates move, so price the shape rather than the headline: per address per month for identity products, per gigabyte or per thread for traffic products. Check the current rate on the vendor's own page before you commit, and read our note on what private proxy means across providers, because none of these labels are standardised across the market.

These are the cases where a fixed address does real work and no amount of clever rotation substitutes for it.

Sessions the remote side pins to an address. Plenty of platforms bind a session cookie to the address that created it, or trigger re-verification when the address behind a logged-in session changes. Rotation breaks those outright. A sticky session postpones the break, it does not prevent it, because the lease ends.

Allowlists. Any time a partner, a bank API, a database or a corporate firewall says "send us the address you will call from", you need permanence. There is no workaround and no rotation strategy that helps.

Licences and seats bound to an address. Some data vendors and enterprise tools authenticate by source address rather than by key. Same situation as an allowlist, same answer.

Slowly built account history. An account that has logged in from the same address for eight months is a different object to a fraud model than one that has logged in from eight countries this week. This is the one case where the value of static compounds over time, and it is also the case where switching vendors is most painful, because the history does not move with you.

Geo consistency that must not wobble. If a session has to present as the same city every time, a fixed address is simpler to reason about than a pool with city targeting, because a pool can legitimately hand you a neighbouring metro and the target may treat the jump as a signal.

The first row is the expensive one. A team gets challenged on a scraping target, reads that residential and ISP addresses look more trustworthy, buys forty static addresses, enjoys a clean week and then ends up in a worse position than it started from. The reason is in the next section.

A rotating pool spreads damage. If one address out of a million gets flagged for hammering a site, the pool absorbs it and your next request comes from somewhere else. That is not a loophole, it is the mechanical reason rotation exists as a product.

A static address concentrates damage. Every request you have ever sent from it is attributable, and the target's counters never reset because the address never changes. Run an aggressive crawl from a fixed address and you are not diversifying, you are compiling a case file. Sites that score addresses rather than sessions will eventually put yours in a bucket you cannot leave, and because you bought the address for its permanence, you cannot rotate out of the problem either.

Two practical consequences.

Never mix jobs on one static address. The address that holds your logged-in account should never be used for bulk collection. One noisy afternoon costs you the account history you spent months building. Separate credentials, separate addresses, separate egress paths, and enforce it in configuration rather than in a wiki page.

Ask what the address did before you got it. Static addresses get recycled. An address that spent last year in a heavily used rotating pool arrives pre-burned on exactly the sites that matter most to you. Most vendors will not answer this question directly, so check it yourself: query the address against a reputation and fraud score service before you build anything on it, then again 30 days in. Our guide to validating IP geolocation accuracy and fraud scores walks through the checks, and what IP reputation is and why it matters explains what those scores are built from.

The numbers below are a model, not a measurement, and the per address rate is a placeholder you should replace with the quote in front of you. What matters is the shape of the answer, which does not change much when you swap the inputs.

Workload A: 25 seller accounts on a marketplace that pins sessions to the address.

The static requirement here is real. You need 25 addresses that do not change, one per account, plus one browser profile per account. At an illustrative $3.00 per address per month, that is $75 a month for the addresses alone. Rotation cannot do this job at any price, so the comparison is not cheaper against dearer, it is works against does not work. What you should still test is whether the platform scores hosting networks at all. If it does not, a dedicated datacenter address does the same job as an ISP address and the ISP premium buys you nothing.

Workload B: 500,000 public product pages a month.

Assume the target starts challenging an address at roughly 300 requests a day. Measure this on your own target, because it is the single input that decides everything below.

• 500,000 requests over 30 days is 16,667 requests a day.
• 16,667 divided by 300 requests per address per day is 55.6, so 56 addresses.
• At the same illustrative $3.00 per address, that is $168 a month, and every one of those addresses is a fixed target. If the site tightens to 150 requests a day, you need 112 addresses and the bill becomes $336.

Now price the same job on rotation. SparkProxy Starter is $75 a month for 100 concurrent threads with unlimited bandwidth against a pool of 1M+ datacenter addresses across 80+ countries, with random rotation per request and 30 day plan validity. Check that concurrency is not the constraint: pushing 16,667 requests inside a four hour nightly window is 16,667 divided by 14,400 seconds, or about 1.16 requests a second. At two seconds per request, that needs roughly three threads in flight. One hundred threads is nowhere near the limit, so the binding constraint is the target's tolerance rather than the plan.

Workload B therefore costs $75 rotating against $168 static at the assumed rate, and the static version degrades when the target tightens while the rotating version does not. Workload A cannot be done on rotation at all. Same buyer, same month, two opposite answers, which is precisely why "is static better" has no answer.

If your monthly volume sits far below 500,000, neither shape is obviously right and the plan floor becomes the deciding factor. Our breakdown of how much proxies cost covers where the floors sit.

Here is the static address question almost nobody asks, and it bites teams in the week they move a scraper into a container.

Most proxy vendors offer two authentication methods: a username and password, or an address whitelist. Whitelist authentication is convenient and keeps credentials out of code, and SparkProxy plans ship a fixed number of slots for it, 5 on Starter, 10 on Core, 15 on Boost and 25 on Plus. Every one of those slots assumes the same thing, that your egress address is static.

Very often it is not. A scraper on a cloud runner, a serverless function, a CI job or a laptop on hotel wifi presents a different source address on every run. The failure looks like a proxy outage, returns an authentication error rather than a routing error, and sends people to the wrong vendor's support queue. Three fixes, in order of preference:

1. Use username and password authentication and skip the problem entirely. This is the right default for anything running in a container or a scheduler.
2. Route your workers through a NAT gateway or one small always-on instance with a reserved address, then whitelist that single address. You now own exactly one static address, which is the cheapest correct amount.
3. Automate the whitelist through your vendor's dashboard or API on every deploy. This works, and it adds a failure mode to your pipeline that you now have to monitor.

The wider point holds beyond proxies. Whenever a system authenticates you by address, the static address you need is on your side of the connection, and it is usually far cheaper to buy than the ones on the exit side. Our notes on how proxy authentication works and IP whitelisting for proxies cover the mechanics.

Run these against your actual target. They take an afternoon and they settle the question better than any comparison table, including the ones above.

Test 1: is anything bound to the address? Log in and capture the session. Replay the authenticated request from a second address. If you get re-verification, a logout or a challenge, the session is address-bound and you need permanence. If it sails through, you do not, and rotation is back on the table.

Test 2: does the target score the network? Fetch the same URL twice, once through a hosting network and once through a consumer ISP allocation, with identical headers and TLS settings. Compare status codes and body length, not just status, because soft blocks return 200 with a stripped page. If both succeed, you do not need the ISP premium and a dedicated datacenter address will do. Our piece on what a datacenter ASN is explains what the target is looking up when it makes that decision.

Test 3: how many requests before it complains? Run one address at a steady, unhurried rate and record where the first challenge lands. That number divided into your daily request count is the number of static addresses a fixed-address design would need, and it converts a vague "static feels safer" into a budget line. Re-measure monthly, because it moves.

Test 4: is your own egress static? Print your source address from the machine that will run the job, on three separate runs, at least an hour apart. If it changes, choose credential authentication now rather than after the first 407 at three in the morning.

Two of those four tests usually come back saying you need one or two fixed addresses for the identity-bound parts of the job and a rotating pool for the bulk. That is a hybrid rather than a purchase decision, it is the normal answer, and it costs less than either pure design.