3proxy

Last reviewed Sep 13, 2026 · 827 words

3proxy is a forward proxy, not a reverse proxy. That distinction filters out most people who land on its page: if you want to put HTTPS in front of your Docker apps, close this tab and read about Caddy or Traefik. 3proxy (5,400 stars, BSD-3-Clause, plain C, first released 2002) is for the other direction: your clients send traffic through it to reach the internet, with per-user authentication, access lists, bandwidth caps, and logging, in a process that idles at about 16 MB of RAM. It is the tool for "give this laptop an egress IP in my datacentre" or "log and throttle what the kids' devices fetch", and it does HTTP, HTTPS CONNECT, SOCKS4/5, FTP, POP3, and a handful of others from one binary.

Who actually runs it

Three groups, in my experience. People with a cheap VPS who want a private SOCKS5 endpoint for a browser or an SSH tunnel and find Squid absurdly large for that. Home networks that want an authenticated proxy on the LAN so that specific machines, or a tablet's browser, go out through a filtered and logged path. And embedded or low-power boxes where every process has to justify its footprint; 3proxy runs happily on a router.

If you only need HTTP with no auth and no SOCKS, Tinyproxy is simpler still. If you need caching, content filtering, or enterprise ACLs, Squid is the bigger and better-documented project and worth its 100 MB. 3proxy sits between: more protocols than Tinyproxy, a tenth of Squid's complexity, and documentation that is honestly sparse, which is why the next section exists.

The config file is a script, and order matters

3proxy reads a config where each line is a command executed in sequence. Auth, users, and ACLs must appear before the service that uses them. A working LAN setup with two users, HTTP on 3128 and SOCKS5 on 1080:

nserver 1.1.1.1
nscache 65536
timeouts 1 5 30 60 180 1800 15 60
log /var/log/3proxy/3proxy.log D
logformat "- +_L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"
rotate 30

auth strong
users aidan:CL:a-long-password
users guest:CL:another-password

allow aidan
allow guest * * 80,443
deny *

proxy -p3128
socks -p1080

auth strong requires username and password; auth none is an open proxy and auth iponly trusts source IPs, which is fine on a LAN and reckless on a public interface. users takes name:CL:cleartext or name:CR:crypted forms; use CR with an MD5-crypt hash on anything shared. The allow and deny lines form an ACL evaluated top to bottom: here aidan can reach anything, guest only ports 80 and 443, and everything else is refused. proxy and socks then start listeners that inherit the ACL above them.

Bandwidth limits use bandlimin 1000000 guest before the service line (bits per second, so that is about 1 Mbit). Run the daemon with 3proxy /etc/3proxy/3proxy.cfg, or use the official 3proxy/3proxy Docker image with the config bind-mounted to /usr/local/3proxy/conf/3proxy.cfg. The container is small enough that Docker's overhead is most of its memory.

The open-proxy trap is the whole risk

An unauthenticated proxy on a public IP is found by scanners within hours and used for spam and credential stuffing within a day, and the abuse reports come to you. Bind listeners to the LAN interface with -i192.168.1.10 on the proxy line, keep auth strong on anything else, and check the log after a week. If the point is a private egress from a VPS, the safer 2026 pattern is to not expose the proxy at all: put the VPS and your devices on Tailscale and bind 3proxy to the tailnet address. Then the proxy has no public listener and the ACL is a second layer rather than the only one.

What it will not do

No caching, no TLS interception, no web filtering by category, no admin interface (there is a tiny built-in web admin for stats, which I would leave off). Logs are plain text and you bring your own rotation and analysis. For ad blocking on the whole network, DNS-level tools in the proxy category such as Pi-hole are the right layer, not a forward proxy.

What I'd do

Install 3proxy on the box that already sits at the network edge, one auth strong block, listeners bound to the LAN or tailnet interface only, SOCKS5 on 1080 for the tools that support it and HTTP on 3128 for the ones that do not. Point a browser profile or a proxychains config at it and forget it exists; it will run for years on a config file you wrote once. Reach for Squid the day you need caching or category filtering, and not before.