MongoDB Atlas接続時の「MongoNetworkError: getaddrinfo ENOTFOUND」の解決方法

問題の概要npm start を実行したり、デプロイ用スクリプトを走らせたりして、正常な接続を期待したとします。しかし、ターミナルには MongoNetworkError が表示されてしまいます。この失敗は通常、初期ハンドシェイク中に発生します。つまり、バックエンドが認証を開始するためのデータベースサーバーを見つけることさえできていない状態を意味します。

エラーは通常、以下のようになります。

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

簡単に言うと、getaddrinfo ENOTFOUND は DNS の失敗です。コンピュータが特定の MongoDB ホスト名の IP アドレスを検索しようとしたものの、DNS リゾルバーが何も見つけられなかったことを示しています。これは、地図上に存在しない住所に手紙を出そうとするような、デジタル上の行為に相当します。

なぜこれが発生するのか？MongoDB Atlas はレプリカセットと SRV レコード（mongodb+srv:// プレフィックスで示されます）を使用しています。この構成では、実際のシャードのアドレスを見つけるために、システムが複数の DNS ルックアップを実行する必要があります。ローカルネットワーク、ISP、または設定のどこかでこのチェーンが途切れると、接続は即座に切断されます。

根本的な原因と解決策### 1. 接続文字列のタイポ（入力ミス）経験豊富なリードエンジニアでもこのミスは犯します。.env ファイルの末尾にあるスペース一つや、100文字の文字列の中の文字欠け一つが、すべてを台無しにします。Atlas の接続文字列は非常に長いことで有名です。

• Atlas UI の Connect メニューから文字列を直接コピーしてください。- 隠れた文字がないか確認してください。もし .env ファイルに MONGO_URI="mongodb+srv://..." と記述している場合、環境変数ローダーが実際にその引用符を期待しているか確認してください。- クラスター ID を確認してください。クラスターを削除して新しいものを作成した場合、ホスト名（例：cluster0.ab12c.mongodb.net）は確実に変更されています。### 2. 信頼性の低い DNS サーバー地元の ISP の DNS サーバーは、SRV レコードを正しく解決できないことがよくあります。これは、自宅やカフェの公共 Wi-Fi で作業している際によく発生する問題です。

解決策：信頼できるプロバイダーに移行するシステムまたはルーターの DNS 設定を、高パフォーマンスなプロバイダーに切り替えてください。

• Google Public DNS: 8.8.8.8 および 8.8.4.4- Cloudflare: 1.1.1.1更新後、キャッシュをクリアして変更を確実に反映させます。

# Windows
ipconfig /flushdns

# macOS
sudo killall -HUP mDNSResponder

# Linux (Ubuntu)
sudo resolvectl flush-caches

3. VPN と企業用ファイアウォール企業ネットワークや VPN（Zscaler や Cisco AnyConnect など）は、ポート 53 での DNS クエリをブロックすることがよくあります。また、セキュリティ上の理由から mongodb.net ドメインを完全にブラックリストに入れている場合もあります。

• 一時的に VPN を切断して、接続をテストしてください。- VPN が必須の場合は、DNS を妨げている可能性のある「スプリットトンネリング（Split Tunneling）」機能がないか確認してください。- ファイアウォールがポート 27017 での送信トラフィックを許可していることを確認してください。シャードクラスターの場合、ポート 27015 および 27016 を開く必要がある場合もあります。### 4. 古いドライバーとの互換性mongodb+srv:// プロトコルは便利なショートカットですが、古いバージョンのドライバーはこれを処理する方法を知りません。それらは、レプリカセット内のすべてのノードをリストした標準的な接続文字列を期待します。

解決策：レガシーな接続形式を使用するAtlas の「Connect」ダイアログで、**「Node.js 2.2.12 or later」**のようなドライバーバージョンを選択してください。これにより、SRV ルックアップをバイパスする、より明示的な長い文字列が提供されます。形式は以下のようになります。

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

5. Docker ネットワークの障害コンテナは常にホストの DNS 設定を継承するとは限りません。アプリがローカルでは動作するのにコンテナ内では失敗する場合、Docker ブリッジネットワークが原因である可能性が高いです。

• docker run コマンドに --dns 8.8.8.8 を追加して、コンテナに特定の DNS を強制的に使用させます。- Docker Compose の場合は、docker-compose.yml ファイルで DNS を定義します。``` services: web_app: image: my-node-app dns: - 8.8.8.8 - 1.1.1.1

## 検証：経路は確保されているか？重いアプリケーションを何度も再起動して時間を無駄にしないでください。ネットワークツールを使用して、ホスト名に到達可能かどうかを確認します。ターミナルで以下を実行してください。

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

レスポンスに IP アドレスが表示されれば、DNS は正常です。`NXDOMAIN` と表示される場合は、マシンがまだそのアドレスを認識できていません。
## 安定性のためのプロのヒント- **環境変数のバリデーション:** アプリが起動する前に、接続文字列が存在し、正しくフォーマットされていることを確認するために、`dotenv-safe` や `zod` などのライブラリを使用してください。- **IP ホワイトリスティング:** DNS エラーは IP ブロックとは別物ですが、併発することがよくあります。Atlas の **Network Access** タブで、現在の IP（テスト目的であれば `0.0.0.0/0`）がホワイトリストに登録されていることを確認してください。- **サブネット管理:** AWS VPC ピアリングや複雑なクラウドアーキテクチャを管理する際は、ToolCraft の [Subnet Calculator](https://toolcraft.app/en/tools/developer/ip-subnet-calculator) を使用してください。サイレントなルーティング失敗の原因となる CIDR ブロックの重複を避けるのに役立ちます。- **スマートなリトライ:** ネットワークの瞬断は起こり得ます。2秒間の DNS の不調で本番サービス全体がクラッシュしないように、接続ロジックにリトライメカニズムを組み込んでください。```
// Mongoose を使用した堅牢な接続ロジック
const connectDB = async () => {
  try {
    await mongoose.connect(process.env.MONGO_URI);
    console.log('データベースに正常に接続されました');
  } catch (err) {
    console.error('接続に失敗しました。5秒後に再試行します...', err);
    setTimeout(connectDB, 5000);
  }
};