Comment configurer un health check pour un pool de proxy : surveillance automatique en 15 minutes

Si vous travaillez avec un grand nombre de proxies — en scrappant des marketplaces, en gérant plusieurs comptes sur les réseaux sociaux ou en lançant des publicités — vous connaissez le problème : soudain, une partie des proxies cesse de fonctionner, et vos tâches s'arrêtent. Le health check (vérification de la fonctionnalité) du pool de proxies résout ce problème automatiquement : le système vérifie chaque IP, exclut les non fonctionnelles et utilise uniquement des connexions stables.

Dans ce guide, nous allons voir comment configurer un health check automatique pour le pool de proxies : d'une simple vérification de disponibilité à une surveillance avancée avec remplacement des proxies défectueux. Cela convient à toutes les tâches — du scraping de Wildberries au multi-comptes dans Facebook Ads.

Qu'est-ce que le health check des proxies et pourquoi est-il nécessaire

Le health check (vérification de la fonctionnalité) est un système de surveillance automatique du pool de proxies qui vérifie régulièrement chaque adresse IP pour sa disponibilité, sa vitesse et son bon fonctionnement. Lorsque vous travaillez avec des dizaines ou des centaines de proxies, une partie d'entre eux cesse inévitablement de fonctionner : expiration, IP bloquée, fournisseur bloquant l'accès ou simplement une baisse de la vitesse.

Sans health check, vous ne découvrirez le problème que lorsque la tâche échouera avec une erreur : le scraper ne collectera pas de données, le compte sera bloqué à cause d'un proxy non fonctionnel, ou la publicité ne sera pas lancée. Avec un health check configuré, le système exclut automatiquement les proxies défectueux de la rotation et n'utilise que des connexions stables.

Le health check est particulièrement critique pour les tâches commerciales : si vous gérez 30 comptes clients sur Instagram, scrappez les prix des concurrents sur Ozon ou lancez des publicités sur Facebook Ads — un arrêt dû à un proxy non fonctionnel peut coûter de l'argent et nuire à votre réputation.

Méthodes de vérification de la fonctionnalité des proxies

Il existe plusieurs niveaux de vérification des proxies — d'une simple vérification de disponibilité à une analyse approfondie de l'anonymat et de la vitesse. Le choix de la méthode dépend de vos tâches : pour le scraping, une vérification de base suffit, tandis que pour le multi-comptes sur les réseaux sociaux, une vérification de la géolocalisation et de l'anonymat est nécessaire.

1. Vérification de base de la disponibilité (Ping Check)

La méthode la plus simple consiste à envoyer une requête HTTP via le proxy à un serveur de test et à vérifier si une réponse a été reçue. On utilise généralement des services publics comme httpbin.org, ip-api.com ou son propre serveur de test.

Ce qui est vérifié : le proxy répond-il aux requêtes ou non (statut 200 OK). C'est une vérification minimale qui élimine les IP complètement non fonctionnelles.

Quand c'est suffisant : scraping de données publiques, collecte d'informations sur des sites sans protection stricte, tâches massives où la vitesse de vérification est importante.

2. Vérification de la vitesse de réponse (Latency Check)

On mesure le temps de réponse du proxy — combien de millisecondes s'écoulent entre l'envoi de la requête et la réception de la réponse. Les proxies lents (plus de 3-5 secondes) peuvent provoquer des timeouts et des soupçons de la part des plateformes.

Ce qui est vérifié : le temps de réponse (latence) et la stabilité de la vitesse. Les proxies avec une latence supérieure à 5000 ms sont généralement exclus du pool.

Quand c'est important : travail avec les réseaux sociaux (Instagram, TikTok), tableaux de bord publicitaires (Facebook Ads, Google Ads), tâches où la vitesse de chargement des pages est cruciale.

3. Vérification de la géolocalisation et de la réputation IP

On vérifie la correspondance de l'IP avec le pays et la ville déclarés, ainsi que la réputation de l'IP (s'il n'est pas sur des listes noires, s'il n'est pas utilisé pour du spam). Pour les proxies résidentiels, cela est critique — les plateformes vérifient la correspondance de la géolocalisation avec les données du compte.

Ce qui est vérifié : pays et ville de l'IP, fournisseur, présence sur des bases de données de spam (DNSBL, Spamhaus), type de connexion (résidentiel/datacenter).

