Since version 0.9.7, SSL/TLS support is built into 3proxy when compiled with OpenSSL (WITH_SSL). Previously available as SSLPlugin, the functionality is now integrated into the main binary. The plugin line is no longer required. SSL/TLS support can be used to:

• Create an https:// proxy (TLS-encrypted connection between client and proxy)
• Implement MITM for TLS traffic inspection
• Connect to upstream servers via TLS with client certificate authentication
• Require client certificate authentication (mTLS)

Creating an https:// proxy:
To create an https:// proxy, you need a server certificate and key. The certificate must not be self-signed and should contain Subject Alternative Names (SAN) for the proxy hostname/IP.

ssl_server_cert /etc/3proxy/certs/server.crt
ssl_server_key /etc/3proxy/certs/server.key
ssl_serv
proxy -p3129
ssl_noserv
proxy -p3128

This creates an https:// proxy on port 3129 and an http:// proxy on port 3128. Configure clients to use https://proxy-host:3129/ as the proxy URL.

Client certificate authentication (mTLS):
To require clients to authenticate with a certificate, use ssl_server_verify and provide the CA certificate:

ssl_server_cert /etc/3proxy/certs/server.crt
ssl_server_key /etc/3proxy/certs/server.key
ssl_server_ca_file /etc/3proxy/certs/ca.crt
ssl_server_verify
ssl_serv
proxy -p3129

Only clients with a valid certificate signed by the CA can connect.

MITM for TLS traffic inspection:
To intercept and decrypt TLS traffic, you need a CA certificate to generate spoofed server certificates:

ssl_server_ca_file /etc/3proxy/certs/ca.crt
ssl_server_ca_key /etc/3proxy/certs/ca.key
ssl_client_verify
ssl_client_ca_file /etc/ssl/certs/ca-certificates.crt
ssl_mitm
proxy -p3128
ssl_nomitm
proxy -p3129

The CA certificate must be trusted by clients. ssl_client_verify ensures the real server certificates are validated. Without ssl_client_verify, the proxy is vulnerable to MITM attacks.

TLS client (connect to upstream via TLS):
To connect to upstream servers via TLS with client certificate authentication:

ssl_client_cert /etc/3proxy/certs/client.crt
ssl_client_key /etc/3proxy/certs/client.key
ssl_client_verify
ssl_client_ca_file /etc/ssl/certs/ca-certificates.crt
ssl_cli
proxy -p3128

Conditional TLS for parent proxy (ssl_client_mode 3):
With ssl_client_mode 3, TLS handshake to parent proxy is performed only if the parent type ends with 's' (secure types). This allows mixing secure and non-secure parent proxies in the same configuration:

ssl_server_cert /etc/3proxy/certs/server.crt
ssl_server_key /etc/3proxy/certs/server.key
ssl_client_mode 3

auth strong
allow user1
parent 1000 https parent1.example.com 443
allow user2
parent 1000 socks5 parent2.example.com 1080
ssl_serv
ssl_cli
proxy -p3128
ssl_noserv
ssl_nocli

This creates an HTTPS proxy (ssl_serv) that accepts TLS connections from clients. For parent proxy connections, user1's traffic goes through an https parent with TLS encryption (secure type), while user2's traffic goes through a regular socks5 parent without TLS. Secure parent types include: tcps, https, connects, connect+s, socks4s, socks5s, socks4+s, socks5+s, pop3s, smtps, ftps.

Creating a Certificate Authority (CA):
For MITM or mTLS, you need a CA. Generate a CA private key and certificate:

# Generate CA private key
openssl genrsa -out ca.key 4096

# Extensions that make the certificate usable as a CA
cat > ca.ext << 'EOF'
basicConstraints=critical,CA:TRUE
keyUsage=critical,keyCertSign,cRLSign
subjectKeyIdentifier=hash
EOF

# Generate CA certificate (valid for 10 years)
openssl req -new -nodes -key ca.key \
    -subj "/C=US/ST=State/L=City/O=MyOrg/CN=My CA" \
    -out ca.csr
openssl x509 -req -in ca.csr -signkey ca.key -sha256 -days 3650 \
    -extfile ca.ext -out ca.crt

