Skip to content

Reliability & retries

bytetourist is built to keep requests flowing even as individual nodes fail, get blocked, or are recycled.

Core tracks the health of every node. When a node accumulates failures (e.g. repeated 5xx/errors), its breaker trips open and core stops sending it traffic. After a cooldown it goes half-open to probe with a trickle of requests; if those succeed it closes and resumes normal traffic.

closed ──fail threshold──▶ open ──cooldown──▶ half-open ──success──▶ closed
└────────── failure ─────────────▶ open

This is automatic and per-node — you don’t configure or observe it per request.

The strict flag controls what happens when your primary pick can’t serve the request:

  • strict=false (default) — if the selected node is unhealthy or no node exactly matches, core falls back to the best available eligible node so your request still goes out.
  • strict=true — core fails fast and returns an error rather than relaxing your constraints. Use this when an exact region/ip_type is non-negotiable.
Terminal window
# fail rather than leave from the wrong place
-U "YOUR_API_KEY-cc-de-iptype-residential-strict-true:"

Each outbound call is bounded by a per-request timeout (a configurable system default). Exceeding it returns 504 Gateway Timeout. Keep your client timeout a little higher than the proxy’s so you see the proxy’s response rather than your own client abort.

bytetourist does not silently retry your request body — the edge node is a pure L7 proxy with no hidden retry or caching, so behaviour is predictable. For idempotent reads, retry on your side; a retried request is re-matched and will typically land on a different node (especially with freshest_ip / ip_rotation).

Code Meaning
407 Auth required — bad, missing, or revoked API key.
403 Plan violation — disallowed region/ip_type, or over a hard limit.
429 Too many in-flight requests for your org (concurrency cap).
502 Upstream/node error executing the request.
504 Outbound call timed out.