ZeroTrace Proxy
Chain Engine
Build multi-hop proxy chains — by hand or automatically with Harmony auto-chain — save them, and run them as a local proxy server your own tools can point at.
Chain Engine
The Chain Engine routes your traffic through a sequence of proxies instead of just one. Each proxy in the sequence is a "hop," and traffic passes through them in order before reaching its destination — so the destination sees only the last hop, and no single proxy in the chain sees both you and where you are going.
The Chain Engine is more than a one-off test. It saves your chains, runs them as a local proxy server on your own machine, watches their health, falls back to a backup route when a hop dies, and shows you every request that flows through. You point your browser or tool at the local endpoint it provides, and the engine handles the multi-hop routing behind it.
Building a chain
A saved chain is an ordered list of hops plus the settings that govern how it runs. You can build one two ways.
By hand. You pick the proxies you want as hops and put them in order. Order matters: a route proxy-a → proxy-b → target is not the same as proxy-b → proxy-a → target, so the engine preserves the exact order you set. You can give each hop a readable label, name and annotate the chain, and tag it (for example manual, stable, or a country hint) so you can find it later.
Automatically, with Harmony auto-chain. Instead of assembling hops yourself, you hand Harmony a pool of proxies and ask it to build a working chain for you. It searches through the pool with a beam search — trying combinations, keeping only the most promising partial chains at each step, and discarding the rest — until it assembles a multi-hop chain that actually connects end to end. It is doing the trial-and-error of finding compatible hops so you do not have to. The chain it produces is a normal saved chain (usually tagged harmony) that you can run, edit, or use as a fallback like any other.
| Setting | What it does | Default |
|---|---|---|
| Target hop count | How many hops the finished chain should have | 3 (range 1–8) |
| Beam width | How many candidate partial chains Harmony keeps alive at each step of the search — wider finds better chains but takes longer | 4 (range 1–12) |
| Max candidates considered | A cap on how many proxies from the pool Harmony will try dialing overall | 20 (range 1–100) |
| Per-dial timeout | How long Harmony waits on each individual hop it tries before giving up on it | 15s (range 5–120s, minimum 5s) |
Harmony reports back whether it found a working chain, the hop list it settled on, the resulting exit address and latency, how many dial attempts it took, and an error if it came up empty.
A saved chain carries: a name and optional notes; tags for search and filtering; its ordered hops (each an entry with an optional label); a set of fallback chain IDs to try if the main route fails; the local port it listens on (or 0 to let the engine pick one); and the policy it runs under. That policy is where timeouts, health checks, authentication, and limits live — see Policies & live traffic for the complete field reference.
Fallback chains
A chain can point at other saved chains as fallbacks. When the main route fails and fallback is allowed by its policy, the engine tries those backup chains instead of simply dropping the connection. The engine checks the fallback wiring for you — it will not let you reference a chain that does not exist, create a loop of chains that fall back to each other, or delete a chain while another chain still relies on it as a fallback.
Running a chain
- Pick or build a chain
Choose a saved chain — one you assembled by hand or one Harmony built — or create a new one.
- Start its local server
Start the chain. The engine opens a proxy endpoint on your own machine (on your local computer only) and tells you the address to use. If the port you asked for is taken, it picks another and tells you which.
- Point your tool at it
Set your browser or application to use that local address as its proxy. From there, everything it sends flows through the chain's hops in order.
- Watch it work
The engine keeps a live snapshot — which chain is active, how many routes are healthy, the last exit address, request and success counts — and a running log of the traffic passing through. See Policies & live traffic.
Health and healing
While a chain runs, the engine keeps an eye on it. It probes the route on a schedule to confirm it is still working, counts failures, and when a route goes bad it switches to a fallback rather than leaving you stranded. How aggressively it does all this — how long it waits, how many failures it tolerates, when it gives up on a route — is set by the chain's policy, which you control.
Startup validation, request and connect timeouts, how often routes are health-checked, the failure threshold, the retry budget, whether fallback is allowed, an optional bandwidth cap, and whether the local endpoint requires a password — all of these are set in a Chain Policy. The full set of settings you can tune is documented on Policies & live traffic.