# El fetch de Node ignora HTTPS_PROXY: corrige UND_ERR_CONNECT_TIMEOUT

Source: https://ipvolt.com/es/guides/node-fetch-ignores-https-proxy
Markdown: https://ipvolt.com/es/guides/node-fetch-ignores-https-proxy.md
Language: es

[Inicio de ipvolt](https://ipvolt.com/es.md) / [Guías](https://ipvolt.com/es/guides.md) / El fetch de Node ignora HTTPS_PROXY: corrige UND_ERR_CONNECT_TIMEOUT

Solución de problemas
11 min de lectura
Por ipvolt

El fetch de Node ignora HTTPS_PROXY y falla con UND_ERR_CONNECT_TIMEOUT aunque curl funcione. Corrígelo con NODE_USE_ENV_PROXY=1 o, en versiones antiguas, con undici.

Tu script define `HTTPS_PROXY`, llama a `fetch()`, espera diez segundos y muere con esto:

```text
node:internal/modules/run_main:107
    triggerUncaughtException(
    ^

[TypeError: fetch failed] {
  [cause]: ConnectTimeoutError: Connect Timeout Error (attempted address: shop.example.de:443, timeout: 10000ms)
      at onConnectTimeout (node:internal/deps/undici/undici:1991:23)
      at Immediate._onImmediate (node:internal/deps/undici/undici:1972:11)
      at process.processImmediate (node:internal/timers:574:21) {
    code: 'UND_ERR_CONNECT_TIMEOUT'
  }
}

Node.js v24.21.0
```

curl, ejecutado en la misma shell y con el mismo `HTTPS_PROXY`, sí consigue pasar:

```sh
curl -sS -o /dev/null -w '%{http_code}\n' https://shop.example.de/p/espressomuehle-k2
# 200
```

Al proxy no le pasa nada. El `fetch` integrado de Node no lee `HTTP_PROXY` ni `HTTPS_PROXY` a menos que se lo indiques, así que intentó llegar a la tienda directamente. La solución corta, en Node 22.21 o posterior y en Node 24 y posteriores:

```sh
NODE_USE_ENV_PROXY=1 node price-check.mjs
```

En versiones anteriores, incluida Node 20, necesitas en su lugar un dispatcher de undici. Ambas soluciones están más abajo, junto con las trampas que las rodean. Todos los comandos y salidas de esta página se ejecutaron el 2 de octubre de 2026 contra un proxy de prueba que registraba las peticiones, en las versiones de Node indicadas en [Cómo se probó](#cómo-se-probó).

## El script que agota el tiempo de espera

El ejemplo que recorre toda la guía es un pequeño trabajo que comprueba cada hora el precio de un producto en una tienda alemana, a través de un proxy residencial. `shop.example.de` representa la tienda real:

```js
// price-check.mjs: log one product's price every hour.
const PRODUCT_URL = 'https://shop.example.de/p/espressomuehle-k2';
const ONE_HOUR = 60 * 60 * 1000;

async function checkPrice() {
  const res = await fetch(PRODUCT_URL, { signal: AbortSignal.timeout(30_000) });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  const html = await res.text();
  const price = html.match(/itemprop="price" content="([\d.]+)"/)?.[1];
  console.log(new Date().toISOString(), price ? `${price} EUR` : 'price not found');
}

await checkPrice();
setInterval(() => checkPrice().catch((err) => console.error(err)), ONE_HOUR);
```

El proxy viene del entorno, como lo esperan curl, Python Requests y la mayoría de las herramientas de línea de comandos. `proxy.example.net`, `USERNAME` y `PASSWORD` son marcadores de posición para el gateway y las credenciales de tu proveedor; aplica percent-encoding a cualquier carácter reservado que contengan y carga los valores reales desde tu gestor de secretos en lugar de escribirlos en el historial de la shell:

```sh
export HTTPS_PROXY='http://USERNAME:PASSWORD@proxy.example.net:8080'
node price-check.mjs
```

En todas las versiones de Node probadas, de la 20.20.2 a la 26.10.0, esta ejecución nunca contactó con el proxy. Falló tras unos 10,6 segundos con el error de arriba. Node 20 y 22 imprimen el mismo `[cause]`, bajo una línea `TypeError: fetch failed` con una traza de pila, en lugar de la forma entre corchetes.

## Por qué el fetch de Node ignora HTTPS_PROXY

El `fetch` integrado de Node es [undici](https://github.com/nodejs/undici). Su dispatcher predeterminado abre una conexión directa con el host que indique la URL. Las variables de proxy solo se leen si activas su lectura de forma explícita: el [PR #57165](https://github.com/nodejs/node/pull/57165) añadió ese soporte en 2025 detrás de `NODE_USE_ENV_PROXY`, y su descripción llama a esa activación un primer paso y deja para más adelante activarla por defecto.

Así que la petición va directamente a `shop.example.de:443`. En una red en la que solo el proxy puede llegar a internet, el intento de conexión no obtiene respuesta, y undici se rinde tras su timeout de conexión de 10 segundos con `UND_ERR_CONNECT_TIMEOUT`. Lee la dirección del mensaje: `attempted address: shop.example.de:443` es la tienda, así que el proxy nunca se usó. Si, en cambio, el mensaje nombra el host de tu proxy, el inalcanzable es el propio proxy, y ese es otro problema; [Corregir TypeError: fetch failed de Node.js detrás de un proxy](/es/guides/fix-node-fetch-failed-proxy) descifra ese caso y las demás cadenas de causa.

Donde se permite el tráfico directo, no hay ningún error. En la prueba, sin activación, un fetch a un host al que la máquina podía llegar directamente devolvió 200 y el proxy no registró nada. En una comprobación de precios, eso significa que la tienda ve la dirección de tu propio servidor en lugar de la del proxy.

## La solución de una línea: NODE_USE_ENV_PROXY=1 o --use-env-proxy

Activa el soporte de proxy integrado de Node para el proceso:

```sh
NODE_USE_ENV_PROXY=1 node price-check.mjs
# 2026-10-02T12:35:44.149Z 49.90 EUR
```

El flag de línea de comandos hace lo mismo, y también funciona en `NODE_OPTIONS`:

```sh
node --use-env-proxy price-check.mjs
NODE_OPTIONS=--use-env-proxy node price-check.mjs
```

Con cualquiera de los dos, todas las versiones probadas que lo admiten enviaron `CONNECT shop.example.de:443` al proxy, con las credenciales de la URL, e imprimieron el precio. Los dos interruptores llegaron en versiones distintas:

| Activación | Añadida en (documentación de Node.js) | Resultado de la prueba |
| --- | --- | --- |
| [`NODE_USE_ENV_PROXY=1`](https://nodejs.org/api/cli.html#node_use_env_proxy1) | v24.0.0, v22.21.0 | Pasó por el proxy en 22.21.0, 22.23.3, 24.0.0, 24.4.1, 24.5.0, 24.21.0 y 26.10.0. Se ignoró sin aviso en 20.20.2 y 22.20.0, que agotaron el tiempo como antes |
| [`--use-env-proxy`](https://nodejs.org/api/cli.html#--use-env-proxy) | v24.5.0, v22.21.0 | Pasó por el proxy en 22.21.0, 22.23.3, 24.5.0, 24.21.0 y 26.10.0. Node 20.20.2, 22.20.0, 24.0.0 y 24.4.1 se negaron a arrancar: `bad option: --use-env-proxy` |
| `NODE_OPTIONS=--use-env-proxy` | Incluida entre las opciones permitidas en `NODE_OPTIONS` | Igual que el flag. Las versiones más antiguas salen con `--use-env-proxy is not allowed in NODE_OPTIONS` |

La guía de [configuración de red empresarial](https://nodejs.org/learn/http/enterprise-network-configuration) añade que el mismo interruptor enruta las peticiones de `node:http` y `node:https` desde v22.21.0 y v24.5.0. Eso coincidió con la prueba: `https.get` usó el proxy en 22.21.0 y 24.5.0, y siguió yendo directo en 24.0.0 y 24.4.1, donde solo estaba cubierto `fetch`.

Lo que hizo tropezar a la prueba, para que no te haga tropezar a ti:

- **Define las variables antes de que arranque Node.** Node las lee al arrancar. Un script que asignaba él mismo `process.env.HTTPS_PROXY` y después llamaba a `fetch` fue directo en todas las versiones.
- **Conserva el esquema en la URL del proxy.** Con `HTTPS_PROXY=127.0.0.1:3128`, el proceso salió antes de ejecutar ningún código con `TypeError: Invalid URL` (`ERR_INVALID_URL`). Con credenciales pero sin esquema, salió con un error `Invalid URL protocol` (`UND_ERR_INVALID_ARG`).
- **Define HTTPS_PROXY para las URL https://.** Con solo `HTTP_PROXY` definida, `fetch` la usó igualmente para la tienda HTTPS en 22.23.3, 24.21.0 y 26.10.0, pero `https.get` fue directo. `HTTPS_PROXY` cubre ambos casos.
- **Pon la activación en la línea de comandos, no en un `--env-file`.** Node leyó `HTTPS_PROXY` de un archivo `.env`, pero `NODE_USE_ENV_PROXY=1` en el mismo archivo no tuvo efecto en 22.21.0, 22.23.3, 24.5.0, 24.21.0 ni 26.10.0. Solo funcionó desde el archivo en 24.0.0 y 24.4.1. Con el proxy en `.env` y el flag en la línea de comandos, todas las versiones que tienen el flag usaron el proxy:

```sh
node --env-file=.env --use-env-proxy price-check.mjs
```

- **Cuenta con un aviso en Node 22.** 22.21.0 y 22.23.3 imprimieron `[UNDICI-EHPA] Warning: EnvHttpProxyAgent is experimental, expect them to change at any time.` La petición pasó igualmente por el proxy.
- **Un 407 es un problema de credenciales, no este.** Con una contraseña incorrecta, el error dos niveles más abajo fue `Proxy response (407) !== 200 when HTTP Tunneling`. [Corrige el error de proxy 407](/es/guides/fix-proxy-error-407) lo explica.

## Node 20 y anteriores: enruta fetch a través de un dispatcher de undici

Node 20 no tiene una activación integrada, y llegó al final de su vida útil el 30 de abril de 2026, según el [calendario de versiones de Node.js](https://github.com/nodejs/Release/blob/main/schedule.json). Las versiones 22.20 y anteriores tampoco tienen la activación integrada. Actualizar es la solución de verdad. Hasta entonces, instala undici desde npm y establece su `EnvHttpProxyAgent` como dispatcher global. Lee `HTTP_PROXY`, `HTTPS_PROXY` y `NO_PROXY`, en mayúsculas o en minúsculas, igual que el soporte integrado:

```sh
npm install undici@7
```

```js
// proxy-setup.mjs: send the built-in fetch through HTTP(S)_PROXY on older Node.
import { EnvHttpProxyAgent, setGlobalDispatcher } from 'undici';

setGlobalDispatcher(new EnvHttpProxyAgent());
```

Cárgalo antes del script, para que `price-check.mjs` no cambie:

```sh
node --import ./proxy-setup.mjs price-check.mjs
```

Con undici 7.30.0, esto usó el proxy en las nueve versiones probadas, de la 20.20.2 a la 26.10.0. Si prefieres limitar el proxy a una sola llamada, pasa el agente como `dispatcher` por petición:

```js
import { EnvHttpProxyAgent } from 'undici';

const dispatcher = new EnvHttpProxyAgent();
const res = await fetch('https://shop.example.de/p/espressomuehle-k2', { dispatcher });
console.log(res.status);
```

`ProxyAgent` recibe una URL de proxy y envía todas las peticiones a través de ella. A diferencia de `EnvHttpProxyAgent`, no lee `NO_PROXY`:

```js
import { ProxyAgent } from 'undici';

const dispatcher = new ProxyAgent(process.env.HTTPS_PROXY);
const res = await fetch('https://shop.example.de/p/espressomuehle-k2', { dispatcher });
console.log(res.status);
```

Ambos imprimieron `200` a través del proxy en todas las versiones probadas, con las credenciales tomadas de la URL.

Elige con cuidado la versión mayor de undici. undici 7 requiere Node 20.18.1 o posterior, según su `package.json`. Con undici 6.29.0, en cambio, las tres configuraciones funcionaron en Node 20, 22 y 24, pero no en 26.10.0: el dispatcher global se ignoró y la petición fue directa, y un dispatcher de undici 6 por petición falló con `UND_ERR_INVALID_ARG`. Los dispatchers de undici 8 tienen el problema contrario en Node 22 y 24, como se recoge en [la guía sobre fetch failed](/es/guides/fix-node-fetch-failed-proxy), que explica ese desfase de versiones. En Node 22.21 y posteriores, y en 24 y posteriores, `NODE_USE_ENV_PROXY=1` no necesita ninguna dependencia.

## Un desvío habitual: https-proxy-agent

Busca cómo usar un proxy en Node y encontrarás `https-proxy-agent`. Es un agente para `node:http`, `node:https` y las bibliotecas construidas sobre ellos. El `fetch` integrado no tiene opción `agent` y la ignora sin avisar:

```js
import { HttpsProxyAgent } from 'https-proxy-agent';

const agent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
const res = await fetch('https://shop.example.de/p/espressomuehle-k2', { agent });
console.log(res.status);
```

No hubo ningún aviso en ninguna versión probada. La petición fue directa y falló con `UND_ERR_CONNECT_TIMEOUT` tras unos 10,6 segundos, exactamente como si el agente no estuviera. El mismo agente (https-proxy-agent 9.1.0) funciona donde corresponde. Estos dos imprimieron 200 a través del proxy en las nueve versiones:

```js
import https from 'node:https';
import { HttpsProxyAgent } from 'https-proxy-agent';

const agent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
https.get('https://shop.example.de/p/espressomuehle-k2', { agent }, (res) => {
  console.log(res.statusCode);
  res.resume();
});
```

```js
import fetch from 'node-fetch';
import { HttpsProxyAgent } from 'https-proxy-agent';

const agent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
const res = await fetch('https://shop.example.de/p/espressomuehle-k2', { agent });
console.log(res.status);
```

El segundo usa el paquete `node-fetch` (3.3.2), no el `fetch` integrado. Si usas el integrado, recurre a `NODE_USE_ENV_PROXY` o a un dispatcher de undici.

## NO_PROXY y la trampa de la variable en minúsculas vacía

Con la activación encendida, `NO_PROXY` enumera los hosts que se saltan el proxy. Un host de comprobación de precios suele ejecutarse junto a cosas que no deberían pasar por un proxy residencial de pago, como una API de base de datos local o una comprobación de estado. En la prueba, sin `NO_PROXY`, incluso una petición a `http://127.0.0.1` pasó por el proxy.

Estas son las rutas que tomó `fetch` hacia `https://shop.example.de/` con distintos valores de `NO_PROXY`, en Node 22.23.3, 24.21.0 y 26.10.0 con `NODE_USE_ENV_PROXY=1`, y en Node 20.20.2 con la configuración de undici 7.30.0 de arriba:

| NO_PROXY | Ruta para shop.example.de |
| --- | --- |
| `localhost,127.0.0.1` | Proxy |
| `shop.example.de`, `.example.de` o `*.example.de` | Directa |
| `shop.example.de:443` | Directa |
| `shop.example.de:8443` | Proxy (el puerto no coincide) |
| `*` | Directa |
| `example.de` | Directa en 20 (undici 7.30.0), 24.21.0 y 26.10.0; proxy en 22.23.3 |

La documentación HTTP de Node describe `example.com` como una coincidencia exacta de host. `https.get` la siguió en 24.21.0 y 26.10.0 y usó el proxy, mientras que `fetch`, en las mismas versiones, trató `example.de` como si cubriera `shop.example.de`. [nodejs/node#65616](https://github.com/nodejs/node/issues/65616) sigue esa diferencia. Los nombres se comparan tal como están escritos, así que `NO_PROXY=localhost` no eximió a `http://127.0.0.1`. Enumera los hosts exactos a los que te refieres e incluye tanto `localhost` como `127.0.0.1` cuando necesites ambos.

La documentación de Node dice que la variable en minúsculas gana cuando ambas formas están definidas. Esto se vuelve extraño cuando la de minúsculas está definida pero vacía, por ejemplo por un `export https_proxy=` olvidado en un perfil de shell o por un valor vacío en una configuración de CI o de contenedor. [nodejs/node#66202](https://github.com/nodejs/node/issues/66202) informa de que `fetch` y `http.request()` interpretan un valor vacío de forma distinta. Este script envía la misma petición de las dos maneras:

```js
// which-route.mjs: send the same request with https.get and with fetch.
import https from 'node:https';

const url = 'https://shop.example.de/p/espressomuehle-k2';
const viaGet = await new Promise((resolve) => {
  const req = https.get(url, { timeout: 15_000 }, (res) => resolve(res.statusCode));
  req.on('timeout', () => req.destroy(Object.assign(new Error('timeout'), { code: 'ETIMEDOUT' })));
  req.on('error', (err) => resolve(err.code));
});
const viaFetch = await fetch(url, { signal: AbortSignal.timeout(15_000) })
  .then((res) => res.status, (err) => err.cause?.code ?? err.name);
console.log({ viaGet, viaFetch });
```

En la red de prueba, 200 significa que la petición pasó por el proxy, y un timeout, que fue directa. Con `NODE_USE_ENV_PROXY=1` en 22.21.0, 22.23.3, 24.5.0, 24.21.0 y 26.10.0:

| Entorno | `https.get` | `fetch` |
| --- | --- | --- |
| `HTTPS_PROXY` definida | Proxy (200) | Proxy (200) |
| `HTTPS_PROXY` definida, `https_proxy=''` | Proxy (200) | Directa (`UND_ERR_CONNECT_TIMEOUT`) |
| `HTTPS_PROXY` definida, `no_proxy=''`, `NO_PROXY='*'` | Directa (`ETIMEDOUT`) | Proxy (200) |

`fetch` trata una variable en minúsculas vacía como definida, así que `https_proxy=''` le desactiva el proxy y `no_proxy=''` anula `NO_PROXY`. `https.get` trata un valor vacío como no definido y recurre a la variable en mayúsculas. El `EnvHttpProxyAgent` de undici 7.30.0 en Node 20 se comportó como `fetch`. La versión con HTTP plano del issue se reprodujo igual. A 2 de octubre de 2026, el issue está abierto y [la corrección propuesta](https://github.com/nodejs/node/pull/66210) se cerró sin fusionarse, así que no confíes en ninguna de las dos interpretaciones. En su lugar, elimina las variables vacías. Esto imprime qué variables de proxy ve un proceso, sin sus valores:

```sh
node -e "for (const k of ['https_proxy', 'HTTPS_PROXY', 'http_proxy', 'HTTP_PROXY', 'no_proxy', 'NO_PROXY']) console.log(k, process.env[k] === undefined ? 'unset' : process.env[k] === '' ? 'EMPTY' : 'set')"
unset https_proxy no_proxy
```

Ejecuta la comprobación en el mismo entorno que el trabajo, como la línea de cron, la unidad de systemd o el contenedor, no solo en tu terminal. Para saber cómo lee estas variables cada cliente (curl, Python y Node), consulta [variables de entorno de proxy](/es/guides/proxy-environment-variables).

## Qué solución usar en cada versión de Node

| Node.js | undici incluido (versión probada) | Qué usar |
| --- | --- | --- |
| 20.x (fin de vida útil) | 6.24.1 (20.20.2) | `EnvHttpProxyAgent` de undici 7 mediante `--import ./proxy-setup.mjs`, y después actualiza |
| 22.0 a 22.20 | 6.21.2 (22.20.0) | El dispatcher de undici 7, o actualiza a la última 22.x |
| 22.21 y posteriores | 6.22.0 a 6.28.1 (22.21.0, 22.23.3) | `NODE_USE_ENV_PROXY=1` o `--use-env-proxy` |
| 24.0 a 24.4 | 7.8.0 a 7.11.0 (24.0.0, 24.4.1) | `NODE_USE_ENV_PROXY=1`; el flag aún no existe |
| 24.5 y posteriores | 7.12.0 a 7.29.1 (24.5.0, 24.21.0) | `NODE_USE_ENV_PROXY=1` o `--use-env-proxy` |
| 26.x | 8.10.2 (26.10.0) | `NODE_USE_ENV_PROXY=1` o `--use-env-proxy` |

Node 18 y anteriores, y las líneas de número impar, no se probaron. Comprueba tu versión con `node -v`, usando el mismo binario que ejecuta el trabajo.

## La comprobación de precios, de principio a fin

El script es el mismo archivo del principio. Solo cambia la forma de arrancarlo. En Node 22.21 o posterior, o en 24 y posteriores:

```sh
export HTTPS_PROXY='http://USERNAME:PASSWORD@proxy.example.net:8080'
export NO_PROXY='localhost,127.0.0.1'
NODE_USE_ENV_PROXY=1 node price-check.mjs
# 2026-10-02T13:20:12.538Z 49.90 EUR
```

En Node 20, con `undici@7` instalado y `proxy-setup.mjs` junto al script:

```sh
node --import ./proxy-setup.mjs price-check.mjs
# 2026-10-02T13:20:11.398Z 49.90 EUR
```

El proceso sigue en ejecución, y `setInterval` repite la comprobación cada hora. En la prueba, el proxy registró un `CONNECT shop.example.de:443` autenticado para la comprobación, y la tienda recibió la petición sin la cabecera `Proxy-Authorization`. Un 200 por sí solo no demuestra la ruta: confírmala en el panel o en el registro de peticiones de tu proveedor, o apunta el script una vez a un endpoint que controles y que informe de la dirección IP de quien llama.

## Cómo se probó

El 2 de octubre de 2026, en un VPS con Ubuntu (linux-x64), con los tarballs oficiales de Node.js v20.20.2, v22.20.0, v22.21.0, v22.23.3, v24.0.0, v24.4.1, v24.5.0, v24.21.0 y v26.10.0, cada uno verificado contra su SHA-256 publicado. Paquetes de npm: undici 7.30.0 y 6.29.0, https-proxy-agent 9.1.0 y node-fetch 3.3.2. curl 8.18.0.

Cada caso se ejecutó como un proceso propio dentro de un espacio de nombres de red de Linux aparte. Allí, `shop.example.de` se resolvía a 203.0.113.10, una dirección reservada para documentación, y se descartaba todo paquete dirigido a una dirección que no fuera de loopback, así que una conexión directa solo podía agotar el tiempo. La única ruta hacia la tienda era un proxy de reenvío en loopback que exigía autenticación Basic y registraba cada `CONNECT` y cada petición reenviada. Detrás de él, un servidor HTTPS local respondía por `shop.example.de` con un certificado de una CA desechable, en la que los procesos confiaban mediante `NODE_EXTRA_CA_CERTS` y curl mediante `CURL_CA_BUNDLE`. Las credenciales de prueba eran inventadas y los marcadores de posición de arriba las sustituyeron. Una ruta cuenta como «proxy» solo cuando el proxy registró una petición autenticada para ese host.

La prueba no cubrió macOS ni Windows (donde los nombres de las variables de entorno no distinguen entre mayúsculas y minúsculas), proxies HTTPS o SOCKS, la red de un proveedor real, Docker, ni Node 18, 23 y 25. Los tiempos proceden del espacio de nombres y no dicen nada sobre la velocidad de un proxy real.

## Guías relacionadas

- [Variables de entorno de proxy: HTTP_PROXY y NO_PROXY](/es/guides/proxy-environment-variables) explica cómo lee las variables cada cliente: curl, Python Requests y Node.
- [Corrige el error de proxy 407 sin adivinar](/es/guides/fix-proxy-error-407) ayuda cuando el proxy ya está en uso pero rechaza tus credenciales.
- [Corrige ERR_TUNNEL_CONNECTION_FAILED](/es/guides/fix-err-tunnel-connection-failed) cubre los mismos rechazos del proxy en Playwright y Puppeteer.
- [Corregir TypeError: fetch failed de Node.js detrás de un proxy](/es/guides/fix-node-fetch-failed-proxy) descifra todas las demás causas detrás de `fetch failed`.

ipvolt es un servicio de proxies para desarrolladores que todavía no está abierto; [únete a la lista de acceso anticipado](https://ipvolt.com/#waitlist-closing) y recibirás un solo correo cuando abra.

## Fuentes y lecturas adicionales

- [Node.js Learn: Enterprise network configuration](https://nodejs.org/learn/http/enterprise-network-configuration)
- [Node.js CLI: NODE_USE_ENV_PROXY=1](https://nodejs.org/api/cli.html#node_use_env_proxy1)
- [Node.js CLI: --use-env-proxy](https://nodejs.org/api/cli.html#--use-env-proxy)
- [Node.js HTTP: built-in proxy support and the NO_PROXY format](https://nodejs.org/api/http.html#built-in-proxy-support)
- [nodejs/node PR #57165: support HTTP[S]_PROXY environment variables in fetch](https://github.com/nodejs/node/pull/57165)
- [nodejs/node issue #66202: fetch() and http.request() disagree when a lower-cased proxy variable is empty](https://github.com/nodejs/node/issues/66202)
- [nodejs/node issue #65616: NO_PROXY=example.com and subdomains, http.request() vs fetch()](https://github.com/nodejs/node/issues/65616)
- [undici 7.30.0: EnvHttpProxyAgent](https://github.com/nodejs/undici/blob/v7.30.0/docs/docs/api/EnvHttpProxyAgent.md)
- [undici 7.30.0: ProxyAgent](https://github.com/nodejs/undici/blob/v7.30.0/docs/docs/api/ProxyAgent.md)
- [Node.js release schedule (end-of-life dates)](https://github.com/nodejs/Release/blob/main/schedule.json)

## Guías relacionadas

- [Variables de entorno de proxy: HTTP_PROXY y NO_PROXY](https://ipvolt.com/es/guides/proxy-environment-variables.md)
- [Corrige el error de proxy 407 sin adivinar](https://ipvolt.com/es/guides/fix-proxy-error-407.md)
- [Corrige ERR_TUNNEL_CONNECTION_FAILED en Playwright y Puppeteer](https://ipvolt.com/es/guides/fix-err-tunnel-connection-failed.md)

## Sobre ipvolt

Los ejemplos usan configuraciones de proxy genéricas, con enlaces a la documentación técnica original. El comportamiento específico de cada producto debe comprobarse con tu proveedor. ipvolt sigue en desarrollo.

[Leer el original en inglés](https://ipvolt.com/guides/node-fetch-ignores-https-proxy.md)

## Entérate cuando se abra el acceso.

ipvolt · En desarrollo

Estamos construyendo infraestructura de proxies para desarrolladores y equipos de datos. Únete a la lista de interés para recibir un aviso cuando ipvolt esté listo.

Un correo cuando se abra el acceso. Nada más.

[Solicitar acceso anticipado](https://ipvolt.com/es/guides/node-fetch-ignores-https-proxy#waitlist-closing)

[Privacidad](https://ipvolt.com/privacy)