The extensions are not optional. Without basicConstraints=CA:TRUE and keyCertSign the certificate is not accepted as a CA, and clients report that they cannot get the local issuer certificate. subjectKeyIdentifier is what certificates signed by this CA point back at.

They are given in a file rather than with -addext because LibreSSL, the openssl command on macOS and some BSDs, does not apply -addext the same way OpenSSL does. The form above behaves the same on both.

For MITM, import ca.crt into client browsers/OS as a trusted root CA.

Creating a server certificate for https:// proxy:
The server certificate must have proper Subject Alternative Names (SAN):

# Generate server private key
openssl genrsa -out server.key 2048

# Create a certificate signing request (CSR)
openssl req -new -key server.key \
    -subj "/C=US/ST=State/L=City/O=MyOrg/CN=proxy.example.com" \
    -out server.csr

# Create extensions file for SAN
cat > server.ext << 'EOF'
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = proxy.example.com
DNS.2 = proxy
IP.1 = 192.168.1.100
EOF

# Sign the certificate with CA
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
    -CAcreateserial -out server.crt -days 365 -sha256 \
    -extfile server.ext

# Check it the way a current client will
openssl verify -x509_strict -CAfile ca.crt server.crt

Verify strictly, because that is what the client does. OpenSSL 3 adds the subject and authority key identifiers when it signs and LibreSSL does not, which is why the extensions file asks for them by name. Python has verified strictly since 3.13 and refuses a certificate carrying no authorityKeyIdentifier; other clients are moving the same way.

For a public https:// proxy, use a CA like Let's Encrypt instead of self-signed.

Creating a client certificate for mTLS:

# Generate client private key
openssl genrsa -out client1.key 2048

# Create CSR
openssl req -new -key client1.key \
    -subj "/C=US/ST=State/L=City/O=MyOrg/CN=client1" \
    -out client1.csr

# Create extensions file
cat > client.ext << 'EOF'
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment
extendedKeyUsage = clientAuth
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
EOF

# Sign with CA
openssl x509 -req -in client1.csr -CA ca.crt -CAkey ca.key \
    -CAcreateserial -out client1.crt -days 365 -sha256 \
    -extfile client.ext

# Create PKCS#12 bundle for browser import
openssl pkcs12 -export -out client1.p12 \
    -inkey client1.key -in client1.crt -certfile ca.crt

Import client1.p12 into the client browser or OS certificate store.

Quick setup script for development/testing:

#!/bin/sh
# Creates CA, server, and client certificates for SSLPlugin testing

# CA
openssl genrsa -out ca.key 4096
cat > ca.ext << 'EOF'
basicConstraints=critical,CA:TRUE
keyUsage=critical,keyCertSign,cRLSign
subjectKeyIdentifier=hash
EOF
openssl req -new -nodes -key ca.key -subj "/CN=3proxy CA" -out ca.csr
openssl x509 -req -in ca.csr -signkey ca.key -sha256 -days 3650 \
    -extfile ca.ext -out ca.crt

# Server
openssl genrsa -out server.key 2048
openssl req -new -key server.key -subj "/CN=localhost" -out server.csr
cat > server.ext << 'EOF'
basicConstraints=CA:FALSE
keyUsage = keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:localhost,DNS:proxy,IP:127.0.0.1
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
EOF
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
    -CAcreateserial -out server.crt -days 365 -sha256 -extfile server.ext

# Client
openssl genrsa -out client.key 2048
openssl req -new -key client.key -subj "/CN=client" -out client.csr
cat > client.ext << 'EOF'
basicConstraints=CA:FALSE
extendedKeyUsage = clientAuth
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
    -CAcreateserial -out client.crt -days 365 -sha256 -extfile client.ext
openssl pkcs12 -export -out client.p12 -passout pass: \
    -inkey client.key -in client.crt -certfile ca.crt

# Both must pass the checks a current client applies
openssl verify -x509_strict -CAfile ca.crt server.crt
openssl verify -x509_strict -CAfile ca.crt client.crt

