关于本文
本文在核对 curl 官方文档和 HTTP 规范的基础上进行整理。验证状态：📘 已确认官方规范，连接目标依赖部分未固定
HTTP 标头的值会根据连接目标和时间点而变化。本文探讨的是解读方法，而非“必须是特定值”。
curl -I 是确认 Web 服务器返回的 HTTP 响应元数据的切入点。无需一开始就记住所有标头。只需按顺序查看 Status、Content-Type、Content-Encoding、Cache-Control 和 Content-Length，就能大大简化 Web 服务器的排查工作。
curl -I 发送了什么
针对 HTTP URL 的 -I / –head 会使用 HEAD 请求。
curl -I https://example.com/
sequenceDiagram
participant C as curl
participant S as Web server
C->>S: HEAD /
S-->>C: Status + Header fields
Note over C,S: response bodyは送信しない
HEAD 是一个 HTTP 方法，用于在没有正文的情况下确认与 GET 对应的元数据。因此，curl -I 的结果和实际的 GET 并不一定完全逐字相同。
首先查看的 5 个项目
从概念上讲，我们将阅读以下输出内容。
HTTP/2 200 content-type: text/html; charset=UTF-8 content-encoding: gzip cache-control: max-age=300 content-length: 12345
| 项目 | 查看内容 |
|---|---|
| Status | 请求结果 |
| Content-Type | HTML、JSON、JavaScript 等表达类型 |
| Content-Encoding | gzip 等内容编码 (content coding) |
| Cache-Control | 针对缓存的指令 |
| Content-Length | 关于表达长度的信息 |
flowchart LR
A[HTTP response] --> B[Status]
B --> C[Content-Type]
C --> D[Content-Encoding]
D --> E[Cache-Control]
E --> F[Content-Length]
切勿仅凭 Status 判断“网站正常”
200 表示 HTTP 请求成功。但这并不意味着应用程序内部的所有功能都正常，或者数据库也正常。
相反，301 或 302 是用于跳转到其他 URL 的重定向，并不一定是故障。
Content-Type 返回了什么
content-type: text/html; charset=UTF-8
在此示例中，表达形式为 HTML，且 charset 表示为 UTF-8。如果是 API 排查，则可能是 application/json；如果是 JavaScript，则可能是 text/javascript 或 application/javascript 等，具体取决于对象。
在确认 gzip 时查看 Content-Encoding
即使在 Web 服务器上启用了 gzip，也并非所有响应都一定会 gzip 压缩。这与请求方的 Accept-Encoding、Content-Type、大小以及服务器设置等有关。
如果要确认接受压缩的请求，例如可以显式指定如下内容。
curl -sS -D - -o /dev/null -H 'Accept-Encoding: gzip' https://example.com/
如果响应中包含以下内容，则说明使用了 gzip 内容编码。
content-encoding: gzip
Cache-Control 不仅限于“缓存与否”
Cache-Control 包含 max-age、no-cache、no-store 等多个指令。由于它们的含义各不相同，如果仅凭“看到 no-cache 这个词所以不缓存”来记忆，很容易产生误解。
调查 HTTP 缓存时，请结合 RFC 9111 一同阅读。
有时可能没有 Content-Length
切勿认为 HEAD 响应中没有显示 Content-Length 就一定存在异常。可见的信息会因传输方法、动态生成、HTTP 版本以及服务器实现等因素而异。
比起“寻找本应存在的标头”，从“实际返回的标头中读出含义”更为安全。
切勿混淆 -I 与 -i
-I：在 HTTP 中发送 HEAD，并确认响应标头
-i：在常规响应中，与正文一起显示标头
如果还想查看 GET 时的实际响应，-i 或 -D – 是备选方案。
curl -i https://example.com/
延伸至 Nginx 排查
如果在 Nginx 中排查 gzip 或缓存，不仅要查看配置文件，最终还要通过 curl 确认其是如何体现到 HTTP 响应中的。
flowchart LR
A[Nginx設定] --> B[リクエスト]
B --> C[レスポンス]
C --> D[Content-Type]
C --> E[Content-Encoding]
C --> F[Cache-Control]
D --> G[設定と実測を照合]
E --> G
F --> G
将设置值与实际响应分开确认，便可排查诸如“写了配置但未应用于目标响应”之类的问题。
小结
curl -I 在 HTTP 中使用 HEAD 请求
首先仅读取 Status 和主要标头
gzip 主要看 Content-Encoding，缓存主要看 Cache-Control
HEAD 和 GET 的目的不同，因此必要时也请确认 GET 端
在 Web 服务器排查中，请核对“设置”与“实际的 HTTP 响应”
官方信息与一手资料
curl 命令行工具与库 — 手册
https://curl.se/docs/manpage.html
RFC 9110 — HTTP 语义
https://www.rfc-editor.org/rfc/rfc9110.html
RFC 9111 — HTTP 缓存
https://www.rfc-editor.org/rfc/rfc9111.html
