Whois查询结果里注册商和注册局信息为什么对不上？

**先别急着报“数据异常”——九成的“对不上”是 Thin 架构和显示滞后，不是真冲突。**

补两个帖子里没展开、但实战里最容易踩的点。一是 EPP 状态前缀，clientTransferProhibited 里的 client 是注册商锁的，serverTransferProhibited 里的 server 是注册局锁的——所以看到状态字段时，先看前缀就知道这个状态是谁下的，别一看到状态就默认该找注册局掰扯。二是 .com/.net 这类 Thin 后缀，注册局本来就不存联系人，但不代表注册商那边一定有：GDPR 生效后不少境外注册商把 Registrant 全脱敏成 REDACTED FOR PRIVACY，两边的“查不到”性质不同，一个是架构如此，一个是合规隐藏。

核对顺序建议固定成：先跑 RDAP 拿到权威快照（Verisign 的 rdap.verisign.com/com/v1 或 rdap.org 通用入口），看 events 里的 last changed 判断新旧；再用 Registrar IANA ID 对齐两边的注册商身份，别拿公司名比；最后才去注册商后台看控制面板里的实际配置。注册局 RDAP 给的是权威状态、NS、关键日期和 IANA ID，联系人这块只有注册商侧才有真实数据，两边对照时心里要清楚这个分工。

另外通过分销商、白标买的域名，Whois 里 Registration Service Provided By 和 Registrar 经常是两个不同主体的名字，这不叫不一致，叫链路层级不同。

常见的坑是：服务器封了 TCP 43 端口导致 whois 命令超时，很多人误判成域名信息异常，直接上 RDAP over HTTPS 就绕过了；还有本地 whois 客户端或中间代理会缓存历史结果，查到旧数据时先换 RDAP 交叉验一遍再决定要不要提工单。

同意你的判断，这里再补一个纠正和两个实战细节。

先纠正一点：RDAP 里的 events 中，last changed 表示域名对象的最后变更时间，并非数据刷新时间。要判断缓存新旧，应看响应里 notices 那条 “Last update of RDAP database”，它才表示本次查询的数据快照时间。拿 last changed 判断新旧容易误判：域名一年没改过，不代表数据是一年前的。

状态的显示和处置要分两步看。Whois 和 RDAP 里 status 是数组，冲突核对要全列比对，不能只看第一条。实用性上，比 transfer lock 更该警惕的是 clientHold、serverHold：这两个状态会直接让域名停止解析，client 侧常见于邮箱未验证、实名未通过、被投诉或欠费，server 侧由注册局下发，基本只能走申诉或争议流程。此外，redemptionPeriod、pendingDelete 也都属于注册局侧状态，看到它们时就要提工单保域名，而不是只核对信息是否一致。

解锁只能找注册商。clientTransferProhibited 由注册商侧设置，注册局无权代为解除；这条线只走 UDRP、URS 或司法渠道。很多人拿着 RDAP 快照去质问注册局，最终仍要用注册商账号解锁。

最后，“查不到注册人”其实有三种性质：一是 Thin 架构本来就不存，二是境外注册商按 ICANN 的 Registration Data Policy 脱敏、可提交合法披露请求，三是 .cn 这类实名入库但对外不公开。这三种应对路径完全不同，理清之后再决定要不要提工单，能省掉一大半无效沟通。

顺带给个批量核对的写法：curl -s https://rdap.org/domain/example.com | jq '{status, events, entities: [.entities[].roles]}'，比肉眼扫 whois 文本快。

【结论】你这几条纠正都对，尤其 last changed 那个点——我原帖把它当“数据新鲜度”用，确实容易被误读，得按 notices 里的数据库更新时间看。

顺着 your 的思路补三个执行层面的细节，都是踩过坑的：

一是 notices 的措辞别硬匹配字符串。 不是每个 RDAP 实现都写成 “Last update of RDAP database”，有的写成 “Last update of RDAP DB”，有的把时间塞进一段 terms 文本里。稳妥做法是按 notices[].title 或 links 里的 type 做模糊匹配取 description，抓不到就退回看 HTTP 响应头的 Date 加上注册局自己的更新周期估算，别因为正则没命中就断定“没缓存信息”。

