新买的云主机装完 SQL Server，本地用 SSMS 能连，同事在自己电脑上试，先报 error 40，等十几秒又变成 10060。折腾一圈，问题就出在 1433 这个端口没通。

1433 是默认实例的端口

SQL Server 的默认实例固定监听 TCP 1433，客户端不写端口时连的就是它。命名实例默认走动态端口，每次启动都可能变，所以连接时要么写成主机名加实例名，要么装 SQL Server Browser 服务，让它用 UDP 1434 帮你查。

先确认服务真的在听

在服务器上执行 netstat -ano 加 findstr 1433，出现 LISTENING 才算开了。没有的话去 SQL Server 配置管理器，网络配置里找到这个实例的协议，把 TCP/IP 启用，再重启 SQL Server 服务。改完协议不重启，等于没改。

IPAll 那一栏清空动态端口，TCP 端口填 1433。有些人只启用了 IP1、IP2，漏了 IPAll，结果外网那块网卡根本不监听。

防火墙和云安全组两道门

netsh advfirewall firewall add rule name=sql dir=in action=allow protocol=TCP localport=1433

Windows 防火墙放行之后，云厂商的安全组还得再加一条入站规则。只开一边是最常见的失误，现象是 telnet 一直挂在那里不动。

报错码分别对应什么

  • 10060：连接超时，端口没通，查防火墙和安全组
  • 40：找不到实例，协议没启用或实例名写错
  • 18456：能连上但登录失败，账号、密码或认证模式不对
  • 4060：库打不开，权限不足或数据库已脱机

用 Test-NetConnection -ComputerName 服务器地址 -Port 1433 比 telnet 好用，能看到具体断在哪一步，失败时还给出提示。

别把 1433 直接暴露公网

SQL Server 挂在公网，日志里每天几千次爆破是常事。正确做法是只允许办公网段访问，或者走跳板机和 SSH 隧道；实在要开，也至少加白名单。改端口只能减少噪音，挡不住扫描器。

数据库端口这种基础设施，配一次就该写进交接文档，下次换人接手不用重新猜一遍。