Traffic Log Fields
Chain Engine and Rotation Engine runtime counters, traffic fields, and switch reasons.
The traffic log is the runtime’s diary. It tells you what the client asked for, which route or proxy was used, whether the request succeeded, how many bytes moved, and why the runtime switched when it did. When a runtime feels “random,” the log is usually the place that makes it boring again.
Shared Runtime Snapshot
Both engines show the local endpoint, requested port, bound port, request count, success count, failure count, switch count, bytes received, bytes sent, last health timestamp, and last notice or error. The bound port is especially important: clients should use the bound endpoint, not whatever port you originally requested.
The counters are not just vanity metrics. A rising request count with no traffic entries usually points at a display/filter issue. No request count change usually means the client is not using the local proxy. A rising failure count with stable request count means traffic is arriving, but route/proxy selection or upstream connectivity is failing.
Chain Traffic
Chain traffic entries focus on the route. They include method, target host, target URL, status, request bytes, response bytes, duration, success flag, error, chain name, route name, and timestamps. For CONNECT traffic, the target host and byte counters are often more useful than the full URL.
When a chain fails, read the error beside the route name. If fallback is enabled and switch count rises, the runtime is trying alternate routes. If healthy route count drops, the health loop is marking routes as unavailable.
Rotation Traffic
Rotation traffic entries add the selection story: rotator, source, proxy, decision, reason, session key, status, bytes, duration, and error. The reason field is the key to understanding rotation behavior.
Common reasons include new session, sticky session reused, status-triggered rotation, assigned proxy unavailable, assigned proxy quarantined, assigned proxy cooling, over concurrency limit, max session requests reached, max session time reached, max session bytes reached, and primary source exhausted.
If the same proxy keeps being reused, check sticky sessions and session limits. If proxies switch too often, check rotate-on statuses and max requests per session. If nothing is available, check cooling and quarantine counts before changing the strategy.
Read traffic logs before editing policy. The reason and error fields usually tell you whether the next fix belongs in the pool, the policy, or the client setup.