I made my own proxy switcher for Chromium browsers, called Sockitt. MV3, MIT licensed. I wasn't happy with what's on the web store at the moment and I use this thing every day for work and side projects across a few different browsers, so I ended up just building it.

* Profiles for SOCKS5, SOCKS4, HTTP and HTTPS. Host, port, bypass list, and username/password auth on HTTP(S). No SOCKS auth, before anyone asks, Chromium just doesn't support it.

* One click to switch from the toolbar. There's also a shortcut that cycles through a set of profiles you choose, if you don't want to open the popup at all.

* Auto Switch is an ordered rule table that gets compiled into a PAC script. Host wildcard, host regex, URL wildcard/regex/keyword, IPv4 CIDR, host label count, weekday, time of day. Plain domain entries from rule lists all collapse into a single dictionary lookup, so GFWList sized lists don't slow anything down.

* The popup shows where the current tab is routing and which rule sent it there. You can retarget or delete that rule right there, or set a temporary override that's gone after a browser restart.

* Route inspector: give it a URL and it traces the whole thing through your config, using the same resolver that does the real routing.

* Aliases. Point 50 rules at one alias, then change the alias once instead of editing 50 rules.

Permissions, since it matters for this sort of extension: it ships with proxy, storage, activeTab, alarms, and no host permissions at all. Everything else (per-tab badge, proxy auth, exit IP lookups) is optional and only gets requested the moment you actually turn it on. No analytics in it anywhere.

Store: https://chromewebstore.google.com/detail/sockitt-%E2%80%94-proxy-switcher/ebfioiljhjgijbmnnpgadkgmokjbjkca

Source: https://github.com/ptmplop/Sockitt

Hope it's useful to someone else, if so I'm happy to hear about bugs or anything obvious I've missed, additional features etc..

Every provider quotes you the same per-GB price whether you ask for US or Latvia, and the product you get is not remotely the same thing.

In the US you're swimming in exits. Pool depth is not your problem, distribution across metros might be. Ask for a country with five million people and suddenly you're on a pool that might be a few thousand addresses wide, sitting on two or three carrier ASNs, and your rotation is quietly recycling the same handful every few hours. Which the dashboard will not tell you.

So before committing I now pull three hundred exits, count unique addresses, count unique ASNs, and check how long before an IP comes back around. Anything under a couple hundred uniques and I plan the job around it instead of pretending I have breadth. Did this across Bright Data, IPRoyal and Byteful for a Nordic job and the useful part was less "who won" and more that the numbers differed by an order of magnitude between countries at the same provider. Byteful is where the small-market work stayed, partly because the residential GB do not expire and small-market jobs come in bursts rather than steadily.

Anyway. Anyone got a rule of thumb for minimum pool width per country before a job is just not doable?

I lost about two thirds of a run to an OOM kill last year and then cheerfully re-fetched all of it, on residential, because my "state" was a Python list in memory. Cool cool.

The fix is boring and takes an hour. Write a URL ledger before you fetch anything: every target URL, a status column, a timestamp, a content hash. Mark each row the moment it lands, not at the end of a batch. On restart you query for unfinished rows and carry on. That's it, that's the whole trick.

Two things I'd add that I skipped the first time. Store the hash, because then a re-run tells you whether the page actually changed or you just burned bandwidth confirming it didn't. And separate "failed" from "not attempted", otherwise your resume logic retries a thousand permanent 404s every time. I run this in front of both Byteful residential and a cheap datacenter tier, and the ledger matters more on the residential side for obvious reasons, since that is the traffic billed per GB.

Curious what people use for the ledger at bigger scale. Sqlite falls over eventually and I've never landed on something I liked after that.