3proxy Proxy Server on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of 3proxy on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. 3proxy is a small, fast and feature rich proxy server that speaks HTTP, HTTPS and SOCKS from a single lightweight daemon. It lets you route outbound web traffic through one controlled gateway, with access control lists, per user authentication and detailed logging.

The image builds 3proxy 0.9.7 from the pinned upstream source (github.com/z3APA3A/3proxy tag 0.9.7), so the exact version is reproducible and there is no third party package repository on the running VM. 3proxy runs under systemd as the unprivileged proxy3 user. Unattended security upgrades keep the base OS patched.

Secure by design — no default credentials. A proxy that anyone can use anonymously is an open relay, so this image never ships a fixed or shared credential. On the very first boot of every VM a fresh per instance proxy username and password are generated, the password is stored as a crypt hash in /etc/3proxy/passwd, and the plaintext is written to /root/3proxy-credentials.txt (mode 0600, root only). Proxy authentication is mandatory (auth strong), so anonymous or wrong credential requests are rejected with HTTP 407.

Locked down by default. Access is restricted to authenticated clients on loopback and RFC1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and the CONNECT method is limited to TLS ports (443, 563) so the proxy cannot be abused to tunnel to arbitrary ports such as mail relays. You widen access to your own client ranges with one config edit.

What is included:

• 3proxy 0.9.7 built from the pinned upstream source, run under systemd as the unprivileged proxy3 user (3proxy.service)

• An HTTP/HTTPS forward proxy on TCP 3128 and a SOCKS4/5 proxy on TCP 1080

• Mandatory proxy authentication (auth strong) against a per instance user, so anonymous requests get HTTP 407

• A per instance username and password generated on first boot, documented in /root/3proxy-credentials.txt (0600)

• A secure default access control list: authenticated clients from loopback and private ranges only, with a deny all default and CONNECT restricted to TLS ports

Prerequisites

• Active Azure subscription, SSH public key, VNet + subnet in target region

• Subscription to the 3proxy listing on Azure Marketplace

• Network Security Group rules allowing TCP 22 (admin) and, for the clients that will use the proxy, TCP 3128 (HTTP/HTTPS proxy) and/or TCP 1080 (SOCKS)

Recommended virtual machine size: Standard_B2s (2 vCPU, 4 GB RAM) for a small proxy. Higher throughput deployments should use Standard_D2s_v5 or larger.

Step 1: Deploy from the Azure Portal

Search 3proxy in Marketplace, select the cloudimg publisher, and click Create. Configure the Network Security Group to allow TCP 3128 (and/or TCP 1080 for SOCKS) from your client networks, and TCP 22 for administration.

Step 2: Deploy from the Azure CLI

RG="proxy-prod"; LOCATION="eastus"; VM_NAME="proxy1"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/3proxy-ubuntu-24-04/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$GALLERY_IMAGE_ID" \
  --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

Step 3: First boot

On first boot the image generates a fresh per instance 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

Step 4: Confirm the service is running

3proxy.service runs under systemd as the unprivileged proxy3 user. ss confirms 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 '

Step 5: The proxy requires authentication

The proxy rejects anonymous and wrong credential requests with HTTP 407, and accepts the correct per instance credentials. Read your credentials from the file into shell variables, then prove 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

Step 6: Proxy HTTPS and use the SOCKS port

The same credentials authenticate HTTPS requests (tunnelled with the CONNECT method to TLS port 443) and the SOCKS proxy 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

Step 7: Review the secure by default configuration

The configuration ships mandatory authentication (auth strong), an access control list that allows authenticated clients from loopback and RFC1918 private ranges only, a deny * default, and CONNECT restricted to TLS ports.

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

Step 8: Confirm no default credentials ship

No default or shared credentials ship in the image. 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

Step 9: Allow your own remote clients

By default only loopback and RFC1918 private ranges are allowed, so 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 anything not explicitly allowed is refused.

Step 10: Add another proxy user

Add users with a crypt hashed password. Generate the hash with openssl passwd and 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

Step 11: Configure a client to use the proxy

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

Or set the standard environment variables so 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.

Step 12: Security recommendations

• Restrict the NSG. Allow TCP 3128 (and 1080 for SOCKS) only from the client networks that need the proxy, and 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.

Step 13: Support and Licensing

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 cloudimg image builds the unmodified upstream 3proxy 0.9.7 source. cloudimg provides the packaging, the secure default configuration, the per instance credential automation, security patching, and 24/7 support with a guaranteed 24 hour response SLA.

cloudimg 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 cloudimg. Deploy from the Portal or the Azure CLI as shown above.

Need Help?

Email support@cloudimg.co.uk for deployment help, configuration questions, or licensing enquiries.