Quick start — connect and verify

Your portal shows the connection formats and controls available for the purchased endpoint. Setup time depends on the client, network and selected plan.

1. 1Open the endpoint in your portal and copy the credential format your client accepts.
2. 2Enter Host, Port, Username and Password in the client's proxy settings. Choose HTTP/HTTPS or SOCKS5 according to that client's documentation.
3. 3Send a test request through the configured client. Confirm that the observed public IP is not your original address, then record the reported ASN and country.

# Credential format:
host:port:user:pass

# HTTP proxy URL:
http://user:pass@host:port

# Observe the public IP used by this request:
curl -x http://user:pass@host:port https://api.ipify.org

A successful IP check proves that this request used the endpoint. It does not prove that every application, protocol or DNS lookup on the device follows the same route.

Choosing a protocol — HTTP/HTTPS vs SOCKS5(h)

The endpoint supports HTTP/HTTPS proxying and SOCKS5. The right choice depends on what the client implements and which traffic it sends through the proxy.

HTTP / HTTPS

Use this when the application explicitly supports an HTTP proxy. HTTPS destinations normally use an HTTP CONNECT tunnel; the proxy does not decrypt the destination's TLS connection.

SOCKS5 / SOCKS5h

SOCKS5 carries TCP connections for compatible clients. Some clients use the socks5h label to request remote hostname resolution, but the exact behavior belongs to the client implementation and must be tested.

• socks5 commonly means the client resolves the hostname locally before opening the proxied connection.
• socks5h commonly asks the client to send the hostname through SOCKS for remote resolution.
• A label alone is not proof of DNS behavior; verify with the same application and operating system used in production.

# HTTP/HTTPS via curl
curl -x http://user:pass@host:port https://api.ipify.org

# SOCKS5h via curl; curl interprets the 'h' as remote hostname resolution
curl -x socks5h://user:pass@host:port https://api.ipify.org

Authentication — credentials and supported allow-lists

Username and password authentication is the portable default. Source-IP allow-list editing is available only on supported lines; the portal shows it when the endpoint supports that capability.

Username / password

Enter the endpoint credentials in a trusted client. Store them as secrets, avoid committing them to a repository, and rotate them through the supported portal workflow if exposure is suspected.

Source-IP allow-list

On supported European lines, a fixed source address can be authorized in the portal. This is useful for a server or office with a stable public IP. It is a poor fit for a changing home or mobile source address.

• Confirm that the source address is public and stable before adding it.
• Test from the exact server or office connection that will originate traffic.
• Remove an old entry when the authorized source changes.

Testing — observe route, location and client behavior

Test from the same client and network used for the real workload. Different lookup services use different databases, so disagreements are observations to investigate rather than proof that one database is universally correct.

Useful observations

• Public IP — confirm that a request through the configured client does not show your original public address.
• ASN and organization — check whether a current lookup identifies the exit network as the expected mobile carrier.
• Country — compare multiple geolocation databases and distinguish country-level confidence from city-level estimates.
• DNS — determine where the actual client resolves hostnames; results vary by browser, operating system, proxy mode and encrypted-DNS settings.
• WebRTC and UDP — test the actual browser or app. A TCP proxy does not automatically cover every UDP path, while browser proxy policies can restrict WebRTC to proxied TCP candidates.
• Latency, download and upload — measure at the hours and from the location where the workload runs.

Third-party fraud, anonymity and proxy labels are private database opinions. They can help compare observations, but they do not predict or guarantee how a destination will treat a request or account.

# Scriptable route observation
curl -x http://user:pass@host:port https://ipinfo.io/json

# Record the returned IP, ASN/organization, country, timestamp,
# client, protocol and endpoint used.

If a result is unexpected, retest with a second lookup service and a minimal client such as curl. Change one setting at a time. Do not request rotation merely to chase a preferred third-party score.

Proxy-aware browser integration

Many browsers and browser-profile tools accept custom HTTP or SOCKS proxy credentials. Their fingerprint, cookie, DNS, WebRTC and geolocation behavior is controlled by that client, not by the proxy endpoint.

