Navicat for Mac SSH隧道连不上而终端能连通，主因是服务器端AllowTcpForwarding被设为no，或Navicat配置中数据库主机误填localhost（应填127.0.0.1）、私钥路径错误、SSH服务器未放行出向数据库端口、MySQL bind-address不兼容IPv4隧道等。
Navicat for Mac 连不上 SSH 隧道，但终端能连通
说明 SSH 服务本身是正常的，问题出在 Navicat 的隧道建立环节。最常见原因是服务器禁用了 TCP 端口转发，或者 Navicat 没有正确走隧道路径。
-
AllowTcpForwarding在/etc/ssh/sshd_config中被设为no—— 即使你用ssh -L手动测试成功，Navicat 的隧道实现依赖该配置，必须为yes - Navicat 默认不启用
RemoteForward，只依赖LocalForward，所以不用检查GatewayPorts - macOS 上若启用了
ssh-agent，而 Navicat 又没配置 Agent 转发（且私钥路径未显式指定），会静默失败 —— 建议直接填私钥文件路径，绕过 Agent - SSH 页面中勾选了【使用密钥】但【私钥】字段为空，或路径指向了一个损坏/权限错误的文件（比如
chmod 600缺失），Navicat 不报错但连接卡在认证阶段
常规页数据库主机填了 localhost 却连不上内网库
这是 macOS + SSH 隧道场景下最高频的误配。隧道建立后，Navicat 是从 SSH 服务器视角发起数据库连接的，“localhost” 指的是 SSH 服务器本机，不是你本地 Mac。
- 如果数据库和 SSH 服务在同一台机器上：常规页【主机】必须填
127.0.0.1（不能填localhost），否则 macOS 解析可能失败或走 Unix socket（Navicat 不支持） - 如果数据库在另一台内网机器（如
192.168.10.5）：常规页【主机】就填这个 IP，确保 SSH 服务器能 ping 通它；填localhost或127.0.0.1必然失败 - MySQL 的
bind-address若设为::1（IPv6 only），而 SSH 服务器默认用 IPv4 连接，也会导致“连接被拒绝” —— 查看sudo lsof -iTCP:3306 -sTCP:LISTEN确认监听地址
测试连接通过但双击连接后卡住或报 2002 错误
“测试连接”只验证到数据库认证前一步（即 TCP 连通 + 账号格式合法），不代表能真正执行查询。卡住往往意味着数据库服务响应慢、TLS 握手失败，或用户权限不足。
- Navicat for Mac 16+ 默认启用 TLS，若 MySQL 设置了
require_secure_transport = ON但没配证书，连接会卡在握手阶段 —— 在常规页取消勾选【使用 SSL】再试 - MySQL 用户权限只允许从特定 host 登录（如
'user'@'192.168.10.%'），而隧道过来的请求源 IP 是 SSH 服务器的内网 IP，需确认匹配 - SSH 服务器内存不足或负载高时，
sshd可能接受连接但延迟响应数据库转发请求，表现为 Navicat 界面无响应，tail -f /var/log/auth.log可看到大量channel 1: open failed: connect failed
防火墙和云平台安全组漏掉 SSH 端口转发链路
很多人只开了数据库端口（如 3306），却忘了 SSH 隧道本身依赖 22 端口的入站 + 出站双向通路。
- 本地 macOS 防火墙（系统偏好设置 → 防火墙 → 防火墙选项）若开启“阻止所有传入连接”，会拦截 Navicat 启动的本地转发端口（通常是随机高端口），导致隧道无法回传数据
- 云服务器安全组必须放行：入方向
22/TCP（SSH 登录），出方向也要放行3306/TCP（从 SSH 服务器访问数据库）—— 很多安全组默认只配入方向 - 企业网络中若部署了透明代理或 DPI 设备，可能重置 SSH 隧道的 TCP 连接，现象是连接几秒后断开，
tcpdump -i any port 22可捕获 RST 包
真实排查时，最容易被跳过的点是：**把“SSH 能连”等同于“SSH 隧道能用”**。前者只验证登录，后者还依赖服务端配置、网络策略、以及 Navicat 对隧道路径的严格解析逻辑。
