Node の Undici でプロキシ IP を使う

一つの fetch リクエストに Undici の ProxyAgent を指定し、接続プールを無関係な Node 通信から分けます。

Undici はディスパッチャーを通してリクエストを送ります。選んだ HTTP プロキシ用の ProxyAgent を作り、プロセス全体のグローバルディスパッチャーを変更する代わりに fetch 呼び出しへ渡します。

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();
}

プログラムを .mjs ファイルとして保存するか、ES モジュールのプロジェクトを使います。文書用 IP はHTTP プロキシ一覧の HTTP プロキシに置き換えます。意図的に Undici の fetch 実装をインポートしているため、dispatcher オプションはこの例のクライアントに属します。

IP を疑う前に Node の互換性を確認する

Undici の対応 Node バージョンはパッケージのリリース次第です。この例は Undici 8.12.3 を使い、Node 22.19.0 以降が必要です。モジュール読み込みやエンジンバージョンのエラーは、リクエストがプロキシに届く前に起こります。すべての Node で最新 Undici が動くと考えず、インストール済みパッケージのエンジン要件を確認してください。

一つの agent で複数のリクエストを処理する

短い例は終了時にディスパッチャーを閉じます。動作中のアプリケーションが同じ接続先へ複数のリクエストを送るなら、その処理中は agent を保持し、処理が終わってから閉じます。URL ごとに作って閉じると、有効な接続再利用ができません。

グローバルディスパッチャーが適するのは、より広い変更を意図している場合だけです。明示的に渡せば、他の構成要素の送信リクエストを変えずにプロキシ IP を試しやすくなります。

応答と失敗した段階を見る

fetch はすべての HTTP エラーステータスを Promise の拒否として扱うわけではありません。403 や 429 は、プロキシで運ばれた実際のサイト応答かもしれません。一方、接続やトンネルのエラーでは、応答オブジェクトができる前にリクエストが拒否されることがあります。ステータスと呼び出しが投げるエラーは分けて確認します。

認証が必要なら Undici の ProxyAgent にコンストラクターで指定する認証オプションがあります。サイト宛てのリクエストヘッダーにプロキシ認証ヘッダーを加えないでください。agent が担当するのは別の接続区間です。

関連記事