Cách sửa lỗi 'MongoNetworkError: getaddrinfo ENOTFOUND' khi kết nối MongoDB Atlas

Vấn đềBạn chạy npm start hoặc lệnh triển khai và mong đợi một kết nối thông suốt. Thay vào đó, terminal lại hiển thị lỗi MongoNetworkError. Lỗi này thường xảy ra trong quá trình bắt tay (handshake) ban đầu, nghĩa là backend của bạn thậm chí không thể tìm thấy máy chủ cơ sở dữ liệu để bắt đầu xác thực.

Lỗi thường trông như thế này:

MongoNetworkError: getaddrinfo ENOTFOUND cluster0-shard-00-00.mongodb.net

Nói ngắn gọn, getaddrinfo ENOTFOUND là một lỗi DNS. Máy tính của bạn đã cố gắng tra cứu địa chỉ IP cho tên miền (hostname) MongoDB cụ thể đó và trình phân giải DNS không trả về kết quả nào. Nó tương đương với việc cố gắng gửi một lá thư đến một ngôi nhà không tồn tại trên bản đồ.

Tại sao điều này lại xảy ra?MongoDB Atlas sử dụng Replica Sets và bản ghi SRV (được biểu thị bằng tiền tố mongodb+srv://). Thiết lập này yêu cầu hệ thống của bạn thực hiện nhiều lần tra cứu DNS để tìm địa chỉ shard thực tế. Nếu mạng nội bộ, ISP hoặc cấu hình của bạn gặp trục trặc tại bất kỳ điểm nào trong chuỗi này, kết nối sẽ bị ngắt ngay lập tức.

Nguyên nhân gốc rễ và Giải pháp### 1. Sai sót trong chuỗi kết nối (Connection String)Ngay cả những lập trình viên trưởng dày dạn kinh nghiệm cũng có thể mắc sai lầm này. Một khoảng trắng thừa ở cuối tệp .env hoặc thiếu một ký tự trong chuỗi dài 100 ký tự sẽ làm hỏng mọi thứ. Chuỗi kết nối Atlas nổi tiếng là dài.

• Sao chép chuỗi trực tiếp từ menu Connect trong giao diện Atlas UI.- Kiểm tra các ký tự ẩn. Nếu tệp .env của bạn có MONGO_URI="mongodb+srv://...", hãy đảm bảo trình tải môi trường (environment loader) của bạn thực sự mong đợi các dấu ngoặc kép đó.- Kiểm tra ID cụm (cluster ID). Nếu bạn đã xóa một cụm và tạo một cái mới, hostname của bạn (ví dụ: cluster0.ab12c.mongodb.net) chắc chắn đã thay đổi.### 2. Máy chủ DNS không đáng tin cậyCác máy chủ DNS của nhà mạng (ISP) địa phương thường thất bại trong việc phân giải các bản ghi SRV một cách chính xác. Đây là một vấn đề đau đầu phổ biến khi làm việc tại nhà hoặc sử dụng Wi-Fi công cộng tại quán cà phê.

Giải pháp: Chuyển sang nhà cung cấp đáng tin cậyThay đổi cài đặt DNS của hệ thống hoặc bộ định tuyến sang một nhà cung cấp hiệu suất cao:

• Google Public DNS: 8.8.8.8 và 8.8.4.4- Cloudflare: 1.1.1.1Sau khi cập nhật, hãy xóa bộ nhớ đệm (cache) để đảm bảo các thay đổi có hiệu lực:

# Windows
ipconfig /flushdns

# macOS
sudo killall -HUP mDNSResponder

# Linux (Ubuntu)
sudo resolvectl flush-caches

3. VPN và Tường lửa doanh nghiệpMạng công ty và VPN (như Zscaler hoặc Cisco AnyConnect) thường chặn các truy vấn DNS trên cổng 53. Họ cũng có thể đưa tên miền mongodb.net vào danh sách đen hoàn toàn vì lý do bảo mật.

• Tạm thời ngắt kết nối VPN để kiểm tra kết nối.- Nếu VPN là bắt buộc, hãy kiểm tra xem nó có tính năng "Split Tunneling" (Phân tách đường truyền) có thể đang gây nhiễu cho DNS hay không.- Xác nhận tường lửa của bạn cho phép lưu lượng truy cập đi (outgoing traffic) trên cổng 27017. Đối với các cụm sharded, bạn cũng có thể cần mở các cổng 27015 và 27016.### 4. Tương thích với các Driver cũGiao thức mongodb+srv:// là một lối tắt tiện lợi, nhưng các phiên bản driver cũ không biết cách xử lý nó. Chúng mong đợi một chuỗi kết nối tiêu chuẩn liệt kê từng nút (node) trong replica set.

Giải pháp: Sử dụng định dạng kết nối cũ (Legacy)Trong hộp thoại "Connect" của Atlas, hãy chọn phiên bản driver như "Node.js 2.2.12 or later". Điều này cung cấp một chuỗi kết nối dài hơn, rõ ràng hơn và bỏ qua việc tra cứu SRV. Nó trông như thế này:

mongodb://user:pass@cluster0-shard-00-00.mongodb.net:27017,cluster0-shard-00-01.mongodb.net:27017...

5. Rào cản mạng trong DockerCác container không phải lúc nào cũng kế thừa cài đặt DNS của máy chủ (host). Nếu ứng dụng của bạn hoạt động bình thường trên máy cục bộ nhưng thất bại bên trong container, mạng bridge của Docker có khả năng là thủ phạm.

• Buộc container sử dụng một DNS cụ thể bằng cách thêm --dns 8.8.8.8 vào lệnh docker run của bạn.- Đối với Docker Compose, hãy xác định DNS trong tệp docker-compose.yml của bạn:``` services: web_app: image: my-node-app dns: - 8.8.8.8 - 1.1.1.1

## Xác minh: Đường truyền đã thông suốt chưa?Đừng lãng phí thời gian khởi động lại một ứng dụng nặng nề nhiều lần. Hãy sử dụng một công cụ mạng để xem hostname có thể truy cập được hay không. Chạy lệnh này trong terminal của bạn:

nslookup cluster0-shard-00-00.mongodb.net

Nếu bạn thấy một địa chỉ IP trong phản hồi, DNS của bạn khỏe mạnh. Nếu bạn thấy `NXDOMAIN`, máy tính của bạn vẫn chưa tìm thấy địa chỉ đó.
## Mẹo chuyên nghiệp để tăng tính ổn định- **Kiểm tra biến môi trường:** Sử dụng một thư viện như `dotenv-safe` hoặc `zod` để đảm bảo chuỗi kết nối của bạn hiện diện và được định dạng chính xác trước khi ứng dụng bắt đầu.- **Danh sách trắng IP (IP Whitelisting):** Lỗi DNS khác với việc bị chặn IP, nhưng chúng thường xuất hiện cùng nhau. Đảm bảo IP hiện tại của bạn (hoặc `0.0.0.0/0` để thử nghiệm) đã được đưa vào danh sách trắng trong tab **Network Access** của Atlas.- **Quản lý Subnet:** Khi quản lý AWS VPC peering hoặc các kiến trúc đám mây phức tạp, hãy sử dụng [Subnet Calculator](https://toolcraft.app/en/tools/developer/ip-subnet-calculator) trên ToolCraft. Nó giúp bạn tránh các khối CIDR bị chồng lấn, vốn có thể gây ra các lỗi định tuyến âm thầm.- **Thử lại thông minh:** Trục trặc mạng luôn có thể xảy ra. Hãy xây dựng cơ chế thử lại (retry) vào logic kết nối của bạn để một sự cố DNS kéo dài 2 giây không làm sập toàn bộ dịch vụ sản xuất của bạn.```
// Logic kết nối mạnh mẽ với Mongoose
const connectDB = async () => {
  try {
    await mongoose.connect(process.env.MONGO_URI);
    console.log('Kết nối cơ sở dữ liệu thành công');
  } catch (err) {
    console.error('Kết nối thất bại. Thử lại sau 5 giây...', err);
    setTimeout(connectDB, 5000);
  }
};