MySQL flexible server - Can't connect
From webapp and from virtual developer VM in same vnet can't connect anymore. Started several days ago, no changes to webapp code or VM. Connections appear to timeout. No changes to Azure Database for MySQL flexible server, webapp code, or VM.
Azure Database for MySQL
-
Adithya Prasad K • 750 Reputation points • Microsoft External Staff
2025-04-28T17:12:46.9566667+00:00 Hi Chris Wheat
Since both your web app and your developer VM (which reside in the same virtual network) suddenly can’t connect to your Azure Database for MySQL Flexible Server despite no changes to the code or the database configuration, here are some troubleshooting steps and potential causes to consider:
- DNS Resolution Issues: Even within the same virtual network, your clients rely on correct DNS resolution to reach the MySQL endpoint. If your Flexible Server is deployed with private access, the server’s DNS name should resolve to its private IP address. From your VM, run a tool like
nslookup
ordig
to verify the resolved IP. An incorrect DNS resolution (for example, if it’s still returning a public IP) might cause your connections to time out because the routing from your VNet is different from expected. - Network Routing and Service Endpoints: Verify that there have been no inadvertent changes in your virtual network’s configuration—this includes route tables and service endpoints. Since your web app and your VM are in the same VNet, confirm that the VNet integration (or subnet delegation, if applicable) for the web app hasn’t been affected by any updates to the VNet policies or NSG rules. Even if no manual changes were made, Azure might have rolled out an update that affects routing in some scenarios.
- NSG and Firewall Considerations: Although you mentioned no changes were made to the database or the application/config, it’s worthwhile to double-check the Network Security Group (NSG) rules and any firewall rules on your VM. In some cases, changes in the underlying Azure fabric may require revalidating that NSG rules still permit outbound MySQL traffic (typically on port 3306). Also, if your MySQL Flexible Server is configured for private access, ensure that no new rules are inadvertently blocking access.
- Server or Platform-Level Changes: Confirm with the Azure Service Health dashboard to see if there have been any platform-level updates or incidents in the region where your MySQL Flexible Server is hosted. Sometimes unexpected connectivity issues arise from transient service updates or outages on the Azure side.
- Connection Testing and Diagnostics: – From the developer VM, try using a tool like Telnet or PowerShell’s
Test-NetConnection
to check if the MySQL port is reachable:
– On your web app, if possible, enable detailed logging or diagnostic capture to confirm whether the issue is strictly at the network level or if it’s filtering at the application layer.Test-NetConnection -ComputerName <mysql-hostname> -Port 3306
Since this behavior started several days ago without any apparent changes on your part, it’s likely the result of either a transient Azure networking issue or updated routing/DNS behavior. If after verifying DNS, NSG, VNet integration, and service health the problem persists, I recommend opening a support ticket with Azure—they can help determine whether some backend change or a subtle misconfiguration is now affecting connectivity.
I hope this gives you a clear roadmap to diagnose and resolve the timeout issue. Feel free to share additional details if you run into any other clues or if any particular step yields unexpected results!
I would request you to refer the below mentioned links for more information
connection issues to Azure Database for MySQL - Flexible Server
Troubleshoot connectivity issues in Azure Database
Connect an App Services Web app to Azure Database for MySQL - DNS Resolution Issues: Even within the same virtual network, your clients rely on correct DNS resolution to reach the MySQL endpoint. If your Flexible Server is deployed with private access, the server’s DNS name should resolve to its private IP address. From your VM, run a tool like
-
Jose Benjamin Solis Nolasco • 1,476 Reputation points
2025-04-28T18:45:02.2733333+00:00 The most probable cause is a DNS resolution issue with the private access (VNet Integration) configuration. When using private access, clients rely on private DNS to resolve the server's fully qualified domain name (FQDN) to its private IP address. If the private DNS zone is misconfigured or not linked to your vnet, connections will time out.
Steps to Resolve
Here’s what you can do to fix the issue:
- Verify VNet Configuration:
- Ensure your webapp, VM, and MySQL server are in the same vnet. Check this in the Azure portal under your MySQL server's Networking tab, confirming it’s set to Private access (VNet Integration).
- Check Private DNS Zone:
- Go to the Azure portal, navigate to your MySQL server's Networking tab, and verify that your vnet is listed under the Virtual Network Links for the private DNS zone (e.g., ending with mysql.database.azure.com).
- Test DNS Resolution:
- From your webapp or VM, run nslookup <your-server-name>.mysql.database.azure.com to see if it resolves to the correct private IP. If it fails, there’s a DNS issue.
- Ensure Azure DNS Usage:
- Check your vnet’s DNS servers blade in the Azure portal to ensure it uses Azure-provided DNS servers. If using custom DNS, set up a conditional forwarder for mysql.database.azure.com to IP 168.63.129.16.
- Review Recent Changes:
- Check the Azure activity log for any recent updates or changes that might have affected your vnet or DNS configuration, especially around when the issue started.
- Check Network Rules:
- Verify there are no network security groups (NSGs) or user-defined routes (UDRs) blocking traffic on port 3306, though this is less likely given no changes were reported.
- Review Connection Strings:
- Ensure your connection strings use the correct FQDN, like <servername>.mysql.database.azure.com, and include necessary parameters like port 3306.
😊 If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find solutions more easily. Thanks!
- Verify VNet Configuration:
-
CW • 0 Reputation points
2025-04-29T06:26:28.65+00:00 My Flexible server networking:
The VNET overview:
The VNET Subnets:
The DEV VM Networking:
PowerShell From the Dev box:
And I can't figure out how to open a ticket with Azure support?
-
Adithya Prasad K • 750 Reputation points • Microsoft External Staff
2025-04-29T18:56:43.18+00:00 Hi Chris Wheat
To open a support ticket with Azure for your Azure Database for MySQL Flexible Server connection issues, follow these steps:Sign in to the Azure Portal: Go to portal.azure.com and log in with your Azure account credentials.
Navigate to Help + Support:
In the Azure Portal, click on the question mark (?) icon in the top-right corner of the toolbar.
Select Help + support from the dropdown menu.
Create a New Support Request:
In the Help + support page, click on New support request.
Alternatively, you can search for "Support" in the search bar at the top of the portal and select Support.
Fill Out the Support Request Form
Step 1: Basics:
Issue type: Select Technical.
Subscription: Choose the subscription associated with your Azure Database for MySQL Flexible Server.
Service: Select Azure Database for MySQL.
Resource: Choose the specific MySQL Flexible Server instance experiencing the issue.
Summary: Provide a brief description, e.g., "Unable to connect to Azure Database for MySQL Flexible Server from Web App and VM in the same VNet; connections timeout."
Problem type: Select Connectivity or a relevant category.
Problem subtype: Choose an appropriate subtype, such as Cannot connect to server.Step 2: Details:
Provide detailed information about the issue, including:
The fact that the issue started several days ago with no changes to the Web App code, VM, or MySQL Flexible Server configuration.
Mention that both the Web App and VM are in the same VNet and connections are timing out.
Include error messages or logs (e.g., attach or reference the logs from the provided URLs if possible).
Specify the troubleshooting steps you’ve already tried (e.g., checking VNet settings, firewall rules, or NSGs).
Timeframe: Indicate when the issue started.
Attachments: Upload any relevant logs or screenshots. Note that the attachment URLs you provided (e.g., learn-attachment.microsoft.com) are not publicly accessible, so you’ll need to download those files and upload them directly to the support ticket.Support plan: Select your support plan (e.g., Developer, Standard, Professional Direct). If you’re using a free account or don’t have a paid support plan, you may have limited options, but you can still file a technical support request for Azure services.
Review the details and click Create to submit the ticketTrack the Support Request:
After submission, you’ll receive a confirmation email with a support ticket number.
You can track the status of your ticket in the Help + support section under Manage support requests. -
Adithya Prasad K • 750 Reputation points • Microsoft External Staff
2025-04-30T16:41:17.3666667+00:00 Hi CW,
We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help. -
Adithya Prasad K • 750 Reputation points • Microsoft External Staff
2025-05-02T16:03:44.0733333+00:00 Hi CW, We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Sign in to comment