3P
Networking AWS

3proxy Proxy Server 0.9.9.1 on AWS User Guide

| Product: 3proxy Proxy Server 0.9.9.1 on Ubuntu 24.04 on AWS

Overview

This guide covers launching and verifying 3proxy Proxy Server 0.9.9.1 on Ubuntu 24.04 from cloudimg on Amazon EC2. It is one version of the cloudimg Hardened WireGuard VPN & VPN, Proxy and Remote Access AMIs listing on AWS Marketplace; you pick it as the software version when you subscribe and launch. The other VPN, proxy and remote access servers in the listing are described on the listing's guide hub.

3proxy is a small, fast proxy server with two front ends in one process: an HTTP/HTTPS forward proxy and a SOCKS4/4.5/5 proxy. Use it to give instances in private subnets controlled outbound access, to put one egress address in front of a group of hosts, or to route tools that only speak SOCKS (SSH, database clients, browsers) through a single audited point. It has no database and no web console: it is configured with one text file.

Version 0.9.9.1 is the current release of upstream's maintained 0.9.9.x LTS branch. It includes the fixes for the three 3proxy security advisories published after 0.9.7: GHSA-pw82-qqrx-wjcr (RADIUS request buffer overflow), GHSA-m528-xhxv-r446 (use-after-free in the HTTP proxy on ftp:// requests) and GHSA-4hjh-799h-mgqh (SMTP proxy buffer overflow). The image compiles it from the upstream release tarball, pinned by its signed SHA-256 checksum, and removes the compiler afterwards. Unattended security upgrades stay on for the operating system.

What is on the image:

  • 3proxy 0.9.9.1 (3proxy.service) running as the unprivileged proxy3 user, with exactly two listeners: HTTP/HTTPS proxy on TCP 3128 and SOCKS proxy on TCP 1080
  • Authentication on both ports with a user and password generated on your instance's first boot; only a salted hash of the password is stored in the 3proxy configuration
  • A not an open proxy policy: only the instance itself and private (RFC 1918) client addresses are served
  • No SSRF into your network: the proxy refuses loopback, private, link-local (instance metadata), CGNAT and multicast destinations, including host names that resolve to them
  • HTTPS tunnelling (CONNECT) limited to ports 443 and 563, nothing to SMTP port 25, no SOCKS BIND or UDP relay, no admin web interface
  • A self-test, /usr/local/sbin/3proxy-roundtrip.sh

Default user: ubuntu · Architecture: x86_64 · Root volume: 8 GiB gp3

Security posture

