Localhost

[rfoel]

Does bruno work on localhost? I keep getting the following error when I send a request:

Error invoking remote method 'send-http-request': Error: connect ECONNREFUSED 127.0.0.1:3000

PS: My local server is running, I can call it with Insomnia, but not with bruno.

I'm on a Mac M1.

[helloanoop]

@rfoel Apologies for checking on this late.

I was able to hit localhost on my machine. I am using a Macbook Air and the bruno version is v0.10.1

Can you confirm if you are still facing the same issue? Which OS and which version of bruno are you currently on ?

[rfoel]

I have Bruno v0.10.2 installed and macOS Ventura 13.1. I recorded a video with the issue.

https://user-images.githubusercontent.com/19496473/226332899-67d3ff18-f3dd-457c-88b4-1ae029670aa8.mov

[helloanoop]

@rfoel Can you confirm that curl works curl -X POST -d '{"email": "rfoelf@gmail.com"}' http://localhost:3000/otp/request

[rfoel]

@helloanoop yes it works fine.

[helloanoop]

Hey @rfoel !

Hope you are doing great!

It has been sometime. No one else from the community has reported this issue. There seems to be something on your machine that is preventing access to localhost from Bruno.

Can you install the latest version from website and check if the issue persists ?

[rfoel]

Same error. I'm not really sure what's happening. Postman and Insomnia work fine on my machine.

Error invoking remote method 'send-http-request': Error: connect ECONNREFUSED 127.0.0.1:3000

[fabioduque]

@rfoel Did you try to check if you have any firewall rule specific for Bruno, which might be blocking it? If curl, Postman and Insomnia work, then it seems to be some rule only affecting Bruno.

After reading your issue, I wanted to test that, so on my MBP M1, I've blocked Bruno using LuLu and I got the same error you have.

Maybe you can also try to remove the app and reinstall it.

[fabioduque]

Ok, sorry, disregard the part about LuLu.

It is not blocking my connection to localhost after all.

After setting the rule, I've closed Bruno, and when I opened it again, it didn't select my correct environment so my {{baseUrl}} was not being populated, hence the connection error. Sorry about that.

LuLu affects an external connection though...

[julianhirt]

I do have the same issue not using LuLu

[fabioduque]

Ironically, for some reason, I started to get the same issue as @rfoel: Error invoking remote method 'send-http-request': Error: connect ECONNREFUSED 127.0.0.1:3000

It should have nothing to do with the firewall / LuLu, as I stated on my previous post.

I can make external requests (google.com, for example), but localhost stopped being reachable. I have uninstalled Bruno (and all associated files in ~/Library), reinstalled and got the same behaviour. I even tried to put the collection in another unrelated folder.

One minute it was working, the other it wasn't. My only change was to add Nuxt devtools in the project I was testing before. I have disabled the devtools, just to see if it had some impact, to no avail.

I have created a new Nuxt project (no devtools) and the result was the same.

What I found is that if I run npm run dev (which runs nuxt dev), Bruno throws the error. If I run nuxt dev --host, to also expose to the network, suddenly it works. This worked on both projects (the already existing one and the new I created for testing).

It doesn't make any sense to me, since it was working even before the --host flag, but for now it's a workaround I'll have to use.

I'm using Nuxt is 3.7.4, and my node version is 18.15. I'm also using nvm, if that matters to other users that might have this.

If anyone has some thoughts on this, it would be appreciated.

[rfoel]

I've made some discoveries. In a project running an express app with docker, bruno seems to work with localhost. My problem still persists when I use serverless-offline though, so the problem might be something between this package and bruno.

[Epick362]

