Proxies for A-Parser: How to Connect Mobile Proxies

Proxies for A-Parser are the addresses A-Parser sends its requests through when it queries search engines and websites, so that thousands of threads do not leave from one IP. A-Parser itself is a universal scraper for SEO work: rankings, autocomplete suggestions, Google and Yandex results, data collection from sites. It runs thousands of threads at once, and without proxies search engines answer it with a CAPTCHA almost immediately. In 2026, mobile proxies are a common choice for this work: search engines block a carrier address far more reluctantly than a datacenter one.

---

What A-Parser is

A-Parser is a program with a web interface that runs on Windows, Linux and, through Docker, macOS. It is launched on a local computer or a remote server and controlled from a browser.

According to the developer, the program ships with more than 110 built-in parsers: search engines, suggestion services, SEO metrics, websites. Custom parsers are written in JavaScript, and sites that need a real browser are handled through Chrome controlled by puppeteer. The developer puts the number of simultaneous threads at 1,000–3,000, depending on the hardware and the task.

The license is bought once and does not expire. The developer’s site lists three editions:

• Lite — $179, Google and Yandex parsers, 3 months of updates;
• Pro — $299, the full parser set and custom JavaScript parsers, 6 months of updates;
• Enterprise — $479, API control and multi-core job processing.

Updates after the included period are paid separately, and an online demo is available before buying. Current terms are on the official A-Parser website.

Why A-Parser needs proxies

A-Parser’s main job is querying search engines, and they are the strictest about automated collection. Since 2025, Google renders results only for browsers that run JavaScript and serves them ten at a time, so the same amount of data takes more requests. Hundreds of requests per minute from one address quickly lead to a CAPTCHA, an HTTP 429 “Too Many Requests” or trimmed results. This is covered in detail in mobile proxies for scraping Google.

Proxies spread the requests across addresses. The more threads a task runs, the more addresses it needs so that each one carries only a few requests.

Tasks A-Parser runs with mobile proxies

• site rankings — daily rank checks for a keyword list in Google and Yandex;
• keyword research — search suggestions and related queries for a keyword set;
• SERP analysis — titles, descriptions and URLs of competitors in the top results;
• regional results — results for a given country from an address in that country;
• site data collection — catalogs, prices and data needed on a regular basis.

The stricter a source is about automated requests, the bigger the gain from mobile addresses: search engines and large platforms meet datacenter addresses with a CAPTCHA noticeably more often.

How proxies work in A-Parser: the proxy checker

Proxies are not added to a task directly. They go through a separate module, the proxy checker. It keeps loading proxies from its sources, tests them and maintains a list of live addresses, and tasks take proxies from that list.

Each checker’s sources live in the files/proxy/<checker name>/ folder:

• proxy.txt — the checker’s own proxy list;
• sites.txt — links to pages that publish proxy lists;
• regex.txt — rules for extracting addresses from third-party pages.

The first checker is called default. It is a template that cannot be edited or deleted, so a new checker is created for one’s own proxies.

---

How to connect LTESpace mobile proxies to A-Parser

1. Create a checker. Open the proxy checker menu, click “Add checker” and save the settings under a new name.
2. Choose the proxy type. Set HTTP or SOCKS5 in the proxy type field, matching the protocol chosen in the LTESpace dashboard. With both types selected, an address that fails the HTTP check is tested again as SOCKS.
3. Put the address in proxy.txt. The line goes in ip:port format, with the login and password in the checker’s authorization fields and proxy authorization enabled. If every proxy has its own credentials, the line is written as login:password@ip:port, and authorization is enabled as well.
4. Leave sites.txt empty. Otherwise random public proxies get mixed in with the paid addresses.
5. Think about checking. The checker re-tests the whole list every 30 seconds, and every test is a connection through the proxy. For a single paid address, checking can be switched off with the “No check proxies” option, which treats every loaded address as alive.
6. Attach the checker to a task. Under Settings → Thread settings, create a preset and select the checker in its proxy checkers field. Then pick that preset in the task editor.
7. Keep paid proxies separate. The “Exclude from All” option keeps the checker’s proxies out of the shared pool: only tasks that select the checker explicitly get them.

The protocols are compared in detail in HTTP, HTTPS and SOCKS5 proxies.

How many threads to run

A-Parser can handle thousands of threads, but the thread count has to match the proxies, not the program’s capacity.

• Multiport — one entry point, and each new connection gets its own IP from the carrier pool. The thread count is chosen at purchase, up to 50. An A-Parser task should run no more threads than were bought, otherwise extra connections are refused. The plan is available for Russian carriers; details are in multiport mobile proxies.
• Private channel — one address assigned to one client. Connections are unlimited, but every thread leaves from the same IP, so for search engines the thread count stays low and the address is changed through a link after a CAPTCHA.
• Shared channel — the address changes on its own by a timer; intervals of 2 and 5 minutes are described for Russian plans. Every request within an interval leaves from one IP, which sets the pace.

Traffic is unlimited on every plan, so only threads and addresses matter in the calculation. When every request needs a new address, see proxy rotation per request.

Public proxies in A-Parser

A-Parser can collect free proxies on its own: pages with proxy lists go into sites.txt, and the checker downloads and tests the addresses. For serious work this is a poor route. Public addresses have long been blacklisted by search engines, they die quickly, and the owner of such a server sees the traffic passing through it. The checker keeps finding and losing addresses, and a large share of requests ends in a CAPTCHA. More in where free proxies come from.

Common mistakes

• more threads than the proxies can carry — CAPTCHAs and refusals instead of data;
• authorization switched off — proxies with a login and password fail the check without proxy authorization enabled;
• the wrong proxy type — an HTTP address tested as SOCKS5, or the other way round, is marked dead;
• paid and public proxies in one pool — the task mixes good and bad addresses;
• re-testing every address every 30 seconds — extra connections for a paid channel.

General scraping rules — threads, pauses, response checks — are covered in proxies for web scraping.

Conclusion

Proxies for A-Parser are connected through the proxy checker: a dedicated checker, the HTTP or SOCKS5 type, the address in proxy.txt, authorization, and the checker attached to the task through thread settings. Mobile proxies give A-Parser addresses that search engines block reluctantly, and the thread count follows the channel rather than the program’s capacity. A channel for A-Parser tasks can be chosen in LTESpace pricing.