A consumer 4G multi-WAN router with failover is a genuinely capable device, and most small deployments never outgrow one. The deployments that do usually cannot name the moment it happened, which is why the upgrade is discovered through an incident rather than planned.
This guide sets out the ceilings that consumer routing equipment reaches, the three signals that indicate you have reached them, and what a SIM-pool gateway changes about the problem.
What are the real ceilings of consumer 4G routers?
Session tables, address handling, and multi-SIM management.
The limits are not about speed, and that is why they are hard to notice.
Throughput is the specification consumer devices advertise and rarely the constraint. Three others bind first. The session table limits how many simultaneous connections the device can track, and a workload with many short-lived connections exhausts it while bandwidth remains idle. Address handling is typically designed for one or two cellular connections, so managing a pool of addresses is outside the model. And multi-SIM management is generally absent: the device may support failover between WANs but not an estate of SIMs with a policy for which one carries what.
Thermal behaviour belongs on the list as well. Consumer equipment is designed for intermittent use at moderate load, so continuous operation at high throughput produces behaviour that the specification does not describe, and the symptom is usually instability rather than a clean failure.
What are the three signals you have outgrown it?
Connection failures at available bandwidth, and slow decay.
Each signal points at a different ceiling, and each is visible before it becomes an outage.
Intermittent connection failures while bandwidth is available indicate session table exhaustion. New connections are dropped while existing ones behave normally, which looks like an application problem rather than a routing one. Degradation after hours of operation indicates thermal behaviour outside the design envelope, and it is recognised by the fact that a restart restores performance temporarily. Requirements you cannot express in the device’s configuration indicate the management model has been exceeded: per-SIM policies, address grouping, and per-port attribution are not features consumer interfaces offer.
Naming which signal applies is what determines the remedy. Session exhaustion calls for a different routing device. Thermal behaviour calls for a device designed for continuous operation. Policy gaps call for a management layer rather than a faster router.
What does a SIM-pool gateway change?
It moves the address estate into the device’s model.
The change is architectural rather than incremental.
A SIM-pool gateway treats addresses as a managed estate: multiple connections are expected, per-port attribution is part of the design, and the addresses belong to the deployment rather than being whatever the upstream connection provides. That model addresses the third signal directly and the first indirectly, because a device designed for many connections has a session table sized for them.
The published range reflects the model difference: the SK Multi-WAN series runs from the four-port configuration at $410.00 to the sixteen-port at $1,380.00, each port representing a distinct address with SOCKS5 and HTTP proxy support. That is a different product category from a router with failover, which is why the comparison should be made on requirements rather than on specification tables.
How should the migration be planned?
Add the gateway alongside, then move workloads.
A migration that replaces the router in one step loses the fallback path at the moment it is most useful.
- Run the gateway alongside the existing router and move one workload at a time.
- Measure each workload on the new path before moving the next, recording the metrics the workload itself cares about.
- Keep the router as the fallback path until every workload has been stable on the gateway.
- Document the address mapping as part of the migration, because it becomes the reference for every later investigation.
Where the workloads have different tolerances — one holding sessions and another not — migrate them in that order, because the tolerant ones reveal configuration problems before the sensitive ones are at risk.
When should the router stay?
When the requirement is connectivity rather than addresses.
A router with failover is the correct device for maintaining a connection, and that is a different job from managing an address estate.
Where the deployment needs resilient connectivity for ordinary traffic and the addresses are incidental, a router is simpler, cheaper and adequate. Where the addresses are the requirement — testing from a market, separating address space between teams, attributing activity per user — the router’s model does not reach it, and adding capacity to it does not change that.
The practical test is whether anyone would notice if the address changed. Where the answer is no, the router is sufficient. Where the answer is yes, the requirement is an address estate, and that is what the gateway provides.
What should the replacement device be specified against?
Session capacity, continuous operation, attribution.
The specification that matters is not the one the router advertised, and the three requirements below are the ones that address the ceilings described above.
Session capacity should be stated as the number of simultaneous connections the device tracks, because that is the limit a workload with many short-lived connections reaches first. Continuous operation should be stated as a duration at load, not as a maximum throughput, because thermal behaviour under sustained use is what the router design does not address. Per-port attribution should be stated as a logging requirement, because an investigation that cannot answer which address carried which activity is not an investigation.
A fourth requirement belongs in the same document: the number of cellular connections the device is designed to manage. A router designed for failover between two uplinks is not designed for an estate of addresses, and the difference is architectural rather than a matter of capacity. Stating it explicitly prevents the upgrade from becoming a larger version of the same constraint.
Where the requirement includes a market or equipment framework, the ETSI standards catalogue covers the network and equipment side, and the numbering that recipients or destinations observe follows ITU Recommendation E.164.
A useful way to test whether the requirement has changed is to ask what happens when an address changes. Where the answer is that nobody notices, the router’s model is still adequate and the upgrade would add complexity without adding capability. Where the answer involves a conversation with a customer, a logged session or an attribution question, the requirement has moved from connectivity to address management, and that is a different product category rather than a larger router.
Migration sequencing deserves the same attention as device selection. Running the gateway alongside the router and moving one workload at a time produces a result that can be attributed; replacing the router in one step produces an outage whose cause is ambiguous when the first workload behaves unexpectedly.
A useful discipline when specifying the replacement is to record which ceiling each requirement addresses. Session capacity addresses the connection-tracking limit, continuous operation addresses the thermal limit, and per-port attribution addresses the management limit. Requirements that cannot be mapped to a specific ceiling tend to be specifications copied from a product page rather than requirements derived from the workload, and they add cost without changing the outcome.
Cost comparison should follow the same logic. A gateway costs more than a router in capital terms and less in operating terms once the address estate is part of the requirement, because the alternative is to manage addresses outside the device, in a spreadsheet, with no attribution. Where the requirement genuinely includes address management, the comparison is between a gateway and a gateway-shaped problem solved by hand.
The operational expectations that apply where the traffic is commercial are described by M3AAWG and, for the North American market, by the CTIA. Where the deployment operates in a facility with an environmental specification, the widely used guidance published by ASHRAE is the normal reference for the operating envelope.
Where the deployment is expected to grow, the replacement specification should state the growth assumption it was written against. A device specified for the current session count becomes inadequate at the next step, and the cost of revisiting that decision is materially higher than the cost of stating the growth assumption once in the first place.
Conclusion
Consumer 4G routers are limited by session table size, address handling and the absence of multi-SIM policy rather than by throughput, which is why their ceilings are discovered through incidents. The three signals that indicate you have reached them are connection failures at available bandwidth, degradation under continuous load, and requirements the interface cannot express.
A SIM-pool gateway changes the model rather than the speed, treating addresses as a managed estate with per-port attribution. The published range runs from four ports at $410.00 to sixteen at $1,380.00. Migrate alongside the router rather than replacing it, keep the fallback until every workload is stable, and document the address mapping as you go. Where the requirement is resilient connectivity rather than address management, the router remains the right device.
Decide whether your requirement is connectivity or addresses. Send your workload types, connection counts and address requirement to service@telarvo.com, or review the published models on the proxy gateway solution pages.
FAQ
How do I know if my router is the bottleneck?
Look for connection failures while bandwidth remains available, which indicates session table exhaustion rather than a speed limit. A second signal is degradation after hours of continuous operation that a restart temporarily resolves, which points at thermal behaviour. Neither appears in a throughput measurement, which is why the bottleneck is often misdiagnosed.
Does a SIM-pool gateway replace a multi-WAN router?
It replaces the address-management function, not necessarily the connectivity role. Where the requirement is resilient connectivity for ordinary traffic, a router is adequate. Where the requirement includes managing a pool of mobile addresses with per-port attribution, the gateway provides a model the router does not have, and the two can run alongside each other during a migration.
Can I use any SIM card in a 4G router or gateway?
The SIM must be permitted to operate in the device and on the network you intend to use, and the device must support the bands that network uses. Where the deployment operates across markets, confirm band support and registration requirements for each market rather than assuming a card that works in one will work in another.
What router features matter for a proxy deployment?
Session table capacity, support for many cellular connections, per-port attribution in the logs, and thermal behaviour under continuous operation. Band support matters for the markets you operate in. Throughput, which is the specification most often compared, is rarely the binding constraint for this type of workload.