SQL Server connection failures: isolate DNS, TCP, TLS and login

Begin with the exact client and error

A database connection crosses several boundaries before a query runs. Name resolution, transport, encryption, login and database authorization can fail independently. Treating every failure as a firewall issue wastes time and can produce unnecessary configuration changes.

Record the application host, SQL endpoint, instance name if used, intended TCP port, authentication mode, driver version and complete error text with a timestamp. Keep credentials out of the record. Identify whether the failure occurs consistently or only under a particular workload.

Microsoft's connectivity troubleshooting overview organizes failures by category. Run checks from the actual application host or its relevant network context; an administrator's laptop may have a different route and identity.

Check DNS and the intended endpoint

Confirm that the name resolves to the expected server or listener from the client context. In PowerShell, a diagnostic starting point is:

Resolve-DnsName sql-stage.example.com

Microsoft documents the Resolve-DnsName cmdlet and its options. The hostname is illustrative; substitute your documented SQL endpoint. Compare the returned address with the environment inventory, including aliases, listeners and any intended failover behavior.

If an application uses a different hostname from the one you tested, you have not yet tested its actual endpoint. An IP-address test may help isolate resolution, but changing the application permanently to an IP can affect certificate-name validation and other deployment assumptions. Resolve the mismatch rather than treating the diagnostic shortcut as the final design.

Test TCP reachability to the actual listening port

After confirming the endpoint and port, test transport from the application host:

Test-NetConnection sql-stage.example.com -Port 1433

Use 1433 only when the target instance is configured to listen there. A named instance can use another port, including a dynamic one. The DBA can confirm the listener through SQL Server configuration and its error log.

Microsoft's network troubleshooting guide distinguishes the SQL TCP port from SQL Server Browser discovery, which uses UDP 1434 when that mechanism is used. Do not request broad port openings merely because an instance is named.

A successful TCP test proves that connection to the tested address and port was possible at that moment. It does not prove certificate trust, valid credentials or permission to query a database.

Diagnose TLS after transport succeeds

A certificate or TLS error can occur after the TCP connection is established. Check the server certificate, the client's trusted certificate chain, the hostname used for validation and supported protocol behavior.

Driver upgrades can expose an encryption configuration that earlier clients did not validate in the same way. Microsoft's certificate trust troubleshooting guide describes this class of failure.

Work toward the intended encrypted connection with a correctly trusted certificate and matching server identity. Treat certificate-validation bypasses as changes to the trust model, not proof that the certificate problem is solved. Coordinate the diagnosis with the DBA and certificate owner rather than weakening settings until the error disappears.

Then check login and database authorization

If the server receives the connection and rejects the login, investigate the identity and authentication path. Confirm whether the application uses a SQL login, a Windows identity or another supported method. An interactive administrator test can succeed while the application service account fails.

After authentication, verify the selected database, user mapping and required permissions. A login reaching the instance does not automatically authorize the same principal to use every database. Restores and migrations can also change the surrounding account and mapping assumptions.

Use the SQL Server log and supported diagnostics to distinguish these cases. Microsoft's login failure reference describes error 18456 and its diagnostic states. Have the application owner and DBA compare the same timestamp, endpoint and identity context rather than alternating between unrelated successful tests.

Hand off evidence for the first failing layer

Build a concise evidence chain: the expected name resolves correctly; the intended TCP port is reachable or not; the client reports a TLS error or completes encryption; the server accepts or rejects the login; the requested operation succeeds or encounters a permission error.

Give the next team the failing check, where it ran, when it ran and what result was expected. For a failed transport test, include source, destination, protocol and confirmed listening port. For a login failure, include the authentication mode and relevant server-side error, without a password.

Repeat the original application workflow after a targeted fix. A working port probe or successful management-tool login is useful evidence, but the service is restored only when its own configured connection and required database operation work.