SQL Server错误10061表示目标计算机主动拒绝连接，根本原因是SQL Server服务未运行、TCP/IP协议未启用或端口被防火墙/其他程序拦截，需依次检查服务状态、网络配置和端口监听。
sql server服务根本没运行，10061就是最直接的信号
Navicat连SQL Server报10061，先看SQL Server服务状态
这个错误不是Navicat的问题，也不是连接字符串写错了——它本质是TCP层面的“没人应答”。10061在Windows系统里对应的是WSAECONNREFUSED，意思是客户端发了SYN包，但目标端口没有任何进程监听，直接被操作系统拒绝。所以第一步永远是确认SQL Server实例本身是否活着。
- 打开
services.msc，找名字带SQL Server (的服务（比如SQL Server (MSSQLSERVER)或SQL Server (SQLEXPRESS)），状态必须是“正在运行” - 如果显示“已停止”，右键启动；如果启动失败，查看“服务状态”列旁的错误提示（常见如
1061：服务无法在此时接受控制信息，说明依赖服务没起来，要先启SQL Server VSS Writer或SQL Server Agent） - 别只信任务管理器里的“进程”——
sqlservr.exe进程存在 ≠ 实例正常提供服务；必须以服务形式运行才绑定端口
SQL Server配置管理器里TCP/IP协议没启用
即使服务跑起来了，如果网络协议被关掉，照样收不到连接请求。很多人只检查服务状态，漏掉这步。
- 打开
SQL Server 配置管理器→SQL Server 网络配置→ 找到你的实例名对应的“协议”节点（如MSSQLSERVER 的协议） - 确认
TCP/IP右键菜单里是“已启用”，而不是灰色或“已禁用”；双击进去，IP地址页签下，IPAll部分的TCP端口要填数字（如1433），且TCP动态端口必须为空（否则会用随机端口，Navicat连不上） - 改完必须重启SQL Server服务，不重启等于没改
防火墙或端口冲突导致连接被拦截
服务开着、协议也启了，但telnet 127.0.0.1 1433不通？那问题就在中间环节。
- Windows防火墙默认会拦1433，进
高级安全Windows Defender防火墙→ 新建入站规则，放行TCP端口1433（或你自定义的端口） - 用
netstat -ano | findstr :1433查端口占用：如果输出里PID不是sqlservr.exe的，说明别的程序抢了端口（比如IIS Express、另一个SQL Server实例） - 远程连接时，还要确认服务器防火墙和云平台安全组（如阿里云/腾讯云）都开了对应端口，光开本地防火墙没用
真正卡住人的地方，往往不是技术多难，而是排查顺序错了——先跳过Navicat日志、先别改连接字符串，盯着服务状态、TCP/IP开关、端口监听这三件事死磕。只要其中一环断了，10061就必然出现，而且不会撒谎。
