BotBrowser Launcher Proxy Setup: Verify Egress IP Step by Step

BotBrowser Launcher can start an authorized profile with a declared proxy, but it cannot repair an upstream provider route or prove that an IP belongs to a person. This article adds a repeatable egress-IP check to BotBrowser Launcher: Profiles, Proxies, and Setup, rather than repeating its launch overview.

BotBrowser Launcher supports launching an authorized profile with a configured proxy and recording the observed route; it does not guarantee provider uptime, anonymity, or a particular destination IP.

TL;DR

• Enter the proxy endpoint in Launcher, then record the effective protocol and a redacted endpoint label.
• Check the public IP from a page you control and compare it with a second independent echo service.
• Test DNS, WebRTC, timezone, and locale as separate observations; one passing check does not prove the others.
• Keep credentials out of screenshots and JSON artifacts. A failed egress check is a provider or configuration signal, not an identity verdict.

Contents

• What this adds beyond the launcher guide
• Run a proxy egress check
• Keep a small evidence artifact
• Triage a mismatch
• Conclusion

What this adds beyond the launcher guide

The launcher guide explains profiles, startup arguments, and the general proxy URL shape. The missing operational question is: what endpoint did the browser actually use? An egress check answers that question with a controlled request and a timestamp. It does not replace the protocol and DNS distinctions in Browser proxy configuration or the address-family checks in IPv4 and IPv6 proxy consistency.

Use a fresh temporary profile for the first run. Give the run an ID such as proxy-check-20261016-01, and write down the browser build, Launcher version, host OS, proxy protocol, and whether the profile was fresh. The profile label is evidence about setup, not a user identifier.

Run a proxy egress check

1. In Launcher, select the profile and enter a redacted endpoint such as socks5h://user:***@proxy.example.test:1080. Keep the real secret in the local secret store.
2. Start the browser and open an HTTPS echo page that you own. Capture the returned public IPv4 or IPv6 address, the request timestamp, and the response status.
3. Open a second echo endpoint in the same context. A mismatch means the two services may be seeing different routes, caches, or address families; it is not proof that either service is wrong.
4. Resolve a test hostname from the page or your controlled endpoint and record whether DNS was observed on the proxy side. Do not upload a full resolver log.
5. Compare the browser-reported timezone and locale with the expected proxy region. If they differ, record the difference before applying an override.

The useful result is a table, not a single green check:

Observation	Result to retain	What it can show
Echo A	status, address family, redacted timestamp	the address seen by one endpoint
Echo B	status, address family, redacted timestamp	whether the route is stable across endpoints
DNS	proxy-side, local, or unknown	the resolver boundary
WebRTC	no candidate, private candidate, or public candidate	the tested ICE exposure only
Locale	declared and observed value	a profile or override mismatch

Keep a small evidence artifact

Store a JSON record beside the test result. This example intentionally omits credentials, cookies, full URLs containing secrets, and raw resolver data:

{
  "runId": "proxy-check-20261016-01",
  "browser": "Chrome 155.0.8059.80",
  "hostOs": "macOS 15",
  "profile": "fresh-temporary",
  "protocol": "socks5h",
  "echoA": { "status": 200, "family": "ipv6", "addressRecorded": true },
  "echoB": { "status": 200, "family": "ipv6", "addressRecorded": true },
  "dns": "proxy-side",
  "webrtc": "no-public-candidate",
  "localeMatch": true,
  "testedOn": "2026-10-16"
}

The record proves only what the named fixture observed. It does not prove anonymity, provider reliability, or that every destination uses the same route. For protocol details, see Browser proxy configuration and the IPv4 and IPv6 proxy consistency guidance.

Triage a mismatch

If both echo pages show the host address, first check that Launcher saved the proxy scheme and port, then repeat with a fresh profile. If only one endpoint differs, compare its redirect chain and address-family preference before changing the browser. If DNS is local while the endpoint is socks5h, verify the provider's DNS support rather than assuming the scheme was ignored.

If WebRTC exposes a public candidate, record the exact browser and route used. A page-level setting can change ICE behavior, but it cannot rewrite a provider's upstream path. If locale or timezone differs, decide whether the proxy geolocation is authoritative for the test; do not silently edit several profile fields until the original mismatch is preserved.

