每一位 SQL Server DBA 都可能在部署完毕后，遭遇过这样一个“劝退”式报错：

(provider: 命名管道提供程序, error: 40 - 无法打开到 SQL Server 的连接) → 拒绝访问。

你反复检查 IP、端口、账号、密码，甚至把 sa 密码复制粘贴了 100 遍，但结果依然是冷冰冰的拒绝。你以为是网络问题，是防火墙问题，甚至怀疑自己电脑中毒了。

别再折腾了！

真正的凶手是 SQL Server 独有的“协议管理”机制。

你的客户端 SSMS 试图用命名管道（Named Pipes）协议去连接，但 SQL Server 服务端却默认禁用了 TCP/IP，这导致连接必须走跨主机的 SMB 认证，最终被系统“拒绝访问”。

今天，【安呀智数据坊】将带你彻底告别这个新手噩梦。

我们提供一份保姆级 5 步 SOP，配合独家的一键排错脚本，帮你搞定 SQL Server 2019/2022 远程连接的所有历史遗留问题！

• 适用场景

主机通过 SSMS 连接虚拟机 / 远程服务器上的 SQL Server 时出现连接失败

• 适用版本

SQL Server 2016 / 2017 / 2019 / 2022

• 客户端工具

SSMS 18 / 19 / 20+

01

问题现象

在使用 SSMS 从主机连接部署在虚拟机中的 SQL Server 时（例如虚拟机 IP 192.168.74.90），填写正确的服务器地址、sa 账号和密码后，点击"连接"报错：

在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误。 未找到或无法访问服务器。请验证实例名称是否正确并且 SQL Server 已配置为允许远程连接。 (provider: 命名管道提供程序, error: 40 - 无法打开到 SQL Server 的连接) (Microsoft SQL Server，错误: 5) 其他信息: → 拒绝访问。

报错截图：

02

错误关键信息解读

这个报错包含 3 个关键信息，是解决问题的核心线索：

核心原因

命名管道（Named Pipes）是本机进程间通信协议，跨主机（尤其是主机 ↔ 虚拟机）连接时会走 SMB 协议，需要 Windows 域账号认证。

这不是远程数据库连接的正确方式。

远程连接 SQL Server 必须走 TCP/IP 协议，但错误提示走了命名管道，说明：

1） 🎯 SQL Server 端TCP/IP 协议未启用，或

2） 🎯 客户端连接串未强制指定使用 TCP 协议

03

问题根因分析

SQL Server 支持多种网络协议，默认优先级如下：

默认安装 SQL Server 后，TCP/IP 是禁用状态，只能本机连接。

这是很多新手远程连接失败的根本原因。

04

完整解决步骤

1

步骤 1：启用 TCP/IP 协议

（虚拟机端操作）

1）打开 SQL Server 配置管理器

开始菜单 → Microsoft SQL Server 2019 → SQL Server 2019 配置管理器

2）打开 SQL Server 配置管理器

依次展开左侧：

SQL Server 网络配置 → MSSQLSERVER 的协议

右侧列表中找到TCP/IP，如状态显示"已禁用"：

• 右键 →启用

3）配置 TCP 端口

双击TCP/IP→ 切换到"IP 地址"选项卡 → 滚动到最下方IPAll：

⚠️ 重点：TCP 动态端口必须清空，否则 SQL Server 会随机分配端口，1433 就不会生效。

2

步骤 2：重启 SQL Server 服务

配置修改后必须重启服务才能生效。

方式一：服务管理器

services.msc → SQL Server (MSSQLSERVER) → 右键 重新启动

方式二：PowerShell（管理员）

Restart-Service MSSQLSERVER -Force

3

步骤 3：验证端口监听状态（虚拟机端）

在虚拟机内 PowerShell 或 CMD 执行：

netstat -ano | findstr :1433

期望输出：

TCP 0.0.0.0:1433 0.0.0.0:0 LISTENING xxxx TCP [::]:1433 [::]:0 LISTENING xxxx

如果没有任何输出，说明 TCP/IP 配置未生效，返回步骤 1 检查。

4

步骤 4：放行防火墙端口（虚拟机端）

在虚拟机 PowerShell（管理员）执行：

# 放行 SQL Server 端口 New-NetFirewallRule -DisplayName "SQL Server 1433" -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow # 放行 SQL Browser（可选） New-NetFirewallRule -DisplayName "SQL Browser 1434" -Direction Inbound -Protocol UDP -LocalPort 1434 -Action Allow

快速排错时，可以临时关闭防火墙测试：

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

⚠️ 测试完成后记得恢复防火墙：

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

5

步骤 5：主机端连通性测试

在主机 PowerShell 执行：

Test-NetConnection 192.168.74.90 -Port 1433

期望结果：

ComputerName : 192.168.74.90 RemoteAddress : 192.168.74.90 RemotePort : 1433 TcpTestSucceeded : True ← 关键字段

6

步骤 6：SSMS 连接配置（主机端）

打开 SSMS，按以下方式填写连接信息：

关键技巧：tcp: 前缀

在服务器名称前加 tcp: 前缀，可以强制客户端使用 TCP 协议，避免走命名管道：

tcp:192.168.74.90,1433 ✅ 明确指定 TCP + 端口 192.168.74.90,1433 ⚠️ 可能走命名管道 192.168.74.90 ⚠️ 极可能走命名管道

7

步骤 7：连接成功验证

配置完成后点击"连接"，SSMS 左侧对象资源管理器出现数据库列表，即连接成功。