Quand c'est critique : multi-comptes sur les réseaux sociaux, arbitrage de trafic, travail avec des comptes liés à des villes spécifiques (par exemple, publication d'annonces sur Avito).

4. Vérification de l'anonymat (Anonymity Level)

On détermine le niveau d'anonymat du proxy — s'il transmet des en-têtes révélant votre véritable IP (X-Forwarded-For, Via). Les proxies peuvent être de trois types : transparent (transparents, transmettent la véritable IP), anonymous (cachent l'IP, mais montrent que c'est un proxy) et elite (totalement anonymes).

Ce qui est vérifié : présence des en-têtes X-Forwarded-For, X-Real-IP, Via, Proxy-Connection. Pour les tâches commerciales, seuls les proxies elite sont nécessaires.

Quand c'est obligatoire : travail avec des plateformes avec une protection anti-fraude stricte (Facebook, Google, TikTok), multi-comptes, arbitrage de trafic.

Configuration de base du health check : vérification de la disponibilité

Commençons par une configuration simple du health check, qui vérifie la disponibilité de chaque proxy dans le pool. Cette méthode convient à la plupart des tâches et prend 10-15 minutes à configurer.

Étape 1 : Préparation de la liste de proxies

Créez un fichier avec vos proxies au format IP:PORT:USER:PASS ou http://user:pass@ip:port. Chaque proxy doit être sur une nouvelle ligne.

Exemple de fichier proxies.txt :

192.168.1.100:8080:user1:pass1
192.168.1.101:8080:user2:pass2
192.168.1.102:8080:user3:pass3

Étape 2 : Choix de l'URL de test

Pour vérifier la disponibilité, vous avez besoin d'un serveur stable qui renvoie une réponse simple. Options populaires :

• httpbin.org/ip — renvoie l'adresse IP du proxy au format JSON
• ip-api.com/json — renvoie l'IP et la géolocalisation
• icanhazip.com — renvoie uniquement l'IP (le plus rapide)
• Votre propre serveur — si vous avez besoin de vérifier l'accès à un site spécifique

Pour une vérification de base, httpbin.org/ip suffit — il est stable et renvoie une réponse structurée.

Étape 3 : Configuration du script de vérification

Créez un script simple qui lit la liste des proxies, envoie une requête via chacun d'eux et vérifie le statut de la réponse. Voici un exemple en Python (le langage le plus populaire pour ce genre de tâches) :

import requests
from concurrent.futures import ThreadPoolExecutor
import time

def check_proxy(proxy_line):
    """Vérification d'un proxy"""
    try:
        # Analyse de la ligne du proxy
        parts = proxy_line.strip().split(':')
        proxy_url = f"http://{parts[2]}:{parts[3]}@{parts[0]}:{parts[1]}"
        
        proxies = {
            'http': proxy_url,
            'https': proxy_url
        }
        
        # Envoi de la requête avec un timeout de 10 secondes
        start_time = time.time()
        response = requests.get('http://httpbin.org/ip', 
                              proxies=proxies, 
                              timeout=10)
        latency = (time.time() - start_time) * 1000  # en millisecondes
        
        if response.status_code == 200:
            return {
                'proxy': proxy_line,
                'status': 'working',
                'latency': round(latency, 2),
                'ip': response.json().get('origin')
            }
    except Exception as e:
        return {
            'proxy': proxy_line,
            'status': 'failed',
            'error': str(e)
        }

# Lecture du fichier avec les proxies
with open('proxies.txt', 'r') as f:
    proxies = f.readlines()

# Vérification de tous les proxies en parallèle (jusqu'à 20 simultanément)
with ThreadPoolExecutor(max_workers=20) as executor:
    results = list(executor.map(check_proxy, proxies))

# Sauvegarde des proxies fonctionnels
working_proxies = [r for r in results if r and r['status'] == 'working']

with open('working_proxies.txt', 'w') as f:
    for proxy in working_proxies:
        f.write(proxy['proxy'])
        
print(f"Vérifiés : {len(proxies)}")
print(f"Fonctionnels : {len(working_proxies)}")
print(f"Non fonctionnels : {len(proxies) - len(working_proxies)}")

Ce script vérifie tous les proxies en parallèle (20 simultanément), ce qui accélère le processus de plusieurs dizaines de fois. Le résultat — le fichier working_proxies.txt ne contenant que des proxies fonctionnels.

Étape 4 : Automatisation de la vérification

Pour que le health check fonctionne en continu, configurez le lancement automatique du script selon un calendrier :

