系统常识 SQL Server命名实例动态端口
命名实例动态端口问题是怎么回事
命名实例默认用动态端口导致每次重启换端口的原理，客户端怎么被坑，以及固定端口、启用 SQL Browser 两种解法。
发布于 2026/11/11
所属频道 SQL Server
结论先行
命名实例（安装时取了名字的实例）默认启用动态端口：服务每次重启，引擎都重新挑一个 TCP 端口。结果就是「服务重启后远程客户端突然连不上」——防火墙按旧端口放行的规则全部失效。两种解法：把实例改成固定端口（推荐）或依赖 SQL Browser 服务解析动态端口。
动态端口的机制
- 客户端连
主机名\实例名时，先向 SQL Browser 服务发 UDP 1434 查询，问「这个实例现在在哪个端口」。 - Browser 返回当前动态端口，客户端再直连该端口。
链条上任何一环断掉（Browser 没开、1434 被防火墙挡、端口重启后变了而防火墙没跟上）都会表现为「连不上」，但本机 SSMS 往往还能连——因为本机查询路径更短、不受部分防火墙规则影响。
解法一：固定端口（推荐）
在 SSMS（SSMS 管理工具条目）右键实例 → 属性 → 数据库引擎 → 连接：
- 取消「使用动态端口」，填一个静态值（如 14340，避开 1433 被其他实例占用的冲突）；
- 重启 SQL Server 服务；
- 防火墙按这个静态端口放行；
- 客户端连接可写
主机名\实例名，或更直接的主机名,14340绕过 Browser。
解法二：依赖 SQL Browser
- 启用 SQL Browser 服务（默认可能禁用）；
- 防火墙放行 UDP 1434 + 各动态端口的实际范围（不固定就放行不了精确端口，要么宽放行、要么回到解法一）。
生产环境几乎都应该走解法一：固定端口 = 防火墙规则可审计、重启不漂移。解法二适合临时排查。
SQL Server 2022 Developer、SQL Server 2019 Developer 条目环境上动态端口行为一致；SQL Browser 服务的职责另见「SQL Browser 服务是干什么的」相关条目，SQL Server 产品族条目 中各版本通用。