http: match subdomains for plain NO_PROXY entries by dibenkobit · Pull Request #65617 · nodejs/node

dibenkobit · 2026-08-28T12:45:58Z

NO_PROXY=example.com only exact-matched the hostname in the
http/https built-ins, so requests to subdomains still used the proxy.
Make plain domain entries match the host and its subdomains, as fetch()
already does, while preserving a label boundary.

The new plain-entry suffix match ignores empty entries and only applies
when both the entry and request host are not IP literals. Existing
leading-dot and wildcard behavior is unchanged.

Fixes: #65616
Refs: #57872
Assisted-by: Grok 4.6 Extra High
Assisted-by: Fable 5

cc @nodejs/http

NO_PROXY=example.com only exact-matched the hostname in the http(s) builtins, so requests to subdomains still used the proxy. fetch() already matches the host and its subdomains. Reuse the existing suffix matcher (label boundary) for plain entries as well as leading-dot ones. Fixes: nodejs#65616 Assisted-by: Grok 4.6 Extra High Signed-off-by: Nikita Snetkov <lukyanish@gmail.com>

nodejs-github-bot · 2026-08-28T12:46:04Z

Review requested:

@nodejs/http
@nodejs/net

codecov · 2026-08-29T19:27:29Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.06%. Comparing base (9f04fcd) to head (b19633f).
⚠️ Report is 33 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #65617      +/-   ##
==========================================
- Coverage   90.07%   90.06%   -0.01%     
==========================================
  Files         751      751              
  Lines      254916   254918       +2     
  Branches    48133    48129       -4     
==========================================
- Hits       229605   229588      -17     
- Misses      16496    16498       +2     
- Partials     8815     8832      +17

Files with missing lines	Coverage Δ
lib/internal/http.js	`92.36% <100.00%> (+0.02%)`	⬆️

... and 34 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

inoway46 · 2026-08-30T05:34:59Z

