用 curl 排查接口问题：从状态码到请求耗时一步步定位

前端说接口报错，后端说本地正常，这种扯皮在开发中很常见。与其各说各话，不如直接在服务器或本机上用 curl 把请求复现一遍。curl 几乎每台 Linux 机器都自带，掌握几个参数，就能快速判断问题出在网络、证书、网关还是业务代码。

一、先看状态码和响应头

加上 -i 参数可以同时看到响应头和响应体：

curl -i https://api.example.com/v1/users

状态码大致可以这样理解：4xx 通常是请求本身的问题，比如 401 没带或带错了令牌，403 没有权限，404 路径写错，429 请求太频繁被限流；5xx 则是服务端的问题，其中 502、504 往往说明网关后面的服务没启动或超时了，而 500 多半要去查应用日志。

二、用 -v 看完整的连接过程

curl -v 会打印 DNS 解析后的 IP、TCP 连接、TLS 握手以及发送的请求头。如果卡在 “Trying x.x.x.x” 不动，说明网络或安全组不通；如果报证书错误，要检查证书是否过期、域名是否匹配、证书链是否完整。确认问题之前不要习惯性地加 -k 跳过校验，那样只会把问题藏起来。

三、复现真实请求

很多“本地正常”的情况，是因为请求参数和线上不一样。带上请求头和请求体，尽量还原调用方的请求：

curl -X POST https://api.example.com/v1/orders \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"sku":"A100","qty":2}'

浏览器开发者工具的网络面板里，右键某条请求可以直接“复制为 cURL”，省去手动拼参数的麻烦。注意分享给别人前，把令牌和 Cookie 去掉。

四、拆解请求耗时

接口慢的时候，可以用 -w 输出各阶段的时间：

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} first_byte:%{time_starttransfer} total:%{time_total}\n" https://api.example.com/v1/users

如果 dns 一项很大，要看解析配置；connect 大说明网络链路慢；first_byte 和 tls 之间差距很大，则是服务端处理慢，应该去看数据库查询或下游依赖。

五、绕过负载均衡直连后端

怀疑是某一台后端实例出问题时，可以用 --resolve 把域名临时指向指定 IP，同时保留正确的 Host 和证书校验：

curl --resolve api.example.com:443:10.0.0.12 https://api.example.com/health

逐台测试，很快就能找出异常的那一台。

小结

排查接口问题时，先看状态码分清责任方，再用 -v 看连接过程，用真实参数复现请求，用 -w 拆解耗时，最后用 --resolve 定位到具体实例。这套顺序走下来，大部分接口问题都能在几分钟内找到方向。