- Error number
- 10060
- Severity
- 20 (fatal: the connection ends; may indicate a serious problem)
- State
- 0
- Product
- Microsoft SQL Server Database Engine
- Versions
- Any SQL Server version reached over TCP/IP through SQL Server client drivers
- Category
- Connectivity
- Last reviewed
- 23 October 2026
On this page
What it means
Client error 10060 means the TCP connection request to SQL Server got no reply at all within the Windows connect timeout, usually because a firewall silently drops the packets or the address or port is wrong.
This page covers the client error 10060, the Windows Sockets error WSAETIMEDOUT; there is no SQL Server engine message 10060. When a client opens a TCP connection it sends a SYN packet and waits. If the host answers with a reset, you get 10061 (actively refused). If nothing comes back at all, Windows retries and then gives up with 10060, about 21 seconds on our lab machine.
Silence is the clue: something is dropping the packets rather than refusing them. That is typically a firewall on the server, the client or the network, an IP address that no machine answers on, or a route that goes nowhere. Note that the driver has its own login timeout (15 seconds by default in SqlClient, per Microsoft): if it expires before Windows gives up, you see "The wait operation timed out" instead of 10060, as our sqlcmd run shows. Both point to the same network problem.
Common causes
- A firewall on the SQL Server host blocks the TCP port without sending a rejection (the Windows Firewall default for blocked inbound traffic).
- A network firewall, security group or VPN policy between client and server drops traffic to the port.
- The connection string uses a wrong or stale IP address, or the DNS name resolves to an address that no longer exists.
- The instance listens on a different port than the client uses, and that port is filtered rather than closed.
- For named instances, the Browser returned a dynamic port that the firewall does not allow.
Diagnose it
Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.
Confirm the port the instance listens on (on the server)
SELECT ip_address, port, type_desc, state_desc
FROM sys.dm_tcp_listener_states
WHERE type_desc = 'TSQL';The port the client must reach. Ports only on 127.0.0.1 or ::1 are local-only (the dedicated admin connection is on 1434 there).
Confirm from the error log that TCP is enabled
EXEC sp_readerrorlog 0, 1, N'Server is listening on';A line such as Server is listening on [ 'any' <ipv4> 1433]. If only loopback addresses appear, remote TCP clients cannot connect.
Test the TCP path from the client
In PowerShell on the client: Test-NetConnection SQLPROD01 -Port 1433. TcpTestSucceeded : False after a long pause confirms packets are dropped; compare with the same test run on the server itself. Microsoft also suggests tracert and PortQry to find where the traffic stops.
How to fix it
Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.
Correct the address and port in the connection string
Client or network sideUse the server name or IP address and the port confirmed on the server, for example tcp:SQLPROD01,1433. Flush stale DNS with ipconfig /flushdns after an address change.
Allow the SQL Server port through the server firewall
Changes configurationOn the SQL Server host, allow inbound TCP on the instance port (and UDP 1434 if clients use named instances with SQL Server Browser).
New-NetFirewallRule -DisplayName 'SQL Server 1433' -Direction Inbound -Protocol TCP -LocalPort 1433 -Action AllowOpen the path in network firewalls and security groups
Changes configurationIf the server firewall is open and Test-NetConnection still times out, the drop is on the network: ask the network team to allow the client subnet to reach the instance port, or fix the cloud security group or network security group rule.
Give named instances a static port
Changes configurationA dynamic port can change at restart and fall outside firewall rules. Set a static port in SQL Server Configuration Manager and open exactly that port.
Caution: Changing the port needs a service restart, which disconnects every session; schedule it.
Examples
Connecting to an address that never answers
Reproduced on 2026-10-23 against 10.255.255.1, a private address with no host behind it. With a 5 second login timeout, ODBC Driver 18 stops before Windows does and reports the wait timeout; a raw TCP connect to the same address (no driver timeout) fails with Winsock 10060 after about 21 seconds, shown in the variants above.
sqlcmd -S tcp:10.255.255.1,1433 -E -C -l 5Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : TCP Provider: The wait operation timed out. . Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login timeout expired. Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : A network-related or instance-specific error has occurred while establishing a connection to tcp:10.255.255.1,1433. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online..
How to prevent it
Record every instance's address and static port, and manage firewall rules for them as code alongside the server build, so moving or rebuilding a server does not leave clients pointing at silence.
After any network change, test from each application host with Test-NetConnection and sqlcmd before traffic is switched.
Common questions
What is the difference between 10060 and 10061?
10061 means the host answered and refused the port (nothing listening, a fast failure). 10060 means nothing answered at all, so the client waited until it timed out; that almost always points to a firewall dropping packets or a wrong address.
Why do I see "The wait operation timed out" instead of 10060?
The driver has its own login timeout. If it expires before Windows abandons the TCP attempt, the driver reports its wait timeout (Windows error 258). The cause is the same unanswered connection.
Will increasing the connection timeout fix error 10060?
No. A healthy connection opens in milliseconds. A longer timeout only makes the failure slower; find and open the blocked path instead.
Learn more on CodeWithSQL
Official documentation
- Fix network-related or instance-specific errors in SQL Server (Microsoft Learn)
- Troubleshoot timeout expired errors (Microsoft Learn)
- Configure the Windows Firewall to allow SQL Server access
Last technically reviewed 23 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4), ODBC Driver 18 for SQL Server. Message text checked against the engine's sys.messages catalogue.