Follow the checks between your application and an approved upstream

The presented ThrottleProxy key is SHA-256 hashed and used for one exact Redis configuration lookup. Invalid random keys do not trigger Redis scans or database fallback.

The resolved key configuration establishes the authorized workspace boundary before destination or traffic policy is evaluated.

The target must match the workspace’s exact-host or explicit one-level wildcard allowlist. Protocol, port, hostname, DNS answers, and self-domain protections are evaluated before connection.

The validated DNS result is pinned for the outbound connection while TLS verification and SNI continue to use the intended hostname.

Rate policy and atomic Redis-backed admission caps protect per-key, workspace, target, and global resources. Queue admission fails fast when its configured caps are full.

Request bytes are counted while streaming, so a chunked upload cannot bypass the body limit by omitting Content-Length.

Proxy credentials, cookies, ThrottleProxy headers, headers nominated by Connection, and hop-by-hop headers are removed before forwarding. The outbound Host represents the intended upstream.

Response bytes are counted while streaming. Idle and absolute deadlines remain separate, and oversized or overdue traffic is aborted.

Lifecycle records preserve safe stages, status, timing, workspace context, and correlation identifiers while redacting secrets, query values, email addresses, unsafe errors, and raw bodies.

The customer request-timeline card is still a synthetic preview of how this context may be presented; it is not a claim of live per-request dashboard data.