回调收到 400 报错通常不是网络不通，而是接收端服务器拒绝了请求格式或签名验证，优先检查服务端日志和业务代码的验签逻辑。
先说结论：HTTP 400 代表请求无效，问题大概率出在接收方的参数解析、签名校验或响应格式不符合发送方要求。
- 先确认：接收接口是否能公网访问且返回状态码正常
- 先处理：核对签名算法、时间戳容差及 Content-Type 设置
- 再验证：使用模拟请求工具重放事件，观察日志变化
命令速用版
如果没有现成的测试工具，可以用 curl 模拟 POST 请求检查接口响应：
curl -v -X POST https://your-domain.com/callback -H "Content-Type: application/json" -d '{"test":"data"}'观察返回的 HTTP 状态码是否为 200，以及响应 body 是否符合平台要求。
为什么会这样
HTTP 400 Bad Request 意味着服务器理解了请求的语法，但无法执行。在回调场景中，常见原因是发送方携带的签名与你计算的签名不一致，或者请求头缺失关键字段。有些平台严格要求回调接口必须返回特定的成功标识（如纯文本 success 或特定 JSON），如果返回了 HTML 错误页或多余内容，也可能被判定为失败并重试，进而触发报错。
分步处理
1. 检查服务端日志：查看 Nginx 或应用日志，确认请求是否到达。如果日志里没有记录，可能是防火墙或 WAF 拦截，需检查安全组规则，做完确认日志中出现对应 IP 的访问记录。
2. 核对签名逻辑：对比官方文档的签名生成步骤，注意字符串拼接顺序、加密方式（MD5/SHA256）及密钥是否正确，确保本地计算结果与请求头一致，做完确认签名比对通过。
3. 检查响应内容：确保接口处理成功后只返回平台规定的成功标记，不要输出调试信息或额外的 HTML 标签，避免污染响应体，做完确认返回体纯净。
4. 确认时间同步：签名通常带时间戳，服务器时间偏差过大会导致验签失败，建议在终端运行 date 命令核对并配置 NTP 同步，做完确认时间误差在允许范围内。
怎么验证是否生效
在平台控制台找到“发送测试通知”或类似按钮，触发一次回调。同时在你服务器终端使用 tail -f 命令监控日志，确认收到请求且业务逻辑返回 200 状态码。如果平台侧显示推送成功且不再报错，即表示修复生效。
常见坑
1. HTTPS 证书问题：如果回调地址是 HTTPS，证书过期或不受信任会导致发送方拒绝连接。
2. 重定向干扰：接口配置了 301/302 跳转，部分平台不支持跳转后的回调接收。
3. 字符编码：签名计算时对中文或特殊字符的编码处理不一致（如 UTF-8 与 GBK）。
4. 安全组限制：云服务器安全组未放行 80 或 443 端口，导致外网无法访问。