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.

Screen.Recording.2023-03-20.at.08.58.42.mov

[helloanoop]

@rfoel Can you confirm that curl works
curl -X POST -d '{"email": "[email protected]"}' 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

[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!

[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

@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!

On WSL I installed apache2, created and enabled config for website which listens on 80 port:

/etc/apache2/sites-available/oplatisa.sk.conf

<VirtualHost *:80>
        ServerName www.oplatisa.sk.local
        ServerAlias oplatisa.sk.local
        DocumentRoot /var/www/oplatisa.sk/public
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        # To make URL segments work
        <Directory /var/www/oplatisa.sk/public>
                Options Indexes FollowSymLinks
                AllowOverride All
                Require all granted
        </Directory>
</VirtualHost>

Then I modified C:\Windows\System32\drivers\etc\hosts and it seems that it automatically got replicated into /etc/hosts because it contains same addresses.

C:\Windows\System32\drivers\etc\hosts

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

::1               www.oplatisa.sk.localhost
127.0.0.1         www.oplatisa.sk.localhost
::1               oplatisa.sk.localhost
127.0.0.1         oplatisa.sk.localhost

\etc\hosts

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl># [network]
# generateHosts = false
127.0.0.1       localhost
127.0.1.1       nb-figura.      nb-figura

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

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix

Then I tried to make requests from Bruno which is installed on Windows 11 and couldnt access it. Before that I had website running in WSL under localhost and when I tried to access it with Bruno from Windows it worked (GET 127.0.0.1). Problems started when I changed website address to oplatisa.sk.local

[BrandonGillis]

Thanks for the detailed answer, that will help a lot to reproduce the issue!

[emflomed17]

I believe for MacOS users this is still an issue right?

I'm still getting the: "Error invoking remote method 'send-http-request': Error: connect ECONNREFUSED 127.0.0.1:3000"

Request example: http://localhost:3000/dev/poc/1a9c4c0f-0ee2-4155-9848-1d047382c5a7

It is a serverless framework project.

My Bruno version is 1.7.1

I have:
M2 Chip
Sonoma 14.2.1

Kind of sad because I really wanted to give it a shot to Bruno.

[anitachan]

I have the same issue. I'm using 1.6.1. I have an intel mac with Sonoma 14.3. In insomnia works well but bruno doesn't. This is my error! Error invoking remote method 'send-http-request': Error: connect ECONNREFUSED ::1:8080

[muffe]

Same issue here

macOS: 14.3.1
Bruno: 1.10.0

Trying to run a pre request script

const fetch = require("node-fetch");
const body = {
  email: "{{username}}",
  password: "{{password}}"
};

const response = await fetch('http:/127.0.0.1:3000/api/users/login', {
	method: 'post',
	body: JSON.stringify(body),
	headers: {'Content-Type': 'application/json'}
});
const data = await response.json();

bru.setVar("ACCESS_TOKEN", data.accessToken);

The error given is

Error invoking remote method 'send-http-request': 
FetchError: request to http://127.0.0.1:3000/api/users/login failed, reason: connect ECONNREFUSED 127.0.0.1:3000

The application is running at 127.0.0.1:300.
If I run a "normal" request in bruno against the endpoint it works, but as soon as the context is the pre request script the above error occurs.

[druxton-consid]

Can confirm this is still an issue unfortunately

[jquinc30]

For @druxton-consid and the ones who continue to experiment the issue, I found 2 workarounds for a teammate that both works for us but I really prefer the second one:

1. In the URL, replace localhost by your ip address [for example, you can find it thanks to the output of the command ifconfig]
   • Example: http://localhost:3000/xyz should be replaced by http://yourIP:3000/xyz. So if yourIP is 10.123.124.125, it should be http://10.123.124.125:3000/xyz
   • NB: with this solution, your will need to change the URL each time your IP address updates. Check the second point for a more robust/long term solution.
2. Update your OS hosts file (/private/etc/hosts on a mac) and create a fake local domain name to trick Bruno.

• Add 127.0.0.1 bruno.local [here bruno.local is arbitrary and can be replaced] (cf line 12 in the below screenshot)
  
• Replace localhost by this domain in URL in Bruno.
  • Example: http://localhost:3000/xyz should be replaced by http://bruno.local:3000/xyz.

[mig8447]

This is still an issue in macOS for me, I managed to fix it by using http://127.0.0.1 instead of http://localhost but this is still an issue with bruno (even the CLI) preferring IPV6

For the CLI you can use the following:

NODE_OPTIONS=--dns-result-order=ipv4first npx -y --package @usebruno/cli bru run

This will make the Bruno CLI to use ipv4 name resolution first

[douglasmiranda]

Bruno 1.12.3
System: Pop!_OS 22.04
Using Bruno AppImage version

Basically same thing happening with me.

Trying to access http API running in container. Ran into the same problems of localhost vs 127.0.0.1 and in some cases my request went through but I've noticed my request with a json body just wont go through.

Doing the same exact comand with cURL or using httpie works just fine.

For reference, I tried the example in this API specifically https://docs.browserless.io/HTTP-APIs/pdf

[trevorrobertsjr]

Bruno 1.19.0
CPU: M3 Pro
OS: macOS 14.5

I am unable to access my flask[async] server via http://localhost. It works with http://127.0.0.1. It works fine with curl
If I use the standard wsgi flask server or with gunicorn, http://localhost works.

[berain-uvic]

On Windows 11 I was having the same issue, uninstalling and reinstalling solved the isssue.

[krestaino]

On Windows 11 after a fresh install of Bruno and running it the first time, I was having this issue. Not the greatest first impression, but simply closing the program and opening it again resolved the issue.

[jeffreyrwells]

This is still an issue in macOS for me, I managed to fix it by using http://127.0.0.1 instead of http://localhost but this is still an issue with bruno (even the CLI) preferring IPV6

For the CLI you can use the following:

NODE_OPTIONS=--dns-result-order=ipv4first npx -y --package @usebruno/cli bru run

This will make the Bruno CLI to use ipv4 name resolution first

Changing http://localhost to http://127.0.0.1 fixed the Bruno CLI for my situation (CLI specific issue only). Thank you!