Proxy Management Dashboard: What It Shows and What It Cannot

Which questions a provider's proxy dashboard can answer, which ones only your own logs can, and the weekly routine that keeps a job from dying at 03:00.

A proxy management dashboard exists to answer four questions faster than a support ticket can: how much of my allowance is gone, what am I entitled to right now, how do I connect, and who else can. Everything else a provider's console shows is a view onto one of those. A common mistake is expecting a fifth answer from it, "is my scraper succeeding", which a provider's dashboard cannot give, for a reason that is structural rather than a missing feature. This guide walks the four questions through Node4's console page by page, then covers the half you have to build yourself, and finishes with the weekly routine that keeps a job from dying at 03:00 for a reason the dashboard was already showing at 17:00.

Why the provider cannot see your success rate

When your client fetches an HTTPS page through a proxy, the proxy receives one thing: CONNECT host:443. It opens a tunnel, and from then on it relays encrypted bytes it cannot read. The status code the target returned, whether the page was a product listing or a CAPTCHA, how long the origin took to answer: all of it happens inside the tunnel. What the proxy can count is the connection, its destination hostname, and the bytes in each direction. That is all a provider dashboard can show for tunnelled traffic, and it is why a "success rate" widget on a provider console can only mean one of three things: it counts plain-HTTP traffic, where the proxy does see the status line; it counts whether the tunnel to the target opened at all, which says the exit was alive and nothing about what the target answered; or it is decoration. Ask which before you read it as a block rate.

So the split is fixed before you open a browser. Consumption, entitlement, connection details and access control come from the provider. Block rate, response classes, latency to the target and data quality come from your own logs, written by the process that can see the response. Treat any dashboard that claims to collapse the two as one to interrogate.

Question one: how much have I used

On Node4 the allowance meter is the first thing on the Dashboard page, and its semantics matter more than its color. Metered products (shared datacenter, Rotating Datacenter, residential, and the free tier) count bytes against a period allowance, and that count is what bills them. Dedicated datacenter and Rotating Unmetered do not meter bandwidth, so on those plans the meter has nothing to say and the constraint lives elsewhere: the number of proxies on dedicated, the concurrent-connection figure on Rotating Unmetered.

Two rules decide what the meter shows. Same-type plans stack, so two residential subscriptions display one summed allowance rather than two meters. And the meter is a gate, not a forecast: a metered plan hard-stops at its cap and refuses every request (a 407 over HTTP, a connection failure over SOCKS5) until the period renews or you top up, and a single large response can carry usage past the line inside one request. If a job runs unattended, turn on auto top-up and set its threshold; it is opt-in, it fires before the stop rather than after it, and the setting shows the exact percentage so this article does not have to. Bandwidth top-ups explains what a top-up costs relative to your plan and when a bigger plan is the better buy.

History lives on the Analytics page, per proxy, as request counts and bytes transferred over the range you pick. Read it for shape rather than for verdicts. A proxy whose transfer doubled overnight while its request count held still is downloading something it did not use to, usually images or a payload that grew, and that is a cost change on you before it is anything else.

Question two: what am I entitled to

Plans and Orders show what you hold and what you paid for it; the invoice guide reads a line item. The entitlement question that actually breaks jobs is subtler: which gateway will accept this credential. Every product refuses a connection from an account that does not hold it, so a 407 from the residential gateway on an account with only a rotating plan is a "wrong product" answer wearing a "wrong password" costume. The free tier is static shared datacenter over HTTP(S); it cannot reach the rotating or residential gateways at all, and SOCKS5 is denied on it. If you are evaluating a gateway product on a free account, that is the whole diagnosis.

Thread counts on a plan card are fair-use guidance rather than an enforced ceiling, with one exception: on Rotating Unmetered the concurrent-connection number is the thing you bought, and it is enforced. Changing or upgrading your plan covers moving between plans without a gap in service.

Question three: how do I connect

The Proxies page shows host, port and credential per static proxy, and the fixed gateway hostname for each gateway product. For a static address there is also a refresh action that swaps the IP, which is the answer to "this one address is burned on one target". It is available from the dashboard and from the API, and it replaces the address, so update anything that had the old one registered at a partner.

