User-pass authentication proves access with credentials supplied to the proxy gateway; IP whitelist authentication permits traffic from approved source egress addresses.
User-pass fits changing client IPs and portable jobs; IP allowlisting fits stable egress under centralized network control.
A 407 response means the proxy did not accept authentication. A destination 401 is a different layer.
Never place live proxy credentials in source control, logs, screenshots, or a URL shared with another service.
Nstdata documents both Channel credentials and whitelist troubleshooting; verify the exact authentication options of your selected Channel before deployment.
What Is Proxy Authentication?
Proxy authentication is the gateway’s check that a client is allowed to use its network route. It happens before or during the client’s attempt to reach the destination. The common choices are a username and password sent to the gateway, or an allowlist of the client’s public egress IP addresses. Some products combine both. Destination-site login is separate: a proxy credential does not sign you into a target account.
Nstdata’s Proxy documentation shows a gateway username built from Channel ID and routing parameters, plus a Channel password. Its troubleshooting guide identifies wrong user-pass credentials and a mismatch between the whitelisted IP and the actual connection source as causes of HTTP 407. The selected Channel and product determine which options are available, so inspect the current dashboard rather than assuming all proxy products behave identically.
How Do User-Pass and IP Whitelisting Differ?
User-pass and IP allowlisting differ in what they trust. User-pass trusts a secret presented by the client; IP allowlisting trusts the network location from which the connection arrives.
Experience Nstproxy Proxy - Start Your Free Trial Today
Identity material
Username and password
Approved public egress IP
Best fit
Developers, cloud jobs with changing egress, per-Channel routing
Stable office or server egress with controlled networking
Main risk
Credential leak through code, logs, or copied URL
Unexpected egress change or shared NAT granting more clients access
Rotation effort
Rotate secret and update clients
Update allowed IPs when infrastructure changes
Debugging question
Did the client send the correct Channel credentials?
What public IP did the gateway actually see?
Neither is automatically “more secure” in every environment. An IP allowlist can be narrow when egress is dedicated and change controlled; it can be broad when many workloads share a NAT address. A password can be scoped and rotated, but embedding it in a URL requires careful handling. When both controls are supported, their combination can reduce accidental exposure, though it also adds operational failure modes.
What Do You Need Before Configuring Either Method?
You need an active proxy Channel, the generated Host and Port, the protocol your client will use, and either Channel credentials or the stable public egress IP to allowlist. Create a Channel and generate a Proxy URL through Channel details → Proxy Generation. Record the selected proxy product, country, session duration, and session ID if the username format uses them. A Channel is a usage and billing unit, so ensure the intended team owns the right Channel.
For IP allowlisting, determine the outbound public IP of the machine or NAT that will connect to Nstdata. A laptop behind a VPN or cloud NAT may have a different egress IP from its local interface address. For user-pass, put the secret in an approved secret store and distribute it only to the job that requires it. Do not publish a real proxy URL in a ticket or knowledge base.
Method 1: How Do You Use Username and Password?
User-pass is configured in the client’s proxy URL or proxy-authentication field using the generated Nstdata Channel credentials.
Step 1: Generate the proxy configuration
Open the Channel details page, enable Proxy Generation, choose the supported parameters, and copy the generated URL. Note Host, Port, Username, Password, and Protocol. Use the generated value rather than manually guessing the gateway or username structure.
Step 2: Configure the client
For a client that accepts a proxy URL, use the documented format below with placeholders. The username may include Channel, proxy type, country, session duration, and session ID; the exact generated value is authoritative.
Avoid shell history exposure in a real run by sourcing secrets from a protected runtime mechanism. The command is illustrative; no live Nstdata credential is available here.
Step 3: Verify and monitor
Inspect the IP-check response for expected exit location and record only redacted routing metadata. If the gateway returns 407, check the generated username, password, Channel status, and whether the credential was URL-encoded correctly in clients that embed it in a URL.
Method 2: How Do You Use an IP Whitelist?
IP whitelisting is configured on the provider side for a stable client egress address, when the selected Channel supports it.
Step 1: Confirm the actual egress IP
From the runtime that will call the proxy, determine its public outbound IP. Repeat the check after VPN, NAT, or cloud networking changes; do not allowlist a private 10.x or 192.168.x address.
Step 2: Add the IP through the approved Nstdata control
Use the current Channel or API whitelist control available to your account. Nstdata’s API interface documentation references a whitelist-IP API command, but does not make the exact current UI path universal for every proxy product. Record the change owner and review date. Avoid broad ranges unless they are required and reviewed.
Step 3: Test from the intended runtime
Connect through the gateway and check the exit IP. Then attempt from an unapproved test egress only if your organization’s security policy permits that negative test. A 407 from the intended runtime often means the gateway sees a different source IP than you assumed. Check NAT, VPN, and IPv4/IPv6 routing.
Handle authentication failures by identifying the failing layer before retrying. A gateway 407 is not a destination 401. Repeatedly retrying bad credentials only increases noise and may consume resources. Log the destination host, redacted Channel identifier, proxy product, error code, and time; never log the password or full URL.
A short diagnostic sequence is: confirm Channel active, confirm gateway Host and Port, inspect the generated Username and Password, confirm the selected auth mode, and check the actual egress IP if allowlisting applies. The Nstdata common-issues page also advises checking Channel traffic and expiry. For several applications sharing routes, Nstdata Proxy Manager can centralize operational visibility, but it does not replace credential governance.
Which Authentication Method Should You Choose?
Choose user-pass when jobs move across networks or need a portable, per-Channel credential. Choose an IP whitelist when egress is stable, dedicated, and easy to change control. Use both only where the selected Nstdata product supports it and the additional control is worth the operational overhead.
Start with one authorized connection test and document how to revoke access. If your actual need is page discovery and Markdown output rather than direct proxy configuration, Nstdata Crawl is a separate Web Crawling API for LLM-ready data with built-in proxy orchestration.