Linux/Mac (cron) :

# Vérification toutes les 30 minutes
*/30 * * * * /usr/bin/python3 /path/to/check_proxies.py

Windows (planificateur de tâches) :

• Ouvrez "Planificateur de tâches"
• Créez une nouvelle tâche → Déclencheur : toutes les 30 minutes
• Action : lancement de python.exe avec le chemin vers votre script

Surveillance avancée : vitesse, géolocalisation, anonymat

Pour les tâches commerciales, une vérification de base de la disponibilité n'est pas suffisante — il est nécessaire de contrôler la vitesse, la géolocalisation et le niveau d'anonymat. Cela est particulièrement important pour le multi-comptes sur les réseaux sociaux et l'arbitrage de trafic, où les plateformes vérifient strictement les proxies.

Vérification de la vitesse et de la stabilité

Un proxy lent (latence supérieure à 3-5 secondes) peut éveiller les soupçons des plateformes : Instagram et Facebook suivent le temps de chargement des pages, et une connexion lente est un signe d'utilisation de proxies. De plus, les proxies lents ralentissent votre travail et peuvent provoquer des timeouts.

Ce qu'il faut vérifier :

• Latence (temps de réponse) : temps moyen entre la requête et la réponse. Norme : jusqu'à 1000 ms pour les résidentiels, jusqu'à 300 ms pour les datacenters
• Vitesse de chargement : combien de kilobits par seconde sont téléchargés via le proxy. Norme : minimum 500 Kbit/s
• Stabilité : vérification de 3-5 requêtes consécutives — la latence ne doit pas fluctuer de manière significative (une variation de plus de 50 % est un mauvais signe)

Exemple de vérification de vitesse avancée :

def check_proxy_speed(proxy_url):
    """Vérification de la vitesse et de la stabilité"""
    latencies = []
    
    # Effectuer 5 requêtes pour vérifier la stabilité
    for i in range(5):
        try:
            start = time.time()
            response = requests.get('http://httpbin.org/ip',
                                  proxies={'http': proxy_url, 'https': proxy_url},
                                  timeout=10)
            latency = (time.time() - start) * 1000
            latencies.append(latency)
            time.sleep(0.5)  # pause entre les requêtes
        except:
            return None
    
    avg_latency = sum(latencies) / len(latencies)
    max_latency = max(latencies)
    min_latency = min(latencies)
    stability = (max_latency - min_latency) / avg_latency * 100
    
    return {
        'avg_latency': round(avg_latency, 2),
        'stability': round(stability, 2),  # % de variation
        'status': 'good' if avg_latency < 3000 and stability < 50 else 'slow'
    }

Vérification de la géolocalisation

Pour le multi-comptes, il est crucial que la géolocalisation du proxy corresponde aux données du compte. Si vous gérez un compte d'une entreprise de Moscou via un proxy de Vladivostok — c'est un signal d'alarme pour la plateforme. Utilisez le service ip-api.com pour vérifier la géolocalisation :

def check_proxy_geo(proxy_url):
    """Vérification de la géolocalisation du proxy"""
    try:
        response = requests.get('http://ip-api.com/json',
                              proxies={'http': proxy_url, 'https': proxy_url},
                              timeout=10)
        data = response.json()
        
        return {
            'ip': data.get('query'),
            'country': data.get('country'),
            'city': data.get('city'),
            'isp': data.get('isp'),
            'proxy_type': data.get('proxy'),  # True si un proxy est détecté
            'mobile': data.get('mobile')  # True pour les IP mobiles
        }
    except:
        return None

Conservez les données de géolocalisation pour chaque proxy et utilisez-les lors de la répartition des tâches : comptes de Moscou — via des proxies moscovites, annonces régionales sur Avito — via des proxies de la ville concernée.

Vérification de l'anonymat

Les proxies peuvent avoir trois niveaux d'anonymat : transparent (transparents), anonymous (anonymes) et elite (élites). Pour travailler avec Facebook, Instagram, TikTok et d'autres plateformes avec une protection anti-fraude, seuls les proxies elite sont nécessaires — ils ne transmettent pas d'en-têtes révélant l'utilisation de proxies.

Ce qu'il faut vérifier :

• Les en-têtes X-Forwarded-For, X-Real-IP, Via — doivent être absents
• L'IP dans la réponse doit correspondre à l'IP du proxy (pas votre véritable IP)
• User-Agent doit être transmis sans modifications

