DEV Community: Sota Support

WebSocket Connections Through Proxies: What Is Different From Regular HTTP Requests

Sota Support — Tue, 11 Aug 2026 17:35:29 +0000

Everything about proxy rotation assumes a request-response model by default — get a response, decide whether to rotate, move on. WebSockets break that assumption structurally, and treating them like regular HTTP traffic is where most proxy + WebSocket integrations go wrong.

The fundamental difference: one long-lived connection, not many short ones

This changes what "rotation" even means: there is no natural per-message rotation point the way there is with per-request HTTP, because rotating mid-connection means literally breaking the connection.

What this means for IP assignment

For WebSocket-based workflows, IP assignment has to happen once, at connection time, and then hold for the full lifetime of that connection. There is no equivalent of "rotate on the next request" available mid-stream.

This makes WebSocket traffic structurally closer to a sticky-session HTTP flow than to stateless rotation, even if your overall system also does high-frequency rotation for its regular HTTP traffic elsewhere.

ws_connection = connect(target, proxy=pool.get_sticky_ip())
# this proxy assignment holds for the entire connection lifetime
# rotation only happens on reconnect, not mid-session

Where proxy compatibility actually breaks

Not all proxy types handle WebSocket upgrade requests correctly. A WebSocket connection starts as an HTTP request carrying an Upgrade: websocket header, and some proxy configurations — particularly ones tuned narrowly for plain HTTP/HTTPS traffic — do not handle the upgrade handshake correctly, silently failing the connection or closing it right after the handshake instead of maintaining the long-lived connection.

Connection timeouts tuned for HTTP requests kill WebSocket connections prematurely. If your proxy or client library has a read timeout tuned for "how long should I wait for an HTTP response" (seconds), and that same timeout applies to an idle-but-legitimate WebSocket connection — which might go quiet for extended periods between messages without being dead — you will see connections drop that were never actually broken. Just idle, which a request-response timeout model misinterprets as failure.

Reconnection logic needs to be IP-aware, not just retry-aware. When a WebSocket connection does drop and needs to reconnect, deciding whether to reconnect through the same IP or a fresh one depends on why it dropped. A clean server-side close is different from a proxy-side failure, and treating every reconnect as "get a fresh IP" can break session-dependent state on the target's side the same way IP rotation mid-session breaks cookie-based auth in regular HTTP flows.

Practical guidance

Treat each WebSocket connection as a single sticky-IP unit for pool-management purposes, not a stream of independently-rotatable requests
Set proxy and client timeouts specifically for long-lived idle connections, separate from your regular HTTP request timeouts
Verify your proxy type explicitly supports the WebSocket upgrade handshake before assuming it "just works" the same way it does for HTTP — this is a real compatibility gap between providers, not a given

This is one of the less-documented compatibility questions we field when SotaProxy gets used for real-time or streaming-adjacent workflows rather than plain request-response scraping. Worth checking explicitly rather than assuming a proxy setup that works fine for HTTP will behave identically for WebSocket traffic.

Handling Redirects Through Rotating Proxies: Where Things Actually Break

Sota Support — Thu, 06 Aug 2026 18:54:36 +0000

Redirects and IP rotation don't inherently conflict, but the interaction between them causes a specific, recurring class of bugs that's easy to miss until you've hit it once. Here's where it actually goes wrong.

The core issue: a redirect is a second request, and rotation doesn't know that

When your HTTP client follows a redirect automatically, it's making a brand new request to the Location header's URL. If your proxy rotation logic operates at the "one IP per request" level without any awareness that a redirect just happened, that second request can silently get a different IP than the first one — even though, from the target's perspective, this looks like one continuous navigation by one user.

Where this actually causes failures

Session or state loss mid-redirect. If the target sets a cookie on the first response and expects it back on the redirect-target request, and your client handles that fine at the HTTP layer, but the IP changed between the two requests — some targets treat that IP jump within a single navigation as suspicious, independent of whether the cookie itself was handled correctly.

Redirect loops that look like proxy failures. Some targets deliberately redirect suspected bots in a loop, often to a "verify you're human" page that itself redirects back. If your rotation logic assigns a new IP on each hop through that loop, you can burn through pool IPs rapidly on what's actually a single bot-detection response, not five independent failures — and your pool health metrics get polluted by IPs that never did anything wrong, they just got unlucky enough to be assigned during a redirect loop.

Geo-mismatch across hops. A redirect to a region-specific URL, common with e-commerce and localized content, combined with a rotation that assigns a completely different geography's IP on the second hop, can produce responses that don't make sense for either IP — the kind of subtle inconsistency that's hard to debug because each individual request "worked," just not coherently together.

