SQL Server Default Ports

SQL Server listens on TCP 1433 by default, and on a box running a single default instance that is usually the end of it.

It stops being true as soon as anything else is going on. A named instance takes a dynamic port that can change when the service restarts, which is the whole reason the SQL Server Browser service exists. Mirroring and Availability Group endpoints, Service Broker and SSIS each bring ports of their own. When a connection fails, the port you assumed is rarely the port in use.

If TCP is not enabled on the instance at all, none of this applies yet: Enabling TCP Connections in SQL Server covers that first step.

---

SQL Server Port Reference

Every port SQL Server uses, and which of them move:

---

SQL Server Networking for DBAs

SQL Server networking is not just a server configuration concern, it is an operational responsibility for DBAs.

In most environments, DBAs are expected to:

• Ensure TCP connections are enabled
• Confirm which ports SQL Server is listening on
• Create or validate local Windows Firewall rules
• Provide accurate port information to network teams

In larger organisations, network access is usually controlled by central firewall teams. When requesting access, DBAs are typically required to supply:

• Source and destination hosts
• Protocol, usually TCP
• Destination port number

It is also our responsibility to test connectivity and confirm that changes work as expected once firewall rules are applied. See Testing Remote Server Port Connectivity with PowerShell for the client-side check.

---

How to Check Which Port SQL Server Is Using

The most reliable way to check which port a SQL Server instance is configured to use is through SQL Server Configuration Manager.

Open SQL Server Configuration Manager and navigate to:

SQL Server Network Configuration → Protocols for <InstanceName> → TCP/IP Properties → IP Addresses tab

This shows the port SQL Server is configured to listen on.

If multiple SQL Server instances are installed on the same server, repeat this check for each instance.

If you need to confirm what the host is actually listening on and which process owns the port, use OS-level checks. See: How to Check Listening Ports on Windows.

---

Checking the HADR or Mirroring Endpoint Port

Availability Groups and database mirroring use a separate TCP endpoint, which listens on its own port.

To view the endpoint port number, run the following query:

-- Show database mirroring endpoint state, encryption, and listening port
SELECT
    e.name AS Endpoint_Name,
    e.state_desc AS Endpoint_State,
    e.type AS Endpoint_Type,
    e.type_desc AS Endpoint_Type_Description,
    d.state AS Mirroring_State,
    d.state_desc AS Mirroring_State_Desc,
    tcp.port AS Port_Number,
    d.is_encryption_enabled AS Encryption_Enabled,
    d.encryption_algorithm_desc AS Encryption_Algorithm_Desc,
    d.certificate_id AS Certificate_Id
FROM sys.endpoints e
JOIN sys.database_mirroring_endpoints d ON e.endpoint_id = d.endpoint_id
JOIN sys.tcp_endpoints tcp ON e.endpoint_id = tcp.endpoint_id;

This endpoint commonly uses port 5022, but it is fully configurable. Do not assume defaults when validating firewall rules or Availability Group connectivity.

---

What Each Port Is For

SQL Server uses multiple ports depending on features and configuration.

The most commonly encountered ports are outlined below.

SQL Server Database Engine

TCP 1433

The default port for the SQL Server Database Engine. Client applications connect to this port unless the instance is configured to use a different one.

SQL Server Browser Service

UDP 1434

Used by the SQL Server Browser service to help clients discover instance names and port numbers, mainly when using named instances with dynamic ports.

The Browser service does not carry database traffic. It only assists with instance discovery.

Dedicated Administrator Connection (DAC)

The Dedicated Administrator Connection has a port of its own. On a default instance that is TCP 1434, and if the port is already taken when the service starts, SQL Server assigns a dynamic one instead. A named instance always takes a dynamic port, and writes it to the error log at startup.

You may see it said that the DAC uses UDP 1434. That is a genuine mix-up, and it is worth being precise about which half is wrong. UDP 1434 belongs to the SQL Server Browser service for instance discovery. The DAC listens on TCP 1434. Two different protocols, the same number, which is why the two get run together so often.

A local DAC connection needs no firewall rule. Remote DAC is switched off by default, and turning it on means opening the DAC port as well as enabling remote admin connections.

SQL Server Integration Services (SSIS)

TCP 135

Used for DCOM communication related to SSIS and other Windows based components. This is environment specific and often restricted in hardened networks.

Database Mirroring or Availability Group Endpoint

TCP 5022 (common default)

Used for database mirroring and Always On Availability Group replica communication. This port must be open between replicas.

All of these ports can be changed. Always verify actual configuration rather than relying on assumptions.

---

Other Ways to Identify SQL Server Ports

Review the SQL Server Error Log

The SQL Server error log records the listening port during service startup.

To check it:

• Open SQL Server Management Studio
• Connect to the SQL Server instance
• Navigate to Management → SQL Server Logs
• Open the current error log
• Look for messages indicating which TCP port SQL Server is listening on.

---

Check the Windows Registry

SQL Server port configuration is also stored in the Windows Registry.

The port number can be found under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server<InstanceName>\MSSQLServer\SuperSocketNetLib\Tcp

Replace <InstanceName> with the appropriate instance name.

Registry checks are useful for automation and verification, but should not replace SQL Server Configuration Manager for day to day administration.

---

Query Active Connections

You can view the TCP port used by current connections with the following query:

SELECT DISTINCT local_net_address, local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

This returns the port used by active connections, not the configured listening port. On idle systems, it may return no rows.

If you need the single-session view (what your session connected to right now), see: How to Get the SQL Server IP Address.

---

Operational Considerations

• Do not assume SQL Server is listening on port 1433
• Named instances often use dynamic ports
• Availability Group endpoints always require separate firewall rules
• SQL Server Browser usage should be deliberate, not accidental

When troubleshooting connectivity, validate in this order:

1. TCP is enabled
2. SQL Server is listening on the expected port
3. The port is reachable from the client
4. The client is connecting correctly
5. Confirm which IP and port the session actually connected to

---

Related Checks and Follow Ups

These posts naturally pair with port validation:

• Enabling TCP Connections in SQL Server
• Testing Remote Server Port Connectivity with PowerShell
• How to Check Listening Ports on Windows
• How to Get the SQL Server IP Address

---

Final Thoughts

Knowing which ports SQL Server uses is foundational DBA knowledge.

Ports directly affect connectivity, security, firewall rules, and troubleshooting. Verifying configuration instead of assuming defaults prevents wasted effort and unnecessary escalation.