ZeroTrace Proxy
Policies & live traffic
The complete field reference for Chain Policies and Rotation Policies, plus the live snapshot and per-request traffic log the engines keep while they run.
Policies & live traffic
A policy is the rulebook a running chain or rotator follows. You save policies separately and assign one to each chain or rotator, so the same tuning can be reused across many of them — change the policy once and every chain or rotator using it picks up the new behavior. ZeroTrace Proxy ships one built-in Balanced policy for each engine; it can be copied but not deleted, and any policy currently assigned to a running chain or rotator can't be deleted until nothing references it.
This page documents every field on both policy types and how to read the live traffic the engines record.
Chain Policy — full field reference
Controls how the Chain Engine validates, watches, protects, and limits a running chain.
| Field | What it does | Default |
|---|---|---|
| Startup validation | Probe the route before treating a freshly started chain as healthy. On = "prove it works before I rely on it"; off = start immediately. | Off |
| Require auth | Whether the local endpoint demands a username and password before it will carry traffic. | Off |
| Auth username / password | The credentials the endpoint requires when Require auth is on. | Empty |
| Probe URL | The destination fetched to health-check the route. Pick one that genuinely travels through the chain. | https://example.com/ |
| Expected status codes | Which response codes from the probe count as success. | 200 |
| Request timeout | How long a forwarded request may take overall before it's abandoned. | 20s (range 1–300s) |
| Connect timeout | How long the engine waits to dial and tunnel through the hops. | 12s (range 1–120s) |
| Health-check interval | How often the running route is re-probed. | 20s (range 5–3600s) |
| Failure threshold | How many probes in a row must fail before a route is marked unhealthy. | 3 (range 1–20) |
| Retry budget | How many alternate (fallback) routes the engine may try for a single request. | 1 (max 5) |
| Fallback enabled | Whether the engine may switch to the chain's fallback routes when the primary fails. | On |
| Bandwidth limit | Optional cap (in MB) on traffic the chain may carry before it stops forwarding. 0 = unlimited. | 0 / unlimited (max 102,400 MB) |
How the policy shapes runtime
- If startup validation is on and the primary route fails but a fallback works, the chain can start in a degraded state rather than not starting at all.
- Failure threshold decides when repeated probe failures flip a route to unhealthy; retry budget caps how hard the engine tries fallbacks before giving up on one request.
- With require auth on, local tools must present the username and password before the endpoint serves them.
- With a bandwidth limit set, the chain stops forwarding once the cap is hit and records a notice in the traffic log.
Faster failure detection: lower the timeouts and the failure threshold. Steadier operation over a flaky link: raise them. A hard traffic cap: set the bandwidth limit. Lock the endpoint down: turn on require auth.
Rotation Policy — full field reference
Controls how the Rotation Engine moves through its pool.
| Field | What it does | Default |
|---|---|---|
| Startup validation | Probe before treating the rotator as healthy at start. | Off |
| Probe URL | The destination fetched to health-check a proxy. | https://example.com/ |
| Expected status codes | Which probe responses count as success. | 200 |
| Request timeout | How long a forwarded request may take overall. | 20s (1–300s) |
| Connect timeout | How long the engine waits to dial the current proxy. | 12s (1–120s) |
| Health-check interval | How often a proxy is re-probed while in rotation. | 30s (5–3600s) |
| Max requests per session | How many requests a proxy carries before the engine rotates to the next one. 1 = rotate every request. | 1 |
| Max session duration | How long a proxy is kept before rotating, regardless of request count. 0 = a sticky proxy lasts as long as it keeps working. | 300s (max 86,400s) |
| Max bytes per session | How much traffic one proxy may carry before rotation. | 50 MB |
| Sticky by target host | Keep the same proxy for the same destination host, so one site always sees you from one address while others see different ones. | Off |
| Failure threshold | Failures in a row before a proxy is marked unhealthy. | 2 (1–20) |
| Retry budget | How many alternate proxies the engine tries for one request before giving up. | 1 (max 10) |
| Rotate on status codes | Response codes from the destination that trigger an immediate rotation to a fresh proxy. | 403, 429, 502, 503, 504 |
| Cooldown | Short rest period for a proxy after one failure, before it's handed out again. | 30s |
| Quarantine | Longer exile for a proxy that keeps failing — pulled out of rotation for this long. | 300s |
| Max concurrent requests per proxy | Caps how many in-flight requests one proxy may carry at once. | 4 (1–64) |
| Fallback enabled | Whether the engine may reach past the current proxy to an alternate when the primary fails. | On |
Cooldown is a short breather given after a single failure — the proxy is skipped briefly, then eligible again. Quarantine is the longer penalty applied once a proxy has failed repeatedly (past the failure threshold) — it's pulled out of rotation for the full quarantine window before the engine will try it again.
Live traffic
Both engines run as a local proxy server bound to your own machine only, and both keep you informed while they run.
The runtime snapshot
At a glance, a running engine shows: the local address to use, the port it actually bound to (which may differ from the one you asked for if that was taken), the active chain or rotator, how many routes exist and how many are currently healthy, the most recent exit address, running request / success / failure counts, how many times it has switched routes, and total bytes in and out.
The traffic log
Every request that passes through is recorded live: method, destination, response status, bytes each way, duration, success/failure (with the error if it failed), and which chain/route or proxy carried it. The log keeps the most recent entries so it stays readable during a busy session.
The engines bind to your own computer — endpoints are reachable only from your machine, never exposed to the network. See Privacy.