Building Micro Proxies in Rust and Go

What a micro proxy actually does

A reverse proxy accepts a connection from a client, selects an upstream service, forwards traffic to that service, and returns the response. The word “micro” usually describes a deliberately narrow implementation rather than a separate network protocol. A micro proxy might support one listener, one upstream, a small configuration surface, and a limited set of operational features. That narrow scope can make the program easier to audit and deploy, but a small executable is not automatically a secure or reliable proxy.

The first architectural decision is whether the proxy understands the application protocol. An HTTP reverse proxy parses requests and responses, can make routing decisions from methods or paths, and must handle HTTP semantics correctly. A TCP proxy treats each connection as a bidirectional byte stream. It can carry HTTP, a database protocol, a custom binary protocol, or any other TCP-based traffic, but it cannot safely apply HTTP-specific rules because it does not interpret HTTP messages.

This distinction affects almost every later choice. An HTTP proxy needs policies for headers, request bodies, protocol versions, upgrades, upstream connection reuse, and malformed messages. A TCP proxy needs clear connection limits, dial timeouts, idle handling, half-close behavior, and bidirectional copy semantics. Both need bounded resources and a shutdown strategy that does not abandon active work without warning.

Reverse proxy and outbound tunnel are different layers

A locally running reverse proxy and an outbound tunnel solve different problems. The proxy decides how accepted traffic is handled after it reaches the local listener. The tunnel supplies a public entry point and transports incoming traffic to that listener. Combining them can be useful, but one does not replace the other.

With Localtonet, the client application on the device establishes an outbound connection to our relay server. This allows a service on that device, or reachable from it, to receive traffic through a public URL or public host and port without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The tunnel remains available only while the selected client device is connected and the tunnel is running.

For example, an HTTP micro proxy might listen locally and route requests to one development service. A Localtonet HTTP tunnel can point to that listener and provide the public URL. A byte-oriented TCP proxy can instead be published through a Localtonet TCP tunnel, which forwards traffic to the configured local IP address and port. The micro proxy still owns its routing, validation, timeout, and upstream policies. Localtonet provides the outbound relay path and public endpoint.

Choosing HTTP or TCP for the proxy boundary

Avoid protocol auto-detection unless there is a concrete requirement and a well-tested detection strategy. Ambiguous detection expands the state machine and creates more failure modes. A small proxy is generally easier to reason about when its listener has one declared protocol and one clear policy.

Rust and Go implementation tradeoffs

Rust and Go can both support efficient concurrent network services. The practical choice should reflect the team’s experience, dependency policy, deployment environment, and tolerance for implementation complexity. Claims that one language is always faster, safer, or smaller usually ignore workload shape, library behavior, compiler options, and operational design.

Concurrency and ownership in Rust

A Rust proxy commonly expresses each accepted connection as an asynchronous task. The type system can make ownership and shared-state boundaries explicit, which is valuable when connection state, cancellation, and configuration must move safely across concurrent tasks. Rust also gives developers detailed control over allocations and buffer lifetimes.

That control comes with design work. Cancellation behavior must be understood across asynchronous operations, shared state should remain intentionally narrow, and task creation must still be bounded. Memory safety does not prevent application-level denial of service, unlimited task spawning, an oversized queue, or an idle connection that never expires.

Concurrency and operational simplicity in Go

A Go proxy commonly handles accepted connections in goroutines and coordinates cancellation through contexts and channels. The standard networking model makes straightforward servers concise, and the runtime handles scheduling and garbage collection. This can reduce the amount of concurrency plumbing required for a small service.

Concision does not eliminate lifecycle concerns. A goroutine can leak while waiting on blocked input, an unbounded accept loop can create too much concurrent work, and a missing deadline can retain connections indefinitely. Context cancellation must be connected to actual network operations, and shared maps or counters still require safe synchronization.

Choose based on constraints, not slogans

Rust may be attractive when precise resource ownership, predictable allocation strategies, or integration with an existing Rust system matters. Go may be attractive when a team values a compact networking implementation, familiar operational tooling, and rapid maintenance by Go developers. A measured prototype using representative request sizes, connection churn, upstream latency, and failure conditions is more useful than a generic language benchmark.

Resource controls that belong in the first design

Resource limits should not be postponed until after load testing. The proxy needs an explicit admission policy. When the concurrency limit is reached, it should reject or defer new work in a predictable way rather than allowing the host to run out of memory or file descriptors. The acceptable behavior depends on the protocol, but the limit itself should be observable.