The fix: treat a redirect chain as one logical request

Configure your client, or your own redirect-handling logic if you're not using automatic following, to keep the same IP for the full chain of a single redirect sequence. Only let rotation assign a new IP once that chain fully resolves — success, final failure, or you've decided to abandon it.

def fetch_with_consistent_proxy(url, max_redirects=5):
    proxy = pool.get_ip()
    for _ in range(max_redirects):
        response = request(url, proxy=proxy, allow_redirects=False)
        if response.is_redirect:
            url = response.headers['Location']
            continue          # same proxy for the next hop
        return response
    return response           # gave up, still one chain, one proxy

This is a small logic change but it closes a real gap — most off-the-shelf HTTP libraries follow redirects transparently without exposing this as something you'd even think to configure, so the bug hides well.

A related trap: relative vs absolute redirect URLs

Some targets return relative Location headers. If your redirect-handling code doesn't resolve them against the original request's base URL correctly, you can end up requesting a malformed URL entirely — which then gets misclassified as a "connection failure" in your logs when it was actually a URL-construction bug, muddying your failure-type statistics in a way that makes proxy pool quality look worse than it actually is.

This is one of the quieter integration bugs we help teams track down when building on SotaProxy — it rarely shows up in initial testing, since single requests with no redirects in the test path look fine, and only surfaces once real target behavior with redirect chains enters the picture. Worth checking your redirect-handling logic specifically if you're seeing inconsistent behavior that doesn't correlate cleanly with any single proxy.

Timeout Tuning for Proxy-Routed Requests: Why Default Values Are Almost Always Wrong

Sota Support — Wed, 05 Aug 2026 11:55:23 +0000

Most HTTP libraries ship with a default timeout somewhere between "none at all" and "way too generous," and most proxy-routed traffic inherits that default without anyone deciding it on purpose. Here's why that default is almost always the wrong number, and how to actually pick one.

Why proxy traffic needs different timeout thinking than direct traffic

A direct request to a target has one network hop's worth of latency variance. A proxy-routed request has at least two: your connection to the proxy, and the proxy's connection to the target. Residential and mobile proxies specifically add real-world network variance on top of that — you're routing through a consumer ISP connection, not a datacenter backbone, and that connection can have genuinely variable latency for reasons that have nothing to do with anything being wrong.

Treating proxy-routed latency variance the same way you'd treat direct-connection latency variance means your timeout is tuned for the wrong distribution entirely.

Too short: the failure mode nobody notices until it's expensive

An aggressive timeout (say, 3-5 seconds) tuned for direct-connection speed will treat a large fraction of genuinely successful-but-slower proxy requests as failures. This is expensive in a specific, sneaky way: you retry a request that was actually about to succeed, burning an extra request against your pool and against the target, for a "failure" that was never a real failure — just impatience.

Too generous: the failure mode that wastes resources differently

A very generous timeout (30-60+ seconds) means a genuinely dead or hanging connection ties up a worker, thread or connection slot for a long time before failing, which throttles your actual throughput far below what your pool could support — especially under concurrency, where each hung connection is blocking a slot that could be serving a request that would succeed immediately elsewhere.

A better starting point: measure your own distribution, don't guess

Before picking a number, log actual response time distribution for successful requests through your specific proxy setup, against your specific targets. Set the timeout at roughly the 95th-99th percentile of successful response times, not a round number that sounds reasonable:

successful_latencies = [collect over a real sample, e.g. 500+ requests]
timeout = percentile(successful_latencies, 97) * 1.2   # small buffer above p97

This will almost never match a "sensible-sounding" default like 10 or 30 seconds, and that's the point — the right number is specific to your proxy type, your target, and your geography, not a constant that applies everywhere.

Different timeouts for different phases of the request

A single timeout value applied to the whole request lifecycle conflates two different things worth tuning separately:

Connection timeout (how long to wait to establish the connection through the proxy): usually should be shorter and stricter — a connection that's slow to even start is a stronger signal of a genuinely bad IP than a connection that's just slow to finish.
Read timeout (how long to wait for the response body once connected): can reasonably be more generous, since a slow-but-completing response is a different situation than a connection that never even opens.

Splitting these lets you fail fast on clearly-bad connections while still tolerating legitimately slow-but-working ones.

Timeouts as a pool health signal, not just an error-handling detail

Track timeout rate per IP over time the same way you'd track ban rate. An IP with a rising timeout rate, even without outright failures, is often an early warning of degrading quality before it shows up as a hard failure — exactly the kind of signal that gets missed when timeouts are treated purely as "did the request work or not" rather than as a graded quality metric.

