-
Notifications
You must be signed in to change notification settings - Fork 530
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
Try all available addresses when connecting to localhost (127.0.0.1 and ::1) #1602
Comments
I don't quite understand what localhost has to do with this issue? In #1248 no localhost was involved. |
This issue is based on this comment: #1248 (comment). There is something we could improve with |
FWIW I'm getting this when running I think this should work as a way to get the stack traces quickly: |
Note: this is better solved in nodejs core. nodejs/node#41625 |
Hi @mcollina, seems like this haven't been assigned/implemented yet? |
would this fix nodejs/node#44731 solve this issue? |
Yes, we'd need to enable that setting once it lands. |
Should we enable it by default? Agents should be able to set this option already, under |
I faced this issue today in native fetch (v19.5.0) , I had to replace |
this worked for me using native fetch (v18.7.0) inside a |
Surprisingly, switching from one to the other worked for me. Thanks. |
@mcollina |
In node v17 (specifically nodejs/node#39987), we switched the default ordering of dns entries to follow what the OS is providing us vs reordering to put IPv4 addresses always first. This creates quite a few issues for folks as some tools only listen to
127.0.0.1
and not::1
.I think we should try multiple addresses when dealing with localhost when establishing a new connection.
Originaklly reported as #1248.
The text was updated successfully, but these errors were encountered: