Строка запроса, которая направляет HTTP в Node через прокси
Соберите обычный запрос к HTTP-прокси основным клиентом Node, разделив конечную точку соединения, абсолютную цель и заголовок Host.
При обычном HTTP-запросе через прямой прокси Node подключается к прокси и отправляет URL назначения в строке запроса. Три значения описывают этот один запрос:
| Значение | Пример |
|---|---|
| Конечная точка TCP-соединения | proxy.example:8080 |
| Цель запроса | http://example.com/news?q=proxy |
| Заголовок Host | example.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 нужно контролировать или понимать.