Node.js - Node-RED v3.0.2 MQTT Configuration Windows Quirk

In prior versions I had used "localhost" in the configuration and it works great. This time I imported nodes from the same version v3.0.2 but as a new Node-RED install, I installed nodes, I thought perhaps a version change is coming in this download?? MQTT nodes are installed as part of Node-RED. So this is what makes it somewhat confusing. On one system I can use the term "localhost" and the other I have to use "".

Also, on the new system is an upgrade on this system from 2.?? to 3.0.2. The older version loaded on this one used "localhost" with the MQTT Configuration node just fine. There is a version difference issue pertaining to syntax perhaps in the MQTT Configuration node itself.

How is node-red running on the new system? In docker? Wsl? Direct on windows?

Is there actually a broker instead and running on the new system? (Since you are talking about localhost and, you will need an MQTT broker in the same OS)

Lastly, what do you see if you ping localhost in a command line terminal?

No, Just Win 10 installed both with Julian's alternate installer. (I really do not think that's the issue). I just updated some more oddity notes.

So is it fixed now? If so, mark the thread as complete. Otherwise, answer the other 2 questions

i get IPv6 reply...

Ok, there is your difference. You probably have ipv6 disabled on the other box.


you are using a different version of nodejs (my guess is you installed either v18 of v19 but your other box has v16 or v14)

Not "fixed" but I have to use When I ported code to it MQTT raised errors all over the place. I went around and around . rinse/repeat. until I just plugged in the for a test. WOW! it worked. But that's not cool that only a different version and no other changes cause this.

Ps, if you want MQTT to work with ipv6 you will need to modify the mosquitto conf to allow ipv6 binding.

(I am assuming mosquitto as you haven't yet answered my other question)

I did upgrade Node.js. 14 to LTS 18. This is true. Sorry for not mentioning it sooner. I forgot that part.

not intending for IPv6 usage. I would normally have that disabled in the NIC.

NODEJS > v16 coupled with your broker not permitting ipv6 is your problem

1 Like

AH HA! Node.js changed "localhost" !!

It isn't that they changed localhost, it is, I believe, that for any name that supports both ipv6 and ipv4 nodejs will prefer ipv6.

Normally, on Linux, localhost maps to (at least it does on mine), so localhost is the same as, presumably your Windows system is giving the option of that or an ipv6 address, and nodejs is using the ipv6 address.
What does
ping localhost


I could be wrong but I think that nodejs resolving to ipv6 instead of ipv4 (in this case) is that the ops OS is actually also resolving to ipv6. In earlier versions of nodejs I believe it would have return an ipv4 address.

I had not realised that was an answer to the ping localhost question. In that case, yes, if ping only returns an ipv6 address for localhost then it is indeed windows that is doing that, nothing to do with nodejs or node-red. If the OS only provides an ipv6 address then that is what they must use.

No. (Sorry for indignation). Prior version of Node.js renders using "localhost" working. Change to 18 from 14 and now I need to specify ''. So Windows is the common element. Node.js is different.

No apology necessary, as I see you are correct, Windows does provide the IPV6 for localhost. On my (linux) system the default install of mosquitto works perfectly with IPV6. Which MQTT broker are you using?

I asked the op several times and indicated the broker may need adjusting for ipv6 binding but....

But would be nice to know (for other users)

Yes, I know. Hopefully we may get an answer so we know how to answer this question in the future.

My experience is that the default mosquitto install on Ubuntu does not need adjusting for IPV6. It would be good to know if the default install on Windows does not support IPV6, or perhaps @hp_apcc is not using Mosquitto.

I'm not entirely sure I understood the original question. But in case it helps, you cannot make assumptions about how "localhost" is represented when trying to account for it in Node.JS.

There are multiple representations that you might get back from the OS depending on several factors including router/DNS/hosts file setup.

Here is a recent example from my own custom node's HTML code:

const localHost = ['localhost', '', '::1', ''].includes(window.location.hostname) || window.location.hostname.endsWith('.localhost')

I expect there are other edge-cases I've not allowed for as well. As you can see ::1 is the IPv6 equivalent of localhost.

I know this isn't exactly what the problem is here but it may help where people are making assumptions about what might be seen as localhost. The important thing to note is that the representation of localhost is not purely dependent on one thing.