How To Check If SQL Server Is Reachable

A retail company called me on a Monday morning because its order app had stopped working. The error message said “A network-related or instance-specific error occurred,” and the team had already restarted the app servers twice. Nobody had checked whether the app servers could even reach the database. It turned out someone had changed a network rule over the weekend, and port 1433 was blocked.

Knowing how to check if SQL Server is reachable saves hours in situations like this. A failed connection can come from DNS, the network path, a firewall, the SQL Server service, encryption, a login, or a paused database. Each layer needs a different fix, so guessing wastes time.

This guide walks you through a layered test, from the cheapest check to the most detailed one. You will use PowerShell, sqlcmd, T-SQL, Azure CLI, and a short Python script. You will also learn the Azure-specific causes, such as firewall rules and private endpoints, and how to read the common error numbers.

The Layered Approach to Testing Reachability

“Reachable” has several meanings. A server can answer a ping but refuse SQL connections. It can accept connections but reject your login. Test one layer at a time, and stop at the first failure.

SQL Server listens on TCP port 1433 by default. Named instances often use a dynamic port, and the SQL Server Browser service on UDP port 1434 tells clients which port to use.

Pro Tip: In my experience, ping is the most misleading test in this list. Many networks block ping on purpose, and a successful ping says nothing about port 1433. I skip it and go straight to a port test.

Step 1: Gather the Connection Details

You cannot test what you cannot name. Collect these facts first:

• Server name: For Azure SQL Database, this looks like <sql-server-name>.database.windows.net. For a VM, it is a host name or IP address.
• Instance name: A named instance is written as server\instance. See how to find the SQL Server instance name in SSMS if you are unsure.
• Port: Usually 1433. Named instances may use a dynamic port.
• Authentication method: Microsoft Entra ID, Windows authentication, or SQL authentication.
• Where you are testing from: Test from the same machine, subnet, or network that the application uses. A test from your laptop proves nothing about a server in another virtual network.

If you can already connect to one server and need its name, use this query:

SELECT @@SERVERNAME AS ServerName,
       SERVERPROPERTY('MachineName') AS MachineName,
       SERVERPROPERTY('InstanceName') AS InstanceName;

This returns the server name, the host machine name, and the instance name (NULL for a default instance). You can also read the guide on how to get the server name in SQL Server using a query.

For Azure SQL Database, get the server’s fully qualified name with the CLI:

az sql server show \
  --name <sql-server-name> \
  --resource-group <resource-group-name> \
  --query fullyQualifiedDomainName \
  --output tsv

The --query and --output tsv options return only the host name, which is easy to copy into the tests below.

Step 2: Test DNS Resolution

Before you test the port, confirm the name points where you expect.

Resolve-DnsName <sql-server-name>.database.windows.net

Resolve-DnsName returns the IP address for the name. On Linux or macOS, use nslookup <server-name>.

Check the answer carefully. If you use a private endpoint, which gives an Azure service a private IP address inside your virtual network, the name should resolve to a private address such as 10.x.x.x. If it returns a public IP, your private DNS zone is missing or not linked to the network. See how to create a private endpoint in Azure and how a private DNS zone works. The message in the server was not found or was not accessible error often points to this layer.

Pro Tip: I once spent an hour on firewall rules before I ran a DNS lookup. The name resolved to a public IP, but the database only accepted private traffic. Now DNS is my first test every time.

Step 3: Test the Network Path and Port

This is the most useful single test. It tells you whether a TCP connection can open, without involving SQL Server logins at all.

Test-NetConnection -ComputerName <server-name> -Port 1433

Read the result:

• TcpTestSucceeded : True means the network path and port are open.
• TcpTestSucceeded : False means something is blocking or nothing is listening.

For a named instance with a custom port, change the port number. On Linux or macOS, use this:

nc -zv <server-name> 1433

The -z flag checks for a listener without sending data, and -v prints the result.

You can also test from a script, which is useful in pipelines and health checks:

import socket
import sys

server = sys.argv[1]
port = int(sys.argv[2]) if len(sys.argv) > 2 else 1433

