固定时间断：多半是单条连接满 24 小时；随机断：多半是心跳没回；连着却没事件：订阅已结束；2026-02-20 以后彻底收不到：工具可能还在用已停用的 listenKey 接口。前三种靠工具自动重连解决，最后一种只能等工具升级或换工具。
先确认断的是哪一条：行情推送和账户推送不是一回事
多数交易工具和币安之间不止一条连接。K 线、深度、最新成交这类公开行情走一条；你自己的挂单变化、成交回报、余额变动走另一条，币安开发者文档把后者叫“用户数据流”（User Data Stream），中文版页面标题是“WebSocket 账户接口”。
两条连接的认证方式不同，断开的原因也不同。行情推送不需要 API 密钥；账户推送必须用你交给工具的那把密钥去订阅。所以症状通常是这样的：图表照常刷新，工具里那笔限价单却一直显示“未成交”，而你在币安网页上已经能看到它成交了。
出现这种对不上，先别去改密钥权限。只读、交易这些权限决定工具能不能查、能不能下单，和推送有没有连上是两件事。账户推送断了，工具通常仍能用 REST 接口主动查询；有的工具在推送不可用时会退回定时轮询，这样更新变慢、请求变多——后者又会牵扯到下面讲的限速。
2026 年 2 月之后，还在用 listenKey 的工具为什么收不到更新
老一点的工具订阅账户推送的方式是：先调用 POST /api/v3/userDataStream 拿一个 listenKey，用它连接 wss://stream.binance.com，再定时调用 PUT 续期。这条路在现货上已经关了。
币安现货 API 更新日志里的时间线是这样的：
- 2025-04-07：宣布用 listenKey 在
wss://stream.binance.com:9443接收用户数据流的方式“已弃用”，改为在 WebSocket API 上订阅。 - 2025-10-24：与 listenKey 相关的文档从现货文档中移除，接口暂时还能用。
- 2026-01-21：公告下列接口自 2026-02-20 07:00（UTC）起不再可用——REST 的
POST、PUT、DELETE /api/v3/userDataStream，以及 WebSocket API 的userDataStream.start、userDataStream.ping、userDataStream.stop。
如果一个工具在这个日期之后没有更新过连接代码，它要么拿不到 listenKey，要么拿到的旧 key 续不了期。表现是：行情正常，账户推送从某一天起再也没恢复，重启工具也没用。这种情况你在账户这一侧无能为力，换密钥、开权限、调 IP 白名单都不会让它好起来。要做的是去看工具的更新记录或支持页面，确认它是否已经改用 WebSocket API 订阅；没有改的，联系维护者，或者在它更新之前停用自动交易功能，避免工具基于过时的订单状态继续下单。
这条停用针对的是现货。杠杆账户的推送官方另有一套 listenToken 订阅说明，合约等产品线也各有自己的用户数据流文档，规则不能直接套用到这里。
两种新订阅方式，和你给工具的密钥类型有关
现在的现货账户推送，是在 WebSocket API（wss://ws-api.binance.com:443/ws-api/v3）这条连接上订阅的。文档给了两种开始订阅的方法：
userDataStream.subscribe：先用session.logon让整条连接以某把密钥的身份登录，再订阅这个账户的事件。文档“会话认证”一节写明，这个功能只支持 Ed25519 密钥。userDataStream.subscribe.signature：不需要先登录，每次订阅时带上 API Key、时间戳和签名。更新日志说明它可以使用任何密钥类型，HMAC、RSA 也行。
这对你交钥匙的方式有实际影响。假设你给某个工具建的是 HMAC 密钥，工具却提示“实时推送需要 Ed25519 密钥”，说明它走的是第一种。你可以按它的要求换一把 Ed25519 密钥，也可以问维护者能否改用签名订阅。换类型等于新建一把密钥，旧的那把要记得删掉，顺序参照计划换钥匙的处理顺序；几种类型的差别在HMAC、RSA、Ed25519 那篇。
第二种方式还有一个维护上的细节：签名订阅要带时间戳，所以设备时钟偏差同样可能让订阅失败，思路和普通签名请求遇到 -1021 时相同，排查方法见时间与签名问题分开查。另外，session.logout 只会结束第一种方式建立的订阅，签名订阅不受它影响，要用 userDataStream.unsubscribe 关闭。
每天差不多同一时间断一次：24 小时连接上限
这是最常见、也最不需要担心的一种。
文档写得很直接：每个到 base URL 的连接有效期不超过 24 小时，到点会被断开，需要客户端自己处理断线重连。服务器维护前还会先发一个 serverShutdown 事件，随后断开，文档要求尽快建立新连接。
关键在于订阅是挂在连接上的。连接一断，上面的订阅也就没了；新连接建好之后，工具必须重新登录或重新签名订阅一次，不会自动恢复。一个正常维护的工具，在日志里会看到每隔约一天出现一次“重连—重新订阅”，而界面上几乎察觉不到。
如果你看到的是每天同一个时间点之后推送就停了，要等到你手动重启工具才恢复，那就是重连写了、重新订阅没写，或者重新订阅失败了却没报出来。这需要工具方修，你能提供的是“每天几点开始停”这条线索。
不定时掉线：20 秒一次的 ping 没有回应
按现行文档，服务器每 20 秒向连接发一次 ping 帧；如果一分钟内没收到 pong，就断开连接。客户端收到 ping 后应尽快回一个 pong，载荷和 ping 相同。客户端主动发的 pong 是允许的，但文档特别注明，这样做并不能防止断开。
网上有些旧问答写的是“每 3 分钟一次 ping”，那是早期说法，排查时以开发者文档当前版本为准。
不定时掉线时，先看工具跑在哪里。装在笔记本上的桌面工具，电脑休眠、合盖或者网络切换时进程停住，自然回不了 pong；放在云服务器或容器里的，资源打满、进程长时间卡顿也会错过。至于工具用的 WebSocket 库会不会自动回 pong，这是维护者要确认的事，不是账户设置能解决的。
这一类掉线和 24 小时上限的区别在于没有规律。把最近几次断开的时间记下来，间隔接近 24 小时的归到上一节，间隔不定、而且和电脑休眠或服务器负载时间吻合的，归到这一节。
连接没断、事件却不来：订阅本身已经结束
还有一种更隐蔽的情况：连接一直在，工具的心跳指示灯也是绿的，但账户事件不再到达。
用户数据流文档列了 eventStreamTerminated 事件发出的几种时机，与现货相关的是两种：用 session.logout 结束了登录方式的订阅，或者调用 userDataStream.unsubscribe 停止了订阅。收到这个事件之后，这个订阅就不会再推送了。工具如果在切换账户、退出登录时调过这两个方法，又没有重新订阅，就会落到这里。
工具方可以用 session.status 查看当前会话里有没有活跃订阅：返回字段 userDataStream 为 true 表示至少有一个订阅在活动，false 表示一个都没有。session.subscriptions 则能列出所有活跃订阅。
还有一条限制，同时管很多账户的工具值得留意：同一条连接上，同一个账户只能有一个订阅。
重连写得太急，会把同一出口的 IP 拖进限制
断线重连本身是对的，问题出在重连的节奏。
WebSocket API 的连接数是按 IP 统计的：文档写明每个 IP 每 5 分钟最多尝试 300 次连接，每次建立连接还要消耗 2 点请求权重。权重同样按 IP 累计，同一出口地址上的所有连接共用一个额度，超过之后请求返回 429；收到 429 还继续猛发，会被自动封禁 IP，被封期间返回 418，封禁时长对屡犯者会逐步拉长，从 2 分钟到 3 天不等。
一个断线后立刻、无间隔、无限次重连的工具，在网络抖动时很容易把自己推到这条线上。更麻烦的是，云端工具可能让多个用户共用同一个出口 IP，一个人的重连风暴可能连累同一台服务器上的其他连接。重连之间应当逐步拉长等待时间，收到 429 时按响应里的 retryAfter 停下来，这和 REST 请求遇到限速时的做法一致，细节见遇到 429 先暂停。
还有一点容易被忽略：官方文档没有说明断线期间发生的账户事件会在重连后补发。稳妥的维护做法是，每次重新订阅成功后，用查询接口把挂单和余额核对一遍，再继续依赖推送。不这么做的工具，可能在你看不见的地方拿着一个已经成交或已撤销的订单状态做后续判断。
交给工具维护者之前，准备好这几样信息
大部分账户推送问题，最终都需要工具一方改代码或升级版本。你这边能做的，是把现象描述到对方可以直接定位的程度，同时不泄露任何秘密信息。
- 断开的时间点（写清时区），以及是否大约每 24 小时出现一次。
- 断开时行情是否还在更新——用来区分是账户推送还是整个网络断了。
- 工具上次更新的版本和日期，特别是 2026-02-20 之后有没有更新过。
- 你给它的密钥是哪一类：HMAC、RSA 还是 Ed25519（只说类型，不发密钥本身）。
- 工具运行在哪里：本机、云服务器，还是工具方的托管服务；本机运行时电脑有没有休眠。
- 界面或日志里出现过的错误原文，例如 429、418 或带负号的错误码。
API Key、Secret、私钥文件和签名串都不要发给任何人，包括自称客服的人。错误码本身怎么分流，可以先对照-2015、-1021、-1022 和 429 的排查顺序，或者在权限检查里输入错误码看下一步该查哪里。
如果工具方迟迟不修，而它又持有交易权限，比较稳妥的选择是先停掉它的自动下单，必要时删掉那把密钥。一个看不到真实订单状态的自动化工具，比暂时不用它风险更大。