Raspberry Pi Proxy Server: HTTP, SOCKS5 and Mobile Modem Setup

Choose the host and operating system deliberately

Use the official Raspberry Pi OS download page and the getting-started instructions for an image supported by your board. The current download family is based on Debian Trixie; a Lite image avoids installing a desktop when you only need a headless service. Select the appropriate architecture in Imager rather than assuming every Pi supports the same image.

Prepare reliable storage, the recommended power supply for the board, cooling suitable for its enclosure and a network connection you can inspect. Ethernet makes the initial route easier to identify when the Pi also has Wi-Fi or cellular interfaces available.

This tutorial uses upstream 3proxy on Linux. It does not establish that a Raspberry Pi is a supported controller for every commercial modem package. If you plan to use Coronium’s farm hardware, confirm its host and software requirements before substituting an ARM board for the supplied installation design.

Set up SSH access before installing the proxy

Raspberry Pi’s remote-access documentation explains enabling SSH through Imager and configuring public-key authentication. Create the user you intend to manage; do not rely on old tutorials that assume a universal default username and password.

Boot the Pi, find its hostname or address and connect from your workstation:

ssh piuser@proxy-pi.local

Replace both placeholders with your configured username and reachable hostname. Verify the host-key fingerprint through a trusted path before accepting an unfamiliar host. If local hostname discovery is unavailable, use the Pi’s known address.

Keep this administrative access working while testing networking changes. Record how to regain access locally if a modem or routing change interrupts the remote session. A proxy listener is a separate service from SSH and does not replace the management connection.

Install the build tools and compile the selected release

On Raspberry Pi OS, install the ordinary build dependencies, then follow the Linux path in the 3proxy 1.0.1 build instructions:

sudo apt update
sudo apt install --no-install-recommends build-essential git ca-certificates curl
git clone --depth 1 --branch 1.0.1 https://github.com/3proxy/3proxy.git
cd 3proxy
make -f Makefile.Linux -j2

The release pin makes the example identifiable. Review subsequent fixes before maintaining it as a service. If you use a distribution package instead, follow that package’s paths and service instructions rather than mixing two installations.

Compilation and package installation are distinct from the proxy configuration. Our related 3proxy guide tested the rule structure on a macOS build of the same release. We have not executed this Raspberry Pi installation on physical Pi hardware, and no Pi throughput or modem-capacity benchmark is claimed.

Run the listeners on loopback first

Save this configuration as 3proxy.cfg inside the build directory and replace the password placeholder:

# 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

Then restrict the file and start the process:

chmod 600 ./3proxy.cfg
./bin/3proxy ./3proxy.cfg

Keep that terminal open. The service is running in the foreground; this step does not create an automatic startup service. The configuration allows the named user from loopback and limits destination ports. The 3proxy setup guide explains rule order and the separate HTTP and SOCKS listeners.

Open another SSH session to the Pi and test the HTTP listener:

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 prompts for the password. Check that a wrong password fails as well. The address returned by ipify belongs to that request’s observed exit; it may still be the Pi’s Ethernet or Wi-Fi connection.

Reach the local proxy through an SSH tunnel

For a workstation that can reach the Pi over SSH, keep the proxy on loopback and forward one local port. The OpenSSH manual documents the -L local-forward syntax and -N mode:

ssh -N -L 127.0.0.1:13128:127.0.0.1:3128 piuser@proxy-pi.local

Leave that tunnel open. From another workstation terminal, repeat the curl check using http://127.0.0.1:13128 as the proxy. The first loopback address binds the forwarded port on your workstation; the destination loopback address is reached from the Pi.

This path protects the workstation-to-Pi hop with SSH while leaving the sample proxy unreachable directly from other hosts. It assumes your SSH service permits forwarding and your workstation can reach it. It does not configure Internet access, router forwarding or carrier NAT traversal.

If your application needs SOCKS5, you can forward the existing SOCKS listener separately, after checking the client’s authentication support. Browser support differs from HTTP-library support; our Playwright guide documents one relevant limitation.

Add a modem only after the proxy path works

The ModemManager device guide explains the control and network ports exposed by cellular devices. A USB connector alone does not establish a supported management interface. Identify the actual modem variant and mode before expecting the Pi to control its data session.

Connect one modem, establish its cellular connection using the supported management path, and inspect the host’s routes. Verify that the proxy’s outbound requests take that interface. A successful request through the new listener proves proxy connectivity, but does not prove that the underlying route is mobile.

Repeat after reconnecting the modem and rebooting the Pi. Check for competing default routes and changes in interface naming. For an E3372, use the variant and firmware guide before applying another model’s instructions.

The mobile carrier controls public address allocation. Reconnecting a modem may preserve the same address; the Pi and 3proxy do not guarantee a fresh IP for each request.

Treat USB power as a shared budget

The Raspberry Pi hardware documentation lists a Pi 5 downstream USB budget of 1.6 A with a suitable 5 A supply, reduced to 600 mA with a 3 A supply. Those are shared USB limits, not an allowance for each connected modem.

A powered hub can supply attached peripherals, but you still need to verify its power supply, per-port behavior and host compatibility. A hub’s advertised port count is not a tested modem count. Include storage devices and other USB peripherals when reviewing the arrangement.

Run a representative job and observe completed requests, host load, temperatures and disconnects. Increase the workload gradually and keep recovery access available. Do not publish a farm capacity derived only from CPU cores, RAM or the number of USB sockets.

Make recovery repeatable before leaving it unattended

When the local setup behaves correctly, choose a service manager or package-supported service definition. Run it with the privileges it needs, use an explicit configuration path and keep credentials out of general logs. Verify what happens when the process stops and when storage fills.

Keep the network test available so an operator can distinguish a proxy-process fault from a modem or carrier fault. Test recovery after a reboot before adding more hardware. The mobile farm guide covers the installation and operating record.

For an AI worker, keep the proxy endpoint in application configuration and bound its request count. A workflow can otherwise exhaust a small host by opening many browsers or retrying failures. Start with the Requests diagnostic when a simple HTTP request is enough.

Frequently asked questions