Device guide · Linux · headless peer 1.6.1

Run a bandwidth-sharing peer on a Linux server

The PROXIES.SX headless peer is one binary for Linux x86-64 with an optional systemd installer. You download it, check its SHA-256, run sudo bash install.sh and paste your SDK / device key; the service then runs unprivileged and only makes outbound connections.

Registration does not guarantee traffic or earnings. Earnings depend on eligible traffic your devices actually serve and on your active partner terms.

Checked on against our published supplier terms

Requirements

From the package's install guide. install.sh itself checks the architecture, a running systemd 235+ and root.
Architecture
Linux x86-64 for the published package (no ARM package; the Go source can be built for arm64)
Service installer
systemd 235 or later, running, plus sudo
Network
Outbound DNS, HTTPS, WebSocket and target TCP access; an OS CA certificate store
Connection type
Residential or mobile IP (datacenter IPs are rejected for listing)
Account
A farmer account, signed agreement, supply-source declaration and an SDK / device key (psx_…)
Not needed
GUI, Go, Docker, Node.js or a compiler; no inbound port

What we checked on 27 September 2026

We downloaded the release, verified it and ran it in a linux/amd64 container. We did not register a device.
Release 1.6.1 contents
FileBytesPurpose
proxies-peer7,233,696The static peer binary
install.sh2,086Checks the platform, verifies checksums, writes the key file and service
proxies-peer.service603Hardened systemd unit
INSTALL.md5,512English install guide
INSTALL-zh.md5,309Chinese install guide
SHA256SUMS400Checksums for the files above
Archive
proxies-peer-linux-amd64.tar.gz, 3,055,028 bytes
SHA-256
2c283797c12458ad0d936796153c581f64c9abe41bf4881fbb3cce0e0ed35e91
Checksum result
OK for the archive and all five files inside it
Output in debian:stable-slim, linux/amd64 (27 Sep 2026)
$ ./proxies-peer -version
proxies-peer 1.6.1

$ ./proxies-peer -h
Usage of ./proxies-peer:
  -api string
        Platform API base URL (default "https://api.proxies.sx/v1")
  -carrier string
        Your ISP / carrier name (informational) (default "unknown")
  -connections int
        Parallel relay sockets (1-5 by default; hard maximum 6) (default 4)
  -country string
        Your ISO-2 country hint (server still verifies the real IP) (default "US")
  -key string
        Your Proxies.sx API key (required)
  -method string
        Connection-type badge (agent/vps/docker) (default "agent")
  -name string
        Friendly agent name shown in your dashboard
  -relay string
        Pin a relay URL (empty = let the server pick the nearest)
  -state string
        Path to the saved identity file (default "/root/.proxies-peer-state.json")
  -verbose
        Log every tunnel open/close
  -version
        Print SDK version and exit without connecting
  -wallet string
        Payout wallet address (optional)

Install on one device

  1. Create your key and declaration first

    In the farmer account, sign the agreement, complete the supply-source declaration and create an SDK / device key. Use this only on devices whose owners have given informed consent.

  2. Download, verify and install

    The installer checks for Linux x86-64, systemd 235+ and a running systemd, verifies SHA256SUMS again, then asks privately for your key. It refuses to replace a peer that is already running.
    Shell
    curl -fLO https://agents.proxies.sx/peer/releases/1.6.1/proxies-peer-linux-amd64.tar.gz
curl -fLO https://agents.proxies.sx/peer/releases/1.6.1/SHA256SUMS
sha256sum -c SHA256SUMS
tar -xzf proxies-peer-linux-amd64.tar.gz
cd proxies-peer-linux-amd64
sudo bash install.sh

  3. Check that it registered

    Allow up to 30 seconds of start-up jitter. Expect REGISTERED (or RESUMED), then CONNECTED and ACK. The installer starts with one relay socket per device.
    Shell
    /usr/local/bin/proxies-peer -version
sudo systemctl status proxies-peer --no-pager
sudo journalctl -u proxies-peer -n 40 --no-pager

  4. Wait for verification before adding devices

    Auto-approval needs at least one hour online and a quality score of 50 or more; automatically verified devices are re-checked hourly. Online and verified alone does not prove the device is listed or receiving customer sessions.

What the installer sets up

Everything below is in install.sh and proxies-peer.service in the release.

