WorkBuddy连接配置全攻略：数据库、SSH、API与本地模型一次打通

连接，是 WorkBuddy 从单机玩具变成生产工具的分水岭。前两篇把安装和工作台配置讲清楚了，这一篇聚焦连接篇：让 WorkBuddy 能读数据库、连服务器、调接口、跑远程命令。毕竟 WorkBuddy 再聪明，如果拿不到数据和外部能力，它就只能在本地自娱自乐。这篇尤其适合已经搭好 WorkBuddy 工作台、但一直被“连不上”“容易断”“连接工具配不明白”困扰的读者。我会按真实业务中接系统的顺序来写：先讲连接设计的底层逻辑，再逐个拆解数据库、SSH、HTTP、本地模型、Skill 与移动设备的连接方法，最后附一份常见故障排查速查表。内容偏实操，可以直接照着配。

1. 连接前先理清：WorkBuddy 连接层设计与网络检查清单

1.1 为什么 WorkBuddy 一定要有一层“连接管理”

WorkBuddy 这类数字员工工作台，本质是一个调度中枢。它负责理解任务、拆解步骤、调用资源。但资源不会自己跑到它面前来：MySQL 在独立服务器上，Redis 在另一台机器，生产环境的 API 需要 token，远程主机只能通过 SSH 登录。没有统一连接层，每个技能都各自写死地址和密码，问题会非常多。最直接的安全问题是凭据散落各处；其次是连接无法复用，同一个数据库连接会被多个任务反复创建销毁；第三是故障定位难，到底是网络不通、认证失败还是服务端超时，没人知道。

所以成熟的连接管理应该具备三个能力：

• 连接配置与业务逻辑分离：WorkBuddy 的 Skill 里只写“用哪个连接名”，不写 IP 和密码。
• 连接状态可视化：每个连接的健康状态、最近调用时间、错误码都要能看到。
• 凭据加密存储：密码、Token 不能明文躺在配置文件里。

这一点，类比到日常生活就是接线板与每家各拉电线的区别。集中管理后，新增一个数据库只需要在连接中心配置一次，所有 Skill 都能共享；某个连接挂了，也只需要在连接中心重启，不需要逐个改任务。

1.2 WorkBuddy 支持哪几类连接以及适用场景

根据实际使用场景，可以把连接分成四类：

• 数据连接：包括 MySQL、PostgreSQL、达梦、Oracle、SQL Server 等数据库，以及 Redis、Kafka、MongoDB 这类中间件。
• 远程主机连接：SSH、SFTP、远程桌面，用于执行命令、传输文件、管理服务器。
• HTTP/API 连接：RESTful API、WebSocket，用于调用第三方系统、问卷接口、企业微信机器人等。
• 设备与端侧连接：USB 调试、蓝牙、局域网服务，用于手机、传感器、打印机等硬件设备。

一般情况下，一个生产级 WorkBuddy 实例至少会配置 1-2 个数据库连接、1 个 SSH 远程主机和若干 HTTP API 连接。初学者最容易犯的错误是贪多，一上来就想把所有系统都接入，结果每个连接都没调通。我的建议是先打通一条端到端链路，比如“数据库读到数据 -> WorkBuddy 处理 -> 调用 Webhook 通知”，再把连接类型扩展。

1.3 连接配置前的网络检查清单

不少人直接在 WorkBuddy 界面里填 IP 和密码，报错了才开始怀疑配置。其实连接问题一大半出在网络层。配置前先花五分钟做三层检查：

第一，目标地址可达吗？用 ping 测试基础连通性。ping 不通说明 IP、路由或防火墙有问题。第二，目标端口通吗？很多服务器禁 ping，但端口可能正常，建议用 telnet 或 nc。例如测试 MySQL：

telnet 192.168.1.100 3306 # 或者 nc -vz 192.168.1.100 3306

看到 Connected to 说明端口通。第三，本机到目标之间有没有安全组或防火墙规则。云主机通常还需要在控制台放行对应端口，本地服务器则检查 iptables、ufw 或 Windows 防火墙。

注意：数据库和 SSH 端口不要直接暴露到公网。WorkBuddy 与目标服务尽量处于同一内网或专线网络，这是最稳的部署姿势。

这段网络检查我每次都会做，因为能省下后面 80% 的排错时间。

2. 数据连接实操：数据库、Redis 与 Docker 容器到底怎么连

2.1 用 WorkBuddy 连接 MySQL/达梦数据库的完整步骤

数据库是连接篇的重头戏。以 WorkBuddy 某个“数据查询” Skill 为例，它需要先定义一个数据源连接。

连接参数通常包括：

• 连接名称：mydb_prod
• 数据库类型：MySQL 或 达梦
• 主机地址：192.168.1.100
• 端口：MySQL 用 3306，达梦默认 5236
• 数据库名/模式：order_db
• 用户名和密码：业务专用账号，别用 root 或 SYSDBA

如果使用 JDBC 类驱动，MySQL 的 URL 一般是：

jdbc:mysql://192.168.1.100:3306/order_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

达梦数据库稍微特殊一点，它的驱动类名和 URL 格式容易记错：

jdbc:dm://192.168.1.100:5236/order_db?compatibleMode=mysql

驱动类名是 dm.jdbc.driver.DmDriver，依赖达梦的 DmJdbcDriver jar 包。很多第一次接触达梦的人会卡在“找不到驱动”这一步，其实把对应版本的 jar 放到 WorkBuddy 的 lib 或插件目录、并在连接配置里指定驱动即可。如果用 Navicat 这类图形化客户端连达梦，参数完全一致，只是在选择驱动时选 DM 驱动即可。先用客户端连通，再回 WorkBuddy 配置，是最稳妥的验证方式。

实操中有三个高频问题：第一是时区问题，MySQL 8 以上 serverTimezone 必须显式指定，否则报 CST 时区识别错误；第二是字符集，建议统一使用 utf8mb4，特别是表里存了表情符号；第三是权限，业务账号只需要最小权限，比如只读账号给 SELECT 就行，别用管理员账号跑日常查询。

2.2 Redis 连接操作与图形化工具选择

Redis 在 WorkBuddy 里的角色很明确：做缓存、做临时队列、做分布式锁。连接配置一般只需要四个参数：host、port、db index、密码。默认端口 6379，db 默认 0，密码可以为空，但生产环境必须设置 requirepass。

命令行验证用 redis-cli：

redis-cli -h 192.168.1.100 -p 6379 -a 'yourpassword' ping

返回 PONG 说明连接正常。WorkBuddy 里配置 Redis 连接后，可以把它封装成一个 Skill，比如“读取缓存键”，输入键名返回值。

图形化连接工具方面，我建议先用轻量的，别一上来就装全家桶。常见的有：

• Redis Desktop Manager（RDM）：老牌，界面清晰，适合看 key 和 TTL。
• Another Redis Desktop Manager：开源免费，跨平台，连接管理比 RDM 更好用。
• redis-cli：命令行，适合脚本和快速验证。

实操心得：连接 Redis 时最容易忽略的是 db index。本地 Redis 默认有 16 个 db，如果 WorkBuddy 连的库和业务实际使用的库不一致，查出来的数据永远是空的。

还有一点，Redis 6 以后默认开启了 ACL，老版本客户端可能因为用户名默认是 default 而连不上。连接参数里要显式加上用户名 default，或者在服务器端给 WorkBuddy 单独建一个用户并授权。

2.3 Docker 内部服务怎么连接：以 iServer 连达梦为例

连接问题在容器环境里会加倍。特别是 Docker 里跑的 iServer 想连另一个容器里的达梦数据库，很多人直接写 localhost，结果死活连不上。原因很简单：localhost 在容器里指容器本身，不是宿主机，更不是另一个容器。

解决思路有三种：

• 同 docker-compose 网络：直接使用服务名作为 host。比如达梦服务名是 dm8，iServer 连接地址就写 dm8:5236。
• 跨容器默认 bridge 网络：让两个容器加入同一个自定义网络。docker network create app-net，然后在运行容器时用 --network app-net 指定。
• 宿主机访问容器：使用宿主机 IP 加映射端口，比如 192.168.1.100:5236。

排查容器连接时，第一步不是改 WorkBuddy，而是先确认容器网络和端口映射：

docker inspect <container_id> | grep -A 20 "NetworkSettings" docker logs <container_id> --tail 200

如果确认服务正常，但还是连不上，就进入目标容器里用 nc 测试：

docker exec -it <container_id> bash nc -vz dm8 5236

容器环境还有一个隐蔽坑：部分镜像默认没有安装 telnet、nc 等网络工具，测试前可能要先 apt install 一下，或者用 docker exec 进入应用容器后，通过应用日志判断连接状态。

2.4 连接池、连接复用与超时参数设置

加了连接之后，还有一个绕不开的性能问题：连接复用。WorkBuddy 如果每次执行 Skill 都新建数据库连接，性能会很差。以 MySQL 为例，每次建连需要 TCP 握手、鉴权、字符集协商，耗时可能几十到几百毫秒。对交互式任务还能忍，对批处理任务就是灾难。

解决方法是使用连接池。WorkBuddy 这类平台底层通常会集成 HikariCP 或类似连接池组件，你需要关心的参数有几个：

• maximumPoolSize：最大连接数，建议根据数据库 max_connections 设置为 5-20。
• minimumIdle：最小空闲连接数，生产环境设为 2-5。
• connectionTimeout：获取连接超时，默认 30 秒，内部系统建议 3-5 秒，避免请求长时间挂起。
• maxLifetime：连接最大生命周期，建议小于数据库 wait_timeout。
• idleTimeout：空闲回收时间。

HTTP 连接同样讲究复用。WorkBuddy 调用外部 API 时，尽量开启 keep-alive，在 HTTP 头里设置 Connection: keep-alive，避免每次请求都重建 TCP 连接。如果调用量大，可以在客户端配置连接池，比如 Java 的 HttpClient 连接池、Python requests 的 Session 复用。

import requests session = requests.Session() session.headers.update({"Connection": "keep-alive"}) resp = session.get("http://api.internal/health") print(resp.status_code)

这个例子虽然简单，但背后就是连接复用。WorkBuddy 的 HTTP 节点如果支持自定义请求头，务必保留 keep-alive。

3. 远程连接与文件传输：SSH 免密、VS Code 和 XFTP 实战

3.1 快速搞定 SSH 免密登录，WorkBuddy 远程执行命令不卡壳

SSH 连接是最常用的远程通道。WorkBuddy 要执行远程巡检命令、拉日志、部署脚本，都离不开 SSH。最省事的配置是密钥认证，省去每次输密码，而且比密码更安全。

生成密钥对：

ssh-keygen -t ed25519 -C "workbuddy-automation" -f ~/.ssh/workbuddy_ed25519

一路回车会在 ~/.ssh 下生成私钥 workbuddy_ed25519 和公钥 workbuddy_ed25519.pub。然后把公钥放到目标服务器：

ssh-copy-id -i ~/.ssh/workbuddy_ed25519.pub user@192.168.1.200

如果服务器不支持 ssh-copy-id，手工追加也行：

cat ~/.ssh/workbuddy_ed25519.pub | ssh user@192.168.1.200 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

然后在 WorkBuddy 的 SSH 连接配置里，认证方式选密钥，指定私钥路径或粘贴私钥内容。

注意：私钥文件权限必须设置为 600，否则 SSH 客户端会直接拒绝使用。检查方法：ls -l ~/.ssh/workbuddy_ed25519，如果不是 -rw-------，执行 chmod 600。

密钥配置好之后，还建议在 config 里加一段连接别名，提升日常操作效率：

Host prod-server HostName 192.168.1.200 User ubuntu IdentityFile ~/.ssh/workbuddy_ed25519 ServerAliveInterval 60

ServerAliveInterval 60 表示每 60 秒发一次心跳，防止长时间空闲后连接中断，这个参数对 WorkBuddy 的长任务尤其重要。

3.2 VS Code Remote-SSH 与 XFTP 的配合使用

调试阶段不可能只用 WorkBuddy，总要亲自登录服务器看看。推荐组合是 VS Code Remote-SSH 连服务器写脚本，XFTP 传文件，WorkBuddy 负责定时调度。

VS Code 装好 Remote-SSH 插件后，按 F1 输入 Remote-SSH: Connect to Host，选择或输入 SSH 连接目标，它会在本地打开一个远程窗口，编辑、终端、调试都直接跑在远程。第一次连接会自动在服务器上安装 vscode-server，如果网络差可能要等一会。这种模式下，WorkBuddy 的 SSH 连接配置和 VS Code 的 SSH 配置可以共用同一个 ~/.ssh/config，避免维护两套地址。

XFTP 用于 SFTP 文件传输。新建会话时协议选 SFTP，端口 22，填好用户名密码或密钥。日常操作中，我喜欢先把服务器上的日志下载到本地分析，再通过 XFTP 把 WorkBuddy 的脚本上传到服务器。这里有个小技巧：SFTP 传输大文件时，如果速度很慢，可以检查双方网卡速率，或者切换为主动模式/被动模式试试。

Windows 自带终端也可以直接用 SSH 命令连接远程服务器：

ssh ubuntu@192.168.1.200

不过 Windows 的 OpenSSH 客户端密钥目录默认为 C:\Users\用户名.ssh\，注意把密钥放对位置，或者用 -i 显式指定。

3.3 Ubuntu SSH 连不上的系统排查思路

用户最容易遇到的是 Ubuntu SSH 无法连接。现象通常有三种：连接超时、拒绝连接、认证失败。对应排查思路完全不同。

连接超时：大概率是网络层问题。检查目标 IP 是否可达、22 端口是否开放，云主机还要看安全组规则。本地防火墙可以用 ufw status 查看，如果启用了 ufw，执行：

sudo ufw allow 22/tcp

拒绝连接：一般说明 sshd 没启动或没监听。先确认服务状态：

systemctl status sshd sudo systemctl enable --now sshd

Ubuntu 上服务名可能是 ssh 而不是 sshd，注意区分。查看监听端口：

ss -tlnp | grep :22

如果啥都没有，说明 sshd 没起来或者监听在其他端口。

认证失败：重点看用户名、密码、密钥是否匹配。配置文件 /etc/ssh/sshd_config 里几个关键项要检查：

PermitRootLogin prohibit-password PasswordAuthentication yes PubkeyAuthentication yes

改完配置记得重启：sudo systemctl restart sshd。

排错技巧：用 ssh -vvv user@host 查看详细握手日志，它会明确告诉你卡在哪一步，比如 "Connection timed out" 还是 "Permission denied (publickey,password)"。这一步能让排查效率翻倍。

3.4 远程桌面与局域网共享的几个典型坑

除了 SSH，日常运维还经常用远程桌面连接 Windows 主机。Win 上执行 mstsc，输入 IP 即可；如果连不上，先确认远程桌面服务是否开启、防火墙 3389 端口是否放行。Windows 防火墙高级设置里入站规则要允许“远程桌面”。

局域网共享这块，容易出问题的两个错误码：连接共享打印机时报 0x0000057，以及提示内存不足。0x0000057 通常和凭据有关，删除旧的共享凭据再重连：

cmdkey /list cmdkey /delete:目标地址

然后重新访问共享打印机。提示内存不足时，先看系统的 Print Spooler 服务是否正常，再把 C:\Windows\System32\spool\PRINTERS 下的残留文件清理掉，重启服务。这类问题虽然看起来跟 WorkBuddy 无关，但 WorkBuddy 经常要自动触发打印或扫描任务，把局域网打印通道修好，自动化流程才不会断在中途。

4. HTTP 接口与本地模型连接：从鉴权到 ERR_SSL_VERSION 排查

4.1 HTTP API 连接配置与会话保持

HTTP API 是 WorkBuddy 与企业系统集成最通用的姿势。第三方系统大多提供 REST 接口，配置一个 HTTP 连接即可调用。

连接配置通常包含：

• 基础地址：https://api.example.com
• 鉴权方式：无、Bearer Token、Basic Auth、自定义 Header
• 默认超时：连接超时 3 秒、读取超时 30 秒
• 是否启用 Keep-Alive

如果接口需要登录后才有数据，WorkBuddy 的 HTTP 节点最好支持会话保持机制：先调用登录接口拿到 Cookie 或 Token，再带着 Cookie/Token 请求业务接口。这里涉及“开启会话连接”的概念，其实就是把 SessionID 保存并复用。

实操里我会这样设计：在 WorkBuddy 里建一个“登录获取 Token”的 Skill，执行后把 Token 写入临时存储；下游接口请求从存储里读取 Token 加到 Authorization 头。这样 Token 过期时只需要重新执行登录 Skill，其他流程不用改。

4.2 本地大模型怎么连进 WorkBuddy

很多人在 WorkBuddy 里想接本地部署的大模型，热词里提到的 Hermes、Ollama 这类都属于本地模型服务。以 Ollama 为例，它默认启动在 11434 端口，提供 OpenAI 兼容接口，WorkBuddy 只需要按 OpenAI API 格式配置。

一个典型配置：

• Base URL：http://localhost:11434/v1
• API Key：随便填，Ollama 默认不校验
• 模型名：hermes3 或 qwen2.5:7b

如果 WorkBuddy 和 Ollama 在同一台机器，用 localhost 就行；如果是局域网内的另一台机器，则用对方 IP，比如 http://192.168.1.50:11434/v1。

连接本地模型最常遇到的坑有三个：第一，Ollama 默认只监听 127.0.0.1，跨机器访问需要在启动时指定 OLLAMA_HOST=0.0.0.0，或者修改环境变量后重启服务。第二，模型上下文长度和 WorkBuddy 超时设置不匹配，长文本任务经常报 timeout，需要把 HTTP 读取超时调大。第三，本地 GPU 显存不足导致推理慢，这是硬件问题，不是连接问题，注意区分。

实操心得：本机连接一切正常，换到别的机器连不上，九成是服务监听地址问题。用 ss -tlnp | grep 11434 确认监听地址，如果显示 127.0.0.1:11434，外部机器必然连不上。

4.3 ERR_SSL_VERSION_OR_CIPHER 到底怎么回事

在浏览器里访问局域网设备，比如管理后台地址 192.168.2.1，提示“此站点的连接不安全，使用不受支持的协议 ERR_SSL_VERSION_OR_CIPHER”，这个报错经常让新手一头雾水。

本质是浏览器和服务端协商 TLS 版本或加密套件失败。老设备只支持 TLS 1.0/1.1 或旧加密算法，而新版浏览器默认关闭了这些弱协议。出现这种情况，最安全的处理方式是升级设备固件，让服务端支持 TLS 1.2 以上。如果是自研服务，调整 Nginx 配置：

ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5;

开发环境下想临时绕过，可以在浏览器高级设置里勾选“允许使用旧版 TLS”，但生产环境千万别这么干，属于用安全换一时的便利。

如果是 WorkBuddy 网页版访问本地服务时报这个错，还需要确认访问协议是否一致：内网服务如果只支持 HTTP，就不要在 WorkBuddy 里把地址写成 https；反之，服务端强制 HTTPS，用 http 访问也会出现类似“不受支持的协议”提示。

4.4 localhost 访问与专用 WiFi 的几个奇怪现象

还有一个常见场景：电脑连了公司专用 WiFi 后，localhost 反而访问不了本机服务。听起来很诡异，但原因通常有三个。第一是系统网络设置中残留了异常网关配置，导致 localhost 流量没有按预期走本机回环地址，处理方法是在网络设置里把本机回环流量恢复默认，确保它不经过任何中间节点。第二是防火墙，某些安全软件会把本机回环地址也拦截，把对应进程加入白名单。第三是 hosts 文件被修改，localhost 没有解析到 127.0.0.1。

另一类问题是连上 WiFi 后浏览器提示“需要操作，没有 Internet，打开浏览器并连接”。这其实是 WiFi 门户认证页，常见于酒店、商场、公司访客网络。打开浏览器访问任意地址会自动跳转到认证页面，登录后才能通网。WorkBuddy 如果部署在这种网络环境里，要特别小心：认证过期后对外连接会全部中断，所以生产环境不要用这类网络。

5. Skill 与终端联动：WorkBuddy 自定义指令和手机/蓝牙设备连接

5.1 把连接能力封装成 WorkBuddy Skill

连接配好只是第一步，真正发挥作用要靠 Skill。WorkBuddy 的 Skill 机制允许你把“连接 + 操作 + 返回格式”打包成一个可复用的能力。

我推荐先做几个基础 Skill：

• 数据库查询器：输入 SQL，返回表格数据。
• 远程主机命令执行器：输入命令，返回标准输出。
• API 健康检查器：输入 URL，返回状态码和响应时间。

下面是一个数据库查询 Skill 的伪代码结构：

def execute_sql(query: str, connection: str = "mydb_prod"): conn = get_connection(connection) try: with conn.cursor() as cursor: cursor.execute(query) rows = cursor.fetchall() return {"status": "ok", "rows": rows, "count": len(rows)} except Exception as e: return {"status": "error", "message": str(e)}

这里 connection 参数用连接名，而不是 IP 和密码，好处是如果数据库迁移，只需要在连接管理器里改一个地方。

自定义指令推荐方面，给 Skill 起名要直接，触发词要明确。比如“查用户数”“跑巡检”“发通知”。在 WorkBuddy 里配置自定义指令时，我会在描述里写清楚：指令触发条件、需要哪些参数、输出格式。越具体越好。一个模糊的指令描述会导致 AI 频繁误解。

5.2 Android 手机连接 WorkBuddy 做端侧联动

移动端联动是 WorkBuddy 场景里很加分的一环。最常见的是 Android 手机通过 USB 调试连接，让 WorkBuddy 识别设备并执行截图、点击、读取通知等操作。

用 Android Studio 连接小米手机前，需要先开启开发者选项：设置 -> 我的设备 -> 全部参数 -> 连续点击 MIUI 版本 7 次，然后在更多设置里打开“开发者选项”和“USB 调试”。

连接后命令行验证：

adb devices

如果看到 devic 状态，说明连接成功。如果显示 unauthorized，需要在手机弹窗上允许调试。如果显示 offline，拔掉 USB 重新插，并重启 adb：

adb kill-server adb start-server

小米手机还有个额外开关：在开发者选项里打开“USB 安装”和“USB 调试（安全设置）”，否则 adb 命令可能没有权限。

WorkBuddy 把 adb 封装成连接后，可以自动完成“获取设备列表”“截屏并保存到指定目录”“模拟点击”等操作，适合做 App 自动巡检、UI 测试。

5.3 蓝牙设备连接与重置：以 GT4Pro 为例

蓝牙设备的连接原理和前面说的 TCP 完全不同，但 WorkBuddy 同样可以通过系统蓝牙接口去联动。以常见的 GT4Pro 手环/穿戴设备为例，配对失败时最有效的一招是重置蓝牙连接缓存。

标准步骤大概是：手机设置里找到该设备，选择取消配对；重启手机蓝牙；重新搜索并配对；配对时保持设备靠近手机，并确保设备处于可被发现模式。如果依旧失败，恢复设备出厂设置再试。

