Quick Start: Your First Proxy Request

From a new account to a confirmed change of egress IP in about ten minutes, including the verification step most people skip.

Setting up a proxy has a definition of done that most first-time users get wrong. Done is not "my request succeeded". Done is "my request succeeded and the target saw an address that is not mine". A proxy that is silently bypassed (a mistyped scheme, an environment variable that excluded your target, a library that quietly ignored the settings you passed) produces requests that succeed flawlessly, from your real IP. Nothing errors. Nothing warns. You discover it weeks later, when whatever the proxy was supposed to protect turns out never to have been protected at all.

So this guide runs to a specific finish line: one request through the proxy, with the exit address compared against a baseline you recorded before you started. Five steps, about ten minutes, and the last step is the one that matters.

Minute zero: record your real IP

Before creating an account, before touching a config file, ask an IP echo service what address your machine currently presents to the internet:

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

Write down the answer. This is your baseline, and everything later in this guide is a comparison against it. Skipping this step is the root of the silent-bypass problem: without a baseline, "it printed an IP" tells you nothing, because your own address is also an IP, and it looks exactly as plausible as anyone else's.

Any echo service works: api.ipify.org, ifconfig.me, icanhazip.com. Pick one and stay with it for the whole session, because different services occasionally format their answers differently and you want your comparison to be a plain string match.

Step 1: create the account and confirm your email

Sign up, then open the confirmation link before doing anything else. This ordering is deliberate rather than bureaucratic: proxies are provisioned against a confirmed address, so an account that skips the email step has nothing provisioned yet. Attempting to authenticate at that point fails in a way that looks like a broken proxy rather than an incomplete signup, and people burn their first half hour debugging the wrong layer. The dashboard shows a persistent banner until the address is confirmed. If you can see that banner, stop and deal with it first.

The free tier provisions 3 free shared proxies with 1 GB/month bandwidth and 10 concurrent threads, which is enough to complete this entire walkthrough without entering payment details. What it includes and how the referral program works is set out in the free tier announcement. What the paid plans add is on the pricing page.

Step 2: find your credential on the Proxies page

Everything you need for the next step lives on one screen: Proxies, in the dashboard. Each product you hold gets its own row showing four values: host, port, username, password. Use the copy buttons rather than retyping or selecting text by hand; a value copied out of a rendered page by drag-selection can pick up trailing whitespace or typographic quote substitutions that are invisible on screen and fatal to authentication.

Two details trip up newcomers here:

• Credentials are scoped to a product. The username beside one host is not valid against another host. Always copy the pair from the same row as the host you are about to use.
• One port carries both kinds of traffic. You configure the HTTP proxy port even when the sites you visit are HTTPS. The proxy tunnels encrypted traffic through the same listener; there is no separate "HTTPS port" to hunt for.

Step 3: send one request through the proxy

Do this in a terminal first, even if your real work lives in a browser or a script. A single command isolates the proxy from every other variable:

curl -v -x http://USERNAME:PASSWORD@HOST:PORT https://api.ipify.org

Substitute all four values from your Proxies row. The -v output narrates the interesting part: you should see cURL connect to the proxy host, issue a CONNECT for the echo service, and report that the tunnel was established.

Three outcomes are possible:

• It prints an IP address. Continue to step 4, but do not celebrate yet, for reasons that step explains.
• It prints a 407 error. The proxy rejected the credentials. The causes are enumerable and all fixable in minutes; work through the 407 troubleshooting guide and come back.
• It hangs, or reports the connection was refused. The request never reached an authenticating proxy at all. Re-check the host and port against the dashboard row character by character, then see connection issues.

Step 4: confirm the egress IP actually changed

Compare the address printed in step 3 against your minute-zero baseline.

If they differ, you are done: genuinely done, in a way you can defend. The request left your machine, traversed the proxy, and exited from an address that is not yours. That is the entire job.

If they match, the request bypassed the proxy even though it succeeded. This happens more often than anyone expects, and always without an error message. The usual mechanisms: a NO_PROXY or no_proxy environment variable that happens to cover your target; tool configuration that applied the proxy to plain HTTP but not to HTTPS, letting encrypted traffic go direct; a system-level proxy setting overriding the one you thought you set; or a scheme typo that made the parser discard the proxy option entirely and fall back to a direct connection.

This is exactly why an IP echo service is the correct first target. Against a real website, a proxied request and a direct request return identical content, and you cannot tell them apart from the response. Against an echo service, the response is the verdict, and checking it is a string comparison.

One refinement worth doing while you are here: run the command twice. On a static product the exit address should be identical both times. On a rotating gateway it may legitimately differ between runs; that is the product working, not an inconsistency. Knowing which behavior your product exhibits now saves confusion later; understanding proxy types explains the distinction between static endpoints and gateways properly.

The two ways to authenticate

The command above used a username and password. That works on every product we sell. There is a second mode, available on some of them, and the two are alternatives rather than layers you stack.

With credential authentication, you attach the username and password to every request, and where you connect from is irrelevant. This is the right default for laptops, home connections, containers, and anything whose public address changes.

With IP whitelisting, available on every product, you register your machine's public address under Auth & IP Access in the dashboard, and then connect with no credentials at all: the proxy recognizes you by source address. On rotating you can instead send your username with an empty password, which keeps your country and session targeting without the secret. On the residential gateway it works the same way with one difference: there is no empty-password option, so you send nothing at all and get an untargeted exit, while country, city and session targeting still travel in the username. Where it is offered it is convenient for servers with stable addresses and for tools that make credential injection awkward, but it is brittle anywhere addresses drift: the day your address changes, requests start failing and nothing in your code changed. A free account can register 1 address; paid plans allow 3. The operational details and failure modes are covered in IP whitelisting best practices.

A reasonable rule, on the products that offer the choice: machines whose addresses never move can whitelist; everything else should send credentials.

Move the working setup into your real tool

The cURL command was scaffolding. Now that you have a verified working credential, transplant it into wherever the actual work happens. Then repeat step 4 inside that tool, because every tool has its own configuration path and every configuration path is a fresh opportunity for a silent bypass. The pattern is always the same: point the tool at the echo service, compare against your baseline.

• Browsers have their own proxy plumbing, covered in browser proxy setup.
• Python scripts and the requests library are covered in Python proxy integration.
• Node applications need an explicit agent; see Node.js proxy setup.

Where to go from here

You now have a working proxy and, more importantly, a repeatable way to prove it is working. The next question is whether the type of proxy you are holding matches what you intend to do with it. Understanding proxy types explains what datacenter, residential, shared and rotating actually mean at the network level, and choosing the right proxy type turns that taxonomy into a decision. If you already know you need more than the free tier provides, the plans are compared here.

Whatever you build next, keep the habit this guide was really about: never trust a proxy configuration you have not verified from the outside. The echo check costs five seconds, and it is the only thing standing between "configured" and "confirmed".