Navicat 连接 MySQL 遇到最多的问题不是用户名密码写错而是网络层面根本不通。上周就有个同事拿着一台内网 MySQL 的地址来问我跳板机信息都拿到了为什么 Navicat 直连就是超时我一看配置就明白他把跳板机当成了摆设直接在“主机”栏填了 192.168.x.x。数据库只在内网公网上唯一能到达的入口就是那台跳板机的 SSH 端口连接方式自然要从“直连”改成“经跳板机转发”。这篇文章把两种我实际用过很久的方案都写清楚Navicat 自带的 SSH 通道图形化配置以及更通用的本地端口转发命令行。适合刚接手内网数据库的后端、测试、DBA也适合只想搞明白“为什么这样配、报错到底卡在哪一步”的人。先说结论只要跳板机的 SSH 能登录Navicat 连内网 MySQL 就一定可以通问题只在于配置时把每份地址填到了正确的位置。1. 为什么必须绕行跳板机理解网络隔离下的数据库访问现状1.1 只有内网 IP 的 MySQL直连注定失败很多刚遇到这个场景的人第一反应是检查 MySQL 服务有没有启动、端口是不是 3306、账号密码有没有错。但真正的问题常常在更底层目标 MySQL 根本没有公网地址它只在公司内网网段里监听。哪怕你把 Navicat 里的主机、端口、用户名、密码全部填对从你的电脑发出的 TCP 包也根本找不到通往那台机器的路由表现就是卡在“连接中”最后超时。我见过不少同事在这种状态下反复重试甚至怀疑是 MySQL 配置问题跑去服务器上改 bind-address结果依然连不上。原因很简单不是 MySQL 不让你连而是网络层面的包就过不去。这时候正确的思路不是去改数据库而是承认一个现实——当前网络环境下只有跳板机这一条路能到内网所有数据库流量都必须从这条路走。1.2 三个看似可行、实际坑人的替代方案既然直连不通有人会动“抄近路”的心思。我印象最深的有三种都见过真实翻车案例把 MySQL 的 3306 端口直接映射到公网。这个操作最危险等于把数据库裸奔在公网上。扫描器每天都在扫常见端口一旦发现 3306 对外开放接下来就是持续的暴力破解。为了省一次跳板登录把生产库暴露给全网代价完全不成比例。在跳板机上装一套 Navicat远程桌面过去操作。跳板机通常是 Linux没有图形桌面强行装图形环境既重又难维护而且多人共用一台跳板机时每个人都要抢桌面会话连接配置混在一起审计也说不清谁做了什么。通过 TeamViewer 之类的远程软件连到一台内网电脑再操作。延迟高不说内网电脑的屏幕、文件也可能一并暴露安全边界完全是糊的。这三个方案共同的问题是没有把跳板机当作“受控入口”而是当成了“临时的跳板工具”。临时用一次看似方便长期用下去全是隐患。1.3 跳板机的定位唯一入口和审计关口想清楚跳板机是干嘛的后面配置就不会糊涂。跳板机的核心价值不是让你“多跳一跳”而是把原本内网里任意可达的服务收敛成一个公网唯一入口。所有访问内网的人都必须先通过 SSH 登录跳板机身份的认证、操作的审计都集中发生在这一层。你可以把跳板机理解为小区门卫访客不能直接闯进任意一栋楼必须先到门卫处登记身份门卫确认后才放行。SSH 通道就是“门卫带你走专用通道进去”的过程——它不暴露楼里的住户只让你在授权范围内访问指定房间。Navicat 里所谓的 SSH 通道做的正是这件事先在跳板机上完成身份认证随后把访问内网 MySQL 的流量安全地“搬运”过去。2. Navicat 内置 SSH 功能图形界面完成全部配置2.1 两份连接信息的填写方式Navicat 的图形化方案最适合不想记命令的人也是我最推荐的入门方式。整个配置只需要填两份信息一份是目标 MySQL 的真实内网地址一份是跳板机的登录信息。我先给一个示例环境后面所有步骤都按这个来角色参数示例值目标 MySQL内网地址192.168.1.100目标 MySQL端口3306目标 MySQL数据库账号app_user跳板机公网地址203.0.113.10跳板机SSH 端口22跳板机登录用户ops打开 Navicat点击“连接”-“MySQL”会看到常规和 SSH 两个标签页“常规”标签里连接名随便写比如“生产库-经跳板机”主机填 192.168.1.100端口填 3306用户名和密码填 MySQL 自己的账号。切到“SSH”标签勾选“使用 SSH 通道”。主机填 203.0.113.10端口填 22用户名填 ops。认证方式先选“密码”填跳板机的登录密码。切回“常规”标签点“测试连接”。如果前面的信息都正确会提示连接成功。有一个细节容易忽略SSH 标签里的“主机”填的是跳板机不是 MySQL。“常规”标签里的“主机”填的是 MySQL不是跳板机。这两个地址填反或者都填同一个地址是新手最常犯的错。2.2 密码认证与公钥认证怎么选用密码认证最省事跳板机给你什么密码就填什么密码。但在实际生产环境里我强烈建议使用公钥认证理由很简单密码会被爆破、会被分享、会被截图而私钥是本地文件理论上只有你自己持有。配置公钥认证需要三步。第一步在本地生成一对密钥ssh-keygen -t ed25519 -C opswork-laptop一路回车就行生成后会在~/.ssh/下出现id_ed25519私钥和id_ed25519.pub公钥。第二步把公钥内容追加到跳板机对应用户的~/.ssh/authorized_keys文件里。第三步在 Navicat SSH 标签里把认证方式从“密码”改为“公钥”选择本地私钥文件id_ed25519加载即可。如果生成密钥时设置了 passphrase还需要在 Navicat 里填写对应的私钥口令。这里有个常见的坑如果手里的私钥文件是 PuTTY 的 .ppk 格式Navicat 直接加载会报错。需要先用 PuTTYgen 把私钥导出成 OpenSSH 格式或者干脆重新生成一对新密钥。另外私钥文件的权限很重要在 Linux/macOS 上要设为 600否则 SSH 客户端会拒绝使用。2.3 Navicat 版本差异与界面细节Navicat 16、17 系列的 SSH 标签位置基本一致选项名称略有差异中文版常见的是“使用 SSH 通道”英文版是“Use SSH tunnel”。界面上还有一个“保留 SSH 通道”或“Keep SSH tunnel”的选项默认不勾选即可。它的作用是连接关闭后是否维持 SSH 通道存活。如果你只是每天打开 Navicat 用几分钟没必要开如果你会频繁断开重连同一个连接勾上可以减少重复握手的时间。另一个和版本强相关的问题是连接 MySQL 8 时的认证插件。MySQL 8 默认使用caching_sha2_password较老的 Navicat 版本会报“Unable to load authentication plugin”或 2059 错误。碰到这种情况优先升级 Navicat 到较新版本而不是去 MySQL 里把认证插件降级成mysql_native_password——后者是降低安全性的行为除非有非常强的兼容性理由否则不推荐。3. 命令行端口转发方案一台跳板机服务多个本地工具3.1 命令行方案比 Navicat 内置方式更灵活的场景Navicat 内置 SSH 通道已经很方便但我在实际使用中有几个场景还是会切到命令行方案需要同时用命令行 mysql 客户端、临时脚本、其他 GUI 工具访问同一台内网 MySQL 时内置通道只服务 Navicat命令行工具用不上。Navicat 的 SSH 握手报错但又不确定是跳板机问题还是 Navicat 问题。先用命令行手动建立通道能把故障范围快速缩小。自动化任务需要后台常驻一条到内网的通道自然也只能靠命令行。命令行方案的本质是用 SSH 客户端在本地监听一个端口把该端口接收到的流量全部转发到目标内网地址。通道建立之后Navicat 连的是“本机地址”而不是直接连跳板机。3.2 ssh -L 端口转发命令逐项拆解最常用的命令是ssh -L 3307:192.168.1.100:3306 -N -f -p 22 ops203.0.113.10拆开看每个参数-L 3307:192.168.1.100:3306本地监听 3307 端口所有到这个端口的 TCP 流量都会被转发到 192.168.1.100 的 3306。-N只建立转发通道不执行远程命令。没有它SSH 登录后会进入一个 shell而通道在 shell 退出时也会断开。-f登录认证成功后转入后台运行。配合-N使用终端就不会一直挂着一个前端进程。-p 22跳板机的 SSH 端口如果跳板机改了端口这里跟着改。ops203.0.113.10跳板机的登录用户和地址。命令执行后会提示输入跳板机密码认证通过后回到本地 shell。这时再打开 Navicat新建一个 MySQL 连接“常规”标签的主机填127.0.0.1端口填3307用户名和密码仍然是 MySQL 的账号测试连接就能通。为什么用 3307 而不是 3306因为本地机器很可能已经装了 MySQL 或者占用了 3306换一个不常用的高位端口可以避免冲突。这个本地端口可以随你定只要没被占用就行。如果还有很多其他内网服务要访问可以通过多条-L参数一次性建立多个转发ssh -L 3307:192.168.1.100:3306 -L 6379:192.168.1.101:6379 -N -f \ -p 22 ops203.0.113.10这样从本地同时访问内网 MySQL 和 Redis只占用一条 SSH 会话。3.3 断线重连与后台运行的保活技巧单纯用ssh -L -N -f有个体验上的短板网络抖动、跳板机重启、笔记本休眠都可能导致通道断开而且它不会自动恢复。短时间用无妨长时间挂着还是要做保活。最简单有效的办法是加心跳参数ssh -L 3307:192.168.1.100:3306 -N -f -p 22 \ -o ServerAliveInterval60 -o ServerAliveCountMax3 \ ops203.0.113.10ServerAliveInterval60表示每 60 秒发一个保活包给跳板机ServerAliveCountMax3表示连续 3 次没有收到响应才判定连接断开。这样运营商层面的空闲连接被回收之类的问题能少很多。想更省心可以上 autossh它会自动检测通道掉线并重新建立autossh -M 0 -L 3307:192.168.1.100:3306 -N -f -p 22 \ -o ServerAliveInterval60 -o ServerAliveCountMax3 \ ops203.0.113.10Windows 用户也不用手动装软件。Windows 10 之后系统自带 OpenSSH 客户端可直接在 PowerShell 或 Git Bash 里跑上面的命令。macOS 和 Linux 更不用说原生支持。跨平台体验一致这也是我更喜欢命令行方案的原因之一。4. 权限、端口、信任关系底层链路拆解4.1 本地应用、SSH 服务端、MySQL 之间的四段链路很多人配置成功后就满足了但一旦报错就会懵因为他们不理解流量到底怎么走的。把链路拆开看其实只有四段本地 Navicat 连接到本机 127.0.0.1:3307这是本地进程之间的通信速度极快不会受网络影响。SSH 客户端把这个连接的所有字节流加密发送到跳板机 203.0.113.10:22。跳板机上的 sshd 解密后取出“目的地是 192.168.1.100:3306”的请求替本地发起一个到目标 MySQL 的 TCP 连接。MySQL 返回的数据原路反向走回跳板机再由跳板机加密回传给本地。理解了这一段很多问题就一目了然。比如从 MySQL 的视角看连接它的人不是本地电脑而是跳板机。因为真正发起到 3306 端口 TCP 连接的是跳板机上的 sshd 进程而不是你本地的 Navicat。这个认知直接影响账号授权怎么写下一节细说。4.2 MySQL 的 host 授权要写跳板机内网地址这是我见过最隐蔽的坑本地电脑在公网跳板机在内网MySQL 位于更深的业务内网。许多人创建 MySQL 账号时习惯性地把 host 写成user%或者写成自己的公网 IP结果用 Navicat 通过跳板机连接时报 1045 Access denied。原因在于 MySQL 授权表的匹配依据是 TCP 连接的源 IP。由于真正连接到 MySQL 的机器是跳板机源 IP 自然是跳板机在你内网里的地址比如 10.0.0.5。你授权给本地公网 IP 根本匹配不上授权给%又可能不符合安全要求。正确做法是登录 MySQL把账号授权到跳板机的内网地址CREATE USER app_user10.0.0.5 IDENTIFIED BY StrongPassword; GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO app_user10.0.0.5; FLUSH PRIVILEGES;如果一台跳板机可能更换 IP或者不止一台跳板机也可以授权到整个网段app_user10.0.0.%。不建议直接%那等于放宽到整个网络违背了“最小权限”原则。还有一种特例如果 MySQL 就跑在跳板机的本机上那跳板机回连的目标地址就是 127.0.0.1授权 host 写成127.0.0.1或localhost即可。4.3 跳板机侧需要满足的三个前置条件跳板机能完成转发自身必须满足三个条件缺一个通道都建不起来但表现又可能不同。第一个是 sshd 服务本身允许 TCP 转发。绝大多数发行版默认配置里AllowTcpForwarding yes所以通常不会踩到但如果跳板机被刻意加固过关掉了端口转发就会出现“SSH 能登录但 Navicat 连不上”的诡异现象。检查方式是登录跳板机后查看/etc/ssh/sshd_config确认没有AllowTcpForwarding no。第二个是跳板机要能访问目标 MySQL 的端口。跳板机虽然在内网但不代表它能访问内网任意一台机器很多公司会对跳板机本身做防火墙策略只开放特定网段。验证方法很简单登录跳板机后执行ssh ops203.0.113.10 nc -vz 192.168.1.100 3306或者用 MySQL 客户端直接试mysql -h 192.168.1.100 -P 3306 -u app_user -p如果这一步就超时或拒绝连接那就是跳板机到 MySQL 之间的网络策略问题跟 Navicat 没有关系不用在本地反复折腾。第三个是 MySQL 的监听地址要能被跳板机访问。如果 MySQL 的bind-address设置为127.0.0.1那就只有本机能连跳板机也连不上。对于需要被内网其他机器访问的 MySQL通常需要将bind-address设置为0.0.0.0或者具体的业务内网地址。这里要区分清楚bind-address控制的是“允许哪些网络接口上的连接进来”而 MySQL 账号里的 host 控制的是“允许哪些来源 IP 认证”两个层面都要配置正确。5. Navicat 连接失败高频问题与排错链路5.1 自下而上的五步排查路径通过跳板机连接 MySQL 的报错种类不少但多数都能沿着链路逐段定位。我自己习惯按下面的顺序排查效率最高本地到跳板机的 TCP 层是否通。在本地执行ssh -p 22 ops203.0.113.10如果能正常登录说明 SSH 服务通如果超时检查跳板机公网地址、端口是否被防火墙或安全组拦截。认证是否通过。登录时报Permission denied (publickey,password)说明密钥或密码不对如果密码正确但仍被拒绝有可能是跳板机上该用户被限制了登录方式比如只允许密钥登录。跳板机到目标 MySQL 的链路是否通。登录跳板机后执行nc -vz 192.168.1.100 3306不通则排查跳板机出方向防火墙、MySQL 监听地址。MySQL 账号授权是否正确。在跳板机上用 mysql 客户端直接连目标库报 1045 则回到账号 host 授权问题上。最后检查 Navicat 里的映射关系。确认“SSH 标签填跳板机常规标签填目标 MySQL 或转发后的本地端口”这一步往往在报错信息不明显时成为盲点。这套顺序的核心思路是不要一上来就怀疑 Navicat先用手工命令行把每一段链路验证通哪一个环节失败问题就锁定在哪个环节。5.2 高频报错原因与解决对照表以下报错是我在帮同事排查时出现频率最高的整理成一张表方便对照报错信息出现位置常见原因处理方案1045 Access denied for userMySQL 认证账号密码错误或 host 授权不匹配用正确账号重新授权host 写跳板机内网地址2003 Cant connect to MySQL serverMySQL 网络MySQL 未监听或跳板机到 MySQL 网络不通检查 bind-address、防火墙、nc 连通性10060 / 10038TCP 连接跳板机到目标端口被防火墙拦截检查跳板机出方向和 MySQL 所在安全组SSH: Connection refused跳板机SSH 端口不对或 sshd 未启动确认跳板机 SSH 端口测试nc -vz 跳板机 22SSH: Permission denied跳板机认证密码/密钥错误或仅允许公钥登录核对凭据私钥格式转成 OpenSSH2059 authentication pluginMySQL 8 认证Navicat 旧版不支持 caching_sha2_password升级 Navicat或按需调整 MySQL 认证插件Address already in use本地端口转发本地端口已被占用换一个未占用的本地端口重新建立转发表中的前三类都指向网络层后几类指向认证层。建议遇到报错先确定“是网络不通还是认证失败”这决定了排查方向。判断方法很简单看报错文本是在 TCP 连接阶段就失败还是已经进入 MySQL 的握手阶段。一般来说能看到1045 Access denied说明 TCP 层是通的问题在 MySQL 账号授权看到Cant connect或Connection timed out说明还没到 MySQL 认证那一步先查网络。5.3 团队共享连接时的凭据管理多人团队协作时经常有人把 Navicat 连接配置直接通过聊天工具发到群里里面带着跳板机密码和数据库密码。这个习惯很危险因为聊天记录会长期留存等于把内网访问凭据散播得到处都是。更稳妥的做法是导出的连接文件不包含密码。Navicat 导出连接时有一个“导出密码”选项默认可以不勾选。这样其他人拿到连接文件后需要自己输入各自的密码。生产环境里我见过不少团队会进一步要求每人使用独立的跳板机账号而不是共享root或ops账号这样一旦出现异常操作审计日志能定位到具体的人。另一个容易被忽略的点是连接命名规范。建议在连接名上直接体现出环境和路径比如“生产-主库-经跳板机”“测试-只读-经跳板机”。别小看这个细节当团队里几十个连接摆在一起时清晰的名字能避免有人误连生产库执行危险操作。5.4 我长期使用下来的一套固定连接方式我自己这两年的固定做法是本地用命令行走ssh -L建一条常驻通道把内网 MySQL 映射到本地的 13306 端口Navicat 里只保存一个连接主机填 127.0.0.1端口填 13306。跳板机登录全部用公钥私钥带 passphrase 并且用系统钥匙串管理。这样切换项目时只需要改通道命令里的目标地址Navicat 连接不用反复配置。有一个实际操作中得来的小技巧本地转发端口尽量选 10000 以上比如 13306、14406不容易和系统服务冲突也好记忆。通道起来之后先用命令行快速验证一下mysql -h 127.0.0.1 -P 13306 -u app_user -p能连上再开 Navicat能省掉不少“数据库看着连不上其实是转发没生效”的无效排查时间。工具不在新旧链路清晰了Navicat 也好命令行也好都只是连接入口。真正有价值的是对跳板机、SSH 通道和 MySQL 权限这三层关系的理解有了这个底子报什么错都不会慌。