Tinyproxy: an HTTP/HTTPS forwarding proxy for small networks

What Tinyproxy is for, and who it is for

Tinyproxy is a small HTTP and SSL proxy daemon under the GNU General Public License. The README positions it for a small network setting, where a larger proxy would be too resource intensive or a security risk. That framing is the whole product thesis: one process, one config file, no cache, no disk. A network administrator sharing an Internet connection across a handful of machines and wanting to allow only HTTP requests is the target reader the README names directly.

The design choice worth noticing is what it does not do. It does not cache responses, so it is not a bandwidth saver in the way a caching proxy is. It does not ship a web UI. The stats host option points at a page rather than a dashboard application. If your reason for wanting a proxy is to cut upstream traffic, this is the wrong tool, and the README never claims otherwise. If your reason is to funnel clients through one controlled egress point, it is a reasonable fit. The project lives at tinyproxy.github.io and takes issues on GitHub; there is no separate product site with a download button.

The buffering connection concept and the request path

The README calls the buffering connection concept one of the key features. In effect, Tinyproxy buffers a high speed response from a server and relays it to a client at the highest speed the client will accept. That is the mechanism: the proxy does not simply splice two sockets together and let backpressure do the work. It reads ahead from the upstream server into a buffer and then drains that buffer toward the client at whatever rate the client can absorb. The stated benefit is that sluggish clients stop stalling the server side of the connection.

That is a real trade-off, not a free win. A buffering proxy holds memory per connection while it reads ahead, so the resource profile depends on how much it buffers and how many clients are concurrent. The README does not publish buffer size limits or tuning knobs for this, and the repository layout does not expose a documented configuration key for it. Treat the buffering behaviour as a fixed property of the daemon rather than something you size yourself.

Beyond buffering, the shape is conventional. Clients are configured to send HTTP requests to the proxy, the daemon accepts them, resolves the target, opens or reuses a connection upstream, and relays the response back. SSL traffic is handled in the same forwarding path, which is why the README describes it as an HTTP/SSL proxy rather than an HTTP-only one. Filtering, upstream chaining, transparent interception and reverse proxying are all optional behaviours compiled in at build time, not toggled at runtime in a stock binary.

Building Tinyproxy from a release tarball

The README gives the standard GNU configure flow. Building from a git checkout requires generating the configure script first; the release tarball already contains it, so that step is skipped when you build from a release. Run these from the top level directory.

./autogen.sh
./configure
make
make install

The first command only applies to a git checkout. After configure finishes you should see the generated Makefiles and a summary of which optional features were enabled; make then compiles the daemon and make install places it on the system. Note that the README does not document an uninstall target, so plan your install prefix before running configure rather than after.

The optional features are the part people miss. They are configure flags, so they are decided before compilation, not in the config file. If you want domain and URL filtering, upstream proxying through another proxy server, transparent proxying, or reverse proxying, the corresponding flag has to be present at build time.

./configure --enable-filter --enable-upstream --enable-transparent --enable-reverse

There is also `--enable-debug` for full debugging support, `--enable-xtinyproxy` to send an XTinyproxy header to web servers in your domain, and `--with-stathost=HOST` to set the default stats host name. The README points at the generated INSTALL file for build system detail; that file is produced by autogen.sh and ships with the release tarball, so it is your reference for anything configure-related the README omits.

Transparent mode is the one setting that configures itself

Of the optional modes, transparent proxying is the odd one out. The README states that unlike other work modes it does not require explicit configuration and works automatically when traffic is redirected to the proxy using the appropriate firewall rules. That means the client side is not told about the proxy at all; the firewall redirects traffic and the daemon picks it up.

The consequence is that transparent mode moves the configuration burden to your packet filter. The README does not supply firewall rules, and it does not describe how the daemon distinguishes intercepted connections from ordinary ones. If you enable the mode, the correctness of the deployment rests on rules you write elsewhere and on the daemon's ability to infer the original destination. That is a thinner contract than the explicit-proxy path, where the client is configured deliberately and the failure modes are visible in the client's own settings.

