Proxy knowledge base

HTTP Proxy Servers

Description: Proxies of this type support the HTTP protocol and are used to access web pages and download files from services that operate on the standard TCP port 80.

Limitations: Regular HTTP proxies are not suitable for websites that require SSL/TLS and cannot be included in a proxy chain.

HTTP proxy classification by anonymity level

HTTPS (CONNECT) Proxies

These proxies support the HTTP CONNECT method, which makes HTTP tunneling possible. In this mode HTTP becomes a transport layer for lower-level TCP traffic.

Because of that, such proxies can connect to almost any required port on the target resource and work with most TCP applications, including SSL/TLS web servers. Tunneling is what makes HTTPS proxies suitable for multi-layer chains and preserves their anonymity.

SOCKS Proxies

Almost any network application can work through SOCKS proxies: mail clients, specialized communication systems, browsers, parsers and other TCP tools.

The key SOCKS feature is the ability to build sequential chains from multiple proxies. This increases anonymity because SOCKS operates on a lower networking level and does not modify HTTP headers.

Classification of SOCKS protocol versions

The most common versions are SOCKS4, SOCKS4a and SOCKS5. All of them support IPv4, TCP and the BIND method that opens a port for incoming connections.

SOCKS4a and SOCKS5 have an important edge over SOCKS4: the client can pass not just an IP but a domain name, and the SOCKS server itself resolves DNS. That avoids DNS leaks. SOCKS5 also handles UDP, IPv6, and stronger authentication.

Web Proxies (CGI Proxies, Anonymizers)

A web proxy is a specialized web page through which a user opens another website, often anonymously. Such a resource is often called a CGI proxy or anonymizer.

The main advantage is simplicity: usually no browser configuration changes are required. Most web proxies can work with HTTPS resources and, if necessary, can be embedded into a cascading scheme.

Detailed Functional Analysis

1. HTTP proxies operate strictly on the application layer, OSI Layer 7, and suit only HTTP requests without built-in encryption.
2. HTTPS proxies can correctly pass TLS/SSL traffic by using HTTP tunneling through the CONNECT method.
3. All SOCKS versions operate on the session layer, OSI Layer 5, which is closer to transport logic.
4. SOCKS4 is the baseline version without authentication and without IPv6 support.
5. SOCKS4a adds minimal improvements while preserving SOCKS4 limitations.
6. SOCKS5 is the most advanced implementation: it supports domain names, extended authentication, IPv6 and UDP.

4.1. Classification by hardware type

Proxy services fall into two big groups, depending on the kind of hardware they run on.

4.2. Classification by IP ownership

Modern databases give you the country, city, ISP, and connection type for any public IP. Sites use this for marketing, anti-fraud, anti-bot defense, and personalization. So how much a request is trusted depends not only on the proxy but also on where the IP comes from.

5.1. Private Proxies

The term private points to a connection used by only one subject. A resource can be treated as truly private only when access is restricted by IP authorization or login and password, which prevents simultaneous use by outsiders.

The market offers proxies rented to one user for a defined period. Such resources are private during the rental window, but their quality can still depend on how earlier clients used them. Usually this is the most expensive class and, with comparable infrastructure, it gives the best stability and speed.

5.2. Shared Proxies with Restricted Access

The number of users is capped by IP binding or required authentication. Owners of small server-proxy pools or subnets do this most often. They also tend to block certain traffic types — outgoing SMTP, for example — to avoid RBL complaints.

An alternative source is resources obtained from botnets. They can be protected by credentials, but more often restriction is implemented through non-standard ports known only to the infrastructure owner. BackConnect proxies also belong here: they do not open an inbound port and instead initiate the outbound connection to a gateway. Their weaknesses are the unknown concrete IP and sudden address rotation every few minutes.

5.3. Public Proxies

Lists of public proxies are openly published on thousands of websites. They usually appear after scanning open ports across network ranges or after address leaks from infrastructure that used to be tied to botnets. After a basic validation, the share of truly working addresses in such sets often stays around 5 percent.

Paid aggregators collect those resources, revalidate them on a regular basis and provide users with working lists of much higher reliability. This is exactly the format behind the systematic checks and classification on Good-Proxies.ru.

6.1. Cascading Proxy Server (Proxy for Proxy)

A cascading proxy is a proxy that connects, as a client, to another upstream proxy. Several proxies stack into a chain: each next one makes an outbound link to the previous.

The key sign of a cascade is that the connection IP and the final IP seen by the target resource are not the same. This is what separates multi-layer schemes from a regular single proxy.

1. Several proxies with different source IPs, and even from different subnets, can produce the same final resulting IP.
2. A single final IP can expose several ports, each of which leads to a different source proxy and even a different geography.

6.2. BackConnect Proxy Server (Reverse Connection Proxy)

BackConnect works differently from a regular proxy. A regular one opens a port and waits for incoming requests, while BackConnect opens no inbound port — it makes an outbound connection to the client or a gateway.

