POST 请求会携带请求体：登录时提交的账号密码、表单里填的资料、上传的文件，都装在请求体里——代理IP场景的接口调试里，请求体与它的类型头是最常被检查的一对。但服务器拿到一堆字节时，怎么知道它们是表单、是 JSON 还是文件？它看 Content-Type 头——代理IP链路调试中这个头就是请求体的报名表，类型对不上往往是报错源头。
请求体本身只是一串字节，离开了类型的说明就没有意义；Content-Type 头给这串字节贴上标签，服务器才知道该按什么规则去解析。没有报名表的内容，服务器只能猜测或拒绝，代理IP场景调试接口时这也是高频出错点。
这篇讲 Content-Type 头：它替请求体报什么名、常见的类型有哪些、报错名会出什么问题。
Content-Type 在报什么名
Content-Type 的值是标准的媒体类型格式：大类/小类，比如 text/html、application/json、image/png。它告诉服务器「我这串字节是什么格式」，服务器照此选择解析方式——是当文本读、当结构化数据解析、还是按二进制存成文件。
常见的几类：表单提交用 application/x-www-form-urlencoded（键值对编码）或 multipart/form-data（含文件的混合表单），接口数据用 application/json，普通文本用 text/plain。每一种类型都对应一套服务器端的解析约定。
报错名会怎样
类型与实际内容不符时，服务器会按错的类型解析：把 JSON 当表单读会解析出乱码，把文件当文本读会损坏数据。多数框架会在解析失败时报错，表现就是接口「收到但处理不了」——排查这类问题，第一眼就该看 Content-Type 与请求体是否匹配。
与 Content-Type 搭配的还有 Content-Length：它声明请求体有多少字节，服务器据此知道读多少算完。类型加长度，一个管怎么读、一个管读多少，两者齐了，请求体才算完整交代清楚。
把请求体与 Content-Type 的关系记成一句话：体是内容，类型头是内容的说明书——类型对了，服务器才能把字节变成它该是的东西。代理IP链路上调试上传与提交类接口，最常踩的坑十有八九在类型与内容不匹配。
Content-Type 是请求体的报名表：媒体类型告诉服务器怎么解析，搭配 Content-Length 声明长度——类型与内容匹配是接口畅通的前提。
到这一篇，请求头的主要成员与机制都过了一遍：结构、格式、家族、自动头、协商、缓存、Host、内容类型。最后把知识串起来——找一次真实请求，把它的头逐行读给你看。
请求体与响应体的类型声明遵循同一套媒体类型体系：Content-Type 头在请求里给体报名，在响应里给内容定性。两处写法一致、规则互通，学会一边就懂另一边，这也是「内容家族」横跨问答两端的原因。
选对 Content-Type 的实用口诀：纯文本用 text/plain，结构化数据用 application/json，表单键值用 urlencoded，含文件上传用 multipart。四种最常见，记熟它们，日常接口对接基本不会在类型上报错。
Content-Type 之外还有配套的字符集参数：application/json; charset=utf-8 中的 charset 声明编码，避免中文乱码。类型管格式、字符集管编码，两者一起写全，服务器解析中文内容时才不会出错——这个细节在跨国访问与代理IP场景中尤其值得注意。
请求体与类型头是一对搭档，理解这对搭档，接口对接的多数问题就迎刃而解。代理IP场景调试提交类接口时，把 Content-Type 与请求体放在一起检查，比单独盯任何一方都有效——类型与内容匹配，服务器才能读懂你的意图。