1.9 KiB
1.9 KiB
2026-08-28 工作日志
抖音 IM「decision=KICK」排查（服务器 116.62.23.103）
结论：不是抖音改了 IM 规则/签名算法，是账号被安全网关风控踢下线。签名链路正常（同服务器另一账号可正常发送、读接口正常返回、凭证完整）。
关键证据（服务器 MySQL kefu 库 + /www/wwwlogs/python/douyin/error.log）：
- 活跃账号：id=11「随安尔乐」my_uid=7670159096859706425、id=12「抖音账号_12」my_uid=7670157997767050299，均为 Chrome/148 UA，keys/web_protect 凭证完整（len 533/459）。
- 两个账号反复 KICK，且都在回复同一测试号「Huhao」(peer_uid=66578464308)，回复内容只是 "ss"/"jjj" 测试文本（非导流话术）。
- 时序：KICK → create_conversation INVALID_REQUEST → 「用户未登录」→ 自动重登录 → 恢复 → 再发 → 再 KICK，形成死循环（约每 10~30 分钟一次）。
- 读接口(get_by_user_init)正常，只有 signed 的发送(message/send)被 KICK → 签名没问题，是账号级风控。
根因判断：抖音 2026 风控收紧（内容+设备+IP+行为+账号五维）。触发点最可能是：多账号同服务器 IP + 对同一陌生 peer 的自动回复行为；且 KICK→重登→再发 的紧循环本身会加重风控。
处理方向：
- 停掉受影响账号的托管/自动回复，冷却几小时~一天。
- 浏览器模式手动重登，先用互关好友或「对方先发」的真实用户测发送，别再用小号对冷门 peer 反复自动回。
- 确认账号没在手机端同时登录（并发登录会吊销 web ticket）。
- 后续可选代码改进：KICK 后对同一会话加冷却（重登后暂不重发），打断紧循环。
环境备注：后端用 MySQL(KEFU_DB_TYPE=mysql)，kefu.db/kefu1.db 是遗留 SQLite（kefu.db 已损坏，非活跃库，可忽略）。