The architecture of our streaming-clean exits

A while back we published a troubleshooting guide for users hitting "VPN detected" walls on streaming services. That post was for the user side. This one is for the engineering side — what actually happens behind a streaming-clean exit, why it is more expensive than people assume, and what we do and do not promise.

Why a residential IP costs us 3-5x a datacenter IP

A /29 in a Tier III datacenter in Frankfurt costs us, roughly, the price of a nice dinner per month per IP, amortized across the rack and transit. A residential IP allocation — by which we mean a real ISP-issued, eyeball-network IP that resolves to a consumer geolocation block — costs us three to five times that, depending on the region. In Sydney and Tokyo it is closer to five.

The reason is that residential IPs are scarce as a legitimate, contracted resource. Most providers in the streaming-VPN space get them through what we will politely call "supply chains we do not endorse" — typically SDKs embedded in free apps that turn a stranger's home router into a proxy. We do not do this. We will not do this. More on that below.

Our residential capacity comes from a small number of ISP partnerships in markets where we have a legal entity or a contracted reseller, plus some hybrid allocations where we pay an upstream for static "consumer-classified" blocks. It is expensive. We pass roughly half of that cost into our pricing and absorb the rest on the assumption that streaming-capable exits are a retention driver.

The three-tier exit pool

Every regional pop has up to three classes of exit IP, and routing decisions happen per-flow.

• Tier 1 — Datacenter. The bulk of our capacity. Cheap, fast, abundant. Fine for general browsing, perfect for low-latency work, recognized as a VPN by most streaming services.
• Tier 2 — Hybrid. IPs that are technically datacenter-allocated but in blocks that streaming services have not yet flagged, often because the ASN is a regional eyeball provider that also happens to host some servers. Mid-priced, mid-success-rate.
• Tier 3 — Residential. The expensive stuff. ISP-classified blocks that look like a home connection. Highest streaming success rate. Limited capacity.

When a user opens a connection, we make a routing decision based on the SNI — the hostname the client is connecting to in the TLS handshake. Note: SNI inspection is not deep packet inspection. We see the destination hostname, which is already public on the wire. We do not see the contents of the TLS session, we do not log destinations beyond a short-lived in-memory counter for the burn detector, and we do not store anything across the boot of the node.

If the SNI is a known streaming destination, we route the flow through Tier 3 — if Tier 3 has capacity in that region. If not, Tier 2. If not, Tier 1 with a one-line warning to the user that they are on a datacenter exit and may hit a wall.

IP rotation cadence in our top streaming cities

Rotation is the second pillar. Even a clean residential block goes stale eventually — streaming services share intelligence, members hammer the same IP, and a block that worked last week starts hitting walls this week.

In our five highest-demand streaming cities — New York, Los Angeles, London, Tokyo, and Sydney — we rotate the active Tier 3 IP set every 24 hours. A block sits in active rotation for a day, then goes into a 14-day quiet period where it is unused. Quiet periods let reputational signals decay. After 14 days it returns to the warm pool.

In our other 26 cities, rotation is every 72 hours, because the demand pressure on any given IP is lower and we can afford a slower cycle.

The burn detector

No matter how careful the rotation schedule is, individual IPs occasionally get burned faster than the schedule expects — a single member hits a particular service at high volume, the IP gets flagged, and now everyone routed through it gets walled.

We run an internal service we call the burn detector. It watches outbound HTTP status codes — specifically the rate of 4xx and 5xx responses on flows tagged as streaming-destination. It does not see content; it sees status codes and SNI hostnames, in memory only. If the 4xx/5xx rate on a given exit IP, for a given destination ASN, crosses a threshold relative to the regional baseline, the IP is rotated out within hours rather than waiting for the scheduled cycle.

Why we will never use botnet-residential services

There is a class of "residential proxy" providers in this market whose IP supply comes from SDKs embedded in free Android apps and browser extensions. The user installs a free flashlight app or a coupon extension. Buried in the EULA is permission to use their home connection as a proxy. They are not really aware. Their bandwidth gets sold to a VPN provider downstream. Their IP shows up doing things they did not do.

We will not buy this. Not because of cost — it is actually cheaper than legitimate residential — but because every IP in that pool has a victim attached to it. Someone whose household network is being used as a proxy for a stranger, with whatever legal exposure that implies. A VPN that protects its members by transferring legal exposure to an unsuspecting third party is not a privacy product. It is a bag-holder relocation service.

This is one of the lines we will not cross even if it costs us competitively. It does cost us competitively. We are slower in some regions because of it. We accept that.

The honest 90% target

We target a 90% streaming-success rate in our five top streaming cities, measured as: of all connection attempts to a major streaming destination from a Tier 3 exit, 90% successfully complete the initial playback handshake. We hit this most weeks. We miss it some weeks, particularly when a streaming service rolls out a new detection model.

We do not promise 100%. Anyone who promises 100% is either lying or running a botnet pool. Streaming detection is an arms race we did not start and do not control. Our job is to be on the right side of the trend most of the time. 90% is the honest number.

What we are still not good at

• Live sports. Geo-restricted live events have aggressive, real-time detection that is harder than catalog streaming. Our success rate on live is closer to 70%.
• Mid-tier cities. Our streaming-clean capacity outside the top five is thinner. Singapore and Toronto are about 80%. Mumbai is closer to 65% and we are working on it.
• Mobile carrier-grade NAT regions. When a user is on a mobile network with carrier-grade NAT, our routing logic occasionally picks a suboptimal exit. We have a fix in flight.

If you are a member, the practical advice is: pick the closest top-five city, prefer the streaming-tagged exit if your client offers it, and if a destination walls you, rotate manually — the next IP from the warm pool is usually clean. We will keep the architecture honest, and we will keep the success rate where we said it would be.