Utiliser une IP de proxy avec Undici dans Node

Associez un ProxyAgent Undici à un seul appel fetch et séparez son pool de connexions du trafic Node sans rapport.

Undici achemine une requête via un dispatcher. Créez un ProxyAgent pour le proxy HTTP choisi et transmettez-le à l’appel fetch au lieu de modifier le dispatcher global de tout le processus.

npm install [email protected]
import { fetch, ProxyAgent } from 'undici';

const dispatcher = new ProxyAgent('http://203.0.113.10:8080');

try {
  const response = await fetch('https://example.com/', {
    dispatcher,
    signal: AbortSignal.timeout(15000),
  });

  console.log(response.status);
  console.log(await response.text());
} finally {
  await dispatcher.close();
}

Enregistrez le programme comme fichier .mjs ou utilisez un projet de modules ES. Remplacez l’IP de documentation par un proxy HTTP de la liste de proxys HTTP. L’import utilise volontairement l’implémentation fetch d’Undici ; l’option dispatcher appartient donc au client de l’exemple.

Vérifier la compatibilité de Node avant d’accuser l’IP

Les versions de Node prises en charge par Undici dépendent de la version du paquet. Cet exemple utilise Undici 8.12.3, qui exige Node 22.19.0 ou ultérieur. Une erreur de chargement de module ou de version du moteur survient avant que la requête atteigne un proxy. Vérifiez l’exigence de moteur du paquet installé, sans supposer que toute version de Node exécute le dernier Undici.

Un agent peut servir plusieurs requêtes

Le petit programme ferme son dispatcher à la fin. Si une application active envoie plusieurs requêtes via le même point, conservez l’agent pour cette charge de travail et fermez-le quand elle se termine. Créer et fermer un agent pour chaque URL empêche une réutilisation utile des connexions.

Un dispatcher global convient seulement si vous voulez ce changement plus large. Le transmettre explicitement facilite le test d’une IP de proxy sans changer les requêtes sortantes d’un autre composant.

Observer la réponse et l’étape de l’échec

Fetch ne traite pas tout statut HTTP d’erreur comme une promesse rejetée. Un 403 ou 429 peut être une vraie réponse du site transportée par le proxy. Une erreur de connexion ou de tunnel peut au contraire rejeter la requête avant l’existence d’un objet réponse. Lisez le statut séparément des erreurs levées par l’appel.

Si une authentification est nécessaire, le ProxyAgent d’Undici propose des options au constructeur. N’ajoutez pas d’en-tête d’autorisation du proxy aux en-têtes destinés au site ; l’agent gère un autre saut de connexion.

Articles similaires