Port 1433: Test SQL Server Connectivity Safely

Q: Is SQL Server port 1433 TCP or UDP?

SQL Server database traffic on port 1433 normally uses TCP. UDP port 1434 is associated with SQL Server Browser, which helps clients discover the TCP port used by named instances.

Q: How do I check whether port 1433 is open?

Test from the same client network path as the application. On Windows, run Test-NetConnection with the authorized host and port 1433, then inspect TcpTestSucceeded. Confirm the actual instance port first.

Q: Does an open port 1433 prove that SQL Server works?

No. A successful TCP test proves only that the target accepted a network connection on that port. It does not validate authentication, permissions, TLS, database names, or query execution.

Q: Should port 1433 be exposed to the public internet?

Avoid broad public exposure. Prefer private networking, narrow source allowlists, encryption, least-privilege accounts, monitoring, and a documented need for each firewall rule.

What is port 1433 used for?

Port 1433 is the conventional default TCP port for a default Microsoft SQL Server Database Engine instance. It is not guaranteed to be the active port. A named instance may choose a dynamic port, and an administrator can assign a different static port. Confirm the real listening port before changing a firewall rule.

TCPDatabase session transport

1433Default instance convention

UDP 1434Browser discovery

1 pathTest from the real client

Port 1433 vs 1434: test the correct protocol

The similar numbers cause a common diagnostic mistake. SQL Server database connections normally use a TCP port. For a default instance, that is commonly TCP 1433. SQL Server Browser listens on UDP 1434 and tells a client which TCP port a named instance uses. Browser discovery is not the database session itself.

Component	Typical port	Purpose	What to test
Default instance	TCP 1433	Database connections	TCP path from the application
Named instance	Dynamic or assigned TCP port	Database connections	Discover the actual port first
SQL Server Browser	UDP 1434	Instance-to-port discovery	Only when discovery is required

What an open port 1433 proves—and does not prove

A successful TCP test proves

The tested client can resolve the target and complete a TCP connection to the selected host and port at that moment.

It does not prove

SQL authentication, database permissions, TLS compatibility, database names, application connection strings, query execution, or production readiness.

Use reachability as the first layer of a layered diagnosis: DNS, route, firewall, listening socket, TLS, authentication, authorization, and application behavior. This prevents the misleading conclusion that “the port is open, so SQL Server is healthy.”

Collect four facts before testing port 1433

Exact hostUse the same DNS name or private IP the application uses. Testing localhost answers a different question.
Actual instance portCheck SQL Server Configuration Manager or the error log. Do not assume a named instance uses 1433.
Real client network pathRun the test from the application host, subnet, VPN, container, or build agent that experiences the failure.
AuthorizationTest only approved systems. A port test needs a host and port—not a password, connection string, or production secret.

How to check if port 1433 is open

Confirm the listenerReview TCP/IP settings and the error-log entry that reports the listening address and port. Restart the Database Engine if a configuration change requires it.
Test from the affected clientReplace the placeholder below with an authorized DNS name or private IP. A true result confirms TCP reachability only for that source, destination, and moment.
Use an explicit endpointTo bypass instance discovery, use tcp:server.example,1433. If the instance listens elsewhere, substitute the verified port.
Continue above the network layerIf TCP succeeds but the application fails, inspect TLS, login method, account state, permissions, database name, driver, and connection-string options.

PowerShell

# Run from the same network path as the application.
Test-NetConnection -ComputerName db.internal.example -Port 1433

# Inspect the network-layer result:
TcpTestSucceeded : True

Do not publish real hosts, IP addresses, credentials, or connection strings. Use sanitized values when sharing diagnostic evidence.

Interpret common port 1433 test results

Result	Likely meaning	Next check
`TcpTestSucceeded: True`	TCP reached a listener	Test TLS, login, database selection, and permissions
Connection refused	The target responded, but no listener accepted the port or a device actively rejected it	Verify service, port, binding, and local firewall
Timeout / filtered	A firewall, route, VPN, security group, or ACL may drop packets	Trace source-to-destination policy from the correct subnet
DNS failure	The client cannot resolve the host	Check private DNS, VPN, suffix, and spelling
Login or TLS error after TCP succeeds	The network works; the failure is higher in the stack	Check certificates, encryption, authentication, driver, and permissions

Why SQL Server port 1433 is not listening

A missing 1433 listener does not automatically mean SQL Server is down. The instance may be healthy on another port. Check these causes in order:

Named instance: it may use a dynamic TCP port.
TCP/IP disabled: the protocol may not be enabled for this instance.
Pending restart: a port change may not take effect until the service restarts.
Wrong IP binding: the expected interface may be disabled or configured differently.
Port conflict: another process may already own the configured port.

The SQL Server error log records which IP addresses and ports the server is listening on. That evidence is more reliable than assuming the default.

Configure access without overexposing port 1433

An inbound rule should be a narrow business exception, not blanket internet exposure. Define the verified destination and TCP port, approved source ranges, environment, owner, review date, and removal condition.

Preferred controls

Private networks, VPN or peering, source allowlists, segmentation, TLS, least-privilege accounts, monitoring, and expiring change records.

Avoid

Opening TCP 1433 to every source, embedding credentials in scripts, or leaving temporary rules active after testing.

Validate every layer after port 1433 becomes reachable

A successful TCP connection is a useful boundary, but it is not the finish line. It shows that the tested client reached a listening process at the resolved address and port during that attempt. It does not identify the process as the intended SQL Server instance, prove that encryption policy can be negotiated, authenticate a login, select the expected database, authorize an operation, or show that a query returns correct results. Preserve the endpoint, source network, timestamp, resolved address, and command output so the result can be compared with application logs rather than remembered informally.

Validation layer	Evidence of success	If it fails
Name resolution	The hostname resolves to the approved address for the intended environment.	DNS suffix, private zone, VPN context, stale cache, and split-horizon records.
TCP reachability	A connection to the verified host and configured SQL Server TCP port succeeds.	Listener binding, routing, firewall, security group, network ACL, and source allowlist.
TLS and pre-login	The driver and server agree on encryption and the certificate is valid for policy and hostname.	Driver version, trust chain, certificate name, expiry, protocol version, and encryption settings.
Authentication	The intended Windows, SQL, federated, or workload identity is accepted.	Authentication mode, account state, credential source, clock, identity mapping, and sanitized error code.
Database authorization	The login maps to the intended database user and can perform only the required operation.	Default database, user mapping, roles, explicit denies, object grants, and row-level policy.

Run the application-level test from the same execution context as the failing workload whenever possible. A successful administrator test from a laptop may use a different DNS resolver, route, source address, driver, certificate store, identity, or connection string. Match the real workload before concluding that port 1433 is healthy. If a temporary firewall exception is used to isolate the cause, give it an owner and expiry, record the before-and-after result, then remove it promptly.

Check the SQL Server endpoint before deeper debugging

Use the InfiniSynapse DB Compatibility Checker to verify TCP reachability for an authorized SQL Server host and port. For SQL Server, this check is limited to the network endpoint: it does not validate credentials, TLS, permissions, or query execution.

Open DB Compatibility Checker Use only authorized, sanitized endpoint information. Do not paste secrets.

A practical decision tree for port 1433 failures

Can the client resolve the hostname?If no, fix DNS, VPN, or the endpoint before inspecting SQL Server.
Is the verified TCP port reachable?If no, distinguish refusal from timeout, then inspect listener, routing, firewall, security group, and source allowlist.
Can the SQL client complete TLS and authentication?If TCP passes but the client fails, focus on certificates, encryption, login method, account state, and driver behavior.
Can the account access the intended database?Validate the database name, default database, mappings, roles, and least-privilege permissions.

Port 1433 FAQ

What is port 1433 used for?

TCP port 1433 is the conventional default port for a default Microsoft SQL Server Database Engine instance. Named instances may use dynamic ports, and administrators can assign another static port.

Is SQL Server port 1433 TCP or UDP?

Database traffic on 1433 normally uses TCP. UDP 1434 is associated with SQL Server Browser and named-instance discovery.

How do I check whether port 1433 is open?

From the application's network path, run Test-NetConnection with the authorized host and verified port, then inspect TcpTestSucceeded.

Why is SQL Server port 1433 not listening?

The instance may use a dynamic or custom port, TCP/IP may be disabled, a restart may be pending, or the test may target the wrong interface.

Does an open port 1433 prove that SQL Server works?

No. It proves TCP reachability only, not authentication, permissions, TLS, database names, or query execution.

Should port 1433 be exposed to the public internet?

Avoid broad public exposure. Prefer private networking, strict source allowlists, encryption, least privilege, and monitoring.

Official Microsoft references

Port behavior and troubleshooting guidance were verified against Microsoft documentation. InfiniSynapse product claims are limited to the tool's stated TCP reachability scope.