Plug a carrier IP into your automation stack

Selenium

Selenium drives Chrome, Firefox and other browsers through WebDriver, which makes it the default choice for scripted QA, uptime checks and structured data collection. Chromium ignores credentials passed in the proxy-server flag, so authenticated lines need either a tiny extension that answers the auth challenge or a local forwarder that injects credentials for you. Once that plumbing exists, every session you spawn exits through a real US carrier SIM.

1. Export PROXY_HOST, PROXY_PORT, PROXY_USER and PROXY_PASS from the values on your NeonProxies dashboard.
2. Build the browser options in your test harness and set the proxy server to host and port.
3. Attach an auth helper: a generated extension for Chrome, or Firefox preferences plus a handler for the login prompt.
4. Add a smoke test that loads an IP echo endpoint and asserts the ASN belongs to AT&T, T-Mobile or Verizon.
5. Hit the rotation URL from your teardown or setup hook when the next batch should use a fresh address.

• Rotation is unlimited with no cooldown, but a new IP mid-flow breaks cookie continuity; rotate at job boundaries.
• Pin the SOCKS5 port when a target relies on WebRTC or other UDP traffic, since UDP over SOCKS5 is supported.

Kameleo

Kameleo exposes a local REST API and client libraries, and its profiles can be driven with Selenium, Puppeteer or Playwright as if they were stock Chrome. That makes it a good host for scheduled account tasks, geo-specific regression tests and ad verification. Supplying the proxy at profile creation keeps fingerprint and network defined in one call.

1. Grab the line's host, port and credentials, and decide on http or socks5 as the proxy type.
2. Either fill in the proxy block when you create a profile in the Kameleo app, or send it in the create-profile request to the local API.
3. Start the profile and connect your automation client to the endpoint Kameleo returns.
4. Navigate to an IP lookup as step one and fail the run if the country is not US.

• Store the proxy per profile, not per script, so a profile reopened next week still leaves from the same line.
• Let Kameleo derive timezone and geolocation from the IP instead of hardcoding them in your profile template.

Full Kameleo setup guide →

Nstbrowser

Nstbrowser ships a desktop client, an API and hooks for Puppeteer, Playwright and Selenium, plus cloud profile storage so workers on different machines can run the same profile. It is aimed at builders who want fingerprint management without writing it themselves. A NeonProxies line gives those profiles a sticky carrier IP you can flip programmatically.

1. Copy the connection string pieces from the dashboard: protocol, host, port, user, pass.
2. Create a profile through the client or the API and set its proxy to those values.
3. Use the client's proxy test, or a quick request through the API, to confirm the line answers.
4. Launch the profile from your worker and connect Puppeteer or Playwright to its debugging endpoint.
5. Rotate through the NeonProxies API between tasks when you want a different address.

• When several workers share cloud profiles, give each profile its own line so two machines never fight over one exit.
• Log the IP at task start; it makes post-mortems far easier than guessing which address a failed run used.

Full Nstbrowser setup guide →

AdsPower

AdsPower bundles a no-code automation builder and a local API with its profile manager, so it attracts people who want scheduled flows without maintaining a full codebase. Its profiles accept HTTP and SOCKS5 proxies with authentication, which covers our lines directly.

1. In the AdsPower profile form, jump to the proxy settings.
2. Choose the protocol and paste host, port, username and password from your dashboard.
3. Hit the connection check and wait for a US carrier result.
4. Save, then attach the profile to an automation task and dry-run it once.

• If your flows open the same profile repeatedly, keep the line sticky and call rotation from a task step only when the flow is done.

BitBrowser

BitBrowser manages profiles as windows and offers an API for bulk create, open and close operations, which is handy when an orchestrator spins windows up and down on demand. Mobile IPs suit it when those windows represent real users of mobile-heavy platforms.

1. Call the create-window endpoint, or use the GUI form, and include a proxy object with type, host, port, user and password.
2. Open the window and let BitBrowser run its proxy detection.
3. Confirm the reported location matches the metro you ordered.
4. Keep a mapping table of window IDs to line IDs in your orchestrator.

• Validate the import format with one row before bulk-loading a list, because a swapped column breaks every window at once.

Incogniton

Incogniton offers Selenium and Puppeteer integration alongside a friendly GUI, a comfortable middle ground for teams moving from manual work to scripts. Proxies are stored per profile and carried into automated launches.

1. Edit the profile and open its proxy tab.
2. Enter the line with protocol, host, port and credentials.
3. Run the built-in check to see the carrier and city.
4. Launch the profile through the integration and confirm your script sees the same IP.

• Use the dashboard's per-request rotation mode only for stateless fetches; logged-in profiles want a sticky IP.

GoLogin

GoLogin keeps profiles in the cloud and also offers an API, so a profile can be launched on a build server as easily as on a laptop. A dedicated line means that wherever the job runs, the target sees one steady carrier address.

1. Open profile settings in GoLogin, or prepare the proxy fields for its API.
2. Set the type to HTTP or SOCKS5 and add host, port, username and password.
3. Test the connection and confirm the country and carrier.
4. Save and launch from wherever the job runs.

• Keep credentials in a secrets store and template them into API calls instead of committing them to a repo.

Multilogin

Multilogin supports Chromium and Firefox cores and exposes automation through a local interface compatible with Selenium, Puppeteer and Playwright. Bigger teams use it when many operators and bots must share a controlled pool of profiles.

1. Create or edit a profile and open its proxy options.
2. Enter HTTP or SOCKS5 details for the line.
3. Run the proxy check and confirm a successful connection.
4. Start the profile via the automation interface and attach your driver.

• Name profiles after the line and metro, for example chi-tmo-03, so logs and dashboards line up without a lookup table.

MostLogin

MostLogin is a recent entrant with profile management and team features. For automation builders it is mostly a manual control surface for checking what a bot will see, and a NeonProxies line plugs in through its standard proxy fields.

1. Create a profile and locate its proxy configuration.
2. Enter the protocol, host, port, username and password.
3. Test from the settings panel, then save.
4. Open the profile and compare what you see with your bot's output for the same target.

• Point the manual profile and the bot at the same line when reproducing a bug, so the network is not another variable.

GeeLark

GeeLark hosts Android cloud phones with per-profile proxy settings and its own automation features for app workflows. It covers mobile-app testing and app-based account tasks that a desktop browser cannot reach. Routing each cloud phone through a NeonProxies line replaces the data-center exit with a US carrier IP.

1. Open the cloud phone profile and find where its network proxy is set.
2. Choose SOCKS5 or HTTP and supply the line's four values.
3. Run the proxy check, then boot the phone.
4. Verify from an in-phone browser that apps will see the carrier IP.

• Match locale, timezone and SIM-region settings on the cloud phone to the line before automating any app flows.