Getting this tuning right is a big part of what separates a scraper that runs reliably in production from one that looks fine in a quick test and then falls apart under real load — it's the kind of thing we spend real engineering time on when helping teams integrate SotaProxy into an existing pipeline. If your timeout values are still whatever the library shipped with by default, that's usually worth revisiting before anything else.

Timeout Tuning for Proxy-Routed Requests: Why Default Values Are Almost Always Wrong

Sota Support — Wed, 05 Aug 2026 11:49:48 +0000

Why proxy traffic needs different timeout thinking than direct traffic

Treating proxy-routed latency variance the same way you'd treat direct-connection latency variance means your timeout is tuned for the wrong distribution entirely.

Too short: the failure mode nobody notices until it's expensive

Too generous: the failure mode that wastes resources differently

A better starting point: measure your own distribution, don't guess

successful_latencies = [collect over a real sample, e.g. 500+ requests]
timeout = percentile(successful_latencies, 97) * 1.2   # small buffer above p97

Different timeouts for different phases of the request

A single timeout value applied to the whole request lifecycle conflates two different things worth tuning separately:

Connection timeout (how long to wait to establish the connection through the proxy): usually should be shorter and stricter — a connection that's slow to even start is a stronger signal of a genuinely bad IP than a connection that's just slow to finish.
Read timeout (how long to wait for the response body once connected): can reasonably be more generous, since a slow-but-completing response is a different situation than a connection that never even opens.

Splitting these lets you fail fast on clearly-bad connections while still tolerating legitimately slow-but-working ones.

Timeouts as a pool health signal, not just an error-handling detail

Track timeout rate per IP over time the same way you'd track ban rate. An IP with a rising timeout rate — even without outright failures — is often an early warning of degrading quality before it shows up as a hard failure. This is exactly the kind of signal that gets missed when timeouts are treated purely as "did the request work or not" rather than as a graded quality metric.

Migrating Between Proxy Providers Without Downtime

Sota Support — Tue, 04 Aug 2026 12:34:38 +0000

Originally published on the SotaProxy blog.

Switching proxy providers is one of those tasks that looks like a config change and turns out to be a migration. Here's how to do it without a gap in coverage, and what breaks if you treat it as a flag flip.

Why the naive cutover fails

The obvious approach — change the endpoint, redeploy, done — has two problems that only show up in production.

First, the new pool has no history with your targets. Even a genuinely high-quality pool starts cold: no accumulated reputation, no evidence of normal behavior from those IPs against those specific sites. A hard cutover means your entire traffic volume lands on cold IPs simultaneously, which is exactly the traffic shape that triggers scrutiny.

Second, you have no baseline to compare against. If success rate drops after the switch, you can't tell whether the new provider is worse, whether you misconfigured something, or whether the target changed its defenses that week. Without overlap, you're debugging blind.

The pattern: run both, shift gradually

Keep the old provider active and route a small percentage of traffic to the new one, increasing over days.

def get_proxy(target):
    if random() < NEW_PROVIDER_SHARE:   # start at 0.05, raise gradually
        return new_pool.get(target)
    return old_pool.get(target)

The key detail is that this needs per-provider metrics, not aggregate ones. If you're only tracking overall success rate, a new pool performing badly on 5% of traffic is invisible inside normal noise. Tag every request with which provider served it and compare the two series directly.

A reasonable ramp: 5% for a day, then 15%, 30%, 50%, 100% — pausing at any step where the new provider's success rate is measurably worse than the old one on the same targets over a comparable sample.

What to compare, beyond success rate

Latency distribution, not just the average. A provider with a similar mean but a much fatter tail will cause timeout-related failures under concurrency that don't appear in low-volume testing.
Success rate per target, not pooled. Providers differ a lot by target; an aggregate that looks equivalent can hide "much better on target A, much worse on target B."
Geographic accuracy, if you depend on it. Verify that IPs claiming a city actually resolve there, rather than trusting the label.
Soft-block rate specifically. A provider can show identical HTTP success rates while returning noticeably more empty or CAPTCHA-shaped 200s. If your pipeline only checks status codes, this migration will look clean and quietly degrade your data.

Things that break that aren't the proxies

Auth model mismatch. If the old provider used IP whitelisting and the new one uses username/password, that's a code change everywhere the proxy is constructed, not a config value.

Session semantics. "Sticky session" means different durations and different renewal behavior across providers. A pipeline built around one provider's stickiness can break subtly on another's — sessions expiring mid-flow rather than at flow boundaries.

