NO_PROXY=example.com does not bypass subdomains for http.request(), unlike fetch()
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 74/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript, nodejs
- Domain
- backend, networking
Research direction
Start with the repro.js behavior and the http entry point ProxyConfig#shouldUseProxy; compare it with fetch()'s EnvHttpProxyAgent and the NO_PROXY documentation. Done means a plain example.com entry bypasses its subdomains with a label boundary, while http.request() and fetch() agree.
Written by the indexing model from the issue text.
Description
Version
v24.18.1, also on main (v27.0.0-pre)
Platform
Darwin xxx.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:54:46 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T6000 arm64
Subsystem
http
What steps will reproduce the bug?
Dead proxy on port 1 — the error code shows where the request went:
NODE_USE_ENV_PROXY=1 HTTP_PROXY=http://127.0.0.1:1 NO_PROXY=example.com node repro.js
const http = require('node:http');
http.get('http://internal.example.com/').on('error', (e) => console.log(e.cause?.code ?? e.code));
// ECONNREFUSED — went through the proxy
fetch('http://internal.example.com/').catch((e) => console.log(e.cause?.code ?? e.code));
// ENOTFOUND — bypassed, hit DNS
How often does it reproduce? Is there a required condition?
Always, when the NO_PROXY entry has no leading dot and the request host is a subdomain of that entry.
What is the expected behavior? Why is that the expected behavior?
Same NO_PROXY in the same process should mean the same thing for http.request() / http.get() and fetch(). http.setGlobalProxyFromEnv() and the docs present one NO_PROXY format for both.
fetch() (undici EnvHttpProxyAgent) already treats a plain example.com as the host and its subdomains, with a label boundary so notexample.com does not match. http should do the same.
What do you see instead?
ProxyConfig#shouldUseProxy exact-matches a plain entry against the hostname. NO_PROXY=example.com therefore does not bypass internal.example.com for http.request(), while fetch() does.
The docs currently describe this as “Exact host name match”, which matches the http implementation and not fetch().
Additional information
Refs: #57872, #62907
- Dominant language
- JavaScript
- Stars
- 122k
- Forks
- 37.4k
- Avg merge
- 4d 4h
- Merged PRs (30d)
- 276
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nodejs/node
-
doc
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
build
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
feature request
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Similar issues
-
bug customer-eng Durable Agents Inngest status: needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
optimization optimization:agents-md-curator
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
githubnext/gh-aw-cao#13475 ·
-
[BUG]: "Clear All" in Settings doesn't clear the saved analysis, old data comes back after reload Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
AOSSIE-Org/OrgExplorer#253 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
oxc-project/oxc#26944 ·
-
ai-observability bug team/ai-observability
Difficulty 2/5 1-3 hours Newbie friendliness 78/100