Types of proxies: a developer's guide to the labels

Suppose your test worker needs a fixed address for an API allowlist. A rotating residential service could offer thousands of exits and still miss that requirement.

Proxy names become easier to read when you split them into separate decisions: where traffic exits, when that IP changes, and how your client connects. A single service can have several labels because each describes a different property.

Are you sending requests or receiving them?

A forward proxy handles outbound connections for a client. You configure your browser or worker to contact it, and it connects to the destination.

A reverse proxy receives traffic for a service you operate. It can send incoming requests to different backends, distribute load, and cache responses. The NGINX reverse proxy documentation shows this server-side setup.

If you're choosing an exit for a script, you're usually evaluating forward proxies. If you're putting a gateway in front of your application, you're designing a reverse proxy deployment.

Choose the exit network

Commercial proxy catalogs commonly group addresses into four sources:

• Datacenter proxies use IPs associated with hosting or cloud infrastructure. Try these for a permitted workload that has no requirement for a consumer or cellular exit.
• Residential proxies use IPs associated with consumer internet connections. They can help when testing how your own service behaves for visitors on those networks.
• ISP proxies, often sold as static residential proxies, generally combine ISP-associated addresses with server infrastructure. Ask how the service is hosted and how addresses are assigned; the label doesn't establish a household connection.
• Mobile proxies exit through cellular carrier networks. They're relevant when carrier routing matters, but they don't reproduce a phone's browser, operating system, or screen size.

These are descriptions of the exit network. Speed, location accuracy, and availability still need testing. An IP-intelligence database can also classify proxy activity separately from network origin; MaxMind documents these distinctions.

Decide how long the address must last

For an allowlisted API client, ask for an address that remains assigned for the required period, along with its replacement policy. Both datacenter and ISP services can offer fixed exits.

Rotation is useful when a test needs observations from several addresses. Check the trigger: a new request, a timer, or an explicit rotation operation. A rotating endpoint can select an address already used earlier, so verify whether the service promises a different IP.

IP persistence and application state are separate. Your client still needs to maintain cookies or tokens across requests. Keeping an address fixed doesn't preserve a login by itself.

Match the protocol to your application

HTTP proxies understand HTTP requests. For an HTTPS destination, a common setup uses CONNECT to open a tunnel, followed by TLS between the client and destination. Keep certificate validation enabled.

Check what a provider means by "HTTPS proxy." Supporting HTTPS destinations through a tunnel and accepting TLS connections to the proxy are separate capabilities. In curl, an https:// proxy URL selects TLS on the client-to-proxy connection. The curl proxy overview explains both connection layers.

SOCKS5 can carry traffic beyond HTTP. RFC 1928 defines TCP operations and UDP association, but your client and proxy service must implement the features you need. SOCKS5 support alone doesn't tell you whether the connection is encrypted.

DNS handling also depends on the client. With curl, socks5:// resolves the destination locally; socks5h:// sends its hostname to the proxy. Check the equivalent option in your library rather than assuming every SOCKS5 connection resolves names remotely. See the curl SOCKS guide.

Read access and privacy labels carefully

Public proxies allow broad access. Shared services let multiple customers use resources. "Private" often indicates restricted access, so ask separately whether the exit IP or capacity is shared.

"Anonymous" doesn't tell you what the operator logs or what identifiers your application sends. Evaluate those details before sending sensitive traffic through an unfamiliar service.

"Transparent" has multiple meanings. In network architecture, it can describe interception without an explicit client proxy setting, as RFC 9110 explains. Some proxy lists instead use it for services that expose client information. Ask which behavior is intended.

Turn the labels into a testable requirement

For the allowlisted worker, an initial specification might be:

Role: forward proxy
Exit network: datacenter acceptable
IP lifetime: fixed throughout the API allowlist period
Protocol: compatible with the worker's HTTPS requests
Access: authenticated; confirm whether the exit is shared
Failure policy: notify before replacing the assigned IP

Run a representative permitted job through the actual worker. Confirm its visible exit, validate the returned data, and record elapsed time and retries. Compare total spend per usable result, including billed traffic from failed attempts.

For collection work, follow the destination's access rules and rate limits. When requests fail, inspect authentication, protocol settings, and the response before buying a different proxy category. A successful connection to an IP-check page establishes much less than a completed application workflow.