Experiencing the same with serverless-offline and Bruno :(

{
    "serverless": "^3.35.2",
    "serverless-offline": "13.2.0"
}

[julianhirt]

Personal update: My issue disappeared after upgrading to Mac OSX Sonoma. Can't reproduce it anymore.

[rfoel]

I guess the issue is specific with serverless-offline and bruno. Other IDE work fine with it, but bruno has something missing.

[fabioduque]

@rfoel I'm not using serverless-offline and also had that issue, so it's not tied to that explicitly.

I am just using Nuxt 3 (Vue 3), which starts everything with vite. It might be something in common, of course.

Luckily, I have updated Bruno and my issue disappeared (meaning that I don't need to use --host option when starting Nuxt).

Btw, concerning Mac OSX Sonoma that @julianhirt mentioned, I had already upgraded when I had the issue with Bruno, so at least for me, Sonoma didn't solve it.

[jrc03c]

Hey, all! I'm on Linux Mint 21.2 (which I think is built on Ubuntu 22.04 LTS), and I'm seeing a similar error, except mine's happening on port 80:

I haven't modified any configurations or preferences or anything. I literally just installed Bruno a few minutes ago and tried making my first request — and this was the first thing I saw. (And I tried it several more different ways and got the same result each time.)

[helloanoop]

@jrc03c @fabioduque Is the issue unique to localhost or is it happening for public apis too? We will be introducing logging very soon that will write stack traces into a file. Hoping that gets us closer to the root cause of the issue.

[fabioduque]

@helloanoop for me it was only happening on loopback (localhost or 127.0.0.1) As soon as I added the --host flag which makes it accessible via IP (192.168.1.x, for example), it worked.

And also remember that for me, in the beginning it worked even without the --host. Then suddenly it stopped working and after I updated Bruno, it started to work again!

Super weird and I know that I'm not being very helpful with this info, because you won't be able to replicate or debug... If it happens again, I'll share more info.

[ajcarrillo]

Hi. I'm getting the same error on Windows in both the installable and portable versions v0.23.0. I added the app to allow it in Windows firewall but that didn't work.

[skyd0me]

Same for me. Everything works fine with remote urls. If I use http://localhost:8080, I see the above mentioned error message. Running on Windows 11 with v0.23.0 (portable version). I can call the same api in chrome, postman, insomnia so I guess not a general "machine" problem

[skyd0me]

ok I could track it down to a wsl2 issue. My backend application is running within wsl2 and looks like bruno was not able to call this endpoint via http://localhost or http://127.0.0.1 But if I use http://[::1] --> IPv6 everything starts working. Need to check how I can adjust my wsl2 config, But it's still strange why this is an issue for bruno and not for postman etc. Maybe they have configured a fallback to IPv6, which is missing for bruno? Just a thought :-)

[austinwilcox]

So I am running into the same error as everyone here, in my case I think I know what the issue is, local ssl certs. I have set up local ssl certs with dotnet before on linux, but it was a bit of a bear. I will test that and report back if creating a self signed ssl cert will fix the issue with Bruno.

[helloanoop]

@austinwilcox Have you tried disabling SSL check in preferences..You can open preferences by clicking on the gear icon on the left bottom of the screen

[austinwilcox]

@helloanoop That fixed the issue for me! Thank you. Glad you got me before I dove into the bear of ssl certs and dotnet apps on linux.

[zarnautovic]

I have same issue with WSL2. my app is running on wsl2 and bruno is not able to make request. Postman is working fine. Even browser is is working without problem. Someone know how to make it work ?

Error is: Error invoking remote method 'send-http-request': Error: connect ECONNREFUSED 127.0.0.1:3000

[rfoel]

ok I could track it down to a wsl2 issue. My backend application is running within wsl2 and looks like bruno was not able to call this endpoint via http://localhost or http://127.0.0.1 But if I use http://[::1] --> IPv6 everything starts working. Need to check how I can adjust my wsl2 config, But it's still strange why this is an issue for bruno and not for postman etc. Maybe they have configured a fallback to IPv6, which is missing for bruno? Just a thought :-)

@helloanoop I really think @skyd0me comment is insightful, it is probably some IPv6 config that bruno is missing.

[Sleitnick]

Got this error when building out a small web server using sockets. I was using AF_UNSPEC for the addrinfo.ai_family field, which I guess was then choosing IPv6 down the line. Forced this to v4 by setting it to AF_INET instead, which "fixed" this issue for me. But yeah, I suspect something to do with IPv6, but I'm no expert with this sort of stuff.

Edit: Just on Win11, not using WSL2 or anything.

[azivkovi]

Just to chip in, I get Error invoking remote method 'send-http-request': Error: connect ECONNREFUSED 127.0.0.1:3000 using Bruno on Windows 11 and trying to reach my app on WSL2. No problem accessing public APIs.

Insomnia works for localhost requests.

[skyd0me]

I found a post which is saying that insomnia is doing an fallback implementation: https://stackoverflow.com/questions/39358426/insomnia-rest-client-error

The app will now first attempt an IPv6 lookup (usually ::1), then fallback to an IPv4 lookup (usually 127.0.0.1) on error

and indeed. Looks like Curl is doing the same.

[zarnautovic]

I made it work with wsl2 changing http://localhost:port to http://[::1]:port. it can be quick fix until devs implement ipv6 lookup

[SandeepPoojari07]

Hello @helloanoop,

I have been facing the same issue on windows with Bruno v0.27.2 http://localhost:3000/ - doesn't work http://[::1]:3000/ - works

Looking forward for a fix on the same. Thanks.

[mkornblum]

Just wanted to add some more evidence in favor of the theory that something is off with IPv6 lookups.

For local development, we run a few containers with Docker Compose behind a Traefik proxy, and they get hostnames like http://my-service.localhost. These are reachable via browsers (Chrome, Firefox), as well as via cURL, as well as via fetch from the dev tools console within Bruno itself. Looking in the Chrome dev tools, it resolves the URL to an IPv6 remote address like [::1]:80.

Trying to use the same hostname in the URL in the Bruno request UI results in the error:

Error invoking remote method 'send-http-request': Error: getaddrinfo ENOTFOUND my-service.localhost

Pulling the IPv4 URL assigned to the container (eg http://192.168.107.11/) off the Traefik dashboard, and using that in the Bruno UI instead, allows the requests to complete as expected.

[nomad483]

I have the same problem server on yii2 (not seen on other technologies) Postman, Curl - connects normally Bruno - gives an error

OS: macOS Sonoma 14.1

[Fancman]

I am running website on apache2 in WSL2 WIndows 10. In hosts file I set custom local URLs for webapp and now when I am requesting API endpoints it is returning error which is getting everyone in thread. I cant fix it with ::1 in URL because I am running multiple websites in apache under 80 port. In Insomnia it works fine.

::1               www.oplatisa.sk.local
127.0.0.1         www.oplatisa.sk.local
::1               oplatisa.sk.local
127.0.0.1         oplatisa.sk.local

[skyd0me]

If I got it right, the concept to fallback to ipv4 is often referenced as happy eyeballs or RFC 8305.

Insomnia is using node-libcurl and there was an issue in the past with the same problems as mentioned here. https://github.com/JCMais/node-libcurl/issues/280 This got resolved in the meantime and it looks like node-libcurl is doing the trick for them.

There is also a bigger PR discussion about implementing happy eyeballs in node 20: https://github.com/nodejs/node/pull/44731

Bruno is using axios. I was not able to find something related to happy eyeballs for axios.

[janos-r]

Same here, Running on linux mint 21.2 with the .deb file from the official website (v1.1.1). I would love to switch from Insomnia but not being able to query localhost is a deal breaker.

[skyd0me]

@janos-r: have you tried the http://[::1]:PORT workaround?

[janos-r]

@janos-r: have you tried the http://[::1]:PORT workaround?

Ok, it works now after adding http:// at the front.

[notfounnd]

I made it work with wsl2 changing http://localhost:port to http://[::1]:port. it can be quick fix until devs implement ipv6 lookup

Same behavior here. I've applied this tip and it works fine on localhost.

[azivkovi]

Feels like this issue should have a high priority as many people will be turned off by not being able to use localhost queries without a hack.

[notfounnd]

Feels like this issue should have a high priority as many people will be turned off by not being able to use localhost queries without a hack.

I think the same, that was close that I not stay in the turned off list because this problem. I have returned to my Bruno's POC after resolve some pendencies here.

Hey @helloanoop, maybe this issue could need a fix/bug tag.

[joshangehr]

I can replicate @fabioduque 's findings. I just downloaded Bruno (via Homebrew, in case that's a sneaky variable), and tried to access a local endpoint and got the same error. I am using Bruno 1.2.0 on Mac OS Sonoma 14.1.1 on a Macbook M2. I am using Astro, which uses Vite under the hood, similar to Nuxt, and I was able to remove the error once I exposed the localhost to the network with the --host flag (thanks, @fabioduque !). I don't have the networking chops to know how Vite is exposing/not exposing localhost with or without that flag, but I figured I'd contribute an additional scenario.

[BrandonGillis]

a coworker is having exactly the same issue on MacOS 13.2, Macbook Pro M2. The local env is running via docker and using traefik to forward request to the appropriate container, anyway with exactly the same docker stack on Linux, everything works fine.

Error message on MacOS 13.2 :

FYI, everything is working correctly with Postman / Insomnia

[helloanoop]

I think we may have finally solved this. Shoutout to @BrandonGillis who worked on the PR's (#1114, #1136) to get this done 👏 👏

The fixes are live in v1.3.2 🥳

@rfoel @julianhirt @fabioduque @Epick362 @jrc03c @ajcarrillo @skyd0me @zarnautovic @Sleitnick @azivkovi @SandeepPoojari07 @mkornblum @nomad483 @Fancman @janos-r @notfounnd @joshangehr Can you test this and react with ❤️ if the fix works

[ben-teboul]

It works very well now, thanks @BrandonGillis

[Fancman]

@helloanoop Thanks for reaching out, but v1.3.2 still didnt fix it for my case. Website is running under WSL2 and in Insomnia I didnt change anything to make requests work. I am attaching screenshots of Bruno, Insomnia and proof that I am using right version.

[BrandonGillis]

@helloanoop Thanks for reaching out, but v1.3.2 still didnt fix it for my case. Website is running under WSL2 and in Insomnia I didnt change anything to make requests work. I am attaching screenshots of Bruno, Insomnia and proof that I am using right version.

Hello @Fancman, I see that your url is using .local, unfortunately the fixes we've made are for .localhost, that's why you're still encountering the issue, anyway we can easily add support for *.local. As a last test, would you mind doing the same test with Postman and see if it works? Thank you!

[Fancman]

@helloanoop Thanks for reaching out, but v1.3.2 still didnt fix it for my case. Website is running under WSL2 and in Insomnia I didnt change anything to make requests work. I am attaching screenshots of Bruno, Insomnia and proof that I am using right version.

Hello @Fancman, I see that your url is using .local, unfortunately the fixes we've made are for .localhost, that's why you're still encountering the issue, anyway we can easily add support for *.local. As a last test, would you mind doing the same test with Postman and see if it works? Thank you!

I changed website configuration on *.localhost and it works now. Thank you

[BrandonGillis]

@helloanoop I think we can add support for special TLD domain see RFC 2606, 2: https://www.rfc-editor.org/rfc/rfc2606#section-2

It would mean adding support for : .test .example .invalid .localhost

For .local TLD it's a little more complicated see RFC 6762, 3 : https://datatracker.ietf.org/doc/html/rfc6762#section-3

Not sure what to do about that TLD, every special case about it I can find just use mDNS, but no special case that resolve to the loopback address, but with the PR #1140 that tries dns resolution first, maybe it's safe to automatically fallback to the loopback for that TLD?

Edit : just saw that the local domain was in the hosts file, so it should have worked without any fallback.

[BrandonGillis]

I am running website on apache2 in WSL2 WIndows 10. In hosts file I set custom local URLs for webapp and now when I am requesting API endpoints it is returning error which is getting everyone in thread. I cant fix it with ::1 in URL because I am running multiple websites in apache under 80 port. In Insomnia it works fine.

::1               www.oplatisa.sk.local
127.0.0.1         www.oplatisa.sk.local
::1               oplatisa.sk.local
127.0.0.1         oplatisa.sk.local

@Fancman just saw that you had the domains in your hosts file, so it should have worked. I will try to reproduce the issue you had with *.local, could you share exactly how it's setup on your machine, for example :

• wsl2 run an http server on test.local on port 8080, do you bind ::1 explicitly?
• Bruno run on windows, but can't reach test.local
• hosts file was modified on windows system32/driver/etc/hosts or is it the host file of wsl2 in /etc/hosts?

Thanks a lot!