Use this guide to understand how InstantProxies authenticates requests, how access is granted to your runtime environment, and how to choose the correct connection method for your setup.
Authentication failures are one of the most common reasons a proxy does not work on the first try. In most cases, the issue is not the proxy itself. It is a mismatch between the configured access method and the environment actually sending traffic.
Use this page when
Use this page when:
- you are connecting to InstantProxies for the first time
- you need to know whether to use username and password or IP authorization
- a request works in one environment but fails in another
- your application, browser, or scraper is getting authentication or access errors
- you want the canonical setup guidance before debugging a larger workflow
What this page covers
This page explains:
- the common authentication models used with InstantProxies
- when to use credentials versus IP authorization
- how access relates to the actual runtime environment
- why authentication and access control are related but not identical
- common mistakes that cause authentication failures
- how to validate the access path before moving into application code
Two common access models
The most common access models for proxy usage are:
- username and password authentication
- source IP authorization
Your setup may use one of these or a combination supported by the product and account configuration.
The important question is not only what authentication model exists, but which one your current runtime is actually using.
Username and password authentication
With username and password authentication, your client includes credentials when connecting to the proxy.
The most common full proxy URL format is:
http://USERNAME:PASSWORD@HOST:PORT
Some tools do not accept a full proxy URL. They may instead ask for:
- host
- port
- username
- password
In that case, enter the values separately instead of pasting the full connection string into one field.
Use username and password authentication when:
- your runtime environment is not allowlisted
- you want a direct credential-based connection method
- your client or application is designed to supply proxy credentials explicitly
Source IP authorization
With source IP authorization, the proxy allows traffic from approved public IP addresses.
The most common connection format is:
http://HOST:PORT
No username or password is included when the source IP is already authorized.
Use IP authorization when:
- the traffic comes from a known server or fixed public IP
- your environment is easier to authorize by IP than by passing credentials in the client
- your runtime does not handle proxy credentials cleanly
If your setup uses IP authorization, the request will only work when the real public IP of the runtime environment is on the allowlist.
Choose the access model that matches the runtime
The most important rule is simple: authenticate from the environment that actually sends the traffic.
This matters because:
- a local machine and a server do not share the same public IP
- a container may not use the same public IP as the host you expect
- a CI runner may use a completely different public IP than local development
- browser tools, scripts, and deployment workers may each run from different environments
A request may succeed locally and fail in production even though the code is identical, simply because the access model does not match the real runtime path.
Authentication is not the same as access control
Authentication answers whether the proxy should accept the connection.
Access control answers which runtime, user, or environment should be allowed to use that connection method.
In practice, this means:
- credentials may be valid, but the wrong environment is still using them
- an IP may be allowlisted, but it may not be the runtime you intended to trust
- a local test may work while a production worker still fails because the access boundary is different
Treat authentication as part of the access model, not as a standalone credential check.
Access control basics for proxy usage
For most InstantProxies users, good access control means keeping the access method aligned with the actual runtime.
That usually means:
- use credentials when the runtime environment is variable or hard to allowlist safely
- use IP authorization when the runtime comes from a stable, known public IP
- avoid reusing one environment’s access assumptions in another environment without rechecking them
- do not expose raw credentials more broadly than necessary
You do not need a large authorization model to use the proxy correctly, but you do need to know which environment is actually trusted.
How authentication and connection format work together
Authentication and connection format should match.
Use this format when using credentials
http://USERNAME:PASSWORD@HOST:PORT
Use this format when using IP authorization
http://HOST:PORT
Do not omit credentials unless:
- your source IP is actually authorized
- you are sure the environment sending the request is the one on the allowlist
Do not include credentials just because they exist in your account if your setup is intentionally using allowlisting and the client expects a simpler connection method.
Common access mistakes
Typical issues include:
- using IP authorization for a runtime whose public IP is not actually allowlisted
- testing locally and assuming the same access applies on a server or CI runner
- pasting a full proxy URL into a field that expects only a host
- omitting credentials in a runtime that is not allowlisted
- including credentials in the wrong field order for the client
- using one environment’s access model in another environment without rechecking the real outbound path
- assuming browser extensions, scripts, and backend jobs all share the same public IP
These are access-path problems, not application-logic problems.
How to validate access quickly
The fastest baseline check is usually a cURL request.
Credential-based test
curl -x http://USERNAME:PASSWORD@HOST:PORT https://httpbin.org/ip
IP-authorized test
curl -x http://HOST:PORT https://httpbin.org/ip
Use these requests to confirm:
- the proxy host and port are correct
- the authentication model is working
- the environment can actually access the proxy
If the first access test fails, validate the access method before debugging a larger workflow.
Access errors usually point to one of three things
When a proxy request fails because of access, the most common causes are:
1. Wrong authentication method
The runtime is using IP authorization when it should use credentials, or using credentials when the client is actually configured differently.
2. Wrong runtime environment
The allowed IP belongs to one environment, but the request is coming from another.
3. Wrong connection format
The client is not consuming the host, port, username, or password in the way it expects.
These are usually easier to fix than deeper application bugs, but only if the baseline access path is checked first.
Access guidance by environment type
Local development
Use this when:
- testing from your own machine
- validating connection format
- confirming baseline behavior before deployment
Be careful with IP authorization here because your home or office public IP may differ from production.
Server or VPS
Use this when:
- running a scraper or application from a known host
- connecting from a stable public IP
- using allowlisting for a long-lived runtime
This is often the cleanest fit for IP authorization.
Containers and CI
Use extra care here because:
- the public IP may differ from the host you expect
- runners may rotate IPs
- one pipeline environment may not match another
In these cases, credentials are often more predictable unless the environment has a clearly stable authorized IP.
Environment-specific access rules
Access problems often come from environment drift rather than bad credentials.
Check access separately for:
- local development
- servers or VPS runtimes
- containers
- CI runners
- browser automation environments
Do not assume that a local success automatically proves that the same access model is correct everywhere else.
When to prefer credentials
Credentials are often easier when:
- the runtime moves across environments
- public IP stability is unclear
- you want the same connection method across local, server, and CI paths
- the client supports authenticated proxy URLs cleanly
When to prefer IP authorization
IP authorization is often easier when:
- the runtime comes from a known stable public IP
- you want to avoid passing credentials through the client runtime
- the server environment is controlled and long-lived
The right choice depends on how the system is actually deployed.
Recommended setup sequence
Use this sequence:
- determine whether the runtime will use credentials or IP authorization
- identify the real environment sending traffic
- build the connection format that matches the client
- validate the access path with cURL
- only then move into application or browser setup
This prevents simple access mismatches from becoming larger debugging sessions.
Key points
- authentication failures are usually caused by access-model mismatches, not by the proxy itself
- the two common access methods are username and password authentication and source IP authorization
- the correct access method must match the real runtime environment
- credentials and IP authorization use different connection patterns
- local success does not guarantee server, container, or CI access will work the same way
- validate the access path before debugging a larger workflow
Next step
Continue to Endpoints, Protocols, and Connection Strings for the canonical proxy format and protocol guide.
If you want to test the authentication path immediately, continue to First Request with cURL.