An Azure relational database service.
The issue occurs because the connection to Azure SQL is successfully established at the TCP level, but the client does not complete the pre‑login/TLS handshake fast enough. Azure SQL only waits a few seconds for the client to send the initial login packets. If the client delays during the handshake most commonly due to high CPU usage, thread contention, or memory pressure in the App Service the service closes the connection. This results in the “TCP Provider, error: 35” and “connection reset by peer” errors. Intermittent network latency can also contribute to this failure pattern.
This behavior is expected and is part of Azure SQL’s protection mechanism to prevent slow‑drip or trickle‑attack‑style connections. It does not indicate an issue with Azure SQL itself.
Recommended Solution: Ensure that the App Service has enough CPU and memory headroom, and scale the App Service plan up or out if it is operating under load. These handshake failures are classified as transient, so implementing retry logic in the SQL client is strongly recommended; retries typically succeed once the CPU or network condition clears. If the issue continues after improving client performance, run the Azure SQL Connectivity Checker to confirm whether intermittent network latency or packet loss is involved.
This approach will prevent the handshake delays that lead to the connection resets and will stabilize the connection behavior.
Hope this helps, Please let us know if you have any questions and concerns.