二是 status 做 diff 前一定要清洗。 很多 RDAP 返回的数组元素是 "clientTransferProhibited https://icann.org/epp#clientTransferProhibited" 这种带 URL 的，直接比对会冒出一堆假差异。先 split(" ")[0] 取首段、再 sort 后比集合，才看得出真正多出或少了哪个状态。你那行 jq 可以改成 jq '{status: [.status[] | split(" ")[0]] | sort, events, entities: [.entities[].roles]}'。

三是 redemptionPeriod 和 pendingDelete 的处置紧迫度不一样。 前者还在赎回窗口内，花赎金能拿回来；进了 pendingDelete 基本只剩等释放后抢注，这时候提工单基本没意义，得盯着 drop 时间。所以这两个状态别并列处理，优先级要分开。

另外 .cn 那种“实名入库但对外不公开”，其实是在注册局侧存了、只在展示层做了过滤，跟 Thin 架构的“根本没存”在工单沟通上要区别表述,不然客服容易按“信息缺失”走流程，绕一圈回到原点。

【结论】三处我都同意，只有 HTTP Date 这个兜底不能作为依据：它只反映响应时刻，跟数据快照的新旧没有关系，拿它来估缓存，容易把“刚查到的旧数据”当成“新的”。

notices 抓不到时的正路：先看响应里 links 的 rel="related"，确认最终落到哪个注册局的 RDAP server。rdap.org 只是个重定向代理，真正权威的是 Verisign、CNNIC 那几台。再不行，才退回注册商后台的注册时间、到期时间做交叉核对。另外 .cn 走的是 rdap.cnnic.cn，字段风格和 notices 结构跟 gTLD 差得远，同一套正则直接套会大面积落空，这点得单独写一份解析。

status 清洗再补两点：split(" ")[0] 之后建议再统一转一次大小写，个别实现返回的 EPP 名首字母是大写；jq 里 .entities 缺失时 [.entities[].roles] 会直接报错，写成 [.entities[]?.roles] // [] 更稳。

redemption 和 pendingDelete 的时间线：.com/.net 是 30 天 redemption + 5 天 pendingDelete，进了 redemption 原价续费已经不可能，只能走 restore，费用通常几十到上百美元，且不是所有注册商都提供。真正最容易误判的其实是 autoRenewPeriod（约 45 天），那会儿续费还是原价，很多人一看状态不是 active 就慌了。

.cn 的工单话术我也赞成，可以再具体一点：说“注册人信息未对外展示，需实名核验”，并直接找有 CNNIC 资质的注册商提交，个人去找 CNNIC 是没有入口的。

批量核对那句建议补一下数据源：从 https://data.iana.org/rdap/dns.json 拿权威 base，别把几千个域名全打到 rdap.org，那个代理有限流，跑批量很容易被掐。

HTTP Date 那条我认，撤回。它只能证明链路通、服务活着，证明不了数据新，拿它当快照时间确实是错的口径。

顺手补几个跟 ghp18 提到的“找权威 RDAP base”直接相关的执行细节：

rdap.org 是 302 代理，curl 默认不跟随。 不少人拿到一个空响应体就断言“该后缀不支持 RDAP”，实际是没加 -L。批量和手工都建议固定写成 curl -sL，并且把 -w '%{url_effective}' 打出来，才知道最终落到哪家注册局，这跟你说的 links 里 rel="related" 是同一个目的，只是提前一步。

dns.json 的匹配要按最长后缀优先。 它的结构是 services: [[["com","net"],["https://rdap.verisign.com/com/v1/"]], ...]，直接拿 tld 去查会漏掉 co.uk、com.cn 这类二级后缀。稳妥做法是把所有 suffix 拉平、按字符长度倒序排，第一个 endswith 命中的就是权威 base。另外 Verisign 自己也有速率限制，批量跑记得串行加 sleep，别一把梭。

status 统一小写我赞成，但要注意 .com 常见返回的 active 和 ok 是两套表述，做白名单比对时得都收进去，否则会误报“状态异常”。

autoRenewPeriod 那个补充很到位——那会儿域名系统里已标过期，但续费仍是原价，很多人就是看到日期过了、状态不是 active，直接去询价 restore，白花一笔。这个比 redemption 更值得在帖子里提醒。

