Client Login

Endpoints, Protocols, and Connection Strings

6 min read

Use this guide to understand which endpoint to use, which protocol your client supports, and how to format a correct proxy connection string for InstantProxies.

A large percentage of proxy setup failures come from simple formatting mistakes: wrong host, wrong port, wrong protocol, incorrect authentication syntax, or using a connection format that the client does not actually support. This page is the canonical reference for connection format.

Use this page when

Use this page when:

  • you are connecting to InstantProxies for the first time
  • your client asks for a host, port, or proxy URL
  • you are unsure whether to use HTTP, HTTPS, or SOCKS5
  • authentication is failing and you need to verify the exact format
  • a tool works with one connection string format but not another

What this page covers

This page explains:

  • what an endpoint is in the context of InstantProxies
  • how protocol choice affects the connection format
  • how to structure host, port, and credentials correctly
  • when to use URL-style proxy strings versus separate host and port fields
  • common formatting mistakes that break proxy connections

What an endpoint means

For InstantProxies, an endpoint is the proxy connection target your client connects to.

That usually includes:

  • a proxy host
  • a proxy port
  • an authentication method
  • a supported protocol

Your client may accept these values in one of two common ways:

  • as a full proxy URL or connection string
  • as separate fields for host, port, username, and password

The correct format depends on the client or runtime you are using.

Supported protocol concepts

The most common proxy protocol patterns are:

  • HTTP proxy
  • HTTPS proxy handling through an HTTP proxy endpoint
  • SOCKS5 proxy, if supported by the product and the client

Different clients use the word protocol differently. Some clients ask for the proxy protocol. Others only want a proxy URL. Others want separate fields and derive the protocol from the client implementation.

Always match the connection format to both:

  • the protocol InstantProxies supports for your plan or product
  • the protocol your application or library actually supports

Canonical connection string format

When a client accepts a full proxy URL, the most common format is:

http://USERNAME:PASSWORD@HOST:PORT

If your access model uses IP authorization instead of username and password, the most common format is:

http://HOST:PORT

If your client expects separate values, use:

  • host: HOST
  • port: PORT
  • username: USERNAME
  • password: PASSWORD

Only include credentials when your authentication model requires them.

HTTP proxy format

Use this format when the client expects an HTTP proxy URL:

http://USERNAME:PASSWORD@HOST:PORT

Or, if IP authorization is already in effect:

http://HOST:PORT

This is the most common connection pattern for cURL, Python requests, Node.js proxy agents, and many browser or scraping tools.

HTTPS requests through a proxy

Many clients still use an http:// proxy URL even when the destination website is https://.

That means the destination can be HTTPS while the proxy connection string still looks like this:

http://USERNAME:PASSWORD@HOST:PORT

Do not assume that an HTTPS destination means the proxy URL itself must start with https://.

The correct proxy scheme depends on what the client expects and what the proxy service supports.

SOCKS5 format

If SOCKS5 is supported by the product and your client, the most common format is:

socks5://USERNAME:PASSWORD@HOST:PORT

Or with IP authorization:

socks5://HOST:PORT

Only use SOCKS5 if:

  • InstantProxies supports it for your service
  • your client or library supports it directly
  • you are intentionally using that protocol instead of HTTP proxying

Username and password authentication

If your account uses username and password authentication, include credentials exactly as required by the client.

Full URL format:

http://USERNAME:PASSWORD@HOST:PORT

Separate-field format:

  • host
  • port
  • username
  • password

Do not mix authenticated and allowlisted connection styles unless you are sure the product and environment are configured that way.

IP-authorized connections

If your account uses source IP authorization, the connection format usually omits credentials.

http://HOST:PORT

This works only when the public IP of the runtime environment is already authorized.

If a connection works locally but fails on a server or in CI, recheck whether the server or runner public IP is actually allowlisted.

Full examples

cURL example

curl -x http://USERNAME:PASSWORD@HOST:PORT https://httpbin.org/ip

Python requests example

proxies = {
    "http": "http://USERNAME:PASSWORD@HOST:PORT",
    "https": "http://USERNAME:PASSWORD@HOST:PORT",
}

Node.js example

const proxyUrl = 'http://USERNAME:PASSWORD@HOST:PORT';

Host and port only example

host = HOST
port = PORT
username = USERNAME
password = PASSWORD

When clients want separate fields instead of a URL

Some applications do not accept a full proxy URL.

They may ask for:

  • proxy host
  • proxy port
  • proxy username
  • proxy password
  • proxy type or protocol

In those cases, do not paste the full connection string into the host field.

Use the values separately and match the protocol selector correctly.

Common connection-string mistakes

Typical issues include:

  • using the wrong host
  • using the wrong port
  • placing the full URL into a host-only field
  • omitting credentials when the runtime is not allowlisted
  • including credentials when the client expects separate fields instead of a full URL
  • using the wrong scheme such as https:// when the client expects http://
  • assuming destination HTTPS changes the proxy URL format automatically
  • using SOCKS5 syntax in a client configured only for HTTP proxies

These errors are simple, but they are also some of the most common reasons a proxy does not connect.

How to verify the format quickly

The fastest baseline check is usually a cURL request.

curl -x http://USERNAME:PASSWORD@HOST:PORT https://httpbin.org/ip

If this works, the connection format is likely correct and the next step is validating how the application or library consumes it.

If this fails, verify:

  • host
  • port
  • username
  • password
  • protocol scheme
  • whether the runtime environment is allowlisted if credentials are omitted

Format guidance by usage pattern

Use a full proxy URL when

Use a full URL when the client accepts one string value such as:

  • proxy URL
  • proxy server
  • proxy address

Use separate values when

Use separate fields when the client explicitly asks for:

  • host
  • port
  • username
  • password
  • proxy type

Use IP-authorized format when

Use the host-and-port-only format only when:

  • your source IP is already authorized
  • the runtime environment is the one actually sending traffic

Use this sequence:

  1. confirm the supported protocol for the client and product
  2. confirm whether authentication is username/password or IP authorization
  3. build the connection string in the format the client expects
  4. validate the format with cURL
  5. reuse the same structure in application code
  6. troubleshoot client-specific issues only after the baseline format is proven

Key points

  • endpoint setup means using the correct host, port, protocol, and authentication model together
  • the correct connection string depends on both the proxy service and the client consuming it
  • HTTPS destinations often still use an http:// proxy URL format
  • some clients require a full proxy URL, while others require separate fields
  • incorrect connection formatting is one of the most common causes of proxy setup failure
  • validate the format with cURL before debugging a larger integration

Next step

Continue to Authentication and Access for guidance on credentials, allowlisting, and account access models.

If you want to test the connection format immediately, continue to First Request with cURL.