Slow speeds

"Slow" is rarely the gateway itself — it's almost always one of: the residential / mobile network, your client config, or the target site. Walk through the diagnosis below.

Baseline expectations

Product	First byte	Throughput per connection
Residential	300–800 ms	10–50 Mbps
Mobile	500 ms–3 s	5–20 Mbps
ISP	50–150 ms	100 Mbps – 1 Gbps

If you're seeing this and assuming it should be faster — re-set expectations. Residential is real residential bandwidth.

Step 1 — measure where time goes

curl -w "\nDNS:%{time_namelookup}s Connect:%{time_connect}s TLS:%{time_appconnect}s TTFB:%{time_starttransfer}s Total:%{time_total}s\n" \
     -o /dev/null -s \
     --proxy http://USER:[e-mail]:7777 \
     https://example.com

Output decoded:

Field	Meaning
time_connect	TCP to gateway
time_appconnect	TLS handshake to target (through tunnel)
time_starttransfer	First byte from target
time_total	End to end

Where is the time going?

• High time_connect (>500 ms) → network from you to gate.helodata.io. Switch to a regional gateway (na.gate.helodata.io, eu.…, ap.…).
• High time_appconnect → target is slow or far from the exit IP.
• High time_starttransfer after handshake → target server processing, not network.

Step 2 — eliminate connection re-establishment

Re-using TCP / TLS connections (HTTP keep-alive, HTTP/2) saves the handshake cost. In requests:

s = requests.Session()                   # persistent connection

In Node with undici, the default dispatcher pools connections automatically — just don't construct a new ProxyAgent per request.

Step 3 — check your concurrency

You might have hit a per-sub-user concurrent limit:

HTTP/1.1 429
X-Helodata-Error-Code: concurrent-limit

See Rate limits. Either lower your concurrency or upgrade your plan.

Step 4 — try a different exit IP

The selected residential IP might just be slow today (it's someone's home internet). Drop your session to get a different IP.

Step 5 — try a different product

If residential is too slow for your throughput needs, ISP gives you 10–50× the per-IP throughput at a different cost model.

When the gateway is slow

Rare but real. Check the status page:

• https://status.helodata.com

If status is green but you're seeing high time_connect consistently, open a ticket with traceroute gate.helodata.io output and X-Helodata-Request-Id from a slow request.

Common pitfalls

• SOCKS5 with local DNS — local resolver adds latency. Use socks5h://.
• TLS-wrapped connection to gateway — adds an extra handshake on top of the target's own TLS; only use when your network demands TLS-only egress.
• DNS cache cold — time_namelookup >100 ms means your DNS resolver isn't caching. Configure a local resolver.
• Logging slows your client — verbose logs can dominate the wall-clock time on small requests.

Benchmarking properly

To compare proxy speed, measure many requests, not one:

for i in $(seq 100); do
  curl -w "%{time_total}\n" -o /dev/null -s \
       --proxy http://USER:[e-mail]:7777 \
       https://example.com/sitemap.xml
done | sort -n | awk 'NR==50{print "median:",$1} END{print "max:",$1}'

Median > 95th percentile — the latter is where bot detection lives.