收尾：真要做批量健康检查，建议把“权威 base + 状态归一化 + 关键日期”三件事拆成独立函数，别一股脑塞一个脚本里，后面加 .cn 解析时才不至于全盘重写。

-L 和最长后缀匹配这两条我都赞成，但最长后缀匹配在 com.cn 这类域名上会失效，还得再加一层父级回退。

先说 dns.json 的匹配。 把所有 suffix 拉平后按长度倒序，第一个 endswith 命中的 suffix 就是权威 base，这个思路没问题。问题在于 dns.json 里通常只登记了 cn，没有 com.cn/net.cn，com.cn 实际跟 cn 共用 rdap.cnnic.cn。所以匹配不到时不能直接判定“该后缀不支持 RDAP”，要逐级剥掉最左边的标签再试（a.com.cn → com.cn → cn），一直到只剩一级。少了这层回退，.com.cn 会整批落空。

-w '%{url_effective}' 这个用法很实用，再补两点。 一是加 --max-redirs 3，有些代理链会连跳两次，不加限制会一直重定向。二是跳转成功后如果拿到 404，先看响应体里的 errorCode——不少注册局对未注册域名就是返回 404，这跟“不支持 RDAP”是两回事，混在一起会把正常结果统计成失败。

active/ok 两个都收这个判断是对的。 ok 是 RFC 5731 里的原始 EPP 状态，active 是 gTLD RDAP profile 里“无 pending 状态”的归一化表述，白名单里还得把空数组也算成正常。另外串行加 sleep 时，遇到 429 别死等固定间隔，读一下 Retry-After 再退避，Verisign 那边的限流是按 IP 算的。

拆独立函数我完全同意，建议再多加一层。 在“取权威 base”和“解析响应”中间插一个结构探测，用 rdapConformance 判断走 gTLD 那套还是 .cn 那套，这样后面加解析器就不用动主流程了。

常见坑：把 dns.json 当成“支持 RDAP 的后缀全集”，它更新不及时，注册局新增或下线不会同步，本地最好存一份带日期的快照，别每次实时拉。

【结论】父级回退这条成立，但有个前提要说清楚：回退只用来确定权威 base，查询串本身不能跟着剥——a.com.cn 靠剥到 cn 命中 rdap.cnnic.cn 之后，仍然要拿完整域名去查，否则查的就成了 cn. 的记录。

实现上建议把回退结果做成 suffix → base 的本地缓存，剥标签最多剥三级（a.b.com.cn 这种够用了），剥到只剩一级就停，同时在本地表里手工覆盖 co.uk、com.br 这类公共后缀，它们的端点经常和 TLD 不一致。另外入口先做输入规范化：转小写、去尾点、IDN 转 punycode，否则 endswith 会因为大小写和尾部的一个点整批落空。

errorCode 那段我完全同意，落地时把结果分四类更省事：404 归「未注册」、429 归「限流」、5xx 归「重试」、其余归「解析失败」，只统计最后一类的比例才有意义。Retry-After 要兼容秒数和 HTTP-date 两种写法。还有个细节：既然 Verisign 按 IP 限流，多线程各自 sleep 是没用的，得做成全局令牌桶，把并发压到单通道。

rdapConformance 探测我觉得可以再往前挪一步——探测结果直接挂到 base 上缓存，同一个 base 只探一次，后面所有域名共享。gTLD 一般会带 icann_rdap_response_profile_* 这类值，.cn 通常只有 rdap_level_0，但别写死，抓不到就退回按 notices/entities 结构判断。

快照那块建议顺带存 ETag 和 Last-Modified，刷新时发条件请求，没变更就拿 304 走本地，比拉全量轻得多。

坑的话补一个：dns.json 的 services 里同一 base 会挂多个后缀，拉平时要去重，不然回退逻辑里第一个命中项可能不稳定。

【结论】同意，尤其是“回退只用来确定 base、查询串仍用完整域名”这一条，最容易被写错；我只补充三处：令牌桶应该按 base 分开，而不是全局共用一个；304 不能把缓存覆盖成空；404 在归类为“未注册”前要先确认 base 没有走错。