The key is written to /etc/proxies-peer/peer.env with mode 0600 inside a 0700 directory, together with a random device name (linux- plus a UUID), one WebSocket and a 30-second registration jitter. The binary goes to /usr/local/bin/proxies-peer. Identity persists in /var/lib/proxies-peer/state.json; keep both files across restarts and never copy them into a device image.

The service runs as a systemd dynamic user with no capabilities, a read-only system, no access to home directories and only IPv4, IPv6 and Unix sockets. If it exits with an error it restarts after 60 seconds, at most five times in five minutes.

proxies-peer.service (excerpt)
[Service]
Type=simple
DynamicUser=yes
StateDirectory=proxies-peer
EnvironmentFile=/etc/proxies-peer/peer.env
Environment=PEER_STATE_FILE=/var/lib/proxies-peer/state.json
ExecStart=/usr/local/bin/proxies-peer
Restart=on-failure
RestartSec=60
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
CapabilityBoundingSet=

Run without systemd

For containers or other supervisors: run as an ordinary user with a persistent, private state path, and read the key without putting it in shell history.
Bash
read -r -s -p 'SDK key: ' API_KEY; echo
export API_KEY
export AGENT_NAME='your-stable-unique-device-name'
export PEER_STATE_FILE="$HOME/.local/state/proxies-peer/state.json"
export WS_CONNECTIONS=1 REGISTER_JITTER_MS=30000
./proxies-peer

Your supervisor must keep the state file, restart with limits, and stop retrying on persistent 401 or 403 responses until the account is checked.

Troubleshooting

Common responses
You seeWhat it meansWhat to do
HTTP 403 on registerThe account may be suspended, missing the current agreement, or at a device limitCheck the key and agreement in the farmer dashboard, then ask support with the key name, device name, version and UTC time. Never send the key or state.
HTTP 401The key or token is not acceptedCheck the key; do not loop restarts
HTTP 429Slow down, a shared limit was hitBack off with jitter and respect Retry-After; the binary makes up to five registration attempts
Close code 4001No token was sent on the WebSocketReport it to support with the version and UTC time
Close code 4002Token invalid or expiredThe client refreshes once for all sockets
Close code 4008The device already holds 6 socketsThe oldest socket was evicted; lower the socket count

Do not delete identity state or change names to diagnose an error: that creates new identities. Restarting a whole fleet at once adds registration load.

Stop, update or remove

Stop and disable the service
sudo systemctl disable --now proxies-peer

Stopping disconnects this device's tunnels. To update, stop the service in a maintenance window and install the new release with the same key, name and state. For permanent removal, stop the process, remove the device from the farmer dashboard, then delete its local secrets and state. You can leave at any time; earnings already recorded stay on your account.

A Chinese version of the install guide is published at linux-zh.md.

Questions

Is there a Linux version of a bandwidth-sharing app that runs without a desktop?
Yes. The PROXIES.SX peer 1.6.1 is a single command-line binary for Linux x86-64. It needs no GUI, Go, Docker, Node.js or compiler on the device, and an optional installer sets it up as a systemd service.
Does it run on a Raspberry Pi or other ARM board?
Not with this package. The published release is linux-amd64 only, and install.sh refuses to run on anything else. No ARM package is published, but the Go source can be cross-compiled for arm64, as described at agents.proxies.sx/peer/go/.
Does it need root or an open port?
The installer needs sudo to write the service and key file. The service itself runs as a systemd dynamic unprivileged user with an empty capability set, and it only makes outbound connections; no inbound port is required.
Will it earn on a VPS?
The binary runs on a VPS, but datacenter IPs are rejected for customer listing. The peer network is for residential and mobile connections.
It says CONNECTED. Why is there no traffic yet?
A running process is not proof of verified, listed or routable supply. A device needs at least an hour online and a quality score of 50 or more for auto-approval, must meet the 500 KB/s routing floor, and customer sessions follow customer demand. Registration does not guarantee traffic or earnings.
Can I run it on many machines?
Yes, but give every real device its own stable AGENT_NAME and state, never clone state into an image, and roll out to one device, then a small cohort, checking each stage before expanding.

Start with one Linux device

Create a farmer account and an SDK / device key, install on one residential or mobile connection, and expand only after it passes the self-test, is verified and listed, and has carried customer traffic.
Create farmer account Read the supplier contract

Sources