Proxy

Introduction

A proxy exposes your serverlets to the world, routing incoming traffic to a backend — usually a serverlet, but it can be any host — and load balancing across more than one. Every serverlet gets a default proxy the moment it’s created, reachable at a generated address right away; add more for custom domains, extra ports, or other services.

A proxy is one of three types, set when you create it: HTTP, TCP, or UDP.

Creating a proxy

• Region — where the proxy runs, or Auto.
• Source — the type (HTTP/HTTPS, TCP, or UDP) and the public domain or port.
• Destination — one or more targets: the protocol, host, and port traffic is forwarded to. Adding more than one target enables load balancing between them.

HTTP

The default type, and what most applications use. A Layer 7 reverse proxy for web traffic on ports 80/443, supporting HTTP/1.1, HTTP/2, and HTTP/3. TLS connections are routed to the right proxy by SNI (the hostname the client asks for during the TLS handshake), so many HTTP proxies with different domains can share the same IP and port.

You don’t need to own a domain to use one: Futrou generates a random subdomain under *.futrou.cloud by default, or you can pick your own subdomain under it — either way it works immediately, with TLS included. Bringing your own domain entirely is also supported; see Custom domains below.

TLS certificates

HTTP proxies get a TLS certificate automatically — there’s nothing to upload or configure. Futrou requests and renews certificates for you; domains with a wildcard are validated over DNS, others over HTTP, and validation reuses the same domain ownership checks used elsewhere on the platform.

Routing options

Advanced options control how requests are forwarded to the target:

• Verify TLS Certificate — validate the target’s TLS certificate. Turn this off only for trusted backends with self-signed certificates.
• Preserve Host — forward the original request’s Host header to the target unchanged. When this is off, the target instead sees the host (or IP) of the destination itself, as if you’d connected to it directly.
• Preserve Headers / Query / Path — forward the original request’s headers, query string, and path unchanged rather than substituting the target’s own.
• Follow Redirects — resolve HTTP redirects from the target server-side, instead of passing them to the client.
• Enforce HTTPS — redirect all HTTP requests to HTTPS at the edge.

Compression

Responses are compressed automatically when the client supports it and the content type is compressible (text, JSON, JS, CSS, SVG, and similar) — there’s nothing to configure. Futrou negotiates the best format the client’s Accept-Encoding header allows, preferring Zstandard, then Brotli, then gzip.

Caching

Proxies respect standard HTTP caching headers from your backend. Cache-Control: s-maxage sets how long a response may be cached, taking priority over max-age if both are present; no-cache, no-store, private, or max-age=0 all mean the response isn’t cached. Cached responses for a proxy can be cleared on demand with a purge, from the proxy’s page or its API — nothing is purged automatically, so purge after a backend deploy if you’ve changed cached content and can’t wait for it to expire naturally.

Rules

Rules let you match incoming HTTP requests and act on them without changing your application. A rule is a condition — matching on port, host, path, or HTTP method — paired with one or more actions, evaluated on every request before it reaches your backend, and again on the response before it reaches the client:

• Redirect a request to another URL, or rewrite its path.
• Set, or delete a request or response header.
• Set the request method or body, or the response status code or body.

Path matching supports exact paths, path-to-regex-style patterns with named and wildcard segments (like /users/:id or /files/**), and raw regular expressions. This covers cases from a simple redirect on one path, to rewriting requests before they reach your backend, to shaping the response your backend sends back — for example stripping an internal header, or forcing a specific status code.

TCP

Raw Layer 4 passthrough for protocols that aren’t HTTP. Traffic is forwarded to your target as-is, without inspecting or modifying it — no compression, caching, rules, or Host rewriting apply, since none of those are HTTP concepts.

A TCP proxy is assigned a port automatically on creation, from a fixed range above 1024 — you can’t request a specific port, including well-known ports like 22 or 3306. The assigned port is stable for the life of the proxy: it won’t change on its own, so once you’ve pointed a client at host:port, it keeps working.

UDP

The same as TCP, for UDP-based protocols: raw passthrough, an automatically assigned stable port above 1024, no HTTP-layer features.

Load balancing

When a proxy has multiple targets — of any type — traffic is distributed between them using one of two strategies:

• Round Robin (default) — spreads requests across all targets over time, preferring targets that are currently responding successfully.
• Primary Failover — sends everything to the first target, only using the next one if it fails.

Failover is reactive: a target is marked down after a request to it actually fails to connect (not on a slow response, and not because it returned an error status code — a reachable target that responds with a 5xx is considered a valid response, not a failure). A target marked down is retried automatically after a short cooldown, so it comes back into rotation once it recovers. If a request to one target fails outright, Futrou tries the next target in the same request before giving up — there’s no separate “retry the same target” step, and a serverlet target that’s asleep at zero instances is woken up and retried instead of being treated as failed (see Scaling to zero).

Custom domains

To use your own domain instead of a generated *.futrou.cloud one, add it as the proxy’s source domain and verify it. Verification checks for a _futrou TXT record on the domain containing the proxy’s ID — the same TXT record a DNS zone creates automatically, so if the domain’s DNS is already on Futrou, verification is typically immediate.

Metrics and logs

Every proxy’s page shows request counts by status code, unique visitors, and bandwidth, along with searchable access logs — useful for confirming traffic is flowing where you expect before and after a change. See Logs for the log format and what else is logged across a project.