A proxy gateway purchase goes wrong in eight predictable ways, and none of them is about the price. They are about bands, port counts, protocols, management, terms, compliance, arrival testing and the record that survives the project. Each is cheap to confirm before the order and expensive to discover after delivery.
This guide is the buyer’s checklist rather than a technical explanation. It sets out what to confirm on each point, what the confirmation looks like, and what happens when the check is skipped.
What should be confirmed about coverage and bands?
Which bands, and whether signal exists where it will sit.
Two checks belong here, and they are separate: whether the device supports the network, and whether the network is usable at the location.
The band check is a datasheet question. Confirm the exact bands and the network generations from the documentation for the model and firmware you are buying, rather than from a phrase such as global coverage. Where the deployment spans markets, the check becomes a matrix with one row per operator and one column per band.
The location check is physical. A device in a basement or a metal cabinet may register and still deliver unreliably, and the symptom is intermittent rather than clean. Where the intended position has no usable coverage, the options are a different position, external antennas, or remote radio placement, and all three are cheaper to plan than to retrofit.
How many ports should you order?
From concurrent addresses, not data volume.
The port count sets how many distinct addresses can be in use at once, which is a different question from how much traffic the deployment carries.
The count follows from the number of consumers the estate serves and how each needs to operate. One consumer needs at least two addresses to rotate or to absorb a failure without losing all capacity. Two consumers need four, so that each has the same property. A shared service serving five teams needs at least ten, because a team with one address cannot rotate. Data volume enters only through the per-number policy, which determines the SIM estate rather than the port count.
The published tiers make the step arithmetic. The four-port configuration at $410.00 suits one consumer with headroom; the eight-port at $760.00 is the smallest that partitions across two; and the sixteen-port at $1,380.00 is the tier where a shared service becomes practical.
Which protocol support matters?
The protocols your clients actually speak.
The question is not which protocol is better but which your clients can use without modification.
Browsers and web tooling speak HTTP natively. Non-browser clients generally require SOCKS5, which carries any TCP traffic without interpreting it, as defined in RFC 1928. Where a deployment serves both populations, the device needs both, and the port groups should be dedicated so that attribution survives.
Two details are worth confirming rather than assuming. That the protocols coexist on the same device rather than each being supported on different models. And that the port allocation allows a separate listener per protocol per group, because a shared listener removes the ability to distinguish the two without inspecting traffic.
What should the management interface provide?
Attribution, rotation control and export.
Three capabilities determine whether the deployment is operable rather than merely functional.
Attribution means the log distinguishes a port, a user and a protocol, so that an investigation starts from facts. Rotation control means triggers, granularity and cooldown are configurable, and that ports can be excluded from rotation so stateful work is unaffected. Export means the record can leave the device in a form your own storage can ingest, because retention on the device is a diagnostic horizon rather than a system of record.
The export capability is the one most often omitted from a buying checklist and most often needed later. A device whose log can only be read on screen has a retention limit set by the device rather than by your policy, and a delivery or attribution question that arrives after that limit cannot be answered from the record.
What commercial terms should be settled?
Warranty scope, lead time, logistics, support window.
Each term affects the operating cost rather than the purchase price, which is why they belong in the business case.
| Term | What to confirm | Why it matters |
|---|---|---|
| Warranty | Period, and what it excludes | Determines replacement cost exposure |
| Dispatch | The committed dispatch term | Sets the earliest possible go-live date |
| Logistics | Carriers used and typical transit | Determines the realistic arrival window |
| Support window | Hours and time-zone coverage | Determines who responds during your incidents |
| Spares | Whether a spare unit is recommended and priced | Determines the recovery time from a hardware failure |
The support window row deserves particular attention where the deployment operates outside the vendor’s working hours. A support window that does not overlap your peak is a support window that does not help during the incidents that matter, and it is a commercial term rather than a technical one.
What should be confirmed about compliance?
Authenticated access and a defined use scope.
Two checks establish that the deployment will be accountable rather than merely functional.
The first is that the device can require authentication and will reject an unauthenticated request rather than falling back to anonymous access. That single property is the difference between an internal tool and an open relay, and it is worth confirming in writing as well as testing on arrival.
The second is that the intended use has a written scope: which markets, which workloads, and who authorises the estate. Where the traffic is commercial messaging rather than proxy work, the consent and identification expectations described by M3AAWG apply to the message and do not become lighter because the equipment is owned. Where the deployment has to satisfy an equipment framework, the ETSI standards catalogue covers the network and equipment side.
What should the arrival check cover?
Identity per port, auth rejection, sustained load.
The arrival check is short, and each item corresponds to a failure that is otherwise discovered in production.
- Per-port identity. Connect through each port and confirm the address observed by an external endpoint matches the documentation.
- Authentication rejection. Attempt an unauthenticated request and confirm it is refused.
- Protocol behaviour. Exercise each supported protocol with a client of the type that will use it.
- Rotation control. Trigger a rotation and confirm granularity and exclusions behave as configured.
- Log export. Export the record and open it in your own tooling without manual correction.
- Sustained load. Run every port concurrently long enough to reach thermal steady state, then repeat the identity check.
Item six is the one that distinguishes a bench result from a deployment result, and item five is the one that determines whether the record outlives the device. Both are frequently skipped because the device appears to work, which is also true of devices that fail later.
What should be recorded for the project?
The deliverables, the checks and their results.
The record is what allows the next purchase to be a comparison rather than a repetition.
Five items are sufficient: the model and firmware version received, the band and coverage confirmation with its source, the port and address allocation, the commercial terms as agreed, and the results of the arrival check. Adding the operational baseline recorded at acceptance — throughput, connection count and registered ports — completes the set.
The record also matters for the future decision to expand. A deployment that documented its port allocation and baseline can be extended by configuration, while one that did not repeats the discovery exercise at every step. Where growth is expected, recording the allocation keyed on the consumer rather than the port is what makes the second unit an extension rather than a second estate.
A final check concerns timing. The lead time, the dispatch term and the transit time together determine the earliest possible go-live date, and a project scheduled against the purchase date rather than the arrival date will be late. Recording the three figures as separate items is what allows a schedule to be built from them.
Where the deployment must reference the numbering or interconnection conventions a network expects, the publications of the ITU Telecommunication Standardization Sector provide a neutral vocabulary, and the environmental expectations for the installed position can be stated using the guidance published by ASHRAE.
Conclusion
Eight checks separate a purchase that works from one that produces a support case: bands and location coverage, port count from concurrent addresses, protocol support matched to clients, a management interface with attribution and export, commercial terms including the support window, authenticated access and a defined use scope, an arrival check that includes sustained load, and a project record that makes the next decision a comparison.
The checks are inexpensive and each corresponds to a failure that is otherwise discovered in production. Where the requirement is expected to grow, recording the allocation keyed on the consumer rather than on the port is what makes a second unit an extension of one estate rather than the beginning of a second one.
Confirm the eight checks before raising the order. Send your target networks, address requirement and client types to service@telarvo.com, or review the published models on the proxy gateway solution pages.
FAQ
How many ports should I buy for a small deployment?
Count concurrent addresses rather than data volume, and give each consumer at least two so that rotation or an address failure does not remove all capacity. One consumer needs two, two consumers need four, and a shared service needs two per team. The published four-port configuration at $410.00 suits one consumer with headroom.
What is the most important check before ordering?
Band support against the networks you will actually use, because a carrier whose bands the radio does not support is a card that will not register. Confirm the exact bands from the datasheet for the model and firmware you are buying, and confirm separately that the installed position has usable coverage, since the two checks are independent.
Should the support window be checked before purchase?
Yes, because it affects the operating cost rather than the price. A support window that does not overlap your peak is one that does not help during the incidents that matter. Confirm the hours and the time-zone coverage in writing, alongside the warranty scope, the dispatch term and the logistics carriers used.
What should I test when the device arrives?
Per-port identity against the documentation, rejection of an unauthenticated request, each supported protocol with the client type that will use it, rotation behaviour including exclusions, export of the log into your own tooling, and a sustained load run with every port active. The last two are the ones most often skipped and most often decisive.