Credential handling in CI and secrets stores. The new credentials need to exist everywhere the old ones did, including places nobody remembers, like scheduled jobs and staging environments.

Don't cancel the old plan on cutover day

Keep the previous provider available at minimum volume for a couple of weeks after reaching 100%. The cost is small, and it gives you an instant rollback path plus a live control group if something degrades. Reputation problems on a new pool often take days to surface — cancelling immediately means discovering them with no fallback.

This overlap period is also the honest way to evaluate a provider: real traffic, real targets, side by side with a known baseline. It's how we generally suggest teams evaluate SotaProxy rather than switching wholesale on trust — a gradual ramp with per-provider metrics tells you more in a week than any benchmark table will.

Proxy Pricing Models Explained: Per-GB vs Per-IP vs Per-Request

Sota Support — Sat, 01 Aug 2026 20:17:17 +0000

Proxy pricing looks arbitrary until you realize the model itself encodes assumptions about how you're supposed to use the product. Pick the wrong one and you're not just overpaying — you're fighting the pricing structure on every request.

Per-GB (bandwidth-based)

You pay for data transferred, and the IP pool is effectively unlimited. Standard for residential and mobile proxies.

Works well when: each request returns a small payload. Scraping text-heavy pages, checking prices, verifying ad placements — high request counts, low bytes per request. You get access to a huge pool without paying for IPs you touch once.

Gets expensive fast when: your targets return heavy pages. A modern e-commerce page with images and video assets can easily be several MB, and if you're not blocking media at the request level, you're paying real money to download product photos you never look at.

The optimization nobody does on day one: block images, fonts, video and stylesheets in your HTTP client or headless browser config. On image-heavy targets this routinely cuts bandwidth by well over half, which on a per-GB plan is a direct, immediate cost reduction with no downside for text extraction.

Per-IP (allocation-based)

You rent a fixed set of IPs for a period, and bandwidth through them is unmetered or generously capped. Standard for datacenter and ISP proxies.

Works well when: you have predictable, sustained volume against a known set of targets, and especially when payloads are heavy. Once you've paid for the IP, downloading 10 MB costs the same as downloading 10 KB.

Gets expensive fast when: your usage is bursty or exploratory. Paying monthly for 50 IPs you use for three days of a campaign is pure waste, and this is the most common way teams overspend without noticing — the bill is flat, so nothing signals that utilization collapsed.

Watch for: the difference between "unlimited bandwidth" and "unlimited bandwidth subject to fair use." Read what the actual throttle threshold is before building a pipeline that assumes the former.

Per-request (API-style)

You pay per successful request, and the provider handles rotation, retries and often rendering. This is the unblocker/scraping-API model rather than raw proxy access.

Works well when: you value not maintaining the infrastructure more than you value per-unit cost. It's genuinely the cheapest option at low volume once you price in engineering time.

Gets expensive fast when: volume grows. The per-unit cost that felt trivial at 10k requests/month becomes the dominant line item at 10M, and by then you've built everything around their abstraction rather than around a proxy layer you control.

The lock-in worth naming: this model usually means you don't have direct IP access, so migrating away later means rebuilding the rotation, retry and session logic the provider was handling for you.

Doing the actual math

Work out cost-per-successful-request under each model for your real traffic, not your ideal traffic:

per_gb_cost      = (avg_payload_mb / 1024) * price_per_gb / success_rate
per_ip_cost      = (monthly_ip_cost * ips_needed) / monthly_successful_requests
per_request_cost = price_per_request

The success_rate divisor matters more than people expect. A cheaper pool with a 60% success rate can easily cost more per successful request than a pricier pool at 95%, because you're paying for the failures too — on a per-GB plan, a blocked response still transfers bytes.

Mixing models on purpose

There's no rule saying you pick one. A common mature setup: datacenter per-IP for high-volume low-defense targets, residential per-GB for the subset of targets that need it, and neither for anything you can get from an official API. Routing each target to the cheapest model that actually works for it is usually a bigger cost lever than negotiating rates within any single model — it's the thing we most often end up working through with teams sizing infrastructure on SotaProxy, since the answer is almost always a mix rather than one plan.

The failure mode to avoid is picking a model once, at the start, when your traffic pattern was hypothetical — and never revisiting it after you learned what your traffic actually looks like.

Proxy Authentication Methods Compared: IP Whitelisting vs Username/Password vs Session Tokens

Sota Support — Tue, 28 Jul 2026 23:37:10 +0000

Most proxy integration bugs aren't about the proxy itself — they're about picking the wrong authentication method for your infrastructure and fighting it for weeks. Here's an honest comparison of the three common approaches.