A transparent proxy serves clients that were never configured to use one. A packet filter redirects their connections to 3proxy, and the transparent command tells the service to take the destination from the filter instead of from the request. Every other feature applies as usual: access rules, parent proxies, limits and logging all see the real destination. It works on Linux and on the BSDs. Since 1.0.1 it is part of the binary; before that it was the separate TransparentPlugin, and the plugin line it needed is no longer required.

The command supplies both the address and the port the client was trying to reach, so a service can serve whatever was redirected to it rather than one port with one target.

Without it a service has to get a destination from somewhere else: an HTTP proxy falls back to the Host header, and a port mapper uses the address it was configured with. Taking the destination from the filter is what makes the other protocols work, and what makes the address authoritative rather than something the client claimed.

tlspr is the clearest case. Nothing reaches it at all unless traffic is redirected to it, or the clients resolve the names to it through DNS. With a redirection it gets the address as well as the name from the handshake, and that is what lets access rules be written with host names: the name from the handshake is matched, and the connection still goes to the address the client was going to. Without the address it would have to resolve the name itself, which is a second lookup and a second answer.

A configuration for web and TLS traffic:

log /var/log/3proxy.log D
auth iponly
allow *

# the destination comes from the redirection for the services below
transparent

# ordinary web traffic, redirected here from port 80
proxy -p3129 -e192.0.2.10

# TLS, redirected here from port 443: tlspr would otherwise have only the
# name in the handshake, and this gives it the address as well
tlspr -p3143 -e192.0.2.10

notransparent

-e gives those services an address of their own to connect from. That address is what the redirection rules exclude, and excluding it is what stops the proxy's own connections from being redirected back into it. Without an exclusion the connection 3proxy makes to the origin matches the same rule, returns to 3proxy, and the traffic goes round until something gives out. Running 3proxy as its own account and excluding that account works too, and is the better choice when the machine has one address.

Linux, iptables. For traffic the machine forwards for others:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80  -j REDIRECT --to-ports 3129
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-ports 3143

Traffic the machine generates itself passes through OUTPUT instead, where the proxy's own connections have to be excluded:

# by the address the services connect from
iptables -t nat -A OUTPUT -p tcp --dport 80 ! -s 192.0.2.10 -j REDIRECT --to-ports 3129

# or by the account 3proxy runs as
iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner proxy3 \
    -j REDIRECT --to-ports 3129

Linux, nftables (Debian 11+, Ubuntu 22.04+, RHEL 8+, Fedora, Arch, where nftables is what iptables is a front end for):

table ip proxy3 {
	chain prerouting {
		type nat hook prerouting priority dstnat; policy accept;
		iif "eth0" tcp dport 80 redirect to :3129
		iif "eth0" tcp dport 443 redirect to :3143
	}

	chain output {
		type nat hook output priority dstnat; policy accept;
		meta skuid != "proxy3" tcp dport 80 redirect to :3129
		meta skuid != "proxy3" tcp dport 443 redirect to :3143
	}
}

Load it with nft -f, and keep it across reboots in /etc/nftables.conf (Debian, Ubuntu) or /etc/sysconfig/nftables.conf (RHEL, Fedora). A table name cannot begin with a digit, which is why the table above is not called 3proxy.

Linux, firewalld (RHEL, CentOS Stream, Fedora, openSUSE). Redirect an incoming port on a zone:

firewall-cmd --permanent --zone=internal --add-forward-port=port=80:proto=tcp:toport=3129
firewall-cmd --permanent --zone=internal --add-forward-port=port=443:proto=tcp:toport=3143
firewall-cmd --reload

firewalld has no exclusion for the proxy's own traffic in that form, so put that part in a direct rule:

firewall-cmd --permanent --direct --add-rule ipv4 nat OUTPUT 0 \
    -p tcp --dport 80 -m owner ! --uid-owner proxy3 -j REDIRECT --to-ports 3129
firewall-cmd --reload

Linux, ufw (Ubuntu, Debian). ufw has no command for redirection; add the rules to /etc/ufw/before.rules, above the *filter block:

*nat
:PREROUTING ACCEPT [0:0]
-A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-ports 3129
-A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-ports 3143
COMMIT

