A firewall (Windows Firewall, Azure NSG, or corporate network firewall) is silently dropping TCP packets to port 1433 instead of actively refusing them — this is the most common cause by far.. SQL Server is listening on a non-default port (e.g. a named instance using dynamic ports) but the client is connecting to 1433, which has nothing listening or is blocked.. The SQL Server Browser service is stopped on the target machine, so named-instance port resolution fails and the client falls back to 1433 which times out.. Network routing issues between the self-hosted integration runtime and the SQL Server — for example, a VNet peering misconfiguration, an ExpressRoute circuit that doesn't route to the SQL Server subnet, or a missing UDR (User Defined Route).. The SQL Server host is powered off, unreachable, or the SQL Server service itself has crashed — the OS never responds to the SYN because there is no process listening.. DNS resolves to a wrong or stale IP address (e.g. after a server migration), so the SYN goes to a host that either doesn't exist or doesn't have SQL Server.

Step 1: From the machine running the integration runtime (or the client), test raw TCP connectivity: Test-NetConnection -ComputerName -Port 1433 -InformationLevel Detailed. If TcpTestSucceeded is False and the command hangs before failing, a firewall is dropping packets.. Step 2: Verify which port SQL Server is actually listening on. Open SQL Server Configuration Manager → SQL Server Network Configuration → Protocols for → TCP/IP → IP Addresses tab → scroll to IPAll. Note the TCP Port (static) or TCP Dynamic Ports value.. Step 3: If using a named instance with dynamic ports, ensure SQL Server Browser is running: Get-Service SQLBrowser | Select Status. Start it with Start-Service SQLBrowser and set it to Automatic startup.. Step 4: Open the correct port on the Windows Firewall of the SQL Server machine: New-NetFirewallRule -DisplayName 'SQL Server 1433' -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow. For named instances, also open UDP 1434 for the Browser service.. Step 5: If the SQL Server is in Azure or behind an NSG, add an inbound security rule: az network nsg rule create --resource-group --nsg-name --name AllowSQL --priority 100 --destination-port-ranges 1433 --protocol Tcp --access Allow.. Step 6: Verify DNS resolution returns the correct IP: Resolve-DnsName . Compare the result with the actual IP of the SQL Server (ipconfig on the server or the Azure portal for Azure SQL). If stale, flush DNS or update your DNS record.. Step 7: If the connection works from the server itself but not from the IR, trace the network path: tracert from the IR machine to identify where packets are being dropped. Check each hop for firewall rules or routing gaps.

High severityconnection

SQL Server Error:
10060

Impact

Every pipeline activity targeting this SQL Server hangs for 15–30 seconds before failing, downstream datasets go stale, and scheduled refreshes consistently miss their SLA window — indicating a persistent network or firewall misconfiguration rather than a transient blip.

Each failed connection attempt burns the full TCP timeout (15–30s) before the activity fails, so pipelines are not just broken — they are slow to fail. ADF retry policies compound the delay: 3 retries × 30s timeout = 90 seconds of dead wait before the pipeline finally reports failure. Downstream tables that depend on this source go stale, Power BI datasets show outdated numbers, and any SLA based on data freshness is breached. If the pipeline has a tumbling window trigger, failed windows queue up and cause a backlog that needs manual catchup after the fix.

What does this error mean?

Error 10060 is a Winsock timeout: the client sent a TCP SYN packet to the SQL Server host and port, but never received a SYN-ACK back within the connection timeout window (default 15–30 seconds depending on the driver). In a data-pipeline context — Azure Data Factory, Power BI refresh, or SSIS — this means the integration runtime cannot establish a TCP handshake with the database at all. The symptom is a pipeline activity that hangs for the full timeout duration and then fails with 'A connection attempt failed because the connected party did not properly respond after a period of time'. Unlike error 10061 (connection refused), 10060 indicates silence on the wire: packets are being dropped, not rejected.

Common causes