Do not paste proxy credentials into issue reports, screenshots, or public articles. A provider timeout, an authentication failure, and a direct-connection fallback have different owners. The artifact should make that ownership visible without retaining sensitive traffic.

Conclusion

Launcher configuration becomes operationally useful when it ends with an observed egress result. Record two independent echo responses, the DNS boundary, the tested WebRTC outcome, and the profile and build that produced them. That evidence is more precise than a claim that a proxy is simply “working,” and it stays within BotBrowser's boundary: repeat an authorized journey, not control a provider or identify a person.

A practical runbook for support teams.

When a support team receives a report that a profile is using the wrong address, start by preserving the original run. Save the run ID, the date, the Launcher version, the browser build, and the profile lifecycle. Do not overwrite the profile or rotate the endpoint before taking the first observation. A changed configuration can be useful for a second experiment, but it cannot explain the first result.

Use a redacted endpoint label that still lets another operator recognize the route. For example, retain the scheme, a provider alias, and the port while replacing the username, password, host, and path with stable placeholders. Store the secret separately in the approved secret store. Screenshots should show the redacted label and the status result, never the address bar if it contains credentials.

Run the two echo checks close together. A public address can change because of load balancing or an address-family preference, so the timestamp matters. Keep the response status and the family (IPv4 or IPv6) in the record. If the two checks disagree, repeat neither check until you have copied the first pair into the evidence folder. The mismatch itself is a useful observation and may disappear after a retry.

Treat DNS as its own test. A proxy scheme that supports remote name resolution does not imply that every browser request uses it. Test a hostname that you control, compare the observed resolver boundary with the intended scheme, and record proxy-side, local, or unknown. Do not infer resolver behavior from the public address alone. An IPv6 egress address can coexist with local DNS, and a local resolver can return an address that is later fetched through the proxy.

WebRTC needs the same discipline. Record only the candidate category needed for the decision: no candidate, private candidate, or public candidate. The result is specific to the browser build, permissions, and test page. It is not a general statement about every WebRTC application. If a public candidate appears, preserve the original result, then investigate the page and browser settings in a separate run. Changing several settings at once hides which change affected the candidate list.

Timezone and locale are useful consistency signals, not proof of network location. Compare the browser observation with the expected region and state which value is authoritative for the test. A proxy provider may operate an exit in one region while the profile intentionally uses another locale. That is a product decision, not automatically a leak. Record the difference before applying an override so the support record remains auditable.

Interpreting common outcomes.

If both echo services report the expected address, DNS is proxy-side, and no public WebRTC candidate appears, the run supports the narrow claim that this profile observed that route under those test conditions. It does not support a claim about unrelated destinations, future runs, or the provider's internal network. Keep the conclusion as narrow as the evidence.

If both echo services report the host address, inspect the saved scheme, port, and profile selection first. A stale profile can make a correct Launcher edit appear ineffective. Re-run with a fresh temporary profile and a new run ID. If the fresh profile succeeds, compare the two records instead of deleting the original; the difference may reveal a saved setting or a profile-specific override.

If only one echo service differs, check redirects, address-family preference, and service-side caching. A disagreement is not enough to select a preferred service. Repeat the pair from the same context, and retain both responses. If the difference persists, report the destination names and timestamps to the provider without sharing credentials or unrelated browsing data.

If authentication fails, classify it separately from a timeout. Authentication points to credentials, an allow-list, or provider policy. A timeout points to reachability, capacity, or a route problem. A direct-connection fallback has a different owner again. The evidence artifact should include the category and status without including the secret or a full request URL.

Evidence retention and handoff.

Keep one small JSON record per run and a short human-readable note describing the decision. The note should answer four questions: which profile was selected, which endpoint label was used, what each check observed, and what remains unknown. Attach the browser and Launcher versions so another operator can reproduce the context. Avoid copying full network traces into a ticket when a redacted status table is sufficient.

When handing a case to a provider, send the run ID, timestamps, status codes, address families, and the redacted endpoint label. Ask the provider to confirm whether the observed route is expected. Do not ask BotBrowser to repair an upstream route that it does not own. BotBrowser can launch the authorized profile and expose the resulting observation; the provider owns its route, credentials, capacity, and destination policy.

