René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"`ClientRequest` emits `error` event with `ERR_PROXY_TUNNEL` twice","articleBody":"### Version\n\nv25.2.0 (affects v24 identically)\n\n### Platform\n\n```text\nLinux d4e4f8af51de 6.11.11-linuxkit #1 SMP Wed Oct 22 09:37:46 UTC 2025 aarch64 GNU/Linux\n```\n\n### Subsystem\n\nhttps\n\n### What steps will reproduce the bug?\n\nI used Docker to test:\n\n```bash\ndocker run --rm \\\n  -e HTTPS_PROXY=http://google.com \\\n  -e NODE_USE_ENV_PROXY=1 \\\n  node:25.2.0 -e 'require(\"https\").request(\"https://wherever\").on(\"error\", console.error)'\n```\n\nEquivalent plain command line:\n\n```bash\nHTTPS_PROXY=http://google.com NODE_USE_ENV_PROXY=1 \\\n  node -e 'require(\"https\").request(\"https://wherever\").on(\"error\", console.error)'\n```\n\n### How often does it reproduce? Is there a required condition?\n\nIt reproduces reliably. Conditions are:\n- enable using an HTTPS proxy from the environment, with `NODE_USE_ENV_PROXY=1` (or `--use-env-proxy`)\n- use a proxy that will reject the tunnel request (I'm using `http://google.com` here which will obviously reject tunneling requests)\n\n\n\n### What is the expected behavior? Why is that the expected behavior?\n\nI expected the `error` event to only be emitted once. This is what happens with other types of error, for example if the proxy itself cannot be resolved (`ENOTFOUND`) or it rejects the connection (`ECONNRESET`).\n\n### What do you see instead?\n\nInstead, the `error` event is emitted twice.\n\nThis is a concern because an unhandled `error` event will abort the process, so code that handles the expects `error` to only be emitted once and uses `EventEmitter.once` or `events.once` can break.\n\nFor example, this fails with an unhandled `error` event, after printing out the first `error` event:\n\n```bash\n$ HTTPS_PROXY=http://google.com NODE_USE_ENV_PROXY=1  \\\n  node -e 'require(\"https\").request(\"https://wherever\").once(\"error\", console.error)'\n\nError [ERR_PROXY_TUNNEL]: Failed to establish tunnel to wherever:443 via http://google.com: HTTP/1.1 404 Not Found\n    at onProxyData (node:https:256:19)\n    at Socket.read (node:https:220:11)\n    at Socket.emit (node:events:508:28)\n    at emitReadable_ (node:internal/streams/readable:832:12)\n    at process.processTicksAndRejections (node:internal/process/task_queues:88:21) {\n  code: 'ERR_PROXY_TUNNEL',\n  statusCode: 404\n}\nnode:events:486\n      throw er; // Unhandled 'error' event\n      ^\n\nError [ERR_PROXY_TUNNEL]: Failed to establish tunnel to wherever:443 via http://google.com: HTTP/1.1 404 Not Found\n    at onProxyData (node:https:256:19)\n    at Socket.read (node:https:220:11)\n    at Socket.emit (node:events:508:28)\n    at emitReadable_ (node:internal/streams/readable:832:12)\n    at process.processTicksAndRejections (node:internal/process/task_queues:88:21)\nEmitted 'error' event on ClientRequest instance at:\n    at emitErrorEvent (node:_http_client:108:11)\n    at _destroy (node:_http_client:962:9)\n    at onSocketNT (node:_http_client:982:5)\n    at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {\n  code: 'ERR_PROXY_TUNNEL',\n  statusCode: 404\n}\n\nNode.js v25.2.0\n\n$ echo $?\n1\n```\n\n### Additional information\n\nIt may be argued that `error` being emitted only once isn't really guaranteed (that I could find), so here is an illustration of how existing code can rely on such behaviour. We encountered this when trying to use https://github.com/panva/openid-client v5.7.0 (version 6 uses `fetch` so is not affected) in conjunction with `NODE_USE_ENV_PROXY`. The code in `openid-client` uses `events.once` together with `Promise.race` to wait for either the `response` or `timeout` events to occur on the `ClientRequest`: https://github.com/panva/openid-client/blob/45c96f67ce0644bd829f61e82fba3dd8c051c89e/lib/helpers/request.js#L135\n\n```js\n    [response] = await Promise.race([once(req, 'response'), once(req, 'timeout')]);\n```\n\nThis relies on the fact that `events.once` will also listen to the `error` event. But it will unsubscribe from `error` after the first event, so the process crashes as the second `error` event is emitted.\n\nHere's a reproduction of the issue as encountered, assuming `npm install openid-client@5.7.0`.\n\nThis scenario, where the proxy refuses to establish a tunnel, fails with an `Unhandled 'error' event` crash:\n\n```bash\n$ HTTPS_PROXY=http://google.com NODE_USE_ENV_PROXY=1 \\\n  node -e 'require(\"openid-client\").Issuer.discover(\"https://wherever\").then(console.log, console.error);'\n\nnode:events:486\n      throw er; // Unhandled 'error' event\n      ^\n\nError [ERR_PROXY_TUNNEL]: Failed to establish tunnel to wherever:443 via http://google.com: HTTP/1.1 404 Not Found\n    at onProxyData (node:https:256:19)\n    at Socket.read (node:https:220:11)\n    at Socket.emit (node:events:508:28)\n    at emitReadable_ (node:internal/streams/readable:832:12)\n    at process.processTicksAndRejections (node:internal/process/task_queues:89:21)\nEmitted 'error' event on ClientRequest instance at:\n    at emitErrorEvent (node:_http_client:107:11)\n    at _destroy (node:_http_client:954:9)\n    at onSocketNT (node:_http_client:974:5)\n    at process.processTicksAndRejections (node:internal/process/task_queues:91:21) {\n  code: 'ERR_PROXY_TUNNEL',\n  statusCode: 404\n}\n\n$ echo $?\n1\n```\n\nThis one, where the proxy cannot be resolved, has a saner behaviour (the same as when no proxy is involved) of rejecting the promise returned by `discover()`, allowing recovery:\n\n```bash\n$ HTTPS_PROXY=http://proxy.invalid NODE_USE_ENV_PROXY=1 \\\n  node -e 'require(\"openid-client\").Issuer.discover(\"https://wherever\").then(console.log, console.error);'\n\nError: getaddrinfo ENOTFOUND proxy.invalid\n    at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:122:26) {\n  errno: -3008,\n  code: 'ENOTFOUND',\n  syscall: 'getaddrinfo',\n  hostname: 'proxy.invalid'\n}\n\n$ echo $?\n0\n```\n","author":{"url":"https://github.com/jonathanperret","@type":"Person","name":"jonathanperret"},"datePublished":"2025-11-12T21:13:38.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/60697/node/issues/60697"}