Alibaba Cloud RDS 'Can't Connect to MySQL Server' Error: IP Whitelist Fix

Alibaba Cloud / 2026-08-01 15:36:36

If you see Can't connect to MySQL server after creating an Alibaba Cloud RDS instance, the first thing to check is usually not the password. In real projects, the problem is often one of these: the wrong source IP was whitelisted, the endpoint is wrong, the instance is not publicly reachable, or the account is still under payment or verification restrictions.

The fastest way to solve it is to match the connection path with the correct whitelist entry. If you are connecting from a laptop or office network, whitelist the public outbound IP of that network. If you are connecting from an ECS instance in the same VPC, do not use the public IP - use the private network path and whitelist the ECS private IP or VPC range as required by your setup.

Quick Fix First

  1. Confirm whether the connection comes from home, office, ECS, VPN, or CI/CD.
  2. Find the actual outbound IP of that path, not the IP shown on your laptop or server.
  3. Add that IP to the RDS whitelist.
  4. Wait a few minutes for the whitelist to take effect.
  5. Reconnect using the correct RDS endpoint and port.

If you only remember one thing: whitelist the IP that leaves the network, not the device IP you see in Windows, macOS, or Linux.

Why This Error Happens So Often

RDS is strict about source access. That is a good thing for security, but it also means a connection can fail even when the database username and password are correct. The common real-world causes are:

  • The laptop is behind a home router, so the public IP is different from the local IP.
  • The office network uses a NAT gateway or proxy, so multiple devices share one outbound IP.
  • The team is using a VPN, and the VPN exit IP is what RDS actually sees.
  • The instance has only an intranet endpoint, but the user is trying to connect from the internet.
  • The whitelist was updated, but the connection was tested too quickly before propagation finished.
  • The cloud account is pending KYC, payment verification, or risk control review and the instance is not fully usable.

Fix the IP Whitelist the Right Way

In the RDS console, open the instance and locate the whitelist or access control settings. Add the source IP or CIDR block that matches your real network path. A single IP is usually added as x.x.x.x/32. A fixed office range can be added as a CIDR block if your network team confirms it is stable and approved.

Examples:

  • 203.0.113.25/32 - one fixed public IP
  • 198.51.100.0/24 - a controlled office subnet
  • 10.0.0.8 or 192.168.1.10 - usually wrong for internet connections, because these are private LAN addresses

Alibaba Cloud After updating the whitelist, wait a short while and test again. A common mistake is to change the rule and immediately retry five times in a row. That creates confusion when the real issue is just propagation delay.

Where People Usually Add the Wrong IP

Scenario What the User Adds Why It Fails Correct Fix
Home laptop 192.168.x.x or 10.x.x.x That is the local LAN IP, not the public egress IP Check the public IP from the same home network and whitelist it
Office network One employee's PC IP Office traffic usually exits through NAT or a proxy Use the office outbound IP from the network team
VPN access The laptop IP before VPN RDS sees the VPN exit IP, not the local device IP Whitelist the VPN egress IP or subnet
ECS in same region Public IP of the ECS The app may be using the private VPC path instead Use the private endpoint and whitelist the ECS private network path
CI/CD or cloud function Temporary runner IP Runners often change on each job Use a fixed NAT/VPN exit IP or a dedicated bastion host

How to Verify the Real Source IP

Do not guess. Verify it from the same place where the database client runs. If you are on a laptop, open a browser on that network and check your public IP. If you are on an ECS or server, run a simple outbound request such as:

curl https://api.ipify.org

If your company uses a proxy or VPN, ask the network team which outbound IP the database actually sees. In many failed cases I have seen, the user kept whitelisting the workstation address while the traffic was leaving from a shared proxy IP hundreds of kilometers away.

When the Whitelist Is Not the Real Problem

If the whitelist is correct and the error still appears, check these items before spending more time on MySQL settings:

  • Wrong endpoint: internal endpoint for private access, public endpoint for internet access.
  • Wrong port: the connection tool may still point to the old port or a cached endpoint.
  • Instance status: overdue payment, expired subscription, or suspended resources can look like a network failure.
  • Security restrictions: the account may be under review, especially after a new registration or unusual payment attempt.
  • DNS or routing issues: the hostname may resolve correctly, but traffic is blocked before it reaches the instance.

A practical shortcut: if the same credentials work from one network path and fail from another, you are dealing with access control, not MySQL login data.

If You Are Still at the Buying Stage: Account, KYC, and Risk Control

Some users search for this error right after purchasing RDS, and the real blocker is not the whitelist at all. The account may still be unfinished. On Alibaba Cloud International, the following situations often slow down activation or block certain operations:

  • KYC not completed: the account cannot fully use paid cloud resources until identity checks pass.
  • Enterprise verification pending: a company account may need business registration documents and authorized signer information.
  • Payment review: the first card payment or top-up can be held for verification.
  • Risk control trigger: too many failed card attempts, mismatched billing details, or suspicious login geography can trigger a review.
  • Regional restrictions: some regions or products may require extra checks or support certain payment methods differently.