IP whitelisting

You register your server's static IP with the proxy provider, and any traffic from that IP is authenticated automatically — no credentials in your request headers at all.

Good for: Fixed infrastructure (dedicated servers, static cloud instances). Zero per-request overhead, nothing to leak in logs, simplest possible integration.

Bad for: Anything running on dynamic infrastructure — serverless functions, auto-scaling containers, local development machines, CI/CD runners. Every new IP means a manual (or API-driven) whitelist update, which turns into real operational friction fast if your infrastructure changes often.

Common failure mode: Teams whitelist a NAT gateway or load balancer IP, then scale horizontally and discover every new instance routes through a different egress IP, silently breaking authentication for a subset of traffic. This one is sneaky because it often only affects some percentage of requests, not all of them, making it look like a flaky proxy rather than an auth config gap.

Username/password (Basic Auth)

Credentials sent per-request, either in the proxy URL itself or as a Proxy-Authorization header.

Good for: Dynamic infrastructure where IPs change constantly. Works identically whether you're running on your laptop or a fleet of ephemeral containers — you don't have to think about where the request originates from at all, which is a real reduction in infrastructure-tracking overhead compared to whitelisting.

Bad for: Credential hygiene. It's extremely easy to accidentally commit credentials to version control, log them in plaintext during debugging, or leak them in error traces. If you go this route, treat proxy credentials with the same care as API keys — environment variables, secrets managers, never hardcoded.

Common failure mode: Special characters in the password breaking URL encoding when embedded directly in a connection string. A password with symbols in a URL needs proper percent-encoding or your requests fail with a confusing "invalid proxy" error that has nothing to do with your actual credentials being wrong.

Session tokens

A short-lived token issued via an API call, used to authenticate a batch of requests, then rotated or expired.

Good for: Sticky-session workflows where you need many requests to route through the same IP for a defined window (multi-step account flows, checkout processes, anything stateful). Also gives you the tightest security posture, since a leaked token has a limited blast radius compared to a long-lived password.

Bad for: Simplicity. This adds a token-management layer to your code — you now need to handle token refresh, expiry, and renewal logic, which is meaningfully more integration work than the other two methods.

Common failure mode: Not handling token expiry gracefully mid-session, so a long-running scrape job silently starts failing partway through instead of refreshing and continuing.

Picking one

If your infrastructure is static: IP whitelisting, it's the least amount of ongoing work. If it's dynamic or you're deploying from many different environments: username/password, treated as a real secret. If you specifically need session persistence for stateful flows: session tokens are worth the extra integration effort — this is one of the places we spend the most engineering time when integrating SotaProxy into a customer's existing pipeline, since getting the auth model right up front avoids most of the "why is this intermittently failing" debugging later.

Mixing methods across environments (whitelisting in production, username/password for local dev) is also completely normal — you don't have to pick just one for your whole stack.

Concurrency Limits and Proxy Pools: How Many Threads Can You Actually Run?

Sota Support — Tue, 28 Jul 2026 23:34:54 +0000

"How many concurrent requests can I run?" doesn't have a single number answer — it depends on your pool size, target tolerance, and what you're actually optimizing for. Here's how to think about it instead of guessing.

The pool-size math nobody does upfront

If you have 1,000 IPs in your pool and you're running 500 concurrent threads with rotation, you're not actually getting 1,000-IP-worth of distribution — you're hitting a huge chunk of your pool within seconds, meaning many requests land on IPs that were JUST used moments earlier. Effective distribution depends on the ratio of concurrent threads to pool size, not just pool size alone.

A rough starting rule: keep concurrent threads at roughly 5-10% of your active pool size if you want each IP to have meaningful "rest time" between requests to the same target. Push much higher than that and you're relying on the target not noticing rapid reuse, not on genuine distribution.

Per-target tolerance varies enormously

The same concurrency level that's invisible to one target gets you blocked in minutes on another:

Static content, light protection: high concurrency tolerated, target largely doesn't track request velocity per IP
Search/listing pages with basic rate limiting: concurrency matters less than requests-per-IP-per-minute — you can run many threads as long as each individual IP stays under the target's per-IP threshold
Account-gated or aggressively fingerprinted targets: concurrency across the whole pool matters less than behavior per session — this is where sticky sessions and human-paced timing matter more than raw thread count

Testing concurrency in isolation, without accounting for which of these three categories your target falls into, produces numbers that don't transfer to a different target at all.

Ramping instead of jumping straight to max concurrency

