A few days ago, I started a new backend project using Node.js, Express, MongoDB Atlas, and Mongoose. Before writing any routes, controllers, or models, I wanted to make sure the application could connect to MongoDB. I created a brand-new Atlas organization, a free-tier cluster, a database user, allowed access from 0.0.0.0/0, copied the connection string into my .env file, and wrote a simple Mongoose connection. Everything looked correct.
When I ran the project, I expected to see a successful connection, but instead I got querySrv ECONNREFUSED _mongodb._tcp.cluster1.... My first thought was that I had configured MongoDB incorrectly. I recreated the cluster, recreated the database user, verified my username and password, checked the connection string, reviewed my code, confirmed the IP whitelist, and even updated Mongoose. Nothing changed.
That's when I stopped blaming MongoDB and started testing DNS. Windows was able to resolve the MongoDB SRV records using nslookup, but Node.js couldn't. Even stranger, dns.lookup("google.com") worked, while both dns.resolve4("google.com") and dns.resolveSrv() failed with ECONNREFUSED. That was the moment I realized the problem wasn't MongoDB at all.
From there, I went down a long debugging rabbit hole. I changed my DNS servers to Cloudflare, switched between my home Wi-Fi and my mobile hotspot, flushed the DNS cache, reset the Windows network stack, checked the registry, inspected the hosts file, looked for proxy settings, investigated old Docker files, checked WSL and Hyper-V, and even reset Windows while keeping my personal files. Through all of this, one thing stayed the same: Node.js always reported 127.0.0.1 as its DNS server, even though Windows was clearly using Cloudflare.
Eventually, I found a temporary workaround by adding dns.setServers(["1.1.1.1", "1.0.0.1"]) before connecting to MongoDB. That immediately fixed the problem, and the database connected successfully. It proved that the issue was related to DNS, but I wasn't satisfied with leaving a workaround in my project.
I kept digging and finally decided to try one last experiment. I uninstalled Node.js v22 and installed Node.js v20 LTS. As soon as I did that, dns.getServers() started returning my actual DNS servers instead of 127.0.0.1. dns.resolve4() worked normally, MongoDB Atlas connected without any extra code, and I no longer needed the workaround.
The biggest lesson from this experience wasn't about MongoDB. It was about debugging. At the beginning, I was convinced Atlas was the problem. Later, I thought Windows networking was broken. In the end, the most useful thing I did was stop making assumptions and start testing one component at a time. Each test ruled out another possibility until only the real cause remained.
I'm still not completely sure why Node.js v22 behaved this way on my machine while Node.js v20 worked perfectly. If anyone has experienced something similar or knows the reason behind it, I'd love to hear your thoughts. That's one of the things I enjoy most about software development every strange bug is an opportunity to learn something new.
Top comments (0)