On this page
Why it happens
Error 10061 is a TCP-level rejection, not a lookup failure. The client resolved the host name to an address, opened a TCP socket to the target machine, and the machine answered with a reset because no process was listening on the requested port. In plain terms: you found the computer, but SQL Server was not accepting connections on that port.
This is more specific than error 53. Error 53 usually means the name or host could not be found at all (DNS, wrong machine name, network path blocked). Error 10061 means the host was found and the port was reached, but it was refused. It is also different from a connection timeout: a refusal comes back immediately with a reset, while a timeout is silence until the client gives up.
Common causes are the SQL Server service being stopped, the TCP/IP protocol being disabled so the engine never listens on any port, the engine listening on a port other than the one the client used, a named instance whose dynamic port the client could not discover because SQL Server Browser is off, or a firewall on the target that sends a reset instead of dropping the packet.
Examples
Connecting with sqlcmd while the service is stopped
-- The host name resolves, but the SQL Server engine is not running.
sqlcmd -S tcp:sqlhost01,1433 -U app_user -P *****Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : A network-related or instance-specific error occurred while establishing a connection to SQL Server. (provider: TCP Provider, error: 0 - No connection could be made because the target machine actively refused it.) (Microsoft SQL Server, Error: 10061).
A connection string pointing at the wrong port
-- The engine listens on 1433, but the client tries 1435.
Server=tcp:sqlhost01,1435;Database=Sales;User Id=app_user;Password=*****;A network-related or instance-specific error occurred while establishing a connection to SQL Server. (provider: TCP Provider, error: 0 - No connection could be made because the target machine actively refused it.) (Microsoft SQL Server, Error: 10061)
A named instance whose port could not be discovered
-- SQL Server Browser (UDP 1434) is off, so the client cannot find the
-- dynamic port for the SQLEXPRESS instance and falls back to a refused TCP attempt.
sqlcmd -S sqlhost01\SQLEXPRESS -EA network-related or instance-specific error occurred while establishing a connection to SQL Server. (provider: TCP Provider, error: 0 - No connection could be made because the target machine actively refused it.) (Microsoft SQL Server, Error: 10061)
How to fix it
Start the SQL Server service
If the engine is not running, nothing is listening and every TCP attempt is refused. Start the service (its name includes the instance, for example MSSQLSERVER for the default instance or MSSQL$SQLEXPRESS for a named one) and set it to start automatically so a reboot does not bring the refusal back.
-- From an elevated command prompt on the SQL Server machine:
net start MSSQLSERVER
-- Named instance:
net start "MSSQL$SQLEXPRESS"
-- Confirm it is listening (should show the SQL Server port):
netstat -ano | findstr :1433Enable TCP/IP and confirm the listening port
If TCP/IP is disabled the engine listens on no TCP port at all. Open SQL Server Configuration Manager, expand SQL Server Network Configuration, enable the TCP/IP protocol, and under its IP Addresses tab read the IPAll TCP Port so you know exactly where the engine listens. Restart the service after changing this.
-- SQL Server Configuration Manager path:
-- SQL Server Network Configuration > Protocols for <INSTANCE>
-- Right-click TCP/IP > Enable
-- TCP/IP > Properties > IP Addresses tab > IPAll > TCP Port = 1433
-- After restarting, verify the port the engine chose from T-SQL:
SELECT local_tcp_port
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;Connect using the correct port
Once you know the real listening port, point the client at it explicitly with the Server,Port syntax. The tcp: prefix forces the TCP protocol and skips protocol negotiation, which avoids a fallback that ends in a refusal.
-- sqlcmd with an explicit port:
sqlcmd -S tcp:sqlhost01,1433 -U app_user -P *****
-- ADO.NET / OLE DB connection string:
Server=tcp:sqlhost01,1433;Database=Sales;User Id=app_user;Password=*****;For named instances, start SQL Server Browser or specify the port
Named instances often use a dynamic port. The client discovers it by asking SQL Server Browser over UDP 1434; if Browser is stopped the discovery fails and the fallback TCP attempt is refused. Start the Browser service, or skip discovery entirely by giving the instance a static port and connecting to Host,Port directly.
-- Start the discovery service on the SQL Server machine:
net start SQLBrowser
-- Or bypass discovery by connecting to the static port directly:
sqlcmd -S tcp:sqlhost01,1434 -U app_user -P *****Open the SQL Server port in the firewall
A firewall that rejects (rather than silently drops) packets on the SQL Server port produces an immediate refusal. Add an inbound rule allowing TCP on the listening port, and UDP 1434 as well when you rely on SQL Server Browser for named instances.
-- Run on the SQL Server machine (elevated PowerShell):
New-NetFirewallRule -DisplayName "SQL Server 1433" -Direction Inbound `
-Protocol TCP -LocalPort 1433 -Action Allow
-- For named-instance discovery:
New-NetFirewallRule -DisplayName "SQL Browser 1434" -Direction Inbound `
-Protocol UDP -LocalPort 1434 -Action AllowHow to prevent it
Pin the engine to a fixed TCP port instead of a dynamic one, and document that port with the server so every connection string and firewall rule can reference it. Keep the SQL Server service on automatic start so a reboot never leaves the port unattended, and enable TCP/IP as part of your standard build so the engine always listens. For permission and access hardening around your endpoints, see the SQL security guide.
Script your firewall rules so the listening port (and UDP 1434 for named-instance discovery) is opened the same way on every machine, and monitor the service and port with a lightweight health check. When a client cannot connect, this turns a scramble into a quick lookup of a known, documented value.
Common questions
What is the difference between error 10061 and error 53?
Error 53 means the host or name could not be found at all, so the client never reached a machine (bad name, DNS failure, or a blocked network path). Error 10061 is more specific: the name resolved and the target machine was reached over TCP, but nothing was listening on the port so the connection was actively refused. In short, 53 is "computer not found" while 10061 is "computer found, port refused."
How is error 10061 different from a connection timeout?
A refusal (10061) comes back immediately: the target machine answers the TCP handshake with a reset because no process is listening on that port. A timeout instead means the client got no answer at all and waited until it gave up, which usually points to a firewall dropping packets, a wrong address, or an overloaded server rather than a closed port.
How do I fix SQL Server error 10061?
Confirm the SQL Server service is running, enable TCP/IP and read the IPAll TCP Port in SQL Server Configuration Manager, then connect to that exact port using the Server,Port syntax such as tcp:host,1433. For named instances, start SQL Server Browser (UDP 1434) or connect to a static port directly, and open the port in the firewall on the SQL Server machine.