On Linux 3proxy asks the kernel where the connection was going. On the BSDs it asks pf, which keeps the original destination in its state table, through /dev/pf - so rdr rules work, and 3proxy has to be able to read that device. Where a redirection leaves the destination on the socket instead, that is used: OpenBSD divert-to and FreeBSD ipfw fwd both do.

The mechanism is chosen automatically, and transparent takes an argument for the installations that need to pin it: auto (the default), netfilter, pf, or socket for reading it off the socket. A mode the build has no code for is refused, so a configuration written for another platform fails where it is wrong instead of quietly doing something else.

FreeBSD, NetBSD and OpenBSD, pf. Redirect in /etc/pf.conf, excluding the address the proxy connects from:

rdr pass on em0 inet proto tcp from ! 192.0.2.10 to any port 80  -> 127.0.0.1 port 3129
rdr pass on em0 inet proto tcp from ! 192.0.2.10 to any port 443 -> 127.0.0.1 port 3143

Load with pfctl -f /etc/pf.conf. 3proxy looks the destination up in pf's state table, so it needs to read /dev/pf: either run it as root, or give its account access to that device.

OpenBSD, divert-to is an alternative which leaves the destination on the socket, and needs no access to /dev/pf:

pass in on em0 inet proto tcp to any port 80  divert-to 127.0.0.1 port 3129
pass in on em0 inet proto tcp to any port 443 divert-to 127.0.0.1 port 3143

FreeBSD, ipfw. fwd delivers the connection locally without rewriting it, which also leaves the destination on the socket:

ipfw add fwd 127.0.0.1,3129 tcp from any to any 80  in recv em0
ipfw add fwd 127.0.0.1,3143 tcp from any to any 443 in recv em0

macOS has /dev/pf but ships no header for it, so a macOS build has no pf lookup, and macOS has neither divert-to nor ipfw to leave the address on the socket. Transparent proxying is not usable there, even though the commands exist in a macOS build.

Check the result by asking for a host through a redirected port and reading the log: the request should appear with the address the client asked for, which is what it would look like through a configured proxy.

Since version 0.9.7, PCRE (Perl Compatible Regular Expressions) filtering is built into 3proxy when compiled with PCRE2 support (WITH_PCRE). Previously available as PCREPlugin, the functionality is now integrated into the main binary. The plugin line is no longer required.

PCRE filtering can be used to create matching and replacement rules with regular expressions for client requests, client and server headers, and client and server data.

Commands:

pcre TYPE FILTER_ACTION REGEXP [ACE]
pcre_rewrite TYPE FILTER_ACTION REGEXP REWRITE_EXPRESSION [ACE]
pcre_extend FILTER_ACTION [ACE]
pcre_options OPTION1 [...]

• TYPE - type of filtered data (comma-delimited list):
  • request - content of the client's request (e.g., HTTP GET request string)
  • cliheader - content of the client request headers
  • srvheader - content of the server's reply headers
  • clidata - data received from the client (e.g., HTTP POST data)
  • srvdata - data received from the server (e.g., HTML page)
• FILTER_ACTION - action on match:
  • allow - allow this request without checking the rest of the rules
  • deny - deny this request without checking the rest of the rules
  • dunno - continue with the rest of the rules (useful with pcre_rewrite)
• REGEXP - PCRE (Perl) regular expression. Use * if no regexp matching is required.
• REWRITE_EXPRESSION - substitution string. May contain Perl-style substrings $1, $2, etc. $0 means the whole matched string. \r and \n may be used to insert new lines.
• ACE - access control entry (user names, source IPs, destination IPs, ports, etc.), identical to allow/deny/bandlimin commands. The regular expression is only matched if the ACL matches the connection data.

Examples:

# Block requests containing specific keywords for certain users
pcre request deny "porn|sex" user1,user2,user3 192.168.0.0/16

# Block responses with specific content type
pcre srvheader deny "Content-type: application"

# Replace content in both directions (censorship)
pcre_rewrite clidata,srvdata dunno "porn|sex|pussy" "***" baduser
pcre_extend deny * 192.168.0.1/16

Note: Regular expressions don't require authentication and cannot replace authentication and/or allow/deny ACLs.

