Proxies in Key Collector: why account modules need static addresses, not rotation

Where it is switched on

Настройки → Сеть, the «Использовать прокси-серверы» checkbox. The table below it has the columns «Адрес», «Порт», «Логин», «Пароль», and only the ticked rows are actually used — the most commonly missed detail when a list is pasted and the proxies “do not work”.

Account modules: static addresses only

The Yandex accounts settings page states it outright: alongside accounts you may specify static proxy servers, which will be used with those accounts. That is not a recommendation but a description of how the module works.

The reason is pinning. Once an account signs in, every subsequent request in the current program session — until a restart — goes through the same proxy, and no rotation happens. So a rotating plan is useless on account modules by design: the address is chosen once and held for the rest of the session.

Google.Ads: IPv6 and SOCKS are not supported

Here the limit is spelled out by the documentation verbatim: only reliably working HTTP/HTTPS IPv4 proxy servers may be specified; IPv6 and SOCKS are not supported. For us that means something simple: our IPv6 plan will not do for this module however cheap it is — it needs IPv4.

The browser handler loses SOCKS

The non-browser handler supports all kinds of proxy servers, SOCKS included. The browser handler does not support SOCKS at all. Switching handlers looks like a performance setting while quietly cutting away half the protocols: a string that worked yesterday stops being accepted today, though nothing in it changed.

Isolated cache multiplies windows

Isolated cache mode needs a separate browser window for every thread-by-address combination. The documentation gives its own example: with a hundred proxy servers and twenty threads it would need two thousand windows, and the mode will not run. In shared cache mode the number of windows equals the thread count. One more reason a long address list in Key Collector is not always better than a short one.

Threads: the ceiling is your accounts

In the Yandex.Direct settings you cannot specify more threads than the number of Yandex accounts configured and activated. The practical conclusion is more honest than any price list: a two-hundred-thread plan will not speed up collection if you have five accounts. How threads are counted across programs is covered in a separate article, linked below.

The vendor recommends checking proxies by hand

On its own network-errors page the vendor describes a seven-step check through an ordinary browser and explicitly discourages relying on automated proxy checkers. Inconvenient advice, but sound: a checker verifies that an address is reachable, not whether a particular source accepts it — and the latter is what breaks here.

Which gives a working rule. If a checker calls the address alive and the module still returns an error, reachability is not the problem: open the source in an ordinary browser through that same address and look at what it answers — a captcha, a refusal or a sign-in page. Those are three different causes with three different fixes, and an automated checker tells them apart from none.

What to buy for Key Collector

• For account modules — static IPv4, one address per account: rotation will not work there anyway, and Google.Ads will not take IPv6.
• For account-free collection — a rotating pool: this is where changing the address does work, and thread-based billing matches the program's model.
• Do not scale threads ahead of accounts: the ceiling is there, not in the proxy plan.