Starting a new target at your theoretical max concurrency is how you find out the hard way that the theoretical max was wrong. A ramp pattern works better:

Start at a low concurrency (5-10 threads), measure ban/failure rate over a meaningful sample (hundreds of requests, not tens)
Increase incrementally, re-measuring failure rate at each step
Stop increasing once failure rate starts climbing measurably above your baseline — that's your real ceiling for this specific target, today

This ceiling isn't permanent. Targets change their tolerance over time (sometimes because of your own traffic pattern, sometimes independently), so the ramp is worth re-running periodically rather than treating a number you found once as permanent truth.

Concurrency per IP vs concurrency per pool

These are different numbers and conflating them causes confusion:

Concurrency per IP: how many simultaneous requests one specific IP is handling right now. For most targets, this should be 1 — an IP handling multiple simultaneous requests to the same target looks nothing like normal user behavior.
Concurrency per pool: how many total simultaneous requests you're running across your whole IP pool. This can be much higher, since it's spread across many different IPs each behaving like a normal single user.

If you're seeing high ban rates and you're not sure why, check whether you've accidentally let concurrency-per-IP creep above 1 somewhere in your request queue logic — this is a common, easy-to-miss bug that looks like a "bad pool" problem but is actually a scheduling problem.

Practical takeaway

Don't ask "what's the max concurrency" as a fixed number — ask "what's the max concurrency for this pool size, against this specific target, today." Re-derive it periodically instead of hardcoding a value you found once and trusting it forever.

This kind of pool-sizing and concurrency planning is exactly what we help teams work through at SotaProxy when architecting proxy infrastructure for scraping and automation at scale — happy to compare notes if you're mid-tuning something like this.

Debugging High Ban Rates: A Systematic Troubleshooting Framework

Sota Support — Tue, 28 Jul 2026 23:33:08 +0000

"Our ban rate went up" is one of the least useful bug reports in scraping and automation work — because it could mean five completely different things, each with a different fix. Here's a framework for actually narrowing it down instead of guessing.

Step 1: Split "ban rate" into what's actually happening

Before touching anything, separate these, because they have different causes:

Hard blocks (403/429, explicit "you've been blocked" pages) — usually IP or fingerprint reputation
Silent degradation (200 status, but wrong/empty/stale data) — often a soft anti-bot response designed to waste your time without tipping you off
Account-level bans (the account itself gets flagged, not just the request) — almost always a fingerprint/behavior signal, not just IP
CAPTCHA walls — a specific escalation tier, tells you the target already suspects automation before the block happens

Treating all four as "bans" and applying one fix to all of them is the single most common reason troubleshooting goes in circles.

Step 2: Isolate the variable — IP, fingerprint, or behavior

Once you know which failure mode you're seeing, test each layer independently:

IP test: hit the target from a fresh, never-used IP with everything else identical. If the ban rate drops significantly, the problem is IP reputation, not your setup.
Fingerprint test: keep the same IP, but rotate to a clean browser fingerprint (new profile, no shared canvas/WebGL history). If this alone helps, your fingerprint pool is contaminated or too uniform.
Behavior test: keep IP and fingerprint constant, slow down request timing to fully human pace. If this alone helps, the target is scoring request velocity/pattern, not identity.

Most real-world cases are a combination of two of these, which is why single-variable fixes ("just get better proxies") often only partially work.

Step 3: Check for pool-level contamination, not just individual IP quality

An IP can be "clean" in isolation and still be part of a contaminated pool if:

It was recently reassigned from another user who got it flagged (common with lower-quality residential providers that recycle IPs fast)
It shares a subnet with IPs that are already flagged, and the target scores at the subnet/ASN level rather than per-IP
It's been hit by other users of the same proxy pool targeting the same site concurrently, creating a traffic pattern the target can correlate

This is why success rate can degrade over time on a pool that tested clean initially — it's not that the IP changed, it's that the pool's collective reputation with that specific target changed.

Step 4: Track failure rate as a time series, not a snapshot

A single "ban rate: 12%" number hides the information you actually need. Track it per IP, per pool, per target, over a rolling window. This reveals:

Whether failures cluster around specific times (rate limiting vs reputation)
Whether specific IPs or subnets are consistently worse (contamination)
Whether the failure rate climbs gradually (reputation decay) or jumps suddenly (a specific IP or fingerprint got burned)

Step 5: Change one thing, measure, then change the next

Once you've isolated where the problem likely sits, resist the urge to change proxy type, fingerprint setup, and request timing all at once. Each change should be tested in isolation against a control group running the old configuration, or you'll never know which change actually fixed it — which means you'll be back here next time something breaks, with no idea what worked last time.

