我抽了 11 家 VPS 商家的 330 个 IP：反查率 0% 到 100% | One IP

2026-09-28 · 数据来自公开可复现源 · 作者 One IP

查一下你手上 IP 的 PTR、黑名单、ASN 和注册信息 →

上一篇写完云厂商的 IP 体检，有人问：那你写的那几家 VPS 商家呢？

合理。挑小鸡的时候真正纠结的是这些名字。所以这次换样本框：不再抽云厂商公布的地址段，而是抽各家背后那个 AS 实际公告的 IPv4 空间。

11 家，每家 30 个，共 330 个。同一个种子（20260928）可复现。

先说方法，因为这次的坑比上次多

商家 → ASN 这一步我没有靠印象，每家都留了证据：

RackNerd 那条我一开始也以为挂在 MultaCOM（AS35916）下游，查了 its looking glass 才发现五个不同机房的跳板全部落在 AS36352 ColoCrossing。这就是为什么这步得查，不能凭印象。

抽样方式：从每个 AS 公告的前缀里取 /24 作为候选池（大前缀用等差取 /24，不展开几万个），再从池里随机抽 /24，每个 /24 里随机取一个主机地址。

抽完我做了个自检：330/330 个抽样 IP 的 BGP 归属都等于目标 ASN。样本框没抽错。

两个必须说清的局限：

• 抽的是「公告空间」，不是「客户手里的机器」。里面含未分配给客户的段。所以下表的反查率严格说是「这个 AS 的空间里有多少地址有反查」，不等于「你买到手有多大概率有反查」。
• /24 只是尽量靠近客户实际拿到的粒度，不是精确等于。

指标四项：反向解析（PTR）、8 个公开黑名单（all.s5h.net、bl.spamcop.net、dnsbl-1.uceprotect.net、dnsbl.dronebl.org、dnsbl.spfbl.net、hostkarma.junkemailfilter.com、psbl.surriel.com、bl.blocklist.de）、RDAP 注册信息、RIPEstat 的 BGP 归属。zen.spamhaus.org 照旧不可用（拒绝公共解析器），只能剔除。

发现一：默认给不给反查，是商家的策略，不是技术概率

330 个合计 163 个有反查，49.4%。

但真正该看的不是百分比，是反查名字长什么样：

• 搬瓦工的 30 个，全部是 X.Y.Z.W.16clouds.com 这个模板——一个不落。16clouds 是 IT7 自己的品牌。
• Contabo 的 29 个里 24 个是 vmiNNNNNNN.contaboserver.net / contabo.net，5 个是客户改过的。
• Hetzner 的 29 个里 25 个是 static.X.Y.Z.W.clients.your-server.de。
• DigitalOcean 那 3 个是什么？hub.operio.work、dev.sightmap.com、mail.sndb.se——全是客户自己的域名，没有一个是 DO 的模板。也就是说 DO 默认不给 PTR，这 3 个是用户自己配的。

一边是「我们对整片空间统一设模板」，一边是「客户不自己设就没有」。这是两种明确不同的策略选择，不是运气。

对读者的实际含义很直接：你要拿 VPS 的 IP 发信，PTR 别指望商家。买完第一件事自己去控制台设上，名字用你自己的域名。 搬瓦工那种 100% 的是少数，而且它给的是它自己的统一样式，不是你的域名。

发现二：黑名单那个数字，不拆开看就会得出错误结论

330 个里 40 个命中至少一个名单，12.1%。按命中数排：

RackNerd 24/30，80%。看起来很难看，对吧。

然后我去看了这 24 个分布在哪些段：24 个命中，落在 24 个不同的 /24，一个段一个，均匀得可疑。再加上 40 次总命中里 36 次来自同一个名单 dnsbl.spfbl.net。

这个形态说明的不是「ColoCrossing 有 24 台机器在发垃圾邮件」，而是这个名单对 AS36352 这片空间做了整体判定——抽到哪都是它，那就不是机器的问题，是名单的政策。至于是不是合理判定，从外部看不出来。

所以「80% 命中」和「ColoCrossing 很脏」之间，差着一次拆解。我第一篇里 13 个黑名单命中，12 个也是 spfbl，同样的结构。

顺带一个逆向观察：腾讯云 0% 反查，却有 5/30 命中 spfbl。没有反查 + 上名单，这两个信号凑一起才是真麻烦。

发现三：反查名、注册主体、公告者，可以是三家

