API经过代理返回415，即使业务字段看似正确，也应先核对线上实际表示，再换出口。JSON、网址编码表单与multipart可承载相似值，却需要不同序列化和元数据。
本文是自有或明确授权端点的小型验收方案，未报告实测兼容结果；代理传输了正文，不代表目标就支持该格式。
一、记录端点契约
MDN说明415 Unsupported Media Type是拒绝不支持的请求格式，可能涉及Content-Type、Content-Encoding或正文检查。单凭状态不能确定哪个字段或组件拒绝。
列出准确网址、方法、API版本、允许的请求媒体类型及参数、请求内容编码和最小有效合成对象，依据目标文档及负责人确认。存在Accept-Post等响应提示时可参考，缺少提示不能当作猜格式的许可。
分清Content-Type描述本请求正文表示，Content-Encoding声明已应用的内容编码，Accept表达响应偏好。改Accept不会把请求序列化成支持的格式。
二、检查实际请求边界
- 选不触发付款、邮件或客户数据操作的测试接收端。
- 记录生效目标网址和方法，在客户端及授权接收端获取遮蔽后的元数据。
- 核对正文实际字节或安全合成样本，不只看序列化前的内存对象。
- 对比媒体类型、参数、内容编码与服务端所选解析器。
- 保存案例ID、客户端版本、正文长度与合成摘要，遮蔽凭据和个人信息。
共享客户端默认头可能在调用代码换正文格式后仍保留。检查拦截器和包装层合并后的最终头；发生重定向时，查看真实接收跳的方法与正文，不能假定保持原样。
三、先建立有效对照
有文档的JSON端点，用客户端支持的JSON序列化器生成无害样本，发送规定媒体类型，确认目标解析出预期字段及契约成功结果。2xx却忽略正文或得到空对象，不算对照通过。
再在测试环境仅改变同一小正文的声明类型，按端点契约记录预期拒绝。不能要求所有错误输入都返回415；语法或字段校验失败可能有不同的文档响应。
负例后恢复有效对照。若它也失败，先查状态、路由及配置，不将变化直接归于媒体类型。
四、浏览器FormData保留边界控制权
目标明确接收multipart时，用正确字段名构造小型FormData。MDN建议通过Fetch或XMLHttpRequest发送时，让浏览器设置Content-Type，确保边界与生成正文一致。
本请求移除冲突的全局JSON头或手写multipart头，不复制旧跟踪的boundary给新正文。非浏览器客户端应按自身文档使用multipart构造器，并将其输出头与正文视为配套结果。
顶层multipart类型与文件部分自己的类型、文件名不同。改扩展名或部分标签不会转换文件字节；样本仍须符合目标文件政策。
五、内容编码须整体调整
只有目标明确支持请求压缩，才单独测试实际编码后的有效样本及匹配声明。普通JSON标成已压缩不算；保留压缩字节却删编码头，也仍不匹配。
契约允许时先跑无压缩对照，再一起调整字节编码与声明，核对接收端解码后的合成字段。同时记录正文大小、解析限制及预期校验结果，避免把其他拒绝悄悄归成415。
六、比较线路并修正请求
批准基线与代理各用独立重置案例，固定客户端版本、目标、格式及样本，对照接收证据。HTTPS隧道中不能假定转发代理可检查加密目标正文；先识别自有TLS终止和解析层，再定位传输组件。
98IP动态住宅IP产品页适合了解授权地区API测试的接入产品，通过API配置页核对当前连接与账户选项。产品接入不定义目标接受的表示，也不证明特定序列化器兼容。
- 规定有效表示：目标解析预期值。
- 同正文冲突类型：观察到契约拒绝。
- 浏览器FormData：生成边界与正文一致。
- 文件部分：内容、类型、文件名满足政策。
- 支持的内容编码：解码后字节与声明相符。
- 恢复对照：修复有效且未改无关线路设置。
这些案例尚未执行。一起修正序列化器及元数据，再用新合成案例验证一次。不要换出口或重复发送未改变的不支持格式；写入结果未知时，按目标回执或读回规则查明后再考虑提交。
FAQ与完成清单
只改头能修415吗？仅当现有字节已符合文档表示，否则正文也要正确生成。
同一个对象就等于同一请求吗？不同序列化器可把相似应用值变成不同表示。
- 契约与有效对照已记录。
- 检查真实正文和最终合并头。
- 保留FormData边界控制权。
- 区分请求编码与响应偏好。
- 核对接收字段和最终副作用。
- 仅保存授权合成样本，尝试有界，不承诺未测兼容性。