For a small network where you control the gateway, transparent mode is usually the reason to choose Tinyproxy over a proxy that only speaks explicit configuration. For a network where clients are laptops that roam, it is not, because redirection only applies where your firewall applies.

Where Tinyproxy is the wrong choice

The clearest limitation is the absence of caching. Tinyproxy buffers, it does not store. A response fetched once is fetched again for the next client. If your goal is to reduce upstream bandwidth across many users requesting the same content, a caching proxy addresses that and Tinyproxy does not, and no configure flag changes it.

The second limitation is platform. The description says POSIX operating systems, and the repository is a GNU autotools C project. There is no Windows build path described in the README, no MSI, no service wrapper. People searching for a Windows proxy will not find one here. Android is likewise outside the documented scope; the daemon is something you put on a gateway or a server, not an app you install on a phone.

The third is the release cadence. Releases exist (1.11.1 in May 2022, 1.11.2 in May 2024, 1.11.3 in March 2026), and the repository has not been archived, with the last push on 2026-09-21. But the gaps between tagged releases are long, and the README does not describe a deprecation policy or a support window. If your organisation requires vendor support or a predictable patch stream, that is a mismatch you should weigh before deployment, not after.

Finally, the README does not document rollback, and it does not document an uninstall path. Upgrading means rebuilding and reinstalling over the previous binary, and reverting means having kept the old one.

Tinyproxy against Squid, Privoxy and HAProxy

Squid is the obvious comparison and the difference is caching. Squid stores responses on disk and memory and serves repeats from cache; Tinyproxy explicitly does not. Squid also carries a much larger configuration surface and a heavier footprint, which is exactly the trade the README describes when it says a larger proxy would be too resource intensive for a small network. If you need cache hits, Squid is the tool; if you need a small forwarding daemon, Squid is more than you asked for.

Privoxy is a filtering proxy aimed at privacy and content rewriting. Tinyproxy's filtering is opt-in at compile time via `--enable-filter` and the README describes it only as the ability to filter out certain domains and URLs. If your requirement is ad blocking or header rewriting, Privoxy is built around that and Tinyproxy is not.

HAProxy is a load balancer and reverse proxy for TCP and HTTP, not a client-side forward proxy. The overlap is only in the word proxy. HAProxy terminates and distributes traffic to backends; Tinyproxy accepts client requests and forwards them outward. Tinyproxy does have a reverse mode behind `--enable-reverse`, but the README does not present it as a load balancer, and there is no health checking or backend pool described. Nginx sits in the same category as HAProxy for this comparison: a web server and reverse proxy, not a forward proxy for clients.

Licence and the cost of running it

Tinyproxy is released under the GNU General Public License, and the repository carries a COPYING file along with AUTHORS, ChangeLog, NEWS, SECURITY.md and TODO at the top level. GPL-2.0 matters if you plan to redistribute a modified daemon or ship it inside a product: the licence obligations attach to distribution, and the COPYING file is the authoritative text, not this article. I am not giving legal advice, and the practical answer depends on whether you are running it internally or passing it on to others.

The operational cost is the build. Because the optional features are configure flags, a binary built without `--enable-filter` cannot filter, and one built without `--enable-upstream` cannot chain to another proxy. Distributions that package Tinyproxy choose a set of flags for you, and the README does not say which. If you depend on a specific mode, check how your package was built or compile it yourself. Upgrades are rebuild-and-reinstall: the README documents no in-place upgrade mechanism beyond replacing the binary, and no rollback. Keep the previous build if you need to go back.

Editorial conclusion

Tinyproxy suits an administrator who wants an HTTP/SSL forwarding proxy on a POSIX box for a small network and is comfortable building from a release tarball or git checkout. It is the wrong pick if you need caching, a Windows binary, or an actively developed project: the last push was on 2026-09-21, but releases are sparse, with 1.11.2 in May 2024 and 1.11.3 in March 2026. Before adopting it, verify that your build enables the optional features you need, since filtering, upstream proxying, transparent mode and reverse mode are all compile-time choices.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. tinyproxy/tinyproxy on GitHub