An open proxy on the internet is found within hours and abused for spam, credential stuffing and hiding attack traffic, and a proxy inside a VPC is a ready-made SSRF tool against everything private around it. This image closes both by default:

  • Authentication is mandatory on every port. 3proxy runs with auth strong: every HTTP request and every SOCKS connection must carry this instance's user and password. With no credentials or a wrong password the HTTP proxy answers 407 and SOCKS refuses the connection. No credential ships in the image, so no two instances share one.
  • Only the password hash is in the configuration. /etc/3proxy/passwd holds a salted BLAKE2b hash (3proxy's $3$ format); the plaintext is only in /root/3proxy-credentials.txt, readable by root alone. The password is never written to a log.
  • Private clients only. The access list serves this instance's user from 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 and ends in deny *. A request from any other address is refused with HTTP 403 even with the right password.
  • The listing security group opens SSH only. Ports 3128 and 1080 stay closed until you open them to your own VPC or client networks, or you reach them through an SSH tunnel. Clients use the instance's private IP.
  • No SSRF. A proxy connects wherever a client asks, so the access list refuses every destination in 0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/3 and the IPv6 loopback, ULA, link-local and mapped ranges. Rules match the resolved address, so http://localhost/ or a DNS name pointing into your VPC is refused too.
  • The metadata service is walled off twice. On top of the access list, both 3proxy.service and its first-boot unit carry a systemd IPAddressDeny for 169.254.169.254, fd00:ec2::254 and 168.63.129.16, so even a configuration mistake cannot let the proxy read the instance's IAM role credentials. Amazon Time Sync (169.254.169.123) still works.
  • IMDSv2 required. The AMI is registered with ImdsSupport v2.0, so instances launched from it refuse token-less (IMDSv1) metadata requests.
  • Fails closed. 3proxy starts only after first boot has written the password hash and a ready marker, and a start-up check refuses to run it without auth strong, without the destination denies, with an allow * or 0.0.0.0/0 rule, or with any extra service such as the admin interface. If first boot cannot finish, the proxy stays stopped and first boot tries again on the next boot.
  • Per-instance identity. SSH host keys and the machine ID are generated fresh on every instance.

Prerequisites

  1. An AWS account and permission to launch EC2 instances
  2. An EC2 key pair in the Region you launch in
  3. A VPC subnet for the proxy, and the CIDR ranges of the clients that will use it

Recommended instance type: m5.large. A small proxy for a handful of clients runs comfortably on t3.small or larger.

Connecting to your instance

Version Operating system SSH user
3proxy Proxy Server 0.9.9.1 on Ubuntu 24.04 Ubuntu 24.04 LTS ubuntu

Step 1: Launch the instance

Option A: AWS Marketplace console

  1. Open the cloudimg Hardened WireGuard VPN & VPN, Proxy and Remote Access AMIs listing on AWS Marketplace and choose View purchase options, then Subscribe. One subscription covers every version in the listing.
  2. Once the subscription is active, choose Launch your software.
  3. Choose One-click launch from AWS Marketplace (or Launch from EC2 Console for the full launch wizard). In Version, choose 3proxy Proxy Server 0.9.9.1 on Ubuntu 24.04, then choose your Region.
  4. Pick an instance type (m5.large recommended; the software charge is $0.04 per vCPU per hour) and your key pair.
  5. Security group: the listing's default group allows SSH (22) only. Restrict it to your own IP address. You will open the proxy ports to your clients in Step 5.
  6. Choose your VPC and subnet, leave the metadata defaults (the image already requires IMDSv2), then choose Launch.

Option B: AWS CLI

Run this on your own workstation. It creates a security group that allows SSH from your management address and the two proxy ports from your VPC only, then launches the instance. Replace the AMI ID with the one shown for your Region on the Marketplace launch page, and the VPC, subnet, key pair and CIDR ranges with your own:

SG=$(aws ec2 create-security-group --group-name 3proxy \
  --description "3proxy HTTP and SOCKS proxy" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 22 --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 3128 --cidr 10.0.0.0/16
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 1080 --cidr 10.0.0.0/16
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=3proxy}]'

You do not need --metadata-options: the AMI already makes IMDSv2 required.

Step 2: Connect and read the credentials

Connect as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot finishes within a minute of launch. It generates this instance's proxy user and password, stores the password hash for 3proxy, records the instance's private IP, starts the proxy and runs the self-test. The details are in /root/3proxy-credentials.txt, readable only by root. This command prints everything except the password line:

sudo grep -v '^proxy\.pass=' /root/3proxy-credentials.txt

# 3proxy 0.9.9.1 on Ubuntu 24.04 (cloudimg AWS Marketplace image) - THIS instance.
# The user and password below were generated on this instance's first boot and exist nowhere else
# (3proxy itself keeps only a salted hash of the password, in /etc/3proxy/passwd).
proxy.user=cloudimg22bff3
proxy.host=172.31.83.46
proxy.http_port=3128
proxy.socks_port=1080
proxy.http_endpoint=172.31.83.46:3128
proxy.socks_endpoint=172.31.83.46:1080
#
# NOT AN OPEN PROXY: both ports require the user and password above (HTTP 407 / SOCKS5 refusal
# without them), only localhost and private (RFC1918) clients are served, and the proxy refuses to
# connect to loopback, private, link-local (instance metadata) and multicast destinations.
#
# NETWORK ACCESS: the listing security group opens SSH only. To serve clients in your VPC, add
# inbound rules for TCP 3128 and/or 1080 ONLY from your VPC CIDR or client security group - never
# 0.0.0.0/0 - and point clients at the PRIVATE IP above. Or use an SSH tunnel:
#   ssh -i <key.pem> -N -L 3128:127.0.0.1:3128 -L 1080:127.0.0.1:1080 ubuntu@<public-ip>
#
# Test from a client:
#   curl -x http://cloudimg22bff3:<password>@172.31.83.46:3128 https://example.com/ -sS -o /dev/null -w '%{http_code}\n'
#   curl -x socks5h://cloudimg22bff3:<password>@172.31.83.46:1080 https://example.com/ -sS -o /dev/null -w '%{http_code}\n'
# Self-test: sudo /usr/local/sbin/3proxy-roundtrip.sh
# User guide: https://www.cloudimg.co.uk/guides/3proxy-proxy-server-0-9-9-1-on-ubuntu-24-04-aws/