连接成功后，可以通过厂商 SDK 或第三方库读取设备数据。热词里提到的 python+miio 连接小米网关也是类似道理，通过局域网协议与设备通信。这个时候 WorkBuddy 的角色是调度器：定时去读取数据，再对接入数据库或推送通知。

注意：硬件设备连接不像软件服务那么可靠，建议在 WorkBuddy 的 Skill 里加自动重连与失败告警逻辑，比如连续拉取不到数据就触发通知。

6. 连接故障速查：中断、慢启动、打印机与局域网经典问题

6.1 连接中断与 WorkBuddy 启动慢的原因分析

连接中断是生产环境最影响体验的问题。成因通常有三类。网络层：防火墙空闲断连、WiFi 休眠、运营商 NAT 超时。遇到这种，启用心跳保活。SSH 配置 ServerAliveInterval，TCP 层可以设置 SO_KEEPALIVE，HTTP 层则依赖 keep-alive。

服务层：数据库 wait_timeout 过短、连接池回收不及时。解决办法是让连接池的 maxLifetime 小于服务端 wait_timeout，比如服务端 wait_timeout=28800 秒，连接池 maxLifetime 设 1800 秒，提前在服务端回收前断开并重建。

WorkBuddy 启动非常慢，别急着怪软件。先看启动日志里有没有大量连接超时。如果 WorkBuddy 启动时要连接多个数据源或外网服务，而某些目标不可达，启动过程会被阻塞到超时。解决方案是开启懒加载，把非关键的连接放到首次使用时创建；或者把不可达的连接暂时禁用。

6.2 局域网共享与打印机连接错误速查

前面已经提到共享打印机 0x0000057 和内存不足的常见解法，这里整理成速查表。

6.3 连接排查方法论与常用命令

排查连接问题，最忌讳瞎试。我自己的流程是：先画出链路图，从 WorkBuddy 到目标服务之间有哪些节点，然后从最近的一跳开始逐层验证。

常用命令:

# 连通性 ping <host> # 端口 telnet <host> <port> nc -vz <host> <port> # 路由 traceroute <host> # 查看本机监听 ss -tlnp netstat -antp # HTTP 调试 curl -v http://<host>:<port>/health # 抓包 tcpdump -i eth0 port 3306 -nn

每一条命令都有自己的用途。ping 看基础连通，telnet/nc 看端口，curl 看应用层协议，tcpdump 看网络包细节。遇到“WorkBuddy 里连不上，但命令行能连上”，优先怀疑 WorkBuddy 所在进程的网络命名空间或网络转发配置，这类问题很隐蔽。

6.4 一套通用的连接自检流程

最后分享一个可以直接抄的自检流程：

1. 确认目标服务确实在监听：ss -tlnp 或 netstat。
2. 确认端口可达：telnet 或 nc。
3. 确认鉴权信息正确：用客户端工具连一次。
4. 确认 WorkBuddy 的配置项与客户端一致：host、port、库名、用户名、密码。
5. 看 WorkBuddy 的错误日志：把报错粘贴到搜索，优先看时间戳和 Caused by。
6. 如果是间歇性失败，检查超时参数和连接池配置。

这套流程解决了我遇到的大部分连接问题。每一条背后都有实际踩坑的教训，比如第 4 条，很多人本地用 root 连没问题，WorkBuddy 里用了只读账号却漏了库名，导致一直报 table not found，看起来像权限问题，实际是配置问题。

说实话，连接这块没有什么玄学。我在实际项目中踩过最多的坑，不是技术多难，而是顺序不对：上来就改配置，不先做网络检查；连不上就怀疑 WorkBuddy，不去看目标服务的日志。把链路拆开，一段一段验证，问题基本十分钟内能定位。如果你想在 WorkBuddy 里把连接管理做好，我有一个建议：把常用的连接测试命令沉淀成一个 Skill，比如“端口检测”，输入主机和端口，自动 telnet 并返回结果。这样以后再遇到“连不上”，不用手工敲命令，直接让 WorkBuddy 自己先给自己做个体检。这算是我最近最满意的一个小技巧，省了不少事。