Checker Triage
Sort and filter Proxy Checker results into practical next-step groups.
Proxy Checker is where a raw candidate list becomes an actual working set. The goal is not to admire a giant table. The goal is to separate rows into decisions: benchmark this, leak-test this, save this, inspect this one manually, and drop the rest.
Start with a run that has HTTPS check enabled. If geography, ASN, ISP, or network type matters for the job, enable location resolution too. Then build a narrow review view: status, detected protocol, HTTPS support, quality score, anonymity, latency, exit IP, country, network type, ASN, ISP, and error are usually enough for the first pass.
First Pass
Sort by Status so alive rows rise to the top. Then sort or filter by Quality score and Latency. A proxy that is alive but very slow, transparent, or missing HTTPS support may still be technically working, but it is not automatically worth promoting.
Read errors in clusters. If many rows fail with the same timeout, the source may be stale or the timeout too low. If many rows fail expected-status validation, the request URL or accepted status list may not match the target. If only one provider or country fails, you may be seeing a source-quality pattern rather than a global checker issue.
Review Buckets
| Bucket | What belongs there | Next action |
|---|---|---|
| Benchmark candidates | Alive rows with HTTPS support and high or medium score. | Send visible rows to Benchmark Proxies. |
| Leak-test candidates | Alive rows with acceptable latency and useful exit data. | Send selected or visible rows to Test Proxy Leaks. |
| Pool candidates | Rows already checked, benchmarked, and leak-tested for the workflow. | Save to a tagged pool. |
| Manual review | Rows with odd ASN, unexpected country, strange error, or surprising anonymity. | Open one row in Proxy Viewer. |
| Drop | Dead rows, poor score rows, transparent rows, or target-failing rows. | Do not send downstream. |
What The Fields Mean In Practice
Quality score is a shortcut, not a law. It combines useful signals, but your target still matters. A medium-score proxy in the right country and network type can be more useful than a high-score proxy in the wrong place. Likewise, low latency is attractive, but a proxy with one fast pass and shaky HTTPS behavior should still go through Benchmark.
Anonymity should be treated as a routing signal. Elite and anonymous rows are better candidates for leak testing. Transparent rows expose proxy behavior through forwarding headers and should be kept only for workflows where that exposure does not matter.
Network type is a heuristic. Use it to sort and prioritize, not as the only proof. If the network type, ASN, ISP, and organization disagree with what you expected, inspect one row in Proxy Viewer before trusting the whole group.
A Good Triage Flow
- Filter to alive rows.
- Remove rows missing HTTPS support if the destination requires it.
- Sort by quality score and latency.
- Filter to the countries or network types you care about.
- Select a small suspicious sample and inspect it in Proxy Viewer.
- Send the reviewed visible rows to Benchmark Proxies.
- Save only benchmarked and leak-tested finalists to a durable pool.
Visible-row handoff is your friend here. Filter the table to the exact rows you trust, then send visible rows instead of copying a separate list by hand.