Your user name (cloudimg followed by six hex digits) and private IP will differ. Print the password itself only when you need it, with sudo sed -n 's/^proxy\.pass=//p' /root/3proxy-credentials.txt; it is 40 or more characters long.

Step 3: Confirm the proxy is running

3proxy.service is active, first boot has completed, the binary is release 0.9.9.1, and 3proxy is the process listening on ports 1080 and 3128. The security group and the access list decide who can actually use them.

systemctl is-active 3proxy.service 3proxy-firstboot.service
sudo grep -ao '3proxy-0\.9\.9\.1' /usr/local/bin/3proxy | head -1
sudo ss -Htlnp '( sport = :3128 or sport = :1080 )'

active
active
3proxy-0.9.9.1
LISTEN 0      26     0.0.0.0:1080 0.0.0.0:* users:(("3proxy",pid=8306,fd=3))
LISTEN 0      26     0.0.0.0:3128 0.0.0.0:* users:(("3proxy",pid=8306,fd=7))

(Do not run 3proxy without a configuration file to check its version: with no argument it waits for a configuration on standard input.)

Step 4: Run the self-test

The shipped self-test checks the whole security posture in a few seconds and needs no internet access. It starts a small test web server on a documentation address (192.0.2.80, TEST-NET-1) on the loopback interface, and on 127.0.0.1 and the private IP, then proves: the only non-loopback listening ports are 22, 1080 and 3128; over HTTP an anonymous request and a wrong password both get 407 and the instance's password gets 200 with the test page; over SOCKS5 no authentication and a wrong password are refused and the instance's password reaches the test page; and loopback, the private IP, a host name that resolves to 127.0.0.1 and the instance metadata service are all refused by the access list, while the same metadata service answers the instance shell directly.

sudo /usr/local/sbin/3proxy-roundtrip.sh

round-trip OK: listening tcp 22 1080 3128 ; HTTP anonymous 407, wrong password 407, per-instance password 200 (body proxied); SOCKS5 no-auth/wrong refused, authenticated reaches the origin; loopback, private, hostname-to-loopback and instance-metadata destinations refused by the ACL on both (HTTP 403), HTTP CONNECT to a non-TLS port 403; host-shell metadata control 200

Step 5: Open the proxy to your clients

Add inbound rules for TCP 3128 (HTTP) and/or TCP 1080 (SOCKS) to the instance's security group, only from the networks that need the proxy (your VPC CIDR, a subnet, or a client security group). Never open them to 0.0.0.0/0. Even if you did, the access list would refuse every public source, but the rule keeps the ports private at the network edge as well:

aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 3128 --cidr <vpc-cidr>
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 1080 --cidr <vpc-cidr>

Then point clients at the proxy's private IP (proxy.host in the credentials file). On a Linux client, set the standard proxy variables with the user and password from Step 2:

export http_proxy="http://<PROXY_USER>:<PROXY_PASS>@<PROXY_HOST>:3128"
export https_proxy="$http_proxy"
export no_proxy="localhost,127.0.0.1,169.254.169.254"
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

