.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Updated and tested 5 October 2026
MSSQL error 26 fires before authentication, before TLS and before the Database Engine has any idea someone is knocking. It's a discovery failure. The client asked the server machine which TCP port a named instance is listening on, waited and got nothing back. Understand that one exchange and the whole fix list below stops looking like a grab bag of unrelated tips.
Here's the message in full, as .NET reports it:
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: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)What happens on the wire when a client resolves host\INSTANCE
A SQL Server named instance doesn't own a fixed port. It takes a dynamic TCP port at service start, and that port can change after a reboot. So when you hand a driver SQLBOX01\SQLEXPRESS, the driver has a hostname and an instance name and no idea where to send TDS traffic. It fills that gap with SSRP (SQL Server Resolution Protocol), and Microsoft's archived protocols blog on SQL Network Interfaces error 26 is still the clearest description of it: "Every time client makes a connection to SQL Server named instance, we will send a SSRP UDP packet to the server machine UDP port 1434. We need this step to know configuration information of the SQL instance, e.g., protocols enabled, TCP port, pipe name etc."
Listening on that UDP port is the SQL Server Browser service, which "reads the registry, identifies all instances of SQL Server on the computer, and notes the ports and named pipes they use", then "responds with the TCP/IP port or named pipe of the requested instance". Once the client has the port it opens a normal TCP connection and the real login begins.
A short detour into why any of this machinery exists. One machine used to mean one instance, and TCP 1433 was the whole answer. Once several instances could share a box, something had to tell a client which port belonged to which name, and the answer was a small resolution service listening on a well-known UDP port. In SQL Server 2000 that was the SQL Server Resolution Service, as Microsoft's MS02-039 security bulletin calls it. Today it is a separate Windows service, which is why the Browser looks like a component bolted onto the side of the product. It is one.
SQL error 26, error locating server/instance specified, means that reply never arrived. The archived page says it as plainly as anyone has since: "the reason that we get this error message is the client stack could not receive SSRP response UDP packet from SQL Browser." Note what that does not tell you. Nothing in it says the engine is down, nothing in it says your password is wrong, and TCP 1433 doesn't come into it at any point. A UDP datagram left and no UDP datagram came home.
Why a default instance on 1433 never produces error 26
A default instance is MSSQLSERVER and it listens on TCP 1433 unless somebody changed it. The client already knows the port from the protocol default, so there's no lookup and no SSRP packet. Microsoft's page on the SQL Server Browser service puts it in one line: with the Browser stopped, "you can connect to the default instance of SQL Server with TCP/IP if it's running on port 1433." Express installs as a named instance by default, which is why error 26 turns up far more often there than anywhere else.
Default port 1433 behaviour is a separate topic and none of it applies while an instance name is in the path. If your connection string has no backslash in the server name and you're still seeing error 26, look for an alias on the client machine or a driver inventing an instance name from somewhere in config. I have found both. The alias took longer.
Checklist for SQL error 26, error locating server/instance specified
1. Confirm the instance name against the instances that exist
Typos win more of these than anything else. SQLEXPRES with a letter dropped, or SQLServer typed on a box whose instance answers to SQLEXPRESS. A hostname copied from a different environment does it just as well. On the server, list what's there with the PowerShell snippet from Microsoft's connectivity troubleshooter:
Get-Service | Where {$_.status -eq 'running' -and $_.DisplayName -like "sql server*"}A named instance shows up as MSSQL$INSTANCENAME. SQL Server Configuration Manager gives you the same list in a GUI, and newer versions of Windows might not list it as an app, so run SQLServerManager17.msc for SQL Server 2025 or SQLServerManager16.msc for 2022. From a Windows client, sqlcmd -L enumerates locally configured servers plus anything broadcasting on the network, though the docs warn that "sqlcmd might not receive a timely response from all servers", so an absent server there proves nothing on its own.
2. Confirm the SQL Server service is running
Obvious, and skipped often enough that it gets its own line. A stopped instance can still return error 26, because the Browser has nothing to report for it and the client never gets far enough to be refused.
3. Start SQL Server Browser and set it to automatic
In Configuration Manager, under SQL Server Services, find SQL Server Browser. State should be Running and Start Mode should be Automatic. Microsoft starts it automatically "when installing a named instance of the Database Engine, including all instances of SQL Server Express", but hardening scripts, group policy and well-meaning colleagues disable it constantly. A Browser set to Manual survives exactly one reboot's worth of luck.
4. Enable TCP/IP for the instance
On a new installation, TCP/IP is disabled for SQL Server Express and for Developer edition, and enabled for Enterprise, Standard, Web and Evaluation. Microsoft's table of default network protocol configuration carries the full grid. What it means in practice is a Developer edition instance on a fresh VPS accepting shared memory connections from the console and refusing everything from the network until you turn TCP/IP on. Configuration Manager, SQL Server Network Configuration, Protocols for your instance, set TCP/IP to Enabled, restart the service.
5. Open UDP 1434 on the host firewall
On Windows, one rule, and the protocol matters more than the number:
New-NetFirewallRule -DisplayName "SQLServer Browser service" -Direction Inbound -LocalPort 1434 -Protocol UDP -Action AllowMicrosoft's connectivity troubleshooting guide includes the reminder because it happens so often: "Make sure that you're opening a UDP port, not a TCP port." TCP 1434 is the Dedicated Admin Connection on a default instance, a completely different thing, and opening it does nothing for the Browser.
On Linux the Browser isn't in the picture at all, so the page to read there is enabling remote connections in SQL Server. On Ubuntu you are looking for a blocked TCP port and nothing else.
6. Open UDP 1434 on the cloud or provider firewall too
Host firewall and network firewall are two separate gates and both have to open. Security groups, network ACLs, provider-level firewall rules, an on-path appliance: any of them will silently drop a UDP datagram and give you an error 26 that looks identical to a Windows Firewall problem. Check both before you conclude the Browser is broken.
7. Check DNS and hosts resolution for the server name
The SSRP packet has to reach the right machine. ping SQLBOX01 and nslookup SQLBOX01 take five seconds and rule out a stale hosts entry or a name resolving to an old IP. Ping failing doesn't prove much on its own, since ICMP is blocked on plenty of networks, but a wrong IP in the answer proves a lot.
Skip the Browser with a static port and connect as host,port
Here's the fix I reach for on any server I own. It looks like a shortcut and it isn't. Give the named instance a fixed TCP port, leave the Browser out of the connection path, and error 26 becomes structurally impossible. You lose instance-name discovery, which matters for a workstation browsing a domain and matters not at all for an application server with a config file.
Find the port the instance is listening on now
Two reliable sources. The error log prints it at startup, in a line that looks like Server is listening on [ 'any' <ipv4> 1433], and that message means the instance is listening on every IPv4 address on the machine. From a session you already have, the DMV is quicker:
SELECT ip_address, port, type_desc, state_desc
FROM sys.dm_tcp_listener_states;An ip_address of 0.0.0.0 is the IPv4 wildcard, and type_desc of Transact-SQL is the listener you care about (the other rows are Service Broker and database mirroring). The permission needed changed along the way: VIEW SERVER STATE on SQL Server 2019 and earlier, VIEW SERVER SECURITY STATE on 2022 and later, so a monitoring account that worked fine on an old box can come back empty on a new one.
Set a static port and restart
Open Configuration Manager, expand SQL Server Network Configuration, select Protocols for your instance, open TCP/IP properties and go to the IP Addresses tab. Scroll to the bottom, to IPAll. Clear TCP Dynamic Ports so the box is empty, put your chosen port in TCP Port, then restart the instance. Microsoft documents the whole sequence under configuring a server to listen on a specific TCP port. Pick something outside the ephemeral range and record it, because nothing on the machine will remind you later.
Then connect with a comma, which is the syntax everyone forgets at least once:
sqlcmd -S SQLBOX01,1435 -U appuser -P '<password>' -CServer=tcp:SQLBOX01,1435;Database=orders;User Id=appuser;Password=<password>;Encrypt=True;TrustServerCertificate=False;SQLBOX01\SQLEXPRESS,1435 also works and skips the Browser lookup just the same, since an explicit port always wins over discovery. The Browser docs confirm the principle: "If the SQL Server Browser service isn't running, you can still connect to the SQL Server if you provide the correct port number or named pipe." Whichever form you use, the port has to be open on TCP. One driver-side wrinkle sits underneath all of this: JDBC wants a colon in front of the port where every other client wants a comma, and that difference has produced at least one outage I know about, in the middle of a migration nobody wanted to be doing.
The rest of the per-driver detail is in the SQL Server connection string reference.
