Provider configuration

A provider is an upstream proxy-supply integration. It combines an adapter, credentials, protocol ports, one or more regional addresses, a location dictionary, and the capabilities routing can use.

Prepare the provider account

Before opening the wizard, collect:

a non-production or spend-limited account;
the provider adapter name supported by the panel;
username/password or token and the rotation procedure;
HTTP and SOCKS5 ports;
every endpoint hostname, its deployment region, and whether it is general, city, or ASN specific;
the matching location dictionary;
the supported geographies, session behavior, concurrency policy, and UDP capability;
supplier status and escalation contacts.

The adapter list is authoritative. Do not import one provider under another adapter because their login syntax looks similar.

Providers page with realistic provider brands and current table columns — The provider list connects each upstream record to packages, endpoints, and its location dictionary.
Use the provider controls to search, create, or start the guided import.
The table shows the current contract: provider, packages, addresses, and location dictionary.

Import a provider

The guided import creates the provider and its endpoint records together. Nothing is written until the final review action.

Provider import wizard supported adapter selection — Step 1 selects the code path that builds the upstream credential grammar.
Choose the exact supported provider adapter, such as ThorData, NodeMaven, or NetNut.
Credentials entered later are protected session inputs and must not appear in screenshots or tickets.

Provider import identity and location dictionary selection — Step 2 gives operators a clear name and binds the correct translation dictionary.
Use an operator-facing identity that distinguishes account or environment when needed.
Attach the dictionary whose vocabulary matches this provider account and adapter.

Provider credentials and protocol port configuration — Step 3 configures upstream authentication and the provider-level protocol ports.
Enter the upstream credentials and only ports confirmed for this account.
Review the endpoint summary before moving to address-level configuration.

Set a protocol port to the provider’s real value. A SOCKS5 port does not by itself prove UDP support; enable and sell UDP only after an end-to-end test.

Provider import regional endpoint address configuration — Step 4 records where the gateway dials and what specialized routing role each address has.
For each endpoint, set the hostname, deployment region, and optional city or ASN tag.
Add another address when regions or targeting modes use different upstream endpoints.

Use separate address rows for materially different endpoints. The region describes where that upstream entry point belongs in your deployment; tags let the integration select specialized address sets such as city or asn.

Provider import final review — The final review is the write boundary for the provider and all listed addresses.
Confirm adapter, identity, dictionary, ports, and endpoint count as one coherent integration.
Import only after every summary value matches the intended supplier account.

Manage provider addresses

Addresses can also be reviewed and created independently under Infrastructure → Addresses. This is useful when a provider adds a region, separates city/ASN traffic, or changes a port range.

Provider Addresses table with current endpoint, provider, region, ports, and tag columns — Address rows make endpoint ownership and protocol exposure visible without revealing credentials.
Search or create addresses from the resource controls.
Verify address, provider, region, HTTP ports, SOCKS5 ports, and routing tag together.

Manual provider address creation with endpoint and protocol ranges — Manual creation supports one hostname with deployment region, routing tag, and optional protocol ranges.
Enter the exact upstream endpoint and the deployment region from which it should be used.
Add HTTP and SOCKS5 ranges only when the supplier exposes address-specific ranges.

Provider-level ports are the normal default. Address-level ranges are for integrations whose endpoints expose a span of usable ports. Do not invent a range from a single documented port.

Validate before assigning package traffic

Send a direct HTTP request through the intended endpoint and confirm the exit IP.
Repeat with SOCKS5 and proxy-side DNS if that product will advertise it.
Test a country, then the narrowest region, city, or ASN you plan to expose.
Test sticky behavior for the duration you plan to sell.
Confirm bytes and requests appear under the expected provider.
Observe health long enough to establish a baseline.
Add the provider to a private test package at controlled weight before any public rollout.

Healthy

Eligible only when protocol, location, package, pool, and customer policy also match.

Degraded

Reduce exposure, inspect endpoint evidence, and preserve alternate tested supply.

Unavailable

New selection can exclude the target; an in-flight customer operation is not automatically replayed.

Edit, rotate, or retire supply

Before changing credentials, ports, dictionary, endpoints, or protocol flags, identify every package and pool that can select the provider. Record the old value and update one responsibility at a time.

For a credential rotation, update a low-risk environment or endpoint first, run live synthetic traffic, then roll out the remaining targets. To retire a provider, move package and pool allocation to tested alternatives, wait for new traffic to leave it, inspect closed analytics and active sessions, and only then disable it.

Continue with pools and routing to turn validated supply into reusable selection policy.