网站返回码4002：3处源头逐个排

4002 这串数字，第一眼就不像正经的 HTTP 状态码。常规的状态码都是三位数，404、403、500、502 翻来覆去就那几十个；蹦出个四位数，基本能断定是应用层自己定义的，或者面板、网关、防火墙给你打上的标记。所以碰上网站返回码4002，别急着重启服务器，也别一上来就怀疑被攻击——先弄清楚这个码是谁写进响应的。各家产品对四位数的定义差别挺大，具体含义以服务商或官方页面说明为准，网上那些对照表不一定对得上你这套环境。

网站返回码4002的三处源头，按顺序排

我习惯把它拆成三处：源站程序、中间层、调用方。这三处出的问题长得像，证据却不一样。源站程序抛出来的码，响应体里往往带一段自己写的内容，可能是 JSON 也可能是几行纯文本；中间层拦下来的，多半是统一的拦截页，或者干脆一片空白加几个响应头；调用方那头的问题更挑场景，往往只在某个接口、某组参数下冒出来，首页刷新反而正常。所以先看“什么时候出现、谁受影响”，比盯着码本身有用得多。

先确认是谁在报这个码

拿命令行去问，比在浏览器里按 F5 一百次靠谱。对着出问题的地址跑一次 curl -I，看响应头里的 Server、Via、X-Cache、X-Powered-By，有没有 CDN、负载均衡、网关的痕迹。然后把域名临时指到源站 IP，或者从内网直连绕开前面那几层，同样的请求再来一次。两边结果不一样，问题就落在中间层；两边都吐同一个码，那八成在源站。

顺手记一下请求的时间点，后面翻日志能对上。这个小习惯比什么都值钱。

源站程序这头，日志比猜谜快

应用日志、nginx 的 access.log 和 error.log，全都翻一遍，grep 4002 直接搜。有些框架会原样把自定义码写进访问日志的状态位，看着别扭，但正好帮了你——调这个接口的请求是不是全堆在同一个时间点、同一个客户端 IP，一目了然。

再往下查：数据库连不上、缓存服务挂了、某个扩展没装、路由规则没匹配上，程序常常不直接报错，而是包成一个业务码返回给前端，页面上就成了 4002。这类情况日志里一定有痕迹，耐着性子往下读几十行，比在群里问一圈强。

中间层拦截：WAF、CDN、反向代理

防火墙和 CDN 都喜欢用自己的编号，区分“我拦的”和“源站真坏了”。同一个页面，换个干净网络、正常浏览器打开就正常，带某个参数、某个 UA 就报 4002，基本可以往规则命中的方向想。去看 WAF 的命中记录、CDN 的回源状态，别只盯源站。这类拦截有时还挺“聪明”：请求头缺了、带了敏感字符，就直接给你打回去，看上去像程序出错。不同服务商的编号不一致，遇到没见过的码，还是查它自己的文档。

鉴权、参数、请求方法，这里最容易背锅

接口类的 4002 挺常见是 Token 过期、签名算错、时间戳超出允许范围、Content-Type 写错、把 POST 写成了 GET。页面上的表现像“服务器出毛病了”，实际是调用姿势不对。拿 curl 或者 Postman 手工构造一次最小请求，参数一个一个加回去，很快能试出来是哪个字段惹的。

跨域也常被算进来。浏览器的预检请求被拦，控制台报的是跨域，服务端日志里落的却是自定义码，两头说法不一样，对着看才能对上号。

顺序别乱，从最近动过的地方下手

上线时间、配置变更、证书更换、安全规则调整，出问题的时间点对得上哪一个，就先查哪一个。我踩过这种坑：全量排查折腾了大半天，最后发现是当天新加的一条拦截规则。顺序上先做减法，能绕开的层先绕开，能用最小请求复现的先复现，别一上来就闷头改代码。

还有个容易漏的点——缓存。错误响应被 CDN 缓存住了，本地怎么改都不生效，一刷缓存立刻正常。看着像灵异事件，其实就是缓存没清。

几个容易走偏的判断

重启确实能让一部分问题暂时消失，但源头没找到，过一阵还会回来。看到码就以为被黑也不靠谱，先看流量特征和请求路径再说。另外别把 4002 当成 400 或者 404，一个是参数有问题，一个是资源不存在，跟自定义码完全是两码事。至于欠费、被停服这类猜测，去服务商控制台看状态，以官方通知为准，别靠猜。

真要我给个顺序：先复现（固定路径、固定参数），再分层（绕开中间层做对比），然后翻日志（拿关键词 grep），最后才动配置和代码。这四步走完还没头绪，就把完整的请求头、响应头、时间点整理好，交给服务商或者程序方，让他们对着自己那套编号查——比你在群里问“4002 到底是啥”有用得多。顺手把这次的排查过程记下来，下次同类问题能省一半时间。