Can’t Connect to SQL Server? Fix Error 26, 40, 53 and 18456 Step by Step

The application won’t start in the morning, SSMS won’t connect, or nobody can reach a freshly built server. SQL Server connection errors usually arrive with the same generic message, and that message doesn’t tell you where the problem is. Yet a connection only works when several layers work in order: the service must be running, the client must find the right instance, the network and firewall must allow it, the login must be accepted and, with newer drivers, the encryption certificate must validate.

This guide explains which layer the most common errors (26, 40, 53, 10060 and 18456) point to, and how to fix each one step by step.

What the Error Message Is Telling You

The most common message looks like this in SSMS or in application logs:

The beginning of the message is always the same; the clue is the error number in parentheses. Splitting errors into groups tells you where to start:

1. Is the SQL Server Service Running?

The first check is the simplest. In SQL Server Configuration Manager or the Windows Services console, confirm that the Database Engine service (SQL Server (MSSQLSERVER) or SQL Server (InstanceName)) is Running. If you use a named instance, the SQL Server Browser service must be running too.

The same check in PowerShell:

Get-Service -Name 'MSSQL*', 'SQLBrowser' | Select-Object Name, Status, StartType

If the service won’t start, the problem isn’t connectivity but startup, and the reason is in the SQL Server error log and the Windows Application log. Our error log guide shows how to read it.

2. Are You Connecting to the Right Server and Instance?

You connect to a default instance with the server name alone (SERVER) and to a named instance as SERVER\InstanceName. Named instances use a dynamic port by default; the client asks SQL Server Browser for the port over UDP 1434. If Browser is stopped or UDP 1434 is blocked, you get error 26.

There are two permanent fixes: run Browser and allow UDP 1434, or assign the instance a static port and specify it explicitly on the client (SERVER,1450). In production, a static port is usually the better choice because it also makes firewall rules predictable.

The error log shows which IP and port SQL Server is actually listening on:

EXEC sys.xp_readerrorlog 0, 1, N'Server is listening on';

3. Is the TCP/IP Protocol Enabled?

In SQL Server Express and Developer installations, the TCP/IP protocol is disabled by default: you can connect from the server itself but not from another machine. In SQL Server Configuration Manager, enable TCP/IP under SQL Server Network Configuration › Protocols for [instance]. The port setting is on the same screen, under IPAll on the IP Addresses tab. The change takes effect after the service restarts.

4. What Does the “Allow Remote Connections” Box Actually Do?

Many guides recommend ticking Allow remote connections to this server on the Connections page of the server properties.

5. Does the Firewall Allow the Ports?

If the service is running and TCP/IP is enabled but the connection still times out (10060), the firewall is the most likely cause. Allow TCP 1433 for a default instance, the static port for named instances, and UDP 1434 if SQL Server Browser is used. First, test from the client whether the port is reachable:

# From the client: is the port reachable?
Test-NetConnection -ComputerName SERVER -Port 1433

# On the server: inbound rule for the SQL Server port
New-NetFirewallRule -DisplayName 'SQL Server TCP 1433' -Direction Inbound `
    -Protocol TCP -LocalPort 1433 -Action Allow -Profile Domain

TcpTestSucceeded : False means the problem is in the network or the firewall, not in SQL Server. Network devices between the server and the client must allow the same port.

6. Login Failed (18456): The State Number Tells You Why

Error 18456 means the connection reached the server but the login was rejected. For security reasons the message sent to the client is vague; the real reason is the state number in the SQL Server error log:

EXEC sys.xp_readerrorlog 0, 1, N'Login failed';

A common cause of 18456 after a migration or restore is a mismatch between the SID of the database user and the server login (an orphaned user). Moving logins to the new server together with their SIDs prevents this from the start.

7. Certificate Errors: Encryption Is Now the Default

ODBC Driver 18, OLE DB Driver 19 and current Microsoft.Data.SqlClient versions encrypt connections by default and validate the server certificate. If the server uses its own self-signed certificate, the connection fails with “The certificate chain was issued by an authority that is not trusted.” A large share of connection errors that appear suddenly after a driver update or a move to SQL Server 2025 come from this; the drivers installed with SQL Server 2025 use this default too.

Linked servers are affected by this change too; we cover the details in our linked server guide.

Connection Troubleshooting Checklist

1. The Database Engine service and, for named instances, SQL Server Browser are running.
2. The server name resolves in DNS; the instance name or port is correct.
3. TCP/IP is enabled; the listening port is confirmed in the error log.
4. The port is reachable from the client with Test-NetConnection.
5. The TCP port and, if needed, UDP 1434 are open in the firewall.
6. For 18456 errors, the state number in the error log has been checked.
7. With newer drivers, the server certificate comes from a trusted authority.

If none of this helps and the server isn’t responding, connect as a sysadmin through the Dedicated Admin Connection (DAC) to see what’s happening inside the server.