1. A classical proxy stays in a passive mode and waits for an incoming connection.
2. A BackConnect proxy reaches out on its own, which helps bypass firewalls and NAT because outbound connections are usually allowed by default.

BackConnect implementation challenges

Such an architecture creates two fundamental tasks for the system.

1. How to pass the client IP address and port to the BackConnect proxy so it can establish the reverse connection.
2. How to ensure that the client is ready to listen for an incoming connection from the gateway server.

This is usually solved through a specialized gateway server that accepts the request from the client, forwards it to one of the BackConnect proxies and returns the result back.

1. The gateway accepts the request from the client and looks like a classic cascading proxy from the client side.
2. The gateway forwards the request to one of the connected BackConnect nodes.
3. The gateway receives the execution result and sends it back to the client.

Technology drawbacks: The client does not know in advance which final IP address will perform the request. Because of that, geographic control usually requires multiple gateways or separate port pools with predictable characteristics.

In the overwhelming majority of cases, BackConnect proxies come from botnet infrastructure.

7.1. Protocol Compatibility (HTTP vs. HTTPS/SOCKS)

If the target resource works only over a protected HTTPS protocol, for example https://yandex.ru/, using a regular HTTP proxy is not acceptable.

1. Standard HTTP proxies without CONNECT support cannot encapsulate and forward encrypted HTTPS traffic correctly.
2. For such tasks you should use only HTTPS proxies or SOCKS proxies.

7.2. Geographic Suitability (Excluding Chinese Resources)

China is a traditional source of a very large number of proxy resources, and the share of such addresses in the overall base can be high.

At the same time, because of the internal censorship system in China, some global services including Google.com, Gmail.com and x.com can be unavailable or unstable.

If your program produces too many connection errors, one possible reason is an attempt to reach a blocked resource through a Chinese proxy.

7.3. Session Stability (Long-Lived Resources)

If you are running tasks in a browser session or a long-running script, priority should be given to long-lived proxy resources.

1. Any proxy can stop working at any moment.
2. The risk of sudden interruption can be reduced by selecting addresses with stricter and more informative quality filters.

8.1. Limits of Full Anonymity

Using a proxy does not guarantee absolute anonymity and does not mean full communication security.

1. Even anonymous and high-anonymity proxies can leak client data through JavaScript and other channels.
2. Proxies themselves may keep detailed logs: traffic, credentials, and other sensitive data.
3. There is always a risk that a resource is controlled by attackers, state structures or intentionally built for traffic interception.

8.2. Proxy Chain Construction

A proxy chain is a sequence of several resources through which traffic passes one by one to increase anonymity.

1. HTTPS proxies, SOCKS proxies and web proxies can all participate in such a chain.
2. Unlike server-side cascades, this kind of proxy chain is built on the client side, by a dedicated program.

8.3. Methods for Building a Chain

1. For HTTPS and SOCKS chains you usually need a separate client tool, for example ProxyCap.
2. If the chain consists only of web proxies, it can be assembled directly inside the browser by opening the next proxy inside the previous session.

8.4. Critical Reliability Parameter

Any chain stops working if even one component inside it fails. The longer the chain, the higher the risk of interruption.

8.5. Proxy Judge Construction

A proxy judge is a specialized script-based resource that shows connection parameters and helps determine the true anonymity level.

1. When an HTTP request reaches it, it outputs the full set of headers and their contents.
2. These signals are exactly what proxy checkers use to identify the proxy type and its anonymity.
3. Choosing a fast and correct judge resource is critical for configuring automated checking systems.

8.6. IP Addressing in Network Space

The internet is a global network of computing nodes connected by wired and wireless communication channels. For these nodes to exchange information, each one needs a unique identifier: the IP address.

The most common format today is IPv4, which means four numeric octets from 0 to 255 separated by dots.

8.7. Classification of IP Ranges

For administration and risk evaluation you need to distinguish between private and dangerous address ranges.

8.8. DNSBL/RBL Mechanism (Realtime Blocking List)

DNSBL or RBL is a structured list of IP addresses and domain names observed in harmful network activity.

1. Typical reasons for listing include spam campaigns, DoS and DDoS attacks, and active port scanning.
2. The lists are distributed through DNS infrastructure. Some databases can also include dynamic IP addresses without direct malicious behavior.
3. The main purpose of DNSBL is to fight spam in email, comments and message forms.

8.9. Procedure for Verifying an IP Address in DNSBL/RBL

To check your IP against the most trusted block lists, open the your IP and RBL check page.

1. We only check block lists where being listed really points to suspicious activity. Dynamic lists are not analyzed separately.
2. After the query finishes you will see the list of databases that include the address and can follow the active source link to identify the reason and the removal procedure.

8.10. Botnet Concept

The term botnet combines the words robot and network and denotes a network of infected devices under centralized control.

1. Attackers use viruses, trojans and worms to remotely control user computers all over the world.
2. Such programs work covertly and consume user resources without the user knowing it.
3. Common botnet jobs: spam, password brute-forcing, DoS attacks, and ad-click fraud.