If you are blocked at this stage, retrying the same payment or opening and closing the order repeatedly usually makes the review slower. The practical approach is:

  1. Complete real-name verification before buying the instance.
  2. Use billing information that matches the cardholder or company documents.
  3. Prefer a stable payment method that your account already passed with.
  4. For enterprise use, prepare registration documents and a contact person who can answer compliance checks.
  5. If the account is newly created, keep the first order small and avoid multiple failed attempts.

Payment Methods and What They Mean for Renewals

A lot of RDS outages are actually renewal failures. The instance keeps running until billing or expiry catches up, then access suddenly stops and the user thinks the whitelist broke. That is why payment planning matters as much as network setup.

Payment Method Operational Speed Main Risk Best Fit
Credit or debit card Fastest for instant orders and renewals Risk control may reject the first charge or a cross-border payment Small teams, quick deployment, short renewal cycle
PayPal or similar wallet Usually fast if supported in the account region Availability varies by site and billing country Users who already have a verified wallet
Bank transfer / invoice Slower because finance approval is involved Processing delay can pause provisioning or renewal Enterprise procurement and annual contracts
Account balance / top-up Good for ongoing renewals once funded Balance can run low if no alert is set Teams that want predictable monthly control

For a production database, auto-renewal and balance alerts are not optional. They are cheaper than downtime. A short payment failure can be more expensive than a higher monthly cloud bill.

Cost Comparison: How People Usually Spend More Than Needed

The error itself is free to fix, but the access design around it can become expensive. Here is the cost pattern I usually see in real projects:

Access Approach Monthly Cost Pressure Operational Risk Comment
Direct public access from home or office IP Low High if the IP changes often Cheap, but fragile for dynamic networks
Fixed office egress via NAT or firewall Medium Lower if managed by IT Good for teams with stable network control
VPN to a fixed exit IP Medium to high Lower for remote workers Useful when staff work from different locations
ECS bastion host or jump server Medium Moderate Good when several admins need controlled access
Private VPC-only access Low to medium Lowest exposure Best when the app is already in Alibaba Cloud

If your team is small and the database is used only by cloud workloads, private access is usually the cleanest option. If remote humans need to connect, use a fixed egress IP instead of opening broad whitelist ranges. That keeps the security review simpler and reduces the chance of random lockouts.

Practical Decision Guide

Use this simple decision path:

  • If the app runs on ECS in the same VPC: use the private endpoint and whitelist the ECS side correctly.
  • If the user connects from a laptop: find the outbound public IP and whitelist only that address.
  • If the company network changes IP often: move to a fixed VPN or NAT exit IP.
  • If you need several admins: place a bastion host in front of RDS and restrict direct internet exposure.
  • If the account is new: finish KYC and payment verification before debugging network settings too deeply.

Alibaba Cloud Frequently Asked Questions

1. I added my laptop IP, but it still cannot connect. Why?

Because the IP shown on your laptop is usually a private LAN address. RDS sees the public outbound address of the network you are using. Check the public IP from the same connection path and whitelist that instead.

2. Can I whitelist 0.0.0.0/0 to make it work quickly?

Technically, in some environments you may be able to open access very widely, but it is a bad operational decision for a database. It increases exposure and makes later audit or incident reviews harder. Use a narrow IP or CIDR block instead.

3. Why does it work from ECS but not from my office?

The ECS instance is probably in the right network path already, while the office network exits through a different public IP. Whitelist the office egress IP, not the ECS IP, if you want both paths to work.

4. How long after editing the whitelist can I test again?

In most cases, only a short wait is needed, but do not assume the change is active instantly. Give it a few minutes, then test again with the correct endpoint and port.

Alibaba Cloud 5. My payment failed and now the instance looks unreachable. Is that related?

Yes, it can be. When an account is under billing hold, overdue renewal, or risk control review, access may be blocked even if the whitelist is correct. Check the account status and renewal record before changing network rules again.

Alibaba Cloud 6. What should I prepare before buying RDS if I know I will connect from multiple countries?

Plan the network path first. A rotating travel IP is painful to manage. A better setup is a VPN with a fixed egress, a bastion host, or private VPC-only access from cloud workloads. Also make sure your account KYC and payment method are stable enough to survive renewals without manual intervention.

What I Would Do in a Real Project

If I were troubleshooting this for a team, I would handle it in this order:

  1. Check whether the instance is active and not blocked by billing or review.
  2. Identify the real client network path and public egress IP.
  3. Confirm whether the connection should be public internet or private VPC.
  4. Add the smallest possible whitelist entry that matches the actual source.
  5. Retest with the exact endpoint the application uses, not just a GUI tool.
  6. Alibaba Cloud Set renewal alerts or auto-renewal so the fix is not lost later due to payment expiry.

That sequence saves time because it separates network mistakes from account and billing problems. In production, those two categories are often mixed together, and that is why teams waste hours on the wrong layer.

TelegramContact Us
CS ID
@cloudcup
TelegramSupport
CS ID
@yanhuacloud