Generic setup

1. 1Create or open the approved browser profile used for the workflow.
2. 2Open its proxy settings and choose a protocol the tool explicitly supports.
3. 3Enter Host, Port, Username and Password from the portal.
4. 4Run the tool's connection test, then independently observe the public IP inside the launched browser.
5. 5Test DNS and WebRTC behavior if those paths matter to the workload.
6. 6Record the endpoint and country assigned to the business workflow.

Operational boundary

An assigned endpoint separates your own credentials and configured route. It does not guarantee a unique carrier public IP, persistent public IP, browser fingerprint, account acceptance or platform outcome.

Approved platform workflow checks

For authenticated platform work, use official team roles and APIs where available. The following checks improve reproducibility without pretending a network setting can control an account decision.

• Confirm account ownership, delegated permission and the platform rules that apply.
• Document which client, country and assigned endpoint the workflow requires.
• Test one approved workflow before moving a larger team or time-sensitive process.
• Avoid requesting rotation during an authenticated session; carrier-controlled changes can still occur.
• Treat a challenge, rate limit or restriction as a reason to stop and review, not something to route around.
• Keep a rollback path to the last verified client and endpoint configuration.

VPN setup — WireGuard / OpenVPN

Eligible VPN plans include a configuration for a supported client. A VPN can route more device traffic than an application-level proxy, but split tunneling, local-network exclusions, client settings and operating-system behavior can change what actually enters the tunnel.

WireGuard

1. 1Install a trusted WireGuard client for the operating system.
2. 2Import the supplied configuration or approved QR code.
3. 3Activate the tunnel and confirm a recent handshake.
4. 4Observe the public route in each application that matters to the workload.

OpenVPN

1. 1Install a trusted OpenVPN client.
2. 2Import the supplied profile and credentials if requested.
3. 3Connect and review the client log for errors.
4. 4Observe the route in each relevant application before relying on it.

Transport limits

WireGuard uses UDP. OpenVPN profiles can use UDP or TCP according to their configuration. TCP port 443 is often permitted on restrictive networks, but plain OpenVPN remains distinguishable from ordinary HTTPS to capable inspection. Test the actual network and profile.

A UDP-capable tunnel can carry compatible UDP traffic, including QUIC, when the client, route and destination allow it. That is a capability to verify, not a universal speed promise.

Scripted setup and rotation controls

Scripts use the same endpoint credentials as other clients. Eligible plans also show a private TMPX rotation link for on-demand change requests; the approved Bearer management API is a separate integration facility. Keep both credentials secret and use them only within authorized workflows.

Rotation in scripts

YUGE, FULL-ACCESS and VPN include a private TMPX rotation link, and a 24-hour product test has the controls of the selected product. Call it between stateless tasks, keep requests at least 5 minutes apart, follow the service response and observe the current exit IP. A successful request is not a promise of a particular, new or persistent address. Treat the link as a secret, the same as your password.

# Request on-demand rotation on an eligible plan.
curl -s "https://<your-rotation-link-from-portal>"

# After the service reports completion, observe the current route.
curl -x http://user:pass@host:port https://ipinfo.io/json

Python (requests)

import requests

proxies = {
    "http": "http://user:pass@host:port",
    "https": "http://user:pass@host:port",
}

response = requests.get(
    "https://ipinfo.io/json", proxies=proxies, timeout=30
)
response.raise_for_status()
print(response.json())

Operational best practices

• Protect endpoint credentials and rotation links as secrets.
• Use a separate assigned endpoint where your own client or business boundaries require it.
• Verify the route in the real client instead of trusting a label or screenshot.
• Record country, ASN, timestamp, protocol and observed exit IP for reproducible troubleshooting.
• Use current destination documentation and stop on access restrictions or security challenges.
• Request rotation only between eligible stateless tasks; never assume the carrier public IP will persist.
• Measure latency, download and upload at the hours the workload actually runs.
• Contact support when the endpoint itself is unreachable or the observed network does not match the order.