То, что у вас только на 200‑300 аккаунтах начали падать «показатели», а на остальных всё в порядке, обычно говорит о том, что в пуле скрыт один‑единственный «плохой» шлюз. Я несколько раз запускал сотни мобильных профилей через один и тот же провайдер, и всё шло гладко до тех пор, пока не оказался в сети один IP, помеченный как подозрительный. После этого сразу же просыпались лимиты, но только на те аккаунты, которые использовали именно эту подсеть – остальные оставались «в живых». Самый быстрый чек — вывести список IP‑ов, привязанных к каждому аккаунту, и сравнить их. Если найдёте совпадения, замените этот диапазон на чистый, а ротацию настроите так, чтобы каждый запрос уходил через отдельный прокси. И да, «свежесть» прокси в этом случае важнее, чем количество: даже 100 новых IP могут работать лучше, чем 1000 «старых», которые уже попали в черный список мобильных сервисов.
Спорю про «один шлюз». У меня на том же провайдере пул чистый, но лимиты у оператора стоят на количестве сессий с одной базы — вот вам и просадка на 200-300 аккаунтах. Проверял: разнес по разным пулам одного и того же вендора — картина выровнялась. Так что ищите не плохой IP, а жесткий каппинг на стороне сотового, который не виден в логах прокси.
Не совсем так работает. У меня доступ к аккаунту пропадал именно из-за каппинга на сессии, как ты пишешь. Переразнёс по пулам — доступ восстановился, без всякой смены плохих IP. Тема рабочая.
Ну ты загнул про плохие IP, у меня было иначе: сессии просто капало на одном пуле, аккаунты отваливались пачкой, перекинул по разным — доступ вернулся без всякой чистки. Ключ тут в раскладе нагрузки, а не в грязных шлюзах. АртёмПик свои 200-300 акков пусть на лимиты оператора смотрит, у меня на тысяче такое же на одном базовом пуле вылезло, пока не развёл. Тема рабочая, но не панацея, надо под каждого провайдера тестить, а не по накатанной.
Слушай, ты про расклад нагрузки по пулам — по факту попал, но не весь смысл закрыл. У меня на тысяче с лишним акков тоже падало пачками, думал шлюзы грязные, ан нет, оператор просто по сессиям с одной базы лимиты душил. Перекинул часть на другой пул и ещё ttl сессий понизил, доступ вернулся тихо, без чисток. АртёмПик пусть не только лимиты смотрит, но и таймауты крутит, а то упрётся в кап и будет думать что IP плохой. Ключ не только в раскладе, а в том чтоб оператор не видел муравейник с одной точки.
Слушай, у меня тоже было: 1200 акков падало, думал, что шлюзы грязные, а на деле лимиты на сессиях с одной базы «задушили». Перекинул часть аккаунтов в другой пул, ttl сессий снизил до 25 минут, и через пару часов доступ уже плавно вернулся. Ещё заметил, что после снижения ttl и добавления в пул с меньшей нагрузкой API‑лимиты перестали «запирать», а кэш в браузере тоже помог очистить старые токены. Главное – не только распределить, но и подправить тайминги и тайм‑ауты.
Про снижение ttl забавно, но я бы не стал на него ставить как на панацею. У меня когда сессии начали отваливаться, дело было вообще не в лимитах базы, а в том, что прокси начали чекать геопозицию при каждом новом подключении. Как только перешел на более стабильные узлы, все сразу ожило. Если у тебя реально помогло уменьшение времени жизни сессии, то, может, у тебя просто база перегружена была запросами, а не лимиты по количеству сессий сработали.
Ну, про геопозицию — это ты, конечно, загнул, конечно, такое вряд ли причина массового вылета сессий. Если прокси начнут чекать локацию при каждом коннекте, то у тебя вообще весь трафик на релокацию встанет, а не просто акки полетят. У меня была похожая фигня с отвалами, но там всё оказалось банальнее: просто не хватало оперативы на сервере, когда скрипт начинал плодить слишком много параллельных запросов. Я в итоге просто поднял конфиг и добавил буфер, и всё сразу стабилизировалось. А вот про снижение ttl в 25 минут — это вообще верный способ убить систему, если сессий и так много, они же просто не успеют восстанавливаться. Я бы на такие радикальные меры не советовал, лучше сначала по логам прокси и нагрузке на железо пройтись, а то так и до полного капкана недалеко. Короче, дело чаще в ресурсах, чем в геопозиции прокси-серверов.