1A firewall (Windows Firewall, Azure NSG, or corporate network firewall) is silently dropping TCP packets to port 1433 instead of actively refusing them — this is the most common cause by far.
2SQL Server is listening on a non-default port (e.g. a named instance using dynamic ports) but the client is connecting to 1433, which has nothing listening or is blocked.
3The SQL Server Browser service is stopped on the target machine, so named-instance port resolution fails and the client falls back to 1433 which times out.
4Network routing issues between the self-hosted integration runtime and the SQL Server — for example, a VNet peering misconfiguration, an ExpressRoute circuit that doesn't route to the SQL Server subnet, or a missing UDR (User Defined Route).
5The SQL Server host is powered off, unreachable, or the SQL Server service itself has crashed — the OS never responds to the SYN because there is no process listening.
6DNS resolves to a wrong or stale IP address (e.g. after a server migration), so the SYN goes to a host that either doesn't exist or doesn't have SQL Server.

How to fix it

1Step 1: From the machine running the integration runtime (or the client), test raw TCP connectivity: Test-NetConnection -ComputerName <server> -Port 1433 -InformationLevel Detailed. If TcpTestSucceeded is False and the command hangs before failing, a firewall is dropping packets.
2Step 2: Verify which port SQL Server is actually listening on. Open SQL Server Configuration Manager → SQL Server Network Configuration → Protocols for <instance> → TCP/IP → IP Addresses tab → scroll to IPAll. Note the TCP Port (static) or TCP Dynamic Ports value.
3Step 3: If using a named instance with dynamic ports, ensure SQL Server Browser is running: Get-Service SQLBrowser | Select Status. Start it with Start-Service SQLBrowser and set it to Automatic startup.
4Step 4: Open the correct port on the Windows Firewall of the SQL Server machine: New-NetFirewallRule -DisplayName 'SQL Server 1433' -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow. For named instances, also open UDP 1434 for the Browser service.
5Step 5: If the SQL Server is in Azure or behind an NSG, add an inbound security rule: az network nsg rule create --resource-group <rg> --nsg-name <nsg> --name AllowSQL --priority 100 --destination-port-ranges 1433 --protocol Tcp --access Allow.
6Step 6: Verify DNS resolution returns the correct IP: Resolve-DnsName <server>. Compare the result with the actual IP of the SQL Server (ipconfig on the server or the Azure portal for Azure SQL). If stale, flush DNS or update your DNS record.
7Step 7: If the connection works from the server itself but not from the IR, trace the network path: tracert <server-ip> from the IR machine to identify where packets are being dropped. Check each hop for firewall rules or routing gaps.

Example log output

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.) [SqlException 10060]
System.Data.SqlClient.SqlException (0x80131904): A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.0.1.50:1433

Frequently asked questions

How does error 10060 differ from error 10061?

Error 10060 is a timeout (no response) — typically caused by a firewall silently dropping the packet. Error 10061 is a refused connection — the target host actively sent a TCP RST, usually because SQL Server is not running or not listening on that port. 10060 hangs for the full timeout; 10061 fails immediately.

Can error 10060 appear in Azure Data Factory?

Yes — most commonly when a self-hosted integration runtime tries to reach an on-prem SQL Server and a firewall blocks port 1433. Check: (1) Windows Firewall on the SQL Server machine, (2) any corporate firewall between the IR and the server, (3) NSG rules if the IR or SQL Server is in a VNet. Also verify the IR machine can resolve the SQL Server hostname to the correct IP.

Will retrying fix a 10060 error?

No. Error 10060 is almost always caused by a persistent misconfiguration (blocked port, wrong IP, stopped service), not a transient network glitch. Retries will each hang for the full timeout and then fail. Fix the underlying firewall or routing issue before retrying.

What is the default TCP timeout for SQL Server connections?

ADO.NET defaults to 15 seconds (Connection Timeout=15 in the connection string), ODBC defaults to 15–30 seconds depending on the driver. You can increase it with Connection Timeout=60, but for 10060 this just means waiting longer before the same failure — it does not fix the root cause.

Source · learn.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-events-and-errors