DogeSMS · 经营情报日报

ISP 自营池「取号成功、发码失败」黑洞：一次目录准入翻转如何在 24 小时内吞掉 380 个 OpenAI 订单

数据窗口：过去 24h / 7d / 30d 对比 · 生成时间 2026-07-14 20:xx UTC · 数据源：production 只读库 + GA4(512790783) + SigNoz

一句话结论：2026-07-12 ISP 自营号池的目录准入从「白名单」翻成「黑名单」（ispcatalog/projector.go Phase 3）。次日（7-13）投影器把 1924 个闲置加拿大号（96% 空置率）灌进了全部未拉黑的服务—— 其中平台第一大营收服务 OpenAI 单日被路由 381 单到 ISP，接码率仅 2.1%（同期 durianrcs 55.4%）。 ISP 加拿大 CLEC 号取号 99.5% 成功、发码几乎为 0，把 373 个本可完成的 OpenAI 订单变成取消/过期。运营用「候选报告一键拉黑」在当天 15:16 手动堵了 2 个号段——但这是被动打地鼠：7-14 仍在 google/CA、gmail、youtube、whatsapp 上以 ~0% 接码率漏水。根因是准入只看「有没有货」不看「发不发得出码」。

381

7-13 单日 ISP·OpenAI 订单（前一周合计仅 2 单）

2.1%

这批订单接码率（durianrcs 同期 55.4%）

373

当日未拿到 OpenAI 验证码的用户（265 取消 + 108 过期）

32×

ISP 单日订单量激增（14 → 449，跨 10 个服务）

96%

ISP 号池闲置率（1924 idle / 2000）——投影器有强动机清库存

已缓解

急性出血已被手动 blocklist 止住，但系统性缺口仍在

1 · 宏观信号：7 月接码率结构性下滑，量涨钱平

先看全局：7 月订单量比 6 月涨了约 40%（7-9 冲到 2655 单），但整体完成率从 6 月的 ~24% 掉到 7 月的 ~17%，营收却基本原地（~$120/天）。「多下单、不多赚」——这是典型的供给/路由效率问题，不是需求问题。

日期	星期	订单	完成	完成率	营收$	利润$
2026-06-16	Tue	1249	325	26.0%	116.65	61.38
2026-06-24	Wed	1609	438	27.2%	157.28	77.98
2026-07-05	Sun	1838	268	14.6%	98.37	43.92
2026-07-09	Thu	2655	425	16.0%	139.74	60.94
2026-07-13	Mon	2046	307	15.0%	126.17	69.60
2026-07-14	Tue*	1377	290	21.1%	131.18	67.59

* 7-14 为截止 20:08 UTC 的部分数据。按服务拆解后发现：整体下滑由两条线共同拉低——(a) telegram/whatsapp 大流量 + 极低接码率的结构性错配（各 6.5% / 4.1%），(b) 本报告聚焦的 ISP·OpenAI 单日事件。前者是长期已知问题（推荐位反馈闭环），后者是本周新发的、可精确定位的回归。

2 · 事件核心：ISP·OpenAI「取号成功、发码失败」黑洞

2.1 按中标供应商拆 OpenAI（cur 7d vs prev 7d）

中标供应商	prev 7d 单量	prev 完成率	cur 7d 单量	cur 完成率	cur 过期率
durianrcs.com	1849	57%	1915	54%	24%
grizzlysms.com	368	23%	461	22%	34%
isptelecom	0	—	381	2%	28%
5sim.net	237	12%	361	14%	29%

ISP 从 prev 7d 的 0 单跳到 cur 7d 的 381 单，且完成率仅 2%——这是把 OpenAI 整体接码率从 45.4% 拽到 37.6% 的直接元凶（其余 supplier 稳定）。

2.2 ISP 是「取号成功但发码为 0」的普遍模式（cur 7d，按服务）

服务	ISP 取号尝试	取号成功率	发码率(sms/alloc)
openai	383	99.5%	2.4%
whatsapp	50	98.0%	14.3%
telegram	20	100%	5.0%
google	14	100%	0.0%
gmail	11	100%	0.0%
github	18	100%	38.9%
cursor	6	100%	33.3%

ISP 加拿大 CLEC/VoIP 号（NPA 236/581）对 C 端消费级服务几乎必被地理风控拒发码（openai/google/gmail/telegram/youtube ~0%），只有 github/cursor 这类开发者服务能收到。但调度器把「取号成功」当成中标信号——号一分出去、订单就走下去、然后静默过期。这与既有认知一致（NPA-236 地理拒发码模式）。

3 · 时间线与根因（代码 × 数据交叉确认）

