小红书
x-s 的算法本体进不了浏览器 —— 这里只有形状检查；XYW 信封能拆一层 JSON
小红书签名验证
小红书要验的东西是一组头部：x-s、x-s-common、x-t、x-xray-traceid，部分接口再加 x-b3-traceid。验证器对每个头做形状检查，x-s 是 XYW_ 格式时还能拆开信封的一层 JSON。
前缀 / 长度 / 字符集 —— 算法本体在 Node 侧，进不了浏览器
签名输入
判定
全部头部的形状都对。
56、signType x2、appId xhs-pc-web这里只有形状检查。x-s 的算法本体是同仓 platforms/xiaohongshu/sign/xhshow/（@ikenxuan/xhshow-ts 的内联副本，依赖 Node 的 crypto 与 zlib），进不了浏览器 —— 所以这一页证明不了「算法对」，只能证明「形状对」。全量校验在 Node 侧跑它的测试
先说实话：这个平台的验证强度是四家里最弱的
x-s 的算法本体是 @ikenxuan/xhshow-ts 的内联副本（在同仓 platforms/xiaohongshu/sign/xhshow/），那条依赖链用了 Node 的 crypto 与 zlib，进不了浏览器 —— 而文档站的验证器必须跑纯代码。所以这一页证明不了「算法对」，只能证明「形状对」。全量校验在 Node 侧跑它的测试（v6 对照快照一字不变）。
形状本身仍有鉴别力：前缀区分两套协议、x-t 的时钟范围能暴露「拿秒当毫秒」这类错、traceid 的长度与字符集是硬约束。
两套 x-s 格式
端点当前一律用 XYS_
曾按「user_posted、user/otherinfo 等数据接口自 2026-03 起以 HTTP 406 拒收 XYS_、
必须换 XYW_」实现 —— 该说法未经线上验证、且已被真机实测推翻：2026-10-11 同一游客
cookie 下，user_posted 用 XYW_ 回 HTTP 461 空 data、用 XYS_ 回 200 + 真数据。
全部 13 个端点现在都走 XYS_；XYW_ 信封仍能被验证器识别与拆解，但照「必须用 XYW_」写会踩 461。
XYW_ 的信封是标准 base64 包着的一层 JSON，浏览器里就能拆：
{
"signSvn": "56",
"signType": "x2",
"appId": "xhs-pc-web",
"signVersion": "1",
"payload": "<真正的签名载荷，不可还原>"
}信封字段是签名器自己报告的元数据（算法版本、平台标识），payload 才是加密载荷。信封对不上口径（比如 appId 不是 xhs-pc-web）是能被形状检查抓到的错；payload 内部对不对，只有 Node 侧的测试知道。
各头部验什么
| 头部 | 形状约束 | 备注 |
|---|---|---|
x-s | XYS_ / XYW_ 前缀 + 非空 | XYW 信封可拆一层 JSON |
x-s-common | 非空 | 压缩+编码的不透明串，底下没有明文可找 |
x-t | 13 位毫秒时间戳 | 能暴露「拿秒当毫秒」 |
x-xray-traceid | 32 位十六进制 | 追踪头；缺失会让部分接口 406 |
x-b3-traceid | 16 位十六进制 | userNoteList 等接口专用 |
amagi 侧怎么组织
九个签名器注册名（xhs-post / xhs-get / xhs-get-trace / xhs-post-rap / xhs-get-rap / xhs-live-get / xhs-get-xyw / xhs-post-xyw / xhs-get-xyw-trace）只做「注册名 → step 清单」的映射，算法唯一实现在 platforms/xiaohongshu/sign/steps.ts，依赖方向单向。签名路径取 signPath（接口路径，与完整 URL 无关）；x-rap-param 例外，要 host + path。机制细节见签名如何组织。
下一步
为什么签名需要被验证
平台对签名是抽样校验的，「请求成功」证明不了任何事；四个平台的验证器与它们各自的验证强度
抖音
a_bogus / X-Bogus / secsdk / 访客令牌 —— 四个验证器，以及各自的常量表与边界
B站
w_rid 重算比对与 av/bv 互转 —— 两个完全可验的纯函数签名
快手
$HE_ 段可整段拆开（时钟与计数器原样读回）；HUDR 段拆不开，说了就是答案
最后更新于 2026-10-23