try:
    with socket.create_connection((server, port), timeout=5):
        print(f"OK: TCP connection to {server}:{port} succeeded")
except socket.gaierror:
    print("FAIL: DNS lookup failed")
except socket.timeout:
    print("FAIL: Timed out - likely blocked by a firewall or NSG")
except ConnectionRefusedError:
    print("FAIL: Refused - host reachable, but nothing is listening on that port")
except OSError as error:
    print(f"FAIL: {error}")

Run it with python check_sql_port.py <server-name> 1433. The script separates three different failures. A DNS error means the name is wrong. A timeout usually means a firewall is silently dropping packets. A refusal means the host answered, but SQL Server is not listening on that port. That distinction narrows your search before you touch a single setting.

Pro Tip: I save this script in the team’s tools repository. When someone says “the database is down,” we run it from the app server first, and the answer usually arrives in under ten seconds.

Step 4: Check Firewalls and Network Rules

If the port test timed out, look at every firewall between the client and the server.

SQL Server on a Windows VM

1. Confirm the Windows Defender Firewall has an inbound rule that allows TCP 1433 (and UDP 1434 for SQL Browser if you use named instances).
2. Check the network security group (NSG), which holds allow and deny rules for traffic in Azure. Learn the basics in what an NSG in Azure is. Make sure no deny rule blocks port 1433 before your allow rule.
3. If you need to add one, see how to open ports on an Azure VM.

az network nsg rule create \
  --resource-group <resource-group-name> \
  --nsg-name <nsg-name> \
  --name Allow-SQL-From-App-Subnet \
  --priority 300 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes 10.0.1.0/24 \
  --destination-port-ranges 1433

This creates an inbound rule that allows TCP 1433 only from the app subnet 10.0.1.0/24. The --priority 300 value must be lower than any deny rule that would block it. Warning: never set the source to * or 0.0.0.0/0 for a database port. That exposes SQL Server to the entire internet. Restrict it to the exact subnets or addresses that need access, and keep the VM inside a private virtual network.

Azure SQL Database

Azure SQL Database has its own server firewall, which allows or blocks client IP addresses. Error 40615 means your IP is not allowed. See how to configure the Azure SQL Database firewall and how to find the Azure SQL Database IP address your client uses.

az sql server firewall-rule create \
  --resource-group <resource-group-name> \
  --server <sql-server-name> \
  --name AllowMyOfficeIP \
  --start-ip-address <office-public-ip> \
  --end-ip-address <office-public-ip>

This creates a rule for one public IP address. Use the same value for start and end to allow a single address. Never use the range 0.0.0.0 to 255.255.255.255. For production, prefer private endpoints and disable public access.

Also remember a connection policy detail. In the default Redirect mode, clients connect to the gateway on port 1433 and are then redirected to the node on ports in the 11000 to 11999 range, so outbound rules must allow that range. If a network team only opens 1433, connections may fail after the redirect.

Azure SQL Managed Instance

A Managed Instance lives inside its own subnet in your virtual network, so reachability depends on routes, NSGs, and peering. If you enable its public endpoint, it uses port 3342 and needs an NSG rule to match. Once connected, see how to monitor the instance with Azure SQL Managed Instance monitoring.

Pro Tip: I keep a one-page diagram of the network path for every production database: client, subnet, NSG, route, firewall, database. During an outage, nobody has to guess where to look.

Step 5: Confirm the SQL Server Service Is Running

If the port test failed with “refused,” or the host answers but SQL does not, the engine may be stopped or not listening.

On a Windows host, check the service:

Get-Service -Name 'MSSQLSERVER'

For a named instance, the service name is MSSQL$<instance-name>. If the status is Stopped, start it and read the error log to find out why. See how to check if SQL Server is running. If the service will not start, these guides cover the SQL Server service not starting problem.

Next, open SQL Server Configuration Manager and verify:

• TCP/IP is enabled under SQL Server Network Configuration.
• The port in the TCP/IP properties matches what clients use.
• SQL Server Browser is running if you use named instances without a fixed port.

Restart the SQL Server service after changing network settings.

Once you are on the host, a quick check of what the server is listening on helps:

SELECT local_net_address, local_tcp_port, net_transport, encrypt_option
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

This shows the address and port your current session uses and whether it is encrypted. It is a fast way to confirm the real port instead of assuming 1433.

Step 6: Test an Actual SQL Connection with sqlcmd

A successful TCP test proves the door is open. Now test the full connection, including encryption and login.

For SQL Server on a VM with Windows authentication:

sqlcmd -S tcp:<server-name>,1433 -E -N -Q "SELECT @@SERVERNAME, GETDATE();"

For Azure SQL Database with Microsoft Entra authentication:

sqlcmd -S tcp:<sql-server-name>.database.windows.net,1433 -d <database-name> -G -N -l 30 -Q "SELECT DB_NAME(), SUSER_SNAME();"

Here is what the flags do:

• -S tcp:<server>,<port> forces a TCP connection to a specific port. Writing the port after a comma avoids relying on SQL Browser.
• -E uses Windows authentication. -G uses Microsoft Entra ID authentication.
• -N requires an encrypted connection. Do not turn encryption off to make a test pass.
• -l 30 sets a 30-second login timeout.
• -Q runs the query and exits.

If you get a certificate error on a test server with a self-signed certificate, -C trusts the server certificate. Use it only in a lab. In production, install a certificate from a trusted authority and keep validation on.

Prefer Microsoft Entra ID and managed identities over SQL passwords. Read what a managed identity in Azure is, and if a password is unavoidable, store it in Azure Key Vault. See how Azure Key Vault works. Never keep passwords in scripts, config files, or spreadsheets.

To test from a desktop tool, use SSMS to connect to Azure SQL Database. If SSMS fails, the guide on SSMS cannot connect to server lists common causes.

Test from Application Code

Applications fail in ways sqlcmd does not, such as driver or timeout problems. This Python test uses the same driver your app would:

import pyodbc

connection_string = (
    "Driver={ODBC Driver 18 for SQL Server};"
    "Server=tcp:<sql-server-name>.database.windows.net,1433;"
    "Database=<database-name>;"
    "Authentication=ActiveDirectoryDefault;"
    "Encrypt=yes;"
    "TrustServerCertificate=no;"
    "Connection Timeout=30;"
)

try:
    with pyodbc.connect(connection_string) as connection:
        row = connection.cursor().execute("SELECT 1").fetchone()
        print("Connected, result:", row[0])
except pyodbc.Error as error:
    print("Connection failed:", error)

ActiveDirectoryDefault uses your signed-in identity, such as an az login session on a laptop or a managed identity in Azure, so no password appears in the code. Encrypt=yes and TrustServerCertificate=no enforce encryption and certificate validation. The Connection Timeout=30 setting gives a gateway or a resuming database time to respond. Make sure the ODBC driver is installed, and check your driver version supports this authentication option.

For a connection string reference, see Azure SQL Database connection string and how to get the connection string from SQL Server.

Pro Tip: I always run both sqlcmd and a short app-language test. When sqlcmd works and the app fails, the problem is the driver, the connection string, or the identity, and I can stop checking the network.

Step 7: Check the Database State

Sometimes the server is fine, but the database is not ready. For Azure SQL, check its status:

az sql db show \
  --resource-group <resource-group-name> \
  --server <sql-server-name> \
  --name <database-name> \
  --query "{name:name, status:status}" \
  --output table

The status field should read Online. A serverless database that is paused returns error 40613 on the first connection while it resumes. Retrying after about a minute usually works, and apps should include retry logic. Learn how it behaves in Azure SQL Database serverless.

On a VM or Managed Instance, check the state with T-SQL:

SELECT name, state_desc, user_access_desc
FROM sys.databases
WHERE name = N'<database-name>';

This shows whether the database is ONLINE, RESTORING, RECOVERING, or OFFLINE, and who is allowed in. A database in the middle of a restore will reject connections until it finishes.

Read the Error Message and Number

The error text usually tells you which layer failed. Use this table as a quick map.

