6195 这个端口，我用三种方式连不上过

机器人在群里装死，我养成一个习惯：第一件事打开 NapCat 的日志。

6195 是 AstrBot 和 NapCat 之间那条 WebSocket 通道的端口，AstrBot 监听，NapCat 连过来。这条线一断，机器人就哑巴。我一共在它上面栽过三次，每次报错长得都像"网络故障"，但原因差得远。

被拒绝，因为根本没人听

Error: connect ECONNREFUSED 127.0.0.1:6195
    at TCPConnectWrap.afterConnect

被拒绝，说明对面没有任何程序在监听。

我先去查防火墙，又去查 docker 网络，还翻了 NapCat 的配置——全是白费功夫。真正的原因在 AstrBot 后台：我给机器人配的那个适配器没启用。适配器不启用，它就不去监听 6195。

后台 → 机器人 → 编辑适配器，平台选 OneBotv11 / aiocqhttp，反向 WS 主机写 0.0.0.0（不是 127.0.0.1），端口 6195，保存启用。

然后确认一下门真的开了：

ss -tlnp | grep 6195

解析不到主机名，因为不在一张网里

后来我为了改点东西，图省事用 docker run 把 AstrBot 单独起了一份，绕开 compose。NapCat 立刻报：

getaddrinfo EAI_AGAIN astrbot

EAI_AGAIN 是解析不出主机名。原来服务是 compose 起的，两个容器在同一个自定义网络里，网络内部可以直接拿服务名当主机名，所以配置写 ws://astrbot:6195/ws 才通。我手动起的那个容器落在默认 bridge 网络，压根不在这个网里，当然解析不到 astrbot。

我想那用 IP 吧，改成宿主机地址，又报：

ECONNREFUSED 172.17.0.1:6195

172.17.0.1 是宿主机在 Docker 网桥上的地址（默认 docker0）。NapCat 能连到宿主机，可宿主机上没跑 6195 的服务，服务在另一个容器里。

最后老老实实回到 compose 统一管理。这种"一半 compose 一半 docker run"的混搭，迟早出事。

能连上，但包太大了

第三次最迷惑，因为跟连接完全无关：

[OneBot] [WebSocket Client] 反向WebSocket (ws://astrbot:6195/ws) 连接错误
RangeError: Max payload size exceeded
    at /app/napcat/node_modules/ws/lib/receiver.js:442

场景很明确：点歌，让机器人发语音。文件一大，单条 WebSocket 消息超限，连接直接被掐。

我几乎把网上能找到的办法试了一遍。第一次把 maxPayloadSize 加在 websocketServers 里，没用——后来发现我实际用的是 websocketClients；挪过去，还是没用；我又怀疑是配置文件语法有问题（那个文件开头少了个 {），补上，照样没用。

结论是：这个版本的 NapCat 在客户端模式下，payload 上限是写死的，配置项覆盖不了。

改传输方式。不发语音通道了，让机器人把音频当文件发，走 HTTP 上传，不经过 WebSocket：

"timeout": {
  "uploadSpeedKBps": 1024,
  "downloadSpeedKBps": 1024
}

发不出去的问题没了。

这三个坑我后来总结过一句话：ECONNREFUSED 是服务状态问题（开关没开），EAI_AGAIN 是容器网络问题（不在一张网），Max payload 是传输限制问题（能连、包太大）。长得像，查的地方完全不同。大文件别硬走 WebSocket，这条也记住了。