Tinyproxy

Last reviewed Sep 13, 2026 · 786 words

Tinyproxy is a forward proxy: your clients point at it and it fetches the web on their behalf. It is not a reverse proxy, and if you arrived here looking for a way to put HTTPS in front of Docker containers, Caddy and the reverse proxy showdown are what you want. For its actual job, Tinyproxy is close to unbeatable on footprint: a C daemon from 1998 under GPL-2.0, about 16 MB of RAM, no database, no cache, and a config file you can read in one screen.

Five lines of config do the job

Install the distribution package (apt install tinyproxy on Debian and Ubuntu, apk add tinyproxy on Alpine, which is also the whole Dockerfile if you want a container) and edit /etc/tinyproxy/tinyproxy.conf:

Port 8888
Listen 192.168.1.10
Allow 192.168.1.0/24
Allow 127.0.0.1
ConnectPort 443

Port 8888 is the default. Listen binds to one interface rather than every address on the machine. Allow lines are the access control list, and only the listed sources may use the proxy. ConnectPort 443 restricts the HTTP CONNECT method, which is how HTTPS tunnels through a forward proxy, to the standard TLS port so nobody uses your box to reach arbitrary services. Restart, then test from a client with curl -x http://192.168.1.10:8888 https://example.com. That is the entire install.

Lock it down before it becomes an open relay

An open HTTP proxy on a public IP gets discovered by scanners within hours and starts relaying spam and credential stuffing under your address. Three rules. Never write Allow 0.0.0.0/0 on anything that is not an isolated lab. Bind Listen to a LAN or Tailscale address, not the public interface. If clients must come from outside, add BasicAuth username password so every request carries credentials, and put the whole thing behind a VPN anyway, because basic auth over plain HTTP is visible to anyone on the path. Set DisableViaHeader Yes if you do not want every upstream site told a proxy is involved.

The real jobs it does well

The homelab uses are narrower than a general-purpose proxy and that is fine. Give a VLAN or a set of containers with no default route a single controlled way out: set HTTP_PROXY and HTTPS_PROXY in their environment and let Tinyproxy's Filter file, with FilterDefaultDeny Yes, allow only the package mirrors and update endpoints they need. Chain through another hop with Upstream http vpn-box:3128 or a SOCKS5 upstream so HTTP traffic from a few machines exits through a VPN without routing the whole network. Test how a site looks from a second IP address. Serve as the proxy setting for a scraper or an older appliance that speaks HTTP proxy but not modern VPN protocols. Each of these is a five-minute setup that would be overkill on anything heavier.

No cache, so Squid still owns that job

Tinyproxy deliberately does not cache. If the reason you want a proxy is to serve the same Ubuntu packages to 15 machines once instead of 15 times, or to cut bandwidth on a metered link, Squid is the right tool and its several hundred megabytes of RAM buy you exactly that. If the reason is ad and tracker filtering at the HTTP layer, Privoxy has the rule engine Tinyproxy's simple URL filter lacks, and for network-wide blocking a DNS sinkhole does the job with no proxy setting on clients at all. Tinyproxy's Filter handles a short allow or deny list of domains; it is not a content filter.

Squid is the bigger project, and usually the wrong one here

Squid has more stars, more features, and decades of enterprise deployment, and for a home network almost all of that is weight you carry for nothing. Tinyproxy's advantage is that the entire config fits in your head, it runs on a router or a Pi Zero without noticing, and there is nothing to tune. The moment you need caching, SSL bumping, authentication against LDAP, or delay pools, you have outgrown it, and that moment is rarer than people assume.

What I'd do

Tinyproxy on the always-on box, bound to the LAN or Tailscale address, Allow restricted to the subnet that needs it, ConnectPort 443 only, Filter with a default deny for any container network that should reach a fixed list of hosts. No public exposure, ever. Reach for Squid only when you can name the cache hit rate you expect to get, and for Privoxy only when filtering is the actual goal.