Skip to content
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

Localhost #124

Closed
rfoel opened this issue Mar 10, 2023 · 59 comments · Fixed by #1114
Closed

Localhost #124

rfoel opened this issue Mar 10, 2023 · 59 comments · Fixed by #1114

Comments

@rfoel
Copy link

rfoel commented Mar 10, 2023

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
Copy link
Contributor

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

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

@rfoel
Copy link
Author

rfoel commented Mar 20, 2023

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
Copy link
Contributor

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

@rfoel
Copy link
Author

rfoel commented Mar 21, 2023

@helloanoop yes it works fine.

@helloanoop
Copy link
Contributor

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
Copy link
Author

rfoel commented Sep 25, 2023

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
Copy link

@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
Copy link

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
Copy link

I do have the same issue not using LuLu

@fabioduque
Copy link

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
Copy link
Author

rfoel commented Oct 5, 2023

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
Copy link

Epick362 commented Oct 9, 2023

Experiencing the same with serverless-offline and Bruno :(

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

@julianhirt
Copy link

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

@rfoel
Copy link
Author

rfoel commented Oct 10, 2023

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

@fabioduque
Copy link

@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
Copy link

jrc03c commented Oct 10, 2023

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
Copy link
Contributor

@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
Copy link

@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
Copy link

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.

image

@skyd0me
Copy link

skyd0me commented Oct 11, 2023

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
Copy link

skyd0me commented Oct 12, 2023

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
Copy link

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
Copy link
Contributor

@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
Copy link

@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
Copy link

zarnautovic commented Oct 25, 2023

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
Copy link
Author

rfoel commented Oct 26, 2023

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
Copy link

Sleitnick commented Oct 26, 2023

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
Copy link

azivkovi commented Oct 26, 2023

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
Copy link

skyd0me commented Oct 26, 2023

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.
image

@zarnautovic
Copy link

zarnautovic commented Oct 30, 2023

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

@notfounnd
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

BrandonGillis commented Nov 30, 2023

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 :
image

FYI, everything is working correctly with Postman / Insomnia

BrandonGillis added a commit to BrandonGillis/bruno that referenced this issue Dec 1, 2023
BrandonGillis added a commit to BrandonGillis/bruno that referenced this issue Dec 1, 2023
helloanoop added a commit that referenced this issue Dec 4, 2023
fix(#124): resolve all *.localhost to localhost, and fix ipv6 issue
@helloanoop helloanoop reopened this Dec 4, 2023
BrandonGillis added a commit to BrandonGillis/bruno that referenced this issue Dec 4, 2023
helloanoop added a commit that referenced this issue Dec 4, 2023
fix(#124): Improve localhost handling, add cache for ipv6 & ipv4 check
@helloanoop
Copy link
Contributor

helloanoop commented Dec 4, 2023

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
Copy link

It works very well now, thanks @BrandonGillis

@Fancman
Copy link

Fancman commented Dec 5, 2023

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

image
image
image

@BrandonGillis
Copy link
Contributor

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

image image image

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
Copy link

Fancman commented Dec 5, 2023

@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.
image image image

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
Copy link
Contributor

BrandonGillis commented Dec 5, 2023

@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
Copy link
Contributor

BrandonGillis commented Dec 5, 2023

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
Copy link

Fancman commented Dec 5, 2023

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
Copy link
Contributor

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

@emflomed17
Copy link

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
Copy link

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
Copy link

muffe commented Mar 12, 2024

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
Copy link

Can confirm this is still an issue unfortunately

@jquinc30
Copy link

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)
    image
  • Replace localhost by this domain in URL in Bruno.
    • Example: http://localhost:3000/xyz should be replaced by http://bruno.local:3000/xyz.

@mig8447
Copy link

mig8447 commented Apr 1, 2024

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

@douglasmiranda
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.