def check_proxy_anonymity(proxy_url):
    """Vérification du niveau d'anonymat"""
    try:
        response = requests.get('http://httpbin.org/headers',
                              proxies={'http': proxy_url, 'https': proxy_url},
                              timeout=10)
        headers = response.json()['headers']
        
        # Vérification de la présence d'en-têtes révélant le proxy
        proxy_headers = ['X-Forwarded-For', 'X-Real-Ip', 'Via', 'Proxy-Connection']
        detected_headers = [h for h in proxy_headers if h in headers]
        
        if len(detected_headers) == 0:
            return 'elite'  # totalement anonyme
        elif 'X-Forwarded-For' not in headers:
            return 'anonymous'  # cache l'IP, mais montre que c'est un proxy
        else:
            return 'transparent'  # transmet la véritable IP
    except:
        return None

Pour les tâches commerciales, utilisez uniquement des proxies elite. Les proxies mobiles ont par défaut un niveau elite, car ils utilisent de véritables IP de fournisseurs de services mobiles.

Rotation automatique : remplacement des proxies défectueux

Le health check devient vraiment utile lorsqu'il ne se contente pas de vérifier les proxies, mais remplace automatiquement les non fonctionnels par des fonctionnels. Cela est crucial pour les tâches continues : scraping de marketplaces, surveillance des prix, autoposting sur les réseaux sociaux.

Stratégie 1 : Pool avec priorités

Créez deux listes de proxies : principale (working) et de secours (backup). Le health check vérifie en permanence le pool principal, et lorsqu'il détecte un proxy non fonctionnel, il le remplace par un proxy du pool de secours.

Comment cela fonctionne :

1. Le health check vérifie tous les proxies du pool principal toutes les 30 minutes
2. Les proxies non fonctionnels sont déplacés dans la liste "en quarantaine" (quarantine)
3. Un proxy fonctionnel est pris du pool de secours et ajouté au principal
4. Après 2-4 heures, les proxies en quarantaine sont vérifiés à nouveau — s'ils fonctionnent, ils retournent dans le pool de secours

Exemple de mise en œuvre :

import json
from datetime import datetime, timedelta

class ProxyPool:
    def __init__(self):
        self.working = []  # pool principal
        self.backup = []   # pool de secours
        self.quarantine = {}  # {proxy: timestamp quand il a été mis en quarantaine}
    
    def check_and_rotate(self):
        """Vérification et rotation des proxies"""
        failed_proxies = []
        
        # Vérification du pool principal
        for proxy in self.working:
            if not self.is_proxy_working(proxy):
                failed_proxies.append(proxy)
                self.quarantine[proxy] = datetime.now()
        
        # Suppression des non fonctionnels du pool principal
        self.working = [p for p in self.working if p not in failed_proxies]
        
        # Ajout de secours autant que nécessaire
        needed = len(failed_proxies)
        for i in range(needed):
            if len(self.backup) > 0:
                new_proxy = self.backup.pop(0)
                if self.is_proxy_working(new_proxy):
                    self.working.append(new_proxy)
        
        # Vérification de la quarantaine — si un proxy est en quarantaine depuis plus de 4 heures, vérification
        now = datetime.now()
        for proxy, quarantine_time in list(self.quarantine.items()):
            if now - quarantine_time > timedelta(hours=4):
                if self.is_proxy_working(proxy):
                    self.backup.append(proxy)
                del self.quarantine[proxy]
        
        self.save_state()
    
    def save_state(self):
        """Sauvegarde de l'état du pool"""
        state = {
            'working': self.working,
            'backup': self.backup,
            'quarantine': {k: v.isoformat() for k, v in self.quarantine.items()}
        }
        with open('proxy_pool_state.json', 'w') as f:
            json.dump(state, f)

Stratégie 2 : Round-robin avec exclusion

Une approche plus simple : utilisez tous les proxies à tour de rôle (round-robin), mais en cas d'erreur, excluez temporairement le proxy de la rotation pendant 30-60 minutes. Convient aux tâches où la vitesse est importante, et non la stabilité parfaite.

Comment cela fonctionne :

• Les proxies sont choisis à tour de rôle : 1, 2, 3, 4, 1, 2, 3, 4...
• Si un proxy renvoie une erreur, il est exclu pendant 30 minutes
• Après 30 minutes, le proxy revient automatiquement dans la rotation
• Si un proxy échoue 3 fois de suite — il est exclu pendant 4 heures

