> For the complete documentation index, see [llms.txt](https://help.proxidize.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.proxidize.com/proxidize-proxies/proxy-analytics.md).

# Proxy Analytics

Read your proxy traffic in the dashboard: usage and request trends, the domains you reach, and a searchable log of every request with error reasons.

**Analytics** answers three kinds of question: how much you are using, whether it is working, and why a request failed.

It covers all three plans, and everything on the page follows the scope and period you set at the top.

You will find it under **Proxies → Analytics** in the sidebar.

<a href="https://www.app.proxidize.com/proxies/analytics/" class="button primary" data-icon="arrow-right">Open Analytics</a>

### Scope your view first

**Type** picks the product and **Plan** picks the access model, then **Data Scope** narrows it further.

On **Per Proxy** you can filter by **Proxies** and by **Tags**. On **Per GB** you filter by **Access Points**. Leave a selector empty to include everything.

**Period** offers **Last Hour**, **Last 24 hours**, **Last 7 Days** and **Last 30 Days**, plus a **Custom Date Range** with **Apply**.

{% hint style="info" %}
Your whole view lives in the page address, including the plan, period, table sort and page size.

Bookmark a view you check often, or send someone the link to exactly the failures you are looking at.
{% endhint %}

**Refresh** at the top right reloads the data without changing your selections.

<figure><img src="https://3163533074-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiAQa47xivOtQQ7mQZOnQ%2Fuploads%2F8uo0G95nSN8O1U50Cn4w%2FAnalytics.png?alt=media&amp;token=bc36832b-ae5c-4f03-b42a-22bb790a300e" alt=""><figcaption></figcaption></figure>

***

### The two views

The toggle at the top right of the chart block switches between two different reports, not just two units.

* **Data Usage** answers how much. The block is titled **Data Consumption Analysis** and gives you **Usage Trends**, with a **Total Usage** badge, alongside **Top 10 Domains (By Volume)**.
* **Requests** answers how well. The block becomes **Network Traffic Insights** and gives you **Request Volume**, which plots **Successful** against **Failed** and shows an **Avg success rate**, alongside **Top 10 Domains (By Request Count)**.

The **Month**, **Week**, **Day** and **Hour** tabs control how finely the data is grouped, and the sensible one for your period is picked for you.

**Avg success rate** is your successful requests divided by your total requests across the whole period, so a bad hour in a good month barely moves it. Hovering any point on **Request Volume** gives that moment's successful count, failed count and success rate, which is how you find the hour something broke.

<figure><img src="https://3163533074-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiAQa47xivOtQQ7mQZOnQ%2Fuploads%2Fih2xBStN978GPlHmrMs6%2Fimage.png?alt=media&amp;token=9cec26e0-c229-4d15-92ae-cf3e18b9daa7" alt=""><figcaption></figcaption></figure>

***

### Connection History

One row per outbound request, newest first, for whatever you have scoped. Requests stay here for **60 days**.

Eight columns are shown by default:

<table data-search="false"><thead><tr><th>Column</th><th>What it shows</th></tr></thead><tbody><tr><td><strong>TIME</strong></td><td>When the request was made</td></tr><tr><td><strong>DOMAIN</strong></td><td>The destination host</td></tr><tr><td><strong>METHOD</strong></td><td>The HTTP method, or <code>CONNECT</code> for HTTPS</td></tr><tr><td><strong>STATUS</strong></td><td>The status Proxidize recorded for the request. See what the status means before drawing conclusions from it</td></tr><tr><td><strong>TRAFFIC</strong></td><td>Data down and data up, separately</td></tr><tr><td><strong>PROXY NUMBER</strong></td><td>Which proxy carried it. On Per GB this is <strong>ACCESS POINT</strong> and shows the access point name</td></tr><tr><td><strong>PROTOCOL</strong></td><td><code>HTTP</code>, <code>HTTPS</code> or <code>SOCKS5</code></td></tr><tr><td><strong>LOCATION</strong></td><td>Where the proxy exited, as far as it resolves</td></tr></tbody></table>

**Columns** adds nine more, and they are where the diagnostic value is:

<table data-search="false"><thead><tr><th>Column</th><th>Why you would turn it on</th></tr></thead><tbody><tr><td><strong>ERROR TYPE</strong></td><td>The reason a request failed, in plain words. Turn this on first</td></tr><tr><td><strong>DURATION</strong></td><td>How long the request or connection lasted</td></tr><tr><td><strong>CARRIER / ISP</strong></td><td>Which ISP carried it, useful when one network behaves differently</td></tr><tr><td><strong>AUTH</strong></td><td>Whether the request authenticated by credentials or by IP</td></tr><tr><td><strong>SOURCE IP</strong></td><td>The public IP that sent the request to us, so you can tell which of your machines or servers it came from</td></tr><tr><td><strong>PORT</strong></td><td>The destination port, <code>80</code> or <code>443</code></td></tr><tr><td><strong>SESSION KEY</strong></td><td>The session the request used, so a row ties back to a specific session</td></tr><tr><td><strong>POOL KEY</strong></td><td>The pool the request used, on pooled traffic</td></tr><tr><td><strong>USERNAME</strong></td><td>The username the request presented</td></tr></tbody></table>

{% hint style="info" %}
**DURATION** is how long the request or connection lasted, not how long the destination took to respond.

On an HTTPS row it can be the lifetime of the whole tunnel, so a duration of thirty seconds usually means a connection that stayed open and busy, not a slow proxy.
{% endhint %}

<figure><img src="https://3163533074-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiAQa47xivOtQQ7mQZOnQ%2Fuploads%2FlgEuLLp4UCXg79sUTCI9%2Fcolumns.png?alt=media&amp;token=d2e91b5c-1ab5-4e46-b59d-ed13dd7f6db2" alt="" width="265"><figcaption></figcaption></figure>

#### Filtering and exporting

**Filters** builds rules rather than offering fixed choices. Each rule is a column, an operator and a value, and once you have more than one you choose whether they combine with **And** or **Or**.

The operators fit the column: text columns offer **contains**, **equals**, **starts with** and **ends with**, **Traffic** offers numeric comparisons, and **Status**, **Auth**, **Protocol** and **Error Type** offer **is** and **is any of**.

**Export** takes the current view as a CSV, so set your scope, period, columns and filters first.

<figure><img src="https://3163533074-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiAQa47xivOtQQ7mQZOnQ%2Fuploads%2FPF7PRQC5GZmsTMbXzm44%2FAnalyticsFiltering.png?alt=media&amp;token=c2a340b1-745f-49b5-aa17-9d4ae862d9aa" alt="" width="563"><figcaption></figcaption></figure>

***

### What the status and error columns mean

**STATUS** and **ERROR TYPE** are independent. A request can carry a status with no error type, and an error type can appear with more than one status.

{% hint style="warning" %}
**STATUS is what Proxidize recorded, not what the website answered.**

Ordinary HTTP requests are logged as `200` once we have passed them through, whatever the destination itself returned. If you need to know that a page came back 404 or 429 from the site you were reaching, read that in your own tool. Analytics tells you whether the request got out of our network, not what it found at the other end.
{% endhint %}

#### Status codes

<table data-search="false"><thead><tr><th>Status</th><th>Meaning</th></tr></thead><tbody><tr><td><code>200</code></td><td>The request or tunnel succeeded</td></tr><tr><td><code>400</code></td><td>The request was malformed or invalid: an invalid protocol, an invalid Simple Mode port, an unsupported command, or missing proxy configuration</td></tr><tr><td><code>401</code></td><td>Authentication failed, mostly on SOCKS</td></tr><tr><td><code>402</code></td><td>Your bandwidth allowance is exhausted</td></tr><tr><td><code>403</code></td><td>We refused the request on policy: a blocked domain, port or country, an invalid session, an IP not on your allowlist, or a disabled account</td></tr><tr><td><code>404</code></td><td>No usable route was found, or the account or access point could not be found</td></tr><tr><td><code>407</code></td><td>We are asking your client to authenticate. Common on IP-authenticated and browser setups before credentials are supplied, and not a response from the destination</td></tr><tr><td><code>409</code></td><td>A connection conflict, mainly during UDP or SOCKS handling</td></tr><tr><td><code>429</code></td><td>You exceeded your concurrent thread limit</td></tr></tbody></table>

***

### What the error types mean

These are the errors you will meet most often. Others exist, so treat an unfamiliar value as a reason to contact support rather than a sign something is wrong with your setup.

| Error type                 | Usual status          | What it means and what to do                                                                                                                                                                                                                                                                                           |
| -------------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **No Bandwidth Available** | `402`                 | Your data allowance is used up. Buy more data or add a package, and check your balance in the header of your product page                                                                                                                                                                                              |
| **Blocked Domain**         | `403`                 | The destination is not permitted. The request never left our network, so there is nothing to retry. See the policy below                                                                                                                                                                                               |
| **Blocked Port**           | `403`                 | The destination port is not permitted. Only ports **80** and **443** are allowed, so point your tool at a standard web port                                                                                                                                                                                            |
| **Thread Limit Exceeded**  | `429`                 | You are running more than **2,000** concurrent connections. Reduce concurrency, spread the work across more proxies or access points, or complete KYB verification to lift the limit                                                                                                                                   |
| **Authentication Failed**  | `401`, `403` or `404` | The credentials or source IP were not accepted. Causes include wrong credentials, an access point that no longer exists, the wrong authentication mode, an IP missing from your allowlist, an expired session, and access that has been disabled. Re-copy your credentials from the dashboard and check your allowlist |
| **No Route Found**         | usually `404`         | We could not select a usable route. Most often this means nothing was available matching what you asked for, so loosen a pinned location or ISP, though it can also mean a proxy or session that no longer resolves                                                                                                    |

{% hint style="info" %}
The **No Connection** variants do not currently mean different things to you, and the same checks apply to all of them.
{% endhint %}

***

#### Why a domain is blocked

Some categories are restricted for accounts verified with KYC only, and **KYB verification lifts them**: financial services, HR platforms, and user-review sites.

A separate set is blocked for everyone and is never unlocked: anything abusive, anything used for hacking, and anything else Proxidize considers unsafe.

***

### Finding the cause of a problem

{% stepper %}
{% step %}

#### Confirm there is a problem

Switch to **Requests** and check the **Avg success rate**, then find the point where **Failed** rises.
{% endstep %}

{% step %}

#### Narrow to that window

Set **Period** to cover it, and switch the granularity to **Hour** to see it precisely.
{% endstep %}

{% step %}

#### Look at the reasons

In Connection History, turn on **ERROR TYPE** and filter it with **is not empty** to see only failures.
{% endstep %}

{% step %}

#### Narrow to the cause

Add a rule for **Proxy Number**, **Access Point**, **Domain** or **Protocol**. If the failures all sit on one proxy, one access point or one destination, you have found it.
{% endstep %}

{% step %}

#### Act, or send it to us

Fix what the error type points at. If it is a **No Connection** error that survives rotation and happens without a proxy too, **Export** the filtered rows and send them to support.
{% endstep %}
{% endstepper %}

***

### Quick FAQ

<details>

<summary>Why do all my HTTPS requests show as CONNECT with no page path?</summary>

HTTPS is encrypted between you and the destination, so the proxy only ever sees the hostname. **CONNECT** is the request that opens that tunnel, and it is the only part visible to us.

</details>

<details>

<summary>My scraper is getting blocked by a website, but my success rate here looks fine. Why?</summary>

Because they measure different things. Analytics counts a request as successful when it got through our network. A site answering with a block page or an error is still a successful trip through the proxy, so watch for that in your own tooling.

</details>

<details>

<summary>How far back can I look?</summary>

Connection History keeps 60 days. The charts can go back considerably further, so use a **Custom Date Range** for long term trends.

</details>

<details>

<summary>What does SOURCE IP show?</summary>

The public IP that sent the request to us, which is your machine or server rather than the proxy's exit IP. It is the quickest way to tell which of your systems is generating traffic.

</details>

<details>

<summary>Does looking at Analytics use my data?</summary>

No. Analytics reports on traffic that already happened. Only traffic through the proxies consumes data.

</details>

***

### Related articles

* [Mobile - Per Proxy](/proxidize-proxies/mobile-proxies/mobile-per-proxy.md)
* [Mobile - PerGB](/proxidize-proxies/mobile-proxies/mobile-pergb.md)
* [Residential - perGB](/proxidize-proxies/residential-pergb.md)
* [How Proxy Assignment Works on Per Proxy Plans](/proxidize-proxies/mobile-proxies/mobile-per-proxy/how-proxy-assignment-works-on-per-proxy-plans.md)

***

### Need help?

If you have any questions, concerns, or need further clarification, feel free to reach out to us via live chat or email us directly at <support@proxidize.com>.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.proxidize.com/proxidize-proxies/proxy-analytics.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.