Keep 169.254.169.254 in no_proxy on the clients, so each client reads its own instance metadata directly (the proxy would refuse it). For SOCKS-aware tools, use socks5h://<PROXY_USER>:<PROXY_PASS>@<PROXY_HOST>:1080; the h makes the proxy resolve host names, so its destination rules see the real address.

Using the proxy from your workstation through SSH

To use the proxy from a machine outside the VPC without opening 3128 or 1080 at all, forward them over SSH and point your browser or tools at 127.0.0.1:3128 or 127.0.0.1:1080 (requests then reach 3proxy from 127.0.0.1, which the access list serves; the password is still required):

ssh -i ~/.ssh/my-key-pair.pem -N -L 3128:127.0.0.1:3128 -L 1080:127.0.0.1:1080 ubuntu@<public-ip>

Step 6: Make requests through the proxy

On the instance, these requests show authentication at work on both ports: no credentials and a wrong password (407 over HTTP; curl exit 97, a SOCKS refusal, over SOCKS), and the instance's credentials over plain HTTP, HTTPS through CONNECT, and HTTPS through SOCKS5. The credentials reach curl on standard input (-K -), so they never appear in a process listing or your shell history.

PU="$(sudo sed -n 's/^proxy\.user=//p' /root/3proxy-credentials.txt)"
PP="$(sudo sed -n 's/^proxy\.pass=//p' /root/3proxy-credentials.txt)"
curl -s -o /dev/null -w 'no credentials:        HTTP %{http_code}\n' -x http://127.0.0.1:3128 http://example.com/
printf 'proxy-user = "%s:wrong-password"\n' "$PU" | curl -K - -s -o /dev/null -w 'wrong password:        HTTP %{http_code}\n' -x http://127.0.0.1:3128 http://example.com/
printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -o /dev/null -w 'HTTP proxy, http:      HTTP %{http_code}\n' -x http://127.0.0.1:3128 http://example.com/
printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -o /dev/null -w 'HTTP proxy, https:     HTTP %{http_code}\n' -x http://127.0.0.1:3128 https://example.com/
printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -o /dev/null -w 'SOCKS5 proxy, https:   HTTP %{http_code}\n' -x socks5h://127.0.0.1:1080 https://example.com/
curl -s -o /dev/null -w 'SOCKS5, no credentials: curl exit %{exitcode}\n' -x socks5h://127.0.0.1:1080 https://example.com/ || true

no credentials:        HTTP 407
wrong password:        HTTP 407
HTTP proxy, http:      HTTP 200
HTTP proxy, https:     HTTP 200
SOCKS5 proxy, https:   HTTP 200
SOCKS5, no credentials: curl exit 97

Step 7: Review the access list

The rules are checked top to bottom and the first match wins: authentication, then the destinations that are never served, then the abuse limits, then the one allow for this instance's user from private sources, then deny *. The files that hold the user and the password hash are readable only by root and the proxy3 group:

sudo grep -E '^(users|auth|deny|allow|proxy|socks) ' /etc/3proxy/3proxy.cfg
sudo stat -c '%a %U:%G %n' /etc/3proxy/3proxy.cfg /etc/3proxy/passwd /etc/3proxy/allowed-users /root/3proxy-credentials.txt
sudo sed -E 's/(CR:\$3\$)[^$]+\$.*/\1<salt>$<hash>"/' /etc/3proxy/passwd

users $/etc/3proxy/passwd
auth strong
deny * * 0.0.0.0/8,10.0.0.0/8,100.64.0.0/10,127.0.0.0/8,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16,224.0.0.0/3,168.63.129.16/32
deny * * ::/128,::1/128,::ffff:0:0/96,fc00::/7,fd00::/8,fe80::/10,ff00::/8
deny * * * 25
deny * * * 1-442,444-562,564-65535 HTTPS
deny * * * * BIND,UDPASSOC
allow $/etc/3proxy/allowed-users 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
deny *
proxy -a -4 -i0.0.0.0 -p3128
socks -4 -i0.0.0.0 -p1080
640 root:proxy3 /etc/3proxy/3proxy.cfg
640 root:proxy3 /etc/3proxy/passwd
640 root:proxy3 /etc/3proxy/allowed-users
600 root:root /root/3proxy-credentials.txt
"cloudimg22bff3:CR:$3$<salt>$<hash>"