This kind of layered diagnosis is exactly what we help teams work through at SotaProxy when ban rates spike unexpectedly — often the real fix is in the proxy pool's composition, not the browser or the code. If you're mid-troubleshoot on something like this, happy to compare notes.

WebSocket Connections Through Proxies: What's Different From Regular HTTP Requests

Sota Support — Sun, 26 Jul 2026 00:02:33 +0000

The fundamental difference: one long-lived connection, not many short ones

A regular HTTP request through a proxy is a discrete unit — connect, send, receive, done, decide on rotation independently for the next one. A WebSocket is a single connection that stays open, often for the entire duration of a session, with many messages flowing both directions over that one connection. This changes what "rotation" even means: there's no natural per-message rotation point the way there is with per-request HTTP, because rotating mid-connection means literally breaking the connection.

What this means for IP assignment

For WebSocket-based workflows, IP assignment has to happen once, at connection time, and then hold for the full lifetime of that connection — there's no equivalent of "rotate on the next request" available mid-stream. This makes WebSocket traffic structurally closer to a sticky-session HTTP flow than to stateless rotation, even if your overall system also does high-frequency rotation for its regular HTTP traffic elsewhere.

ws_connection = connect(target, proxy=pool.get_sticky_ip())

this proxy assignment holds for the entire connection lifetime

rotation only happens on reconnect, not mid-session

Where proxy compatibility actually breaks

Not all proxy types handle WebSocket upgrade requests correctly. A WebSocket connection starts as an HTTP request with an Upgrade: websocket header, and some proxy configurations — particularly ones tuned narrowly for plain HTTP/HTTPS traffic — don't handle the upgrade handshake correctly, silently failing the connection or falling back to closing it after the handshake instead of maintaining the long-lived connection.

Connection timeouts tuned for HTTP requests kill WebSocket connections prematurely. If your proxy or client library has a read timeout tuned for "how long should I wait for an HTTP response" (seconds), and that same timeout applies to an idle-but-legitimate WebSocket connection (which might go quiet for extended periods between messages without being dead), you'll see connections drop that were never actually broken — just idle, which a request-response timeout model misinterprets as failure.

Reconnection logic needs to be IP-aware, not just retry-aware. When a WebSocket connection does drop and needs to reconnect, deciding whether to reconnect through the same IP or a fresh one depends on why it dropped — a clean server-side close is different from a proxy-side failure, and treating every reconnect as "get a fresh IP" can break session-dependent state on the target's side the same way IP-rotation mid-session breaks cookie-based auth in regular HTTP flows.

Practical guidance
Treat each WebSocket connection as a single sticky-IP unit for pool-management purposes, not a stream of independently-rotatable requests
Set proxy/client timeouts specifically for long-lived idle connections, separate from your regular HTTP request timeouts
Verify your proxy type explicitly supports the WebSocket upgrade handshake before assuming it "just works" the same way it does for HTTP — this is a real compatibility gap between providers, not a given

This is one of the less-documented compatibility questions we field when SotaProxy gets used for real-time or streaming-adjacent workflows rather than plain request-response scraping — worth checking explicitly rather than assuming your proxy setup that works fine for HTTP will behave identically for WebSocket traffic.

Building a Proxy Failover Strategy: What Happens When Your Primary Pool Goes Down

Sota Support — Fri, 24 Jul 2026 12:16:32 +0000

Most proxy integrations are built assuming the pool is always available, and the failure mode gets designed reactively, after the first real outage, instead of planned for upfront. Here's what an actual failover strategy looks like.

Why "just retry" isn't a failover strategy

If your primary proxy provider has an outage (their infrastructure, not just individual IPs failing), retrying against the same pool doesn't help — you're retrying against something that's actually down, not against normal noise. A real failover strategy needs a genuinely separate path to fall back to, and clear logic for when to use it.

The three components of an actual failover setup

Health detection above the individual-IP level. Per-IP failure tracking (which most setups already have) doesn't tell you the difference between "a few IPs are having a bad day" and "the whole provider is down." You need an aggregate signal — failure rate across the entire pool spiking simultaneously, not just isolated IPs — to distinguish pool-level outages from normal IP-level noise.

if pool.overall_failure_rate(last_5_min) > outage_threshold:
trigger_failover()

