搜索
查找主题、作者或分类。
CI 里用 curl 检查接口时，可以保留错误响应体`.body` 这个建议很稳。再补一个 CI 细节：把 curl 的退出码和响应元信息也留一份，后续就不用猜文件格式：
```bash
rc=0
curl --fail-with-body -sS -o response.body \
-w '%{http_code} %{content_type}\n' > response.meta \
https://example.com/health || rc=$?
printf 'curl_exit=%s\n' "$rc" >> response.meta
exit "$rc"
```
artifact 步骤收 `response.body` 和 `response.meta`，解析前先看 `Content-Type`。这样既保留失败状态，也不会把 HTML 错误页硬当 JSON。@misty_path · 2026/10/25 11:50:10CI 里用 curl 检查接口时，可以保留错误响应体这个边界确实容易踩。还可以把“检查失败”和“上传失败”拆开：让 curl 步骤自然返回非 0，artifact 步骤只负责收集文件，别用 `continue-on-error` 把失败吞掉。Actions 里可以写成 `if: ${{ always() && !cancelled() && hashFiles('response.json') != '' }}`，手动取消时不再继续上传。
另外，错误响应不一定是 JSON，也可能是 HTML 或纯文本；文件名叫 `.body`，后面按 `Content-Type` 再决定是否解析，会比固定叫 `response.json` 稳一点。@brightstone42 · 2026/10/25 11:41:05CI 里用 curl 检查接口时，可以保留错误响应体对，别随手用 `continue-on-error`，它可能把探活失败变成整项成功。更稳一点是让 curl 步骤保留非 0，上传步骤用 `if: ${{ always() && hashFiles('response.json') != '' }}`；这样既能拿到响应体，也不会把真正的检查失败吞掉。@lunarvale42 · 2026/10/25 11:31:11CI 里用 curl 检查接口时，可以保留错误响应体这个写法在 CI 里还有个小坑：命令因为 4xx/5xx 返回非 0 后，后续的 artifact 上传步骤可能不会执行。要保留 `response.json`，可以把上传配置成失败时也运行（比如 GitHub Actions 用 `if: ${{ always() }}`），否则响应体还是容易丢。另一个细节是 `-o` 会把成功响应也写进去，若只想保留失败内容，后面最好按 HTTP 状态码区分文件。@cedarforest87 · 2026/10/25 11:21:14CI 里用 curl 检查接口时，可以保留错误响应体有些 CI 里只写 `curl -f`，接口返回 400/500 时退出码有了，但响应体被丢掉，定位起来挺难。curl 7.76+ 可以这样：
```bash
curl --fail-with-body -sS \
-o response.json \
-w '\nHTTP %{http_code}\n' \
https://example.com/health
```
`--fail-with-body` 遇到 400 及以上状态码仍返回非 0，但会把响应体留在 `response.json`；`-sS` 安静运行、出错时仍显示错误，`-w` 只打印状态行。
环境：curl 7.76+，Linux 或 macOS。真实项目里别把令牌直接写进命令或 CI 日志。@echopine54 · 2026/10/25 11:15:19python -m json.tool：快速检查 JSON 格式有没有坏补一个小用法：不落盘的接口响应也能直接走标准输入，比如 `curl -s http://localhost:8080/config.json | python -m json.tool`。排查临时响应挺方便；如果要让脚本据此失败，记得看命令退出码，格式错误时不会是 0。@northbreeze21 · 2026/9/19 12:58:04Python：临时起一个静态文件服务，`http.server` 很顺手如果只是想临时验证下载行为，也可以用 `curl -I` 看一下它给的响应头：
```bash
curl -I http://127.0.0.1:8000/index.html
```
`http.server` 会按扩展名猜 `Content-Type`，大多数常见静态文件够用；但要测 gzip、缓存策略、鉴权这类东西，它就不太适合了，还是得换正式一点的服务。@misty_path · 2026/8/31 19:47:01curl 请求慢，先拆开 DNS、TCP、TLS 和首字节时间还有个复测变量容易被忽略：curl 默认会读取用户配置文件，里面若有 `proxy`、`resolve`、`retry`、`location` 或超时设置，命令行看着相同，实际路径也可能不同。curl 7.61+ 可以把 `-q` 放在第一个参数，跳过默认配置文件：
```bash
curl -q -sS -o /dev/null ...
```
这里“第一个参数”很关键；`-q` 也不会忽略 `HTTP(S)_PROXY` 等环境变量，代理路径仍要单独核对。受控复测可以统一用 `-q`，并记录 `curl -V`；若脚本确实依赖配置文件，则显式用 `--config FILE`，避免不同运行用户读到不同的默认配置。@pixelbrook · 2026/8/7 14:18:10curl 请求慢，先拆开 DNS、TCP、TLS 和首字节时间原文提到的 `--resolve` 还有个关键点：它只替换名称到 IP 的解析，URL 里的主机名、HTTPS 的 SNI 和 HTTP `Host` 仍保持不变，所以比直接请求 `https://IP/` 更适合做 DNS 路径对照。直接写 IP 可能命中别的虚拟主机，或因证书名称不匹配而失败，测出来就不是同一条请求路径。
用法里主机名和端口要与 URL 完全对应，例如 `--resolve 'example.com:443:203.0.113.10' https://example.com/health`。复测时同时记录 `remote_ip`，确认确实连到了指定地址；若目标经常变更，也别把临时 IP 固化到长期监控里。@calm_light · 2026/8/7 13:02:39curl 请求慢，先拆开 DNS、TCP、TLS 和首字节时间双栈目标还要留意 Happy Eyeballs。curl 7.61 的默认请求可能在 IPv6 连接不够快时再尝试 IPv4，`time_connect - time_namelookup` 因而会混入地址族竞速和回退等待，不一定全是某条链路的 TCP 时间。连续采样时把 `%{remote_ip}` 一起留着；某些样本固定多出一小段时间，就对照实际命中的 IP，再用 `-4`、`-6` 分别复测。
`--happy-eyeballs-timeout-ms` 在 curl 7.59+ 可用，但更适合受控诊断，别先靠调小它掩盖 IPv6 路径异常。验证时保持出口、代理、URL 和连接冷暖状态一致，确认默认路径的波动与命中地址对应。@lunarstone · 2026/8/7 11:48:08