# CLOVE 后台与官方系统，怎样连起来？完整证据链、九个追问与原始档查证

**一个管理网址，可以被说成仿站。一张截图，可以被质疑剪裁。但当公司公告、官方程式、Google 专案设定与较早的网页封存，逐段接上同一条线，问题就不能只靠一句「与我们无关」带过。**

这篇把来源摊开。你可以不接受本鹦鹉的判断，但应该有机会亲手核对：我们读到甚么、哪些资料互相吻合，以及哪一段仍需要平台拿出纪录。

[先读调查主文](/cn/guides/clove-scam/) · [直接下载原始资料](#downloads) · [自己动手查证](#verify)

查证基准：2026 年 9 月 5 日。本文所列的九种说法是预先分析的可能解释，**并非 CLOVE 已经作出的回应**。

## 先用一间店，把整条线讲明白

想像一间店有个你未见过的后房。我们要做五件事：

1. **看店主介绍。** 公司自己有没有说，这个品牌是自己的服务？
2. **对表格编号。** 店面与后房的资料，有没有写同一个部门号码？
3. **查登记地址簿。** 提供系统的 Google，是否也把两个地址列在一起？
4. **翻旧副本。** 较早由别人保存的资料，是否与今天看到的一样？
5. **问工作做过没有。** 手册写有一项工作，还要拿值班纪录，才能知道何时做过。

前四步已有可以逐份打开的材料。第五步，要靠实际执行与交易纪录。**同一间店的关系接上了，不等于已经看见谁把哪份奖品交给谁。**

「店、后房、地址簿」是帮助理解的比喻。下面保留真实来源：地址簿对应系统的授权跳转清单，不能当成店契或员工名册。

<details>
<summary>打开原始资料与详细对照</summary>

## 第一条线：公司自己把产品连了起来

[TrustHub 官网](https://trusthub.jp/)把「クローブオリパ」列为旗下服务，连到 `oripa.clove.jp`。[Apple 的 Clove 页面](https://apps.apple.com/hk/app/clove/id1631035982)列出供应商 TRUST HUB, K.K.；[公司原发公告](https://prtimes.jp/main/html/rd/p/000000001.000059394.html)及 [SMBC 2024 年 10 月 15 日公告](https://smbc-cf.com/news/data/2024/10/news_20241015.pdf)，也支持 TrustHub 与 Clove 产品的关系。

这一步回答的是「公司与产品有没有关系」。接着，才轮到管理网站。

## 第二条线：官方前台与管理登入页，指向同一专案

把 [clove.jp 官方程式](https://clove.jp/_next/static/chunks/pages/_app-087b8d6889c74648.js)与[管理登入页程式](https://clv-admn-next.vercel.app/_next/static/chunks/pages/signIn-ac96f3ec7e9b1cbe.js)放在一起，能找到相同的公开 Firebase 设定：

| 识别项目 | 两份程式的共同值 |
| --- | --- |
| 专案 ID | `clove-v2-prd` |
| App ID | `1:385949280493:web:224ed7999dd0740cfdc4e4` |
| 认证网域 | `clove-v2-prd.firebaseapp.com` |

两份程式的公开设定 key 杂凑也相同，完整对照在身份包的 `identity-chain-sources.json`。这些是公开应用程式的专案识别资料。[Firebase 文件](https://firebase.google.com/docs/projects/api-keys)说明，这类 key 用来识别专案；本身不能当作后台登入权限。

有人可以复制一段公开程式。所以，调查不能停在「设定一样」。下一步才是这次补件的关键。

## 第三条线：Google 回传的清单，也列了管理网域

2026 年 9 月 5 日 03:56 UTC，分别使用上述两份程式的公开设定识别资料，从 Google 的公开专案设定端点取得 HTTP 200 回应。两份回应逐位元组相同，专案编号都是 `385949280493`。

其中的 `authorizedDomains` 同时包括：

- `clove.jp`
- `oripa.clove.jp`
- `clv-admn-next.vercel.app`

**关联已经延伸到 Google 回传的专案设定。** 要把这个管理网域解释为与官方系统毫无关系，就必须同时交代：它为何出现在这个专案的授权网域清单。

这个栏位的用途也要说准：[Google 定义](https://docs.cloud.google.com/identity-platform/docs/reference/rest/v1/TopLevel/getProjects)是登入元件可跳转的授权网域。它支持专案设定层面的技术关联，并不列出公司法律持有人、Vercel 帐户持有人或当日操作员。要查到谁加入网域、何时加入、谁控制部署，就要接上 IAM、设定变更与部署历史。

两份 Google 原始 JSON 都在身份包的 `public-captures/`，共用 SHA-256：

```text
7a574650bdfa74f1460bb31500d691ff8d6a386660b56cfe21239675e936228b
```

## 第四条线：较早的第三方封存，让版本有迹可循

[Wayback 在 2026 年 8 月 23 日 02:14:55 UTC 保存的官方 JS](https://web.archive.org/web/20260823021455id_/https://clove.jp/_next/static/chunks/pages/_app-087b8d6889c74648.js)，与 9 月 5 日保存的官方 JS 逐位元组相同。这表示这份官方程式并非只在本次整理时才出现。

它的 SHA-256 是：

```text
df59333f5c2ff7ff223e7b321575fd86c6d6aaaa86622f84fa9946ecf70204fa
```

[管理登入 JS 的 9 月 5 日封存](https://web.archive.org/web/20260905034032id_/https://clv-admn-next.vercel.app/_next/static/chunks/pages/signIn-ac96f3ec7e9b1cbe.js)也与保存原件相同。SMBC 与公司公告另有可读副本；Apple 副本可读，但与本次下载的内容杂凑不同，不能把它写成完全相同的原件。

较早的官方 JS，不能替今天的 Google 设定补上整段历史。每份材料的时间，必须各自保留。

**目前可以连起来的是：公司 → Clove 产品 → 官方程式与管理程式的共同专案 → Google 清单中的管理网域。** 对这条链提出异议，需要指出哪一份来源有错、哪一段推导不成立。

## 身份接上了，再看后台到底做甚么

日本、v2、香港及两个美国库存管理版本，都有用户分配排程的介面实作。[日本管理程式](https://clv-admn-next.vercel.app/_next/static/chunks/pages/oripa/list-0f33ebdda397cc72.js)包含选取商品、输入检查、提交排程及读取结果；[共用操作定义](https://clv-admn-next.vercel.app/_next/static/chunks/2902-1b4cb7dff6c6ef54.js)列出 `scheduleAssignGuaranteedWinOripaUsers`。[跨版本原始连结见主文](/cn/guides/clove-scam/)。

这次完整上下文也保留了「アド确定オリパ」提示。该段呼叫提交 `oripaIds`，即卡池／商品 ID；没有在这段操作中输入任意中奖者的用户 ID。资格分配是需要查清的具体解释，不能被函数英文名称盖过。

**身份关联，回答「这套程式与谁的系统相连」。执行纪录，才回答「它做过甚么」。** 这是同一条调查的下一段，不能用前一段冒充后一段。


</details>

## 九种可能说法，逐项对照

以下每一项都列出现有材料能追问的地方，以及能把争议真正说清楚的纪录。平台日后若回应，应另附原文、日期及出处，不把下列假设改写成它说过的话。

### 1.「这是仿站，与我们无关」

像说「后房不是我的」。那就请把相同编号和地址簿上的连接一起解释。

<details>
<summary>打开原始资料与详细对照</summary>

复制品牌外观，解释不了整条关联。官方 JS、管理 JS 的共同专案，加上 Google 回应中的管理网域，使「完全无关」需要具体说明。可核对的答案是 Vercel 专案及团队控制纪录、Google 授权网域变更历史，以及公司与开发商的部署关系。单说「不是我们的」，没有回答这些资料。

</details>

### 2.「那只是外判、旧版或测试环境」

像说「这是外判的旧工作室」。可以，请拿出它何时使用、替谁工作的纪录。

<details>
<summary>打开原始资料与详细对照</summary>

[管理共用程式](https://clv-admn-next.vercel.app/_next/static/chunks/pages/_app-6827489be620db89.js)指向多个 `api.prd.*.clove.jp` 主机，并与官方页面共用专案设定。这让环境用途成为可查的问题。`prd` 命名本身仍不能证明正式执行；版本对应、部署日期、路由配置及流量纪录，才可以判定哪段时间服务甚么用途。

</details>

### 3.「截图或程式被你改过」

像说「你换了那张纸」。那就把纸的原件与别人保存的副本，一张张对。

<details>
<summary>打开原始资料与详细对照</summary>

请指出档案、位置及差异。读者可以把公开包内的原始位元组、SHA-256、当时来源及第三方封存互相比对。相符的 Wayback 副本增加了独立比对点；时间戳则固定所签杂凑。杂凑只证明档案是否一致，时间戳不会替文章的推论背书。

</details>

### 4.「只是没用到的程式」

像说「手册有写，但从未做过」。查值班簿与工作纪录，才知道。

<details>
<summary>打开原始资料与详细对照</summary>

目前展示的是候选商品查询、介面检查、操作呼叫及回应处理连成的流程，足以追问用途。要查是否执行过，仍要看后端 resolver 版本、工作建立与完成纪录，以及相应资料表。介面已整合与曾经执行，应各用对应资料回答。

</details>

### 5.「只是正常的アド确商品资格分配」

像说「我只是派优惠场的入场券」。那就看当时公开的入场规则，与实际派给谁是否一致。

<details>
<summary>打开原始资料与详细对照</summary>

这个解释有上下文支持，必须正面核对。请列出选人规则、资格条件、适用商品 ID、购买限制、付款前的公开说明，以及分配结果；再说清楚它与普通奖池的边界。若纪录显示它只分配已披露的优惠资格，判断就应跟着纪录走。若用途超出披露范围，争点也会变得明确。

</details>

### 6.「没有指定得奖者，也没有付费玩家受影响」

要证明某个客人受影响，得拿那个人的收据与结果来对。现在还没有这条完整对照。

<details>
<summary>打开原始资料与详细对照</summary>

目前公开材料没有一条完整的交易对照，足以直接驳倒这句话。需要把商品 ID、执行时间、工作 ID、分配结果、付款及得奖纪录连起来，并与玩家付款时看到的条件比较。公开版本应匿名化；完整资料可交由获授权的独立审查者核对。不能把一个函数名，写成每个玩家必输的证明。

</details>

### 7.「封号只是处理多帐户，没有灭证」

请人离店，与烧掉他的收据，不是同一件事。要查的是原因与纪录还在不在。

<details>
<summary>打开原始资料与详细对照</summary>

[官方条款](https://clove.jp/terms)确有针对多帐户等情况的帐户措施。因此，封号本身不能证明报复或灭证。争议个案需要措施时间、具体理由、申诉处理，以及交易资料的保存、备份与汇出安排。失去登入入口，与平台删掉所有纪录，是两件需要分别查证的事。

</details>

### 8.「只是 AI 分析错误」

不用相信分析者的名字。打开原件；看错了就改，也让其他人接着查。

<details>
<summary>打开原始资料与详细对照</summary>

AI 报告不能替代来源。这篇提供的是可下载的公开程式、设定回应及封存副本；任何人都可以指出误读。此前把 `adminSoftDelete` 归到指定日本 list 档的引证，已撤下：在该档及已解码历史副本中未找到此字串。更正一个错误，同时也要求其余证据逐项受检验。

</details>

### 9.「系统已经改了」

今天换了新手册，旧手册还是旧手册。新旧各写甚么，要按日期对。

<details>
<summary>打开原始资料与详细对照</summary>

新版本可以改变今天的功能，不能改写旧版本曾公开提供的内容。比对时请附更新日期、版本、修改范围及部署纪录。删除或修改本身，也不能自动当作认错、报复或曾经操控抽奖的证据。

</details>

<h2 id="downloads">原始资料、公开分析与封存证明</h2>

资料直接放在本站。两个 ZIP 是供读者查证的公开重整版：原始回应与程式保留原位元组，说明文字重新编写；内部编辑笔记不混入公开稿。包内 `DISTRIBUTION.json` 逐档列出保留、重整及省略的项目，`SHA256SUMS.txt` 用来核对这一版内容。

- [公开来源包：HTTP 回应、JS、WARC 与封存回执](/reports/clove-evidence/clove-sources-public-20260905.zip)
- [身份证据包：Google 设定、公司来源、程式上下文与四份补件](/reports/clove-evidence/clove-identity-public-20260905.zip)
- [五语公开分析稿与核对工具包](/reports/clove-evidence/clove-analysis-public-20260905.zip)
- [下载清单、SHA-256 与签章资料](/reports/clove-evidence/release.json)

这些新 ZIP 有各自的 RFC 3161 时间戳；档名加上 `.tsr` 即是对应签章，`.tsq` 是请求。原封存包的旧杂凑与旧签章另存于 `prior-seals/`，**只对应原包，不能拿来验证重整后的新 ZIP**。最早的来源包另保留来源清单的签章，签的是该清单。

截至本次整理，保存纪录列出 24 个可读 Wayback 来源副本，以及[一份 Archive.today 历史文章](https://archive.md/lYFbI)。历史文章保留当时文字，更正以现版主文为准。Arquivo.pt 的 20 个记录仍待公开整合确认，Google 设定的 Wayback 工作未完成，Perma.cc 没有完成回执；这些不计入保存成功。

<h2 id="verify">不靠本鹦鹉，自己动手查</h2>

### 第一步：核对你下载的是哪一份

下载 ZIP 与 `release.json`，比较档案大小和 SHA-256。Windows PowerShell 可执行：

```powershell
Get-FileHash -Algorithm SHA256 -LiteralPath .\clove-identity-public-20260905.zip
```

解压后，在包的根目录执行随附的 `python verify_files.py`，逐一核对 `SHA256SUMS.txt`。它只读本机档案，不连线，也不执行证据包内的 JS。

### 第二步：沿着来源找到原文

公开来源包从 `capture-manifest.json` 查网址、保存时间、HTTP 状态及档案；身份包从 `additional-public-manifest.json` 与 `identity-chain-sources.json` 查起。Apple、公司公告及 SMBC 的部分补件没有保留下来完整 HTTP 标头，清单有明写，不把缺失补成 HTTP 200。

用文字编辑器开启两份 JS，搜寻 `clove-v2-prd`、App ID 及认证网域；再开 `public-captures/admin-firebase-public-config.json`，核对 `projectId` 与 `authorizedDomains`。对照 Google 栏位定义，便能自己判断这条连接能支持甚么。

### 第三步：读操作的前后文

在日本 list 档搜寻 `scheduleAssignGuaranteedWinOripaUsers`、`oripaIds`、`アド确定オリパ` 及 `ユーザーの自动割り当て予约`。看提交参数、候选商品及回应处理，再到共用 chunk 核对操作定义。只截取英文函数名，会漏掉决定用途的上下文。

四份较晚找回的 JS 在 `recovered-missing-entries/`，杂凑与旧清单一致，但取得时间是 9 月 5 日；它们不会被改写成原包当时已收录。

### 第四步：核对第三方时间与签章

Wayback 网址内的 14 位数字是该副本的 UTC 时间。打开实际 replay，核对最后落到的网址与档案杂凑；提交工作成功不等于已经有可读副本。动态页面的 HTML 不同，也不应直接判定造假。

要核对新 ZIP 的时间戳，下载同名 `.tsr`，以及本站提供的 [FreeTSA CA 凭证](/reports/clove-evidence/cacert.pem)和[签署凭证](/reports/clove-evidence/tsa.crt)，在同一资料夹执行：

```sh
openssl ts -verify -data clove-identity-public-20260905.zip -in clove-identity-public-20260905.zip.tsr -CAfile cacert.pem -untrusted tsa.crt
```

成功结果为 `Verification: OK`。也可以依 [FreeTSA 官方方法](https://www.freetsa.org/index_en.php)独立取得凭证。信任基础是该时间戳机构与其凭证链；这里没有宣称 Bitcoin 锚定。时间戳证明对应杂凑在签发时已存在，并不证明网站作者身分、实际抽选结果或指控成立。

## 最后要接上的，是玩家的交易

现在，身份关联已有可以逐段重查的材料。真正能厘清玩家是否受损的，是同一批商品的规则、分配、付款、结果与帐户措施纪录。

**如果平台能交代，就把纪录放到桌面上。如果资料互相矛盾，就指出矛盾在哪里。** 这是本鹦鹉要求的答案，也是一篇公开调查应接受的检验。

本鹦鹉对 CARDZ.GAME 的推荐立场与邀请码披露，放在[主文末段](/cn/guides/clove-scam/)。推荐不能替 CLOVE 证据加分；同一把尺，也用来检视我推荐的平台。
