How to set up a proxy and verify your first request

To set up a proxy, you choose a proxy line, fund an account, collect the gateway host, port and credentials, pick an authentication mode, and generate a connection string for the country and session behavior you want. Then you verify it: send a request through the proxy to an IP echo service, confirm the exit address and country, confirm HTTPS and SOCKS5 work, and confirm the address rotates or holds as intended. The whole procedure takes about fifteen minutes with nothing more than curl, and it gives you a known-good baseline before any scraper or browser is involved.

This guide uses ProxyForge's dashboard for the account steps, but the verification half applies to any provider. Every command reads the connection string from an environment variable, and every placeholder is written as USERNAME, PASSWORD and PORT: substitute the values your dashboard shows, never values copied from an article.

Which proxy line should you start with?

The first decision when you set up a proxy is the line. Pick the one that matches the target, not the cheapest one on the price list. A short version of the decision:

If you are unsure, start small on the line you think fits and measure. The trade-offs are covered in depth in residential vs ISP vs datacenter proxies, and each line's product page lists current coverage, for example the residential proxies page.

Step 1: fund the wallet and place a small order

ProxyForge bills pay-as-you-go from a prepaid wallet, with no monthly minimum. Residential and mobile are ordered by the gigabyte, ISP and datacenter by the address, and the smallest order is 1 GB or 1 IP. ISP and datacenter also have a paid trial. Current rates are on the pricing page.

For a first test, order the minimum. You are verifying plumbing, not throughput, and a verification run like the one below uses a few megabytes at most.

If more than one person will use the account, create an organization now and add colleagues with the narrowest role that fits: owners manage members, billing, API keys and settings, users buy and manage proxies, and read-only members can see usage without changing anything. Proxy team access walks through the roles in detail.

Step 2: collect credentials and choose an auth mode

Open the dashboard at app.proxyforge.io and find the proxy credentials for the line you ordered. You need three things: the gateway host, the port, and either a username and password or an allowlisted source IP.

Every line supports both authentication modes:

• Username and password. The client sends credentials with each proxy connection. This works from anywhere, including laptops, CI runners and serverless functions whose outbound address changes.
• IP allowlist. You register the public IP your traffic leaves from, and the gateway accepts connections from that address without credentials. This suits tools that cannot send proxy credentials, such as Chrome launched with --proxy-server.

To allowlist, you need your true egress address, which is not the address on your network interface if you sit behind NAT. Ask an echo service directly, without a proxy, from the machine that will send the traffic:

curl -s https://api.ipify.org

Register the address it prints. If your workloads run behind a cloud NAT gateway, a corporate firewall or a Kubernetes egress gateway, run the command from inside that environment, because the address your laptop sees is not the address the gateway will see. The full comparison of the two modes, including the security trade-offs, is in IP allowlist vs username and password proxy authentication.

Step 3: generate a connection string

Targeting options, such as the exit country and whether the session rotates or holds an address, are chosen in the dashboard's configuration panel, which generates the exact connection string for your selection. Use the generator rather than composing the string by hand: the format is specific to your account and the generator is the source of truth.

For a first test, generate two strings for the same country: one rotating, one sticky. The shape is:

http://USERNAME:[email protected]:PORT

Export it as an environment variable so that it never lands in shell history or a committed file in plain form:

read -rs PROXY_URL && export PROXY_URL

Paste the string at the prompt; -s keeps it off the screen. If your password contains characters such as @, :, / or #, they must be percent-encoded inside a URL. The dashboard's generated string handles this; a string assembled by hand often does not.

Step 4: send the first request and confirm the exit IP

Compare your direct address with the address seen through the proxy:

curl -s 'https://api.ipify.org?format=json'
curl -s -x "$PROXY_URL" 'https://api.ipify.org?format=json'

The second response should show a different IP. If both lines print the same address, the request did not use the proxy. If the second command fails, jump to the troubleshooting table below before changing anything else.

Check the exit country independently

The echo service tells you the address, not where it is. Look the address up in a geolocation service, sending that request through the proxy as well so you check the same exit:

curl -s -x "$PROXY_URL" https://ipinfo.io/json

Read the country field. Geolocation databases disagree at the edges, so judge country-level targeting on the country, not the city, and when a result looks wrong, check a second database before concluding that targeting failed. For static ISP and datacenter addresses, a registry lookup through RDAP will also show who holds the range, which is the basis of the provenance checks described in what IP provenance means.

Step 5: confirm HTTPS and SOCKS5 work

HTTPS through the CONNECT tunnel

An HTTP proxy carries HTTPS traffic by opening a tunnel: the client sends CONNECT host:443 to the proxy, the proxy answers 200, and the TLS handshake then runs end to end between your client and the target. The proxy relays encrypted bytes and never sees the page content. Watch this happen with verbose output:

curl -sv -x "$PROXY_URL" https://api.ipify.org -o /dev/null 2>&1 | grep -E '^(> CONNECT|< HTTP|\* SSL|\* TLS)'

You should see the CONNECT line, a 200 response from the proxy, then the TLS handshake with the target, then the target's own HTTP status. A 407 here means the proxy rejected your credentials before the tunnel opened; a TLS error after a successful CONNECT is between your client and the target, not the proxy.

Note that with an http:// proxy URL, the hop from your client to the gateway itself is not encrypted until the tunnel opens, which means the proxy credentials travel in a header readable on that hop. Treat the proxy password as a secret with the same care as an API key.

SOCKS5 with remote DNS

Every ProxyForge line also speaks SOCKS5, on the same host, port and credentials: switch the scheme to SOCKS5 in the dashboard's code examples and only the URL scheme changes. With the username and password exported as PROXY_USER and PROXY_PASS, use remote DNS resolution so the hostname is resolved at the proxy rather than on your machine; otherwise your local resolver leaks the lookup and may return an address that is wrong for the exit country:

curl -s --socks5-hostname gateway.proxyforge.io:PORT \
  --proxy-user "$PROXY_USER:$PROXY_PASS" \
  'https://api.ipify.org?format=json'

The equivalent with a single URL uses the socks5h:// scheme, where the h means remote DNS:

curl -s -x "socks5h://USERNAME:[email protected]:PORT" 'https://api.ipify.org?format=json'

In code, the same distinction applies. Python Requests, for example, needs socks5h:// and the requests[socks] extra; see using a proxy with Python Requests for the full configuration.

Step 6: confirm rotation or stickiness

Run several requests in a row with each connection string and compare the addresses:

for i in 1 2 3 4 5; do curl -s -x "$PROXY_URL" https://api.ipify.org; echo; done

With a rotating string, you should normally see a different address on most lines. With a sticky string, you should see the same address on every line for the length of the session. Sticky sessions on peer-based lines can end before their maximum duration if the peer goes offline, so an occasional change is expected; a change on every request with a sticky string means the string is not the sticky one. ISP and datacenter addresses do not rotate at all: every request leaves from the address you were assigned.

Which behavior your workload needs is its own design question, covered in rotating vs sticky proxies.

Troubleshooting the first request

If the table does not resolve it, capture the output of curl -v with the password redacted and send it to support; that output shows exactly which hop failed.

Next steps

Once these checks pass, you have a known-good connection string and a way to prove it still works. Keep the curl commands above as a smoke test to run whenever something upstream breaks or you set up a proxy for a new team, then move on to your client of choice.

ProxyForge issues credentials and connection strings from the dashboard, supports HTTP, HTTPS and SOCKS5 on every line, and gives every account a named engineer for support, including the first integration. If you are moving from another provider rather than starting fresh, the migration process mirrors your existing endpoint structure and auth format so the checks above can run against both providers side by side.