First, always specify the internal interface to accept incoming connections with the 'internal' configuration command or '-i' service command. (See How to start any of the proxy services (HTTP, SOCKS, etc.)). If no internal interface is specified, your proxy will act as an open proxy.

It's also important to specify the external interface to prevent access to the internal network with 'external' or -e.

3proxy with configuration files allows you to use authentication and authorization for user access. Authentication is possible by username/password or the user's NetBIOS name. The authentication type is specified by the 'auth' command.

auth none

auth iponly

auth nbname

auth strong

Different services can have different authentication levels.

auth none
pop3p
auth iponly
proxy
auth strong
socks

Since version 0.6, double authentication is possible, e.g.:

auth iponly strong
allow * * 192.168.0.0/16
allow user1,user2
proxy

Version 0.6 introduces authentication (username) caching to increase performance. It's recommended to use authentication caching with resource- or time-consuming authentication types, such as nbname or external plugins (WindowsAuthentication). Caching can be set with the 'authcache' command with 2 parameters: caching type and caching time (in seconds). The caching type defines the type of cached access: 'ip' - after successful authentication, all connections during the caching time from the same IP are assigned to the same user; the username is not requested. "ip,user" - the username is requested, and all connections from the same IP are assigned to the same user without actual authentication. "user" - same as above, but IP is not checked. "user,password" - username and password are checked against cached ones. For authentication, the special authentication type 'cache' must be used. Example:

authcache ip 60
auth cache strong windows
proxy -n

authcache can be used to bind a user's sessions to an IP with the 'limit' option. With

  authcache ip,user,pass,limit 120
  auth cache strong

The user list is created with the 'users' command.

users USERDESC ...

users admin:CL:bigsecret test:CL:password test1:CL:password1
users "test2:CR:$1$lFDGlder$pLRb4cU2D7GAT58YQvY49."
users test3:NT:BD7DFBF29A93F93C63CB84790DA00E63

• No password type: use system authentication.
• CL - cleartext password
• CR - crypt password; only MD5 crypt passwords are supported
• NT - NT-hashed (MD4) passwords in hex, as used in pwdump or SAMBA

users $/etc/.3proxypasswd

users $"c:\Program Files\3proxy\passwords"

The commands allow, deny, and flush are used to manage ACLs:

allow <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist> <weekdaylist> <timeperiodlist>
deny <userlist> <sourcelist> <targetlist> <weekdaylist> <timeperiodlist>
flush

• <userlist> - comma-delimited list of users
• <sourcelist> - comma-delimited list of source (client) networks. Networks can be defined as a single IP address or in CIDR form xxx.yyy.zzz.mmm/l, where l is the length of the network mask (a number of non-zero bits). 192.168.1.0/24 means a network with a 255.255.255.0 mask.
• <targetlist> - comma-delimited list of target (server) networks. In 3proxy 0.6 and above, it's allowed to use hostnames with wildmasks in the targetlist. A wildmask may only appear at the beginning or at the end of the hostname, e.g., 192.168.0.0/16,www.example.com,*wrongsite.com,*wrongcontent*.
• <targetportlist> - comma-delimited list of ports. It's possible to define port ranges with -, e.g., 80,1024-65535 means port 80 and all unprivileged ports.
• <commandlist> - the list of allowed actions:
  CONNECT - establish an outgoing TCP connection, e.g., POP3 or SOCKSv5
  BIND - allow an incoming TCP connection (SOCKSv5)
  UDPASSOC - create a UDP association (SOCKSv5)
  ICMPASSOC - create an ICMP association (not implemented)
  HTTP_GET - HTTP GET request (HTTP proxy)
  HTTP_PUT - HTTP PUT request (HTTP proxy)
  HTTP_POST - HTTP POST request (HTTP proxy)
  HTTP_HEAD - HTTP HEAD request (HTTP proxy)
  HTTP_CONNECT - HTTP CONNECT, aka HTTPS request (HTTP proxy)
  HTTP_OTHER - another HTTP request (HTTP proxy)
  HTTP - any HTTP request except HTTP_CONNECT (HTTP proxy)
  HTTPS - alias for HTTP_CONNECT (HTTP proxy)
  FTP_GET - FTP get request (http, ftp proxy)
  FTP_PUT - FTP put request (ftp proxy)
  FTP_LIST - FTP list request (http, ftp proxy)
  FTP - any FTP request
  ADMIN - administration interface access

