Proxelar: The Rust Proxy That Turns Live Traffic Into a Developer Workbench

The Same Proxy, Three Ways to Drive It

Most proxies make you pick a camp. You get a terminal tool, or a GUI, or a web console. Proxelar does something more interesting: it treats the interface as a preference and the proxy engine as the product. That is why the repo feels less like a utility and more like a control surface for live traffic.

The project’s creator, Emanuele Em, says it plainly in the README: “Proxelar is a programmable MITM proxy that intercepts HTTP/HTTPS traffic so you don't have to guess what your app is doing. Forward & reverse modes, TLS interception, TUI, terminal, and web GUI.” That combination is the point. The tool is built for people who move between quick inspection, deeper analysis, and hands-on traffic shaping.

Why This Is More Than a Packet Viewer

Packet viewers show you what happened. Proxelar is built for what happens next. It can intercept requests, hold them, modify them, replay them, and route them through forward or reverse proxy modes. That makes it closer to a live test harness than a read-only inspector.

That matters because debugging traffic is often not an observation problem. It is a control problem. You do not just want to see a bad response. You want to rewrite it, fake it, or slow it down until the client reveals its assumptions.

The Rust Core Keeps the UI Out of the Hot Path

The repo is split into three Rust workspace members: proxelar-cli, proxyapi, and proxyapi_models. That separation is not cosmetic. It keeps the engine, data model, and presentation layer from becoming one tangled blob.

The important pattern is the event channel. The proxy emits ProxyEvent messages over an mpsc channel, so the UI can be slow, pretty, or remote without blocking the traffic path. In plain terms, the core keeps running even if the screen gets busy.

Lua Makes the Proxy Programmable

Proxelar’s scripting layer is where the proxy stops behaving like infrastructure and starts behaving like software you can shape. The Lua hooks, especially on_request and on_response, let you intercept a live exchange and mutate it before the client sees anything.

That is enough to do practical damage in the best possible sense: inject CORS headers, mock endpoints, fake latency, or return malformed payloads when you want to see how a client behaves under stress. The examples directory makes the intent obvious. This is not scripting for decoration. It is scripting for traffic surgery.

function on_request(req)
  if req.path == "/api/user" then
    req.headers["X-Debug"] = "1"
    req.body = '{"user":"mocked"}'
  end
  return req
end

function on_response(res)
  res.headers["Access-Control-Allow-Origin"] = "*"
  return res
end

The project’s own wording frames it as a programmable MITM proxy. That is the right abstraction. Once the traffic is scriptable, the proxy becomes a test harness for edge cases you do not want to reproduce inside application code.

Why Rust Changes the Proxy Story

Rust matters here for more than fashion. Proxelar leans on tokio for async execution, hyper and hyper-util for protocol handling, and rustls for TLS. The codebase also forbids unsafe code in the core, which lines up cleanly with the security-sensitive job the proxy is doing.

The result is a single-binary tool that feels native rather than layered. That is a real product advantage in a proxy. When the tool sits between you and live traffic, startup friction, memory behavior, and protocol correctness are not abstract concerns.

Where Proxelar Sits Beside mitmproxy, Burp, ZAP, and Charles

Proxelar is not trying to beat the incumbents on breadth. It is trying to make a narrower job feel better. Against mitmproxy, it competes on architecture and interface flexibility. Against Burp and ZAP, it offers a lighter, more developer-centric workflow. Against Charles, it brings openness and programmability to a space that is usually polished but closed.

That comparison is the real answer to the question, “Why not just use the thing everyone already uses?” Because Proxelar is built around a different promise. It does not center a security suite. It centers the moment where traffic becomes editable.

The Shape of the Project

The repository looks early, but not experimental. There is a clear workspace split, a typed data model, dedicated docs, CI automation, and a maintainer who appears to be building deliberately rather than improvising in public.

That is usually the sign of a project that knows its identity. Proxelar is not trying to be every kind of proxy. It is trying to be the one you reach for when live traffic needs to be observed, intercepted, and reshaped without ceremony.