// the find
chimurai/http-proxy-middleware
:zap: The one-liner node.js http-proxy middleware for connect, express, next.js and more
The standard solution for proxying HTTP requests in Node.js middleware stacks. If you're running Express or Next.js and need to route /api calls to a backend service during development — or in production — this is what you reach for. It recently migrated its underlying engine from the abandoned http-proxy to httpxy (the unjs fork), which keeps it alive.
Migrating to httpxy was the right call — http-proxy was effectively dead and this keeps the project on a maintained foundation. The plugin system is genuinely well-designed: you can eject the defaults and compose exactly what you want without monkey-patching internals. The responseInterceptor helper handles brotli/gzip/deflate decompression automatically before handing you a buffer, which saves real boilerplate. Test coverage is thorough — e2e specs against actual HTTP servers, not mocked responses.
The IPv6/localhost ECONNREFUSED footgun (Node 17+) is documented but not fixed; it's a sharp edge that bites developers immediately and the suggested fix ('just use 127.0.0.1') feels like a shrug. responseInterceptor disables streaming, which means you can't use it on large file proxies without buffering the entire response in memory — this is a hard limitation, not a config option. The router and pathRewrite APIs accept both objects and functions but combine poorly: using both together in non-obvious order creates silent precedence bugs that are hard to debug. WebSocket proxying with ws: true on multiple server instances requires manual upgrade wiring per server, which the docs bury in a footnote.