代理返回 400 怎么排查：请求行、请求头、Host、编码和代理改写

代理返回 400，表示某一层服务器认为收到的请求存在语法、格式或路由上下文问题，无法按当前形式继续处理。它不等于代理失效，也不能仅凭状态码判断错误来自代理入口、上游网关还是目标站。最有效的排查方式，是先固定同一请求，再比较直连、经过代理和最小化请求之间的差异。

开始前保存请求方法、完整 URL、HTTP 版本、请求头、正文长度与编码、代理协议、代理认证方式、出口 IP、时间和请求标识。敏感认证值只记录字段是否存在及脱敏摘要。不要在原因不明时反复切换出口、批量重试或添加更多请求头，这会让证据变得更难比较。

先确认它确实是 400

400 是通用的错误请求；401 与目标站身份认证有关；403 表示请求已被理解但被拒绝；404 指向资源或路由不存在；407 是代理认证要求；414 常见于请求目标过长；431 常见于请求头字段过大。若实际状态码是 403，可转入目标站拒绝、出口与请求条件检查；若是 404，应按地址、重定向和主机路由路径处理。

• 通过条件：原始响应状态码、响应头和响应体都确认是 400，且能保存一次完整复现。
• 失败条件：客户端把代理握手、TLS 或认证错误统一显示成 400。
• 停止条件：无法确认响应来源，或继续测试会提交表单、修改业务数据。

第一步：确认 400 由哪一层返回

比较 Server、Via、请求标识、错误页结构、响应时间和代理日志。代理入口、企业网关、内容分发节点、应用网关与目标应用都可能返回 400。把同一时间窗口的客户端记录与状态码、出口和请求阶段日志字段放在一条记录中，先确定请求是否已经到达出口和目标站。

第二步：用最小请求建立基线

选择一个已获准、不会修改数据的地址，只保留方法、URL、必要的 Host 和标准客户端标识。先在直连路径复现，再使用同一出口和同一代理入口复现。随后每次只恢复一个请求头、查询参数或正文部分。最小请求成功而完整请求失败，说明问题更可能在新增字段或正文；两者都失败，则先检查入口、路由和协议。

第三步：逐字符检查请求行和 URL

检查方法与请求目标之间的空格、HTTP 版本、绝对形式与源站形式、路径中的空格和控制字符、百分号编码、重复问号、无效转义及不可见字符。使用 HTTP 代理时，客户端与代理之间可能使用绝对 URL；建立 HTTPS 隧道后，隧道内通常发送面向目标站的路径。不要把两种形式混在同一层。

复制可见 URL 不足以排除问题，应保存发送前的字节表示或客户端调试输出。若修正一个字符后最小请求稳定通过，再恢复其他字段；若需要猜测未公开路径或枚举资源，应停止并回到正式入口。

第四步：核对 Host、端口和 SNI

URL 域名、Host、显式端口、CONNECT 目标与 TLS SNI 应指向同一个预期服务。重复 Host、空 Host、Host 中带路径、非默认端口遗漏或 SNI 与 Host 不一致，都可能让网关无法选择正确站点。HTTPS 连接还应按SNI、证书和协议链检查顺序确认隧道目标。

这里只核对正式配置，不应通过伪造 Host 或替换 SNI 去尝试访问未获准服务。若目标域名或端口来自临时配置，先由服务负责人确认正确入口。

第五步：清理重复、冲突和过大的请求头

重点检查 Content-Length 与 Transfer-Encoding 是否同时出现，多个 Content-Length 是否不一致，Connection 或 Proxy-Connection 是否被错误转发，以及请求头名称、冒号、换行和字段值中是否含控制字符。虽然过大的请求头更应返回 431，但部分网关仍可能使用 400，因此也要记录单个字段与总请求头大小。

删除非必要自定义头后逐个恢复。不要把 Proxy-Authorization 发送给目标站；代理认证异常应按407、凭据、白名单、协议和端口检查处理，而不是把认证字段混入目标请求。

第六步：检查正文长度、内容类型和传输编码

带正文的 POST、PUT 或 PATCH 请求要同时核对 Content-Type、Content-Length、字符集、边界字符串与实际字节数。压缩、分块传输、客户端自动重试或中间层重新封装，都可能造成声明长度与实际正文不一致。先用空正文或最小合法正文建立基线，再逐段恢复内容。

若请求会修改业务数据，不要靠重复提交验证。应使用测试环境、幂等接口或由业务负责人提供的低风险样本；无法确认幂等性时立即停止。

第七步：排除字符编码和不可见字符

路径、查询参数、JSON、表单和请求头可能分别使用不同编码规则。检查 UTF-8、百分号编码、加号与空格、换行风格、字节顺序标记及从表格或聊天工具复制的不可见字符。声明为 JSON 的正文必须是合法 JSON，字段名和字符串引号也要逐项确认。

可将失败请求与成功样本转成十六进制摘要做差异比较，但日志中不得保存明文密码、令牌或完整个人数据。只保留定位所需的脱敏片段和哈希。

第八步：检查代理或网关是否改写了请求

比较发送前、代理入口记录和目标侧记录，观察 Host、Forwarded、X-Forwarded-For、Accept-Encoding、Connection、内容长度和请求目标是否变化。正常的代理行为也可能触发严格网关的格式检查，因此判断依据应是实际差异，而不是假定“经过代理就一定不变”。

若只有某一代理协议或某一客户端版本会改写字段，固定单一变量复测并保留版本号。若修改涉及共享网关规则，不要在生产流量上直接试错，应先转给网关负责人。

400 排查决策表

什么时候可以重试，什么时候必须停止

只有在已识别并修正一个明确格式问题后，才做少量受控复测。400 通常不是等待几秒就会自行消失的临时网络错误，不应直接套用超时或限流重试。需要定义次数、间隔和终止阈值时，可参考超时、限流与连接异常的重试边界，但要把格式错误与临时故障分开。

• 通过条件：最小请求和完整请求在同一条件下连续得到预期响应，且日志字段一致。
• 失败条件：恢复某个字段后稳定出现 400，或不同层记录的请求内容不一致。
• 停止条件：需要提交非幂等请求、修改共享网关、暴露敏感值，或结果持续波动且无法归因。

团队交接要记录什么

交接记录至少包括原始 URL、方法、HTTP 版本、代理入口与协议、出口 IP、响应来源、请求行摘要、Host、端口、SNI、请求头清单与总大小、正文类型和长度、字符集、首次异常时间、最小请求结果、直连对照、代理改写差异、修正项、复测结果、负责人和下次复核时间。需要更换已批准线路时，先确认代理资源范围，再按相同字段验收，不能把“换出口后偶尔成功”当作根因结论。

最终判断

代理返回 400 的核心不是立即换 IP，而是确认哪一层拒绝了哪一种请求表示。先定位响应来源，再用最小请求核对请求行、Host、请求头、正文与编码，最后比较代理前后的实际差异。只要证据不足、请求会修改业务数据、敏感字段可能泄露或共享网关需要变更，就应停止自动重试并转人工确认。