Sitelet https://github.com/nodejs/node/issues/43187
Skip to content

Expose Undici's ProxyAgent and setGlobalDispatcher within Node #43187

Description

@pimterry

Originally posted by @pimterry in #42814 (comment)

As a motivating example: I'd love to automatically support global Fetch in https://www.npmjs.com/package/global-agent (drop-in lib to make all Node HTTP use the system proxy) but even though Node bundles Undici AFAICT this isn't possible without adding a full separate Undici dep to that lib, which would more than double its size, just [EDIT: largely] to ship code that's already present in Node itself.

This would be immediately solved if ProxyAgent and setGlobalDispatcher were exposed explicitly somewhere in future.

I've just done a quick test on main in Undici: exposing ProxyAgent & setGlobalDispatcher explicitly increases the Undici bundle size from 334.2kb to 336.0kb (+1.8kb / +0.5%).

Could these APIs be included and exposed in future? Agents for HTTP are a very core API that it would be useful to have usable out of the box, the equivalent functionality is usable OOTB for the legacy http module APIs, and 2kb is not a significant jump in bundle size for this functionality.

Activity

  1. targos commented on May 23, 2022

    @targos
    Member

    setGlobalDispatcher is exposed:

    global[Symbol.for('undici.globalDispatcher.1')] = yourDispatcher;
  2. pimterry commented on May 23, 2022

    @pimterry
    MemberAuthor

    Replying to the last comment from @mcollina in the previous issue:

    I would recommend opening up a separate issue about this topic and bringing it to the TSC. I don't think the whole of Undici has the stability guarantees needed to be part of the Node.js LTS cycle yet.

    This makes sense! I'm not aware of Undici's process around stability guarantees like this, but I can understand how there are constraints there.

    I do understand this isn't a top top priority since installing & importing Undici elsewhere is a usable workaround, so there's certainly no rush just would justify shipping an unstable API unnecessarily. I do think that the current situation isn't a good end state though, and there are good options we can aim for to fix this, so it would be great to find agreement to aim in that direction in the medium term.

    I'm not sure how to take anything to the TSC, but very happy to be included on any discussion of this any time.

  3. pimterry commented on May 23, 2022

    @pimterry
    MemberAuthor
    global[Symbol.for('undici.globalDispatcher.1')] = yourDispatcher;

    That's does work as a workaround, but it's not especially nice as the official API for this, and I think ProxyAgent needs to be available too to make this usable for global Fetch.

  4. mcollina commented on May 23, 2022

    @mcollina
    SponsorMember

    I don't think we should expose undici further until we want to consider fetch as stable.

  5. frank-dspeed commented on May 24, 2022

    @frank-dspeed
  6. mcollina commented on May 24, 2022

    @mcollina
  7. sosoba commented on Dec 5, 2022

    @sosoba
    Contributor

    @mcollina
    I don't think we should expose undici further until we want to consider fetch as stable.

    2022-11-14, Version 19.1.0

  8. mcollina commented on Dec 5, 2022

    @mcollina
    SponsorMember

    That does not mark it stable, on purpose. It's the first step on that journey. This is something we might want to consider right now.

  9. added
    tsc-agendaIssues and PRs to discuss during Technical Steering Committee meetings.
    on Dec 5, 2022
  10. mcollina commented on Jan 18, 2023

    @mcollina
    SponsorMember

    In the TSC meeeting of today, we decided that we are going to support HTTP_PROXY, HTTPS_PROXY and NO_PROXY env variables directly in Undici: nodejs/undici#1650.

  11. removed
    tsc-agendaIssues and PRs to discuss during Technical Steering Committee meetings.
    on Jan 18, 2023
  12. GabenGar commented on Jan 18, 2023

    @GabenGar

    How is it going to handle different casing rules?

  13. JasonKleban commented on Nov 15, 2023

    @JasonKleban

    setGlobalDispatcher is exposed:

    global[Symbol.for('undici.globalDispatcher.1')] = yourDispatcher;

    Is there a workaround to obtain ProxyAgent?

  14. 48 remaining items

  15. removed
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Aug 13, 2025
  16. metcoder95 commented on Oct 31, 2025

    @metcoder95
    Member

    @mcollina is exposing some undici internals still in the plan? Couldn't find the tracking issue from the last collab summit

  17. tmccombs commented on Nov 19, 2025

    @tmccombs

    Is there currently any workaround to set proxy settings for specific requests that doesn't involve adding a dependency on undici?

  18. github-actions commented on Jun 25, 2026

    @github-actions
    Contributor

    This issue has been marked as stale due to 210 days of inactivity.
    It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

  19. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jun 25, 2026
  20. hyrious commented on Jun 25, 2026

    @hyrious

    Would http.setGlobalProxyFromEnv([env]) solve this issue?

  21. tmccombs commented on Jun 25, 2026

    @tmccombs

    @hyrious that doesn't solve my use case, because I need to use a proxy for some requests, but not all of them, so I can't set proxy settings globally.

  22. hyrious commented on Jun 25, 2026

    @hyrious

    @tmccombs I see. I just searched for the implementation of fetch dispatcher and found that the dispatcher was captured instantly on calling fetch, so in theory there's a hacky way to make proxy happen per fetch without adding a new dependency:

    async function fetchWithTemporaryGlobalProxy(url, init, proxyEnv) {
      const restore = setGlobalProxyFromEnv(proxyEnv);
    
      try {
        return fetch(url, init);
      } finally {
        restore();
      }
    }

    This is bound to the implementation so not that stable.

  23. removed
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jun 26, 2026
  24. thw0rted commented on Jun 29, 2026

    @thw0rted
  25. github-actions commented on Sep 28, 2026

    @github-actions
    Contributor

    This issue has been marked as stale due to 90 days of inactivity.
    It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

  26. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Sep 28, 2026
  27. mbrevda commented on Sep 28, 2026

    @mbrevda

    nostale

  28. removed
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Sep 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestIssues requesting new Node.js features.

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions