3proxy Configuration: Authenticated HTTP and SOCKS5 Setup

Use the released version and its configuration reference

3proxy 1.0.1 was released on October 10, 2026. We reviewed it and compiled that tagged source on macOS on October 11. The project’s build instructions distinguish platform makefiles and package installation paths.

For a Linux source build with Git, a C toolchain and Make available:

git clone --depth 1 --branch 1.0.1 https://github.com/3proxy/3proxy.git
cd 3proxy
make -f Makefile.Linux -j2

The project places built executables in bin/. Our local fixture used the documented Makefile.FreeBSD path on macOS, not a Linux kernel or cellular modem. Check the current release notes before adopting the pin into a maintained installation.

Use the binary and service layout supplied by your chosen package when you install through a distribution. Do not mix a package-managed service with a second hand-built executable unless you deliberately manage their paths and configuration files.

Start with local HTTP and SOCKS5 listeners

Create 3proxy.cfg and replace the example password with a unique value. This simple example uses a plain configuration secret, so restrict the file before running it:

chmod 600 ./3proxy.cfg

# Local diagnostic listeners. Replace the example password before use.
maxconn 32
users farmuser:CL:REPLACE_WITH_A_UNIQUE_PASSWORD

auth strong
allow farmuser 127.0.0.1 * 80,443
deny *
proxy -i127.0.0.1 -p3128

flush
auth strong
allow farmuser 127.0.0.1 * 80,443 CONNECT
deny *
socks -i127.0.0.1 -p1080

From the build directory, run ./bin/3proxy ./3proxy.cfg in the foreground. Use another terminal for the request checks below. The example does not install a service, change firewall rules or listen on every network interface.

The configuration manual defines users, auth strong and the ordered allow/deny rules. Here the username and source address must match, and destination ports are restricted. CL stores the password as clear text in the configuration; it is not a password hash.

The flush command clears the access list before the next service’s rules. The SOCKS rule permits CONNECT operations for this diagnostic. Avoid inserting unrelated service lines into the example without checking which rules they inherit. The tagged sample configuration illustrates this order and the option to load users from a separate protected file.

Check both listeners, then check an invalid password

The HTTP proxy manual documents the HTTP service, while the SOCKS manual documents the SOCKS listener. These are separate listeners even when the same process owns them.

Use curl from the same host. Supplying only the username asks curl to prompt for the password, keeping it out of the command text:

curl --fail --show-error --noproxy "" \
  --connect-timeout 10 --max-time 30 \
  --proxy http://127.0.0.1:3128 --proxy-user farmuser \
  https://api.ipify.org

curl --fail --show-error --noproxy "" \
  --connect-timeout 10 --max-time 30 \
  --proxy socks5h://127.0.0.1:1080 --proxy-user farmuser \
  https://api.ipify.org

Repeat with an incorrect password and confirm that the request fails. Then use a controlled destination port outside the allow list and confirm that it is denied. Do not count a service as correctly configured merely because one valid password worked.

The curl reference covers proxy credentials and exclusions. --noproxy "" removes an inherited exclusion for this diagnostic. The socks5h scheme asks the SOCKS proxy to resolve the destination hostname. The public IP response from ipify identifies that request’s observed exit, without testing every application on the host.

Distinguish listening, source binding and routing

The 3proxy how-to separates the internal address, where clients connect, from the external address used as the outgoing source. Its service flags allow each listener to receive its own settings.

For a farm, first establish a working cellular interface and operating-system route. An external address or -e option must refer to an appropriate local source address. It does not create a modem connection, select an APN or install the route needed to reach the destination.

Test the result from the actual listener a client uses. A successful request from the host shell may use another default route. Record the listener, intended modem interface and observed public address together when checking the mapping.

If several modem interfaces share similar private addressing, resolve that routing design before copying a listener block many times. The Huawei compatibility guide explains why device mode and host enumeration need checking first.

Review access controls before changing the bind address

Both sample listeners bind to 127.0.0.1, so remote clients cannot reach them directly. Before selecting a client-facing address, define who should connect and which destinations they need. Restrict network access at the host or network firewall as well as in 3proxy’s rules.

The sample’s port list alone is not a complete destination policy. A client might reach a private service using an allowed port unless you also restrict destination addresses. Decide whether local management networks and internal services must be excluded for your users, then test those exclusions.

Protect the client-to-proxy connection appropriately for the network it crosses. Basic proxy credentials are not encrypted merely because the final destination uses HTTPS. Keep the configuration file and any separate user database readable only by the intended service account.

For unattended operation, use the service mechanism documented for your package or installation method. Check the running executable and configuration path, process ownership and restart behavior. The project how-to describes service and logging options; retain only the request information your operation needs and control access to it.

Set capacity from measurements of the actual installation

The sample caps configured service connections with maxconn 32. That number is a diagnostic choice, not a throughput recommendation or a statement that one modem supports thirty-two productive jobs.

Measure completed requests and failure categories under your intended workload. Separate proxy connection errors, DNS failures, destination responses and carrier interruptions. Keep application timeouts and job concurrency bounded even if the proxy accepts more connections.

A source-address setting does not rotate the carrier’s public IP. Treat modem reconnects and provider rotation controls as separate operations, and preserve the route needed by an authorized session. For browser jobs, the Playwright guide explains context lifetime and session continuity.

What the 3proxy fixture established

We compiled the 1.0.1 release and ran the displayed rule structure against local HTTP and TLS fixtures. The fixture substituted ephemeral listener and destination ports for the example’s fixed ports. It verified HTTP and SOCKS5 authentication, HTTPS CONNECT with a trusted local certificate, rejection of an incorrect password and denial of a destination port outside the allow list. The destination received no proxy Authorization header or unintended website Authorization header.

This test covers configuration order and request behavior on the stated build. It does not measure Linux interface binding, physical modems, carrier reconnection or farm throughput. Run those checks on your target host before promoting a configuration to production.

For an AI collection pipeline, keep proxy administration outside the model’s tool inputs. Give workers the endpoint they are meant to use and a bounded request budget. The Requests guide and Scrapy guide cover the clients that connect to this service.

Frequently asked questions