News

Introducing the New Shifter Residential Proxies

A new gateway model with improved speed, 205M+ residential IPs, bandwidth-based pricing, and precision targeting by country, region, city, and ASN.

James Meadow

James Meadow

May 18, 2026 · 6 min read

Today we’re shipping the next generation of Shifter Residential Proxies. It’s the biggest change to the product since we launched the original residential gateway, and it consolidates a year of customer feedback into three things that we think materially improve the experience of running production proxy traffic at scale.

If you’re in a hurry: it’s one endpoint, you pay per GB, you can target by country, region, city, or ASN on every plan with no upcharge, and the pool jumped from 31M+ to 205M+ residential IPs across 195+ countries. Speed is up across the board.

The rest of this post walks through what changed, why, and what existing customers need to know.

What’s new, in one screen

One unified gateway. A single endpoint, p.shifter.io:443. Every request, every country, every session, same host, same port. Targeting hints get encoded into the username string at request time, no plan-specific subdomains or per-port allocations to manage.

Bandwidth-based pricing across the board. You pay for the data you actually move. No ports, no per-request charges, no concurrency caps. Plans start at $1.00/GB at scale; the pricing page has the full ladder.

City and ASN targeting on every plan. What used to be an enterprise feature is now included with every plan, with no surcharge. You can route through any city we have coverage in (most of them, see Locations) or constrain to a specific ASN, by appending one query-style flag to your username.

These three changes are tightly coupled in our heads, they’re the result of one architectural rethink, not three independent product decisions. But the buyer-side experience is what changed: a simpler endpoint, a simpler invoice, and more precision than most teams expected to have at the price point.

Why one gateway

The original residential product, when we launched it years ago, used port-based plans. Buy 100 ports, get 50 concurrent connections on each, each with its own host:port pair. It was a defensible model for the time and it served us, and the customers building serious infrastructure on top of it, well for years.

Two things changed that made the port model the wrong primitive:

Pools got large enough that concurrency stopped being the constraint. When you have 205M IPs in the pool, the question “can the network handle 5,000 concurrent connections” stopped being interesting. The answer is yes. The interesting questions are about which IPs, in which geographies, with what session behavior, questions that ports didn’t help you answer.

Workloads got more dynamic. A modern data pipeline doesn’t run 100 steady-state scrapers for a month. It runs bursty fan-outs triggered by webhooks or schedules, with concurrency ranging from 1 to 1,000 over hours. Static port allocations either under-served those bursts or over-charged for idle capacity.

The unified gateway answers both. One endpoint, parsed-at-the-edge targeting, no concurrency cap. Allocate IPs from the right pool at request time, route, return. The customer’s mental model gets simpler: one URL, one auth, one credential set, one bill.

Why bandwidth pricing

This part of the change is the most consequential and the easiest to explain. Bandwidth is what you actually consume. Ports were a proxy (different sense of the word) for bandwidth, concurrency × throughput. Bandwidth is the underlying physical resource. Pricing on the underlying resource means the bill matches reality.

Concretely, on the new pricing:

  • You buy a bandwidth allocation, e.g. 100 GB/month at our middle tier.
  • You can use it however you want, 1 request that streams a 100GB file or 100 million requests that each fetch a 1KB API response.
  • Unlimited concurrency, unlimited request rate, no port limits.
  • Overage rolls onto pay-as-you-go pricing from your wallet, no plan upgrade required mid-month.

For most teams, this dramatically changes how usage forecasting works. “How much data are we going to move next month” is a question you can answer with a back-of-envelope calculation. “How many ports do we need” was a question you could only answer empirically after running the workload for a few weeks.

If you’ve been on a port plan and you’re considering moving, the support team can pull your usage history and walk you through what the equivalent bandwidth plan would look like. Reach out at hi@shifter.io and we’ll run the numbers together.

Why city and ASN targeting everywhere

Country-level targeting solves a small problem. City- and ASN-level targeting solve a much bigger one for the workloads that actually pay our bills.

A team monitoring e-commerce prices across US metros needs city precision, Amazon’s prices in New York, LA, Chicago, Houston, and Miami are five different prices, and a country-level proxy returns one of them with no way to know which. A team verifying ad placements needs to confirm the ad served in San Francisco actually contains the San Francisco creative. A team scraping food delivery needs to fetch each DoorDash market separately.

What used to be a feature gated behind enterprise contracts is now in every plan. The reason is simple: it costs us no more to route a request through a specific city IP than a country IP. The customer-side gate was a billing decision, not a technical one. We removed the gate.

Same with ASN targeting. If you need a specific ISP, Comcast (AS7922), Verizon (AS701), BT (AS2856), append -asn-<number> to the username and that’s where your traffic routes. No upcharge, no extra plan.

The full geo flag set:

customer-USERNAME-country-us # country
customer-USERNAME-country-us-region-california # state/region
customer-USERNAME-country-us-city-new_york # city
customer-USERNAME-country-us-asn-7922 # ASN (Comcast)
customer-USERNAME-country-us-strict-true # fail if no exact match

Combine any of them. country + city, country + asn, all four together. The gateway parses and routes.

What existing customers need to do

If you’re on an original port-based plan, your plan and your existing port-based credentials continue to work. The new gateway uses a different pricing model (bandwidth instead of ports). There’s no fee to switch, and we have discounts available for existing customers. Contact support and we’ll work out the right migration plan and price for your usage.

If you’re a new customer: just sign up. The new gateway is the default. Pricing is on the Residential Proxies pricing page and the full docs are at /docs/products/residential-proxies.

What’s next

This launch is the visible piece of about a year of work. The less-visible piece is the operational side, better observability into per-request behavior, better dashboards for bandwidth and session metrics, better SDKs across more languages. Some of that has shipped already; more is queued. We’ll write about the interesting parts as they land.

In the meantime, the new Residential Proxies are live. Pricing, docs, and signup are all linked above. If you’ve been waiting for the price of city-level precision to come down, it just did. If you’ve been waiting for ports to die, they didn’t, but you no longer have to think about them. And if you’re starting from zero today, welcome. Our team is on chat at hi@shifter.io if you get stuck.

Tags: residential proxies product launch gateway bandwidth pricing geo-targeting

Ready to get started?

Try Shifter's residential proxies, 205M+ IPs, 195+ countries, from $1.00/GB.

Get Started