curl 跟随 302 后仍发送 POST，但请求体为空

接口第一次收到完整的 POST 数据，返回 302 后，跳转目标收到的请求却没有正文。有时服务端日志仍写着 POST，让人以为数据在代理或服务端解析时丢失了。目标接口可能因此返回参数缺失，也可能返回 411；这些状态本身不能确定原因。

如果命令同时使用 -L、-X POST 和提交数据的选项，应先检查这几个选项的组合。下面的命令可能出现这一现象，地址和数据都是示例：

curl -L -X POST \
  --data 'name=demo' \
  'https://api.example.com/submit'

curl 跟随 301、302、303 时，默认会把原先的 POST 按 GET 方式继续请求，不再重发原来的 POST 正文。但 -X POST 又把发出去的方法名称固定成了 POST。于是，日志里的方法名还是 POST，并不代表 curl 仍在执行带正文的 POST 提交。

本文针对 curl 命令行的 -L / --location 行为。不要把结论直接套到其他 HTTP 客户端，或采用不同重定向控制方式的调用中。排查时保留实际 curl 版本、原始命令和每一跳响应；下文只在受控测试接口上使用无敏感信息的数据。

先看第一跳返回了什么

去掉 -L，让测试请求停在第一跳。提交数据已经会使 curl 使用 POST，不需要再写 -X POST：

curl --silent --show-error \
  --dump-header first-response.headers \
  --output first-response.body \
  --data 'name=demo' \
  'https://api.example.com/submit'

这仍然会向接口提交一次数据，所以不能拿创建订单、扣费或真实上传接口随意尝试。两个输出文件会写入当前目录，应使用空的测试目录，避免覆盖已有文件。

检查响应状态和 Location，确认它指向哪里：是补尾斜杠后的同一接口、新域名，还是提交完成后的结果页面。不能因为收到了 302 就假定下一跳也要求 POST。若第一跳没有返回重定向，本文的原因便不足以解释请求体为空，需要另查原始请求和服务端接收情况。

需要查看整条链时，可在受控环境中给原有命令加入 --verbose，对照每一跳的方法和响应头，并在目标服务的测试日志中检查实际接收的正文。诊断输出可能含认证头、Cookie 或其他敏感信息，分享前应清理；不要把线上凭据带入示例。

下一跳是结果页面时，删除 -X POST

有些接口接收提交后，重定向到一个用于查看结果的页面。这里下一跳用 GET 是预期行为，再强制发 POST 反而可能返回方法不允许或参数缺失。

保留数据选项和跟随重定向即可：

curl --location \
  --data 'name=demo' \
  'https://api.example.com/submit'

第一跳仍由 --data 发起 POST。遇到相应的 301、302 或 303 后，curl 按默认规则继续请求，去掉 -X POST 是为了不再强行覆盖后续方法名称。验证时应看到第一跳携带数据，结果页按接口设计收到 GET；不要要求结果页再收到一遍提交正文。

下一跳确实要接收同一份 POST 时，使用 --post302

如果接口约定 302 后仍需向目标提交同一份数据，可以使用专门控制这种行为的 --post302。先确认整个跳转链和所有接收方可信，再发送数据：

curl --location --post302 \
  --max-redirs 3 \
  --data 'name=demo' \
  'https://api.example.com/submit'

这里同样没有 -X POST。--post302 让 curl 在跟随 302 时保持 POST 提交行为，而不是只把请求行里的方法名称改掉。--max-redirs 3 是示例的跳转次数上限，应按已确认的接口流程调整；它不会验证跳转目标是否值得信任。

这个选项只对应 302。如果链中还有 301 或 303，后面仍可能改变行为。301 有对应的 --post301，303 有 --post303，但不应为了保住请求体就把三个选项全部加上。尤其是 303，通常就是让客户端去获取另一处结果，是否继续提交必须由接口约定决定。

如果你能调整接口，并且它确实需要客户端保留方法和正文，可以评估使用保留方法的 307（临时）或 308（永久）重定向。先验证调用方兼容性和整个流程，不要全站替换响应码。已知正式接收地址、且接口允许直接访问时，也可以直接请求那个地址，避免经由不必要的跳转提交数据。

方法名、正文和接收方都要核对

修正后，不能只凭目标日志出现 POST 或最后返回 200 就宣布成功。对需要重发数据的流程，应逐跳核对响应状态与目标 URL，在最终测试接口确认字段值和正文内容；对提交后查看结果的流程，应确认下一跳按约定使用 GET。

示例中的表单数据很小，便于核对。文件上传、流式输入和 libcurl 程序还涉及各自的数据读取与重放方式，不能仅凭这个命令行示例认定所有上传都能重发。若目标要求 JSON，也需要单独满足它的媒体类型和数据格式，--post302 不负责转换正文。

不要把 --location-trusted 当成请求体丢失的修复选项。它会放宽跨目标转发凭据等敏感数据的限制，解决的是另一件事。即便没有使用它，允许重发的业务正文仍可能随着跳转送往新的接收方，因此修改前必须确认 Location 链。

保留原命令和修改记录，先用不会产生业务副作用的测试接口验收。若新策略导致重复提交或错误目标接收数据，应撤回新增的重发选项，或临时停止自动跟随并检查响应。撤回参数只能影响后续调用，已经发生的提交仍需按业务流程处理。