Проверка на списък с прокси с ограничен паралелизъм

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. Адресът на изход е друго наблюдение от страната на дестинацията, отделно от конфигурирания вход.

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