TCP Provider: Error code 0x2746 on Linux while trying to connect to Azure SQL

[MartinLukas-oss]

Describe the bug

Connecting to Azure SQL from a Linux container hosted in AKS fails with a TCP connection reset during the TLS
handshake starting from mssql-python==1.5.0. The same code and connection string work with
mssql-python==1.4.0 from exactly the same hosting environment. The failure is independent of the base OS and OpenSSL version (tested on
Debian Bookworm and Debian Trixie — see matrix below).

Exception message:
mssql_python.exceptions.OperationalError: Driver Error: Communication link failure;
DDBC Error: [Microsoft]TCP Provider: Error code 0x2746

Stack trace:
  File "mssql_python/db_connection.py", line 55, in connect
    conn = Connection(
  File "mssql_python/connection.py", line 378, in __init__
    _raise_connection_error(e)
  File "mssql_python/connection.py", line 89, in _raise_connection_error
    raise exc from None
mssql_python.exceptions.OperationalError: Driver Error: Communication link failure;
DDBC Error: [Microsoft]TCP Provider: Error code 0x2746

To reproduce

Dockerfile

FROM python:3.12-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
    libltdl7 libkrb5-3 libgssapi-krb5-2 \
  && rm -rf /var/lib/apt/lists/*

RUN pip install --no-cache-dir "mssql-python==1.5.0" azure-identity

Python

import mssql_python

conn = mssql_python.connect(
    "Server=tcp:<server>.database.windows.net,1433;"
    "Database=<db>;"
    "Authentication=ActiveDirectoryDefault;"
    "Encrypt=yes;TrustServerCertificate=no;"
)

The container runs on Kubernetes with Azure Workload Identity (azure.workload.identity/use: "true"),
so DefaultAzureCredential resolves via WorkloadIdentityCredential using the projected
AZURE_FEDERATED_TOKEN_FILE.

Expected behavior

Successful connection, as produced by mssql-python==1.4.0 under identical conditions.

Further technical details

Python version: 3.12 / 3.14
SQL Server version: Azure SQL Database
Operating system: Docker container (Linux)

Additional context

The regression seems to come from the compiled ddbc_bindings Linux binary — not in the OS,
OpenSSL version, or authentication layer.

Version matrix

Base image	OpenSSL	mssql-python	Result
python:3.12-slim (Debian Bookworm)	3.0.x	1.4.0	✅ connects
python:3.12-slim (Debian Bookworm)	3.0.x	1.5.0	❌ 0x2746
python:3.12-slim (Debian Bookworm)	3.0.x	1.7.1	❌ 0x2746
python:3.14-slim-trixie (Debian Trixie)	3.3.x	1.4.0	✅ connects
python:3.14-slim-trixie (Debian Trixie)	3.3.x	1.7.1	❌ 0x2746

What was ruled out

• The error occurs during the TLS handshake, before any authentication token is sent —
  confirmed by the TCP-reset error code (0x2746 = WSAECONNRESET).
• Base OS / OpenSSL version is not the cause. The failure reproduces on Debian Bookworm
  (OpenSSL 3.0.x) and Debian Trixie (OpenSSL 3.3.x). 1.4.0 connects successfully on both.
• System OpenSSL configuration has no effect. Modifying SECLEVEL, setting OPENSSL_CONF,
  and excluding DHE cipher suites (!kDHE) all had no impact — the ddbc_bindings binary
  appears to be compiled with OPENSSL_NO_AUTOLOAD_CONFIG or the failing TLS path bypasses
  config-controlled code entirely.

Related: #461 reports the same 0x2746 on Linux against a Fabric SQL endpoint (opened
March 2026, still open). This report demonstrates the issue also affects standard Azure SQL
Database.

[github-actions]

Hi @MartinLukas-oss, thank you for opening this issue!

Our team will review it shortly. We aim to triage all new issues within 24-48 hours and get back to you.

If you have additional information to share, please feel free to update the issue.

Thank you for your patience!

[denys-nva]

I see the issue also happening in Microsoft Fabric Runtime 1.3 for mssql-python == 1.7.1, previous version (1.6.0) didn't have the issue.
OperationalError: Driver Error: Communication link failure; DDBC Error: [Microsoft]TCP Provider: Error code 0x2746