Running your own proxy server vs paying for one: Tinyproxy, 3proxy and Privoxy, tested

A VPS with Tinyproxy or 3proxy on it is a perfectly good proxy, and it takes about ten minutes. What it gives you is one address, the VPS’s own, registered to a hosting company and never changing. If that one address is all your job needs, running it yourself is cheaper than anything we sell, and this guide shows how to do it safely. If you need many addresses, home addresses or rotation, no amount of config will produce them, and that is where paying starts to make sense.

Every config below was run before we printed it: Tinyproxy 1.11 from Debian 13’s package, 3proxy 1.0.0 from the project’s own .deb, and Privoxy 4.2, each in a throwaway container and tested with curl from a second one, against a page that echoes back the caller’s IP and headers.

What a DIY proxy server actually gets you

The row that decides most cases is “Registered to”. Your VPS’s address belongs to a hosting network, exactly like our datacenter IPs, so it gets the same welcome: fine on APIs and most sites, blocked or challenged by the ones that refuse hosting ranges. Before you build anything, run the five-minute residential vs datacenter test from the VPS itself. If the target lets the VPS in, you may not need us.

Option 1: Tinyproxy, the smallest HTTP proxy

Tinyproxy is an HTTP proxy and nothing else, which is a feature. On Debian or Ubuntu, sudo apt install tinyproxy, then change or add these lines in /etc/tinyproxy/tinyproxy.conf, keeping the package’s own User and Group lines:

Port 8888
Allow 203.0.113.7
BasicAuth monkey CHANGE-ME
ConnectPort 443
DisableViaHeader Yes

• Allow is your own public IP (the one here is a placeholder). Anyone else gets 403 before the password is even checked.
• BasicAuth adds a username and password on top. Without the right ones, Tinyproxy answers 407.
• ConnectPort 443 limits HTTPS tunnels to port 443. With no ConnectPort line at all, Tinyproxy tunnels to any port, which is how a proxy ends up relaying spam. A tunnel to port 80 was refused in our test, and the log said Refused CONNECT method on port 80.
• DisableViaHeader Yes matters more than it looks. By default Tinyproxy adds Via: 1.1 your-vps-hostname (tinyproxy) to every plain HTTP request, which tells the site both that a proxy is involved and what your server is called.

Restart it, open port 8888 in the VPS firewall to your own IP only, and test from home:

sudo systemctl restart tinyproxy
curl -x http://monkey:CHANGE-ME@VPS_IP:8888 https://httpbin.org/ip

The origin should be the VPS’s address. One thing to know about any plain HTTP proxy, this one included: the username and password travel to it as Basic authentication, readable by anything on the path between you and the VPS. That is why the Allow line is there too.

Option 2: 3proxy, for HTTP and SOCKS5 from one config

3proxy does both proxy types in a dozen lines. Debian 13 does not package it; the project publishes .deb and .rpm files on its GitHub releases page, and its package runs the service as the proxy user from /etc/3proxy/3proxy.cfg. Replace that file with:

nserver 1.1.1.1
nserver 9.9.9.9
nscache 65536
timeouts 1 5 30 60 180 1800 15 60
users monkey:CL:CHANGE-ME
auth strong
allow monkey 203.0.113.7
proxy -p3128 -n -a
socks -p1080

sudo install -o root -g proxy -m 640 3proxy.cfg /etc/3proxy/3proxy.cfg
sudo systemctl restart 3proxy
curl -x http://monkey:CHANGE-ME@VPS_IP:3128 https://httpbin.org/ip
curl -x socks5h://monkey:CHANGE-ME@VPS_IP:1080 https://httpbin.org/ip

• users monkey:CL:CHANGE-ME defines a user with a cleartext password, hence the 640 file mode. auth strong makes every connection log in, and allow monkey 203.0.113.7 accepts that user only from your IP. From anywhere else, 3proxy answers 407 even with the right password.
• -a on the proxy line is the one not to drop. Without it, 3proxy adds a header like Forwarded: for=YOUR_HOME_IP:PORT;by=vps-hostname:3128 to plain HTTP requests, handing the site the very address you were hiding. With it, nothing is added.
• -n turns off NTLM authentication, which you will not use. socks -p1080 is the SOCKS5 side, sharing the same users and rules.

Option 3: Privoxy, if you want filtering rather than a door

Privoxy is a filtering proxy: it strips trackers and rewrites headers. Its own configuration file is explicit that Privoxy itself does not support proxy authentication, so never expose it to the internet. Leave it on its default listen-address 127.0.0.1:8118 and reach it through SSH:

ssh -N -L 8118:127.0.0.1:8118 you@VPS_IP
curl -x http://127.0.0.1:8118 https://httpbin.org/ip

Privoxy can also pass everything on to another proxy, which is a handy trick for an HTTP-only tool that needs to reach a SOCKS5 proxy with a password. One line in its config does it, and the hostname is resolved at the far end:

forward-socks5   /   USER:PASS@IP:PORT  .

The other two: Dante and plain SSH

Dante (its server is sockd) is the classic SOCKS5-only server, with logins checked against the system’s own users. It is more configuration than 3proxy for the same result on one VPS. SSH needs no proxy software at all: ssh -N -D 127.0.0.1:1080 you@VPS_IP gives you a SOCKS5 proxy on your own machine that exits from the VPS, and AdsPower even takes an SSH server as a profile’s proxy directly. The guide to forcing any app through a proxy has the SSH routes in more detail.

Before you leave it running

• Never run it open. An open proxy on a public IP gets found by scanners and used by strangers, and the abuse reports for their traffic go to you and your hosting provider. Password plus an IP allowlist plus a firewall rule, all three.
• Read your VPS provider’s acceptable use policy before you start. It is their network, and their rules on proxies, scraping and outbound traffic are the ones that apply.
• Check your traffic allowance. A proxy moves every byte twice, in and out of the VPS. Your provider’s dashboard says how much a month you get.
• Keep the logs. Tinyproxy logs connections and failed logins out of the box. 3proxy logs nothing until you add a bare log line to its config; then it writes to standard output, which under systemd means journalctl -u 3proxy. When something odd happens, that is the first place to look.

The honest verdict: when DIY wins, and when it does not

Run your own when

• You already pay for a VPS and one address will do. Tinyproxy on it costs nothing more, and we cannot undercut nothing.
• You need one fixed outbound IP: for an API that allowlists callers, for webhooks, or for your own scripts to come from somewhere other than home.
• The target does not care about hosting ranges and the job is mostly bandwidth. A VPS’s traffic allowance can go a long way further than buying residential gigabytes would.
• You want to learn how proxies behave from the inside. Breaking your own is the best way.

Pay when

• The site blocks hosting ranges. Your VPS fails the same test our datacenter IPs fail. Only an address registered to a consumer ISP, or a real home connection, gets past that.
• You need many addresses. Every extra IP means another server to set up, patch and watch.
• You need rotation, or a country your provider does not have. A VPS is in one place and stays one address.
• Your time costs more than the difference. A rented proxy is somebody else’s 3am.

So, where are we not the cheapest answer? Anywhere one hosting IP is enough and you already have the server. For those jobs, set up 3proxy above and keep your money. When the job outgrows it, our datacenter proxies are the same kind of address without the server to look after, ISP proxies are the step for sites that refuse hosting ranges, and residential is the one thing a VPS cannot imitate at all. Not sure which side of the line you are on? Ask in Discord, where nobody is on commission. 🍌