这是这轮最有意思的部分。看三个具体 IP：

173.44.54.180    BGP 公告 AS20473（Vultr）
                 RDAP 注册主体 = West Coast Internet Provider LLC（段名 CC-173-44-54-0-24）
                 PTR = unassigned.quadranet.com

198.20.246.214   BGP 公告 AS31898（Oracle）
                 RDAP 注册主体 = HostGator.com LLC（netname HGBLOCK-7）
                 PTR = 198-20-246-214.unifiedlayer.com

204.44.82.41     BGP 公告 AS36352（RackNerd/ColoCrossing）
                 PTR = 204.44.82.41.static.quadranet.com

三个名字，三家不同公司。我抽到的 330 个里，有 6 个的反查指向第三方机房域名（quadranet.com 在 RackNerd 和 Vultr 两家的样本里各出现一次，unifiedlayer.com、hostgator.com.br 出现在 Oracle 的段里）。

最合理的解释是 IP 转手之后反查没清——unassigned.quadranet.com 这个字面意思就是「未分配」。但我没法从外部证明它一定不是客户自己设的。能确定的结论只有一条，而且这条比上面所有数字都重要：

PTR 不能当归属证据。 单看反查名字判断「这个 IP 是谁家的」，这次能直接翻车。

发现四：你买的是商家，持有地址的是别人的机房

RDAP 的注册主体分布很能说明问题。同一个商家抽的 30 个 IP：

RackNerd 那行值得盯着看：16 个注册在 HostPapa 名下，只有 9 个是 RackNerd LLC。它跟 BGP 那层完全吻合——AS36352 的 holder 就是 HostPapa 系的 ColoCrossing。

意思是：你在 RackNerd 下单，地址空间的实际持有者是 HostPapa 的机房。这不是毛病，是这门生意的常态——小商家租机柜和 IP 段，自己只管卖和服务。但两个实际后果：

1. 投诉和追责链条要长一层。 想申诉某个 IP 被误判，先在 RDAP 里看清 abuse 联系人是商家还是上游机房。 2. 「这个段以前是谁的」决定它的历史声誉。 Oracle 段里挂着 HostGator 注册的老段就是活例子——接手的不是新段，是带着历史的段。

另外腾讯云那 27 个查到的结构是：没有 registrant 实体，联系人写的是 James Tian、Jimmy Xiao 这样的具体人名（APNIC 风格的 administrative/technical 联系人）。要查滥用得顺着 IRT 对象走。这个我没法从外部验证真伪，只如实记录结构。

一个我砍掉的指标

我原本算了「RDAP 里披露 abuse 角色的比例」，跑出来 330/330，100%。

太整齐，回头用严格标准重检了 10 个：0/10。

差别在于我第一版的判定是「整段 JSON 里出现 abuse 字符串」。而 abuse 会出现在 remarks、邮件地址、IRT 引用名里——不是「有个实体标了 abuse 角色」。数字是假的，指标作废。

写在这里是因为这类错误才是这种文章里最容易出的：如果一个比例刚好是 100% 或者 0%，先去怀疑你的判定逻辑，别先写结论。

最后：这轮没测什么

• 邮件实际能不能送达。 没有一个黑名单命中能推出「邮件会被退」，也没有 0 命中能推出「一定能进收件箱」。要看真实送达率得自己发一轮测试信，那是另一篇文章。
• 真实机器的体验。 我抽的是公告空间，不是你手上那台。同一家不同机房、不同批次差别很大。
• zen.spamhaus.org。 它拒绝公共解析器的查询，这轮依然拿不到。它是邮件圈权重最高的名单之一，缺了它就是缺了一块——我不拿别的名单凑数假装覆盖了。

原始 330 条记录和采集脚本都公开：数据 vps-audit-2026-09.json（CC BY 4.0），脚本和同一份数据也在 GitHub：mazihua-lgtm/vps-ip-audit-2026-09。种子写死在脚本里，重跑得到同一批样本。

上面这些检查我平时是在自己的工具里跑的：https://pureip.app/ip（IP 纯净度与风险评分查询，PTR、黑名单、ASN、注册信息放在同一页）。这次的 330 个样本是它的副产品。

披露一句：pureip.app 是我自己做的 IP 查询与网络诊断工具箱，这 330 条数据是它的副产品。数据是真的，工具是我的，先说清楚，省得你后来发现。