Routing

When a request arrives, ProxySave runs through this process:

1. Collect candidates. All configured providers (your BYOK keys + managed pool) are considered.
2. Apply constraints. Providers exceeding your max-price-per-gb are eliminated. Providers with historical latency above your max-time-ms for this label are deprioritized.
3. Rank by cost. Remaining providers are sorted by effective cost per GB, cheapest first.
4. Route. The request is sent to the cheapest qualifying provider.

Not all proxy traffic is the same. Scraping product pages on Amazon has different provider performance characteristics than monitoring airline prices. ProxySave learns these differences.

When you tag requests with a label header, ProxySave tracks per-label metrics for each provider:

• Success rate (percentage of requests that return a valid response)
• Median response time
• P95 response time
• Block rate (how often the target blocks this provider)

Over time, routing decisions become more accurate for your specific workload. A provider that's cheap but frequently blocked on your target will be automatically deprioritized, even if it meets your stated constraints.

When a provider fails (network error, timeout, blocked response), ProxySave automatically retries through the next cheapest qualifying provider. This happens transparently — your application receives a single response.

The retry chain works like this:

1. Request sent to cheapest provider (e.g., NetNut at $1.80/GB)
2. If it fails, retry through next cheapest (e.g., IPRoyal at $2.90/GB)
3. Continue until a provider succeeds or all candidates are exhausted
4. If all providers fail, return ALL_PROVIDERS_FAILED with the last error

The X-ProxySave-Retries response header tells you how many retries occurred. A value of 0 means the first provider succeeded.

The retry mechanism creates an implicit fallback chain ordered by cost. But you can also force a specific provider while still benefiting from automatic fallback:

ProxySave occasionally routes a small percentage of requests (<2%) through providers that aren't the current cheapest winner. This exploration ensures the router discovers when a provider improves its pricing or performance for your workload.

Exploration only happens within your stated constraints — ProxySave never sends an exploration request to a provider that exceeds your max cost or latency limits. And exploration requests still benefit from retry logic, so they don't reduce your effective success rate.