Проверка списка прокси с ограниченной параллельностью

var options = new ParallelOptions
{
    MaxDegreeOfParallelism = 8,
    CancellationToken = cancellationToken
};
await Parallel.ForEachAsync(endpoints, options,
    async (endpoint, token) =>
    {
        var result = await ProbeAsync(endpoint, target, token);
        observations.Add(result);
    });

Используйте ограниченный пул обработчиков, а не запускайте отдельную задачу для каждой конечной точки. Для проверок разрешённых публичных целей бесплатный список прокси даёт строки-кандидаты; при построении зонда сохраняйте протокол каждой записи. Этот фрагмент планирования .NET предполагает ProbeAsync, учитывающий прокси, и потокобезопасный сборщик observations. Восемь — иллюстративная граница, а не измеренный оптимум. Зонду по-прежнему нужны лимиты на попытку и отмена всего задания.

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

Открытый порт TCP не доказывает согласование с прокси. Получение адреса прокси как сайта тоже отличается от его использования для запроса цели.

Выбирайте цель и метод под требуемую возможность. HEAD может сэкономить трафик тела, но не доказывает, что GET возвращает полезное содержимое; сайт может отклонить один и разрешить другой. HTTPS добавляет CONNECT и TLS назначения, которых нет в простом HTTP. Адрес выхода — ещё одно наблюдение со стороны назначения, отдельное от настроенного входа.

Ограниченная работа не даёт проверяющему исчерпать собственные сокеты, память или планировщик до того, как он оценит маршрут. Поэтапный результат остаётся полезным для политики выбора, не создавая видимости, что один успешный пункт назначения делает конечную точку универсально хорошей.