Парсеры на примере Adheart и Facebook Ads-Library 

Начнём с общей информации, каким образом анти-бот система может выявлять абузеров. Самую базу в виде прокси описывать не буду.

Adheart.

1. Так, как в данном сервисе требуется авторизация, то постоянная смена ip, используя резидентские прокси не подойдёт. Желательно, в данном случае, иметь одну подсеть и прокси, айпишники готорых через https://www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test не показывает красный скор. Желательно, чтобы он был зелёным.
2. Запросы желательно не выполнять через curl. Анти-бот система может легко проверить tls findgerprint и понять, что вы выполняете запросы не через браузер. Таким образом работает cloudflare, можете почитать здесь https://developers.cloudflare.com/bots/concepts/bot/. Можно воспользоваться публичным кодом, который можно найти вместе с документацией и ридми здесь: https://github.com/Skyuzii/SpoofingTlsFingerprint
3. Задержки, попытка эмуляции действий реального пользователя. Бесконечные запросы со слипом ровно в n секунд реально выглядят подозрительно, советую рандом в диапазоне. Также, лучше всего выключать запросы через определённого пользователя на какое-то время, от часа от 4х, опять же рандомно.
4. Перед начал парсинга, выполняю все имеющиеся запросы при логине. По моей практике ботов, которые не заходили на определённые страницы, на которые редиректит браузер быстро вычисляли. По этому после логина, бот делает GET запросы на:
   https://adheart.me/api/user/info,
   https://adheart.me/api/user/subscription,
   https://adheart.me/api/user/referral/balance
5. Далее, я включаю инструменты разработчика (f12) и наблюдаю запросы, которые выполняет браузер после того, как я начал поиск креативов. Обращаю внимание на запрос на https://adheart.me/s2.php после того, как я открываю следующую партию креативов. В body некий параметр s. Это тоже защита, гарантирующая, что этот запрос был выполнен с определённой страницы. Что передавать в s было найдено в исходном коде страницы teasers. Можно найти по поиску var secret.В ответ приходят новые куки.
6. Этого уже достаточно, чтобы не палиться ботом до тех пор, пока не будет найдена капча. Решается она достаточно просто, через сервисы типа 2captcha, rucaptcha или anti-captcha. Важно обратить внимание на то, что в запросе на выполнение капчи должен быть referer, то есть та страница с которой был совершён запрос. Параметры меняются каждую новую страницу и было бы странно, что полученная капча на 1000 страница была решена на 1й странице. Да, конечно, если подождать где-то 20 минут, капча пропадает, однако её тоже лучше решать, чтобы анти-бот система не посчитала вас ботом.

Примерный код всего, что я описал можно найти в github (https://github.com/1hermn/adheart-parser). Это не рабочий production вариант, его нужно допилить, либо написать свой на его основе. Бот проработал почти 2 недели и не был забанен, проработал бы больше, но у меня закончились деньги на сервисе решения капч.
Запуск:
npm i переименовать .env.example в .env, записать ваши данные, прокси и прочее

запускать: npm run start

Ads-library.

1. Изначальный подход такой же. Использование сайта и поиск запросов. Я использую для этого инструменты разработчика. Чаще всего, удобно использовать burp suit, но для его использование нужен опыт. Uri запроса вам уже известно, судя по php коду.
2. Я заметил - это обязательное наличие user agent, совпадающее с tls fingerprint. То есть опять же, запросы чисто через curl не подойдут, нужно использовать возможные подмены. Так как в данном сервисе не требуется авторизация, то лучше всего использовать на каджый запрос разный user agent, а также разный ip. То есть задача - эмулировать взаимодействие с площадкой разными пользователями.
3. Далее. Увидев кучу параметров в POST запросе я начал исключать параметры из body запроса, с которыми запрос подходит. Вычислил обязательные:
   __user:0 __a:1 dpr:1 lsd:lsd
   Где постоянные все, кроме lsd. Lsd представляет собой рандомные буквы, и передаётся как в body запроса, так и в Headers с X-Fb-Lsd
4. Прокси я решил использовать мобильные, так как с ними запросы проходили, а также ошибки рейтлимита я ловивил редко и достаточно было сменить ip адрес, чтобы продолжить работу. Скорость работы здесь ничем не ограничена, забанить могут только ip, которые сразу же меняется. По железу (tls) забанить не могут, так как я использую хромовские отпечатки и это значит, что они забанят всех пользователей хрома. Увеличение скорости работы - добавление новых прокси.
5. В коде, который выложен на github примерный рабочий код для парсера ads-library. Его опять-таки нужно дописать, но он работает. Однако, из него был вырезан часть кода, который занимается генерацией tls fingerprint и последующей его эмуляцией в запросе, так как данный код продавался за $2000 и я не хочу подставлять знакомого, выкладывая его в открытый доступ. Однако, если вам понравится данная работа - я могу внести правки и сбилдить проект под нужную вам операционную систему.

Проект сбилжен для linux и windows.
Перед тем, как запустить под linux нужно прописать chmod +x go_build_main_linux Далее для обоих операционных систем одинаково.

1. Отредактировать config.yaml в ./release. proxy_url и proxy_rotation_url брать с личного кабинета сайта (https://mobileproxy.space/), на нём тестирвал. Не дорого и работает прекрасно. Есть тест на 2 часа.
2. Запускать из папки release: ./go_build_main_linix -config ./config.yaml
3. В случае в windows - заменить на ./go_build_main.exe

В обоих скриптах сохранение результатов в папке results