This boundary makes the workflow repeatable. A later run can use the same checks, compare the same fields, and explain a changed result without claiming more than the browser actually observed.

For a scheduled check, keep the procedure deterministic. Pin the test page, the request method, and the timeout. Run the checks from the same profile state when comparing two providers, and change one variable at a time. A test that changes the browser build, profile settings, and proxy at once may produce a new result, but it cannot identify which input caused the change. A small runbook with stable inputs is more valuable than a large collection of screenshots.

Before starting, confirm that the profile is authorized for the intended workspace and that the operator is allowed to use the selected endpoint. A proxy test can expose operational data even when it contains no credentials. Limit access to the evidence folder, set a retention period, and remove fields that are not needed for the support decision. The goal is to preserve enough context for a repeat run without turning a diagnostic record into a browsing history.

The first request should establish the baseline. Open the controlled echo page, wait for the documented response, and save the status and address family. Then run the second echo request without changing tabs, permissions, or profile settings. If the page redirects, retain the final destination name and the redirect count. A redirect may explain why two services see different addresses, especially when one service prefers IPv4 and the other prefers IPv6.

Do not treat an HTTP 200 response as proof that the proxy is healthy. The response proves that one request completed. It says nothing about upload capacity, long-lived connections, certificate interception, or destinations that apply a different policy. For those questions, add a separate test and state its scope. Keep the egress article focused on the address, resolver boundary, and browser observations that it can actually support.

When a run fails, record the failure before retrying. A timeout, a refused connection, a certificate error, and an authentication error have different diagnostic paths. Include the phase in which the failure occurred: profile startup, proxy connection, DNS resolution, TLS negotiation, or page response. This simple label helps the next operator choose a useful next step without guessing from a generic red status.

Compare retries by run ID, not by file modification time. A clock change, a daylight-saving transition, or a copied artifact can make filesystem times misleading. The JSON testedOn field and the response timestamp should be the primary ordering fields. Keep the browser and Launcher versions beside them because an update can alter address-family preference, permission behavior, or the available proxy schemes.

If the provider supplies an allow-list, record the allow-list version or a redacted policy identifier. Do not paste the full customer list into the article or ticket. The support handoff needs enough information for the provider to find its own logs, not a copy of every authorized destination. Ask the provider to correlate the run ID and timestamp on its side, then compare its route description with the browser observation.

For a useful comparison, keep the request sequence identical across two runs. Use the same controlled endpoint, HTTP method, timeout, profile state, and address-family preference, then change only the proxy endpoint. Capture the response status even when the page displays an error, because a connection refusal and a successful response are different observations. A run that reaches the page but returns an unexpected address should be classified as a routing mismatch; a run that never completes should be classified as a reachability or authentication failure. This distinction keeps a dashboard from turning every red result into a generic proxy outage.

When the two runs use different profiles, do not compare only the final IP. Record whether the profile carried a stored proxy setting, a locale override, a WebRTC permission, or a cached service worker. These inputs can change what the test page observes without changing the provider route. Start with a fresh profile for a clean baseline, then repeat with the operational profile as a second experiment. Preserving both records makes it possible to explain a difference without claiming that Launcher or the provider caused it.

Teams often want a single “proxy working” field in a dashboard. A better dashboard keeps separate fields for echo A, echo B, DNS, WebRTC, locale, and error category. A composite status can be derived from those fields for triage, but the underlying observations remain available for review. This avoids turning an unknown DNS boundary into a false pass just because the public address looked correct.

The same artifact format works for a pre-release check and a support investigation. In a pre-release check, compare the expected route with the observed route and fail the release when the narrow acceptance rule is not met. In an investigation, preserve the unexpected observation and use a new run for each experiment. The format stays stable while the decision context changes.

Finally, document the limit in the ticket itself. State that BotBrowser Launcher started the authorized profile and recorded the browser-visible result, while the provider controls the upstream route and service policy. This wording prevents a later reader from mistaking a successful echo for a guarantee of anonymity or universal routing. Clear limits make the evidence safer to reuse and easier to audit.

Public sources

• Proxy configuration (MDN)
• WebRTC connectivity (W3C)
• DNS over HTTPS (RFC 8484)