For more detail on these messages, see the guides on cannot open server requested by the login, the instance-specific error, and could not open a connection to SQL Server.

If the connection works but queries are denied, the problem is permissions, not reachability. Review SQL Server permissions and test with a non-administrator account that has only the rights your application needs. Give each application its own least-privilege user, never sa or sysadmin.

Pro Tip: I write the error number in the incident ticket before anything else. Teams that Google the text instead of the number often chase the wrong layer for an hour.

Monitor Reachability So You Find Out First

Manual tests help during an incident. Monitoring helps you avoid one.

• Azure Monitor: It collects metrics and logs from Azure SQL and Managed Instance. Learn what Azure Monitor does. Alert on failed connections, firewall blocks, and availability drops.
• Synthetic checks: Schedule the Python port test from the app subnet every minute, and alert on two failures in a row.
• Log connection events: Turn on diagnostic logs, and keep them long enough to compare the time a problem started with the time a change was made.
• Track changes: Alert on NSG, firewall, and DNS changes. In my experience, most “sudden” outages follow a quiet configuration change.

Use tags such as owner and environment so alerts reach the right team, and create a budget with alerts so a retry loop does not quietly raise a bill.

Pro Tip: I add a “change in the last 24 hours” check to every outage checklist. It finds the cause faster than any tool, because the network usually breaks because someone changed it.

SQL Server Connectivity Checklist

• Test in layers: Check DNS, then the port, then firewalls, then the service, then encryption, then login. Stop at the first failure.
• Test from the right place: Run checks from the application’s own subnet or host, not from your laptop.
• Encrypted connections: Keep -N and Encrypt=yes on, and install a trusted certificate instead of trusting any server certificate.
• Private access: Use private endpoints or VNet integration for production databases, and never open a database port to the whole internet.
• Least privilege: Give applications their own users, prefer Microsoft Entra ID and managed identities, and test with a non-administrator account.
• Retry and monitoring: Add retry logic for serverless resume and brief gateway failovers, and alert on connectivity changes.

Frequently Asked Questions

How do I check if SQL Server is reachable from another computer?

Run Test-NetConnection -ComputerName <server-name> -Port 1433 from that computer. If it returns TcpTestSucceeded : True, the network path and port are open. Then run sqlcmd with -N to confirm that encryption and your login work.

Why can I ping SQL Server but not connect?

Ping only tests basic network reachability. The connection may fail because port 1433 is blocked, the SQL Server service is stopped, TCP/IP is disabled, or the login is wrong. Test the port next, not another ping.

What port does SQL Server use?

The default is TCP 1433. Named instances often use a dynamic port, and SQL Server Browser on UDP 1434 helps clients find it. Azure SQL Database also redirects connections to ports 11000 to 11999 in Redirect mode.

How do I fix error 40 or error 53 in SQL Server?

Both mean the client cannot find or open a path to the server. Check the server name, DNS resolution, port 1433, firewalls and NSGs, and whether the SQL Server service is running. For Azure SQL, also check the server firewall and private endpoint DNS.

How do I check if an Azure SQL Database is online?

Run az sql db show and read the status field, or query sys.databases on a VM or Managed Instance. A serverless database may be paused and take about a minute to resume. Build retry logic into your application.

You learned how to test SQL Server reachability layer by layer, from DNS and the port to encryption, login, and database state. The key principle is to test from the application’s own network, keep encryption and least-privilege access on, and never open a database port to the whole internet. I hope you found this article helpful.

You May Also Like

• How to check the SQL Server edition
• How to view SQL Server error logs
• SQL Server user permissions explained
• How to reset the sa password in SQL Server
• Connect to Azure SQL Database using Python

Bijay Kumar Sahoo

After working for more than 15 years in the Software field, especially in Microsoft technologies, I have decided to share my expert knowledge of SQL Server. Check out all the SQL Server and related database tutorials I have shared here. Most of the readers are from countries like the United States of America, the United Kingdom, New Zealand, Australia, Canada, etc. I am also a Microsoft MVP. Check out more here.