• <weekdays> - weekday numbers or periods (0 or 7 means Sunday, 1 is Monday, 1-5 means Monday through Friday).
• <timeperiodlist> - a list of time periods in HH:MM:SS-HH:MM:SS format. For example, 00:00:00-08:00:00,17:00:00-24:00:00 lists non-working hours.

Redirections are useful to, e.g., forward requests from specific clients to different servers or proxy servers. Additionally, redirections are useful to convert the proxy interface from one format to another, e.g., requests from a SOCKS proxy can be redirected to a parent HTTP proxy, or a SOCKSv5 client can be redirected to a SOCKSv4 proxy.
Because 3proxy understands "transparent" web requests, it can be used as an intermediate software between an HTTP proxy and a NAT server for transparent HTTP forwarding, because it can convert a "Web server" request issued by a client to a "proxy request" required by a proxy server. A simple redirection is:

auth iponly
allow *
parent 1000 http 192.168.1.1 3128
proxy

auth iponly
allow * * * 80
parent 1000 http 0.0.0.0 0
allow * * * 21
parent 1000 ftp 0.0.0.0 0
allow * * * 110
parent 1000 pop3 0.0.0.0 0
socks

Q: What is it for?

Q: What are the restrictions?

Q: What are the advantages?

Q: How to set it up?

auth iponly
allow * * * 80,8080-8088
parent 1000 http 0.0.0.0 0
allow * * * 80,8080-8088
#redirect ports 80 and 8080-8088 to local HTTP proxy
#Second allow is required, because ACLs are checked
#twice: first time by socks and second by http proxy.

allow * * * 21,2121
parent 1000 ftp 0.0.0.0 0
allow * * * 21,2121
#redirect ports 21 and 2121 to local
#ftp proxy


allow *
#allow the rest of connections directly

socks
#now let the socks server start

Q: How does it affect different ACL rules?

allow * * * 80,8080-8088
parent 1000 http 0.0.0.0 0
#redirect http traffic to internal proxy

allow * * $c:\3proxy\local.nets 80,8080-8088
#allow direct access to local.nets networks
allow * * * 80,8080-8088
parent 1000 http proxy.3proxy.org 3128
#use parent caching proxy for the rest of the networks

allow *
#allow direct connections for the rest of socks
#requests

The proxy itself doesn't manage network-level routing. The only way to control the outgoing channel is to select the external interface. It's possible to make the external interface (what is usually selected with the 'external' command or '-e' option) random by using local redirection with an external port of 0.

auth iponly
allow *
parent 500 http 10.1.1.101 0
parent 500 http 10.2.1.102 0

If both interface addresses are in the same network, e.g., 10.1.1.101 and 10.1.1.102, and you want to select a random gateway between 10.1.1.1 and 10.1.1.2, you must control it by using the routing table, in case there is no default gateway route for Windows:

 route add -p 10.1.1.1 10.1.1.101
 route add -p 10.1.1.2 10.1.1.102
 route add -p 0.0.0.0 mask 0.0.0.0 192.168.1.1
 route add -p 0.0.0.0 mask 0.0.0.0 192.168.1.2

The parent command may also be used to build proxy chains. In this case, multiple 'parent' commands are used for a single 'allow' rule with different weights (the first argument of the parent command). A chain may contain any number of proxy servers, but it should be noted that every hop significantly reduces performance. It's possible to mix different types of proxies within a single chain: HTTPS (HTTP connect), SOCKS4, SOCKS5. A weight different from 1000 is used to build random chains. If weight W is below 1000, this proxy will be used as the next chain hop with a probability of W/1000. That is, if the weight is 250, the probability that this proxy will be used for the next hop is 25%. 'parent' records with a combined weight of 1000 establish a group; one of these records will be used for the hop with a probability according to the weight. Warning: each group must have a weight that is a multiple of 1000. As follows, the combined weight of all 'parent' records must also be a multiple of 1000. If the combined weight of 'parent' records in the chain is 3000, the chain has 3 hops and must be formed of 3 groups. Example:

