Quick Start: Your First Proxy Request

From a new account to a confirmed change of exit IP in about ten minutes, including the check that proves the proxy is really in the path.

Send your first request through Node4, then check that the destination sees your proxy's IP address instead of your own. That second part is the goal of this guide. A proxy that is silently bypassed (a mistyped scheme, an environment variable that excluded your target, a library that ignored the setting) returns successful responses from your real address, and nothing warns you. Four steps, about ten minutes.

Before you start: record your real IP

Ask an IP echo service what address your machine currently presents:

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

Write the answer down. Every later check in this guide compares against it. Any echo service works (api.ipify.org, ifconfig.me, icanhazip.com); pick one and use it throughout so the comparison is a plain string match.

Step 1: create the account and confirm your email

Sign up, then open the confirmation link before anything else. Free proxies are issued only once the address is confirmed, so an unconfirmed account has nothing to authenticate against yet, and the failure looks like a broken proxy rather than an incomplete signup. The dashboard shows a banner until the address is confirmed; if you can see it, deal with that first.

Dashboard banner asking you to verify your email address before your free proxies are issued.

The free tier is 3 free shared proxies with 1 GB/month bandwidth and 10 concurrent threads, enough to complete this walkthrough with no payment details. If the Dashboard instead shows a banner saying the free proxies were not added (one free set per person, for example), the banner states the reason and links to support or plans. Free proxies that carry no traffic for 30 days are paused, and one click brings back a fresh set. What it includes is in the free tier announcement; what the paid plans add is on the pricing page.

Step 2: copy your connection values from the Proxies page

Open Proxies in the dashboard. The Connect card holds everything. With Copy as set to url and the protocol on HTTP, its top line is the complete proxy URL, http://USERNAME:PASSWORD@HOST:PORT, already percent-encoded. Copy that line, or the four fields below it (host, port, username and password) if your tool asks for them separately.

Connect card on the Proxies page: connection string, host, port, username and password, each with a copy button.

  • One credential per account. Your username and password are the same on every product you hold an active plan for. Static proxies (the free set, shared and dedicated datacenter) each have their own IP address; the card shows one as Host (example) and the full list is further down the page. The rotating and residential gateways use one fixed hostname and port.
  • Use the copy buttons. A value drag-selected from a rendered page can pick up trailing whitespace or typographic quotes that are invisible on screen and fail authentication.
  • One port carries HTTP and HTTPS. Configure the HTTP proxy port even for HTTPS sites; encrypted traffic is tunnelled through the same listener. There is no separate HTTPS port.

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, so the proxy is isolated from every other variable:

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

Paste the URL from the Connect card in place of http://USERNAME:PASSWORD@HOST:PORT. The -v output should show curl connecting to the proxy host, issuing a CONNECT for the echo service, and reporting the tunnel established. Three outcomes:

  • It prints an IP address. Continue to step 4.
  • It prints a 407 error. The proxy rejected the credentials. Work through the 407 troubleshooting guide and come back.
  • It hangs, or the connection is refused. The request never reached the proxy. Re-check the host and port against the dashboard row, then see connection issues.

Step 4: confirm the exit IP changed

Compare the address printed in step 3 with the one you recorded at the start.

If they differ, the setup works. The request left your machine, went through the proxy, and exited from an address that is not yours.

If they match, the request bypassed the proxy even though it succeeded. The usual causes: a NO_PROXY or no_proxy environment variable that covers your target; a tool that applied the proxy to plain HTTP but not HTTPS; a system-level proxy setting overriding the one you set; or a scheme typo that made the parser discard the proxy option and connect directly. Fix the cause and repeat step 3.

An echo service is the right first target because its response is the verdict. Against a real website, a proxied and a direct request return identical content and you cannot tell them apart.

Run the command twice. On a static product, the free set included, the exit address is the same both times. On a rotating gateway it will usually differ between runs, because each curl run opens a new HTTPS tunnel and the gateway picks an exit per tunnel; that is the product working. Understanding proxy types explains the difference between static endpoints and gateways.

The two ways to authenticate

The command above used a username and password, which works on every product and from any network. The alternative is IP whitelisting, available on every product: register your machine's public address under Account Settings → Auth & IP Access and connect with no credentials. The two are alternatives, not layers. One cost to know: a whitelisted residential connection sends no username, so its exit is untargeted, with no country, city or session. A free account can register 1 address; paid plans allow 3. Whitelisting suits servers with fixed addresses, and it fails the day the address changes, with nothing changed in your code. What each product keeps when you whitelist is in authentication; the failure modes are in IP whitelisting best practices.

Move the working setup into your real tool

Now put the same four values into the tool you actually use, then repeat step 4 inside that tool: point it at the echo service and compare against your baseline. Every tool has its own configuration path, and each one is a fresh chance for a silent bypass.

A paid plan is delivered as soon as the payment is confirmed, and an email titled "Your Node4 proxies are ready" (static plans) or "Your Node4 gateway is live" (rotating and residential) follows with your endpoint. Where to look:

  • Static plans (shared and dedicated datacenter) add one row per IP on the Proxies page.
  • Gateway plans (rotating and residential) add no IP rows. Their fixed hostname and port are on the Connect card on the same page.
  • Your username and password are the same account-wide credential you already have, under Account Settings → Auth & IP Access. A new plan does not issue a new one.

If nothing appears, open Orders. A pending order is a payment still confirming: a Bitcoin transaction waiting for network confirmation, a PayPal payment PayPal has not completed, or a card payment held for review. Do not pay again. An email titled "We are still setting up your ..." means the payment went through and delivery is being finished by our team. Payment problems explains each case and when to contact support.

Next steps

You have a working proxy and a repeatable way to prove it. The next question is whether the type of proxy you hold matches the job. Understanding proxy types explains datacenter, residential, shared and rotating at the network level, and choosing the right proxy type turns that into a decision. If you already know you need more than the free tier, the plans are compared here.

Whatever you build next, keep the echo check. It takes five seconds and it is the difference between "configured" and "confirmed".

Copy-paste examples for curl, Python, Node.js, Go and Scrapy are in our examples repository on GitHub.