Navicat 连接 Azure SQL 超时主因是网络策略、防火墙或连接字符串配置错误，需检查 Azure 防火墙放行 IP、强制 SSL 加密、正确服务器名与端口、DNS 解析及 Navicat 客户端设置。
navicat 连接 azure sql 超时，90% 不是 navicat 的问题，而是 azure sql 的网络策略、防火墙或连接字符串配置没对。
检查 Azure SQL 防火墙规则是否放行你的 IP
Azure SQL 默认拒绝所有外部 IP 访问，即使你填对了服务器名和密码，也会卡在“连接超时”——它根本没走到认证那步。
- 登录
Azure Portal→ 找到你的 SQL 服务器 → 左侧菜单点「防火墙和虚拟网络」 - 确认「允许 Azure 服务和资源访问此服务器」已开启（否则 Navicat 从公网连不上）
- 在「添加客户端 IP」里点「添加当前客户端 IP」——注意：这是你本地出口 IP，不是内网 IP；如果用公司网络，可能需要联系 IT 获取真实出口 IP
- 如果用的是动态 IP（比如家用宽带），建议加一段 CIDR 范围（如
123.45.67.0/24），别只填单个 IP
确认连接字符串中服务器名、端口、加密参数正确
Azure SQL 强制要求加密传输，且不接受默认端口以外的自定义端口（即必须走 1433），错一个字符就会静默超时。
- 服务器名必须是完整格式：
your-server-name.database.windows.net，不能省略.database.windows.net - 端口必须留空或显式填
1433；填其他值（如1434）会导致连接挂起 - 「高级」选项卡中务必勾选
Use SSL，并设为Require（不是Allow或Prefer） - 如果启用了 Azure AD 身份验证，Navicat 版本需 ≥ 16.1，且连接类型要选
SQL Server Authentication+ 勾选Use Azure AD authentication，不能混用 SQL 登录
排查 DNS 解析与中间网络干扰
超时时间固定在 30 秒或 60 秒？大概率是 DNS 卡住或代理截断，而非数据库响应慢。
- 在命令行执行：
nslookup your-server-name.database.windows.net，看是否能秒级返回 A 记录；若超时或返回错误 IP，说明本地 DNS 不稳定，可临时改用8.8.8.8或1.1.1.1 - 执行：
telnet your-server-name.database.windows.net 1433，如果卡在「正在连接…」超过 10 秒，说明 TCP 握手失败——此时不是数据库问题，而是企业防火墙、上网行为管理设备或云安全组拦截了出向1433 - 某些公司网络会静默丢弃非 HTTP/HTTPS 流量，可尝试用手机热点重试，快速定位是否是本地网络策略导致
Navicat 客户端设置中容易被忽略的坑
即使服务端全 OK，Navicat 自身几个开关设错，也会表现为“连接超时”而非明确报错。
- 「高级」选项卡里的
Connection timeout建议设为60（默认常为 30），避免 DNS 解析慢时直接放弃 - 取消勾选
Auto Reconnect—— Azure SQL 不支持传统 MySQL 那种自动重连语义，开启反而导致连接状态混乱 - 不要启用
Keep connection alive（保持连接间隔）：Azure SQL 会主动 kill 空闲连接，心跳包可能触发更早断连，且无实际作用 - 如果用的是 Navicat Premium 15 或更老版本，升级到 16.x；旧版驱动对 Azure SQL 的 TLS 1.2+ 和 token 认证兼容性差，容易假死
真正卡住的地方往往不在数据库本身，而是在你和 Azure 数据中心之间的某一层：DNS、出口防火墙、安全组、SSL 握手、甚至 Navicat 驱动版本。先跑通 telnet 和 nslookup，再调 Navicat 设置，比反复改连接超时时间有用得多。
