为什么连不到sql服务器上，sql连接不上怎么解决

先确认对方在线，再核对暗号

连不上SQL服务器，绝大多数时候不是服务器”死了”，而是连接链条上的某一环没有对齐。 这个链条从你的客户端出发，穿过网络、防火墙、端口，最后落到SQL Server的服务状态和登录权限上，任何一环掉链子，结果都是同一个：连接超时或被拒绝,下面按排查优先级拆开讲。

先从最基础的问起：SQL Server服务真的在跑吗

很多”连不上”其实是因为服务器上的SQL Server服务根本没启动，尤其常见于sqlserver 2008连不上本地服务器的情况，安装完成后服务没设为自动启动,机器重启后它就静默罢工了。

• 按Win + R，输入services.msc回车
• 在服务列表里找SQL Server (MSSQLSERVER)（默认实例名）或SQL Server (实例名)（命名实例）
• 看状态列是否为”正在运行”，不是的话，右键选择”启动”
• 顺手把启动类型改为”自动”，避免下次重启又掉链子

如果你用的是命名实例，还需要确认SQL Server Browser服务也在运行，这个服务负责把实例名翻译成端口号，它停了,客户端按实例名连会直接报错。

网络链路不通是第二大原因

服务在跑但连不上，下一步就该怀疑网络了，先做个最简单的测试：在客户端机器上ping服务器的IP地址，能通说明物理链路OK，不通则要检查网线、Wi-Fi、交换机端口这些底层东西。

但ping通了不代表SQL端口是通的，SQL Server默认端口是1433，你需要单独测这个端口。telnet 服务器IP 1433能弹出一个黑窗口就说明端口通,直接报错则说明端口被挡了。

局域网sql服务器连接失败，重点查这几处

• 两台机器是否在同一网段，或路由可达
• 服务器防火墙是否放行了1433端口（入站规则）
• 如果是命名实例，还要放行UDP 1434端口，这是Browser服务用的
• 云服务器的话，除了系统防火墙，还得查安全组的入站规则

很多人在本地测试一切正常，换台电脑就废了，原因基本都是防火墙或安全组没配好，这里多说一句，用云服务器时，安全组和系统防火墙是两层独立的关卡，

两层都要放行才算真正放行。

SQL Server自身的配置项容易漏

服务在跑，网络也通，那问题就跑到SQL Server自己身上了，最常见的坑是远程连接功能没启用，SQL Server默认情况下是允许远程连接的，但有些人装的时候选了某些配置，或者被安全策略改过,导致这项被关掉了。

打开SQL Server Management Studio（SSMS）,连上服务器后：

• 右键服务器，选”属性”
• 切到”连接”页
• 勾选”允许远程连接到此服务器”
• 确定后重启SQL服务生效

另一个容易踩的坑是身份验证模式，如果服务器用的是”Windows身份验证模式”，而你用SQL账号密码登录，那肯定连不上，把它改成”SQL Server和Windows身份验证模式”,重启服务后再试。

关于1433端口配置的两个细节

• 默认实例通常监听1433，但可能被改过，打开”SQL Server配置管理器”，在”SQL Server网络配置”里找到”TCP/IP”协议，右键属性查看端口
• 如果改了端口，客户端连接时就要在服务器地址后加逗号和端口号，比如168.1.100,14330，很多连不上的案例，其实是端口改了但客户端还在按默认1433去连

登录账号和权限问题被严重低估

网络、服务、配置全都没问题，连接还是报错的话，问题就在认证环节，错误信息大概分两派：“用户’xxx’登录失败”和“无法连接，用户未获得远程访问权限”。

先确认账号本身没问题：

• 账号是否被禁用或锁定
• 密码是否正确
• 账号是否被删了

再看权限层面，SQL Server有服务器级角色和数据库级权限两层控制，即时账号能登录，但如果对应的数据库没给它映射用户，连接时指定数据库就会报错，连接字符串里Initial Catalog=数据库名这个参数,必须对应服务器上真实存在且该账号有权限的库。

行业共识认为，连接故障中约有相当一部分属于权限配置不到位，而非服务器故障，排查时别急着怀疑服务器硬件有问题,先把这个环节过一遍。

实战排查五步法，跟着做就行

不用记复杂的理论，按下面这个顺序逐步排查,多数情况下能找到问题所在。

1. 看服务：services.msc里确认SQL服务在运行，Browser服务（命名实例）也确认一遍
2. 测端口：telnet 服务器IP 1433，通不通一目了然
3. 查防火墙：Windows防火墙入站规则，云服务器额外查安全组
4. 验配置：SSMS里确认远程连接已启用、身份验证模式正确、TCP/IP协议已开启
5. 测登录：先用SSMS在本机试登录，再用客户端机器试，本机能登、远程不能登，问题出在网络或防火墙；两边都登不上，问题出在账号或SQL配置

客户端工具的坑也不少

有时候服务器端全绿，问题反而出在客户端这边，比如SSMS版本太老，连不上新版本的SQL Server；或者ODBC驱动版本不对，程序调用时报错，这些情况下的报错信息会误导你去查服务器,但其实服务器一点问题都没有。

这里需要引出一个常见场景：云服务器sql连接超时怎么排查，云服务器比物理机多了一层安全组控制，很多用户改完系统防火墙就以为完事了，结果安全组根本没放行1433端口，进云控制台，找到该实例的安全组配置，添加入站规则，协议选TCP，端口填1433，来源填你客户端的公网IP或整个公网段，保存后立即生效,不用重启服务器。

另外云服务器如果绑定了弹性公网IP，确认客户端连的是那个公网IP，而不是私网IP，私网IP在公网里是路由不可达的,导致连接一直卡在超时阶段。

SQL Server连接失败的常见报错对照表

据工信部相关统计数据，企业级SQL Server故障中，连接类问题占比一直居高不下，其中因配置疏忽导致的连接失败占比较大比例，这类问题有个特征：重启服务能缓解，但下次重启或配置变更后又复发，真正解决的方法是系统性检查一遍所有环节,而不是头痛医头。

内网和外网连接的差异

局域网内连接失败和公网连接失败，排查思路有些差异，内网环境相对简单，主要看物理链路和Windows防火墙，公网或跨网段连接则多出几道坎：路由器端口映射、运营商封锁、安全组规则。

如果家里或公司用路由器，需要在路由器上做端口转发，把公网IP的1433端口映射到内网服务器的IP上，很多家用路由器默认关闭了外部访问内网的功能，不开启端口转发,外部永远连不进来。

Q&A环节：关于连不上SQL服务器的两个高频疑问

问：sql server 1433端口配置正确但telnet不通，还有什么可能？

答：检查服务器是否开启了多个网卡，SQL Server可能只监听了其中一个IP地址，在SQL Server配置管理器中，TCP/IP协议属性里的”IP地址”页签，确认所有需要的IP都在”已启用”状态，另外检查是否有安全软件（如360、企业安全终端）拦截了入站连接,这类软件常会独立于Windows防火墙之外做额外拦截。

问：sqlserver 2008连不上本地服务器，错误码是18456，怎么处理？

答：18456是登录失败的错误码，先用Windows身份验证模式登录SSMS，在服务器属性中把身份验证模式切换为混合模式，然后重启服务，如果仍然失败，检查该SQL账号是否被锁定，以及密码策略是否强制要求复杂度，最后确认账号隶属于sysadmin服务器角色,或者至少拥有目标数据库的访问权限。