/ /

Private Endpoints

Docs Home

Troubleshoot Private Endpoint Connection Issues

Note

This page applies to both Atlas Infinite and Atlas Core.

Review the sections on this page to diagnose and resolve common private endpoint connection issues.

Dedicated Clusters

Check the status of your AWS PrivateLink connections.

To view the status of each private endpoint:

In Atlas, go to the Database & Network Access page for your project.
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 Database & Network Access under the Security heading.
  The Database & Network Access page displays.
In the sidebar, click Private Endpoint.
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 / Rejected

AWS failed to establish a connection between Atlas VPC resources and the interface endpoint in your VPC. This status may appear as Failed or Rejected depending on the failure reason.

Common causes include:

Missing region from the accepted endpoint regions list
Incorrect VPC Endpoint ID
Transient AWS issues

If you have confirmed that your configuration is correct and the failure may be due to temporary AWS delays, you can use the Retry button in the Atlas UI to retry the connection. If the issue persists, click Edit to correct the endpoint ID, or verify that the endpoint's region is included in the accepted endpoint regions.

To learn more about troubleshooting failed endpoints, see Troubleshoot Private Endpoint Connection Issues.

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.

Cross-Region Private Endpoint Issues

The following sections describe common issues with cross-region private endpoint connectivity and how to resolve them.

Endpoint Submission Failure (Missing Region)

If you forgot to specify the region where the consumer endpoint is located during submission, the endpoint status in Atlas transitions to Failed or Rejected because the endpoint service cannot locate and accept the connection.

To resolve this issue:

Add the missing region to accepted endpoint regions.

Add the missing region to the list of accepted endpoint regions. To learn more, see Manage Accepted Endpoint Regions.

Retry the connection.

After you add the region, return to the endpoint service card and click the Retry button next to the failed endpoint entry.

Warning

Do not delete a failed endpoint if it is the only endpoint registered with that private endpoint service. If you delete the last endpoint, the entire endpoint service is automatically deleted, and you must restart the entire configuration process.

Endpoint Submission Failure (Incorrect Endpoint ID)

If you submit an incorrect AWS VPC Endpoint ID (for example, a typo or an ID from a different service or VPC), the endpoint status in Atlas transitions to Failed or Rejected because the endpoint service cannot locate and accept the connection.

You can resolve this issue using one of the following methods.

To correct the ID on the existing endpoint entry:

Locate the failed endpoint.

On the endpoint service card, locate the failed endpoint entry.

Edit the endpoint ID.

Click the Edit button in the Actions column.
In the modal, update the VPC Endpoint ID field with the correct ID.
Click Save to update the ID.
Atlas attempts to accept the correct endpoint.

To replace the failed entry with a new endpoint instead:

Add a new endpoint with the correct ID.

Add a new endpoint using the correct endpoint ID. To learn more, see Set Up a Private Endpoint for a Dedicated Cluster.

Delete the failed endpoint.

After the correct endpoint is successfully accepted (status displays as Available), you can delete the failed endpoint entry.

Warning

Endpoint Submission Failure (Transient or Unknown Error)

If an endpoint submission fails and you have already verified that:

The necessary region is included in the accepted endpoint regions for the private endpoint service.
The submitted endpoint ID is correct and corresponds to the VPC endpoint you created in AWS.

The failure might be due to a transient AWS issue or an error in the initial acceptance process.

Note

Even after the endpoint is in the Pending Acceptance state in AWS, there might be a slight delay for all background resources to update. Cross-region endpoints, in particular, might take an additional 30 seconds to become discoverable by the Atlas endpoint service in a different region.

To resolve this issue:

Locate the failed endpoint.

On the endpoint service card, locate the failed endpoint entry (status displays as Failed or Rejected).

Retry the connection.

Click the Retry button in the Actions column to attempt to establish the connection again.

Warning

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://cluster0-pl-0.k45tj.mongodb.net 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://aws-replica-set-7-pl-0-lb.22qdu.mongodb-dev.net/" --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

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 collect the exact source VPC Private IP address using the attribute sourceClient.

grep 'Connection accepted' mongod.log | jq -r '(.attr.sourceClient // .attr.remote)' | awk -F: '{print $1}' | sort | uniq -c | sort -rn

25957 192.168.254.155
25957 192.168.253.161
25957 192.168.248.236
14420 10.70.2.254
14420 10.70.2.116

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://cluster1-psc-0.4uyx2d.mongodb.net

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://cluster1-psc-1.4uyx2d.mongodb.net

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 Database & Network Access page for your project.

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 Database & Network Access under the Security heading.

The Database & Network Access page displays.

In the sidebar, click Private Endpoint.

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.

Warning

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://cluster1-psc-0.4uyx2d.mongodb.net

mongodb+srv://cluster1-psc-1.4uyx2d.mongodb.net

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 Database & Network Access page for your project.

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 Database & Network Access under the Security heading.

The Database & Network Access page displays.

In the sidebar, click Private Endpoint.

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. Note: If you see the error message "The endpoint could not be found in GCP. Please verify the endpoint name is correct and is created in the correct GCP project and try again," you might have mistyped your private endpoint name, or you may still need to create it. To resolve this, click Edit and make sure the fields are accurate.
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.

Warning

Make sure that your security groups are configured properly.

For each resource that needs to connect to your Atlas clusters using GCP Private Service Connect, you must allow outbound traffic to the forwarding rule's private IP addresses on all ports (1024-65535). See Managing Consumer Security For PSC for more information.

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://cluster1-psc-0.4uyx2d.mongodb.net

mongodb+srv://cluster1-psc-1.4uyx2d.mongodb.net

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.cluster1-psc-0.j735c.mongodb.net

Server:               127.0.2.2
Address:      127.0.2.2#53
------------
   QUESTIONS:
   _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net, type = SRV, class = IN
   ANSWERS:
   ->  _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net
   service = 0 0 1024 pl-0-us-central1-gcp.j735c.mongodb.net.
   ttl = 60
   ->  _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net
   service = 0 0 1025 pl-0-us-central1-gcp.j735c.mongodb.net.
   ttl = 60
   ->  _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net
   service = 0 0 1026 pl-0-us-central1-gcp.j735c.mongodb.net.
   ttl = 60
   AUTHORITY RECORDS:
   ADDITIONAL RECORDS:
------------
Non-authoritative answer:
_mongodb._tcp.cluster1-psc-0.j735c.mongodb.net        service = 0 0 1024 pl-0-us-central1-gcp.j735c.mongodb.net.
_mongodb._tcp.cluster1-psc-0.j735c.mongodb.net        service = 0 0 1025 pl-0-us-central1-gcp.j735c.mongodb.net.
_mongodb._tcp.cluster1-psc-0.j735c.mongodb.net        service = 0 0 1026 pl-0-us-central1-gcp.j735c.mongodb.net.
Authoritative answers can be found from:
telnet pl-0-us-central1-gcp.j735c.mongodb.net 1024

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