Proxies for Key Collector

Key Collector accepts proxy lists in its settings:

1. Copy the proxy list of addresses from your IPrazon dashboard. The main format is IP:PORT, or IP:PORT:LOGIN:PASS if you need it.
2. Open Key Collector settings, the network and proxy section.
3. Paste the proxy list and pick a protocol, either SOCKS5 or HTTP.
4. Enable a proxy check before collection if needed.
5. Start collection of frequencies or suggestions, queries go through the proxy pool.

The more proxy addresses are used, the more stable the collection and the fewer captchas appear.

It is easier to count from the number of search engine requests than from the number of phrases. Pulling frequencies, parsing suggestions and collecting results are different requests, and one phrase can produce several calls.

Then the rate limit comes in. Search engines react to the density of requests from a proxy address, so the ceiling is set by the safe rhythm per IP. Total speed comes from multiplying that rhythm by the number of proxy addresses in the proxy pool.

The practical order: find the rate at which checks do not appear, then divide the volume you need by that rate to get the number of addresses. Raising threads inside Key Collector only makes sense once the proxy pool can serve them.

A proxy connection refusal almost always comes down to four causes, and checking them in this order saves time. First: the wrong proxy type is selected, HTTP where SOCKS5 is needed or the other way round. Second: the port does not match the one issued.

The third cause sits in the format. If the proxy list is issued as IP:PORT with no login, access works by binding, and requests only go through from the proxy address you registered. Changing machine, network or outbound interface returns a refusal on a perfectly working list.

Fourth: a typo in the login or password, most often a trailing space picked up when copying the string. Check separately that Key Collector actually routes traffic through the proxy: a connection is confirmed by the source address on an IP test service.

Address switching is configured in two places and mixing them up causes trouble. The first is the proxy pool side: the proxy address changes on its own by schedule or per request, and Key Collector needs to do nothing. The second is the software side: you feed different strings from the proxy list to different tasks yourself.

The first option suits uniform work where no state is held between requests. The list is connected once and new proxy addresses arrive automatically, with no intervention needed.

The second option is what you need when collection runs in long queues and the rate to the search engine has to stay controlled. The address is then pinned explicitly and you decide when to change it: after a cycle finishes, after a number of processed items, or on a timer.

Running both modes on one task is usually harmful. If the proxy pool rotates on its own while the software cycles through the proxy list in parallel, behaviour becomes unpredictable and some requests leave from addresses you did not intend.

The base rule: load has to fall evenly across the proxy pool, otherwise some addresses burn out ahead of the rest. So it is better to assign projects to addresses deliberately than to let the software grab whichever comes first.

When tasks differ in weight, count by intensity. One heavy process can produce more requests than five light ones, and it makes sense to give it dedicated addresses so it does not crowd the others.

Keeping a small reserve of addresses that are not permanently occupied pays off. It comes in useful when part of the proxy pool starts meeting checks: you move the affected tasks onto fresh proxy addresses without stopping everything.

And finally, record which task ran from which address. Without that, when refusals appear there is no way to tell whether the cause is a specific address, the task settings or the platform itself.

The datacenter pool means stable fast addresses and automatic rotation: queries spread across 12,000 IPs, the rate per address is lower, and captchas appear less often.

Traffic is unlimited on all packages, important on large semantic projects with tens or hundreds of thousands of phrases. The pool covers 200+ countries if you collect regional frequencies.

SOCKS5 and HTTP are in the package, with login/password or IP authorization. Key Collector works with both without extra setup.