curl -X HEAD 收到响应头后仍不退出

用 curl -X HEAD 查看网页信息，终端迟迟没有输出；加上小写 -i 后能看见 200 OK 和响应头，命令却仍停在那里。过一段时间还可能出现 transfer closed with ... bytes remaining to read。换成大写 -I，同一地址很快返回响应头并结束。

如果已经收到完整响应头，这种差异通常来自请求方法与 curl 的接收行为不一致：-X HEAD 只把请求里的方法文字改成 HEAD，没有同时告诉 curl 不应等待响应正文。本文针对 HTTP/HTTPS 请求；尚未完成 DNS、连接或 TLS 握手的等待，不属于这个判断。

HEAD 响应里的长度不表示随后还有正文

HEAD 用于取得资源的响应信息，正常响应不发送正文。它可以带有非零 Content-Length，表示对应 GET 响应的内容长度。不能因为看到了这个字段，就要求服务器在 HEAD 响应后再发送这些字节。

curl -X HEAD 在请求行里确实发送 HEAD，但原来的传输方式没有相应改成只取响应头。在 HTTP/1.1 的某些响应与连接条件下，curl 会继续等待不会到来的正文；连接提前关闭时，也可能把它理解为剩余内容尚未读完。是否表现为长时间等待、超时或其他结束方式，还取决于响应头、协议和连接关闭行为，不能把“每次都挂住”当作必然现象。

这也解释了为什么只看抓包中的方法名称不够。两条命令都可以发出 HEAD，请求行一致并不表示客户端后续处理一致。

用 --head 同时选择方法和接收方式

只需要 HEAD 响应时，移除 -X HEAD，使用大写 -I 或长选项 --head：

curl --head --max-time 15 'https://app.example.com/status'

这里的地址是占位值，应换成允许诊断的实际路径。--head 选择 HEAD 请求并按不接收正文的方式处理；--max-time 15 给本次传输设置时间上限，避免排查命令一直等待。时间上限只是诊断保护，真正修正行为的是 --head。

小写 -i 的作用不同：它让 curl 把响应头也放进输出，并不把请求改成 HEAD，更不替代 --head。给原来的 -X HEAD 增加 -i，只能让响应头变得可见，不能解决等待正文的问题。

无需为了这个问题删掉服务端的 Content-Length、关闭所有长连接或缩短反向代理超时。它们会影响其他请求，也不能让客户端正确选择 HEAD 行为。

确认等待发生在哪一步

对同一地址做一次带诊断输出的 HEAD 请求：

curl --verbose --head --max-time 15 \
  'https://app.example.com/status'

查看是否已经建立连接、完成 TLS 握手、发出 HEAD 并收到响应头。若故障原本发生在收到响应头之后，而移除 -X HEAD、改用 --head 后可以正常完成，处理路径与这个问题一致。保留同一地址、认证和代理条件，避免同时修改多个变量。

诊断输出可能包含认证相关头部、Cookie 或带签名的地址，只在受控位置保存。不要为了让请求通过而加入 -k；证书校验失败需要按证书问题另行处理。

如果正确的 HEAD 请求仍在连接前等待，应继续检查对应的连接阶段。如果服务器直接返回 405 Method Not Allowed，说明当前资源拒绝该方法，不是这个“等不到正文”的问题；根据接口约定选择 GET 或修正服务端路由。HEAD 正常结束也不等于 GET 正文已下载并验证，不能用它确认文件内容完整。

排查时先保留最小命令，不增加自动重试，也不要用额外请求方法选项叠加修补。若脚本中还有上传、请求体或其他方法控制参数，应先拆清原来要执行的操作，而非只把 HEAD 拼进一个复杂命令。

修改脚本后的验收与回退

保存旧命令，替换脚本里的 -X HEAD，然后用脚本实际运行的账户和网络环境核对：请求方法仍是 HEAD、响应头能够输出、传输在合理时间内结束。还要检查 HTTP 状态码是否符合业务预期；curl 完成传输不自动代表服务返回 200。

这项修正不写目标资源，也不需要修改服务器配置。若脚本输出解析依赖旧格式，应同步核对，因为 --head 会输出响应头。回退时恢复保存的脚本，再按明确的请求需求修订；不要通过延长超时把错误的接收方式留在正式任务中。