allow *
parent 500 socks5 192.168.1.1 1080
parent 500 connect 192.168.10.1 3128

allow * * * 80
parent 1000 socks5 192.168.10.1 1080
parent 1000 connect 192.168.20.1 3128
parent 300 socks4 192.168.30.1 1080
parent 700 socks5 192.168.40.1 1080

A SOCKSv5 UDP ASSOCIATE request only asks 3proxy to open a relay port, it carries no destination. The destination is taken from every datagram the client sends afterwards, so a single association may reach any number of destinations. 3proxy authorizes the destination of every datagram, so ACLs limiting the destination address, host name or port do apply to UDP traffic.

Differences from TCP:

• A datagram to a denied destination is dropped, the association is not terminated.
• The parent proxy and the external address are selected for the destination of the datagram and not for the ASSOCIATE request, and are re-established if a later destination selects another ACL entry. Only socks5 and socks5+ parents can be used for UDP.
• ACLs are checked for the datagrams sent by the client only. A datagram received on the association is relayed to the client without an ACL check: with a parent proxy only the datagrams from the parent are accepted, an association without a parent accepts a datagram from any source. The source reported to the client is the actual source of the datagram. The address in the log record is the destination the client sent the datagrams to, the source of the received datagrams is not logged.
• A client may use a single association to reach many destinations. An ACL entry which limits the destination silently drops the datagrams to every other destination, so limiting the destination of UDP traffic can break such clients in a way which is hard to diagnose. Limit it only when it is really required.
• Bandwidth limiters and traffic counters which limit the destination are selected when the destination is authorized, so they are selected for the destination of the first datagram and are not re-selected for every following destination. They can not be applied per destination to incoming UDP traffic at all.
• Every change of the destination host name, address or port is authorized again and logged. Use nscache for host names and the authentication cache for anything more expensive than 'iponly'. The -U option of the socks service turns the logging and/or the re-authorization off; with -U0 or -U1 only the first destination of an association is authorized.

Limit the destinations a client may send datagrams to:

auth iponly
allow * * 8.8.8.8 53
deny *
socks -p1080

The ASSOCIATE request succeeds, datagrams to 8.8.8.8:53 are relayed, datagrams to any other destination are dropped.

The same with 'strong' (or RADIUS, or plugin) authentication, where every new destination would otherwise be authenticated again:

users user1:CL:password
authcache user,pass,dstaddr,dstport 60
auth cacheacl strong
allow user1 * 8.8.8.8 53
deny *
socks -p1080

With 'cacheacl' the ACL result is not re-evaluated on a cache hit, so every field the ACL limits must be a part of the cache key: 'user' and 'pass' for the userlist, 'dstaddr' and 'dstport' for the targetlist and the targetportlist, 'ip' for the sourcelist, 'dsthost' for host names in the targetlist, 'dstoper' for the operationlist. Without the destination in the key the result cached for one destination is applied to any other destination and the destination is not checked at all. Use plain 'cache' instead of 'cacheacl' if ACLs may change during the cache lifetime, or if a parent proxy is used: on a 'cacheacl' hit the ACL is not walked, so no parent proxy is selected and datagrams are sent directly.

3proxy supports bandwidth filters. Use the bandlimin/bandlimout and nobandlimin/nobandlimout commands to manage filters. 'in' means incoming and 'out' means outgoing traffic.

bandlimin <bitrate> <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist>
nobandlimin <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist>

  bandlimin 57600 * 192.168.10.16
  bandlimin 57600 * 192.168.10.17
  bandlimin 57600 * 192.168.10.18
  bandlimin 57600 * 192.168.10.19

  bandlimin 57600 * 192.168.10.16/30

  nobandlimin * * * 110
  bandlimin 57600 * 192.168.10.16/32

counter <filename> <type> <reportpath>
countin <number> <type> <amount> <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist>
nocountin <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist>
countout <number> <type> <amount> <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist>
nocountout <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist>

