用 curl 快速验证接口与排查网络问题

接口调不通时，很多人第一反应是改代码、重启服务，其实问题可能根本不在代码里：域名没解析、端口没放通、反向代理配错了，都会表现为同样的报错。先用 curl 在命令行里把请求单独跑一遍，把网络层和应用层分开，往往几分钟就能缩小范围。

最基础的是看状态码和响应头。curl -i https://example.com/api/health 会同时输出响应头和响应体，状态码一眼就能看到：200 是通了，404 是路径不对，502/503 多半是后端或代理出了问题。只想看头、不想下载大响应体时，用 curl -I，相当于只发 HEAD 请求，适合快速确认服务是否存活。怀疑缓存或重定向捣乱时，加上 -L 让 curl 自动跟随重定向，再用 -w “%{http_code} %{url_effective}” 看最终落到了哪个地址，避免被 301 带到错误的地方还以为是接口本身有问题。

接口返回不对时，先确认发出去的到底是什么。curl -v 会打印完整的请求过程：DNS 解析到了哪个 IP、TLS 握手是否成功、发了哪些请求头、服务器回了什么。看到 TLS 报错先别急着怀疑证书过期，可能是系统时间不对、或者中间代理截获了证书。测试环境证书自签时可以用 -k 跳过校验，但这只是排查手段，正式调用绝不能长期用它。需要带请求体时，POST 用 -X POST -H “Content-Type: application/json” -d ‘{“name”:“test”}’，把请求头和请求体都显式写出来，排除了客户端封装差异，问题就更容易复现。

耗时问题也要量化，不要只凭感觉说“慢”。curl -w 能输出各阶段耗时，比如 DNS 解析、TCP 连接、TLS 握手、首字节返回各花了多久。DNS 耗时高就查解析，TLS 耗时高就看证书链和网络往返，首字节耗时高才是后端处理慢。这样分段看，就不会把数据库慢查询误判成网络问题，也不会把网络抖动误判成代码问题。加 -o /dev/null -s 可以把响应体丢掉，只看耗时统计，适合反复测。

还有几个排查组合很实用。怀疑是本机代理或环境变量干扰时，用 curl --noproxy ‘*’ 绕过代理直接连，对比结果就能确认是不是代理的问题。怀疑 IPv6 解析异常时，用 -4 强制走 IPv4，看问题是否消失。接口在浏览器里能打开、在命令行里却 403，多数是少了 User-Agent 或 Cookie，用 -H 加上浏览器同款请求头再试一次，往往就能复现或排除。需要反复测同一个接口时，把完整命令写进一个小脚本，参数一变就能重跑，比每次在浏览器里点来点去可靠得多。

curl 的价值不在于命令多，而在于它把一次请求拆成了可验证的步骤：先确认能不能连通，再确认状态码对不对，最后才看响应体里的业务数据。按这个顺序排查，网络问题、配置问题、代码问题各归其位，不用再靠重启和猜测碰运气。