Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Localhost no longer works for devServer proxy. #4828

Closed
Spedwards opened this issue Apr 22, 2023 · 6 comments
Closed

Localhost no longer works for devServer proxy. #4828

Spedwards opened this issue Apr 22, 2023 · 6 comments

Comments

@Spedwards
Copy link

Spedwards commented Apr 22, 2023

Bug report

Dev Server proxy targets no longer accept localhost as a valid option. After upgrading to v4, I have had to switch from localhost to 127.0.0.1 which is the same thing so it makes no sense.

There was nothing about this included in the v4 migration post which leads me to believe this is a bug.

Actual Behaviour

When making HTTP requests (through axios) to my server backend, I get proxy errors. These are the exact same errors I get when the server isn't even running. Upon switching the target to 127.0.0.1, it works.

Proxy error: Could not proxy request /api/v1/settings from localhost:8080 to http://localhost:3333.
See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (ECONNREFUSED).

Expected Behaviour

I honestly don't know how to explain the expected behaviour as I'm not entirely sure why it's not working to begin with. HTTP requests should connect to the server and only throw this error if the server cannot be found. localhost and 127.0.0.1 are synonymous so working on one and not the other makes zero sense.

How Do We Reproduce?

I am using webpack-dev-server through vue-cli, but upon asking for help from them, I was informed that they pass these settings along to webpack and it's not handled by Vue. That said, here are my settings:

module.exports = {
	devServer: {
		proxy: {
			'/api': {
				target: 'http://127.0.0.1:3333',
			},
			'/uploads': {
				target: 'http://127.0.0.1:3333',
			},
		},
	},
}

I then have an Axios instance:

axios.create({ baseURL: '/api/v1', timeout: 3000 })

All HTTP requests go through that.

Please paste the results of npx webpack-cli info here, and mention other relevant information

$ npx webpack-cli info

  System:                                                     
    OS: Windows 10 10.0.19045                                 
    CPU: (8) x64 Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz     
    Memory: 14.90 GB / 31.92 GB                               
  Binaries:                                                   
    Node: 18.16.0 - ~\.nvm\versions\node\v18.16.0\bin\node.EXE
    Yarn: 1.22.4 - C:\Program Files (x86)\Yarn\bin\yarn.CMD   
    npm: 9.5.1 - ~\.nvm\versions\node\v18.16.0\bin\npm.CMD    
  Browsers:                                                   
    Chrome: 112.0.5615.138                                    
    Edge: Spartan (44.19041.1266.0), Chromium (112.0.1722.48) 
    Internet Explorer: 11.0.19041.1566                        
  Packages:                                                   
    sass-loader: ^8.0.2 => 8.0.2 
@alexander-akait
Copy link
Member

Can you create reproducible example?

@IsaaX
Copy link

IsaaX commented Apr 27, 2023

I can confirm this as well. The issue with me was that I was in the process of upgrading my nodejs v14.20 -> nodejs 18.14.2

This was the version of webpack dev server I was using

"webpack-dev-server": "^4.13.3",

using nvm use 14.20 then running my webpack server with no webpack config changes I would run the server successfully.

Then doing
nvm use 18.14.2
with no webpack config changes, the server would stop working.

The only thing that seemed to fix it was
changing localhost to 127.0.0.1

I'm not familiar what could be the reason for this behavior however I hope this helped in some way.

I appreciate this post, thanks for giving me a workaround solution in the meanwhile

@snitin315
Copy link
Member

@IsaaX Can you share a minimal reproduction repo?

@chimurai
Copy link
Contributor

Sounds like this nodejs 17 change (nodejs/node#39793):

"dns: runtime deprecate type coercion of dns.lookup options"

TL;DR

Node.js 17+ no longer prefers IPv4 over IPv6 for DNS lookups. E.g. It's not guaranteed that localhost will be resolved to 127.0.0.1 – it might just as well be ::1 (or some other IP address).

https://github.com/chimurai/http-proxy-middleware#nodejs-17-econnrefused-issue-with-ipv6-and-localhost-705

Most likely related to upgrading node v16 or lower to node v17 or higher.

@bradzacher
Copy link

bradzacher commented Jul 11, 2023

That Node17 change causes a lot of problems around the place, sadly.
The issue right now is that webpack-dev-server currently relies on Node's internal dns resolution for localhost - which means that servers run in Node16 will bind to ipv4, and servers run in Node17+ will bind to ipv6.

This causes issues because not all environments will resolve localhost to ipv6 by default (few will) and can be a problem if someone configures a client to connect to 127.0.0.1 instead of localhost (which will ofc fail).

I think the best course of action is to update webpack-dev-server so that it does a dns.lookup on the provided host so that it resolves all possible IPs for that hostname and tries to bind to all of them.

Or at least - do this specifically for the localhost case.

Simple example code that could be used:

const dns = require('dns');
const addresses = /** @type {import('dns').LookupAddress[]} */ (await new Promise((resolve, reject) =>
  dns.lookup('localhost', { all: true }, (error, addresses) => {
    if (error) {
      reject(error);
    } else {
      resolve(addresses);
    }
  }),
));
for (const {address} of addresses) {
  // bind to address
}

It looks like this isn't a super simple problem to solve in the codebase though because it would involve spinning up two separate servers - because one http server cannot listen to two addresses at once.

@alexander-akait
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants