SQL Server port guide: database access on port 1433

A SQL client connects to the server listener, negotiates protocol settings, authenticates with SQL authentication, Windows authentication, Entra ID, or another supported method, and then sends queries, transactions, and metadata requests.

The port only confirms that the listener can be reached. Real database access also depends on login state, database permissions, encryption settings, instance configuration, connection strings, DNS, and firewall rules at multiple layers.

A default SQL Server instance typically listens on TCP 1433. Named instances may use dynamic ports unless you configure a static port. SQL Server Browser can help clients discover named instances, but many production environments prefer static ports for clearer firewall policy.

If your connection string uses server,port syntax, verify the exact port. If it uses an instance name, check SQL Server Configuration Manager, the error log, or server settings to see which port the instance actually listens on.

Open SQL access only from application servers, admin workstations, migration tools, reporting services, or trusted networks that need database connectivity. Public access should be avoided unless there is a very specific managed and monitored requirement.

For cloud databases, prefer private endpoints, VPC or VNet peering, VPN, bastion paths, service networking, or provider-native firewall allowlists instead of allowing the whole internet to reach 1433.

Before allowing TCP 1433, confirm the instance is listening on the expected interface and port, encryption policy is known, logins are scoped, least-privilege database roles are in place, and backups are reliable.

A port checker can confirm network reachability, but it cannot prove the database is safe. Test the real connection string with sqlcmd, SQL Server Management Studio, Azure Data Studio, application health checks, and server logs.

On Windows Server, enable TCP/IP for the SQL Server instance, set a static port if needed, restart the service, and allow inbound TCP 1433 in Windows Defender Firewall only from trusted sources.

On Linux SQL Server deployments, confirm mssql-server listens on the intended port and allow that port in firewalld, ufw, nftables, iptables, or cloud security groups. Keep management access separate from application access.

For managed SQL services, use provider firewall rules, private endpoints, and identity controls. Do not assume opening a cloud database endpoint is equivalent to exposing a single VM port; provider-level access policy also matters.

Start with an external or internal port check against the database hostname and TCP 1433, depending on where the client will run. If the port is open, test the actual connection with sqlcmd, SSMS, Azure Data Studio, or the application connection string.

If TLS is required, verify certificate trust and encryption settings from the client. Then check server logs for login failures, firewall denials, database-level permission errors, and connection timeout patterns.

If port 1433 is closed, SQL Server may not be running, TCP/IP may be disabled, the instance may use a different port, or a host, cloud, or network firewall may block the path. Named instances often fail because the actual dynamic port is different from what the client expects.

If the port is open but login fails, inspect authentication mode, username format, password state, disabled logins, database user mapping, permissions, encryption requirements, and server error logs. If queries connect but are slow, look at locks, indexes, CPU, memory, I/O, and query plans.

Keep SQL Server off the public internet wherever possible. Restrict sources, require encryption, patch the engine, disable unused logins, use least-privilege roles, rotate credentials, and audit failed logins and privileged actions.

Back up databases, test restores, monitor slow queries and replication health, and separate administrative access from application access. A database port is a direct path to sensitive data, so network reachability must be paired with strong identity and data controls.