You can set a traffic limit per day (D), week (W), month (M), year (Y), or absolute ('N'), as specified by the 'type' argument of the counterin command. Traffic information is stored in a binary file specified by the 'filename' argument. The countersutil utility can be used to manage this file. The reportpath specifies the location of text reports; the type parameter of the 'counter' command controls how often text reports are created. The amount is the amount of allowed traffic in megabytes (MB). nocountin allows you to set exclusions.

3proxy accounts for protocol-level traffic. Providers count channel- or IP-level traffic with network and transport headers. In addition, 3proxy does not count DNS resolutions, pings, floods, scans, etc. This accounts for approximately a 10% difference. That is why you should have a 15% reserve if you use 3proxy to limit your traffic. If the difference with your provider is significantly above 10%, you should look for traffic bypassing the proxy server, for example connections through NAT, traffic originating from the host with the proxy installed, traffic from server applications, etc.

For name resolution and caching, use the commands nserver, nscache / nscache6, and nsrecord.

  nserver 192.168.1.2
  nserver 192.168.1.3:5353/tcp

  nscache 65535
  nscache6 65535

  nsrecord server.mycompany.example.com 192.168.1.1
  nsrecord www.porno.com 127.0.0.2
  ...
  deny * * 127.0.0.2

IPv6 is supported since version 0.8. Please note that some proxy protocols, e.g., SOCKSv4, do not support IPv6. SOCKSv5 supports IPv6 with a special request type (which must be implemented by the client).
3proxy supports proxying from IPv4 and IPv6 networks to IPv4, IPv6, and mixed networks. An IPv6 address may be used in internal, external, and parent commands, ACLs, -i and -e options, etc. The external command and -e options may be given twice for each service—once with an IPv4 and once with an IPv6 address. internal can be given only once; to bind to all IPv4 and IPv6 addresses, use [0:0:0:0:0:0:0:0] or [::].
Any service may be configured with -4, -46, -64, or -6 options to specify the desired priority for name-to-IPv4/IPv6 address resolution (IPv4 only, IPv4 priority, IPv6 priority, IPv6 only).

For example, a user needs access from an external network to a proxy server located on the host 192.168.1.2. This host cannot be accessed from the external network, but it has access to the external network with an external address 1.1.1.1. Also, the user has access to the host 2.2.2.2 (IP address may be dynamic) with hostname host.dyndns.example.org via the external network. The user needs 2 instances of 3proxy, the first one on the host 192.168.1.2 with the config

  users user:CL:password
  auth strong
  allow user
  proxy -rhost.dyndns.example.org:1234

  auth iponly
  allow * * 1.1.1.1
  tcppm -R0.0.0.0:1234 3128 1.1.1.1 3128

3proxy supports HAProxy PROXY protocol v1 for both receiving and sending client IP information. This is useful when 3proxy is behind a load balancer or when passing client information to a parent proxy.

Receiving PROXY protocol header:
Use the -H option to make 3proxy expect a PROXY protocol v1 header on incoming connections. This allows 3proxy to receive the real client IP address from HAProxy or another load balancer:

proxy -H -p3128
socks -H -p1080

The PROXY protocol header must be sent before any protocol-specific data.

Sending PROXY protocol header to parent proxy:
Use the ha parent type to send a PROXY protocol v1 header to the parent proxy. Place ha before the parent that should receive the header; after the header is sent, parent protocol negotiation continues:

allow *
parent 1000 ha 0.0.0.0 0
parent 1000 socks5 parent.example.com 1080
proxy

This configuration connects to the SOCKS5 parent, sends the PROXY protocol header with the original client IP, then performs SOCKS5 negotiation before relaying the client payload. The parent should use -H to accept the header (for example socks -H).

Use the maxseg command to set the TCP maximum segment size (MSS) for outgoing connections. This can be useful to work around path MTU discovery issues or to optimize traffic for specific network conditions:

maxseg 1400
proxy -p3128 -OcTCP_NODELAY,TCP_MAXSEG -OsTCP_NODELAY,TCP_MAXSEG

The value is specified in bytes. This setting uses the TCP_MAXSEG socket option and may not be supported on all platforms. A typical use case is to reduce MSS to avoid fragmentation in VPN tunnels or to work around MTU issues with certain network paths.