The four-port tier is where most mobile proxy deployments begin and where many of them stay. Four addresses are enough to validate that an approach works, to test a market, and to run workloads whose concurrency is measured in single digits; they are not enough to act as a shared service.
This guide covers the entry tier on its own terms: what four ports actually provide, which workloads they suit and which they do not, how much bandwidth the tier carries, how rotation should be configured at this size, and what to verify so that a later expansion is a configuration change rather than a rebuild.
What does a four-port proxy gateway provide?
Four independent mobile addresses on one appliance.
Each port corresponds to a distinct address obtained through the operator rather than shared with other subscribers.
Three properties follow. The addresses are exclusive, which means behaviour does not change because a stranger used the same address a moment earlier. They are mobile, obtained through a cellular network rather than a data centre, which gives them the characteristics of a subscriber connection. And they are yours to manage, with rotation and authentication under your control rather than a provider’s policy.
The protocol these addresses serve is defined in RFC 1928, which specifies a connection-level proxy that carries any TCP traffic without interpreting it. That property is what makes a four-port device useful for clients that are not browsers, and it is why the tier is often chosen by engineering teams rather than by procurement.
Which workloads suit four addresses?
Testing, verification and low-concurrency work.
The tier is correct more often than its small capacity suggests, provided the workload is described in concurrent addresses rather than in data volume.
Four situations fit it well. Verifying how a service behaves from a particular market before committing to infrastructure there. Confirming that geo-targeted content resolves correctly and that application behaviour matches expectations. Monitoring your own properties as a user in that market would see them. And separating address space for a small number of internal systems that must not share an external identity.
Each of those is a verification activity rather than a production scale-out, and each is completed within hours or days rather than continuously. A four-port unit carries them comfortably, and the entry price of $410.00 makes it inexpensive to adopt and inexpensive to outgrow.
Which workloads do not?
Anything that needs many addresses at once.
Three requirements exceed the tier regardless of how modest the traffic volume appears.
Shared service is the first: where several teams or customers draw from the same estate, four addresses cannot be partitioned without leaving each with one. Concurrency is the second: where a workload requires more simultaneous distinct addresses than four, the tier is the constraint and additional clients cannot be served. Continuity of identity is the third: where an address must remain stable over a long session and rotation is also required for other work, four addresses leave no room to separate the two.
A fourth case belongs on the list because it is easy to overlook: any deployment where an address failure must not interrupt service. With four addresses and no spare, a fault removes a quarter of the estate rather than triggering a substitution.
How much bandwidth does the entry tier carry?
Aggregate peak, measured rather than summed.
Cellular links rarely deliver their theoretical maximum simultaneously, so the sum of four maxima overstates what the tier can carry.
The workable method is to measure the sustained throughput of one port on the target network, apply a concurrency factor measured on the same network rather than assumed, and add headroom for management traffic on a separate path. On many deployments the factor sits well below the port count, because the operator schedules the radios rather than running them all at full rate at once.
The larger risk at this tier is the reverse: sizing the outbound path for the average and discovering the ceiling during a test. Cellular throughput varies with time of day and with conditions at the installed position, so the figure worth planning against is the worst sustained value observed rather than the best.
How should rotation be configured at this size?
Conservative triggers, and no rotation mid-session.
With four addresses the cost of a badly timed rotation is proportionally larger than at higher tiers.
Three settings matter. Trigger should be whatever the workload actually requires rather than the most responsive option available, because an aggressive trigger consumes the small estate faster. Granularity should be one address at a time, never the estate, since rotating four addresses at once removes all capacity simultaneously. And cooldown should be long enough that a failure trigger cannot cycle the estate during a network problem.
The absolute rule at this tier is that stateful workloads should never be rotated mid-session. Any workload that authenticates or holds a connection depends on the address remaining stable for the duration of that interaction, and with four addresses there is no spare to absorb the interruption. Where both stateful and rotating work must run, they belong on different ports.
What should the acceptance test cover?
Per-port identity and authenticated access.
The two checks that matter establish that each port is what it claims and that the device cannot be used anonymously.
- Per-port identity. Connect through each port and confirm the address observed by an external endpoint matches the documented port.
- Authentication enforcement. Attempt an unauthenticated request and confirm it is rejected rather than served.
- Protocol behaviour. Confirm SOCKS5 works with a non-browser client and that HTTP works with a browser, on the same device.
- Rotation behaviour. Trigger the configured rotation and confirm it affects one address rather than the estate.
- Sustained load. Run all four ports concurrently for long enough to reach thermal steady state, then repeat the identity check.
Item two is the one with security consequences and the most common configuration defect on any proxy appliance: an unauthenticated listener reachable from outside your network is an open relay, and the activity it carries will be attributed to your infrastructure. The addresses and management paths on the local network should follow the private ranges defined in RFC 1918, and where the path to the device has to be secured, the transport guidance in NIST SP 800-52 Revision 2 describes the protocol versions and cipher suites that should no longer be offered.
Item five is the one that distinguishes a bench result from a deployment result. A device that passes at idle and degrades under sustained load will present as an intermittent network problem, which is the most expensive kind to diagnose.
What should be recorded at handover?
Addresses, rotation policy, auth, baseline.
The record is what makes a later expansion a configuration change rather than a rebuild.
| Item | What to record |
|---|---|
| Address map | Which port provides which address, and for which purpose |
| Rotation policy | Trigger, granularity, cooldown, and exclusions |
| Authentication | Method and which credentials belong to which client |
| Bandwidth baseline | The sustained figure measured, and the conditions |
| Thermal baseline | Behaviour observed after a sustained run |
| Versions | Firmware version at acceptance |
Where the deployment supports commercial traffic, the operational expectations described by M3AAWG are the practical reference for what an accountable operator documents, and the equipment side of any framework requirement is covered by the ETSI standards catalogue.
A related point concerns the device’s role beyond proxying. Pools in this range also support port forwarding and SMS send and receive, which means one appliance can serve a verification workload and a small messaging workload in the same deployment. Where that combination is intended, the two should use separate port groups, because a shared group makes the log unable to distinguish a proxy request from a message.
Where the deployment is expected to grow into a shared service, the smallest change that accommodates it is the step to eight addresses. That configuration allows each of two consumers to hold four addresses, which is the minimum for either to rotate or to absorb an address failure without losing all capacity at once.
Where the tier is chosen for a test, record the test result as well as the configuration, because a later decision to scale will rest on whether the approach worked rather than on the fact that it was tried.
Conclusion
A four-port gateway provides four exclusive mobile addresses under your own management, which is enough for verification, market testing and low-concurrency work, and not enough to act as a shared service. The workload should be described in concurrent addresses rather than data volume, because that is the dimension the tier constrains.
Two practices keep the tier safe. Rotation should be conservative, granular to one address, and excluded for any stateful workload, since there is no spare capacity to absorb an interruption. And acceptance should confirm per-port identity and reject unauthenticated access, because the second is the defect that turns an internal tool into an open relay. The published step to the eight-port configuration at $760.00 is inexpensive where the requirement is expected to grow.
Confirm authentication and per-port identity before the deployment carries traffic. Send your workload type, address requirement and rotation policy to service@telarvo.com, or review the published models on the proxy gateway solution pages.
FAQ
How many addresses does a four-port proxy gateway provide?
Four, one per port, each obtained through the operator rather than shared with other subscribers. That exclusivity is the difference from a subscription service, where an address may be in use by someone else a moment earlier. Four addresses suit verification and low-concurrency work; they do not support partitioning across several teams or customers.
Can four addresses support several teams?
Not without leaving each team with one address, which removes any ability to rotate or to absorb a failure. Where the estate must serve more than one consumer, the tier should be chosen so each has at least two addresses, and the published step to eight ports at $760.00 is the smallest configuration that supports a partition with headroom.
What rotation settings suit a small deployment?
Conservative triggers, granularity of one address rather than the estate, and a cooldown long enough to prevent cycling during a network problem. Stateful workloads should be excluded from rotation entirely, because with four addresses there is no spare to absorb an interruption, and a mid-session address change breaks any interaction that authenticates or holds state.
Is an unauthenticated proxy a security risk?
Yes, and it is the most common configuration defect on any proxy appliance. A listener reachable from outside your network without authentication is an open relay usable by anyone who finds it, and the activity is attributed to your infrastructure. Require authentication, keep credentials per user rather than shared, and confirm during acceptance that an unauthenticated request is rejected.