All Products
Search

This Product

    ApsaraDB RDS:Troubleshoot instance connection issues

    Document Center

    ApsaraDB RDS:Troubleshoot instance connection issues

    Last Updated:Jun 17, 2026

    This topic describes how to resolve connection issues with an ApsaraDB RDS for MySQL instance.

    When you build and debug your workloads, you may be unable to connect to an ApsaraDB RDS for MySQL instance. Common causes include mismatched network types and incorrect IP address whitelist settings. This topic covers these causes and their solutions.

    Mismatched network types

    • The ECS instance is in a VPC, and the ApsaraDB RDS for MySQL instance is in the classic network

      • Solution 1 (Recommended): Switch the network type of the ApsaraDB RDS for MySQL instance from classic network to VPC. For more information, see Change the network type of an ApsaraDB RDS instance.

        Note

        After the switch, both instances must be in the same VPC to communicate over the internal network.

      • Solution 2: Purchase a new ECS instance in the classic network. ECS instances cannot be migrated from a VPC to the classic network. We recommend that you use a VPC because it provides higher security than a classic network.

      • Solution 3: Connect to the RDS instance from the ECS instance using its public endpoint. This method offers poor performance, security, and stability.

    • The ECS instance is in the classic network, and the ApsaraDB RDS for MySQL instance is in a VPC

      • Solution 1 (Recommended): Migrate the ECS instance from the classic network to a VPC.

        Note

        After the migration, both instances must be in the same VPC to communicate over the internal network.

      • Solution 2: Switch the network type of the RDS instance from VPC to classic network. We recommend that you use a VPC because it provides higher security than a classic network.

      • Solution 3: Use ClassicLink to connect the ECS instance in the classic network to VPC resources over an internal network.

      • Solution 4: Connect to the RDS instance from the ECS instance using its public endpoint. This method offers poor performance, security, and stability.

    Different VPCs

    VPCs are logically isolated network environments built on Alibaba Cloud. To communicate over an internal network, your ECS and ApsaraDB RDS for MySQL instances must be in the same VPC.

    Different regions

    • Public connection: Use the public endpoint of the RDS instance to connect across regions or accounts over the internet. You are not charged for the inbound and outbound internet traffic of the RDS instance.

    • Private connection: By default, if an ECS instance and an RDS instance are in different regions or belong to different accounts, they cannot connect over an internal network because their VPCs are isolated. However, you can use a VPC peering connection or Cloud Enterprise Network (CEN) to connect the two VPCs, allowing the ECS instance to access the RDS instance across regions or accounts.

      • VPC peering connection: This feature supports cross-region and cross-account VPC connections. It is cost-effective but relatively complex to configure, making it suitable for simple scenarios with a small number of VPCs.

      • Cloud Enterprise Network (CEN): This product supports cross-region and cross-account VPC connections. It is easy to configure but more expensive, making it suitable for complex scenarios with multiple VPCs.

    Incorrect IP address whitelist settings

    Domain name resolution failure or error

    A DNS server failure or a change in the network interface card (NIC) configuration can cause domain name resolution to fail or return an incorrect IP address. Use theping andtelnet commands to test connectivity to your RDS instance. 

    ping <domain_name>
telnet <domain_name> <port_number>

    Examples

    # Example of a successful ping
[root@xxx ~]# ping rm-xxx.mysql.rds.aliyuncs.com
PING rm-xxx.mysql.rds.aliyuncs.com (192.168.0.176) 56(84) bytes of data.
64 bytes from 192.168.0.176 (192.168.0.176): icmp_seq=1 ttl=64 time=0.151 ms
64 bytes from 192.168.0.176 (192.168.0.176): icmp_seq=2 ttl=64 time=0.141 ms
64 bytes from 192.168.0.176 (192.168.0.176): icmp_seq=3 ttl=64 time=0.107 ms
64 bytes from 192.168.0.176 (192.168.0.176): icmp_seq=4 ttl=64 time=0.108 ms
# Example of a failed ping
[root@izbpxxx ~]# ping rm-bp1xxx.mysql.rds.aliyuncs.com
ping: rm-bp1xxx.mysql.rds.aliyuncs.com: Name or service not known
[root@izbpxxx ~]#
    # Example of a successful telnet connection
