3proxy

Search the Marketplace for 3proxy, select the SecureAnyCloud publisher, and click Create.

Configure the Network Security Group to allow TCP 3128 (and/or TCP 1080 for SOCKS) from your client networks. Allow TCP 22 for administration.

RG="proxy-prod"; LOCATION="eastus"; VM_NAME="proxy1" IMAGE_URN="sac1647283583153:3proxy-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:3proxy-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 3128 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1002

On first boot the image generates a fresh proxy username and password, writes the crypt hash to /etc/3proxy/passwd, starts 3proxy, and writes /root/3proxy-credentials.txt. This completes within a few seconds.

SSH in as azureuser and read the details:

sudo cat /root/3proxy-credentials.txt

Check that 3proxy.service is running under systemd as the unprivileged proxy3 user. Then use ss to confirm the HTTP/HTTPS proxy is listening on :3128 and the SOCKS proxy on :1080.

systemctl is-active 3proxy.service ps -o user= -C 3proxy | head -1 ss -tlnp | grep -E ':3128 |:1080 '

The proxy rejects anonymous and wrong-credential requests with HTTP 407, and accepts the correct per-VM credentials. Read your credentials from the file into shell variables, then run the round trip.

These commands run on the VM against loopback. From a remote client, replace 127.0.0.1 with the VM address and connect from an allowed range.

PROXY_USER=$(sudo grep '^PROXY_USERNAME=' /root/3proxy-credentials.txt | cut -d= -f2-)
PROXY_PASS=$(sudo grep '^PROXY_PASSWORD=' /root/3proxy-credentials.txt | cut -d= -f2-)
echo -n 'anonymous : HTTP '; curl -s -o /dev/null -w '%{http_code}\n' -m 15 -x http://127.0.0.1:3128 http://example.com
echo -n 'wrong password : HTTP '; curl -s -o /dev/null -w '%{http_code}\n' -m 15 -x "http://$PROXY_USER:wrong@127.0.0.1:3128" http://example.com
echo -n 'authenticated : HTTP '; curl -s -o /dev/null -w '%{http_code}\n' -m 25 -x "http://$PROXY_USER:$PROXY_PASS@127.0.0.1:3128" http://example.com

Send an HTTPS request and a SOCKS request with the same credentials. HTTPS requests are tunnelled with the CONNECT method to TLS port 443, and the SOCKS proxy listens on port 1080.

PROXY_USER=$(sudo grep '^PROXY_USERNAME=' /root/3proxy-credentials.txt | cut -d= -f2-)
PROXY_PASS=$(sudo grep '^PROXY_PASSWORD=' /root/3proxy-credentials.txt | cut -d= -f2-)
# HTTPS through the HTTP proxy (CONNECT to 443)
curl -s -o /dev/null -w 'https via 3128 : HTTP %{http_code}\n' -m 25 -x "http://$PROXY_USER:$PROXY_PASS@127.0.0.1:3128" https://example.com
# SOCKS5 on port 1080 curl -s -o /dev/null -w 'https via socks: HTTP %{http_code}\n' -m 25 --socks5-hostname "$PROXY_USER:$PROXY_PASS@127.0.0.1:1080" https://example.com

Print the configuration to review it. It ships mandatory authentication (auth strong) and an access control list that allows authenticated clients from loopback and RFC1918 private ranges only. It also sets a deny * default and restricts CONNECT to TLS ports.

grep -vE '^\s*#|^\s*$' /etc/3proxy/3proxy.cfg

The image ships no default or shared credentials. Check the file permissions: the credentials file is 0600 root:root, and the proxy passwd file stores a crypt hash rather than the plaintext password.

sudo stat -c '%n %a %U:%G' /root/3proxy-credentials.txt
sudo stat -c '%n %a %U:%G' /etc/3proxy/passwd
sudo sed -E 's/(:CR:.{6}).*/\1********/' /etc/3proxy/passwd

By default only loopback and RFC1918 private ranges are allowed. Remote clients on the public internet are denied even with valid credentials.

