1. DBeaver 连接 MySQL 报错到底卡在哪从 Communications link failure 到 401 的排查思路DBeaver 是一款基于 Java 的通用数据库客户端很多人拿它连 MySQL、PostgreSQL、ClickHouse日常写 SQL、导数据、看表结构都靠它。但只要你用过一段时间大概率会遇到这几类报错Communications link failure、Public Key Retrieval is not allowed、local proxy failed、401 Unauthorized甚至日志里冒出reading choices这种看起来跟数据库八竿子打不着的字样。这些报错表面都叫“连接失败”但根因完全不在一个层面有的是 MySQL 服务端超时参数太短有的是 JDBC URL 少了关键参数有的是驱动版本和 MySQL 8.0 的认证插件对不上还有一类是你在 DBeaver 里配了某个统一 API 通道或代理入口结果 Key、Base URL、Model ID 三件套没对齐请求在网关层就被挡回来了。这篇内容适合三类人第一类是用 DBeaver 连本地或云上 MySQL被Communications link failure和Public Key Retrieval is not allowed反复折磨的开发者第二类是在 DBeaver 里同时管理数据库连接和 AI 辅助通道遇到401、local proxy failed不知道怎么区分是数据库问题还是通道问题的同学第三类是团队里负责统一 Key 和 API 入口需要把连接配置标准化、可复制、可排查的人。我会按“先定位报错属于哪一层再给可复制配置最后逐步验证”的顺序讲每一步都能直接跟着做。先建立一个判断框架后面所有排查都围绕它展开。DBeaver 的一次连接请求大致经过四层DBeaver 客户端 → JDBC 驱动 → 网络/代理层 → MySQL 服务端或统一 API 网关。Communications link failure通常出在网络层或服务端超时Public Key Retrieval is not allowed出在 JDBC 驱动与 MySQL 认证插件协商阶段401 Unauthorized和local proxy failed多半出在代理层或统一通道的鉴权阶段reading choices这类字样往往来自某个 OpenAI 兼容接口的响应解析说明你请求打到的其实不是 MySQL而是一个模型网关。把这条链路记住你就不会再把所有报错都当成“MySQL 挂了”。我试过最典型的一次本地 MySQL 明明用命令行能连DBeaver 却一直Communications link failure查了半天发现是wait_timeout只有默认的 28800 秒而连接池里有个空闲连接放了太久复用的时候服务端已经把它断了。这类问题不是靠重启 DBeaver 能解决的得从服务端参数和连接保活两头下手。下面从原问题场景开始一层层拆。2. 原问题与场景DBeaver 连 MySQL 的典型报错与触发条件2.1 Communications link failure连接被服务端悄悄断开这个报错完整长这样Communications link failure The last packet sent successfully to the server was 0 milliseconds ago。关键词是“last packet sent successfully”意思是上一次通信还是好的这次发出去就没回应了。常见触发条件有三个一是 MySQL 的wait_timeout和interactive_timeout太短空闲连接被回收二是网络中间有防火墙或负载均衡把长连接掐了三是 MySQL 8.0 默认的caching_sha2_password认证在首次连接时握手失败表现也可能类似。先确认服务端超时参数。用命令行或 DBeaver 的 SQL 编辑器执行show global variables like wait_timeout; show global variables like interactive_timeout;默认wait_timeout是 28800 秒也就是 8 小时。如果你希望连接更稳可以临时调大set global wait_timeout 604800; set global interactive_timeout 604800;注意这是全局变量重启 MySQL 后会失效。要持久化得改my.cnf或my.ini[mysqld] wait_timeout 604800 interactive_timeout 604800改完重启服务。但光调服务端还不够DBeaver 这边的连接保活也要配否则连接池里的空闲连接照样会被回收。在 DBeaver 的连接设置里找到“连接设置 → 初始化”或“驱动属性”把autoReconnect设为true并适当设置maxReconnects。更稳的做法是开启心跳查询比如在“连接设置 → 保持活动”里填一条SELECT 1间隔 60 秒。2.2 Public Key Retrieval is not allowedMySQL 8.0 的认证坑这个报错几乎只在 MySQL 8.0 及以上出现原因是 MySQL 8.0 默认认证插件从mysql_native_password换成了caching_sha2_password。当 JDBC 驱动用非 SSL 连接时服务端要求客户端通过 RSA 公钥加密密码但驱动默认不允许从服务端获取公钥于是报Public Key Retrieval is not allowed。解决办法是在 JDBC URL 后面加参数jdbc:mysql://localhost:3306/your_db?allowPublicKeyRetrievaltrueuseSSLfalse在 DBeaver 里不用手写完整 URL打开连接设置 → “主要”标签页 → “驱动属性”找到allowPublicKeyRetrieval把值改成true同时把useSSL按实际情况设为false或true。如果你是在代码里用 JDBC就直接拼在 URL 上。这个参数的含义是“允许客户端从服务端获取公钥用于密码加密”在可信网络里开启是安全的公网环境建议配合 SSL 使用。2.3 401、local proxy failed、reading choices通道层报错的特征这三类报错和前面两个性质不同。401 Unauthorized是鉴权失败local proxy failed是本地代理或转发层没起来reading choices通常出现在解析 OpenAI 兼容响应时——响应体里有个choices字段解析失败就会报这个。它们共同指向一个事实你的请求没有真正打到 MySQL而是打到了一个统一 API 通道或模型网关上。典型场景是你在 DBeaver 里既配了数据库连接又通过某个插件或外部工具配了 AI 辅助通道两套配置混在一起Key 填错、Base URL 填成数据库地址、Model ID 没写都会触发这类报错。排查时第一步就是确认报错来自哪一层如果 DBeaver 的报错弹窗里出现HTTP 401或proxy字样基本可以判定是通道层而不是 MySQL 本身。3. TaoToken 前置把统一 Key 与 API 通道配置成可复制的三件套3.1 为什么要在 DBeaver 场景里引入统一通道很多团队现在的做法是数据库连接一套账号密码AI 辅助编码一套 Key模型调用又一套 Key散落在各个工具里。DBeaver 作为客户端如果同时承担数据库管理和 AI 辅助查询配置就会很乱。把 AI 通道统一到 TaoToken 这类入口好处是 Base URL、Key、Model ID 三件套固定下来任何工具接入都照这个填排查时也有统一参照。TaoToken 的 API 入口是https://taotoken.net/api官网是https://taotoken.net/。注意 API 地址不带 UTM 参数直接用于配置。下面给的三件套是通用格式你按自己实际拿到的值替换即可。3.2 三件套Base URL、Key、Model ID无论你用的是 DBeaver 的 AI 插件、Cline、还是 Claude Code接入统一通道都绕不开这三个值配置项说明示例格式Base URL统一 API 入口地址https://taotoken.net/apiAPI Key鉴权密钥形如sk-开头sk-xxxxxxxxModel ID模型标识按需选择claude-sonnet-4-5等在 DBeaver 里如果你用的是支持自定义 API 的 AI 助手插件通常会在插件设置里让你填这三项。填错任何一项都会出现401或reading choices。特别注意 Base URL 不要带多余路径也不要写成数据库地址。3.3 在 DBeaver 中配置统一通道的入口DBeaver 本身是数据库客户端AI 能力一般通过插件或外部工具实现。如果你的工作流是“DBeaver 管数据库 外部工具调模型”那统一通道的配置放在外部工具里。如果你用的是带 AI 功能的 DBeaver 发行版或插件配置入口通常在“首选项 → AI”或插件自己的设置面板。以常见的 OpenAI 兼容配置为例你需要填的 JSON 结构大致如下{ baseUrl: https://taotoken.net/api, apiKey: sk-你的Key, model: claude-sonnet-4-5 }如果你用的是 Cline 或类似工具配置会写在settings.json或对应的 MCP 配置里。Cline 的 MCP 配置示例{ mcpServers: { taotoken: { command: npx, args: [-y, your-mcp-server], env: { BASE_URL: https://taotoken.net/api, API_KEY: sk-你的Key, MODEL_ID: claude-sonnet-4-5 } } } }Codex 的auth.json配置示例{ base_url: https://taotoken.net/api, api_key: sk-你的Key, model: claude-sonnet-4-5 }这三件套一旦固定后面所有报错排查都可以先对照它Base URL 对不对、Key 有没有过期、Model ID 是不是写错。很多401和reading choices就是这三项里某一项填错导致的。4. 可复制配置DBeaver 连接 MySQL 的完整参数与验证请求4.1 DBeaver 连接 MySQL 的驱动属性配置打开 DBeaver新建 MySQL 连接填好主机、端口、数据库、用户名、密码后先别急着点“测试连接”。切到“驱动属性”标签页逐项确认以下参数属性名建议值作用allowPublicKeyRetrievaltrue解决 MySQL 8.0 公钥检索报错useSSLfalse内网/true公网控制 SSL 连接autoReconnecttrue断线自动重连maxReconnects3最大重连次数connectTimeout10000连接超时毫秒socketTimeout30000socket 超时毫秒serverTimezoneAsia/Shanghai时区避免时间错乱如果你习惯直接写 JDBC URL完整格式如下jdbc:mysql://127.0.0.1:3306/your_db?allowPublicKeyRetrievaltrueuseSSLfalseautoReconnecttruemaxReconnects3connectTimeout10000socketTimeout30000serverTimezoneAsia/Shanghai在 DBeaver 的“主要”标签页里把 URL 填到“JDBC URL”输入框或者用“编辑驱动设置”里的 URL 模板。注意your_db换成你的实际库名127.0.0.1换成实际主机。4.2 连接保活与超时参数前面调了服务端的wait_timeout客户端这边也要配保活。在 DBeaver 连接设置的“初始化”里可以加一条初始化 SQLSELECT 1或者在“连接设置 → 保持活动”里设置心跳间隔为 60 秒。这样即使连接空闲也会定期发一条轻量查询避免被服务端回收。如果你用的是连接池比如 HikariCP参数要写在池配置里spring: datasource: hikari: connection-timeout: 10000 idle-timeout: 600000 max-lifetime: 1800000 keepalive-time: 60000 connection-test-query: SELECT 1max-lifetime要小于 MySQL 的wait_timeout否则连接还没被池回收服务端先断了就会报Communications link failure。4.3 统一通道的验证请求配好三件套后先用一条最简单的请求验证通道是否通。如果你有 curl可以这样测curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: ping}] }如果返回401说明 Key 不对或没带上如果返回reading choices相关错误说明响应解析有问题通常是 Model ID 写错或 Base URL 路径不对如果返回正常内容说明通道通了。这一步能把通道层问题和数据库层问题彻底分开。5. 验证请求与成功结果逐步确认连通性5.1 先验证 MySQL 服务端可达在 DBeaver 里点“测试连接”之前先用命令行确认服务端活着mysql -h 127.0.0.1 -P 3306 -u root -p -e SELECT 1;能返回结果说明服务端和账号密码没问题。如果这里就失败DBeaver 里再怎么配也没用先解决服务端或网络问题。5.2 再验证 DBeaver 驱动层回到 DBeaver点“测试连接”。如果报Public Key Retrieval is not allowed按 4.1 加allowPublicKeyRetrievaltrue如果报Communications link failure检查wait_timeout和保活配置如果报Unknown database检查库名拼写。成功的结果是弹窗显示“已连接”并且能在左侧看到数据库和表结构。这时候执行一条查询SELECT NOW(), VERSION();能返回当前时间和 MySQL 版本说明驱动层和服务端都通了。5.3 最后验证统一通道如果你在 DBeaver 里集成了 AI 辅助或者用外部工具调模型按 4.3 的 curl 验证。成功结果是返回一段正常的 JSON里面有choices字段和内容。如果返回401检查 Key如果返回local proxy failed检查本地代理是否启动、端口是否被占用如果返回reading choices解析错误检查 Model ID 和 Base URL。三层都验证通过整个链路才算真正打通。任何一层失败都按对应章节排查不要混着改。6. 本篇常见错排查401、local proxy failed、reading choices 对照表6.1 401 Unauthorized报错原文通常是HTTP 401 Unauthorized或invalid api key。根因是鉴权失败。排查顺序第一确认 Key 有没有复制完整前后有没有空格第二确认请求头里带的是Authorization: Bearer sk-xxx第三确认 Key 没有过期或被禁用第四确认 Base URL 和 Key 是同一套环境的不要拿 A 环境的 Key 配 B 环境的地址。在 DBeaver 场景里如果你把数据库密码和 API Key 搞混了也会出现类似报错。数据库连接用的是 MySQL 账号密码AI 通道用的是 API Key两者不要填错位置。6.2 local proxy failed报错原文可能是local proxy failed或proxy connection refused。根因是本地代理或转发层没起来。排查顺序第一确认代理进程是否在运行第二确认代理监听的端口和配置里写的一致第三确认没有其他程序占用该端口第四确认防火墙没有拦截本地回环地址。如果你没有主动配代理却在 DBeaver 或外部工具里看到这个报错检查是不是某个插件默认开了代理转发。关掉不必要的代理配置直连统一通道即可。6.3 reading choices 解析错误报错原文可能包含reading choices或cannot read property choices。根因是响应体不是预期的 OpenAI 兼容格式。排查顺序第一确认 Base URL 是https://taotoken.net/api不要多加/v1或漏掉第二确认 Model ID 是通道支持的模型第三确认请求体是合法的 JSONmessages字段格式正确第四用 curl 单独测一次排除工具层干扰。6.4 三件套对照速查报错优先检查常见根因401API KeyKey 错误、过期、未带 Bearerlocal proxy failed代理配置代理未启动、端口冲突reading choicesBase URL Model ID地址路径错、模型名错Communications link failurewait_timeout 保活连接被服务端回收Public Key RetrievalallowPublicKeyRetrievalMySQL 8.0 认证插件排查时按“先分层、再对照、后验证”的顺序走基本能覆盖 DBeaver 连 MySQL 和统一通道的绝大多数报错。配置改完记得重启 DBeaver 或重连让新参数生效。如果你在接入统一通道时需要拿 Key 或看文档可以从 API Keys 页面获取接入细节参考接入文档想先验证模型是否通用模型对话页面测一条如果是长期编码或 Agent 场景直接看 Coding Plan 更合适。