Перейти к содержимому
Диагностика

Как построить честный чекер прокси: состояния, таймауты и параллельность

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

3 мин чтенияПроверено и обновлено: 6 августа 2026 г.

Главное за минуту

  • TCP, авторизация, релей и ответ назначения проверяются отдельно.
  • Состояние проверяется не равно онлайн или офлайн.
  • Connect timeout и общий timeout задаются независимо.
  • Параллелизм ограничивается пулом, а результат читается для каждой операции.

Многоступенчатая проверка

Минимальная цепочка включает DNS нужной стороны, соединение с прокси, авторизацию, CONNECT или SOCKS-релей и запрос к собственной контрольной конечной точке. Для каждого этапа сохраняют длительность и код. Так поддержка видит точное место отказа.

  • Прокси недоступен: не установлено соединение до конечной точки.
  • Доступ отклонён: транспорт есть, авторизация не прошла.
  • Назначение недоступно: прокси ответил, но релей не создан.
  • Проверка подтверждена: контрольный запрос завершился ожидаемо.

Четыре пользовательских состояния

Практичная модель — проверяется, работает, не работает и результат не подтверждён. Таймаут или потерянный ответ сначала дают неопределённый результат, а не безусловный офлайн. Последний успешный сигнал и время офлайна показываются отдельно от текущей попытки.

Таймауты и осторожные повторы

Таймаут подключения ограничивает установление соединения, общий таймаут — всю операцию, включая DNS и передачу. Один повтор допустим для безопасной проверки без изменений после небольшой задержки. Управляющие команды не повторяют тем же правилом, потому что первый результат мог быть выполнен, но потерян.

Масштабирование без шторма

Multi-интерфейс cURL допускает много одновременных операций, но приложение всё равно задаёт предел по системе, серверу и клиенту. Добавляйте разброс запуска (jitter), группируйте проверки и автоматически останавливайте новые попытки при массовом сбое локации (circuit breaker). Завершение передачи означает только окончание операции — успешность читается из индивидуального результата.

Данные для поддержки

Храните идентификатор прокси, время, этап, обезличенный код ошибки, длительности и версию проверки. Не сохраняйте пароль или управляющую ссылку. Агрегированный сбой локации должен отображаться отдельно, чтобы авторемонт не начал массово переносить исправные прокси.

Практический чек-лист

  1. 1Разделить DNS, connect, auth, relay и контрольный запрос.
  2. 2Использовать минимум четыре состояния результата.
  3. 3Назначить разные таймауты этапу подключения и всей операции.
  4. 4Ограничить параллелизм и добавить разброс запуска.
  5. 5Остановить массовые действия при признаках сбоя локации.
  6. 6Исключить секреты из диагностических событий.

Источники и документы

Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.

  1. 1.curl project: CURLOPT_CONNECTTIMEOUT
  2. 2.curl project: CURLOPT_TIMEOUT
  3. 3.curl project: libcurl multi interface overview
  4. 4.curl project: CURLINFO_RESPONSE_CODE

Продолжить чтение

Материалы по близкой теме

Честная проверка

Что на самом деле подтверждает сайт проверки IP

Читать

Пошаговая диагностика

Прокси не подключается: найдите ошибку по этапу соединения

Читать

Практическая проверка

Как проверить HTTP- и SOCKS5-прокси через cURL

Читать