接口不通先别怪后端：用 curl 把问题定位到哪一层

联调时最常见的一句话就是“接口不通”。但“不通”其实是好几种完全不同的故障：域名解析失败、网络不可达、TLS 握手失败、服务端返回错误码、返回体格式不对。直接把锅推给后端，往往来回扯皮半天。curl 是每个开发机上都有的工具，用它按层排查，几分钟就能把问题钉在某一层。

第一层：先看能不能连上。`curl -v https://api.example.com/health` 里的 -v 会打印 DNS 解析、TCP 连接、TLS 握手的全过程。如果卡在 “Could not resolve host”，那是 DNS 或域名本身的问题，先检查域名拼写和本地解析；如果卡在 “Connection refused” 或超时，先看端口和防火墙，而不是去翻业务代码。

第二层：看状态码，别只看正文。很多接口返回 200 但正文是错误提示，也有很多接口返回 4xx 但正文写得很清楚。用 `curl -i` 同时打印响应头和正文，用 `-o /dev/null -w "%{http_code} %{time_total}\n"` 只看状态码和耗时。401 先查 Token 是否过期，403 查权限，404 查路径，500 再去找后端日志。状态码定性，比把整个报错截图发群里有效得多。

第三层：精确复现请求。浏览器开发者工具里可以把一次请求“复制为 cURL”，拿到命令后在终端重放，能复现就是后端或参数问题，不能复现先怀疑浏览器缓存、Cookie 或代理。发 POST 时用 `-H "Content-Type: application/json" -d '{"name":"test"}'`，注意 shell 里单引号包 JSON、双引号包字段的基本写法，很多人调不通只是引号转义错了。

第四层：怀疑代理和证书。公司内网、VPN、抓包工具都可能改写请求。`curl --noproxy '*'` 绕过代理重测一次，如果绕过就通了，问题在代理配置不在接口。遇到证书报错先别急着加 -k 跳过验证：-k 只适合本地自签调试，生产联调长期用 -k 等于关掉校验，正确做法是把自签 CA 加进系统信任库，或者确认对方证书链本身没过期。

最后，把结论写成一句话再去找人：比如“域名解析正常、TCP 能通、TLS 握手失败，证书已过期三天”。带着分层结论去沟通，对方可以直接动手，不用再从头复现一遍。排查接口的本质不是工具多熟，而是先分层、再定性、最后复现——curl 只是把这三步做得最快的那把尺子。