根本原因是迁移向导启动时反向校验目标库连通性，而非源库连接问题；需检查目标MySQL的bind-address是否为0.0.0.0、防火墙/安全组是否放行3306端口、SSH隧道配置是否误启用，并可通过connections.xml调大connection_timeout参数临时缓解。
MySQL Workbench 迁移向导报 Connection timeout 的根本原因
这不是网络不通的简单问题，而是迁移向导在启动阶段会尝试用源库的连接参数（尤其是 host、port、user）反向连接目标库或自身所在机器，用于校验 SSH 隧道、SSL 配置或元数据服务端口。如果目标 MySQL 实例监听的是 127.0.0.1 而非 0.0.0.0，或者防火墙/云安全组没放行目标端口（默认 3306），就会卡在“Testing connection…”并最终超时。
关键点：这个超时和你能否用 Workbench 正常连上源库完全无关——它测的是迁移流程内部的连通性链路。
检查并修正目标 MySQL 的 bind-address 和防火墙
- 确认目标 MySQL 配置中
bind-address 不是 127.0.0.1（否则只接受本地回环连接）；应设为 0.0.0.0 或具体可访问的内网 IP
- 在目标服务器上运行
sudo ss -tlnp | grep :3306，确认监听地址不是 127.0.0.1:3306
- 云环境（如 AWS/Aliyun）必须检查安全组规则，确保入方向允许来源 IP（即你运行 Workbench 的机器 IP）访问
3306
- 本地测试时若目标 MySQL 是 Docker 容器，需加
-p 3306:3306 并确认容器内 bind-address 配置正确
绕过 SSH 隧道自动检测（常见于远程目标库场景）
bind-address 不是 127.0.0.1（否则只接受本地回环连接）；应设为 0.0.0.0 或具体可访问的内网 IP sudo ss -tlnp | grep :3306，确认监听地址不是 127.0.0.1:3306 3306 -p 3306:3306 并确认容器内 bind-address 配置正确 迁移向导默认勾选 Use SSH tunnel 时，即使你没填 SSH 参数，它仍会尝试建立隧道并等待响应，极易触发超时。
- 在迁移向导第一页（Source Selection）点击
Manage Connections… - 编辑目标连接，在
SSH标签页中：- 取消勾选
Use SSH tunnel - 确保
Connection Method是Standard TCP/IP - 如果目标库确需 SSH 访问，手动填入完整 SSH 主机、端口、用户、密钥路径，并在
MySQL Hostname填127.0.0.1（因为 SSH 隧道会在本地映射）
- 取消勾选
调整 Workbench 内部超时阈值（临时应急）
Workbench 没有图形界面选项调这个值，但可通过修改配置文件生效：
- 关闭 Workbench
- 找到配置文件：
~/.mysql/workbench/connections.xml（macOS/Linux）或%APPDATA%\MySQL\Workbench\connections.xml（Windows） - 在对应连接节点下添加或修改：
60 30改成60或120） - 重启 Workbench 后重试
注意：该参数仅影响部分连接阶段，不能解决底层不可达问题，只是给慢链路多一点时间。
迁移向导的连接校验逻辑藏得深，很多用户反复确认“我能连上”，却没意识到它其实在用另一套路径探测——最稳妥的做法永远是先用 mysql -h 目标IP -P 3306 -u 用户 -p 在 Workbench 所在机器上手动连一次目标库。
