-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
ConnectionRefused when fetch()
is localhost
#1425
Comments
I used to hardcode localhost to 127.0.0.1 as a workaround, but it's not great since technically the OS could have rewritten localhost to anything else @uNetworking do you have any ideas? |
Fixed in Bun v0.7.1 |
Still have this issue on 0.7.3 for localhost:8000 |
On 1.0.0 same error |
I have the same error on 1.0.0 |
Could this be related with my Next.js dev with
|
I have the same issue with the following: Gives the output:
EDIT 2023-10-09 |
Using 127.0.0.1 works as a workaround. |
Edit: this is incorrect, the server will begin on the tick after it has started the code snippet in the issue is technically wrong. export default {
port: 4281,
fetch(request) {
return new Response("Ok");
}
}
console.log(await fetch("http://localhost:4281/hello")) when you use export default to start a server, it will only start after the module is finished evaluating, so you cannot top-level-await a fetch here. Bun.serve({
port: 4281,
fetch(request) {
return new Response("Ok");
},
});
console.log(await fetch("http://localhost:4281")); This works for me on Linux and MacOS. Can someone test this on WSL? |
I wonder if the issue is that Bun is defaulting to an IPv6 connection for localhost, but there's no entry for You could try adding this to
|
@markstos I already have /etc/hosts entry for IPv6 localhost and unfortunately it still does not work. |
Having the same issue and can’t really use Bun on any of my projects because of this. Is there something I can do to help debug this? |
I think this has been solved with 1.0.4, at least for me. Give it a try |
Unfortunately not for me. It says, |
@nCrafts You can checkout the Bun project and review the related test coverage and then add a new failing test which triggers this failure: https://github.com/oven-sh/bun/blob/main/test/js/web/fetch/fetch.test.ts There are already some tests for |
In my case, it seems to happen intermittently when the express res object closes |
Related issue on
console.log("fetching projects");
const request = await fetch("https://git.syonet.com/api/v4/projects", {
headers: {
"Private-Token": "< my private token >",
},
});
const projects = await request.json();
console.table(projects); output: ConnectionRefused: Unable to connect. Is the computer able to access the url?
path: "https://git.syonet.com/api/v4/projects" |
I can confirm the problem with |
any update? |
Still broken on 1.0.27. Example of
|
Can confirm replacing |
Make requests to Notes: |
Still happening on |
Still happening |
1 similar comment
Still happening |
Same on 1.1.1:
Fixed by replacing localhost with 127.0.0.1 |
Same on 1.1.x:
|
Oh wow. Connecting to |
Still happening. |
Happens on 127.0.0.1 as well |
Used the latest version |
@Jarred-Sumner maybe you can check this out? |
is there a temporary workaround for this? We've been experiencing this issue in production (under v1.1.8), the server randomly fails to resolve url and throws |
@schulzf if you can use |
@Jarred-Sumner in our case is a not localhost but a live url (and it doesn't support ipv6). Is there a way to disable ipv6 in bun? (we're running under Cloud Run, we can't access the underlying system configuration) Edit: Will try using axios with custom http agent
|
Fixed in Bun v1.1.9 |
I am still having the same problem on Bun v.1.1.12 using localstack and trying to upload an image to s3
Error:
As comented in the thread, changing it to 0.0.0.0 or 127.0.0.1 makes it work, but not ideal |
not sure what I'm doing wrong but I can't seem to make bun fetch, neither using 0.0.0.0 or 127.0.0.1. tried everything spoken in this thread so far 🙄 |
holy moly, I figured out my problem. the issue is that I needed to fetch between containers, so nothing worked until I tried |
Has this been tested with local TLS (Caddy server) as well? I am able to visit this URL using cURL but not with Bun. > await fetch('https://test.localhost/api/v2/portal/funnels/1/')
ConnectionRefused: Unable to connect. Is the computer able to access the url?
path: "https://test.localhost/api/v2/portal/funnels/1/" |
TLS turns out not to be the issue... instead, localhost subdomains ( |
Hello, if for some reason when you try to access a registry file the connection fails, it gives an error of connection refused and not installed. Connection errors will not be recovered. The only way out in this case is to persist. This error is more likely to be detected if the json file that tries to access and fails is different in each attempt, especially if many components are installed at once. |
Still happening at v1.1.21 |
@MichaelYuhe Please fill out a new issue referencing this one and providing information on how to replicate and the versions of bun and OS. |
I cannot determine whether the issue is with the server or with Bun, as I have encountered the same problem when using other URLs. I am using a URL similar to http://oa.xxxx.com, and I am in a production environment. |
If you don't provide the exact url or another url at which this happens we can't help. |
I'm sorry, I should have considered that it might be a server issue, because normally there wouldn't be any mistakes. Thank you! |
If you're continuing to run into an issue like this, please open a new issue with a complete reproduction |
What version of Bun is running?
0.2.2
What platform is your computer?
Darwin 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 20:57:23 PDT 2022; root:xnu-8020.121.3~2/RELEASE_ARM64_T8110 arm64 arm
What steps can reproduce the bug?
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior?
No response
What do you see instead?
The above code fails with the error:
Additional information
No response
The text was updated successfully, but these errors were encountered: