Routing strategies

After targeting filters the fleet, a strategy chooses one edge from the eligible set. Set it with strategy-<name> in the username or the X-Proxy-Strategy header. If you don’t set one, requests use the default, goodput_per_second.

The strategies

Strategy	What it does
`goodput_per_second`	The default. Weights each edge by the pages it delivers per second of slot time against this site: its success rate divided by its latency. Fast, reliable edges take most of the traffic; slow ones keep a small share.
`goodput_weighted`	Weights each edge by its success rate against this site (pages per request), without regard to speed.
`round_robin`	Even rotation across eligible edges.
`weighted_round_robin`	Round-robin biased by each edge’s weight. Every edge currently has weight 1, so today it behaves like `round_robin`.
`least_connections`	Sends to the edge with the fewest in-flight requests, for natural load levelling.
`lowest_latency`	Picks the edge with the best recently-measured latency.
`random`	Uniform random pick. The cheapest selection.
`ip_hash`	Hashes the client IP to a stable edge, so it’s sticky without session state. This works for plain-HTTP requests; over HTTPS the proxy doesn’t see the client IP, so every client maps to the same edge.
`session_affinity`	Pins a `session` id to one edge (see Sessions).
`freshest_ip`	Uses the least-recently-used edge for this (org, host), giving maximum IP variability.
`ip_rotation`	Rotates through the pool by picking the least-used edge, scoped per (org, target host).
`cost_aware`	Favours edges with a higher weight (cheaper, preferred egress), balanced against how many connections each already has. With every edge at weight 1 today, it behaves like `least_connections`.

Why the default is pages per second

Round-robin splits traffic by candidate count, so an edge that converts 43% of requests gets the same share as one that converts 87%. Weighting by success rate alone fixes that and fails the other way: it can’t see how long a request holds a slot, so a slow but accurate edge ends up with too many of them. Scoring pages per second of slot time weighs both.

Variability strategies are scoped per (org, host)

freshest_ip and ip_rotation track usage per (org, target host), not globally. That means:

Your traffic to site-a.com rotates independently of your traffic to site-b.com.
A request to a new host starts a fresh rotation, so the first hit to a new target is deterministic, not “wherever the global counter happens to be.”
Two different orgs never perturb each other’s rotation.

# spread requests to one host across as many distinct edges as possible
-U "YOUR_API_KEY-strategy-freshest_ip:"

Choosing a strategy

Just get it done? Leave it unset: goodput_per_second sends traffic where pages come back fastest.
Scraping a single site hard? freshest_ip or ip_rotation to spread load across IPs and avoid per-IP rate limits.
Latency-sensitive? lowest_latency (backed by continuously-measured per-edge latency).
Multi-step / logged-in flows? session_affinity to stay on the same edge.
Cost-sensitive bulk? cost_aware to lean on higher-weight, cheaper edges.