逆向站内接口时，先给请求头建基线再猜参数

把华为云开发者站点的几个内部接口抄成 Python 时，反复遇到同一类现象：浏览器里正常返回的接口，脚本调就是 HTTP 500，响应体还是网关的统一错误页，没有任何字段提示。

一、500 常常是缺头，不是服务端挂了

成长中心走的网关在 devdata.huaweicloud.cn 上，路径里嵌了内部服务前缀。同一份 body，只补两个头就从 500 变 200：

Content-Type: application/json;charset=UTF-8
Origin: https://developer.huaweicloud.cn

这类网关会在校验失败时直接抛未捕获异常，而不是返回 4xx 加错误描述。所以拿到 500 时先看自己的头，不要立刻怀疑接口下线。

二、csrf 头的取值位置有三种

常见误解是把 Cookie 里叫 csrf/csrf-eco 的值直接抄进请求头。实际见过三种情况：Cookie 同名值即正确值、由某个 GET 接口的响应头现给、以及两者都要带。华为云社区/成长中心属于第二种：

r = s.get("https://devdata.huaweicloud.cn/api/get-ainfo")
s.headers["csrf"] = r.headers.get("csrf") or ""     # 在响应头里，不在 cookie 里

写通用客户端时，把「取 CSRF」做成一次显式请求，并且允许失败回落到 Cookie，比硬记某个 Cookie 名字要稳。

三、命名风格不统一，以实际调用为准

同一体系里既有驼峰（pageNum/pageSize）也有下划线（page_no/page_size、experiment_id），甚至报错文案里的字段名和真正生效的字段名不同。判据不是看报错，而是看响应是否进入了业务分支——把可疑字段改成下划线试一次，返回从「参数为空」变成「资源不存在」，就说明解析已经正确。

四、GET 与 POST 不要想当然

积分余额这类简单查询看着像 POST，实际是 GET：GET .../growth/bonus-beans。用错方法时网关可能返回 404 也可能返回空 body，不会明确说不支持。所以定位应当从同源页面的真实请求里取方法+路径+头，一次抄全，而不是从字段名去猜接口设计。

小结

排查顺序固定下来会省很多时间：先补 Origin/Referer 与 Content-Type（对付 500），再确认 CSRF 取值来源（对付 unequal/未登录），然后按目标 host 筛 Cookie（对付随机 CSRF 失败），最后才是参数命名与方法。前三步都是头的问题，却常常被当成参数问题反复试。