Timeouts should cover distinct phases. A connection may need an accept-to-processing deadline, an upstream dial timeout, HTTP header and body timing rules, an idle timeout, and a total request or connection lifetime where appropriate. One universal timeout is rarely enough because a slow handshake, a slow upload, and an idle keep-alive connection represent different conditions.

Buffers must also be bounded. A TCP relay should not allocate an unlimited buffer per direction. An HTTP proxy should limit header size and decide how request and response bodies are streamed. Buffering an entire body can simplify some transformations, but it also makes memory consumption depend on untrusted input. Streaming reduces that risk, although retries and transformations become more complicated.

Safe HTTP handling

An HTTP reverse proxy is not merely a TCP copier. It must parse messages consistently and reject malformed input. Header handling deserves a defined policy, especially for hop-by-hop headers, connection upgrades, host routing, and forwarding metadata. The proxy should not accept client-supplied forwarding identity as trusted truth unless the request came through a trusted boundary and the exact trust rule is documented.

Preserve only the headers required by the application and protocol. Avoid logging authorization values, cookies, API keys, or complete query strings that may contain secrets. If the upstream uses the Host value for routing, define whether the original host is preserved or replaced. If request identifiers are accepted from clients, validate their format and length before including them in logs.

Request smuggling risks arise when intermediaries disagree about message boundaries. Use maintained HTTP libraries, reject ambiguous framing, and avoid hand-written parsing unless protocol implementation is the actual project objective. Apply limits before expensive routing or authentication work whenever possible.

TCP connection handling and graceful shutdown

A TCP proxy generally opens an upstream connection after admitting the client, then copies bytes in both directions. Correct behavior includes partial reads, partial writes, cancellation, half-closed streams, upstream refusal, and one direction finishing before the other. The proxy should decide whether completion in one direction closes the entire connection or permits the remaining direction to drain.

Graceful shutdown begins by closing or canceling the listener so no new connections are accepted. Existing connections receive a bounded period to finish. After that deadline, remaining connections are closed. Track active connections so shutdown progress is visible, and make repeated termination signals produce deterministic behavior rather than racing multiple cleanup paths.

HTTP shutdown follows the same broad principle, but persistent connections and in-flight requests require separate accounting. Stop accepting new connections, discourage new requests on reusable connections where the HTTP stack supports it, wait for active requests, and enforce a final deadline. The shutdown timeout itself should be configurable within a safe operational range.

Observability without collecting sensitive traffic

Useful proxy telemetry answers operational questions without recording payloads. Recommended measurements include active connections, accepted and rejected connections, upstream dial failures, request counts by broad outcome, transferred byte totals, latency distributions, timeout counts, and graceful-shutdown duration. Labels should have bounded cardinality. Raw URLs, arbitrary hostnames, client identifiers, and error strings can create unbounded metric dimensions.

Logs should identify the event, listener, selected upstream category, duration, byte counts, and sanitized failure reason. Generate or propagate a bounded request identifier for HTTP when needed, but do not treat an externally supplied identifier as proof of identity. Health checks should distinguish whether the process is alive from whether it is ready to accept traffic and reach its required dependencies.

How to expose the local proxy with Localtonet

Complete the proxy’s local security and failure testing before making it publicly reachable. The following workflow applies the documented Localtonet lifecycle without inventing protocol-specific fields or fixed relay values. Available servers, regions, and options must be obtained from the current dashboard because availability can vary.

Localtonet tunnels can be managed from a single dashboard or REST API. Exact API operations, authentication details, server values, and plan availability should always be taken from the current product documentation rather than embedded as assumptions in the proxy.

A practical validation checklist

Before exposure, verify that the listener binds only where intended, upstream destinations cannot be changed by arbitrary client input, and administrative endpoints use separate listeners. Confirm that connection, request, buffer, and queue limits behave correctly under pressure. Simulate an unreachable upstream, slow upload, slow response, abrupt client disconnect, and termination while traffic is active.

For HTTP, test malformed headers, oversized headers, unexpected methods, large bodies, forwarding-header spoofing, and upstream cancellation. For TCP, test half-close behavior, idle connections, failed dials, partial transfers, and both sides disconnecting in different orders. Finally, verify that logs and metrics remain useful without exposing credentials, cookies, tokens, private payloads, or high-cardinality values.

Frequently asked questions