A genuinely independent secondary path. A secondary pool from the same provider doesn't help if the provider's infrastructure itself is down — you need either a different provider entirely, or at minimum infrastructure that doesn't share the failure domain of your primary (different upstream network, different account/API layer). This is the part that costs real money to maintain (a standing secondary relationship you're not using most of the time) and the part teams most often skip until the first real outage makes the cost of not having it obvious.
Explicit fallback and recovery logic, not just a switch. Failing over isn't a one-time event — you need logic for when to fail back to the primary once it recovers, and this needs its own health check, not just "the outage alert cleared." A primary that's flapping (up, down, up, down) needs hysteresis in your recovery logic, or you'll bounce back and forth between providers on every blip, which is often worse than staying on a slightly-degraded primary.

What tier of failover you actually need

Not every workload justifies a fully redundant secondary provider running hot at all times:

Non-critical batch jobs (can tolerate delay): a manual or semi-automated fallback, triggered by alerting, is often sufficient — you don't need instant automatic failover if a few hours of delay is acceptable.
Time-sensitive monitoring/verification work: needs automatic failover, since a delayed response might as well be no response for use cases like ad verification or price monitoring where staleness has real cost.
Revenue-critical flows (checkout monitoring, live account operations): needs both automatic failover and a tested, not just theoretical, secondary path — the worst time to discover your failover doesn't actually work is during the outage it was built for.
The failover path you never test is the one that fails when you need it

The most common failure mode isn't "no failover plan" — it's a failover plan that was built once, never exercised again, and quietly broken by the time an actual outage happens (expired credentials on the secondary account, a config drift, an integration that was never updated alongside the primary). Scheduling a periodic, deliberate test of the failover path — even just monthly — catches this class of bug before it matters, rather than during an actual incident.

This kind of resilience planning is part of how we think about infrastructure reliability at SotaProxy — assuming any single provider (including us) can have a bad day, and building the fallback path before it's needed rather than during the incident. If your current setup doesn't have a tested failover path, that's usually a bigger risk than it feels like until the day it matters.

Handling Redirects Through Rotating Proxies: Where Things Actually Break

Sota Support — Thu, 23 Jul 2026 15:11:11 +0000

The core issue: a redirect is a second request, and rotation doesn't know that

When your HTTP client follows a redirect automatically, it's making a brand new request to the Location header's URL. If your proxy rotation logic operates at the "one IP per request" level without any awareness that a redirect just happened, that second request can silently get a different IP than the first one — even though, from the target's perspective, this looks like one continuous navigation by one user.

Where this actually causes failures

Session or state loss mid-redirect. If the target sets a cookie on the first response and expects it to come back on the redirect-target request, and your client handles that fine at the HTTP layer, but the IP changed between the two requests — some targets treat that IP jump within a single navigation as suspicious, independent of whether the cookie itself was handled correctly.

Redirect loops that look like proxy failures. Some targets deliberately redirect suspected bots in a loop (often to a "verify you're human" page that itself redirects back). If your rotation logic assigns a new IP on each hop through that loop, you can end up burning through pool IPs rapidly on what's actually a single bot-detection response, not five independent failures — and the pool health metrics get polluted by IPs that never did anything wrong, they just got unlucky enough to be assigned during a redirect loop.

Geo-mismatch across hops. A redirect to a region-specific URL (common with e-commerce and localized content) combined with a rotation that assigns a completely different geography's IP on the second hop can produce responses that don't make sense for either IP — the kind of subtle inconsistency that's hard to debug because each individual request "worked," just not coherently together.

The fix: treat a redirect chain as one logical request for rotation purposes

Configure your client (or your own redirect-handling logic, if you're not using automatic following) to keep the same IP for the full chain of a single redirect sequence, and only let rotation logic assign a new IP once that chain fully resolves — success, final failure, or you've decided to abandon it.

def fetch_with_consistent_proxy(url, max_redirects=5):
proxy = pool.get_ip()
for _ in range(max_redirects):
response = request(url, proxy=proxy, allow_redirects=False)
if response.is_redirect:
url = response.headers['Location']
continue # same proxy for the next hop
return response
return response # give up, still logged as one chain, one proxy

A related trap: relative vs absolute redirect URLs

Some targets return relative Location headers, and if your redirect-handling code doesn't resolve them against the original request's base URL correctly, you can end up requesting a malformed URL entirely — which then gets misclassified as a "connection failure" in your logs when it was actually a URL-construction bug, muddying your failure-type statistics in a way that makes proxy pool quality look worse than it actually is.

This is one of the quieter integration bugs we help teams track down when building on SotaProxy — it rarely shows up in initial testing (single requests, no redirects in the test path) and only surfaces once real target behavior with redirect chains enters the picture. Worth checking your redirect-handling logic specifically if you're seeing inconsistent behavior that doesn't correlate cleanly with any single proxy.