Proxies: formats and gateways

What we accept, how many you need, and why residential or ISP exits in GB.

Every monitor makes its requests through proxies that you supply. That is deliberate: your monitors get their own reputation instead of sharing ours with strangers, and you can pick a provider that suits the site you are watching. You do not need many. A handful of good exits beats a thousand shared ones.

Step 1: the formats we accept

Paste one proxy per line: at the Which proxies? step of the New monitor page, or in the Add a list of exits panel on Settings → Proxies. All of these work, and you can mix them in one list:

host:port:username:password
username:password@host:port
http://username:password@host:port
host:port

Where a screenshot would go: the Proxies page, a Name field reading "ISP pool" above an eight-row text area, with the Add list button under it.

Everything is normalised to http://user:pass@host:port when you save, blank lines and # comments are ignored, and duplicate lines are dropped — pasting the same list twice is the commonest upload mistake and it would otherwise double your apparent exit count for nothing.

A line with no credentials is treated as an open or IP-authorised proxy. If your provider authorises by IP rather than by password, allow-list our servers with them before you save the list (ask us for the address), or every request comes back 407.

Lines we cannot read are reported, not silently dropped. The page tells you how many were rejected and shows the first few, so you can go back to your provider with specifics rather than wondering why a monitor is quiet.

Step 2, alternative: a rotating gateway

Some providers do not give you a list at all. They give you one hostname and rotate the exit for you. The right-hand panel, Or a rotating gateway, takes those, field by field:

Name: Anything you will recognise later, for example Residential GB. It is the label you pick from when creating a monitor.
Host: Hostname and port together, as the provider gives them: gateway.example.net:8000. Use the HTTP port, not the SOCKS one.
Username: The gateway username. Providers of this kind encode the options into it, for example user-country-gb-session-a1b2c3. Paste exactly what they gave you; where the username carries a session token, a fresh one is substituted per session so a run does not sit on one exit.
Password: The gateway password. It is encrypted when stored and never rendered back into the page.
Country: An ISO two-letter code. For the UK that is GB. UK is not a country code and gateways answer it with a 400. Leave it blank and we use GB.
Session minutes: How long the gateway keeps one exit before rotating it. 30 is a reasonable default: long enough for a cleared session to be worth having, short enough that one blocked exit is not your whole afternoon.

Where a screenshot would go: the gateway panel with those six fields filled in, the password masked, and Country reading GB.

How many do I need?

Fewer than people expect. A Ticketmaster UK monitor reads one event about twenty times a minute through one cleared session; it only needs another exit when the site refuses the one it has. A football club monitor is lighter still: each sign-in reads about five times a minute, and each holds an exit of its own.

One or two events: ten good exits is comfortable.
Five to ten events: twenty-five to fifty.
A busy on-sale: more helps, but only if they are on different networks.

Exit diversity matters far more than line count. A long list whose addresses sit in only a handful of networks behaves like a handful of proxies, however many lines it has. Judge a list by how many separate networks it covers, not by how long the file is.

Which type to buy

ISP / static residential — the usual choice. Fast, stable, and the address does not change under you mid-poll.
Rotating residential — good for spreading load across many networks, which is exactly what blocks punish. Fine for monitoring.
Datacentre — cheapest, and blocked most often on ticketing sites. Worth trying, not worth relying on.
Mobile — highest trust, highest price, usually overkill for monitoring.

Why it has to be residential or ISP: ticketing sites keep lists of the address ranges that belong to hosting companies, and answer them with a refusal before any page is served. In our testing, a plain request to ticketmaster.co.uk from a datacentre address was refused outright, with nothing behind it to read. A residential or ISP address is one an ordinary customer could plausibly have, so it gets an ordinary answer.

Country: GB

Match the country of the site. A UK event polled from a UK address raises the fewest questions, and some UK ticketing pages behave differently or refuse outright from abroad. On a list, buy GB exits; on a gateway, set Country to GB.

Checking a list

Two checks, and it matters which is which.

When you save a list, the page tells you how many lines were accepted and which were not. That is a check of the text you pasted, not of the proxies.

The Test button (on Settings → Proxies, and on the proxies step of the New monitor page once a list is saved) fetches one tiny page (api.ipify.org, which answers with the address it saw) through three of the config’s exits, eight seconds each. On a list it picks three lines at random; on a gateway it opens three fresh sessions, because a gateway has no fixed exits to pick from. The result sits under the config’s name until you test again:

3/3 exits reachable (86.x, 90.x, 2.x) — the credential is right and all three answered, from three different addresses. Three different first octets is the reassuring part: one repeated address means the provider is not rotating.
proxy 407: bad username/password — the credential is wrong, or the provider expects IP authorisation and has not been told about our servers.
timed out — nothing answered within eight seconds. Usually the wrong port: providers often give an HTTP port and a SOCKS port, and we want the HTTP one.
connection refused — something is listening and said no. Wrong port again, or the subscription has lapsed.
1/3 exits reachable … the rest timed out — a partly dead list. It will run, slowly and with more blocks; prune it.

What the Test button does not prove. It only asks whether our servers can reach the internet through that credential. An exit that answers here can still be refused by a ticketing site, because the refusal is about whose address it is, not about whether it works. A green 3/3 and a monitor full of blocks is a perfectly consistent pair of facts, and it means the exits are reachable but not residential enough. Testing is also rate limited to three goes a minute.

So the real test is still the first monitor: start it and watch the counters on its card for a minute.

Polls climbing, blocks flat — the exits are fine.
Blocks climbing, session age resetting every few seconds — the exits are being refused. Each of those costs a credit, so fix it before leaving it running.

Blocked exits, in detail.

Common problems

Everything returns 407

Wrong username or password, or the provider expects IP authorisation and has not been told about our servers.

Everything times out

Wrong port. Providers often give an HTTP port and a SOCKS port; we want the HTTP one.

A 400 mentioning the country

The country field wants an ISO code. GB, not UK.

It worked yesterday and not today

Rotating plans retire exits. If most of the list is healthy and a few lines are not, the list is fine and those exits are gone.

I cannot delete a proxy list

A list still used by a monitor cannot be deleted — a monitor with no proxy would read the site from our own address, which is a block and a wasted credit. Point those monitors at another list first.

We never show a proxy password back to you, and any password that appears in a log line is replaced before the line is written.

← Create a Discord webhook Club sign-ins →

Something here wrong or missing? Tell us, and we will fix the page rather than just answer the message.