Port 1433 SQL Server – Free, Online, Private

What listens on 1433

Port 1433 is Microsoft SQL Server. The IANA name is ms-sql-s, Microsoft-SQL-Server. A default instance listens on TCP 1433. A named instance may listen on a dynamic port and register it with the SQL Server Browser, which is UDP 1434, a different number that is not this page. Clients that omit the port and omit the instance name are asking for 1433. The TDS protocol is what rides on the TCP connection. Encrypting TDS is a server setting and a client setting. The port does not imply TLS. IANA also lists UDP 1433. SQL clients use TCP.

The IANA service name is ms-sql-s: Microsoft-SQL-Server. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 1433. The service described here is the TCP one. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 1433

Service notes for port 1433: the IANA name is ms-sql-s (Microsoft-SQL-Server), and the program people mean is SQL Server. TCP 1433 is the IANA ms-sql-s port, the default SQL Server listener. The UDP row in the registry is not how clients connect. SQL Server on a public 1433 is scanned for sa and for weak passwords. Do not publish it. Keep it on the application network, require encryption, disable sa or give it a long secret, and prefer Windows or Entra authentication where you can. A login that is db_owner on every database is the account that will be in the next dump. Backup files and the sa password in a connection string in a repo are the usual second finding. The port being open is the first. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 1433, you are on the wrong page.

A named instance and a default instance confuse every runbook. ss shows some high port, the client is aimed at 1433, and the connection fails. Read the error log for the port the instance actually bound. Another trap is a firewall that allows 1433 to the Windows host while the SQL service is stopped, so the probe gets a reset and someone restarts the wrong service. Another is forcing encryption without a certificate the client trusts. TCP succeeds and the login fails. Another is IPv6. SQL Server can listen on both, and a client may pick the one you did not open.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 1433 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. A default instance shows sqlservr on TCP 1433. A listener on only 127.0.0.1 is reachable from the host and not from the app tier. Test from the app tier.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• Named instances often do not use 1433. UDP 1434 is the browser lookup, not the database port.
• The registry's UDP 1433 row is not the client protocol.
• TDS encryption is configuration, not a property of the number.
• A reset means nothing is accepting. A login error means something is.

Linuxsudo ss -lptn 'sport = :1433'
sudo lsof -nP -iTCP:1433 -sTCP:LISTEN

macOSsudo lsof -nP -iTCP:1433 -sTCP:LISTEN
netstat -anv -p tcp | grep '\.1433[^0-9]'

Windowsnetstat -ano | findstr :1433
Get-NetTCPConnection -LocalPort 1433

Remotenc -vz host 1433