Proxy quality: what decides it and how to measure it

9 November 2026

Proxy quality is not just speed. It is the sum of several factors you can measure one by one: the network an address belongs to and its reputation, the share of requests that succeed, latency, whether the address holds through a session, and whether the connection leaks. You can check most of them yourself in a few minutes, before you rely on any provider.

The factors and how to measure each

The network the address comes from

Every public address belongs to an autonomous system. RFC 1930 defines it as a connected group of IP prefixes run by one or more operators under a single routing policy. Each system has a number and an owner name, and the site you visit sees both before anything else. What is an ASN covers this in more depth.

The owner name tells the site whether the address belongs to a hosting company, a home broadband provider or a mobile carrier. That classification often shapes how a request is treated more than the country does. The three kinds are compared in Residential, data center and mobile proxies.

Reputation

An address carries the history of whoever used it before you. If it sent spam or password-guessing attacks, it may sit on blocklists or carry a high risk score with scoring services. The result is repeated verification prompts or outright refusals. How these scores are built is explained in IP reputation.

Uptime and success rate

Uptime answers one question: does the proxy server accept a connection right now? Success rate measures what you actually care about, a request that reaches the site and comes back with the expected response. A proxy can be up all the time and still have a poor success rate if its addresses are blocked.

Status codes separate the causes of failure. RFC 9110 defines 407 for proxy authentication required, 502 for an invalid response from the next server, and 504 for a timeout waiting on it. Those three concern the proxy and its path. A 403 or 429 usually comes from the site itself: a refusal, or too many requests.

Latency and throughput

Latency decides how quickly pages and small requests load; throughput decides how fast large files download. They are independent: a distant proxy can deliver good throughput with long latency. Measuring each phase with curl is covered in Proxy speed.

Holding the address through a session

Some tasks want a new address for every request. Others break if the address changes halfway, such as signing in or completing a payment. Quality here means the provider gives you the mode you choose and tells you how long an address lasts. See Rotating vs sticky proxies.

Leak protection and encryption

A proxy only changes the address of the traffic that goes through it. Your device may still resolve names through your local provider, the browser may expose your address over WebRTC, or an IPv6 connection may bypass the proxy. In each case the site sees a trace of your real connection. Each case has its own article: DNS leaks, WebRTC leaks and IPv6 leaks.

Encryption depends on the protocol. SOCKS5, specified in RFC 1928, does not encrypt data by itself, and a plain HTTP proxy carries the request, username and password as readable text. HTTPS sites stay protected by their own encryption, but anyone watching the path sees the site name and your proxy login. The two protocols are compared in SOCKS5 vs HTTP proxy.

Location accuracy

There is no single official register that maps every address to a city. Geolocation databases combine registry records, network measurements and files that operators publish themselves in the format defined in RFC 8805. So databases may agree on the country and disagree on the city, especially for mobile networks. More in IP geolocation.

Support and transparency

A good provider documents how to connect with each protocol, publishes the state of its service, and says plainly what it logs and what it does not. Before buying, ask a specific technical question, such as where names are resolved or how long an address lasts. How fast and how precisely they answer is a fair preview of what happens when something breaks.

How to test a proxy yourself

1. Connect through the proxy and open My IP. Check that the address, network and country are what you paid for.
2. Look the same address up in IP lookup and compare the country and city with another database.
3. Run the DNS leak test while connected. The resolvers it lists should be in the address's country, not yours.
4. Send fifty requests in a row to the site you care about and count the status codes:

for i in $(seq 1 50); do
  curl -s -o /dev/null -m 15 -x http://HOST:PORT --proxy-user USER:PASS \
    -w '%{response_code}\n' https://example.com/
done | sort | uniq -c

A 000 in the output means curl got no response at all, because of a timeout or a dropped connection. Repeat the test at different times of day, since network load changes.

How to choose

• Start from the task. Collecting public pages in bulk is not the same as opening a bank account from abroad. The first needs throughput and many addresses; the second needs one trusted address that stays put.
• Test before you commit. Buy the smallest amount on offer and run the tests above against your real task, not a test site.
• Ask where the addresses come from. Some residential proxy networks are built from devices whose owners do not know they carry other people's traffic.
• Do not send sensitive data over an unencrypted proxy on a network you do not trust. Use an encrypted protocol between you and the proxy.

With syriaproxy you exit from the Syriatel mobile network inside Syria (AS48065), through an address shared with ordinary subscribers, and names are resolved inside Syria. The apps, the extension, WireGuard and the HTTPS proxy are encrypted; SOCKS5 and the HTTP proxy are not. The service's live state is on the status page.

FAQ

Check your proxy with the free proxy checker: whether it works, its latency and its exit address.