> ## Documentation Index > Fetch the complete documentation index at: https://developers.soax.com/llms.txt > Use this file to discover all available pages before exploring further. # Proxy Speed & Latency > What affects proxy latency, what to expect from each proxy type, and how to measure and improve performance in your setup. Proxy latency is real and worth understanding before you build. This page explains what drives it, what numbers to expect, and what you can do when speed matters. ## What latency means in a proxy setup When you send a request through SOAX, there are two network hops instead of one: 1. Your application → SOAX proxy node 2. SOAX proxy node → target website The total response time you see includes both hops plus the target's own response time. SOAX controls the first hop and the quality of the second; the target's response time is outside our control. When people say "the proxy is slow", it's usually one of three things: * The proxy node is geographically far from the target. * The eligible node pool is small due to narrow targeting, and the system spends time finding a match. * The target itself is slow or is rate-limiting the node. ## What to expect by proxy type There's a direct tradeoff between how legitimate an IP looks to the target and how fast it is. Residential and mobile IPs come from real consumer devices on real ISP connections — that's why they're harder to detect, and also why they add more latency than datacenter IPs. | Proxy type | Typical added latency | Notes | | ------------------------ | --------------------- | ---------------------------------------------------------------------- | | Residential | 100–800ms | Varies by country and ISP. Home connections can be asymmetric. | | Mobile | 150–1000ms | Cellular networks add variable overhead. Higher on congested carriers. | | ISP (static residential) | 50–200ms | Datacenter infrastructure with residential IP registration. | | Datacenter | 20–100ms | Fastest option, but higher detection risk on protected targets. | These are added latency figures on top of the target's own response time. A target that responds in 300ms over a direct connection might respond in 600–900ms through a residential proxy. That's expected behavior, not a problem. ## What affects latency in practice **Geographic distance between the node and the target.** SOAX automatically routes your requests through the nearest infrastructure server — we have servers in Europe, Asia, and North America. This means the first hop (your application → SOAX) is handled efficiently regardless of where you're running your code. The second hop (SOAX → target) still depends on which country your proxy node is in relative to the target's server location — so if speed matters, it's worth matching your node's country to where the target is hosted. **Pool size.** The more specific your targeting, the smaller the eligible pool. If you're targeting a specific city and ISP, the system may need more time to find an available matching node. [`NODE_NOT_FOUND`](/troubleshooting/error-codes#node_not_found) errors are the extreme case, but even before that, narrow pools can add allocation overhead. Start broad and narrow down only if you need to. **Concurrency.** High concurrency against a small pool can create contention. If you're sending hundreds of parallel requests targeting a narrow geo, some will wait for an available node. Broaden your targeting or reduce concurrency to keep response times predictable. **Target site behavior.** Some targets actively slow down traffic they suspect is automated. If latency spikes on a specific target but works fine on others, that's the target responding to your traffic pattern — not a proxy issue. See [CAPTCHA & ban rates](/troubleshooting/captcha-ban-rates). ## How to reduce latency **Match the node's country to the target's server location.** The content you want to access and the server you're hitting can be in different countries — target the server, not the content. If the target is hosted in Germany, use `country-de`. **Use sessions for multi-request workflows.** If you're making several requests as part of the same task, bind them to a session. You pay the node allocation cost once and reuse the same node for subsequent requests. **Broaden your targeting.** Narrow targeting means a smaller pool and higher allocation time. If you're targeting city + ISP, try removing the ISP filter first and see if latency improves. **Adjust your HTTP client timeout.** Residential and mobile proxies are slower than datacenter IPs. If your client has a tight timeout (e.g. 5 seconds), you'll see false failures on perfectly healthy connections. 15–30 seconds is more appropriate for residential traffic. ## Next steps Understand what makes an IP trustworthy and how SOAX maintains pool quality. What to do when the target site is blocking your requests. Full parameter reference including session and rotation options. Step-by-step checklist for diagnosing connection issues.