You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proxy assumes server can bind to IPv6 when specifying localhost #2330
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.
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.
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.
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.
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.
@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.
Activity
Timer commentedon May 22, 2017
Can you downgrade to 1.0.4 and try?
Timer commentedon 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 commentedon 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 commentedon May 22, 2017
What does your
proxyconfig look like?Timer commentedon May 22, 2017
[::1]is the IPv6 equivalent oflocalhost.@tomjal can you try changing your
proxyproperty fromlocalhostto127.0.0.1?What host are you binding to with your application running on
5000?If your application on
5000is binding to127.0.0.1and you're specifyinglocalhostin yourproxy, this is expected to not work.tomjal commentedon 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
Timer commentedon 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.
[-]Proxy not working in version 1.0.x ?[/-][+]Proxy assumes server can bind to IPv6 when specifying localhost[/+]Timer commentedon May 22, 2017
What version of .NET core are you on? This announcement seems relevant: aspnet/Announcements#185.
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 commentedon 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 fromlocalhostto127.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 commentedon 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.pyconnects tolocalhostbut 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 commentedon May 23, 2017
I went ahead and did some testing on Windows.
So it seems that
localhostis 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 commentedon 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 commentedon May 24, 2017
This should be fixed in 1.0.6.
https://github.com/facebookincubator/create-react-app/releases/tag/v1.0.6
uvtzxpm commentedon May 24, 2017
@Timer I can confirm that using
localhostworks for me using 1.0.6, thanks.