应使用 telnet 或 nc 测试 TCP 端口连通性，而非仅依赖 ping；结合 traceroute 定位网络路径问题；检查数据库 bind_address/listen_addresses 配置是否允许跨网段访问；启用 Navicat 压缩与合理超时设置。
用 telnet 或 nc 测试端口连通性，别只靠 ping
ping 只能说明 ICMP 通，但 MySQL、PostgreSQL 等服务走的是 TCP，端口不通照样连不上。直接用 telnet 或更可靠的 nc 验证：
-
telnet 192.168.10.5 3306（Linux/macOS/WSL）或Test-NetConnection 192.168.10.5 -Port 3306（PowerShell） - 如果卡住几秒后报
Connection timed out，说明中间某处防火墙或路由策略拦截了该端口 - 如果立刻返回
Connection refused，说明目标机器上服务没监听，或bind-address配置为127.0.0.1 - Windows 用户若无 telnet，优先用 PowerShell 的
Test-NetConnection，它比 ping 更贴近真实连接行为
查路由跳数和丢包：tracert / traceroute 是必做项
跨网段延迟高，往往不是最后一跳的问题，而是中间某个节点存在策略限速、ACL 过滤或链路拥塞。不要跳过这步：
- Windows：
tracert -d 192.168.10.5（加-d跳过 DNS 解析，避免干扰） - macOS/Linux：
traceroute -n 192.168.10.5（-n同样禁用反向 DNS） - 重点关注：哪一跳开始出现 * * * 或明显延迟跃升（比如从 5ms 突增至 200ms）
- 若卡在企业防火墙、运营商出口或云平台安全组边界，需协同网络管理员检查对应策略是否放行 TCP 3306/5432 等端口
Navicat 自身的超时与压缩设置必须调
默认配置是为局域网设计的，跨网段不改参数，光靠“等”解决不了问题：
- 进连接编辑页 → Connection 标签 → 勾选
Use compression（MySQL 协议压缩对 WAN 效果显著，尤其 SELECT 大字段时） - → Advanced 标签 → 把
Connect timeout设为10，Read timeout和Write timeout改为60（防小抖动误断） - 若服务端是 MySQL 8.0+ 且用
caching_sha2_password，旧版 Navicat（≤16.0.18）握手多一次 RTT —— 升级到16.1.7+或临时切回mysql_native_password - 注意：
Use compression在 PostgreSQL 连接中叫Enable compression，位置在 SSH 或 SSL 标签下，别漏找
确认数据库是否监听在跨网段可访问地址
很多“跨网段连不上/慢”，本质是服务只绑定了本地地址：
- MySQL 查
SHOW VARIABLES LIKE 'bind_address';，若返回127.0.0.1，需改为0.0.0.0或具体内网 IP，并重启服务 - PostgreSQL 检查
postgresql.conf中listen_addresses是否含'0.0.0.0'或目标网段 IP；再看pg_hba.conf是否允许对应 CIDR 段（如host all all 192.168.10.0/24 md5） - SQL Server 确认 SQL Server Configuration Manager → SQL Server Network Configuration → Protocols → TCP/IP 已启用，且 IPAll 下的
TCP Port明确填了1433（而非空白或0） - 改完配置务必重启服务，且用
ss -tulnp | grep :3306类命令验证监听地址是否已变为*:3306
跨网段连接慢，真正耗时的往往不是 SQL 执行本身，而是三次握手、SSL 握手、认证协商这些前置步骤。一旦中间某个环节被策略限制或响应迟缓，Navicat 就会卡在 “Executing…” 或反复重试。把 telnet、traceroute、bind_address、Use compression 这四点串起来看，比盲目调大超时更有用。