-        const suffix = entry.substring(1);
+      // Strip a leading "." if present, then match as a suffix with a
+      // label boundary. "*.example.com" is handled below (subdomains only).
+      if (!entry.startsWith('*.')) {


Could we limit suffix matching to domain entries?
As written, NO_PROXY=127.0.0.1 also bypasses foo.127.0.0.1, although IP entries are documented as exact matches. Empty entries from trailing commas can also match hostnames ending in a dot.

Sure, will look into that

Updated in the latest fixup to keep the change scoped to plain entries:

The new suffix match ignores empty entries, so an empty entry from a
trailing comma cannot match a hostname ending in a dot.

It only applies when both the entry and request host are not IP
literals, so NO_PROXY=127.0.0.1 does not match foo.127.0.0.1.

Existing leading-dot and wildcard behavior is unchanged. Both cases are
covered by regression tests.

inoway46 · 2026-08-30T05:40:11Z

+
+  // The request should go through the proxy (not bypass it),
+  // because badexample.com is not a subdomain of example.com.
+  assert.match(stdout, /Status Code: 200/);


This test seems to pass whether the proxy is used or bypassed, since both paths reach the same server. Could we also assert that the custom lookup for badexample.com was not used?
For example:

assert.doesNotMatch( stdout, /Resolving lookup for badexample\.com/, );

Nice catch, will fix

Added it to all three negative blocks

Limit NO_PROXY suffix matching to domain entries and domain hosts: - drop empty entries (e.g. from trailing commas) at parse time, so they can no longer match hostnames ending with a dot - IP entries only match a host exactly; IP hosts can only be bypassed by exact IP, IP:port, or IP range entries - degenerate "." and "*." entries no longer match every host ending with a dot Assisted-by: Claude Fable 5 Signed-off-by: Nikita Snetkov <lukyanish@gmail.com>

Assert that the negative NO_PROXY domain tests actually go through the proxy: both paths return 200 from the same server, so assert on the absence of the custom lookup log line instead. Assisted-by: Claude Fable 5 Signed-off-by: Nikita Snetkov <lukyanish@gmail.com>

Reword the NO_PROXY IP-matching note: the previous wording contradicted the IP range and host:port forms listed above it. Assisted-by: Claude Fable 5 Signed-off-by: Nikita Snetkov <lukyanish@gmail.com>

Keep the change scoped to plain domain entries. Preserve the existing leading-dot and wildcard behavior, while preventing the new suffix match from applying to empty entries or IP literals. Signed-off-by: Nikita Snetkov <lukyanish@gmail.com>

mcollina · 2026-09-01T15:18:44Z

@@ -4615,7 +4619,7 @@ Proxy URLs can use either HTTP or HTTPS protocols:
 The `NO_PROXY` environment variable supports several formats:

 * `*` - Bypass proxy for all hosts
-* `example.com` - Exact host name match
+* `example.com` - Host and subdomain match (matches `sub.example.com`)
 * `.example.com` - Domain suffix match (matches `sub.example.com`)


This would make example.com and .example.com match. This does not seem something we might want to do

nodejs-github-bot added http Issues and PRs related to the http subsystem. needs-ci PRs that need a full CI run. labels Aug 28, 2026

inoway46 reviewed Aug 30, 2026

View reviewed changes

dibenkobit added 3 commits September 1, 2026 11:09

fixup! http: match subdomains for plain NO_PROXY entries

15fa397

Reword the NO_PROXY IP-matching note: the previous wording contradicted the IP range and host:port forms listed above it. Assisted-by: Claude Fable 5 Signed-off-by: Nikita Snetkov <lukyanish@gmail.com>

dibenkobit marked this pull request as draft September 1, 2026 12:45

dibenkobit force-pushed the http-no-proxy-suffix branch from af34dc3 to 8af581d Compare September 1, 2026 12:57

dibenkobit force-pushed the http-no-proxy-suffix branch from 8af581d to 09d37d4 Compare September 1, 2026 13:44

dibenkobit marked this pull request as ready for review September 1, 2026 13:44

dibenkobit requested a review from inoway46 September 1, 2026 13:44

dibenkobit mentioned this pull request Sep 1, 2026

Tracking issue: HTTP_PROXY/HTTPS_PROXY/NO_PROXY support in Node.js #57872

Open

13 tasks

mcollina requested review from joyeecheung and removed request for inoway46 September 1, 2026 15:17

mcollina reviewed Sep 1, 2026

View reviewed changes

Navigation Menu

Uh oh!

Uh oh!

http: match subdomains for plain NO_PROXY entries - #65617

http: match subdomains for plain NO_PROXY entries#65617
dibenkobit wants to merge 5 commits into
nodejs:mainfrom
dibenkobit:http-no-proxy-suffix

dibenkobit commented Aug 28, 2026 •

edited

Loading

Uh oh!

nodejs-github-bot commented Aug 28, 2026

Uh oh!

codecov Bot commented Aug 29, 2026

Uh oh!

inoway46 Aug 30, 2026

Uh oh!

dibenkobit Aug 30, 2026

Uh oh!

dibenkobit Sep 1, 2026 •

edited

Loading

Uh oh!

inoway46 Aug 30, 2026

Uh oh!

dibenkobit Aug 30, 2026

Uh oh!

dibenkobit Sep 1, 2026

Uh oh!

mcollina Sep 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

dibenkobit commented Aug 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nodejs-github-bot commented Aug 28, 2026

Uh oh!

codecov Bot commented Aug 29, 2026

Codecov Report

Uh oh!

inoway46 Aug 30, 2026

Choose a reason for hiding this comment

Uh oh!

dibenkobit Aug 30, 2026

Choose a reason for hiding this comment

Uh oh!

dibenkobit Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

inoway46 Aug 30, 2026

Choose a reason for hiding this comment

Uh oh!

dibenkobit Aug 30, 2026

Choose a reason for hiding this comment

Uh oh!

dibenkobit Sep 1, 2026

Choose a reason for hiding this comment

Uh oh!

mcollina Sep 1, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dibenkobit commented Aug 28, 2026 •

edited

Loading

dibenkobit Sep 1, 2026 •

edited

Loading