2 ott 2026 \u00b7 @juan<\/p>\n
A mobile proxy farm is, stripped of marketing language, a rack of cellular modems attached to Linux hosts, each modem exposing its carrier-assigned connection through a proxy endpoint that remote clients can use. The engineering problem is less glamorous than the term suggests. It is mostly about USB stability, deterministic device naming, per-interface routing, process isolation, controlled IP rotation and observability across dozens or hundreds of flaky radio links.<\/p>\n
This guide walks through that stack layer by layer: hardware, Linux modem management, network architecture with policy routing and network namespaces, the proxy daemons themselves, an IP rotation service, containerization with Docker and orchestration with Kubernetes, and finally monitoring, security and compliance. I include working configuration and code snippets throughout. They are written to be readable and adaptable rather than copy-paste production code; test everything on your own hardware and carrier before relying on it.<\/p>\n
I also mention a few open-source projects hosted on GitHub that are widely used as building blocks. I name repositories by their owner and project name rather than linking to them, so you can search for them directly.<\/p>\n
A conventional datacenter proxy forwards traffic from a server with a static IP address allocated to a hosting provider. A residential proxy<\/a> forwards traffic through a fixed-line consumer connection. A mobile proxy<\/a> forwards traffic through a cellular data connection: 4G LTE or 5G, via a SIM card on a mobile network operator (MNO) or mobile virtual network operator (MVNO).<\/p>\n The defining property of mobile egress is carrier-grade NAT (CGNAT). Most mobile operators do not give each subscriber a unique public IPv4 address. Instead, the modem receives an address from a private or shared range, frequently from the block that RFC 6598 reserves for exactly this purpose, and the carrier translates many subscribers onto a pool of public IPv4 addresses at its NAT gateways. A single public IPv4 address at a given moment may therefore represent many real users.<\/p>\n That has two consequences engineers need to understand:<\/p>\n IPv6 adds another dimension. Many carriers now assign native IPv6 prefixes to mobile devices, often a \/64 per session. Whether that matters depends on the target services your clients reach and whether your proxy layer supports IPv6 egress. I keep the examples below IPv4-centric because that is where most operational complexity lives, but I note IPv6 implications where relevant.<\/p>\n Mobile proxies have real engineering and business uses, including:<\/p>\n The same infrastructure can be abused for credential stuffing, ad fraud, fake account creation, scalping and evasion of fraud controls. Those uses can be illegal, and they also harm the operator: carriers suspend SIMs linked to abuse, and providers that tolerate abuse get blocklisted and sued. I treat acceptable-use enforcement as part of the architecture, not an afterthought, and the final section covers it in detail. Before building anything, read your carrier’s terms of service. Many consumer and IoT data plans explicitly prohibit reselling connectivity or running servers, and operating a commercial proxy service on such plans can breach contract.<\/p>\n Everything above the hardware inherits its instability. Most production incidents in modem farms trace back to power, USB enumeration, heat or radio conditions, not to software.<\/p>\n There are four common device classes, each with different control surfaces.<\/p>\n USB dongles in HiLink mode.<\/strong> Devices such as the Huawei E3372 in its HiLink firmware variant present themselves to the host as a USB Ethernet adapter (CDC-ECM or RNDIS) and run their own internal router with a web UI, usually on . The host sees a NAT’d LAN connection, which means double NAT on top of the carrier’s CGNAT. They are simple to bring up but are controlled through the device’s HTTP API rather than standard Linux modem tooling, and every dongle defaults to the same subnet, which you must work around.<\/p>\n USB dongles in stick (modem) mode.<\/strong> The same hardware families with “stick” firmware expose serial AT ports and a QMI or MBIM data interface. These are managed by ModemManager, give the host the carrier-assigned IP directly, and integrate much more cleanly with Linux routing.<\/p>\n M.2 or mini PCIe modules on USB carrier boards.<\/strong> Industrial LTE and 5G modules, for example Quectel’s EC25 family for LTE or RM5xx series for 5G, mounted on USB adapter boards with external antennas. They cost more, but offer better thermal behavior, proper antenna connectors, documented AT command sets and longer product lifetimes. For any farm intended to run continuously, I consider modules the most defensible choice.<\/p>\n Android phones.<\/strong> Phones tethered over USB provide good radios and batteries that smooth out power fluctuations, but they introduce an entire operating system to manage, battery swelling risks when kept permanently charged, and control via ADB rather than standard modem interfaces. They are best treated as a niche option.<\/p>\n USB is the weakest link. Each modem enumerates as several interfaces and endpoints, and USB host controllers have finite endpoint and bandwidth resources. Large numbers of devices on one controller can produce enumeration failures that look like random modem crashes.<\/p>\n Practical guidance:<\/p>\n For that last point, the open-source tool uhubctl, from the GitHub repository mvp\/uhubctl<\/strong>, controls per-port power on hubs that implement it correctly. Hub compatibility varies, so check before buying hardware.<\/p>\n # List hubs that support per-port power switching<\/p>\n sudo uhubctl<\/p>\n # Power-cycle port 3 on hub 1-1.2<\/p>\n sudo uhubctl -l 1-1.2 -p 3 -a cycle -d 5<\/p>\n Cellular modems draw short current spikes during transmission, especially at the cell edge where they transmit at high power. An underpowered hub causes brown-outs that reset modems at random. Budget generously for hub power supplies, use short, good-quality cables, and avoid bus-powered hubs entirely.<\/p>\n Heat is the second silent killer. Densely packed dongles throttle or drop connections as they warm up. Provide airflow, space devices apart, and monitor module temperature where the hardware reports it through AT commands or ModemManager.<\/p>\n Signal quality affects throughput, latency and session stability. Use external antennas where the device supports them, place antennas away from the metal rack, and record signal metrics such as RSRP, RSRQ and SINR for every modem so you can correlate failures with radio conditions.<\/p>\n SIM management is an operational discipline of its own. Track each SIM’s ICCID, plan, APN, data limits and the physical slot it occupies. Many farms lose hours to a single misplaced SIM. Treat SIM inventory as configuration data stored alongside your infrastructure code.<\/p>\n For small farms, an x86 mini PC running a mainstream Linux distribution such as Debian or Ubuntu Server works well. Single-board computers can work for a handful of modems but often share limited USB bandwidth across all ports. Whatever you choose, use a recent kernel, because driver fixes for qmi_wwan, cdc_mbim and option arrive continuously.<\/p>\n Once hardware is connected, the host must reliably detect each modem, put it into the correct mode, bring up a data session and give the resulting network interface a stable identity. This is where most homegrown farms accumulate fragile shell scripts. A cleaner approach leans on the standard Linux tooling.<\/p>\n Many USB dongles first enumerate as a virtual CD-ROM containing Windows drivers. The usb_modeswitch package, together with its udev rules and device database, switches them into their networking mode automatically. Check lsusb before and after plugging in a device: the product ID usually changes once the switch succeeds.<\/p>\n sudo apt install usb-modeswitch usb-modeswitch-data modemmanager libqmi-utils libmbim-utils jq<\/p>\n lsusb<\/p>\n ModemManager is the standard Linux daemon for controlling mobile broadband devices. It speaks QMI, MBIM and AT protocols and exposes a uniform D-Bus API. Its command-line client, mmcli, is all you need for most automation, and it supports JSON output with -J, which makes scripting far less brittle than parsing human-readable text.<\/p>\n # List modems<\/p>\n mmcli -L<\/p>\n # Inspect modem 0 as JSON<\/p>\n mmcli -m 0 -J | jq ‘.modem.generic | {state, “equipment-identifier”, “signal-quality”}’<\/p>\n # Connect using the carrier’s APN<\/p>\n mmcli -m 0 –simple-connect=”apn=internet,ip-type=ipv4v6″<\/p>\n # Inspect the resulting bearer (index shown in the modem output)<\/p>\n mmcli -b 0 -J | jq ‘.bearer | {status, “ipv4-config”}’<\/p>\n The bearer output tells you which kernel network interface carries the session and the IP configuration the carrier assigned: address, prefix, gateway and DNS. Note that ModemManager does not configure the interface itself unless NetworkManager is driving it. If you use ModemManager standalone, as I recommend for farms, your own tooling must apply that configuration.<\/p>\n One trap catches nearly everyone. mmcli modem indexes (-m 0, -m 1) are assigned in detection order and increment whenever a modem re-enumerates. After a few resets, modem 3 may become modem 17. Never store indexes in configuration. Key everything on a stable hardware identifier, typically the IMEI reported as equipment-identifier, and resolve the current index at runtime.<\/p>\n #!\/usr\/bin\/env bash<\/p>\n # : print the current mmcli index for a given IMEI<\/p>\n set -euo pipefail<\/p>\n IMEI=”$1″<\/p>\n for path in $(mmcli -L -J | jq -r ‘.”modem-list”[]’); do<\/p>\n idx=”${path##*\/}”<\/p>\n if [[ “$(mmcli -m “$idx” -J | jq -r ‘.modem.generic.”equipment-identifier”‘)” == “$IMEI” ]]; then<\/p>\n echo “$idx”; exit 0<\/p>\n fi<\/p>\n done<\/p>\n echo “modem $IMEI not found” >&2; exit 1<\/p>\n Kernel interface names such as wwan0 or wwp0s20f0u3i4 either change with enumeration order or are cryptic. Assign deterministic names based on the physical USB path using systemd .link files. First, find the path:<\/p>\n udevadm info \/sys\/class\/net\/wwan0 | grep ID_PATH=<\/p>\n # E: ID_PATH=pci-0000:00:14.0-usb-0:2.3:1.4<\/p>\n Then create a link file that binds that path to a name you choose:<\/p>\n # \/etc\/systemd\/network\/<\/p>\n [Match]<\/p>\n Path=pci-0000:00:14.0-usb-0:2.3:1.4<\/p>\n [Link]<\/p>\n Name=wwm03<\/p>\n Now the modem in hub port 2.3 is always wwm03, regardless of enumeration order. Because the name is tied to the physical port, swapping a failed modem for a replacement in the same port preserves all downstream configuration. Your inventory then maps three identifiers together: physical port, IMEI and SIM ICCID.<\/p>\n<\/p>\n With ModemManager standalone, a small script reads the bearer configuration and applies it to the interface. For QMI devices, the kernel driver often needs raw-IP mode, which ModemManager typically sets; verify with cat \/sys\/class\/net\/<iface>\/qmi\/raw_ip.<\/p>\n #!\/usr\/bin\/env bash<\/p>\n # <imei> <ifname> <apn><\/p>\n set -euo pipefail<\/p>\n IMEI=”$1″; IFACE=”$2″; APN=”$3″<\/p>\n M=$(\/usr\/local\/bin\/ “$IMEI”)<\/p>\n mmcli -m “$M” –enable<\/p>\n mmcli -m “$M” –simple-connect=”apn=${APN},ip-type=ipv4″<\/p>\n B=$(mmcli -m “$M” -J | jq -r ‘.modem.generic.bearers[0]’ | awk -F\/ ‘{print $NF}’)<\/p>\n CFG=$(mmcli -b “$B” -J)<\/p>\n ADDR=$(jq -r ‘.bearer.”ipv4-config”.address’ <<<“$CFG”)<\/p>\n PFX=$(jq -r ‘.bearer.”ipv4-config”.prefix’ <<<“$CFG”)<\/p>\n GW=$(jq -r ‘.bearer.”ipv4-config”.gateway’ <<<“$CFG”)<\/p>\n ip link set “$IFACE” up<\/p>\n ip addr flush dev “$IFACE”<\/p>\n ip addr add “${ADDR}\/${PFX}” dev “$IFACE”<\/p>\n echo “$GW” > “\/run\/modems\/${IFACE}.gw”<\/p>\n Notice what the script deliberately does not do: it does not add a default route. With dozens of modems, adding default routes to the main routing table would make the host’s egress unpredictable. Routing is handled separately, per modem, which is the subject of the next section.<\/p>\n Also tell NetworkManager, if installed, to leave these interfaces alone, for example with an unmanaged-devices=interface-name:wwm* entry in its configuration. Two daemons fighting over the same interface is a classic source of intermittent failures.<\/p>\n The central networking requirement of a proxy farm is simple to state and easy to get wrong: traffic entering the proxy for modem N must leave through modem N, and only modem N.<\/strong> If a modem drops, its traffic must fail rather than silently leak out of another modem or the host’s wired uplink. That leak would expose the wrong IP, break client expectations and potentially route customer traffic through infrastructure it should never touch.<\/p>\n There are two mainstream ways to achieve this on Linux<\/a>: policy-based routing in a shared network stack, and network namespaces. I strongly prefer namespaces for anything beyond a few modems, but understanding policy routing helps explain why.<\/p>\n Linux supports multiple routing tables and rules that choose a table based on packet attributes. You give each modem its own table, place a default route through that modem in it, and add a rule saying traffic sourced from that modem’s address uses that table.<\/p>\n # Table 103 for wwm03<\/p>\n IFACE=wwm03<\/p>\n TABLE=103<\/p>\n ADDR=$(ip -4 -o addr show dev $IFACE | awk ‘{print $4}’ | cut -d\/ -f1)<\/p>\n ip route replace default dev $IFACE table $TABLE<\/p>\n ip rule add from $ADDR lookup $TABLE priority 1000$((TABLE % 100))<\/p>\n For raw-IP point-to-point interfaces, a device route without a gateway is sufficient; for Ethernet-style interfaces such as HiLink dongles, add via <gateway>. The proxy daemon must then bind its outgoing sockets to the modem’s source address.<\/p>\n This works, but it is fragile at scale. Every rotation changes the source address, so rules must be rewritten atomically. A process that forgets to bind its source address falls through to the main table and leaks. DNS lookups made by the proxy may go out the wrong interface unless handled carefully. And all modems share one conntrack table and one set of firewall rules, which complicates debugging.<\/p>\n An alternative within this model is marking packets with an fwmark per user or per listening port and routing by mark, but it inherits the same leak-on-misconfiguration property.<\/p>\n A network namespace is an isolated copy of the Linux network stack: its own interfaces, routing tables, firewall rules and sockets. If you move a modem’s interface into a dedicated namespace and run that modem’s proxy process inside the same namespace, the only path to the internet that process can see is the modem. When the modem goes down, the namespace has no default route, and connections fail closed. Isolation becomes a property of the structure rather than of correct rule-writing.<\/p>\n The architecture looks like this:<\/p>\n +——————- host (root netns) ——————-+<\/p>\n client –TCP–> | eth0 :20003 –DNAT–> veth-h03 |<\/p>\n | | |<\/p>\n | +—— netns m03 —–v———————–+ |<\/p>\n | | veth-n03 <- proxy listens | |<\/p>\n | | wwm03 (modem) default route -> internet | |<\/p>\n | +———————————————–+ |<\/p>\n +———————————————————+<\/p>\n The setup script:<\/p>\n #!\/usr\/bin\/env bash<\/p>\n # <id> <ifname><\/p>\n set -euo pipefail<\/p>\n ID=”$1″; IFACE=”$2″<\/p>\n NS=”m${ID}”<\/p>\n VH=”veth-h${ID}”; VN=”veth-n${ID}”<\/p>\n HOST_IP=”10.200.${ID#0}.1″; NS_IP=”10.200.${ID#0}.2″<\/p>\n ip netns add “$NS” 2>\/dev\/null || true<\/p>\n ip link set “$IFACE” netns “$NS”<\/p>\n ip link add “$VH” type veth peer name “$VN”<\/p>\n ip link set “$VN” netns “$NS”<\/p>\n ip addr add “${HOST_IP}\/30” dev “$VH”; ip link set “$VH” up<\/p>\n ip netns exec “$NS” ip link set lo up<\/p>\n ip netns exec “$NS” ip addr add “${NS_IP}\/30” dev “$VN”<\/p>\n ip netns exec “$NS” ip link set “$VN” up<\/p>\n ip netns exec “$NS” ip link set “$IFACE” up<\/p>\n # The modem is the ONLY default route inside the namespace<\/p>\n ip netns exec “$NS” ip route replace default dev “$IFACE”<\/p>\n Two details are easy to miss.<\/p>\n Moving the interface resets its addressing.<\/strong> When an interface changes namespace, its addresses are removed. Run the bring-up logic from the previous section after the move, executing the ip addr commands inside the namespace with ip netns exec. ModemManager itself stays in the root namespace, because it talks to the modem over USB control ports, not through the network interface.<\/p>\n DNS must be namespace-local.<\/strong> ip netns exec bind-mounts files from \/etc\/netns\/<name>\/ over their \/etc counterparts, so you can give each namespace its own resolver configuration, ideally pointing at the carrier DNS servers reported in the bearer:<\/p>\n mkdir -p \/etc\/netns\/m03<\/p>\n printf ‘nameserver %s\\n’ $DNS1 $DNS2 > \/etc\/netns\/m03\/resolv.conf<\/p>\n This prevents a subtle leak in which proxied connections exit through the modem but DNS lookups exit through the host’s uplink, revealing a different network to the resolver and producing geolocation mismatches.<\/p>\n The proxy inside each namespace listens on its veth address. On the host, a DNAT rule maps a public port to that address. Using nftables:<\/p>\n # \/etc\/nftables.d\/proxy-farm.nft<\/p>\n table ip farm {<\/p>\n chain prerouting {<\/p>\n type nat hook prerouting priority dstnat; policy accept;<\/p>\n tcp dport 20003 dnat to <\/p>\n tcp dport 21003 dnat to <\/p>\n }<\/p>\n chain forward {<\/p>\n type filter hook forward priority filter; policy drop;<\/p>\n ct state established,related accept<\/p>\n iifname “eth0” oifname “veth-h*” ip daddr tcp dport { 3128, 1080 } accept<\/p>\n }<\/p>\n }<\/p>\n Enable forwarding with sysctl -w net.ipv4.ip_forward=1. Note the forward chain’s default drop policy: nothing from the namespaces can traverse the host toward its own uplink unless explicitly allowed, which closes the last leak path.<\/p>\n In larger designs, clients do not connect to individual modem ports at all. A front-door gateway authenticates the client, chooses a modem according to sticky-session or rotation policy, and forwards to the right namespace. I return to that pattern in the Kubernetes section.<\/p>\n With one isolated namespace per modem, the proxy daemon becomes almost trivial: it listens on the namespace’s veth address and opens outbound connections normally, because the only route available is the modem. Two mature open-source daemons dominate small and mid-sized deployments.<\/p>\n 3proxy, maintained by Vladimir Dubrovin and hosted on GitHub as z3APA3A\/3proxy<\/strong> (also mirrored under the 3proxy<\/strong> organization), is a compact C proxy server that bundles HTTP\/HTTPS (CONNECT), SOCKS4\/5 and several other proxy services in a single binary. It is lightweight, which matters when you run one instance per modem, and its configuration language is terse.<\/p>\n A per-modem configuration:<\/p>\n # \/etc\/3proxy\/m03.cfg<\/p>\n nserver # replace with carrier DNS from the bearer<\/p>\n nscache 65536<\/p>\n timeouts 1 5 30 60 180 1800 15 60<\/p>\n log \/var\/log\/3proxy\/m03.log D<\/p>\n logformat “L%Y-%m-%dT%H:%M:%S %N %p %E %U %C:%c %R:%r %O %I %T”<\/p>\n rotate 14<\/p>\n users alice:CR:$1$Qn3b$exampleexampleexample0<\/p>\n auth strong<\/p>\n allow alice<\/p>\n maxconn 500<\/p>\n proxy -p3128 -i10.200.3.2<\/p>\n socks -p1080 -i10.200.3.2<\/p>\n A few notes. -i sets the internal address the service listens on. 3proxy also offers -e to set the external address used for outgoing connections, which is how you would pin egress in a policy-routing design; with namespaces it is unnecessary, because the namespace already constrains egress. The CR user type stores a crypt-style hash rather than a cleartext password; avoid cleartext credentials in configuration files. auth strong requires username and password authentication, and the allow line restricts which users may use the services that follow.<\/p>\n GOST (GO Simple Tunnel) is a Go-based tunnel and proxy toolkit. Version 3, a substantial refactor, lives in the GitHub repository go-gost\/gost<\/strong>; the legacy version 2 remains at ginuerzh\/gost<\/strong>, and the two differ in configuration syntax, so check which documentation you are reading. GOST supports HTTP, SOCKS5, chaining, rate limiting, admission control, dynamic configuration through a web API, and Prometheus metrics, which makes it attractive when you want the proxy itself to expose operational data.<\/p>\n The simplest invocation, run inside the namespace:<\/p>\n ip netns exec m03 gost \\<\/p>\n -L “” \\<\/p>\n -L “socks5:\/\/alice:s3cret@10.200.3.2:1080”<\/p>\n For real deployments, prefer a YAML configuration so credentials are not visible in the process list:<\/p>\n # \/etc\/gost\/m03.yaml<\/p>\n services:<\/p>\n – name: m03-http<\/p>\n addr: <\/p>\n handler:<\/p>\n type: http<\/p>\n auther: users<\/p>\n listener:<\/p>\n type: tcp<\/p>\n – name: m03-socks<\/p>\n addr: <\/p>\n handler:<\/p>\n type: socks5<\/p>\n auther: users<\/p>\n listener:<\/p>\n type: tcp<\/p>\n authers:<\/p>\n – name: users<\/p>\n auths:<\/p>\n – username: alice<\/p>\n password: s3cret<\/p>\n metrics:<\/p>\n addr: <\/p>\n path: \/metrics<\/p>\n Verify field names against the version you deploy; GOST’s configuration schema has evolved across release candidates.<\/p>\n On a single host without containers, systemd can run each proxy inside its namespace through a template unit. The NetworkNamespacePath= directive places the service in an existing namespace:<\/p>\n # \/etc\/systemd\/system\/farm-proxy@.service<\/p>\n [Unit]<\/p>\n Description=Proxy for modem namespace %i<\/p>\n After=network-online.target<\/p>\n [Service]<\/p>\n NetworkNamespacePath=\/run\/netns\/%i<\/p>\n ExecStart=\/usr\/local\/bin\/3proxy \/etc\/3proxy\/%i.cfg<\/p>\n Restart=always<\/p>\n RestartSec=2<\/p>\n DynamicUser=yes<\/p>\n CapabilityBoundingSet=<\/p>\n NoNewPrivileges=yes<\/p>\n ProtectSystem=strict<\/p>\n LogsDirectory=3proxy<\/p>\n [Install]<\/p>\n WantedBy=multi-user.target<\/p>\n Then systemctl enable –now farm-proxy@m03. Because the listening ports are above 1024, the service needs no special capabilities, so the hardening directives cost nothing.<\/p>\n HTTP proxies handle plain HTTP requests and tunnel HTTPS through CONNECT. SOCKS5 carries arbitrary TCP and, where supported, UDP via UDP ASSOCIATE. Offering both is standard. If clients use SOCKS5 with remote DNS resolution, the proxy resolves hostnames inside the namespace, which keeps DNS consistent with the egress network. With local resolution on the client side, the client’s DNS reveals its own network, a frequent source of geolocation inconsistencies that customers misattribute to the proxy.<\/p>\n UDP deserves caution. Carrier NATs often have short UDP mapping timeouts, and UDP traffic is disproportionately associated with abuse such as amplification attacks. Many operators disable UDP relay entirely unless a customer has a specific, vetted need.<\/p>\n Rotation means forcing the carrier to assign a new session, which usually, though not always, yields a different public egress IP behind the carrier’s NAT. It is the feature customers ask about first and the one that causes the most operational damage when implemented carelessly.<\/p>\n There are three levels of intervention, from gentle to brutal.<\/p>\n 1. Bearer reconnect.<\/strong> Tear down and re-establish the data session. With ModemManager:<\/p>\n M=$(\/usr\/local\/bin\/ “$IMEI”)<\/p>\n mmcli -m “$M” –simple-disconnect<\/p>\n sleep 2<\/p>\n mmcli -m “$M” –simple-connect=”apn=${APN},ip-type=ipv4″<\/p>\n This is fast and usually sufficient to obtain a new private address. Whether the public address changes depends on how the carrier’s NAT assigns pool addresses.<\/p>\n 2. Radio power cycle (“airplane mode”).<\/strong> Put the modem’s radio into a low-power state, then back on, forcing it to detach from and re-attach to the network. ModemManager exposes this as power states:<\/p>\n mmcli -m “$M” –set-power-state-low<\/p>\n sleep 5<\/p>\n mmcli -m “$M” –set-power-state-on<\/p>\n mmcli -m “$M” –simple-connect=”apn=${APN},ip-type=ipv4″<\/p>\n Re-attachment takes longer than a bearer reconnect, but more reliably produces a fresh network-side context.<\/p>\n 3. Hard reset.<\/strong> Cut USB power with per-port switching. This is a recovery mechanism, not a rotation mechanism. Using it routinely causes re-enumeration, new mmcli indexes, interface churn and long downtime.<\/p>\n For HiLink dongles, rotation goes through the device’s HTTP API instead. The Python library Salamek\/huawei-lte-api<\/strong> on GitHub wraps that API for many Huawei LTE routers and USB sticks, including the E3372, and exposes calls such as toggling the mobile data switch. Because every HiLink dongle sits at the same default address, you must either change each device’s LAN subnet in its settings or reach each one from inside its own namespace, which the namespace design already provides.<\/p>\n Rotation interrupts every connection currently flowing through that modem. If two customers share a modem and one triggers a rotation, the other loses their sessions. A rotation service therefore needs:<\/p>\n The following FastAPI sketch shows the shape of such a service. It runs on the host, in the root namespace, because it needs ModemManager over D-Bus, and it checks the public IP from inside the modem’s namespace.<\/p>\n # <\/p>\n import asyncio, json, os, time<\/p>\n from fastapi import FastAPI, HTTPException<\/p>\n INVENTORY = json.load(open(“\/etc\/farm\/modems.json”)) # id -> {imei, apn, netns}<\/p>\n COOLDOWN_S = 120<\/p>\n IP_ECHO_URL = os.environ[“IP_ECHO_URL”] # an IP-echo endpoint you operate<\/p>\n locks = {mid: asyncio.Lock() for mid in INVENTORY}<\/p>\n last_rotation: dict[str, float] = {}<\/p>\n app = FastAPI()<\/p>\n async def run(*cmd: str, timeout: float = 60) -> str:<\/p>\n p = await asyncio.create_subprocess_exec(<\/p>\n *cmd, stdout=asyncio.subprocess.PIPE, stderr=asyncio.subprocess.PIPE)<\/p>\n out, err = await asyncio.wait_for(p.communicate(), timeout)<\/p>\n if p.returncode != 0:<\/p>\n raise RuntimeError(f”{cmd[0]} failed: {err.decode().strip()}”)<\/p>\n return out.decode().strip()<\/p>\n async def public_ip(netns: str) -> str:<\/p>\n return await run(“ip”, “netns”, “exec”, netns,<\/p>\n “curl”, “-s”, “–max-time”, “10”, IP_ECHO_URL)<\/p>\n @app.post(“\/modems\/{mid}\/rotate”)<\/p>\n async def rotate(mid: str):<\/p>\n m = INVENTORY.get(mid)<\/p>\n if m is None:<\/p>\n raise HTTPException(404, “unknown modem”)<\/p>\n if time.monotonic() – last_rotation.get(mid, 0) < COOLDOWN_S:<\/p>\n raise HTTPException(429, “cooldown active”)<\/p>\n if locks[mid].locked():<\/p>\n raise HTTPException(409, “rotation in progress”)<\/p>\n async with locks[mid]:<\/p>\n before = await public_ip(m[“netns”])<\/p>\n idx = await run(“\/usr\/local\/bin\/”, m[“imei”])<\/p>\n await run(“mmcli”, “-m”, idx, “–set-power-state-low”)<\/p>\n await asyncio.sleep(5)<\/p>\n await run(“mmcli”, “-m”, idx, “–set-power-state-on”)<\/p>\n await run(“\/usr\/local\/bin\/”, m[“imei”], mid, m[“apn”], timeout=90)<\/p>\n after = await public_ip(m[“netns”])<\/p>\n last_rotation[mid] = time.monotonic()<\/p>\n return {“modem”: mid, “before”: before, “after”: after,<\/p>\n “changed”: before != after}<\/p>\n In production you would add authentication, persist cooldown state, emit metrics, and replace the external IP-echo service with one you operate yourself, both for reliability and to avoid sending your fleet’s egress IPs to a third party. Note also that from earlier must be adapted to run its ip commands inside the namespace once the interface has been moved.<\/p>\n Customers generally want one of two behaviors. Sticky<\/strong> sessions keep a client on the same modem, and therefore the same IP, for a period, which matters for workflows like logged-in QA sessions. Rotating<\/strong> pools assign a different modem per connection or per time window. The gateway layer implements both by mapping a session token embedded in the proxy username, for example alice-session-abc123, to a modem, with a time-to-live. This is a common convention in commercial proxy services and is easy to parse at the gateway.<\/p>\n Containers bring reproducible builds, versioned deployments and resource limits to the proxy layer. They do not change the fundamental constraint: a modem is a physical device attached to a specific host, and its network interface lives in that host’s kernel.<\/p>\n A small multi-stage build for 3proxy:<\/p>\n # Dockerfile<\/p>\n FROM debian:bookworm-slim AS build<\/p>\n RUN apt-get update && apt-get install -y –no-install-recommends \\<\/p>\n build-essential git ca-certificates && rm -rf \/var\/lib\/apt\/lists\/*<\/p>\n # Pass the 3proxy repository’s git URL with –build-arg<\/p>\n ARG THREEPROXY_REPO<\/p>\n ARG THREEPROXY_REF=master<\/p>\n RUN git clone –depth 1 –branch ${THREEPROXY_REF} ${THREEPROXY_REPO} \/src<\/p>\n WORKDIR \/src<\/p>\n RUN ln -s Makefile.Linux Makefile && make<\/p>\n FROM debian:bookworm-slim<\/p>\n COPY –from=build \/src\/bin\/3proxy \/usr\/local\/bin\/3proxy<\/p>\n RUN useradd -r -u 10001 proxy<\/p>\n USER 10001<\/p>\n ENTRYPOINT [“\/usr\/local\/bin\/3proxy”]<\/p>\n CMD [“\/etc\/3proxy\/3proxy.cfg”]<\/p>\n Pin THREEPROXY_REF to a release tag rather than a moving branch in production, and confirm the output binary path for the version you build. Official images also exist on Docker Hub for both 3proxy and GOST (gogost\/gost), which may be preferable to building your own.<\/p>\n Docker does not natively attach containers to arbitrary named network namespaces. There are three workable patterns.<\/p>\n Pattern 1: move the interface into the container’s namespace.<\/strong> Start the container with no networking, find its PID, and move both the modem interface and a veth end into its namespace:<\/p>\n CID=$(docker run -d –name proxy-m03 –network none \\<\/p>\n -v \/etc\/3proxy\/m03.cfg:\/etc\/3proxy\/3proxy.cfg:ro farm\/3proxy:1.0)<\/p>\n PID=$(docker inspect -f ‘{{.State.Pid}}’ “$CID”)<\/p>\n mkdir -p \/run\/netns && ln -sf \/proc\/$PID\/ns\/net \/run\/netns\/c-m03<\/p>\n ip link set wwm03 netns c-m03<\/p>\n # …then create the veth pair, addresses and default route as in <\/p>\n This yields the same isolation as the bare-metal namespace design, with the proxy packaged as an image. The cost is that a container restart destroys the namespace and returns the modem interface to the host, so the attach logic must run again on every restart.<\/p>\n Pattern 2: use Podman instead.<\/strong> Podman supports joining an existing namespace directly with –network ns:\/run\/netns\/m03, which keeps the namespace, and the modem inside it, stable across container restarts. For single-host farms, this is the cleanest option I know of.<\/p>\n Pattern 3: host networking with explicit egress binding.<\/strong> Run with –network host and pin egress with policy routing and the proxy’s external-address option. It is simple, but you lose namespace isolation and inherit all the leak risks of Option A.<\/p>\n Kubernetes<\/a> is worthwhile once you manage several farm hosts, want declarative rollouts, and need a control plane for gateways, rotation APIs, billing and monitoring. Lightweight distributions such as k3s are common at the edge. The key design decision is separating node-local hardware management<\/strong> from per-modem proxy workloads<\/strong>.<\/p>\n Modem management touches USB devices, D-Bus and the root network namespace, so it runs as a DaemonSet with host access, scheduled only on nodes labeled as modem hosts:<\/p>\n apiVersion: apps\/v1<\/p>\n kind: DaemonSet<\/p>\n metadata:<\/p>\n name: modem-agent<\/p>\n namespace: farm-system<\/p>\n spec:<\/p>\n selector:<\/p>\n matchLabels: {app: modem-agent}<\/p>\n template:<\/p>\n metadata:<\/p>\n labels: {app: modem-agent}<\/p>\n spec:<\/p>\n nodeSelector:<\/p>\n : “true”<\/p>\n hostNetwork: true<\/p>\n hostPID: true<\/p>\n containers:<\/p>\n – name: agent<\/p>\n image: <\/p>\n securityContext:<\/p>\n privileged: true<\/p>\n volumeMounts:<\/p>\n – {name: dbus, mountPath: \/run\/dbus}<\/p>\n – {name: farm-run, mountPath: \/run\/farm}<\/p>\n – {name: dev, mountPath: \/dev}<\/p>\n volumes:<\/p>\n – {name: dbus, hostPath: {path: \/run\/dbus}}<\/p>\n – {name: farm-run, hostPath: {path: \/run\/farm, type: DirectoryOrCreate}}<\/p>\n – {name: dev, hostPath: {path: \/dev}}<\/p>\n The agent talks to the host’s ModemManager, keeps sessions connected, executes rotations, and writes each modem’s current bearer configuration to \/run\/farm\/<modem-id>.json. It also publishes inventory, for example as node labels or as a custom resource, so the scheduler and gateway know which modems exist on which node.<\/p>\n Each modem then gets its own proxy pod, pinned to the node that physically holds it. To hand the modem interface to the pod, use Multus<\/strong>, the meta-CNI plugin from the GitHub repository k8snetworkplumbingwg\/multus-cni<\/strong>, together with the host-device plugin from containernetworking\/plugins<\/strong>, which moves an existing host interface into a pod’s network namespace.<\/p>\n apiVersion: <\/p>\n kind: NetworkAttachmentDefinition<\/p>\n metadata:<\/p>\n name: modem-wwm03<\/p>\n namespace: farm<\/p>\n spec:<\/p>\n config: |<\/p>\n {<\/p>\n “cniVersion”: “0.4.0”,<\/p>\n “type”: “host-device”,<\/p>\n “device”: “wwm03”<\/p>\n }<\/p>\n The pod keeps its normal cluster interface for inbound connections from the gateway, plus the modem as a secondary interface. A small sidecar with NET_ADMIN applies the address from the agent’s bearer file and replaces the pod’s default route with the modem, while keeping a specific route for the cluster pod and service CIDRs on eth0, so the gateway can still reach the proxy:<\/p>\n apiVersion: apps\/v1<\/p>\n kind: Deployment<\/p>\n metadata:<\/p>\n name: proxy-m03<\/p>\n namespace: farm<\/p>\n spec:<\/p>\n replicas: 1<\/p>\n strategy: {type: Recreate}<\/p>\n selector:<\/p>\n matchLabels: {app: farm-proxy, modem: m03}<\/p>\n template:<\/p>\n metadata:<\/p>\n labels: {app: farm-proxy, modem: m03}<\/p>\n annotations:<\/p>\n : modem-wwm03<\/p>\n spec:<\/p>\n nodeSelector:<\/p>\n : farm-node-01<\/p>\n containers:<\/p>\n – name: proxy<\/p>\n image: <\/p>\n ports: [{containerPort: 3128}, {containerPort: 1080}]<\/p>\n livenessProbe:<\/p>\n exec: {command: [“\/bin\/sh”, “-c”, “ip link show wwm03 | grep -q UP”]}<\/p>\n periodSeconds: 15<\/p>\n – name: netcfg<\/p>\n image: <\/p>\n env: [{name: MODEM_ID, value: m03}, {name: CLUSTER_CIDRS, value: “”}]<\/p>\n securityContext:<\/p>\n capabilities: {add: [“NET_ADMIN”]}<\/p>\n volumeMounts: [{name: farm-run, mountPath: \/run\/farm, readOnly: true}]<\/p>\n volumes:<\/p>\n – {name: farm-run, hostPath: {path: \/run\/farm}}<\/p>\n The Recreate strategy matters: a rolling update would try to start a second pod requesting the same physical interface while the first still holds it.<\/p>\n One caveat deserves emphasis. If a modem re-enumerates on USB, the kernel destroys its interface, and the replacement appears in the host’s root namespace, not in the pod. The liveness probe above catches this and restarts the pod, at which point Multus attaches the new interface. Expect that cycle to cost tens of seconds per incident; it is one more reason to invest in stable power and USB.<\/p>\n Clients should not connect to individual modem pods. A gateway Deployment, exposed through a LoadBalancer or NodePort Service, authenticates clients, applies sticky-session or rotation policy, enforces rate limits and acceptable-use rules, and forwards each connection to the chosen modem pod via a per-modem ClusterIP Service selecting modem: <id>. GOST’s chaining and dynamic configuration API can implement much of this; larger operators typically write a dedicated gateway so policy, billing and logging live in one place.<\/p>\n Manifests for dozens of modems should be generated rather than written by hand. A Helm chart or Kustomize overlay that renders one NetworkAttachmentDefinition, Deployment and Service per inventory entry keeps the cluster state aligned with the physical inventory file.<\/p>\n Before buying hardware, it helps to reason about where the bottlenecks will be. They rarely sit where newcomers expect.<\/p>\n Radio throughput is variable and shared.<\/strong> A modem’s throughput depends on the cell’s load, signal quality, carrier aggregation support and the plan’s traffic shaping. Advertised category speeds describe the radio’s theoretical ceiling, not what a crowded cell will deliver at 8 p.m. Measure real throughput per site at different times of day before committing to customer bandwidth guarantees.<\/p>\n Uplink is usually the scarcer direction.<\/strong> Cellular networks allocate far less capacity to uplink than downlink. Workloads that upload heavily, such as posting media, will saturate a modem much faster than browsing workloads.<\/p>\n Data caps and fair-use policies dominate economics.<\/strong> Many “unlimited” plans throttle after a fair-use threshold. Track consumption per SIM in near real time and route traffic away from SIMs approaching their limits, otherwise a single heavy customer can degrade a modem for everyone sharing it.<\/p>\n Host resources are rarely the constraint.<\/strong> A proxy process per modem consumes little CPU and memory at typical traffic volumes. The host’s real constraints are USB topology and power, discussed earlier. Size the host for observability tooling, logging and headroom rather than for proxy throughput.<\/p>\n Concurrency per modem should be capped.<\/strong> Carrier NAT tables limit concurrent sessions per subscriber, and exceeding them causes connection failures that look like random proxy errors. Set maxconn in 3proxy, or the equivalent limiter in GOST, to a conservative value per modem and tune upward based on observed error rates.<\/p>\n A useful planning exercise is to model each modem as a resource with four budgets: throughput, uplink, monthly data and concurrent connections. The gateway’s scheduling logic should be aware of all four, not only of which modems are online.<\/p>\n Most incidents fall into a small number of recognizable patterns. Knowing them shortens recovery dramatically.<\/p>\n Check the kernel log first with journalctl -k or dmesg. Messages about USB disconnects, over-current or descriptor read errors point to power or cabling. If the device still appears in lsusb but not in ModemManager, the modem may be stuck in a state that ModemManager cannot probe; restart ModemManager or power-cycle the port with uhubctl.<\/p>\n Compare the registration state and operator shown by mmcli -m <idx> with expectations. A wrong APN, an exhausted data allowance, a SIM PIN or a suspended SIM all produce connection failures. Many carriers send an SMS when a plan is exhausted; ModemManager can list messages with mmcli -m <idx> –messaging-list-sms, which is worth automating.<\/p>\n The modem has an address but packets go nowhere. For QMI devices, check raw-IP mode. Inside the namespace, confirm the interface is up, the address is applied and the default route points at the modem:<\/p>\n ip netns exec m03 ip -br addr<\/p>\n ip netns exec m03 ip route<\/p>\n ip netns exec m03 ping -c 3 -I wwm03 <\/p>\n If ping by IP works but hostnames fail, the namespace’s resolver configuration is wrong or missing.<\/p>\n This is almost always a leak: the proxy process is not running in the namespace you think it is, or a policy-routing rule fell through to the main table. Check which namespace a process belongs to with ip netns identify <pid>, and test egress from inside the namespace rather than from the host.<\/p>\n Some carriers reassign the same public NAT address to a subscriber for a while. Lengthening the low-power interval sometimes helps; on some networks only waiting does. Report it to customers honestly rather than retrying aggressively, which risks flagging the SIM.<\/p>\n Correlate the timestamps with temperature and signal metrics. Disconnects that cluster during hot afternoons point to thermal problems; disconnects that follow poor SINR point to radio conditions; disconnects across many modems at once point to a shared hub or power supply.<\/p>\n Every script in this guide depends on one piece of data: a reliable mapping between logical modem IDs, physical USB ports, IMEIs, SIMs, APNs and network namespaces. Keep that mapping in a version-controlled file and generate everything else from it, including systemd .link files, 3proxy configs, nftables rules and Kubernetes manifests.<\/p>\n A minimal inventory:<\/p>\n {<\/p>\n “m03”: {<\/p>\n “node”: “farm-node-01”,<\/p>\n “usb_path”: “pci-0000:00:14.0-usb-0:2.3:1.4”,<\/p>\n “ifname”: “wwm03”,<\/p>\n “imei”: “860000000000003”,<\/p>\n “iccid”: “8900000000000000003”,<\/p>\n “carrier”: “example-mno”,<\/p>\n “apn”: “internet”,<\/p>\n “netns”: “m03”,<\/p>\n “ports”: {“http”: 20003, “socks5”: 21003},<\/p>\n “limits”: {“maxconn”: 300, “monthly_gb”: 200}<\/p>\n }<\/p>\n }<\/p>\n A small generator renders configuration from it. Using Python and Jinja2 templates:<\/p>\n # <\/p>\n import json, pathlib<\/p>\n from jinja2 import Environment, FileSystemLoader<\/p>\n inv = json.load(open(“inventory.json”))<\/p>\n env = Environment(loader=FileSystemLoader(“templates”), keep_trailing_newline=True)<\/p>\n out = pathlib.Path(“build”)<\/p>\n for mid, m in inv.items():<\/p>\n for tpl, dest in [(“link.j2″, f”systemd\/10-{m[‘ifname’]}.link”),<\/p>\n (“3proxy.cfg.j2″, f”3proxy\/{mid}.cfg”),<\/p>\n (“deployment.yaml.j2″, f”k8s\/{mid}.yaml”)]:<\/p>\n path = out \/ dest<\/p>\n path.parent.mkdir(parents=True, exist_ok=True)<\/p>\n path.write_text(env.get_template(tpl).render(id=mid, **m))<\/p>\n The benefits compound. Replacing a failed modem becomes a one-line change to the IMEI. Moving a SIM to another slot is a reviewed commit instead of a late-night edit on a production host. Auditing which customer used which SIM on which date becomes a matter of reading the history of one file alongside your logs.<\/p>\n Treat SIM identifiers in the inventory as sensitive. ICCIDs and IMEIs are not secrets in the cryptographic sense, but they link infrastructure to carrier accounts and should not live in public repositories.<\/p>\n The gateway is the component that turns a collection of modems into a service. Its core logic is simple to describe: authenticate the client, parse any session or targeting parameters from the proxy username, select a modem, and relay the connection.<\/p>\n The username convention mentioned earlier carries routing intent without any custom client software. A client configures a standard proxy URL whose username looks like alice-session-7f3a-ttl-600, and the gateway decodes it:<\/p>\n # (excerpt)<\/p>\n import re, time, random<\/p>\n PATTERN = re.compile(r”^(?P<user>[a-z0-9]+)(?:-session-(?P<sid>[a-z0-9]+))?(?:-ttl-(?P<ttl>\\d+))?$”)<\/p>\n sticky: dict[tuple[str, str], tuple[str, float]] = {}<\/p>\n def pick_modem(username: str, healthy: list[str]) -> tuple[str, str]:<\/p>\n m = PATTERN.match(username)<\/p>\n if not m:<\/p>\n raise ValueError(“malformed username”)<\/p>\n user, sid = m[“user”], m[“sid”]<\/p>\n ttl = min(int(m[“ttl”] or 600), 3600)<\/p>\n if sid:<\/p>\n key = (user, sid)<\/p>\n modem, expires = sticky.get(key, (None, 0))<\/p>\n if modem in healthy and expires > time.time():<\/p>\n return user, modem<\/p>\n modem = random.choice(healthy)<\/p>\n sticky[key] = (modem, time.time() + ttl)<\/p>\n return user, modem<\/p>\n return user, random.choice(healthy)<\/p>\n A production gateway replaces the in-memory dictionary with a shared store such as Redis so that multiple gateway replicas agree on session assignments, weights selection by each modem’s remaining budgets from the capacity model, and caps the TTL so a single customer cannot pin a modem indefinitely. It also enforces per-customer concurrency and bandwidth quotas before a connection ever reaches a modem, which protects shared modems from one noisy tenant.<\/p>\n For the relay itself, you can either implement HTTP CONNECT and SOCKS5 in the gateway or chain to the per-modem proxies and let them handle the protocol. Chaining is simpler and keeps the gateway thin; GOST’s forwarding chains are designed for this pattern. Implementing protocols directly gives finer control over logging and admission decisions. Many teams start with chaining and move protocol handling into the gateway only when they need it.<\/p>\n Whichever approach you choose, log every admission decision with the customer, modem, destination host and outcome. Those records are what you will need when an abuse report arrives.<\/p>\n A farm should be tested like any other distributed system, with particular attention to failure paths.<\/p>\n Leak tests.<\/strong> For every modem, take its interface down and confirm that connections through its proxy fail rather than succeeding through another route. Then bring it up and confirm that the reported public IP belongs to the expected carrier. Automate this check and run it after every deployment.<\/p>\n DNS consistency tests.<\/strong> Resolve a test hostname through each proxy with remote resolution and confirm that the queries arrive from the carrier’s resolver, not from your uplink. If you operate your own authoritative DNS for a test domain, its query logs make this straightforward.<\/p>\n Rotation tests.<\/strong> Trigger rotations under load and measure how long the modem takes to return, how many in-flight connections fail, and how often the public IP actually changes. These numbers become the honest figures you quote to customers.<\/p>\n Chaos tests.<\/strong> Power-cycle random USB ports with uhubctl during business hours on a staging rack, and confirm that the node agent, liveness probes and gateway health checks recover without manual intervention.<\/p>\n Security tests.<\/strong> From inside a proxy session, attempt to reach private ranges, the metadata address and your management network. Every attempt should fail. Attempt unauthenticated connections to every exposed port; every one should be refused.<\/p>\n Run these tests on a schedule, not only at launch. Carrier behavior, firmware and kernel drivers all change underneath you.<\/p>\n A modem farm without metrics is a farm you debug by guessing. Every modem should report radio, session and proxy health, and every alert should identify a modem by its stable ID, not by an mmcli index.<\/p>\n The metrics worth collecting fall into four groups:<\/p>\n A small exporter in the node agent can translate mmcli JSON into Prometheus metrics:<\/p>\n # signal_exporter.py (excerpt)<\/p>\n from prometheus_client import Gauge, start_http_server<\/p>\n import json, subprocess, time<\/p>\n RSRP = Gauge(“modem_rsrp_dbm”, “LTE RSRP”, [“modem”])<\/p>\n UP = Gauge(“modem_bearer_connected”, “Bearer connected”, [“modem”])<\/p>\n def mm(*args):<\/p>\n return json.loads(subprocess.check_output([“mmcli”, *args, “-J”]))<\/p>\n def scrape(mid, idx):<\/p>\n sig = mm(“-m”, idx, “–signal-get”)[“modem”][“signal”][“lte”]<\/p>\n if sig.get(“rsrp”) not in (None, “–“):<\/p>\n RSRP.labels(mid).set(float(sig[“rsrp”]))<\/p>\n state = mm(“-m”, idx)[“modem”][“generic”][“state”]<\/p>\n UP.labels(mid).set(1 if state == “connected” else 0)<\/p>\n if __name__ == “__main__”:<\/p>\n start_http_server(9105)<\/p>\n while True:<\/p>\n for mid, idx in current_inventory(): # IMEI-resolved indexes<\/p>\n scrape(mid, idx)<\/p>\n time.sleep(30)<\/p>\n The JSON key layout of –signal-get varies between ModemManager versions, so test the parsing against your installed version. Plot RSRP against disconnect frequency per modem; the correlation usually tells you whether a problem is radio or USB.<\/p>\n An open proxy is abused within hours of being discovered. The minimum baseline:<\/p>\n The destination blocklist is easy to apply per namespace with nftables:<\/p>\n ip netns exec m03 nft -f – <<‘EOF’<\/p>\n table inet egress {<\/p>\n chain out {<\/p>\n type filter hook output priority filter; policy accept;<\/p>\n ip daddr { , , , } oifname “wwm03” drop<\/p>\n tcp dport 25 drop<\/p>\n }<\/p>\n }<\/p>\n EOF<\/p>\n This is not legal advice, and rules vary widely by country, but several principles apply almost everywhere.<\/p>\n Carrier contracts.<\/strong> Consumer and many IoT data plans prohibit reselling access, running servers or tethering at commercial scale. Operating a proxy service on such plans can breach contract and lead to termination of every SIM on the account. Business or M2M plans with explicit permission are the defensible route.<\/p>\n Know your customer.<\/strong> Commercial operators commonly verify customer identity, require stated use cases, and refuse anonymous high-risk usage. Because traffic from your modems is attributed to your SIMs, abuse complaints and law-enforcement requests will reach you, not your customers.<\/p>\n Logging and data protection.<\/strong> Keep enough connection metadata, such as customer, modem, timestamps, destination host and byte counts, to investigate abuse, but treat it as personal data under regimes such as the GDPR where applicable. Define retention periods and access controls before you collect anything.<\/p>\n Target-site terms and computer misuse law.<\/strong> Accessing websites through proxies is generally lawful, but using proxies to evade blocks, exceed authorization or automate prohibited actions can violate site terms and, in some circumstances, computer misuse statutes. Your acceptable-use policy should prohibit credential stuffing, account creation fraud, ad fraud, scalping, spam and similar activity, and your gateway should enforce it with rate limits, destination policies and the ability to suspend customers immediately.<\/p>\n A mobile proxy farm like <\/strong>this<\/a> to sell mobile proxy with a proxy SIM Card<\/strong> is an exercise in turning unreliable hardware into a dependable service. The decisions that matter most are structural: modules over consumer dongles where budget allows, stable identities keyed on physical port and IMEI, one network namespace per modem so isolation fails closed, a rotation service that treats each modem as shared state with locks and cooldowns, and an orchestration layer that respects the fact that each modem belongs to exactly one machine. Open-source building blocks such as 3proxy, GOST, ModemManager, uhubctl, Multus and the CNI host-device plugin cover most of the stack. What they cannot supply is operational discipline and an acceptable-use policy enforced in code, and those are what separate a service from a liability.<\/p>\n Multi-SIM routers usually fail over or bond connections rather than exposing each SIM as an independently addressable egress. A farm needs per-modem isolation, per-modem rotation and per-modem monitoring.<\/p>\n No. It produces a new session. Whether the public IP changes depends on the carrier’s CGNAT pool behavior. Always verify and report the result honestly.<\/p>\n For a few modems, yes. USB bandwidth and power become limiting factors quickly, so larger farms generally use x86 hosts with multiple USB controllers.<\/p>\n No. A single host with namespaces, systemd and Podman works well for small farms. Kubernetes pays off across multiple hosts and when you need a full control plane.<\/p>\n Many carriers assign IPv6 prefixes to mobile sessions. If your proxies and clients support it, request ip-type=ipv4v6 and configure IPv6 routes and firewall rules inside each namespace too; otherwise IPv6 can become an unmonitored leak path.<\/p>\n APN (Access Point Name):<\/strong> The carrier gateway identifier a modem uses to establish a data session.<\/p>\n Bearer:<\/strong> ModemManager’s object representing an active data session and its IP configuration.<\/p>\n\n
Legitimate Use Cases and Acceptable Use<\/strong><\/h2>\n
\n
The Hardware Layer<\/strong><\/h2>\n
Choosing the cellular device<\/strong><\/h3>\n
USB topology and controllers<\/strong><\/h3>\n
\n
Power and heat<\/strong><\/h3>\n
Radio and SIM considerations<\/strong><\/h3>\n
The host<\/strong><\/h3>\n
Linux Modem Management<\/strong><\/h2>\n
Mode switching<\/strong><\/h3>\n
ModemManager and mmcli<\/strong><\/h3>\n
Modem indexes are not stable<\/strong><\/h3>\n
Stable interface names<\/strong><\/h3>\n
Bringing up an interface without NetworkManager<\/strong><\/h3>\n
Network Architecture: Isolating Each Modem<\/strong><\/h2>\n
Option A: policy routing with source-based rules<\/strong><\/h3>\n
Option B: one network namespace per modem<\/strong><\/h3>\n
Exposing namespaces to clients<\/strong><\/h3>\n
The Proxy Layer<\/strong><\/h2>\n
3proxy<\/strong><\/h3>\n
GOST<\/strong><\/h3>\n
Supervising per-modem proxies with systemd<\/strong><\/h3>\n
HTTP versus SOCKS5 and protocol considerations<\/strong><\/h3>\n
IP Rotation<\/strong><\/h2>\n
Rotation mechanisms<\/strong><\/h3>\n
Rotation is a shared-state problem<\/strong><\/h3>\n
\n
A minimal rotation service<\/strong><\/h3>\n
Sticky sessions versus rotating pools<\/strong><\/h3>\n
Containerizing with Docker<\/strong><\/h2>\n
Building a proxy image<\/strong><\/h3>\n
Getting the modem into the container<\/strong><\/h3>\n
Orchestrating with Kubernetes<\/a><\/strong><\/h2>\n
The node agent: a privileged DaemonSet<\/strong><\/h3>\n
Per-modem pods with Multus and host-device<\/strong><\/h3>\n
The gateway<\/strong><\/h3>\n
Capacity Planning<\/strong><\/h2>\n
Troubleshooting Common Failures<\/strong><\/h2>\n
Modem disappears from mmcli -L<\/strong><\/h3>\n
Modem registered but bearer will not connect<\/strong><\/h3>\n
Bearer connected but no traffic<\/strong><\/h3>\n
Proxy reachable but clients see the wrong IP<\/strong><\/h3>\n
Rotation succeeds but the IP stays the same<\/strong><\/h3>\n
Random disconnects under load<\/strong><\/h3>\n
Inventory as Code<\/strong><\/h2>\n
Building the Gateway<\/strong><\/h2>\n
Testing and Validation<\/strong><\/h2>\n
Monitoring and Observability<\/strong><\/h2>\n
\n
Security Hardening<\/strong><\/h2>\n
\n
Abuse Prevention, Compliance and the Law<\/strong><\/h2>\n
Conclusion<\/strong><\/h2>\n
Frequently Asked Questions<\/strong><\/h2>\n
Why not just use a single router with several SIMs?<\/strong><\/h3>\n
Does rotation always produce a new public IP?<\/strong><\/h3>\n
Can I run this on a Raspberry Pi<\/a>?<\/strong><\/h3>\n
Is Kubernetes necessary?<\/strong><\/h3>\n
What about IPv6?<\/strong><\/h3>\n
Glossary<\/strong><\/h2>\n