先确认1433是否真被占：用netstat -ano | findstr :1433查LISTENING及PID；若sqlservr.exe自占却连不上，问题多在协议、身份验证或防火墙；改端口须在SQL Server配置管理器中清空TCP Dynamic Ports、设TCP Port为纯数字、重启MSSQLSERVER服务；命名实例需客户端显式指定端口如myserver,1434；防火墙须添加TCP端口入站规则；连不上时优先检查TCP/IP是否启用、服务日志监听地址、telnet端口连通性。
SQL Server默认端口1433被占用，连不上怎么办
直接换端口不是最优解——先确认是不是真被占了，再决定动不动配置。很多情况下是 sqlservr.exe 没起来、防火墙拦了、或客户端连的是命名实例却没配 sql server browser 服务。
用这条命令快速验证端口状态：
netstat -ano | findstr :1433
如果输出里有 LISTENING 且 PID 不是 SQL Server 的（查任务管理器对比），才是真被占；如果是 sqlservr.exe 自己占着但连不上，问题大概率在协议或身份验证上。
SQL Server配置管理器里改TCP端口的实操要点
改端口本身不难，但改错位置或漏步骤会导致实例彻底失联。必须进 SQL Server 配置管理器（不是 Windows 服务管理器），路径是：「SQL Server 网络配置」→「MSSQLSERVER 的协议」→ 右键 TCP/IP →「属性」→「IP 地址」页签。
- 别只改
IPAll下的TCP Port，得把所有启用的IPx行里的TCP Dynamic Ports清空（设为 blank），否则动态端口会覆盖你填的固定值 -
TCP Port填纯数字，比如1434，别加冒号或括号 - 改完必须重启
SQL Server (MSSQLSERVER)服务，光重启 SQL Server Browser 不行 - 如果用的是命名实例（如
MyServer\INST1），改端口后客户端连接字符串必须显式带端口，例如：Server=myserver,1434;Database=xxx;
防火墙和客户端连接字符串怎么同步调整
开了新端口，Windows 防火墙默认不放行，连本地都连不上。别只加「程序」规则——sqlservr.exe 走的是端口通信，必须建入站规则放行 TCP 端口。
- 在「高级安全 Windows 防火墙」里新建入站规则 →「端口」→ TCP → 特定本地端口（如
1434）→ 允许连接 → 仅域/专用/公用按需选 - 客户端如果用 SSMS 连接，服务器名称不能写
myserver\instance，得写myserver,1434（注意是英文逗号） - .NET 连接字符串里，
Server值要从.\SQLEXPRESS改成localhost,1434，否则还是走默认 1433 或命名管道 - SQL Server Browser 服务只对命名实例 + 动态端口生效，改了固定端口后它其实可以关掉，但关之前确保所有客户端都已更新连接串
改端口后连不上？优先检查这三处
90% 的“改完连不上”问题出在这几个地方，比重装 SQL Server 快得多：
-
SQL Server 配置管理器里确认TCP/IP协议是「已启用」状态（右键看，不是只点了属性） - 服务日志里搜
Server is listening on，看实际监听的是哪个 IP+端口，有时候改的是 IPv6 地址段但客户端连的是 IPv4 - 用
telnet myserver 1434测试端口通不通，如果提示“无法打开到主机的连接”，说明网络层或防火墙卡住了，不是 SQL Server 配置问题
端口只是表象，背后常混着协议启用、服务状态、防火墙策略、客户端解析逻辑四层问题。调一个点就试一次，别堆一堆改动再验证。
