.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Updated and tested 1 October 2026
The default port for MSSQL is TCP 1433, and that holds for a default instance. Everyone knows the number, including every scanner sweeping IPv4 all day long. A named instance is a different story: it picks a fresh port each time the service starts, unless somebody pinned it. That difference sits behind most of the firewall tickets I have worked on SQL Server boxes.
Port map first, then the ways to prove which port your instance is really on, then how to move it on Linux and on Windows.
TCP 1433, UDP 1434 and the dedicated admin connection
The database engine on a default instance listens on TCP 1433. SQL Server Browser sits on UDP 1434 and answers discovery requests, which is how a client turns HOST\SQLEXPRESS into a real port number before it opens a session.
The dedicated admin connection (DAC) on a default instance uses TCP 1434. Same number as the Browser, completely different transport. Remote DAC is disabled by default, so that TCP port stays shut until somebody enables remote admin connections on purpose. The next time a firewall report lists 1434 twice and a colleague calls it a duplicate row, that is what you are both looking at.
1433 is registered with IANA to Microsoft-SQL-Server and 1434 to Microsoft-SQL-Monitor, which is where the Browser's number comes from. The registration is older than a good number of the people writing firewall rules against it. Slammer moved on UDP 1434 back in 2003 and some network teams still treat the number as radioactive two decades later. Neither fact changes anything about your instance.
Named instances and dynamic ports
A named instance asks the operating system for an available TCP port when the service starts and keeps it until the next restart. Convenient on a laptop with four instances installed. Miserable for a firewall, because the rule you wrote on Tuesday points at a port the instance walked away from on Wednesday.
Clients that cannot reach the Browser hit error 26 while locating the server or instance, which is the failure you are choosing between here. Two ways out. Leave the port dynamic and let clients find it through SQL Server Browser, which means opening UDP 1434 and accepting the extra round trip, or assign the named instance a static TCP port and write one firewall rule that stays true. I pin the port on anything that is not a developer machine, and a pinned port also lets you skip the Browser entirely by connecting to host\INSTANCE,1435.
The MSSQL server port numbers you will meet
The numbers below come from Microsoft's page on configuring the Windows firewall for SQL Server, which is more careful with the word "default" than most articles are. The ones you meet in practice:
- TCP 1433 database engine, default instance
- UDP 1434 SQL Server Browser
- TCP 1434 dedicated admin connection on the default instance, remote access off until you enable it
- TCP 2383 Analysis Services, default instance
- TCP 2382 the Analysis Services Browser redirect, which points a client at a named AS instance
Past those the numbers get less tidy. Integration Services runs its legacy service on TCP 135, borrowing the RPC endpoint mapper, while the Scale Out Master listens on 8391 and the Scale Out Worker connects outbound to it. Reporting Services serves HTTP on 80 and HTTPS on 443, through URL reservations and not a dedicated port of its own. Windows Failover Clustering uses UDP 3343 for the cluster heartbeat, which is not a SQL Server port at all and turns up in the same firewall reviews anyway. Analysis Services in a named instance takes a dynamic port and relies on 2382 to redirect clients to it, in the same shape as the database engine and the Browser.
None of that applies to Azure SQL Database. Clients reach its gateway on 1433, and under the Redirect connection policy they also need outbound ports 11000 to 11999 open to the database nodes in the region.
I have never had a reason to touch the Analysis Services ports in anger. What is written above about 2382 and 2383 comes off the documentation, not off a server I have run.
Two more numbers get repeated as defaults all over the internet and are not defaults at all. Microsoft's own wording on mirroring: "There's no default port for database mirroring however Books Online examples use TCP port 5022 or 7022." Availability group endpoints follow the same habit, and Service Broker's 4022 comes from documentation examples too. Use them for consistency if you like. Just do not expect a fresh install to be listening there, and do not write a monitoring check that assumes it.
Find the MSSQL port your instance is listening on
Three ways to answer it, and all three beat assuming. The default port MSSQL uses is 1433 on a default instance only, so on a named instance do one of these before you write a firewall rule against a number you guessed.
Read the startup line in the error log
SQL Server writes its listeners to the error log every time it starts, one line per address:
Server is listening on [ 'any' <ipv4> 1433]On Linux that log lives at /var/opt/mssql/log/errorlog and it is UTF-16LE, so a plain grep comes back empty and you assume the line is not there. Convert it first:
sudo iconv -f UTF-16LE -t UTF-8 /var/opt/mssql/log/errorlog | grep -i "listening on"On Windows the file is C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\Log\ERRORLOG for SQL Server 2025, with MSSQL16 in the path for 2022. If the folder name matches neither, check which version the instance reports and come back with the right path. Older major versions follow the same MSSQLnn pattern the whole way down.
Query sys.dm_tcp_listener_states
SELECT listener_id, 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, meaning every interface on the machine. The type_desc column separates the Transact-SQL listener from Service Broker and database mirroring listeners, so a mirrored server returns several rows and only one of them is the port your application cares about.
The permission on this DMV changed, and it catches people out after upgrades. VIEW SERVER STATE covers it on SQL Server 2019 and earlier. SQL Server 2022 and later want VIEW SERVER SECURITY STATE instead, as the DMV reference spells out. A monitoring login that worked for three years starts returning an empty result set after an in-place upgrade, with no error message to explain why.
Check TCP/IP properties in Configuration Manager
SQL Server Configuration Manager ships with the engine and not with SSMS, and newer versions of Windows might not list it as an app because it is an MMC snap-in. Run SQLServerManager17.msc for SQL Server 2025 or SQLServerManager16.msc for 2022, both sitting in C:\Windows\SysWOW64. Expand SQL Server Network Configuration, select Protocols for your instance, open TCP/IP and switch to the IP Addresses tab. Scroll all the way to the bottom for IPAll.
Change the port with mssql-conf on Linux
One key, one restart:
sudo /opt/mssql/bin/mssql-conf set network.tcpport 14330
sudo systemctl restart mssql-server
sudo cat /var/opt/mssql/mssql.confThe mssql-conf reference is blunt about what happens next: "When connecting to SQL Server now, you must specify the custom port with a comma (,) after the hostname or IP address." A colon does nothing here. Comma, straight after the host:
sqlcmd -S localhost,14330 -U sa -CThat -C is there because sqlcmd from mssql-tools18 defaults to mandatory encryption while a stock install presents a self-signed certificate. Plenty of SQL Server connection strings broke on the same default change after a driver upgrade, throwing a certificate trust error that has nothing to do with the port you just moved.
An instance built from the one-click template on a LumaDock MSSQL VPS comes up on 1433 like any other Linux install, and the same key moves it. The template ships the engine only, so licensing works exactly as it does anywhere else: Express and Developer stay free, and a paid edition runs on a key you supply.
Change the port on Windows in the IP Addresses tab
Screenshots and the full click path sit in Microsoft's walkthrough for configuring a server to listen on a specific TCP port. Back in TCP/IP properties, under IPAll, clear the TCP Dynamic Ports box so it is empty, type your number into TCP Port and restart the SQL Server service.
This is where an hour goes. The tab lists IP1, IP2, IP3 and so on, one section per address bound to the machine, with IPAll at the very bottom. Half the people who do this for the first time set the port under IP1, restart and find the instance still on 1433 or still dynamic. IPAll is what applies unless a specific address section overrides it, so IPAll is where the number belongs. And if TCP Dynamic Ports under IPAll still contains a 0, the instance keeps asking for a dynamic port at startup and the number you typed never takes effect.
