При обычном HTTP-запросе через прямой прокси Node подключается к прокси и отправляет URL назначения в строке запроса. Три значения описывают этот один запрос:

ЗначениеПример
Конечная точка TCP-соединенияproxy.example:8080
Цель запросаhttp://example.com/news?q=proxy
Заголовок Hostexample.com

Этот пример для Node 22 делает разделение явным:

const http = require('node:http');
const destination = new URL('http://example.com/news?q=proxy');

const request = http.get({
  hostname: 'proxy.example',
  port: 8080,
  path: destination.href,
  headers: { Host: destination.host },
  signal: AbortSignal.timeout(15000),
}, (response) => {
  console.log(response.statusCode);
  response.on('error', console.error);
  response.resume();
});
request.on('error', console.error);

Конечная точка — заполнитель; выберите кандидата из списка HTTP-прокси для публичного HTTP-теста и проверьте его ответ. Пример вычитывает ответ после вывода статуса; приложение может вместо этого использовать тело. Запрос остаётся частью цели запроса.

Почему полный URL нужен именно там

Исходный сервер обычно получает цель вида /news?q=proxy. Прямому прокси тоже нужен пункт назначения, поэтому HTTP/1.1 определяет цель в абсолютной форме:

GET http://example.com/news?q=proxy HTTP/1.1
Host: example.com

По правилам HTTP/1.1 прокси, получивший абсолютную форму, при пересылке использует полномочия URI и заменяет несогласованное полученное поле Host. Отправка согласованного заголовка Host назначения всё же оставляет исходящий запрос однозначным. Имя хоста соединения в Node — это посредник, поэтому задавайте заголовок осознанно, а не полагайтесь на этот адрес соединения.

Если требуется аутентификация, учётные данные прокси относятся к его переходу. Параметр запроса auth в Node создаёт заголовок Authorization для ресурса; это не общий параметр входа через прокси. Используйте требуемую прокси схему и подходящий клиент прокси, когда обмен сложнее.

HTTPS добавляет туннель

Этот пример охватывает обычную передачу HTTP. Типичное HTTPS-соединение через HTTP-прокси сначала запрашивает CONNECT example.com:443, а затем запускает TLS к назначению внутри принятого туннеля. Смена URL примера на HTTPS не добавляет этих этапов.

Для HTTPS или смешанной нагрузки используйте поддерживаемый прокси-агент или диспетчер с нужной поддержкой туннелей. Для совместимых версий Node один из вариантов — fetch из Undici с ProxyAgent. Сохраните этот небольшой пример базового клиента для случаев, когда именно обычный обмен HTTP нужно контролировать или понимать.

Похожие статьи