2026-07-12 · 目录准入翻转
ispcatalog/projector.go Phase 3：ISP service 准入从白名单翻成黑名单，投影面 = catalog_services 全量 active − isp_service_blocklist。设计初衷合理（白名单漏掉了 amazon/CA、cursor/US 等真实需求），但副作用是一次性把所有活跃服务对 ISP 开放。
2026-07-13 全天 · 洪水
ISP 单日订单从前一周的 3~14/天 暴涨到 449 单、跨 10 个服务、整体接码率 4%。其中 OpenAI 占 381 单（US 362 单），接码率 2.1%——265 取消 + 108 过期。ISP 有 1924 个闲置号（96% 空置），投影器有强动机把库存灌进任何未拉黑的高需求服务。
2026-07-13 15:16 · 被动止血
运营通过「候选报告一键拉黑」写入 isp_service_blocklist：openai/US/581 + openai/US/236。此后 ISP·OpenAI 归零。检测→止血约 15 小时。
2026-07-14 · 残余漏水（打地鼠未清）
ISP 当日仍有 33 单、接码率 12%。因为 blocklist 是逐 (服务,国家,号段) 精确匹配：openai 只堵了 US 的 236/581；google/CA（581 号段）、gmail、youtube、whatsapp/CA 仍以 ~0% 接码率漏水。

历史佐证：ISP·OpenAI 全历史 561 单、接码率 3.9%——说明「ISP 收不到 OpenAI 码」是号段物理属性，非偶发。2026-05 周曾有过一次 178 单的小规模episode，随后休眠；7-12 的准入翻转把它重新、且更大规模地唤醒。
GA4 交叉验证：7-13 站点 sessions=1850（当周最高），流量健康——失败是内部供给/路由造成，不是需求或流量异常。

4 · 影响量化（7-13 openai/US 反事实）

供应商	单量	完成	完成率	均价$	均利润$
isptelecom	362	8	2.2%	0.576	0.576
durianrcs.com	166	92	55.4%	0.327	0.187

用户体验（真实损失）：当日 373 名用户下单 OpenAI 却拿不到码——退款摩擦、信任流失、客服负担。这是最实的代价。
直接 P&L（较小）：若这 362 单走 durianrcs（55.4%）而非 ISP（2.2%），约多 ~193 个完成单。按 durianrcs 均利润 $0.187 计 ≈ ~$36 当日利润。因失败订单会退款、且 ISP 自营池边际成本≈0，直接账面损失有限。
系统性风险（最需重视）：本次靠人工「恰好」在 15h 内抓到。ISP 还有 96% 闲置库存待清；下一个爆量服务、或下一批新号段，会在无人盯守时重新打开同样的漏斗。急性事件已止，但结构性缺口未修。

5 · 建议动作

根治（推荐）：给 ISP 投影器加「发码质量闸门」——把被动黑名单升级成主动自愈准入。

在 ispcatalog/projector.go 投影时，对每个 (service,country) 读取 ISP 近窗口的发码率（数据现成：isp_numbers.successful_otp_count / allocation_count 或 supplier_execution_attempts），当样本≥N（如 30）且发码率<阈值（如 20%）时，自动不投影该 combo。
这样既保留 7-12 翻转的红利（自动发现 ISP 能干的 github/cursor/amazon），又自动排除它干不了的（openai/google/gmail/...），无需人工打地鼠。
与现有健康监控互补：当前 supplier-health 只看余额/水位（ISP 显示「2000 号很健康」），对「发码崩盘」失明——这正是本次盲区。

⚠️ 为什么本报告没有自动提 PR：目录准入 / 路由 / 定价属团队既定红线——需人工评审 + A/B，不autonomous上线。且 7-12 的翻转是团队带明确 rationale 的主动设计决策，急性出血也已止住。因此这里给出可直接落地的方案 + 代码位置，交由人来决策，而非擅自改路由。
临时止血（运营可立即做，属数据/运营决策）：把结构性发不出码的服务（openai/google/gmail/youtube/paypal/claudeai）在 isp_service_blocklist 加全局条目（country/npa 留空，效果同 paypal/claudeai 那两行），堵住 google/CA 等残余漏水，别再逐号段补。

6 · 次要观察（供留意，非本次重点）

SigNoz worker 24h 错误 204 条，无新增急性火情。但「严重告警：链上余额不足，可能被盗或数据库错误」24h 内触发 130 次（~5次/时稳态）——要么某 TRON 地址真的余额偏低，要么是告警刷屏。建议单独排查该告警的信噪比。
telegram/whatsapp 结构性错配：telegram 现为第一大下单服务（7d 4056 单）但接码率仅 6.5%，whatsapp 4.1%。属长期已知的推荐位反馈闭环问题，需 A/B 调权重，此处仅记录。

数据来源：production 只读 PG（orders / supplier_execution_attempts / isp_numbers / isp_service_blocklist / isp_service_pricing）· GA4 property 512790783 · SigNoz(tuna-worker)。
代码交叉确认：backend/internal/service/ispcatalog/projector.go（main 分支）。所有百分比/单量均可用报告内列出的口径复现。