Tinyproxy, a buffering proxy for small networks whose features are chosen at build time

Buffering decides who sets the pace on the wire

The headline idea in this proxy is the buffering connection. Instead of relaying bytes at whatever rate an origin server hands them over, the daemon pulls a fast response off the network into a buffer and then writes it out to the client at the highest speed that client will accept. The gap matters on a shared uplink. A server on a fast link can outrun a small network, and the client ends up waiting on a stream whose pace was decided three hops away. Tinyproxy moves that pacing decision down to the slowest link in the path.

That design also explains the stated niche. The README calls Tinyproxy a small, efficient HTTP and SSL proxy daemon released under the GNU General Public License, and it names buffering as a key feature rather than a tuning option. Nothing in the README offers a setting that switches buffering off, or a flag that resizes it. The relay speed follows the client, and that is the whole contract.

The sizing argument is a claim, not a measurement

The pitch is explicitly about size. Tinyproxy is described as useful in a small network setting, where a larger proxy would be too resource intensive or a security risk, and the named user is a network administrator sharing one Internet connection with a small group while allowing HTTP requests only. That is a sizing argument, not a benchmark.

The README gives no throughput number, no memory ceiling, no concurrent connection limit, no latency figure, and no comparison against any other proxy. How many simultaneous clients the daemon handles before it becomes the bottleneck, how much memory a buffered response occupies, whether it degrades under a burst, none of that is answered in the README. An administrator sizing a shared connection gets a clear design intent and zero capacity numbers.

Documented configure switches decide what the binary can do

What a Tinyproxy install can do is settled when it is built, not when it is started. The build is a standard GNU configure script driven by automake, and the README hands over the full set of switches it documents:

--enable-debug
--enable-xtinyproxy
--enable-filter
--enable-upstream
--enable-transparent
--enable-reverse
--with-stathost=HOST

`--enable-debug` turns on full debugging support. `--enable-filter` allows the daemon to filter out certain domains and URLs. `--enable-upstream` enables proxying connections through another proxy server. `--enable-reverse` enables reverse proxying. `--with-stathost=HOST` sets the default name of the stats host. A binary compiled without a switch simply lacks that capability, so the configure line used on a given machine is the real statement of what that machine can do.

A git checkout must generate configure before it can build

The build path forks depending on where the code came from. Tinyproxy uses the standard GNU configure script based on the automake system, and a fresh clone does not contain that script. If you are compiling from a git checkout, the first command, run from the top level directory, is:

./autogen.sh

That step generates the configure script. The release tarball contains the pre-created configure script, so when building from a release you skip it. Either way the build is the same three commands in the top level directory:

./configure
make
make install

For anything deeper than this, the README points you at the INSTALL file that autogen.sh generates and that ships inside the release tar ball.

XTinyproxy headers travel to every web server in your domain

One switch has an effect that reaches past the proxy's own clients. With `--enable-xtinyproxy` compiled in, Tinyproxy sends the XTinyproxy header to any web server in your domain. Read that sentence slowly: the header is not a private label between the proxy and its own clients, it is sent to any web server in your domain. Anyone who cares what the proxy discloses to those servers has to decide about this switch deliberately at build time, because it cannot be added afterwards without rebuilding.

Filtering sits beside it. `--enable-filter` allows the daemon to filter out certain domains and URLs, which is the switch that matters when the goal is to let HTTP requests through for a small group and nothing else. Both are build switches, not entries in a configuration file.

Transparent mode depends on firewall rules, not a config line

Most proxy work needs explicit configuration. Transparent proxying is the exception, and the README says so directly. `--enable-transparent` allows Tinyproxy to be used as a transparent proxy daemon, and unlike other work modes, transparent proxying does not require explicit configuration and works automatically when traffic is redirected to the proxy using the appropriate firewall rules.

That moves part of the setup out of the project and into the network. Those redirect rules are yours to write and yours to keep correct, and the README does not say what they should contain, which interface they belong on, or how to confirm that a packet took the path you intended. Reverse proxying and upstream chaining are plainer by comparison, since both are ordinary build switches: one is for acting as a reverse proxy, the other for passing connections through another proxy server.

The README stops at make install, so the first run is on you

Everything above is build documentation. The README does not document how to start the installed daemon, where its configuration file lives, what its default listening port is, which keys that file accepts, or how to keep it running after a reboot. The top level of the repository does contain etc/, docs/, data/, scripts/, tests/, src/ and m4macros/, and build detail is delegated to the generated INSTALL file, but nothing narrates a first client request or an error to expect when one fails.

The two gaps that decide whether a proxy is usable at all are access control and logging, and neither has a documented answer here. Expect to read the source tree and the docs/ directory before the first deployment. Expect that reading, not a tutorial, to be the work.

Support arrives as issues, pull requests and one Libera channel

The project asks for help in public and in two places. Problems go to the issue tracker on the project's repository host, and contributions are a pull request against a clone of that same repository. Day to day discussion happens in the #tinyproxy channel on libera (irc.libera.chat), where the project says you can meet developers and users to discuss development, patches and deployment issues.

The code is C under GPL-2.0, on the master branch. Release tags are sparse and slow: 1.11.1 shipped on 27 May 2022, 1.11.2 on 8 May 2024, and 1.11.3 on 7 March 2026, which is a two year rhythm rather than a stream. The last push to the repository landed on 21 September 2026. A TODO file and a .travis.yml sit at the top level, but neither the README nor the release list announces a planned feature or a supported platform matrix.

Editorial conclusion

Tinyproxy fits a network administrator who wants to relay HTTP requests for a handful of clients on a host too small for a full proxy, and it fits nobody who needs published performance figures or a documented first run. Before deploying one, check the switches your binary was compiled with, read the configuration sources under etc/ and docs/, and confirm that your access control and logging needs are met, because the README answers neither.

Frequently asked questions

Official sources

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