Persistent Azure App Service to Azure SQL pre-login timeout (SqlException -2) despite successful DNS, TCP and firewall checks

Thank you. I checked the available App Service TCP diagnostics for the supplied UTC window.

For the selected App Service instance, both TCP States and Outbound Sockets remained at 0 throughout the displayed period, including 2026-09-23 06:20–06:21 UTC. No spike or high outbound-connection count was visible.

The dedicated SNAT Port Exhaustion detector is unavailable because the App Service is currently on the Basic SKU; the portal only recommends upgrading and does not provide a detector result. Therefore, the available telemetry does not support SNAT exhaustion, although the Basic-tier limitation prevents it from being conclusively excluded.

The SQL connection policy was also already changed to Proxy for a controlled test, confirmed as effective, and the readiness endpoint still returned HTTP 503. It was then rolled back and verified as Default.

Could you please advise how to determine whether the Azure SQL gateway received the pre-login attempt during this exact window:

2026-09-23T06:20:38.4668729Z–2026-09-23T06:20:55.7567144Z

If the gateway did not receive it, which App Service platform diagnostic can identify where the outbound connection stopped?

From Kudu/console, test the actual SQL hostname from the affected App Service instance:

nslookup <server>.database.windows.net

and

tcpping <server>.database.windows.net:1433

The important point is to verify the resolved IP address and confirm that it is the expected SQL endpoint

If you can provide the output of nslookup/tcpping from the production App Service and the corresponding output from the working environment, we can narrow down whether this is a DNS, routing, firewall/NSG, Private Endpoint, or SQL-side access-path issue.

Also, are you able to connect to the prod SQL database from SSMS or VsCode manually?

I ran the checks directly from the SSH console of the affected production Linux App Service instance.

DNS resolution succeeded. The SQL hostname resolved through the expected Azure SQL public gateway CNAME chain in Sweden Central:

dentalsaas-prod-sql.database.windows.net → dataslice2.swedencentral1-a.control.database.windows.net → Azure Traffic Manager → cr8.swedencentral1-a.control.database.windows.net

I have omitted the resolved public IP address from this public post.

The supplied tcpping utility could not run because its bc dependency is not installed in the App Service container. nc is also unavailable. I therefore performed the equivalent bounded TCP test using Bash /dev/tcp:

timeout 10 bash -c '</dev/tcp/dentalsaas-prod-sql.database.windows.net/1433'

Result:

TCP_1433=reachable

Therefore, DNS resolution and TCP connectivity to the Azure SQL gateway on port 1433 both succeed from the affected production App Service instance.

I can also connect to the production database through Azure Portal Query Editor and execute metadata queries successfully. The external database principal exists and has effective CONNECT permission. However, the production application still fails during SqlConnection.Open / pre-login with Microsoft.Data.SqlClient.SqlException Number -2, State 0, Class 11, before any SQL command executes.

I do not currently have a separate working App Service environment for a direct comparison. Given that DNS and TCP/1433 work from the affected instance, what should we inspect next to determine whether the timeout occurs during TLS/pre-login negotiation, within Microsoft.Data.SqlClient, or in the Azure SQL gateway path?

Could you please confirm if you are using App Registration or Management Identity?

Also have you used the below SQL for creating the App Reg / MI? And, If you are using User Assigned Managed Identity, you might pass that in the Connection String too.

**
**That identity must then be created as a user in the target database, for example:

CREATE USER [<managed-identity-name>]
FROM EXTERNAL PROVIDER;

and then the required permissions/roles should be granted, for example:

ALTER ROLE db_datareader ADD MEMBER [<managed-identity-name>];
ALTER ROLE db_datawriter ADD MEMBER [<managed-identity-name>];

The exact permissions should of course follow the application's least-privilege requirements.

If an App Registration/service principal is being used, verify that the correct service principal/object identity was created in SQL. Don't assume that the App Registration's client ID alone identifies the SQL database principal.

Also check:

SELECT
    name,
    type_desc,
    authentication_type_desc
FROM sys.database_principals
WHERE name = '<identity-name>';