Скрипт падает с обрывом соединения раз в сто запросов через датацентровый IP и раз в десять — через резидентный или мобильный канал. Это не брак прокси, а свойство среды: обрыв на бытовом или сотовом канале — нормальное явление, которое клиент обязан пережить сам, без вмешательства человека. Разберём, откуда берётся разница в частоте обрывов, какие таймауты и паузы между повторами задавать, какие ошибки стоит повторять, а какие нет, и как ретраи сказываются на расходе трафика.

Почему резидентный и мобильный канал рвётся чаще серверного

Датацентровый IP сидит на выделенном канале провайдера с резервированием и почти нулевым джиттером — обрыв там редкость и обычно системная авария. Резидентный адрес — это реальное домашнее подключение: роутер перезагружается, провайдер переключает абонента между узлами, DHCP-аренда обновляется, устройство на минуту уходит в сон. Мобильный канал добавляет к этому хендоверы между базовыми станциями, переключение сетей и временную потерю сигнала — всё это происходит на живом устройстве живого абонента, а не на выделенном для вас порту. NAT сотового оператора, за счёт которого один адрес разделяют сотни абонентов, — та же причина, по которой такой IP почти невозможно забанить: подробнее в статье почему мобильные прокси сложно забанить. Обратная сторона устойчивости к бану — сам канал физически менее стабилен, чем серверный.

Разумные значения таймаутов подключения и чтения

Таймаут подключения (connect timeout) и таймаут чтения (read timeout) — разные вещи, и путать их нельзя. Connect timeout ограничивает время на установление сессии; для датацентрового канала достаточно 3–5 секунд, для резидентного и мобильного — 8–15, потому что через реальное устройство пакет проходит больше промежуточных узлов. Read timeout ограничивает ожидание ответа после того, как соединение уже установлено; ориентир — ожидаемое время ответа целевого сервера с запасом в 2–3 раза, обычно 15–30 секунд для обычных запросов и больше для тяжёлых операций. Слишком короткий таймаут на резидентном канале превращает нормальную сетевую задержку в ложный сбой, слишком длинный — держит соединение открытым без пользы и тратит трафик впустую.

Экспоненциальная пауза между повторами

Повторять запрос сразу после обрыва — плохая идея: если причина в перегрузке узла или временной потере сигнала, мгновенный повтор попадёт в то же состояние. Экспоненциальный backoff увеличивает паузу с каждой попыткой — например, 1, 2, 4, 8 секунд — и даёт каналу время восстановиться. К паузе стоит добавлять случайный джиттер в пределах 20–30% от расчётного значения: без него параллельные потоки одного скрипта после общего сбоя повторяют запросы синхронно и создают собственный всплеск нагрузки. Число попыток разумно ограничивать тремя-четырьмя: дальше вероятность успеха почти не растёт, а расход времени и трафика — растёт линейно.

Какие ошибки повторять, а какие — нет

Повторять стоит то, что похоже на временный сбой: обрыв соединения, таймаут, ошибки 502/503/504 и сетевые исключения без ответа от сервера. Не стоит повторять то, что не изменится от новой попытки: ошибку 400 с некорректным телом запроса, 401/403 как проблему авторизации, 404 как отсутствующий ресурс. Отдельно стоит обрабатывать код 429 — это не сбой, а прямое указание притормозить, и повторять такой запрос нужно с паузой, которую сервер обычно называет в заголовке ответа, а не по общей схеме backoff. Слепой повтор всех ошибок подряд без разбора — типичная причина, по которой скрипт часами долбит в стену вместо того, чтобы остановиться и сообщить о проблеме.

Как отличить обрыв канала от блокировки площадкой

Обрыв канала — это отсутствие ответа: таймаут, сброс соединения, ошибка на уровне TCP или TLS. Блокировка — это ответ, просто нежелательный: код 403, капча вместо контента, редирект на страницу проверки, HTML нормального размера вместо ожидаемых данных. Первое лечится повтором, второе — нет: повторный запрос с того же адреса на блокировку почти всегда получает тот же ответ, а смена адреса через ротацию — уже другой вопрос, разобранный в статье о настройке ротации IP по API. Каждый повтор — отдельная сессия резидентного или мобильного канала, а такие каналы тарифицируются по трафику: агрессивный ретрай на заблокированном адресе не решает проблему, а просто расходует гигабайты на получение одного и того же отказа. Лимит попыток и разбор кода ответа — это вопрос не только надёжности, но и бюджета.

Частые вопросы

Сколько раз стоит повторять запрос, прежде чем сдаться?

Для большинства задач достаточно трёх-четырёх попыток с экспоненциальным ростом паузы. Если все они провалились, вероятность успеха пятой попытки на том же адресе низкая, а расход трафика продолжает расти — разумнее сменить адрес через ротацию или вернуть ошибку вызывающему коду.

Нужны ли разные настройки таймаута для датацентрового и резидентного канала?

Да. Датацентровый канал держит стабильную низкую задержку, и короткий таймаут там оправдан. Резидентный и мобильный каналы проходят через реальное оборудование живого абонента, поэтому таймауты на них стоит задавать заметно шире — иначе нормальная сетевая задержка будет постоянно приниматься за сбой.

Можно ли использовать один и тот же алгоритм ретраев для всех ошибок?

Нет. Сетевые сбои и ответы 5xx — кандидаты на повтор с задержкой. Ошибки авторизации и некорректного запроса повторять бессмысленно. Код 429 требует паузы по инструкции сервера, а признаки блокировки — капча, редирект, код 403 — требуют смены адреса, а не повтора на том же IP.

Резидентные и мобильные каналы для задач с ретраями — в разделе прокси: там же можно оценить расход трафика на конкретный сценарий и выбрать канал под нужный баланс стабильности и цены, сверившись с разницей между мобильными и резидентными прокси.