05

常见问题排查清单

按顺序排查，覆盖 99% 的连接失败场景：

06

常见错误对照表

07

原理小结

理解以下几点，以后不会再踩坑：

1） SQL Server 默认不开 TCP/IP，远程连接前必须手动启用

2）命名管道 ≠ TCP/IP，跨主机连接必须走 TCP

3）动态端口和固定端口只能二选一，配置固定端口时动态端口必须清空

4）修改协议配置后必须重启 SQL Server 服务

5）连接串加 tcp: 前缀是最保险的做法

6）防火墙 + SQL 配置 + 认证模式，三者缺一不可

08

一键排错脚本

将以下脚本保存为 check_sqlserver.ps1，在虚拟机端 PowerShell（管理员）执行：

Write-Host "==== SQL Server 连接环境检查 ====" -ForegroundColor Cyan # 1. 检查服务 Write-Host "`n[1] SQL Server 服务状态:" -ForegroundColor Yellow Get-Service MSSQLSERVER | Format-Table Name, Status, StartType # 2. 检查端口监听 Write-Host "[2] 1433 端口监听状态:" -ForegroundColor Yellow $listen = netstat -ano | findstr :1433 if ($listen) { Write-Host $listen -ForegroundColor Green } else { Write-Host "❌ 1433 端口未监听！" -ForegroundColor Red } # 3. 检查防火墙规则 Write-Host "`n[3] 防火墙 1433 规则:" -ForegroundColor Yellow Get-NetFirewallRule -DisplayName "*SQL*" -ErrorAction SilentlyContinue | Format-Table DisplayName, Enabled, Direction, Action Write-Host "`n==== 检查完成 ====" -ForegroundColor Cyan

写在最后

error: 40 让我们看到了 SQL Server 独特的“协议管理”机制。这份 SOP，不仅是解决报错，更是帮你建立起“网络协议先行”的运维思维。

记住这 5 步铁律：

• 启用 TCP/IP（打开门神）

• 固定端口 1433（明确门牌号）

• 重启 SQL 服务（让门神生效）

• 放行防火墙（撤销拦截）

• 连接串加 tcp: 前缀（明确出行方式）

告别 Oracle/MySQL/PostgreSQL 的“无需思考”，拥抱 SQL Server 的“精细化配置”！

您在 SQL Server 使用过程中，遇到过哪些让您“想不通”的报错？(是 error: 26、error: 53 还是 error: 18456？)

在评论区分享您的“协议血泪史”，让所有 DBA 引以为戒！

转发给你的开发和运维搭档，让他明白：SQL Server 的连接问题，往往不是网络，是协议！

作者介绍

大家好，我是刘峰，安丫科技创始人，一名专注数据库实战的技术讲师与顾问。

我拥有Oracle OCM和PostgreSQL ACE 双认证，同时是PostgreSQL 中国分会官方授权讲师。

技术栈覆盖主流商业库Oracle、SQL Server、MySQL，开源库 PostgreSQL，以及国产数据库 OceanBase、达梦、瀚高等产品。

过去十余年，我深度参与了电信、金融、政务、制造、互联网等多个行业的数据库项目。

完整经历过从传统 Oracle、MySQL 架构向 PostgreSQL、分布式数据库、国产信创库的技术演进与迁移实战。

项目交付内容涵盖数据库安装部署、备份恢复、巡检监控、高可用建设、性能调优、版本升级、异构迁移以及运维规范建设等多个方向。

在性能优化与故障诊断方面，我积累了大量实战经验。

从慢查询诊断、执行计划分析、索引优化、参数调优，到故障根因定位、应急处理，能够快速定位问题并给出可落地的解决方案。

特别是在跨数据库平台的性能对比与优化适配上，形成了一套相对系统的方法论。

除项目交付外，我也长期投入企业数据库技术培训工作。

面向 DBA 团队、开发团队和运维团队开展专题课程，内容包括 PostgreSQL 运维与调优、Oracle 数据库管理、MySQL 性能优化、国产数据库迁移适配、SQL 调优方法论、故障案例分析等。

安呀智数据坊｜我们能做什么

无论你是业务系统的技术负责人，还是数据部门的第一响应人，我们都能为你提供可靠的支持：

• 数据库类型支持

Oracle / MySQL / PostgreSQL / SQL Server 等主流数据库

• 核心服务内容

性能优化 / 故障处理 / 数据迁移 / 备份恢复 / 版本升级 / 补丁管理

• 系统性支持

深度巡检 / 高可用架构设计 / 应用层兼容评估 / 运维工具集成

• 专项能力补充

定制课程培训 / 甲方团队辅导 / 复杂问题协作排查 / 紧急救援支持

【安呀智数据坊·应急响应中心】

数据库故障往往发生在那 1% 的不可控时刻。

如果你正面临生产库崩溃、误操作导致数据丢失，且通过常规手段无法解决，请直接联系我们。

服务承诺：我们秉承“问题解决为先，方案闭环为本”的服务理念。

安全底线：全程签署企业级保密协议（NDA），保障数据安全是我们的第一铁律。

技术支援：拥有 Oracle ACE 专家带队的“十五年数据库急诊”团队。

本文涉及关键词：

SQL Server、命名管道、error 40、TCP/IP 协议、SSMS 连接失败、Named Pipes、SQL Server 配置管理器、防火墙 1433、动态端口、SQL Server 迁移、DBA 运维。

原文链接：https://mp.weixin.qq.com/s/hcveAHAPdio9zNKRwrfyWA