Cette méthode est bonne pour le scraping et les tâches massives, où il est possible de manquer quelques requêtes sans conséquences critiques.

Stratégie 3 : Rotation pondérée par métriques

Une approche avancée : chaque proxy se voit attribuer un "poids" basé sur des métriques (vitesse, stabilité, taux de succès des requêtes). Les proxies avec un poids élevé sont utilisés plus souvent, ceux avec un faible poids moins souvent. Convient aux tâches critiques : multi-comptes, arbitrage.

Formule de poids :

weight = (success_rate * 0.5) + (speed_score * 0.3) + (uptime * 0.2)

où :
- success_rate : % de requêtes réussies au cours de la dernière heure (0-100)
- speed_score : 100 - (latency / 50) — plus c'est rapide, plus c'est élevé
- uptime : % du temps où le proxy a été disponible au cours des dernières 24 heures

Les proxies avec un poids supérieur à 70 sont utilisés pour les tâches critiques (connexion aux comptes), ceux avec un poids de 40-70 pour les tâches ordinaires, et ceux en dessous de 40 sont temporairement exclus.

Outils prêts à l'emploi pour le health check du pool de proxies

Si vous ne souhaitez pas écrire votre propre script, utilisez des solutions prêtes à l'emploi. Beaucoup d'entre elles ont une interface web, une API et une intégration avec des outils populaires.

1. ProxyChecker par Proxy-Store

Outil gratuit pour Windows/Linux avec interface graphique. Vérifie la disponibilité, la vitesse, l'anonymat et la géolocalisation. Prend en charge HTTP, HTTPS, SOCKS4/5. Exporte les résultats en TXT, CSV, JSON.

