02 Where shaping happens
Through a proxy
Route your traffic through an intermediary and you can shape it precisely — but only what you route.
The constraint is the architecture
A proxy sits in the path of specific application traffic, not the path of all traffic on a machine. HTTP proxies intercept HTTP and HTTPS. SOCKS proxies handle whatever is pointed at them. In either case, the shaping — the added delay, the bandwidth ceiling, the injected loss — applies only to the connections the application explicitly routes through that proxy. Anything that connects directly to the network, bypassing the proxy, is invisible to it and untouched by whatever conditions you have set.
That is a constraint, but it is also a capability. When you want to test one service under degraded conditions while leaving everything else on the machine running normally, a proxy is the most surgical instrument available. You degrade the REST calls without touching the DNS lookups that belong to a different resolver, or the telemetry pipeline that connects on its own socket. No other shaping layer offers that selectivity by default.
The mechanism is straightforward: the proxy accepts a connection from the application, opens its own connection to the destination, and relays bytes between them. Shaping happens on the relay — the proxy reads from one side at a controlled rate, holds bytes in its own buffer, and writes to the other side accordingly. This is userspace queuing. It is not the kernel's packet scheduler, not a token bucket enforced at the network interface, not anything that touches the wire below TCP. The proxy shapes at the stream level, not the packet level.
That difference matters for one class of measurement. Packet loss and reordering, when injected at the proxy layer, manifest as TCP retransmission seen from inside the connection, not as a dropped IP datagram seen from the outside. The shape of the impairment is real and valid for application testing; it just is not identical to what a hardware link or a kernel-level shaper produces. For most software developers asking "does my app degrade gracefully," the distinction is irrelevant. For someone measuring protocol behaviour at the transport layer, it is the whole question.
HTTPS complicates things once the proxy needs to inspect or modify content, because TLS encrypts the stream end-to-end. A transparent or tunnelling proxy can still rate-limit and delay without terminating TLS; it simply cannot parse what is inside. That is usually sufficient for conditioning work — you do not need to read the bytes to slow them down.
The honest summary: a proxy shapes with precision and without privilege. It requires no kernel extensions, no root access, no changes to routing tables. What it cannot do is shape traffic that does not pass through it.