For a gateway product the page cannot list the exits, because there is no list. The exit is chosen when you connect, and targeting is expressed in the username. The residential builder on that page writes the username for you; on the rotating tiers you append the segments yourself. The connection builder turns any row into a curl, Python, Node or browser configuration, which is the quickest route from "I have a plan" to "I have a working request".

One credential per account is the model, and entitlement follows the products the account holds rather than the credential used. A paid account can hold up to 5 credentials, which is how you give separate jobs separate identities so that revoking one does not stop the others.

Question four: who can connect

Auth & IP Access, at /authentication, is where the IP whitelist lives. It is not under Settings, and people look there first. Whitelisting works on every product, and what you register is a source address, not a person: every process behind that address inherits the grant and spends your allowance. The scope of what a whitelisted connection can express differs by product. On static datacenter nothing is lost, because nothing is expressed per request. On the rotating gateways you can send your username with an empty password and keep country and session targeting without the secret. On residential you send no username and no password at all, and the connection is untargeted by design; anything that pins a location or a session on residential still authenticates with credentials. IP whitelisting best practices covers the sharing set behind an address and what a drifting line looks like from the proxy's side. A free account can register 1 address; paid plans allow 3.

API keys under Settings are the other access surface. They are scoped and revocable, they manage the account rather than carry traffic, and they belong in a secret store rather than an environment file that ends up pasted into a ticket; storing API keys securely is the short version. For a team, the Teams page gives members their own logins with a read-only viewer role, a manager role for proxies and an admin role for members and settings; billing stays with the account owner, so the person watching a meter does not need the login that can cancel the plan.

The half you have to build

Because the provider cannot see responses, the other half of a proxy dashboard is a table you write from inside your scraper: one row per request with the exit address, the target host, the status code, the response size and the elapsed time. Log the exit even when you think you know it. A rotating job that logs it is the only one that can tell you, when a block rate spikes, whether one range is burned or the target changed policy for everyone. Group that table by target and by day and you have the block-rate view no console can render.

That table is what proxy analytics means by telemetry, and measuring proxy performance is the benchmark harness that turns it into comparable numbers. When a target starts refusing, block replay will show whether the refusal was about the address or about the request, which decides whether the fix is rotation or headers.

Automating the console

Anything you click twice a week belongs in a pipeline. The REST API covers the account side: /usage and /usage/bandwidth for the meter, /proxies and /proxies/refresh for the list and the swap, /ip-whitelist for adding a runner's address before a job and removing it after, and /webhooks so that a low-allowance event or a failed renewal lands in the channel your on-call reads. It reaches the billing side as well: /billing/invoices for the PDFs your accounts team asks for, /auto-topup and /alerts for the settings, and /topups to buy more data when the preflight below says a job will not fit. Agencies that hand access to clients can give each one a sub-user at /sub-users, with its own monthly bandwidth cap and usage. The limit is 60 requests per minute per key, flat across plans. The management API has every endpoint with request and response shapes.

The pattern that pays for itself first is a preflight. Before a long job starts, read the meter, compare it to the job's estimated bytes, and refuse to start if the allowance will not cover it. It is ten lines, and it converts "the job died at 03:00" into "the job declined to start at 17:00, with a reason".

A weekly routine

What Node4's console does not show, and what that costs you

It does not show target status codes, per-request latency, or a success rate, for the structural reason above. It does not graph gateway CPU or memory; those are our problem, and the status page is where an incident on our side is reported. It does not show the exit address a gateway request used, and neither does your client unless the target echoes it back: if a job needs the exit on record, fetch an IP echo through the same session and log it. If your evaluation of a proxy management dashboard is a checklist with those rows on it, Node4 fails them, as does any provider whose proxies relay HTTPS through tunnels they cannot read.

What it does show is the four questions, answered from the system that bills you, plus an API to ask them from code. The features page lists the console and API surface, plans are on pricing, and the dedicated datacenter and residential pages describe the products the meter is metering.