To allow a client range, add an allow line above the final deny * in /etc/3proxy/3proxy.cfg and reload the service. Replace <your-mgmt-cidr> with your own client network:

sudo sed -i '/^deny \*/i allow * <your-mgmt-cidr>' /etc/3proxy/3proxy.cfg
sudo systemctl reload 3proxy

Keep the deny * line last so that anything not explicitly allowed is refused.

Users are stored with crypt-hashed passwords. Generate the hash with openssl passwd, append a user:CR:<hash> line to /etc/3proxy/passwd, then reload. Replace <new-password> with a strong password:

HASH=$(openssl passwd -1 '<new-password>')
echo "teammate:CR:$HASH" | sudo tee -a /etc/3proxy/passwd >/dev/null
sudo systemctl reload 3proxy

From a client machine on an allowed range, point your tools at the proxy. Read the username and password from /root/3proxy-credentials.txt, and replace <public-ip> with your VM's public IP. For example, with curl:

curl -x http://<public-ip>:3128 -U 'PROXY_USERNAME:PROXY_PASSWORD' https://ifconfig.me

Alternatively, set the standard environment variables so that most command-line tools use the proxy:

export http_proxy="http://PROXY_USERNAME:PROXY_PASSWORD@<public-ip>:3128"
export https_proxy="$http_proxy"

Replace PROXY_USERNAME and PROXY_PASSWORD with the values from /root/3proxy-credentials.txt.

Restrict the NSG. Allow TCP 3128 (and 1080 for SOCKS) only from the client networks that need the proxy. Allow TCP 22 for administration only.

Keep authentication mandatory. The image ships auth strong. Never remove it, or the proxy becomes an open relay.

Scope the access control list. Add only the specific client ranges you need above the final deny *. Do not use allow * from any source.

Keep CONNECT restricted to TLS ports so the proxy cannot be abused to tunnel to mail or arbitrary ports.

Rotate credentials by editing /etc/3proxy/passwd and reloading. The plaintext of the original per-VM password lives only in /root/3proxy-credentials.txt.

Keep the OS patched. Unattended security upgrades remain enabled on the running VM.

3proxy is developed by the 3proxy project and distributed under the 3proxy Public License Agreement, a permissive BSD-style licence. The software is additionally available under the Apache 2.0, GPL and LGPL licences at your option. This image builds the unmodified upstream 3proxy 0.9.7 source.

SecureAnyCloud provides the packaging, the secure default configuration, the per-VM credential automation, security patching, and 24/7 support with a guaranteed 24-hour response SLA.

SecureAnyCloud is not affiliated with or endorsed by the 3proxy project. 3proxy is a mark of its respective owner and is used here only to identify the software.

Deploy on Azure

Find 3proxy Proxy Server on Ubuntu 24.04 LTS on the Azure Marketplace, published by SecureAnyCloud. Deploy from the Portal or the Azure CLI as shown above.

Need Help?

Email sales@secureanycloud.com for deployment help, configuration questions or licensing enquiries.

Deploy on Azure

Launch 3proxy 0.9.7 on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Find 3proxy on AWS Marketplace, published by SecureAnyCloud. Choose Continue to Subscribe, then Continue to Configuration and Continue to Launch.

Select the Ubuntu 24.04 delivery option, your instance type (m5.large) and your key pair. Choose a security group that allows TCP 22 for administration, plus TCP 3128 and TCP 1080 from the client networks you want to serve.

SSH in with your EC2 key pair, using the login user for the OS variant you launched.

OS variant SSH login user Example

Ubuntu 24.04 ubuntu ssh -i your-key.pem ubuntu@<public-ip>

ssh -i your-key.pem ubuntu@<public-ip>

On first boot the image generates a per-instance proxy username and password. It writes them to the crypt-hashed /etc/3proxy/passwd and the root-only /root/3proxy-credentials.txt. It also resolves the instance public IP through EC2 instance metadata for the credentials note, and then systemd starts the proxy. This completes within a minute.

Confirm the service is active and listening on both proxy ports:

sudo systemctl start 3proxy.service 2>/dev/null || true sleep 1
sudo systemctl is-active 3proxy.service ss -tln | grep -E ':(3128|1080)' ps -o user=,comm= -C 3proxy

The service reports active, ports 3128 and 1080 are listening, and the process runs as the unprivileged proxy3 user.

The per-instance username and password live in a root-only file. Read the file over SSH:

sudo cat /root/3proxy-credentials.txt

The file holds PROXY_USERNAME and PROXY_PASSWORD for this instance, along with the proxy endpoints and an example command. These values are unique to this instance. They are generated on first boot and never baked into the image.

From an allowed client, point any HTTP client at the proxy on port 3128 and use the per-instance credentials.

The example below runs on the instance itself, where a loopback client is always allowed. It reads the credentials straight from the file, so it proves a real authenticated forward-proxy hop over both HTTP and HTTPS:

sudo systemctl start 3proxy.service 2>/dev/null || true sleep 1
U=$(sudo grep '^PROXY_USERNAME=' /root/3proxy-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^PROXY_PASSWORD=' /root/3proxy-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'HTTP via proxy: %{http_code}\n' -x "http://$U:$P@127.0.0.1:3128" http://example.com
curl -s -o /dev/null -w 'HTTPS via proxy: %{http_code}\n' -x "http://$U:$P@127.0.0.1:3128" https://example.com

Both requests return 200, which shows the traffic was carried end to end through the proxy.

From your own machine, the equivalent command uses the instance public IP. Run it once you have widened the access control list (Step 7) and opened the port in the security group:

curl -x http://<user>:<pass>@<public-ip>:3128 https://ifconfig.me

For a SOCKS client, use port 1080 with the same username and password.

Authentication is enforced. An anonymous request, or one with the wrong password, is rejected with HTTP 407 and carries no traffic:

sudo systemctl start 3proxy.service 2>/dev/null || true sleep 1
U=$(sudo grep '^PROXY_USERNAME=' /root/3proxy-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'anonymous: HTTP %{http_code}\n' -x "http://127.0.0.1:3128" http://example.com
curl -s -o /dev/null -w 'wrong password: HTTP %{http_code}\n' -x "http://$U:wrongpass@127.0.0.1:3128" http://example.com

Both print 407. The default access control list also permits only authenticated clients from loopback and the private RFC1918 ranges, so the image never ships as an open proxy.

By default only clients on loopback and the private RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are allowed.

To serve a client outside those ranges, add an allow rule for your own client CIDR above the final deny * in /etc/3proxy/3proxy.cfg. Edit the file (for example with sudo nano /etc/3proxy/3proxy.cfg) so the access control section reads:

# Authenticated clients from the private ranges (default) plus your own CIDR allow * 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 allow * 203.0.113.0/24
# <-- your client CIDR deny *

Reload the service to apply the change without dropping existing connections:

sudo systemctl reload 3proxy

Then open the matching port (3128 and/or 1080) to your client CIDR in the instance security group. Keep the rules as tight as your use case allows: widen to specific client networks, not to 0.0.0.0/0.

• Per-instance credentials. The username and password are generated on first boot. The plaintext copy in /root/3proxy-credentials.txt is 0600 root:root. The proxy reads a crypt-hashed copy from /etc/3proxy/passwd (0640 root:proxy3).
• HTTPS CONNECT is restricted to the standard TLS ports (443 and 563), so the proxy cannot tunnel to arbitrary ports such as mail relays.
• Least privilege. 3proxy runs under systemd as the unprivileged proxy3 user with NoNewPrivileges, ProtectSystem, ProtectHome and PrivateTmp hardening.
• Logs are written to /var/log/3proxy/ with daily rotation and 30-day retention.
• Add more users by appending further user:CR:hash lines to /etc/3proxy/passwd and reloading the service. Generate each hash with openssl passwd -1.

sudo systemctl status 3proxy.service --no-pager

After a configuration change, reload with sudo systemctl reload 3proxy or restart with sudo systemctl restart 3proxy. The service is enabled at boot.