La période d'essai est courte et s'accompagne généralement d'un trafic limité. Consacrer ce temps à ouvrir quelques pages au hasard revient à laisser au hasard votre décision d'achat. Un bon test d'essai doit produire cinq métriques mesurables , et ces métriques doivent provenir de vos cibles réelles.
Dans cet article, nous présentons un protocole de test applicable étape par étape.
Avant de tester : le plan de mesure
Consacrez l'essentiel du temps au test sur la cible réelle. Les trois premières étapes ne font que vérifier que le service est correctement configuré ; c'est la quatrième étape qui détermine la décision d'achat.
Étape 1 — Vérification de base
Vérifiez d'abord que la connexion est établie et que la sortie correspond bien à l'adresse attendue :
--socks5-hostname et --socks5 la différence est essentielle : le premier résout le DNS côté proxy et prévient toute fuite.
Si vous préférez un outil, notre page de vérification de proxy effectue la même vérification en masse et détecte automatiquement le protocole ; vous pouvez par ailleurs consulter l'IP de sortie Mon adresse IP via.
Étape 2 — Géographie et anonymat
Si vous avez demandé un ciblage par pays, vérifiez que l'IP de sortie appartient réellement à ce pays. Mesurez ensuite le niveau d'anonymat — vérifiez si le proxy ajoute ou non des en-têtes supplémentaires.
- Exactitude du pays : Le pays demandé correspond-il au pays rapporté ? En cas de non-correspondance, le paramètre de ciblage est peut-être mal orthographié.
- Exactitude de la ville : Si vous avez acheté un ciblage par ville, mesurez le taux d'écart ; une précision de 100 % n'est pas une attente réaliste.
- Fuite d'en-têtes : Avec le test d'anonymat déterminez le niveau elite/anonyme/transparent.
- Fuite DNS : Test de DNS leak vérifiez d'où est effectuée la résolution de noms.
- Fuite WebRTC : Si vous comptez utiliser un navigateur, le test WebRTC .
Étape 3 — Largeur du pool
Si vous testez un service rotating, mesurer la largeur réelle du pool est bien plus instructif que le chiffre affiché sur la page commerciale :
190 IP uniques ou plus sur 200 requêtes indiquent un pool solide. Si vous n'observez que 40 à 50 IP uniques, le pool n'est pas aussi large qu'annoncé.
Pourquoi la répartition des blocs est importante article sur la diversité de sous-réseaux .
Étape 4 — Test sur la cible réelle
C'est l'étape qui détermine la décision. Sur les sites de test génériques, presque tous les proxys réussissent ; la vraie question est de savoir ce qui se passera sur votre cible.
La latence moyenne est trompeuse ; quelques requêtes très lentes faussent la moyenne. Le p50 (médiane) montre l'expérience typique, le p95 le pire scénario.
Exécutez également le même test en connexion directe (sans proxy). L'écart entre les résultats avec et sans proxy révèle l'apport réel du proxy et son coût.
Étape 5 — Stabilité de session
Si vous avez acheté des sessions sticky, vérifiez que l'engagement de durée est réellement tenu. La méthode est simple : avec la même clé de session, envoyez des requêtes à intervalles réguliers pendant la durée annoncée et observez si l'IP de sortie change.
Si l'IP change avant l'expiration, l'engagement de session n'est pas tenu. Sur les tâches nécessitant une authentification, cela se transforme directement en problème de sécurité des comptes.
Tableau de comparaison des résultats
Si vous testez plusieurs fournisseurs, regroupez les résultats dans un même tableau. La décision ne doit pas se prendre sur « lequel est le moins cher », mais coût par requête réussie sur.
| Métrique | Fournisseur A | Fournisseur B | Remarque |
|---|---|---|---|
| Taux de réussite | — | — | Le plus élevé l'emporte |
| Taux de CAPTCHA | — | — | Le plus faible l'emporte |
| Latence médiane | — | — | Valeur p50 |
| Latence p95 | — | — | Comportement de la queue |
| IP uniques / 200 | — | — | Étendue du pool |
| Exactitude du sticky | — | — | L'engagement est-il tenu |
| Coût par requête réussie | — | — | La véritable métrique de décision |
Ce qu'il ne faut pas faire pendant l'essai
La bonne approche
- Tester sur des cibles réelles, à un rythme proche de celui de la production.
- Consigner chaque métrique sous forme chiffrée.
- Effectuer une comparaison avec la connexion directe.
- Poser une question technique à l'équipe support.
Ce qu'il faut éviter
- Épuiser la totalité du quota dans la première demi-heure.
- Se contenter des sites de test génériques.
- Décider sur la base d'une seule requête.
- Imposer une charge très supérieure au rythme de production et obtenir un résultat faussé.
Résumé
La période d'essai est un outil de décision ; bien utilisée, elle fonde sur des données solides un choix qui vous engagera des mois. Appliquez les cinq étapes dans l'ordre, consignez les résultats sous forme chiffrée et fondez la comparaison sur le coût par requête réussie. Pour accélérer vos tests, vérification de proxy, test d'anonymat et test de ping vous pouvez utiliser nos outils conjointement.