This guide shows how to confirm that your InstantProxies setup is actually working before you move into application code, browser configuration, or browser automation.
It is written for developers, scraping engineers, automation engineers, and technical operators who need to verify that traffic is routing through the intended proxy path and that the selected authentication method is working correctly.
If you have already completed a first test request, this is the next page you should follow.
Why Verification Matters
A proxy setup can look correct in the dashboard and still fail at runtime.
For example, you may have:
- the right proxy IP but the wrong authentication method
- a valid allowlist entry but the wrong source machine
- working credentials copied into the wrong request format
- a browser or client that appears configured but is still sending traffic directly
That is why verification should happen before deeper implementation. The goal is to prove the actual network path, not just the dashboard configuration.
What a Verified Connection Means
A verified connection means you have confirmed all of the following:
- the proxy endpoint is reachable
- the selected authentication method is working
- traffic is being sent through the proxy rather than directly
- the destination sees the proxy IP you intended to use
- your current environment behaves the way you expect before you add more complexity
This gives you a clean baseline for every later guide in the documentation.
Start with the Simplest Possible Test
Always begin with a minimal request before using a framework, crawler, or browser workflow.
The simplest baseline test is a cURL request to the InstantProxies IP check endpoint.
If You Are Using IP Whitelist Authentication
curl -x http://PROXY_IP:PORT http://checkip.instantproxies.com/
If You Are Using Username and Password Authentication
curl -x http://USERNAME:PASSWORD@PROXY_IP:PORT http://checkip.instantproxies.com/
Replace the placeholders with the exact values from your dashboard.
If you have not already done this baseline test, go to First Request with cURL first.
What a Successful Result Looks Like
A successful verification request should return an IP value seen through the proxy path.
Expected format:
IP=YOUR_PROXY_IP
That result confirms the most important thing first: the request is being routed through the proxy rather than going out directly from your normal connection.
Verify the Correct Authentication Method
InstantProxies supports multiple authentication methods, so part of verification is making sure you are testing the one you actually selected.
If You Chose IP Whitelist Authentication
Confirm that:
- the public source IP of the machine sending the request is allowlisted
- you are testing from that same machine or environment
- you are not unintentionally mixing in proxy credentials when they are not needed
If you need to review the dashboard-side setup, use Authorizing Your IP Address.
If You Chose Username and Password Authentication
Confirm that:
- the username and password are copied exactly as shown in the dashboard
- the credentials are included in the proxy request correctly
- you are not assuming IP allowlisting is active if it is not the method you selected
Many first-time verification failures come from testing the wrong authentication model rather than from a bad proxy endpoint.
Verify from the Same Environment You Actually Plan to Use
A verified connection should come from the same type of environment that will run the real workload.
For example:
- if your scraper will run on a cloud VM, verify from the cloud VM
- if your application will run in a server environment, verify from that server
- if your browser workflow will run locally, verify from that local machine first
- if your CI pipeline will send traffic, verify from that pipeline environment separately later
Do not assume that because a proxy works on one machine, it is already verified everywhere else.
Use the Dashboard Tools as a Second Check
After your direct cURL test works, use the built-in tools to confirm the environment more clearly.
Test Proxies in the Dashboard
Use the dashboard proxy test to confirm that the assigned proxies are online and responsive.
This helps separate endpoint availability from local configuration problems. If you need help with the control panel itself, start with Dashboard Overview and Testing Proxies in the Dashboard.
Browser Privacy Test
If your next step is browser usage or browser automation, use Browser Privacy Test to see what a destination sees from your browser session.
This is especially useful for confirming that browser-level traffic is actually leaving through the proxy path rather than through your direct system connection.
Network Status Page
If a setup that previously worked suddenly stops working, check Network Status before assuming the issue is only local.
This helps you distinguish between:
- local misconfiguration
- environment drift
- temporary proxy availability issues
- broader service-level conditions
For incident context, continue to Network Status and Incident Interpretation.
Signs That the Connection Is Not Really Verified Yet
Your connection is not fully verified if any of these are still unclear:
- you have not run a minimal direct test
- you do not know which authentication method the request actually used
- you do not know which source environment the request came from
- you have not confirmed the returned IP through the proxy path
- your application appears to work sometimes, but you have never proven the baseline outside the application itself
If any of those apply, continue verifying before moving into a larger workflow.
Common Verification Mistakes
The most common verification mistakes are:
- verifying through a larger application instead of a minimal request
- testing from the wrong machine or environment
- mixing authentication methods accidentally
- copying the wrong proxy IP or port
- assuming a browser is using the proxy because the browser settings look correct
- skipping the returned-IP check and assuming success too early
Verification is only complete when the network path itself is proven.
If Verification Fails, Check These in Order
If the connection is not working as expected, check these in order:
- Did you use the correct proxy IP and port?
- Did you choose the correct authentication method?
- If using IP whitelist authentication, is the current source IP really allowlisted?
- If using username and password authentication, were the credentials copied exactly?
- Are you testing from the same environment you intended to validate?
- Does the dashboard proxy test show the proxy online?
- Does the problem happen in the minimal request, or only in the larger application?
If the minimal verification request fails, solve that first before debugging code, browser state, or automation runtime behavior.
For deeper diagnosis, continue to Connectivity Troubleshooting or Authentication and Allowlist Errors.
What to Do After Verification Succeeds
Once your connection is verified, you have a known-good baseline.
From there, move into the guide that matches your next real task.
If You Want to Use InstantProxies in Code
Continue to a language-specific guide such as Python, Node.js, PHP, Java, Go, or .NET.
If You Want to Use InstantProxies in a Browser
Continue to the browser setup guides.
If You Want to Use InstantProxies in Browser Automation
Continue to the Playwright, Puppeteer, or Selenium guides in the browser automation section.
If You Need to Diagnose a Failure
Continue to:
- Connectivity Troubleshooting
- Authentication and Allowlist Errors
- Local Failures vs Target-Site Blocks
Before Contacting Support
Before opening a support request, collect these details:
- the exact proxy IP and port you tested
- which authentication method you selected
- the source IP you allowlisted, if using IP whitelist authentication
- the username used, if using username and password authentication
- the machine or environment you tested from
- whether the minimal verification request succeeded or failed
- what returned IP you saw, if any
- whether the dashboard test showed the proxy online
This makes support much faster and helps avoid unnecessary back-and-forth.
Recommended Next Step
If your connection is verified, continue to Choose the Right Integration Path.
If verification failed, continue to Connectivity Troubleshooting before changing your broader imple