Node の HTTPS クライアントで SOCKS エージェントを使う

socks-proxy-agent を Node コアの HTTPS リクエストに接続し、Node エージェントと fetch ディスパッチャーの区別を保ちます。

SOCKS 対応のエージェントは、Node コアの HTTPS クライアントのために宛先接続を確立できます。アプリケーションで socks-proxy-agent が利用可能な場合：

const https = require('node:https');
const { SocksProxyAgent } = require('socks-proxy-agent');

const agent = new SocksProxyAgent('socks5h://proxy.example:1080');
const request = https.get('https://www.example.com/', {
  agent,
  signal: AbortSignal.timeout(15000),
}, (response) => {
  console.log(response.statusCode);
  response.on('error', console.error);
  response.resume();
});
request.on('error', console.error);

この公開 HTTPS リクエストでは、例のエンドポイントを SOCKS5 プロキシリスト の未認証の候補に置き換えます。コールバックはステータスを出力した後に応答を読み切ります。アプリケーションが必要とする場合はそこで本文を消費してください。エージェントは割り当てられた操作に再利用し、そのクライアントポリシーが廃止されて作業が終わったら破棄します。

宛先名をどこで解決するかを選ぶ

socks-proxy-agent の URL 処理では、socks5h は宛先ホスト名の解決をプロキシ経路に任せ、socks5 はローカルで解決します。名前がプロキシのネットワークでのみ利用できる場合に重要です。

HTTPS URL はウェブサイトの同一性を保ちます。エージェントは Node がそのサイトへ TLS を開始する前に SOCKS ネゴシエーションを行います。

ユーザー名／パスワード方式のサービスでは、予約文字の URI コンポーネントエンコーディング を使って認証情報をプロキシ URL に含めます。完全な URL はログに残さないでください。宛先の Authorization ヘッダーはウェブサイトのアカウントに属します。

このエージェントは Node コアの HTTP/HTTPS リクエスト API で動作します。Node の fetch はディスパッチャーインターフェースを使うため、そのクライアントが対応する SOCKS 統合は別途設定してください。

関連記事