How to Fix “A Network-Related or Instance-Specific Error” in SQL Server

The “A network-related or instance-specific error occurred while establishing a connection to SQL Server” message appears when your app or client cannot reach the SQL Server instance you entered. In most cases, this happens because the SQL Server service is stopped, the server or instance name is wrong, TCP/IP is disabled, the required port is blocked by Windows Firewall, or remote connections are not configured correctly.

Before changing settings, first confirm how you are connecting.

• If you are connecting to the same computer, the problem is often the server name, instance name, or the SQL Server service.
• If you are connecting from another computer, also check TCP/IP, SQL Server Browser, and Windows Firewall.

Connection format matters here:

• Default instance: SERVERNAME
• Named instance: SERVERNAME\INSTANCENAME
• Direct IP and port: 192.168.1.10,1433

For example, MSSQLSERVER is the default instance, while SQLEXPRESS is a common named instance. If you enter the wrong server or instance name, SQL Server will not be found even if the service is running normally.

1. Verify the Server Name and Instance Name

This is the quickest check and is often the real cause when the error appears on a local connection. Make sure the name you entered exactly matches the installed SQL Server instance.

1. Open SQL Server Configuration Manager or Services by pressing Windows + R, typing services.msc, and pressing Enter.
2. Look for your SQL Server service name:
   • MSSQLSERVER = default instance
   • MSSQL$SQLEXPRESS or similar = named instance
3. Use that exact name in your connection:
   • Default instance: SERVERNAME
   • Named instance: SERVERNAME\SQLEXPRESS

If you are using the wrong server name, SQL Server will reject the connection because the target instance does not exist under that name.

If you are using SQL Server Express, your server name often needs \SQLEXPRESS at the end.

2. Make Sure the SQL Server Service Is Running

SQL Server must be actively running before it can listen for incoming connections. If the service is stopped, every connection attempt will fail no matter what server name or port you use.

1. Press Windows + R, type services.msc, and press Enter.

   

2. Find the SQL Server service for your instance:
   • MSSQLSERVER for the default instance
   • MSSQL$InstanceName for a named instance
3. Check whether its status is Running.
4. If it is stopped, right-click it and select Start.
5. If it is already running but connections still fail, right-click it and select Restart.

3. Enable TCP/IP for SQL Server

SQL Server can be installed with shared memory or local-only access, which works on the same computer but fails from another device. Enabling TCP/IP allows SQL Server to listen for normal network traffic.

1. Open SQL Server Configuration Manager.
2. Expand SQL Server Network Configuration.
3. Select Protocols for MSSQLSERVER or the relevant instance.
4. In the right pane, right-click TCP/IP and choose Enable.
5. If prompted, restart the SQL Server service.

4. Confirm the SQL Server Port

SQL Server commonly uses TCP port 1433, but named instances may use a different or dynamic port. If your app expects port 1433 but the instance is listening on another port, the connection will fail even though SQL Server itself is running.

1. Open SQL Server Management Studio (SSMS) and connect locally if possible.
2. In Object Explorer, expand Management and then SQL Server Logs.

   

3. Open the current log and filter it using server is listening on.

   

4. Note the port shown in the log entry.

You can also check it in SQL Server Configuration Manager:

1. Open Protocols for your instance.
2. Double-click TCP/IP.
3. Open the IP Addresses tab.
4. Under IPAll, check the configured TCP Port.

   

5. Start SQL Server Browser for Named Instances

If you connect using a named instance such as SERVERNAME\SQLEXPRESS, the SQL Server Browser service may be needed so clients can discover the correct port automatically.

1. Open Services or SQL Server Configuration Manager.
2. Locate SQL Server Browser.

   

3. Check whether its status is Running.
4. If it is stopped, right-click it and select Start.

6. Allow SQL Server Through Windows Firewall

If SQL Server is running and correctly configured, Windows Firewall may still block inbound connections. This is especially common when connecting from another computer.

1. Press Windows + R, type firewall.cpl, and press Enter.

   

2. Click Advanced settings.

   

3. Select Inbound Rules, then click New Rule.

   

4. Select Port and click Next.

   

5. Select TCP and enter the SQL Server port, usually 1433.

   

6. Select Allow the connection.

   

7. Choose the required profiles and finish the rule.

   

You can also allow the SQL Server executable directly if needed:

sqlservr.exe is commonly located in a path similar to C:\Program Files\Microsoft SQL Server\MSSQLxx.InstanceName\MSSQL\Binn\sqlservr.exe.

7. Confirm the Server IP Address for Remote Connections

If you are connecting from another computer by IP address, make sure you are using the correct one.

1. On the SQL Server host computer, press Windows + R, type cmd, and press Enter.
2. Run ipconfig.
3. Note the correct IPv4 address.

   

4. Use that IP in your connection string, optionally with the port, for example 192.168.1.10,1433.

8. Check the Connection String in Your App or Client

If SQL Server works in SSMS but your application still fails, the connection string is likely incorrect.

Common examples:

• Default local instance: localhost or .
• Named local instance: .\SQLEXPRESS
• Remote default instance: SERVERNAME or 192.168.1.10,1433
• Remote named instance: SERVERNAME\INSTANCENAME

Double-check the following:

• The server name is spelled correctly
• The instance name is correct
• The port matches the actual SQL Server port
• Your authentication mode and credentials are correct

Many connection failures are not caused by SQL Server itself, but by clients pointing to the wrong instance, wrong port, or wrong machine.