[root@xxx ~]# telnet rm-xxx.mysql.rds.aliyuncs.com 3306
Trying 192.168.0.176...
Connected to rm-xxx.mysql.rds.aliyuncs.com.
Escape character is '^]'.
N
5.6.16-logtEkkVNd-0!)\}\4/,/GXfu<mysql_native_password
# Example of a failed telnet connection (domain name resolution failure)
[root@izbpxxx ~]# telnet rm-bp1xxx.mysql.rds.aliyuncs.com 3306
telnet: rm-bp1xxx.mysql.rds.aliyuncs.com: Name or service not known
rm-bp1xxx.mysql.rds.aliyuncs.com: Host name lookup failure
[root@izbpxxx ~]#

    If the test fails, modify the NIC configuration file to resolve the issue:

    1. Modify the NIC configuration file. 

      vi /etc/sysconfig/network-scripts/<nic_configuration_file_name>
      Note

      The <nic_configuration_file_name> is the NIC used by the ECS server. Run theifconfig command to view the file name suffix. The default is ifcfg-eth0.

    2. Add the following lines to the end of the file: 

      DNS1=100.100.XX.XX
DNS2=100.100.XX.XX
      Note

      If DNS1 and DNS2 are already configured, update their IP addresses as shown above.

      DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
DNS1=100.100.2.136
DNS2=100.100.2.138

    3. Run the following command to restart the network service: 

      sudo systemctl restart network

    4. Run the following command to check if the modification was successful: 

       cat /etc/resolv.conf
      [root@xxx ~]# cat /etc/resolv.conf
options timeout:2 attempts:3 rotate single-request-reopen
: generated_by /usr/sbin/dhclient-script
nameserver 100.100.2.136
nameserver 100.100.2.138
[root@xxx ~]#

    Test port connectivity

    If domain name resolution is working correctly, use thetelnet command to test port connectivity to the RDS instance.

    telnet <RDS_endpoint> <port_number>

    For example, test the default port 3306 of an ApsaraDB RDS for MySQL instance:

    telnet rm-xxxx.mysql.rds.aliyuncs.com 3306

    • An output containingConnected to andEscape character is indicates that the port is accessible at the network layer.

    • AConnection timed out error indicates the network is unreachable or blocked by a firewall. Check the following configurations:

      • Verify that the RDS IP address whitelist includes the client IP address.

      • Verify that the security group rules allow traffic on the corresponding port.

      • Verify that the client and the RDS instance are in the same VPC. An internal endpoint is accessible only from within its VPC.

    • AConnection refused error indicates that the port is not being listened on. Check the running status and port configuration of the RDS instance.

    If bothping andtelnet commands run successfully but your application still reports a connection timeout, the issue is at the application layer, not the network layer. Usetcpdump to capture packets and analyze the TCP three-way handshake and four-way handshake to identify the root cause of the timeout.

    tcpdump -i eth0 host <RDS_endpoint> -w rds_capture.pcap

    Analyze the packet capture file: No response to a SYN packet indicates the network is unreachable or blocked. No data exchange after a successful three-way handshake indicates an application-level anomaly.

    Instance stuck in Creating Network Connection state

    In the console, go to the Tasks page. Find the task and click Retry or Modify switching time. For more information, see Use Task Center.

    Read timeout from no response to FIN packet

    When you connect to an ApsaraDB RDS for MySQL instance through an intermediate network like a VPN or leased line, the connection might work initially but then time out. This can happen if the server fails to respond after the client sends a FIN packet.

    Follow these steps to troubleshoot the issue:

    1. In the ApsaraDB RDS console, go to the instance details page. In the left-side navigation pane, click Parameters and check the values of the wait_timeout and interactive_timeout parameters. In ApsaraDB RDS for MySQL, the default value of wait_timeout is 86,400 seconds. If this parameter is set to a low value, the server will close idle connections prematurely.

    2. Check for packet loss or high latency on the intermediate network link, such as the VPN or leased line. Use the telnet <RDS_endpoint> <port_number> command to test port connectivity to the RDS instance and confirm accessibility at the network layer.

    3. Use tcpdump or Wireshark to capture packets on both the client and server simultaneously. Analyze the sequence of TCP FIN/RST packets to determine whether the disconnection occurs at the network transport layer or the database application layer.

    Troubleshooting timeouts with logs

    Investigate connection timeout issues by checking the error log and slow log of your RDS instance.

    1. Log on to the ApsaraDB RDS console. On the Instances page, find the target instance and go to its management page. In the left-side navigation pane, choose Logs > Error Logs.

    2. Check the error log for records such as Host is blocked, connect timeout, or Aborted connection to identify the reason for the connection failure.

    3. Choose Slow Query Logs and check for long-running slow queries that may be blocking new connections.

    4. Check the instance's wait_timeout and interactive_timeout parameter settings to determine if timeouts are automatically disconnecting idle connections.