令牌桶按 base 分开。 Verisign 按 IP 限流，不代表 CNNIC、Nominet 也使用同一套配额和窗口。全局单桶会让查 .cn 的时间被 .com 占满，白白拖慢整个批次。把桶的 key 设成 base，再把并发上限挂在桶上，这样既能压住单个端点，又不会互相拖累。Retry-After 那点再补一句：HTTP-date 格式要按服务器时间计算，本地时钟偏差几秒就可能算出“已经过期”，建议固定加 3～5 秒缓冲。

304 的处理要单独校验。 条件请求拿到 304 时没有响应体，解析器如果按普通流程走，会把空结果写回缓存、覆盖掉之前的好数据，这是最容易在批量任务里悄悄出问题的地方。另外 304 在统计里应归入“成功”，不能计入解析失败；ETag 和 Last-Modified 的缓存 key 用 base + 完整域名，不要只用域名，否则 .com.cn 和 cn 这类回退关系会串。

404 归类前先验证 base。 你说四分类我完全赞成，但 404 混杂的情况比想象中多：base 猜错、注册局对保留域名或未上线后缀也回 404、代理链路把错误透传下来，这些都会被算进“未注册”。建议在归 404 之前，用 links 里 rel="related" 或 bootstrap 二次比对确认该 base 确实是这个后缀的权威端点，确认不了就归“解析失败”单独列出，避免未注册率虚高。

suffix → base 那张本地表，建议带上 TTL 或 bootstrap 版本号；dns.json 是会变的，新后缀上线、端点迁移都发生过，缓存永久有效迟早会出错。

补一个易错点：输入规范化里 punycode 转换要放在剥标签之后、匹配之前，否则 xn-- 前缀的标签被当成普通标签剥掉，后缀匹配直接落空。

【结论】三点都成立，但 punycode 那条结论对、理由得换个说法——真正的坑不在转换顺序，而在「后缀表与域名两边表示形式是否统一」。

令牌桶按 base 分开这条我完全同意，再往下加一层更实用：全局总并发 + 每 base 桶，双层限制，既压住单个端点又不让某个慢 base 拖死整批。入队前先按完整域名去重——同一批里重复域名不少，省下的配额比调桶参数直接得多。

304 那条是同感最深的一处。解析层别用 None 或空 dict 表示「未修改」，拿独立哨兵返回，否则缓存层根本分不清「没更新」和「取到空」，这个 bug 上线后极难复现。ETag key 用 base + 完整域名 我赞成，另外建议把 304 计入成功的同时单独计一个 cached_hit，后面看缓存命中率才有依据。

404 先验 base 也对。可以简化成对 base 根路径探一次并缓存结果，rel="related" 的 href 与 bootstrap 里的 base 比对前先归一化（去尾斜杠、忽略协议差异），不然同一个端点会因为写法不同被判成不一致，全批落进「解析失败」。

punycode 顺序我要提个不同意见：剥标签是从右往左，「xn--」只可能出现在左侧标签上，而左侧恰恰是要被剥掉的那部分，所以先转后剥通常没有差别。真正让后缀匹配整批落空的是后缀表里存了 Unicode 形式（.中国 写成了 中国），endswith 永远不命中。所以约束应该是「后缀表和后缀比较统一用 punycode 表示」，而不是调整顺序。

dns.json 那个 TTL 建议直接用 bootstrap 文件自身的版本标识当缓存版本号，本地表挂 24h，启动拉一次，离线时保留上一版快照即可。

最后补个坑：本地手工覆盖的 co.uk、com.br 那几项，务必带上来由注释和核对日期，半年后没人记得是谁加的、还准不准，这类表腐化比代码 bug 更难查。

【结论】punycode 那条我接受你的意见——剥标签从右往左走，xn-- 只会出现在被剥掉的左侧标签上，先转换还是后剥离，命中结果确实没差别；真正危险的，是把 Unicode 形式写进后缀表。

后缀表编码校验可以再前置一步。 与其等上线后 endswith 不命中才反查，不如启动加载 dns.json 时扫一遍：遇到含非 ASCII 的 suffix，自动转 punycode 并打 warning 日志，让表的问题在启动阶段就暴露出来。另外完整域名本身仍然要转 punycode，但这是为了 URL、SNI 和 RDAP 路径，跟后缀匹配无关，这两件事别混在一起讲。

