Could Not Open a Connection to SQL Server: Error 53 and Named Pipes Error 40

The client could not find a SQL Server at the name you typed. Nothing reached the instance, so no login was checked and its error log has nothing to show. Check the name first, then the port, then the protocol.

SSMS shows the same text and adds (Microsoft SQL Server, Error: 53), the form listed on the network-related error page on MS Docs. Error 53 is the Windows reason underneath: The network path was not found.

Which Form You Have

The client tries each enabled protocol in turn and reports the last one that failed, which is why Named Pipes Provider appears even when you never asked for Named Pipes. Find your message:

• Named Pipes Provider, error: 40 with Error 53, or [53] from sqlcmd. The client reached nothing: the name did not resolve, or nothing answered at the address it resolved to. Start at Check the Name First.
• TCP Provider, error: 0 - No such host is known (Error 11001). The same fault seen through TCP: DNS has no record for the name. Check the Name First.
• TCP Provider: The wait operation timed out, The remote computer refused the network connection (1225) or Error 10060. The name resolved; nothing answered on the port. Then the Port.
• SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified. A named instance whose port could not be looked up. Named Instances and the Browser.
• Named Pipes Provider, error: 40 with Error 2. The machine answered and has no SQL Server pipe. Then the Protocol.

Through System.Data.SqlClient the same name gives the message in the box above, with Number 53 and Class 20.

Decode the Number in Brackets

The bracketed number is a Windows error, not a SQL Server one. net helpmsg turns it into words on any Windows machine, and the same texts are in the system error code list on MS Docs:

• 53, the client could not reach the machine: a bad name, or nothing at that address. Check the name, then the port.
• 64, seen on the lab in place of 53 for the same faults. Treat it as 53.
• 2, the machine is there and has no SQL Server pipe. Check the protocol.
• 1326, Named Pipes reached the machine and Windows refused your account. Documented, not reproduced here: MS Docs gives the fix as adding the user to the Users group on the SQL Server machine.

Check the Name First

From the machine that is failing, not from yours, ask DNS for the exact name in the connection string:

Resolve-DnsName SQLPROD01

DNS name does not exist settles it: fix the name or the DNS record. Forcing TCP with tcp: in front of the name shows the same fault without the Named Pipes wording, No such host is known (Error 11001).

If the name resolves, connect by IP address. If the IP works and the name does not, MS Docs points at stale name resolution on the client: run ipconfig /flushdns, then check the HOSTS file and any client alias in SQL Server Configuration Manager, which can send a good name to an old server. How to Get the SQL Server IP Address gives you the right IP to test with. If the name resolves to the right IP and you still get 53, the machine is not answering at that address: check the port.

Then the Port

The name resolves, so test the port from the failing client with Test-NetConnection:

Test-NetConnection SQLPROD01 -Port 1433

TcpTestSucceeded : False means nothing answered: the instance listens on another port, the service is down, or a firewall is in the way. The walkthrough is Testing Remote Port Connectivity with PowerShell, and the port to expect is in SQL Server Default Ports. On the server itself, How to Check Listening Ports on Windows shows what SQL Server is really listening on.

That port was closed, not firewalled, and sqlcmd still reports a timeout. System.Data.SqlClient against the same port says The remote computer refused the network connection (1225). A firewall that drops the packets gives Error 10060, the timeout form on the MS Docs page; the ports to open are in Configure a Windows Firewall for Database Engine Access.

Without a port or a tcp: prefix, a machine that does not answer at all comes back as error 53 instead, because Named Pipes is tried last. On the lab, an IP address with no machine behind it gave Error 53 through System.Data.SqlClient after the full 30 second timeout.

Named Instances and the Browser

A name like SQLPROD01\SALES has no port in it. The client asks the SQL Server Browser service on UDP 1434 which port the instance uses, as MS Docs describes. No answer gives error 26, Error Locating Server/Instance Specified, while the default instance on the same machine still connects. sqlcmd shows it as [xFFFFFFFF].

• The Browser service is stopped on the server. Start it.
• UDP 1434 is blocked between client and server. Open UDP, not TCP.
• The instance name is wrong. A name that does not exist gets the same error 26.

Connecting with the port, SQLPROD01\SALES,50123, skips the Browser entirely: if that works, the Browser or UDP 1434 is the problem. The full diagnosis and a real Error 26 capture are in Error Locating Server/Instance Specified (Error 26).

Then the Protocol

The name resolves and the machine answers, but the instance does not accept the protocol the client used. With TCP/IP disabled on the server, remote clients fail while local connections keep working over shared memory. Turning it on, and the service restart that change needs, is in Enabling TCP Connections in SQL Server; MS Docs confirms a protocol change only takes effect after a restart.

Forcing Named Pipes with np: against a machine that has Named Pipes turned off gives the error 40 message with Error 2, The system cannot find the file specified: the machine was found, the pipe was not. That only matters when an application or an alias forces Named Pipes.

If the connection works with tcp: in front of the name but fails without it, the client is trying another protocol first. MS Docs says to check Client Protocols on the client and keep TCP/IP ahead of Named Pipes.

Frequently Asked Questions