回调失败90%是服务器配置问题，需检查公网可访问性、防火墙、Nginx拦截规则及HTTPS证书；签名验证前必须用file_get_contents('php://input')原样读取原始数据，禁用自动解析与转码。
回调 URL 不被支付平台访问到，90% 是服务器配置问题
支付平台发来的回调请求根本没进你的 PHP 脚本，不是代码逻辑错，而是网络或服务层挡住了。常见现象：502 Bad Gateway、Connection refused、超时无响应，或 Nginx/Apache 日志里完全查不到该请求。
- 确认回调地址是公网可访问的（不能是
127.0.0.1、localhost或内网 IP），且协议、端口、路径与你在支付后台填写的**完全一致**（注意末尾斜杠、大小写） - 检查服务器防火墙（如
ufw、iptables）是否放行了对应端口（通常是 80/443） - Nginx 配置中确保没有
location规则意外拦截了回调路径（例如用^~ /api/匹配但漏掉了/notify） - 如果是 HTTPS 回调，确认证书有效（部分平台如微信会校验证书链，自签名证书直接失败）
签名验证失败，先看原始数据有没有被 PHP 自动处理过
很多开发者卡在「明明按文档拼了参数，签名还是不一致」，根本原因是 PHP 的 $_POST 或 file_get_contents('php://input') 拿到的数据已被篡改或截断。
- 微信/支付宝等平台回调默认用
application/xml或application/json发送，此时$_POST为空——必须用file_get_contents('php://input')原样读取原始 body - Apache + mod_php 下，某些配置（如
enable_post_data_reading Off）会导致php://input为空，需改为On；Nginx + PHP-FPM 则通常没问题 - 读取后别做
urldecode、json_decode再重拼——签名必须基于原始未解析的字符串（XML 文本或 JSON 字符串本身）计算 - 检查签名密钥是否用对：微信分「API 密钥」和「商户证书私钥」，支付宝分「应用私钥」和「支付宝公钥」，拿混就必然失败
PHP 接收回调时容易忽略的底层细节
看似简单的 HTTP 请求接收，在生产环境常因 PHP 运行模式或框架行为出问题。
- 不要依赖
$_SERVER['REQUEST_METHOD'] === 'POST'就认为是合法回调——支付平台可能用 GET 模拟（极少见），或你被恶意伪造请求；必须校验签名+来源 IP（微信提供白名单 IP 段，支付宝有notify_id二次查询机制） - PHP 脚本执行超时（
max_execution_time）会导致回调中断，平台重试；建议开头加set_time_limit(0)，并立即返回成功响应（echo 'success'），再异步处理业务逻辑 - 日志要记两件事：原始请求体（
file_get_contents('php://input')）、签名计算过程中的待签字符串；否则出问题只能抓瞎 - 避免在回调里直接操作数据库写入失败导致整个流程卡死——用消息队列或记录待处理任务表更稳妥
调试阶段怎么快速定位是 URL 还是签名问题
别靠猜，用最简方式隔离问题。
立即学习“PHP免费学习笔记（深入）”；
- 先写一个裸脚本（不引入框架、不连接数据库），只做三件事：记录
php://input到文件、打印$_SERVER头信息、固定返回success；部署到回调地址，看支付平台后台是否显示「通知成功」 - 如果平台仍报「无响应」，就是 URL 层问题（DNS、防火墙、反向代理）；如果显示「通知成功」但你的签名验证失败，说明数据通了，专注查签名逻辑
- 用微信「沙箱环境」或支付宝「回调调试工具」发送模拟请求，比等真实支付触发快得多；注意模拟请求的 timestamp、nonce_str 等字段也要参与签名
- 用
curl -v手动模拟回调请求，对比你本地收到的原始数据和平台文档给的示例数据，逐字节比对（尤其空格、换行、编码）
