Proxy Clients are the per-customer credentials you hand out in front of a tunnel — each with its own username, password, ACLs, and limits. Among those limits, the one that virtually every reseller eventually reaches for is a byte quota: a hard cap on how much traffic a given customer can push through before the door slams shut. Get it right and you can sell metered bandwidth plans with confidence; ignore it and a single high-volume customer can quietly eat into everyone else's capacity.
This guide explains exactly where the quota field lives, what counts toward it, how the enforcement engine works under the hood, and how to reset or top up a client without interrupting other customers. If you haven't issued any Proxy Clients yet, start with per-customer proxy clients first.
What is a bandwidth quota on a Proxy Client?
A quota is a cumulative byte ceiling attached to one Proxy Client. Unlike a speed cap (which throttles throughput), a quota is a lifetime or periodic total. The moment the running byte count crosses the ceiling the client stops working entirely — no graceful slowdown, just a hard cutoff. That distinction matters when you're designing a reseller plan: you're selling a bucket of bytes, not a rate.
Quotas are optional. Leave the field empty and that client is unlimited. Set a number and you control exactly how much data that customer can move before they need to top up or renew. This is the foundation of any pay-as-you-go pricing model.
Where the quota lives
Open any proxy from your panel's /proxies page, scroll to the Proxy Clients section, and create or edit a client. You will see a Quota field. The unit is bytes. Leave it empty for unlimited access, or enter an integer for a hard cap. The panel displays the human-readable equivalent alongside the raw input so you never have to count zeroes:
1073741824— 1 GiB5368709120— 5 GiB53687091200— 50 GiB107374182400— 100 GiB
Using bytes as the base unit is intentional. Some customers buy in fractional gigabytes, some in terabytes; one unit eliminates conversion ambiguity at the database level.
What counts toward the quota
Both upload and download count. Every byte the client sends to the target, and every byte the target returns, are added to the same running total. That reflects true cost — a customer streaming video through your tunnel generates mostly downstream traffic, and ignoring it would significantly undercount real resource usage.
What is not counted: protocol framing — TLS handshakes, the SOCKS5 greeting sequence, HTTP CONNECT preamble. Only the payload bytes flowing between the two ends of the tunnel once the connection is established are metered.
The 10-second flush window — and what it means for precision
Counting every byte synchronously would require a database write on every packet, which is impractical at proxy throughput. Instead the edge node buffers usage in memory and flushes the accumulated total to the database every 10 seconds. Enforcement runs immediately after each flush. Here is what that means in practice:
- Small overshoot is possible. A client sitting at 99.9% of its quota can exceed the cap by up to a few hundred kilobytes during the window before the next flush triggers deactivation. This is a deliberate design trade-off: the overshoot is bounded and far cheaper than per-byte synchronisation at scale.
- The dashboard lags by up to 10 seconds. The usage bar in your panel updates each flush cycle. If a refresh appears frozen, wait one more tick.
- Deactivation is immediate after the flush crosses the line. Once the running total exceeds the cap the client flips to inactive, all tunnels close, and new connections are refused — before the next flush even runs.
For rotating proxy pools with multiple devices, each edge node flushes independently. The sum reaches the panel on every cycle, so aggregate usage is still accurate within the same 10-second window.
What "quota exhausted" looks like to the end user
Two things happen simultaneously the moment a client is deactivated by quota enforcement:
- Every open tunnel for that client closes. Mid-request, mid-stream — the sockets receive a clean TCP FIN. A scraper will see a connection reset on its next read; a browser will show a connection error. There is no warning before the cut.
- New connections are refused with a protocol-appropriate error. HTTP tunnels return
407 Proxy Authentication Required; SOCKS5 connections receive an authentication-failure reply. The error continues until you take action — raise the cap, reset usage, or reactivate the client manually.
This is intentionally a hard cutoff, not a soft warning. If you want graceful degradation — for example notifying your customer at 80% — monitor the usage field via the Nodetonet API and send your own alert before the ceiling is hit. The API is documented in your first REST API call.
Quota vs other per-client limits — a quick comparison
| Limit type | Controls | Enforcement | When to use |
|---|---|---|---|
| Quota (bytes) | Total lifetime data | Hard cutoff at flush | Metered data plans, reselling by GB |
| Thread limit | Concurrent connections | Immediate, per-connect | Preventing one client from hogging capacity |
| Expiry date | Access duration | Hard cutoff at clock time | Trial periods, time-boxed plans |
| IP / domain allow-deny | Allowed destinations | Immediate, per-connect | Restricting client to approved sites |
Quotas and expiry dates compose cleanly. You can sell a plan that reads "5 GB or 30 days, whichever comes first" by setting both fields on the same client. See time-limited Proxy Clients for the expiry side of that combination.
Resetting and topping up
Edit the client in your panel and choose one of two actions:
- Raise the quota. The total cap becomes the new value; existing usage carries over. Use this for "add 10 GB to the customer's current bucket." If the client was deactivated by quota enforcement, raising the cap instantly reactivates it.
- Reset usage to zero. Same quota ceiling, fresh slate. Use this for a monthly billing cycle where customers get a fixed allocation each period. The client reactivates immediately.
Either action takes effect the moment you save — there is no propagation delay. The next connection attempt from that client will succeed. For high-volume reseller setups, consider automating both actions via the REST API so renewals happen without manual intervention. See your first REST API call for the endpoint reference.
Building a metered reseller plan around quotas
Nodetonet's reseller and white-label system lets you issue credentials to end-customers without them ever seeing your panel. Quotas are the key pricing lever: you set the byte ceiling per Proxy Client, collect payment (prepaid credit, no Nodetonet monthly subscription), and reset or top up when the customer pays again. Combine with:
- Thread limits to prevent any single customer from saturating shared capacity.
- IP and domain allow-deny lists to enforce acceptable-use policies.
- Audit logs to show customers their usage history if they dispute the meter.
- Mobile proxy pools via token groups so each client draws from a shared device fleet with automatic failover.
You can verify any client's effective IP at any time with the proxy checker tool, or hand customers the what is my IP link so they can self-serve that check.
What's next
- Thread limits per client — cap concurrent connections so one customer cannot starve the rest.
- Time-limited Proxy Clients — combine quotas with an expiry date for "1 GB or 7 days, whichever first".
- Per-customer proxy clients — the full picture for issuing scoped credentials.
- Your first REST API call — automate quota resets and top-ups programmatically.
- Nodetonet quickstart — if you haven't set up a tunnel yet.