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

Proxy assumes server can bind to IPv6 when specifying localhost #2330

Closed
tomjal opened this issue May 22, 2017 · 14 comments
Closed

Proxy assumes server can bind to IPv6 when specifying localhost #2330

tomjal opened this issue May 22, 2017 · 14 comments
Milestone

Comments

@tomjal
Copy link

tomjal commented May 22, 2017

I updated from 0.9.5 to 1.0.5 and it says that:

"Proxy error: Could not proxy request /ui_host/api/v1/account/context from localhost:3000 to http://[::1]:5000/."

Any ideas?

@Timer
Copy link
Contributor

Timer commented May 22, 2017

Can you downgrade to 1.0.4 and try?

@Timer
Copy link
Contributor

Timer commented May 22, 2017

Normally, this error would mean that your server is not running on http://[::1]:5000/. Are you sure your server is running?

@tomjal
Copy link
Author

tomjal commented May 22, 2017

Im 100% sure that server works and is running properly. Im not sure what this [::1] means? My package.json has "proxy": "http://localhost:5000"

@gaearon
Copy link
Contributor

gaearon commented May 22, 2017

What does your proxy config look like?

@Timer
Copy link
Contributor

Timer commented May 22, 2017

[::1] is the IPv6 equivalent of localhost.

@tomjal can you try changing your proxy property from localhost to 127.0.0.1?
What host are you binding to with your application running on 5000?

If your application on 5000 is binding to 127.0.0.1 and you're specifying localhost in your proxy, this is expected to not work.

@tomjal
Copy link
Author

tomjal commented May 22, 2017

@Timer you were right, it works with 127.0.0.1. The server is .NET Core Kestrel and for some reason it does not work with IPv6. Thanks

@tomjal tomjal closed this as completed May 22, 2017
@Timer
Copy link
Contributor

Timer commented May 22, 2017

I'm going to reopen this because I think we can make this smarter.
We resolve localhost to IPv6 because normally that's what it is, but that is obviously painful for servers that don't support it.
I think we should act more in line with the underlying network and try both, or only perform this resolution when you're offline.

@Timer Timer reopened this May 22, 2017
@gaearon gaearon added this to the 1.0.x milestone May 22, 2017
@Timer Timer changed the title Proxy not working in version 1.0.x ? Proxy assumes server can bind to IPv6 when specifying localhost May 22, 2017
@Timer
Copy link
Contributor

Timer commented May 22, 2017

What version of .NET core are you on? This announcement seems relevant: aspnet/Announcements#185.

Configuring Kestrel to bind to localhost used to only bind to the IPv4 loopback interface. This caused confusion among users, especially those putting Kestrel behind reverse proxies that would see failures or delays because the proxies where trying to establish an IPv6 connection to Kestrel on localhost.

Seems like in >=1.0.0 they fixed their bug and bind to [::1] as well. If they don't, this may be a regression on their part.

@uvtzxpm
Copy link

uvtzxpm commented May 22, 2017

For what it's worth, I had exactly the same problem with a Google App Engine (dev_appserver.py) backend. I fixed it by changing the proxy from localhost to 127.0.0.1, as already suggested.

There might be other strange and wonderful servers that people are using that can be affected by this.

@Timer
Copy link
Contributor

Timer commented May 23, 2017

While inspecting these individual cases, it's amazing how deep into the rabbit hole you can go.

In @uvtzxpm's case, dev_appserver.py connects to localhost but Python 2 by default doesn't enable IPv6 (you have to configure it with --enable-ipv6; Python 3 has it on by default afaik).

Most of this testing was done with Node servers on windows which do support IPv6.

@Timer
Copy link
Contributor

Timer commented May 23, 2017

I went ahead and did some testing on Windows.

So it seems that localhost is resolvable as long as you're on a network, but not necessarily online.
Since this is the case, we don't really want to resolve localhost to something else if we're not on a network.

If we're not on a network, we are going to be super safe and assume 127.0.0.1.

See #2332.

@Timer
Copy link
Contributor

Timer commented May 23, 2017

@uvtzxpm can you manually patch your files with that PR and make sure it works when you switch back to localhost?
@tomjal would appreciate if you could try too.

@gaearon
Copy link
Contributor

gaearon commented May 24, 2017

@uvtzxpm
Copy link

uvtzxpm commented May 24, 2017

@Timer I can confirm that using localhost works for me using 1.0.6, thanks.

@lock lock bot locked and limited conversation to collaborators Jan 21, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants