下午三点十七分，录报隔壁工位的录报小周又对着屏幕骂了一句。我探头一看，录报熟悉的录报黄色警告框，SQL Server 2008，录报错误码 40。录报这已经是录报本周第三次了。他重启了服务，录报检查了网络，录报甚至把防火墙关了又开，录报结果还是录报连不上。最后他干了一件事——把连接字符串里的录报服务器名从“localhost”改成了“127.0.0.1”，问题瞬间消失。录报

这个错误码 40 的录报全称是“无法打开到 SQL Server 的连接”。微软官方的录报解释绕来绕去，什么网络相关或实例-specific 的错误。但根据我这几年在运维泥潭里摸爬滚打的经验，它十有八九不是 SQL Server 本身的问题，而是你根本没找到那扇门。门都没摸到，谈什么钥匙？

最常见的坑，是服务压根没起来。别笑，真有人查半天网络，最后发现 SQL Server 服务是停止状态。打开“服务”管理器，找到 MSSQLSERVER 或者你命名的实例名，看看状态列。如果是“已停止”，右键启动就行。但更隐蔽的情况是服务起来了，却只监听在特定的 IP 上。比如服务器配了双网卡，SQL Server 默认只绑定了内网 IP，你从外网用公网地址去连，它连个响应都不给你，直接报 40。

另一个高频雷区是“命名管道”和“TCP/IP”协议被禁用。SQL Server 安装时默认开启共享内存，但有时候为了“安全”，管理员会把 TCP/IP 给禁了。这时候你本地用共享内存能连上，远程一用 IP 就报 40。解决方式很粗暴：打开“SQL Server 配置管理器”，找到“SQL Server 网络配置”，把 TCP/IP 启用，然后重启服务。别问我为什么默认没开，问就是微软的脑回路你猜不透。

还有种情况，纯粹是防火墙在作祟。Windows 防火墙默认会拦掉 1433 端口，但问题是你得确认 SQL Server 真的在监听 1433。用 netstat -ano 看一下，如果监听端口是动态的（比如 49351），那就是你之前没设置固定端口。这时候要么改 SQL Server 的端口为 1433，要么在连接字符串里加上端口号。别指望防火墙自动放行，它没那个智能。

说个我自己的糗事。有次部署测试环境，怎么连都报 40，日志查遍了，服务正常，端口监听正常，防火墙也关了。最后发现是连接字符串里多打了一个空格——在服务器名后面。对，就一个空格。SQL Server 的客户端解析这玩意儿的时候，直接把空格当成主机名的一部分，然后去 DNS 里找不到，瞬间报错。那个下午我抽了半包烟，就为了一个空格。

回到小周的问题。他改了 localhost 为 127.0.0.1 就能连上，说明他机器上 SQL Server 的配置里，TCP/IP 的监听地址没有包含 IPv6 的 ::1。而 localhost 会优先解析成 IPv6 地址，结果连不上。这种问题在 Windows 10 和 Server 2016 之后特别常见。解决方案有两个：要么在 hosts 文件里把 localhost 强制指向 127.0.0.1，要么去 SQL Server 配置里把 IP6 的监听也勾上。我推荐前者，省事。

最后提醒一句，报错 40 的时候，先别急着重启服务或者重装。打开 SQL Server 的错误日志，位置通常在安装目录下的 \MSSQL\Log\ERRORLOG 文件。看最后几行，如果里面有“Server is listening on”之类的字样，说明服务正常，问题在网络层。如果什么都没有，那才是服务本身没起来。日志不会骗人，但人经常骗自己。

小周后来跟我说，他把那个空格的问题记在了笔记本上。我笑了笑，没告诉他，这行字他下个月就会忘掉。因为这种错误，永远是在你最着急的时候冒出来，然后花掉你一下午，最后解决方式简单到让你想砸电脑。

(责任编辑：热点)