Avantages : interface simple, vérification rapide (jusqu'à 1000 proxies par minute), filtres par pays et vitesse.

Inconvénients : pas de rotation automatique, doit être lancé manuellement.

2. Proxy Scraper & Checker

Projet open-source en Python avec collecte automatique de proxies gratuits et health check. Convient pour des expériences et des tests, mais pas pour les entreprises (les proxies gratuits sont instables).

Avantages : gratuit, collecte automatique de proxies, vérifications personnalisables.

Inconvénients : qualité des proxies gratuits faible, blocages fréquents.

3. Proxy Pool Manager (solutions commerciales)

Services payants avec gestion complète des proxies : health check, rotation automatique, API, intégration avec des navigateurs anti-détection (Dolphin Anty, AdsPower, Multilogin). Exemples : Bright Data Proxy Manager, Smartproxy Dashboard, Oxylabs Proxy Rotator.

Avantages : tout dans une seule solution, support 24/7, intégrations prêtes à l'emploi.

Inconvénients : coût élevé (à partir de 50 $/mois), dépendance à un fournisseur de proxies spécifique.

4. Health check intégré dans les navigateurs anti-détection

Si vous utilisez des navigateurs anti-détection pour le multi-comptes, beaucoup d'entre eux ont une vérification intégrée des proxies :

• Dolphin Anty : vérification de la disponibilité et de la vitesse lors de l'ajout de proxies au profil
• AdsPower : vérification automatique des proxies avant le lancement du profil
• Multilogin : testeur de proxies intégré avec vérification de l'anonymat
• GoLogin : vérification de la géolocalisation et de la réputation IP

Ces outils sont pratiques pour les spécialistes SMM et les arbitragistes qui travaillent avec un petit nombre de comptes (jusqu'à 50-100). Pour de grands volumes, une solution propre est nécessaire.

Scénarios d'utilisation pour les entreprises

Examinons des cas concrets où le health check du pool de proxies résout de réelles tâches commerciales.

Cas 1 : Scraping des prix des concurrents sur les marketplaces

Tâche : un vendeur sur Wildberries scrappe les prix de 500 concurrents toutes les 2 heures pour ajuster automatiquement ses prix. Un pool de 50 proxies est utilisé.

Problème sans health check : une partie des proxies est bloquée par Wildberries après 100-200 requêtes, le scraper échoue avec des erreurs, les données sont collectées de manière incomplète. Il faut vérifier et remplacer manuellement les proxies tous les 2-3 jours.

Solution avec health check : toutes les 30 minutes, le système vérifie les 50 proxies avec une requête à Wildberries. Les non fonctionnels (statut 403, 429 ou timeout) sont automatiquement remplacés par des proxies de secours du pool de 20 proxies de secours. Le scraper utilise toujours uniquement des proxies fonctionnels.

Résultat : la stabilité du scraping est passée de 70 % à 98 %, le travail manuel a été réduit de 2 heures par jour à 10 minutes par semaine.

Cas 2 : Multi-comptes pour une agence SMM

Tâche : une agence SMM gère 80 comptes Instagram de clients via Dolphin Anty. Chaque compte est lié à son propre proxy (1 compte = 1 proxy).

Problème sans health check : si un proxy cesse de fonctionner, le gestionnaire ne le découvre que lorsqu'il ne peut pas accéder au compte du client. Pendant ce temps, Instagram peut bloquer le compte en raison d'une "activité suspecte" (changement brusque d'IP).

Solution avec health check : toutes les 60 minutes, le système vérifie tous les 80 proxies (disponibilité + géolocalisation). Si un proxy ne répond pas, le gestionnaire reçoit une notification sur Telegram, et dans Dolphin Anty, les paramètres du profil sont automatiquement mis à jour avec un proxy de secours de la même ville.

Résultat : le nombre de blocages de comptes dus à des problèmes de proxies est passé de 5-7 par mois à 0-1. Économie : ~500 $/mois en restauration de comptes.

Cas 3 : Arbitrage de trafic sur Facebook Ads

Tâche : un arbitragiste lance des publicités avec 15 comptes Facebook Ads. Chaque compte utilise son propre proxy résidentiel des États-Unis.

Problème sans health check : Facebook vérifie strictement la stabilité de l'IP. Si le proxy "saute" (changement d'IP ou interruptions de connexion), le compte est soumis à vérification ou immédiatement bloqué. Coût de la perte d'un compte : 200-500 $ (restauration + temps d'arrêt des campagnes).

Solution avec health check : vérification toutes les 15 minutes : disponibilité, vitesse (la latence doit être stable), anonymat (niveau elite). Si un proxy montre une instabilité (variation de latence supérieure à 30 %), il est exclu de la rotation jusqu'à ce que les raisons soient clarifiées. Pour les comptes critiques, seuls les proxies avec un uptime > 99,5 % au cours des dernières 24 heures sont utilisés.

Résultat : le nombre de blocages dus à des problèmes de proxies est passé de 2-3 par mois à 0. ROI a augmenté de 15 % grâce à un fonctionnement stable des campagnes.

Erreurs courantes lors de la configuration du health check

Examinons les erreurs typiques qui réduisent l'efficacité du health check ou créent de nouveaux problèmes.

Erreur 1 : Vérification trop fréquente

Problème : vérifier toutes les 1-5 minutes crée une énorme charge sur les proxies et les services de test. Les services publics (httpbin.org, ip-api.com) peuvent bloquer votre IP pour spam. De plus, des vérifications fréquentes consomment du trafic — si vous avez 100 proxies et vérifiez chaque minute, cela fait 144 000 requêtes par jour.

Solution : pour des proxies stables, une vérification toutes les 30-60 minutes est suffisante. Pour des tâches critiques — toutes les 15 minutes. Utilisez votre propre serveur de test au lieu de services publics si vous avez besoin d'une vérification fréquente.

Erreur 2 : Vérification uniquement de la disponibilité

Problème : un proxy peut répondre aux requêtes (statut 200 OK), mais être lent (latence de 10 secondes) ou avoir une géolocalisation incorrecte. Pour les tâches commerciales, un tel proxy est inutile ou même dangereux.

Solution : vérifiez de manière complète — disponibilité + vitesse + géolocalisation + anonymat. Pour le multi-comptes, la géolocalisation est critique, pour le scraping — la vitesse, pour l'arbitrage — tout ensemble.

Erreur 3 : Absence de quarantaine

Problème : un proxy peut temporairement "tomber" en raison d'un redémarrage du serveur ou de problèmes chez le fournisseur, mais redémarrer après 1-2 heures. Si vous supprimez immédiatement ces proxies du pool, vous perdez des IP fonctionnelles.

Solution : utilisez un système de quarantaine — les proxies non fonctionnels ne sont pas supprimés, mais exclus pendant 2-4 heures. Après ce délai, ils sont vérifiés à nouveau, et s'ils fonctionnent — ils retournent dans le pool.

Erreur 4 : Ignorer les métriques de stabilité

Problème : un proxy peut fonctionner, mais de manière instable — la latence fluctue de 500 ms à 5000 ms, la période...