3proxy HTTP, HTTPS and SOCKS Proxy Server on AWS User Guide

Overview

This guide covers the deployment and configuration of 3proxy on AWS using cloudimg AWS Marketplace images. 3proxy is a lightweight, tiny proxy server that provides HTTP and HTTPS forward proxying and a SOCKS4/5 proxy in a single small daemon.

The image builds the official 3proxy binary (pinned at build from the upstream release) and runs it under systemd as the unprivileged proxy3 user, so a working proxy endpoint is listening within minutes of launch. The HTTP and HTTPS forward proxy listens on port 3128 and the SOCKS proxy on port 1080.

Security by design - no baked password. There is no default password inside the image. A unique proxy username and password are generated on this instance's first boot and written into the proxy's crypt-hashed password file and a root-only credentials file. Proxy authentication is enforced, so an anonymous or wrong-password request is rejected with HTTP 407 and carries no traffic.

Security by design - not an open relay. The default access control list allows authenticated clients only from loopback and the private RFC1918 ranges, followed by a deny-all rule. HTTPS CONNECT tunnelling is restricted to the standard TLS ports (443 and 563), so the proxy cannot be abused to reach arbitrary destinations. To serve clients outside the private ranges you widen the access control list to your own client CIDR and open the matching port in your security group - both deliberate, documented steps.

What is included:

• 3proxy 0.9.7 (official binary, built and pinned at build time), run under systemd as the unprivileged proxy3 user (3proxy.service)

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

• A per-instance proxy username and password, generated on first boot and never baked into the image

• A secure-by-default configuration: authentication enforced, access restricted to private client ranges with a deny-all default, and HTTPS CONNECT limited to standard TLS ports

• Unattended security upgrades left enabled so the server keeps receiving patches

Prerequisites

• Active AWS account, an EC2 key pair, a VPC and subnet in the target region

• Subscription to the 3proxy listing on AWS Marketplace

• A security group allowing TCP 22 (admin) and, from the clients you intend to serve, TCP 3128 (HTTP/HTTPS proxy) and TCP 1080 (SOCKS)

Recommended instance type: m5.large (2 vCPU, 8 GB RAM). Light proxying runs comfortably; busy proxies can move to a larger instance type.

Step 1: Launch from AWS Marketplace

Find 3proxy on AWS Marketplace, published by cloudimg, and choose Continue to Subscribe, then Continue to Configuration and Continue to Launch. Select the Ubuntu 24.04 delivery option, your instance type (m5.large), your key pair, and a security group that allows TCP 22 for administration plus TCP 3128 and TCP 1080 from the client networks you want to serve.

Step 2: Connecting to your instance

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

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

Step 3: First boot

On first boot the image generates a per-instance proxy username and password (written to the crypt-hashed /etc/3proxy/passwd and the root-only /root/3proxy-credentials.txt), resolves the instance public IP via 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.

Step 4: Retrieve your proxy credentials

The per-instance username and password live in a root-only file. Read them 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 and were generated on first boot - they are never baked into the image.

Step 5: Send traffic through the proxy

From an allowed client, point any HTTP client at the proxy on port 3128 using the per-instance credentials. The example below runs on the instance itself (a loopback client is always allowed) and 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: the traffic was carried end-to-end through the proxy.

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

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

For a SOCKS client, point it at port 1080 with the same username and password.

Step 6: The proxy is not an open relay

Authentication is enforced. An anonymous request, or one presenting 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. Combined with the default access control list, which only permits authenticated clients from loopback and the private RFC1918 ranges, this means the image is never shipped as an open proxy.

Step 7: Allow your own clients

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, then reload the service. 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 *

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.

Step 8: Security and configuration notes

• 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 (generate a hash with openssl passwd -1) and reloading the service.

Step 9: Managing the service

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

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

Support

This image is published and supported by cloudimg. For assistance, contact cloudimg support through the AWS Marketplace listing. 3proxy is distributed under a BSD-style permissive license; cloudimg is not affiliated with or endorsed by the 3proxy project.