Two ways to connect
Webshare supports two connection modes for its proxies:
- Direct connection. You connect to each proxy's own IP address and port, taken from your proxy list.
- Backbone connection. You connect to one gateway hostname, and Webshare forwards your request through an IP it selects.
Both support HTTP and SOCKS5, and both can be authenticated with a username and password or by IP authorization. The difference is who decides which IP each request uses: your code, or Webshare.
Direct connection
In direct mode, the proxy list from the dashboard or API gives you entries like IP:PORT:USERNAME:PASSWORD. Your code picks an entry for each request.
Advantages:
- Full control. You decide rotation, stickiness and per-IP rate limits.
- Predictable IPs. Each entry is a known address, which is what you want for accounts or whitelisting.
- No gateway hop. Requests go straight to the proxy you chose.
Drawbacks:
- You write the rotation logic, and you need to reload the list when IPs are replaced.
- Large lists need management in code or config.
Direct mode suits scrapers with their own proxy middleware (for example Scrapy), antidetect browsers that assign one IP per profile, and any job where the IP must stay fixed.
Backbone connection
In backbone mode you use a single endpoint. Webshare's documentation shows the gateway at p.webshare.io on port 80, with behaviour controlled by the username:
- A rotate suffix gives a new IP on each request.
- A session number keeps the same IP for requests that share it.
Advantages:
- One proxy URL for everything, which is easy to drop into any tool.
- Rotation handled for you.
- Easy sessions without tracking IPs yourself.
Drawbacks:
- Less control over exactly which IP you get.
- An extra hop through the gateway.
Backbone mode is the normal way to use rotating residential proxies, and it's handy for datacenter lists in tools that only accept one proxy.
Which to choose
| Job | Mode | Why |
|---|---|---|
| Scraper with its own rotation | Direct | Control and per-IP limits |
| Quick scripts and no-code tools | Backbone | One URL, rotation built in |
| Rotating residential scraping | Backbone with rotate | Pool access through the gateway |
| Logins, carts, pagination | Backbone with session, or a fixed direct IP | IP stays the same for the flow |
| Antidetect profiles, accounts | Direct, dedicated IP | One known IP per identity |
| Partner IP whitelisting | Direct, dedicated IP | The partner must know your IP |
Example: same task, two modes
Direct, rotating through a downloaded list in Python:
import random, requests
proxies = [l.strip().split(":") for l in open("webshare_list.txt") if l.strip()]
ip, port, user, pw = random.choice(proxies)
url = f"http://{user}:{pw}@{ip}:{port}"
print(requests.get("https://httpbin.org/ip", proxies={"http": url, "https": url}, timeout=20).json())Backbone, letting Webshare rotate:
import requests
url = "http://USERNAME-rotate:PASSWORD@p.webshare.io:80"
print(requests.get("https://httpbin.org/ip", proxies={"http": url, "https": url}, timeout=20).json())Copy exact usernames, ports and suffix formats from your dashboard, since they depend on your plan. More examples in Webshare with Python.
Budget tip: You can test most of this guide for free: Webshare gives every new account 10 datacenter proxies and 1 GB of bandwidth a month without a credit card. Move to a paid plan once the pilot works. See our complete Webshare guide.
Common mistakes
- Mixing modes in one config. Using direct IPs with backbone usernames (or the other way round) causes authentication errors. See fixing common Webshare errors.
- Expecting rotation in direct mode. A direct IP never rotates on its own.
- Using rotate for logins. Sessions break when every request has a new IP.
Performance considerations
Both modes perform well for most jobs, but there are differences at scale:
- Direct mode spreads connections across many proxy IPs, which can increase total throughput and avoids any single gateway bottleneck.
- Backbone mode concentrates connections on the gateway. That's convenient, but your client must open new connections when you want new IPs; connection reuse can keep the same exit.
- Latency in either mode is dominated by the target's response time and geographic distance.
If you see throughput limits in backbone mode, check client connection pooling and your plan's thread limit before changing modes.
Switching modes without rewriting code
Keep proxy selection behind a single function in your code. Then switching from direct to backbone (or the reverse) is a change to that function only:
def get_proxy(session=None):
if MODE == "backbone":
user = f"{USER}-{session}" if session else f"{USER}-rotate"
url = f"http://{user}:{PASS}@p.webshare.io:80"
else:
ip, port, u, p = random.choice(PROXY_LIST)
url = f"http://{u}:{p}@{ip}:{port}"
return {"http": url, "https": url}Which mode for which product
| Product | Usual mode |
|---|---|
| Free plan and shared datacenter | Direct, or backbone for simple tools |
| Dedicated datacenter | Direct |
| Static residential | Direct |
| Rotating residential | Backbone |
Proxy tip: If your residential usage goes up and down, compare Geonode: its per-GB residential bandwidth doesn't expire, so you only pay for what you use. See Webshare vs Geonode.
Troubleshooting by mode
In direct mode, a failing request points at one IP; replace or exclude it. In backbone mode, failures are spread across IPs; look at the target, your rate and your credentials instead.
A real-world example
A developer builds a no-code workflow that fetches product pages and also runs a Scrapy project. The workflow tool only accepts a single proxy URL, so it uses the backbone gateway with the rotate option. The Scrapy project uses the direct list with a custom middleware that applies per-IP rate limits and skips IPs that a particular site has blocked. Both draw on the same Webshare plan, each using the mode that suits it.
If you're still shortlisting, compare this setup with the options in our best proxies guide, and use our cheap proxies guide to estimate what a sensible budget looks like.
Key takeaways
- Direct mode connects to each proxy's own IP and port; backbone mode connects to one gateway that chooses the exit IP.
- Direct suits scrapers with their own rotation, accounts and whitelisting.
- Backbone suits rotating residential traffic, quick scripts and tools that accept one proxy.
- Rotate and session options live in the backbone username.
- Keep proxy selection in one function so switching modes is a one-line change.
FAQ
Is the Webshare backbone the same as a backconnect proxy?
Yes, it works like a backconnect proxy: one entry point that forwards through many exit IPs.
Can I use backbone mode with datacenter proxies?
Yes. The gateway can rotate through your datacenter list, which is convenient for tools that accept only one proxy.
Which mode is faster?
Direct avoids the gateway hop, so it can be slightly faster. In practice target response time usually matters more.
Can I switch between backbone and direct at any time?
Yes. They're two ways of connecting to the same proxies; change your configuration and credentials accordingly.
Does backbone mode work with the free plan?
The free plan's proxies can be used in either mode; check the dashboard for the connection details offered.
Which mode should I use for Puppeteer?
Either. Use a session username on the backbone for residential, or a fixed direct IP for accounts.
Editorial note: Proxy providers change their pools, features and prices often, so treat any figures here as typical ranges at the time of writing and confirm current terms with the provider before you buy.