Webshare with Proxy Bastion

Last checked 2026-08-14

Proxy Bastion does not sell IPs. It sits in front of proxies you already pay for and gives each person a revocable, metered link instead of your credentials. What they receive is a relay link and nothing else: no upstream host, no upstream password.

This release accepts http and https upstreams only. It does not support socks5 upstreams.

One thing worth separating before you start: Webshare publishes REST API documentation whose authentication is an Authorization header carrying a token. That token is for calling their management API, for example to list your proxies. It is not the credential a proxy connection uses. Registering the token where a proxy password belongs produces an authentication failure that looks like a wrong password, because it is one.

We have not published a Webshare gateway host or port here, because we could not confirm them from a public page on the date below. Take them from your own dashboard or proxy list and verify them with the command in step two. We are not affiliated with Webshare and we do not resell their traffic.

What is supported

We have not published Webshare's gateway host, port or credential format on this page, because we could not confirm them from their public documentation on the date above. Take those values from your own dashboard and verify them with the command in the setup steps below.

Setup

1. Separate the API token from the proxy credentials

The token in their API documentation is the credential for calling that management API. It is not the credential a proxy connection uses, so registering it where a proxy password belongs fails authentication. You want the username and password that belong to a proxy entry: if you pulled your proxy list through the API, those are fields inside the response, not the header you used to fetch it.

2. Verify the upstream before registering it

Substitute the host, port, username and password from the proxy entry itself. A 200 confirms you picked the right pair of credentials, which is the mistake this page exists to prevent.

curl -sS -o /dev/null -w 'http_code=%{http_code}\n' --max-time 15 --proxy 'http://USER:PASS@HOST:PORT' https://example.com

3. Distinguish a rejected credential from an unreachable proxy

Send the same request with no credentials at all. A 407 proves the proxy is reachable and demanding authentication, so the host and port are right and only the credentials are in question. A timeout or a refused connection means the host or port is wrong instead.

curl -sS -o /dev/null -w 'http_code=%{http_code}\n' --max-time 15 --proxy 'http://HOST:PORT' https://example.com

4. Register the upstream, pool it, then issue one link per recipient

Each link carries its own expiry and traffic ceiling, and the recipient never sees the host or the password. Two limits to know before you rely on either control: a revoked link can stay usable for up to about 60 more seconds while the edge cache expires, and the traffic ceiling is enforced from usage reported back in batches, so a link can overshoot it by up to about five minutes of traffic.

Sources

  • Webshare maintains a public integrations directory with an Anti-Detect Browsers and Multi-Accounting Tools category listing GoLogin, ixBrowser and AdsPower among others. The page states no gateway host, port or credential format. https://www.webshare.io/integrations (checked 2026-08-14)
  • The Webshare API documentation authenticates calls to that API with an Authorization header in the form Authorization: Token followed by the token, and states no proxy gateway host or port. https://apidocs.webshare.io/ (checked 2026-08-14)