Здоровье прокси: какой сайт и какую операцию вы проверили?
Отделяйте общую доступность прокси от сбоев, специфичных для назначения, когда поддерживаете пул прокси для повторного использования.
Прокси загружает вашу страницу проверки IP, но терпит неудачу на API, который нужен вашему приложению. Называть его «здоровым» или «мёртвым» — значит терять самый полезный факт: два запроса были разными.
Начните с записи на уровне транспорта для конечной точки. Можете ли вы достучаться до её слушателя и завершить требуемое согласование прокси? Храните наблюдения, специфичные для назначения, рядом с этой записью, а не перезаписывайте её.
| Наблюдение | Область для проверки |
|---|---|
| Слушатель прокси отклоняет подключения | Конечная точка и маршрут к ней |
| Прокси отклоняет один порт назначения | Разрешённая операция для этого назначения |
| Один сайт возвращает ошибку учётной записи | Приложение назначения и учётные данные |
| Большие ответы застревают, маленькие завершаются | Объём передачи и политика тайм-аута |
HTTP-ответ может подтвердить, что путь запроса что-то вернул, и при этом оставаться непригодным для приложения. Храните успех транспорта, статус HTTP и ожидаемое содержимое как отдельные результаты.
Если одно назначение сбоит многократно, приостановите или исследуйте эту пару «конечная точка — назначение». Отключение прокси для каждой несвязанной задачи может выбросить полезную ёмкость. И наоборот, глобальный сбой соединения не должен оставаться скрытым за изолированной записью одного сайта.
Практический ключ здоровья может включать идентификатор прокси, службу назначения и тип операции. Избегайте использования полного URL с учётными данными или каждого уникального пути ресурса как постоянно растущего ключа. Группируйте только там, где группировка даёт осмысленный прогноз о следующем запросе.
Цель — лучшие доказательства маршрутизации, а не большая коллекция зелёных значков. Результат здоровья должен говорить, что было опробовано, когда и что он действительно установил.