proxy -a also removes the Via and X-Forwarded-For headers, so the sites your clients visit do not learn their private addresses.

Step 8: Private and metadata destinations are refused

With the correct password, requests for the instance metadata service, for loopback, for the instance's own private IP and for a host name that resolves to loopback (localhost) are all refused by the access list with HTTP 403, while the metadata service still answers the instance shell directly. The systemd metadata block sits behind the access list on both units:

PU="$(sudo sed -n 's/^proxy\.user=//p' /root/3proxy-credentials.txt)"
PP="$(sudo sed -n 's/^proxy\.pass=//p' /root/3proxy-credentials.txt)"
PH="$(sudo sed -n 's/^proxy\.host=//p' /root/3proxy-credentials.txt)"
for url in http://169.254.169.254/latest/meta-data/ http://127.0.0.1:22/ "http://${PH}:22/" http://localhost:22/; do
  printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -m 10 -o /dev/null -w "%{http_code}  ${url}\n" -x http://127.0.0.1:3128 "$url" || true
done
curl -s -m 5 -o /dev/null -w 'metadata from the shell: HTTP %{http_code} (IMDSv2 token request)\n' -X PUT -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' http://169.254.169.254/latest/api/token
systemctl show -p IPAddressDeny 3proxy.service 3proxy-firstboot.service

403  http://169.254.169.254/latest/meta-data/
403  http://127.0.0.1:22/
403  http://172.31.83.46:22/
403  http://localhost:22/
metadata from the shell: HTTP 200 (IMDSv2 token request)
IPAddressDeny=fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32

IPAddressDeny=fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32

Step 9: Confirm it is not an open proxy

To see the refusal of a public source for yourself, this block adds a documentation-range address (192.0.2.88, TEST-NET-1) to the loopback interface for a moment, sends a request from it with the correct password, and removes the address again. 3proxy answers 403 because the source is not private; the same request from 127.0.0.1 succeeds:

PU="$(sudo sed -n 's/^proxy\.user=//p' /root/3proxy-credentials.txt)"
PP="$(sudo sed -n 's/^proxy\.pass=//p' /root/3proxy-credentials.txt)"
sudo ip addr add 192.0.2.88/32 dev lo
printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -o /dev/null -w 'from 192.0.2.88 (public): HTTP %{http_code}\n' --interface 192.0.2.88 -x http://192.0.2.88:3128 http://example.com/
printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -o /dev/null -w 'from 127.0.0.1 (local):   HTTP %{http_code}\n' --interface 127.0.0.1 -x http://127.0.0.1:3128 http://example.com/
sudo ip addr del 192.0.2.88/32 dev lo

from 192.0.2.88 (public): HTTP 403
from 127.0.0.1 (local):   HTTP 200

Step 10: How the fail-closed start works

3proxy.service only starts once first boot has written /var/lib/cloudimg/3proxy-ready, and its start-up check (ExecStartPre, run as root) re-reads the configuration every time. Both units carry the metadata block drop-in. The request log records one line per request (time, service, result code, user, client, destination and bytes), never a password or a URL:

systemctl cat 3proxy.service | grep -E '^(ConditionPathExists|ExecStartPre|ExecStart|User|IPAddressDeny)='
ls /etc/systemd/system/3proxy.service.d/ /etc/systemd/system/3proxy-firstboot.service.d/
sudo bash -c 'tail -n 3 /var/log/3proxy/3proxy.log*' | cut -c1-100

ConditionPathExists=/var/lib/cloudimg/3proxy-ready
User=proxy3
ExecStartPre=+/usr/local/sbin/3proxy-preflight.sh
ExecStart=/usr/local/bin/3proxy /etc/3proxy/3proxy.cfg
IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128
/etc/systemd/system/3proxy-firstboot.service.d/:
50-cloudimg-imds-deny.conf

