Profile anatomy↗
How a JSON profile becomes a stable, shared target for the running process.
STATIC overview
STATIC is the local Rust proxy at the center of 404. A browser sends supported traffic to its listener; STATIC reads one selected profile, opens a separate connection to the destination, and returns the response. It can shape parts of the outbound connection and eligible page content. It is not an exit network: the website still sees the public IP of your chosen route.
The two sides of the proxy
There are two TLS relationships for HTTPS. The browser authenticates a certificate issued by STATIC’s local CA; STATIC separately authenticates the website on its upstream connection. The browser’s own TLS handshake is therefore not the handshake the website sees. Follow a request for the connection routing and response path.
One profile, several surfaces
| Surface | What STATIC uses the profile for | Where to read more |
|---|---|---|
| HTTP requests | Header rules and navigation/cache handling | Request headers |
| Upstream TLS | A candidate ClientHello plan passed to the transport backend | TLS and certificates |
| Upstream HTTP/2 | Settings, pseudo-header order, and other supported options | HTTP/2 |
| Page JavaScript | Identity and selected high-entropy API wrappers in eligible documents | JavaScript runtime |
| Linux packets, if configured | The selected profile can be synced into an external pinned eBPF map | Packet boundary |
These are related targets, not proof that every observable detail matches a native browser. STATIC warns about some profile inconsistencies, but it does not enforce browser-family matching for a manual operator. Read Profile anatomy before editing a profile.
The pieces inside STATIC
- Listener and connection router. Classifies direct TLS, HTTP
CONNECT, and plain HTTP proxy traffic. Negotiated ALPN selects a client-facing HTTP/2 or HTTP/1.1 path. - Shared profile store. Loads JSON profiles, resolves inheritance and seeded overlays, and shares active selection between the data plane and local control plane.
- Request and response pipeline. Applies header rules, behavioral metadata, CSP handling, HTML injection, and
Alt-Svchandling in a defined order. - Upstream fetcher. Builds a separate origin request through
wreq, with TLS and HTTP/2 options where supported. - Certificate provider and control plane. Issues site certificates from the local CA; exposes readiness, CA, profile, stop, and telemetry endpoints on a separate local listener.
The request path ties these pieces together. HTTP/1.1 and HTTP/2 document the different execution paths.
Explore the components
Request headers↗
The exact order of header rules and the request context they use.
TLS↗
The local certificate relationship and the separate outbound ClientHello plan.
HTTP/1.1↗
CONNECT, direct TLS, plain HTTP, buffered responses, and WebSockets.
HTTP/2↗
Per-stream Flows, upstream settings, retries, and selective buffering.
JavaScript↗
The injected browser runtime, its API modules, and context boundaries.
Continue into HTML injection and CSP, control and CA custody, and the packet boundary for the supporting systems.
What STATIC can and cannot cover
The bundled script changes selected JavaScript-visible properties after it loads into an eligible page. Already-running scripts, service workers, module workers, and browser-native behavior outside that script can still expose the host browser. TLS fidelity is limited by what the wreq backend can express. WebSocket upgrades take a separate tunnel path. STATIC does not change your account identity, IP address, or every packet field. See HTML injection and CSP, JavaScript runtime, and Packet boundary for the exact boundaries.
To install and run the CLI, start at Self-hosted / CLI. This section explains how the current implementation works; the STATIC source tree is the source of truth for a specific release.