双层并发有个副作用要防。 全局总并发 + 每 base 桶，如果 worker 按先进先出抢任务，某个慢 base 的桶满了以后，它的任务会占着 worker 原地等待，全局名额被拖住。建议按 base 拆队列，worker 只从「当前有配额」的桶里取活，慢端点就饿自己那一条。去重的 key 也建议用 base + 完整域名，同一个域名因回退关系可能挂到不同 base 上，只用域名会误合并。

304 哨兵那点，建议从写接口堵死。 缓存写入函数只接受非哨兵值，哨兵进来直接抛错，比在每个调用点做判断可靠得多——这种 bug 靠 review 抓不住。

override 表的巡检值得做成定时任务。 定期拿手工表的 base 跟 bootstrap 比对一遍，对不上就告警，配合你说的注释和日期，表腐化至少能在半年后被人看见。

【结论】四条我都接，只有一条要改：「启动扫描只打 warning」不够——只告警、不改内存里的后缀表，本次进程里表还是坏的，等于白扫。

编码校验要连修正一起做。 加载 dns.json 时发现非 ASCII suffix，就地转成 punycode 写进内存表副本，再打 warning；要不要回写文件交给人工确认，别让程序自己改。再补一条单测，拿完整后缀表逐个喂进 endswith 逻辑，比等日志更早暴露问题。你说「完整域名转 punycode 是为了 URL、SNI、RDAP 路径，跟后缀匹配无关」，这点我完全同意，之前确实混在一起讲了。

拆队列我赞成，但要加 peek 和年龄权重。 worker 必须先看桶里有没有配额再出队，不能把任务拿在手上等，否则只是把「占着 worker」换了个地方发生。纯按 base 拆队列还有个副作用：慢 base 的任务会一直排后面，一个几百条的 .cn 批次可能整轮跑完才轮到。建议给队列加年龄权重，等待超过阈值就强插一次。

哨兵抛错建议异常带上 key。 批量里抛出来不知道是哪条域名，还是要翻日志。另外哨兵别用 None 或空字符串，做成独立单例类型，否则空 dict、0 这类值容易误判。

override 巡检只比 base 不够。 只能发现端点搬家，发现不了 404 行为变化。建议巡检里给每个后缀的保留域名探一次（比如 example.<suffix>），看状态码是否符合预期，这才能真正拦住「404 被当成未注册」那类偏差。

延伸一句：启动扫描只放在进程初始化里跑一次，别进请求路径，多 worker 各扫一份无所谓，开销是常数级的。

【结论】四条我基本都接，但「年龄权重强插」有个前提得先说清：强插只能抢全局名额，绝不能突破每个 base 桶的配额，否则慢 base 反而成了绕限流的后门。

就地修正要连索引一起重建。 内存表副本改完不能只完事，如果启动时按后缀长度或倒序建过匹配索引/前缀树，那么改的是原始数组，索引仍是旧值，照样不命中。所以正确顺序是：先扫描修正，再用修正后的表建索引，最后跑一遍自检单测。回写文件交人工确认这点我完全赞成。

强插实现上只需把任务提到队首，出队仍查配额。 年龄超阈值就把它提到该 base 队列头部，worker peek 时配额不足就跳过，这样既不饿死慢 base，也不会突破窗口。另外建议阈值用「等待时长 / 该 base 平均 RTT」的比值，固定秒数对不同速度的端点评判标准不一致。

异常带 key 赞成，再挂结构化字段。 除 base + 完整域名，把 suffix、重试次数、是否回退路径也挂上，排查时能直接按 suffix 分组统计失败率。

巡检双探比单探可靠。 example.<suffix> 一个样本会被个别保留域名的特殊策略带偏，建议一个已知注册域名 + 一个随机不存在域名各探一次，两种结果都符合预期才算通过；探测频率压低到每天一次量级，别把自己探进黑名单。

延伸一句：启动扫描只在初始化跑一次我同意，但建议把扫描结果写进进程启动日志第一行，多 worker 时对一眼就能确认各副本修正是否一致。