/etc/systemd/system/3proxy.service.d/:
50-cloudimg-imds-deny.conf
1792453852.288 PROXY.3128 00001 cloudimg22bff3 127.0.0.1:48984 0.0.0.0:0 0 0
1792453861.226 PROXY.3128 00001 cloudimg22bff3 192.0.2.88:58532 0.0.0.0:0 0 0
1792453861.276 PROXY.3128 00000 cloudimg22bff3 127.0.0.1:54500 172.66.147.243:80 98 933

Result code 00000 is a completed request and 00001 a request the access list refused. The log rotates daily (3proxy.log.YYYY.MM.DD) and keeps 30 days. The start-up check, /usr/local/sbin/3proxy-preflight.sh, refuses to start 3proxy if auth strong is missing or weakened, if the loopback, private or link-local destination denies or the final deny * are gone, if an allow line serves any user or the whole internet, if the password file does not hold exactly one $3$ hash for the configured user, or if another service (the admin web interface, a port mapper, a DNS proxy) is added. If you deliberately want a different policy, edit that script rather than removing the check.

Step 11: Change the policy (optional)

Edit /etc/3proxy/3proxy.cfg, then restart 3proxy and run the self-test again (sudo systemctl restart 3proxy && sudo /usr/local/sbin/3proxy-roundtrip.sh). Common changes:

  • Serve another of your own client ranges that is not RFC 1918 (for example a carrier-grade NAT range on a VPN): add it to the source list of the allow line, never 0.0.0.0/0:
allow $/etc/3proxy/allowed-users 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10
  • Let clients reach one internal service through the proxy (for example an internal package mirror): add a specific allow line for that address and port above the destination deny lines. Keep it as narrow as possible and never allow 169.254.0.0/16:
allow $/etc/3proxy/allowed-users 10.0.0.0/8 10.0.5.20 443
  • Allow only a list of destination domains: replace the allow line with one that names the hosts (wildcards at the start or end are allowed), for example allow $/etc/3proxy/allowed-users 10.0.0.0/8 *.amazonaws.com,example.com.

Step 12: Rotate the user and password (optional)

The quickest way to issue a new user and password is to run first boot again. It mints new credentials, rewrites the hash and the credentials file, restarts 3proxy and runs the self-test; the old credentials stop working immediately:

sudo rm /var/lib/cloudimg/3proxy-firstboot.done
sudo systemctl start 3proxy-firstboot.service
sudo grep -v '^proxy\.pass=' /root/3proxy-credentials.txt

Update your clients with the new values. The new password is generated and hashed inside the first-boot unit, so it never appears on a command line or in /var/log/auth.log.

Step 13: Security recommendations

  • Keep TCP 3128 and 1080 open only to the networks that need the proxy, and TCP 22 only to your management addresses. If your clients only need one protocol, open only that port.
  • Keep auth strong and the destination denies. The start-up check enforces them; they are what make a mis-set security group harmless.
  • Restrict destinations (Step 11) if the proxy is the only egress for a private subnet.
  • Ship /var/log/3proxy/ to your log platform.
  • Leave unattended security upgrades on, and reboot after kernel updates.

Support and licensing

3proxy is free software by Vladimir Dubrovin (3APA3A) and 3proxy.org, distributed under the 3proxy 0.9 Public License, a BSD-style licence that also lets you use and redistribute it under the Apache License 2.0, the GNU GPL version 2 or later, or the GNU LGPL version 2.1 or later. The licence text ships on the image at /usr/share/doc/3proxy-cloudimg/copying. This image compiles the unmodified 3proxy 0.9.9.1 release source. cloudimg provides the packaging, the authenticated not an open proxy defaults, the destination and metadata blocks, the fail-closed start, the self-test and 24/7 support.

cloudimg is not affiliated with or endorsed by the 3proxy project. 3proxy is used here only to identify the software.

For help with deployment or configuration, email support@cloudimg.co.uk or visit cloudimg support.