⭐ 推荐:社区规则条款 V1.0

域名被投诉侵权时Whois信息会作为证据吗?

满月居于空
满月居于空 萌新站长
发布于 2026-10-28 08:53 ·8 浏览 ·12 回复
内容摘要

Whois记录在域名侵权投诉中可作为证据,主要证明注册人身份与注册时间,不能单独证明侵权;遇隐私保护需向注册商申请披露,并应与网页、备案、解析等证据结合使用。

学完这篇你能搞清楚:域名被投诉侵权时,Whois 记录到底能不能当证据、能证明什么、查不到真实信息时该走哪条路,以及自己作为域名持有人该怎么应对。

第一步:先弄清 Whois 记录里到底有什么

这一步的目的是知道手里这份记录能证明哪些事实。在终端执行 whois 你的域名.com(Linux/macOS 自带;Windows 可装 Sysinternals 的 Whois 工具,或用注册商官网的 Whois 查询页),会返回注册人姓名/组织、邮箱、电话、地址、注册商、注册时间、到期时间、DNS 服务器等字段。

其中真正有证据价值的是三类:注册时间(判断是否早于对方商标申请日)、注册人身份信息(判断被投诉主体是否对得上)、注册与续费历史(判断是否存在囤积、倒卖痕迹)。注册时间这类客观字段几乎不会被推翻,身份字段则经常因为隐私保护而失真。

注意:Whois 里的「Registrant Email」很可能是一个代理邮箱(如 whoisproxy@ 开头)或注册商的隐私保护地址,它不是真实联系邮箱,别把它当成对方的常用邮箱去发律师函。

第二步:分清场景——域名争议程序还是法院诉讼

两种程序对 Whois 的态度不同。走域名争议解决程序(国际域名适用统一域名争议解决政策 UDRP,国内 CN 域名适用域名争议解决办法)时,投诉人提交的 Whois 打印件是标准材料之一,专家组会用它确认域名持有人身份和注册时间;走法院诉讼时,Whois 属于电子数据类证据,需要说明来源和取得方式,通常还要公证或做时间戳固定。

所以先确认你面对的是哪种程序:争议机构的投诉书模板里一般会明确列出「域名注册信息」为必交附件;法院则更看重证据链完整性。GJ 站长论坛(www.gj0.com)的站长交流区里常有人贴出这类投诉材料,可以对照格式。

第三步:把公开 Whois 固化成可用证据

这一步做完,你手上就有一份时间点明确、内容不可篡改的查询记录。操作顺序是:打开注册局或注册商的官方 Whois/RDAP 查询页(如 com 域名可用 curl https://rdap.verisign.com/com/v1/domain/example.com 拿到结构化 JSON),执行查询后立刻整页截图,同时保存页面 URL 和查询时间;重要案件建议直接做公证或第三方时间戳。

注意:普通截图容易被质疑「可伪造」,金额大或争议激烈的案子不要省公证费;另外 Whois 结果会随域名状态变化,隔几天再查可能就不一样了,务必保留首次查询的原始文件。

第四步:公开信息被隐藏时,走注册商信息披露流程

如果 Whois 显示的是隐私保护或代理注册,你需要向域名注册商提交信息披露申请。入口通常在注册商官网的「法律事务/Law Enforcement/滥用举报(Abuse)」页面,提交材料包括:权利证明(商标注册证)、侵权说明、你所走的程序(已立案的案号或争议机构受理号)。注册商一般只在收到法院文书或争议机构要求时才披露真实注册人。

注意:直接给注册商客服发一封「我要这个域名主人的信息」的邮件基本不会有用,必须附权利凭证和程序文件;不同注册商响应周期差异很大,从几天到数周都有可能,别卡在投诉截止日前才动手。

第五步:把 Whois 和其他证据串起来用

单独一份 Whois 只能证明「谁在什么时间注册了这个域名」,证明不了「他在侵权」。要把下面这些材料一起提交:网站页面截图(含侵权内容)、ICP 备案信息、页面上的联系方式与收款账户、域名解析记录(dig 域名 +short 或历史解析查询)、对方是否批量注册相似域名的记录。多条线索指向同一主体时,Whois 中的身份信息才真正发挥作用。

反过来,如果你是域名持有人被投诉:第一件事是核对注册信息是否真实有效,虚假 Whois 在争议程序里会被直接认定为恶意;第二件事是整理商标申请日之前的注册与使用证据;第三件事是保留网站正常经营的页面存档。

注意:注册信息过期不更新,可能被别人抢注或导致域名被注销,这在争议中对你非常不利。

小结

  • Whois 记录可以作为证据,主要证明注册人身份与注册时间,不能单独证明侵权成立。
  • 公开查询结果要配合截图、URL、时间戳或公证固定,否则证明力会被削弱。
  • 隐私保护状态下拿不到真实信息,须通过注册商的信息披露流程,附权利证明和程序文件。
  • 证据要成链:Whois + 网站内容 + 备案信息 + 解析记录,相互印证才有说服力。
  • 域名持有人应保持注册信息真实有效,虚假信息本身就可能被认定为恶意。

免责声明:本文为一般性信息整理与技术操作说明,不构成法律意见;具体案件请咨询执业律师或向域名争议解决机构核实最新规则。

本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-2654.html
转载请注明出处,版权归原作者所有。
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 12

阿乐
阿乐 资深会员 1楼 2026-10-28 09:15

能当证据,但它的证明力很窄——Whois 只能证明「谁、在什么时间注册了这个域名」,证明不了「他在侵权」。

在 UDRP 或国内域名争议程序里,Whois 打印件是投诉人材料的标准组成,专家组主要拿它确认两件事:持有人身份,和注册时间是否早于对方商标申请日。后者往往是整个案子的胜负手,所以作为持有人,第一件该做的事是把域名注册时间、商标申请/注册时间拉成一条时间轴,把最早的注册凭证(注册商确认邮件、当年的付款记录、注册局记录)固定下来。法院诉讼里 Whois 算电子数据,光截图不够,来源和取得方式要说清楚,最好是公证或时间戳。

另外有一个反直觉的点:别以为开了隐私保护就查不到。争议程序一旦受理,争议机构会要求注册商披露真实注册人信息,藏不住,反而可能被认定配合度低。真正有效的抗辩是有没有「善意使用」——域名是否对应真实运营的站、有没有 ICP 备案、页面内容与域名是否相关、有没有向对方兜售或索价的记录。这些比 WhoIs 本身重要得多。

还有个坑要避开:收到投诉通知后临时改 Whois、转移注册商、或者把页面内容清空,这些动作在专家眼里几乎等于自认恶意,一律不要做。真要做的只有一件——把所有时间证据先固定好,再决定走和解还是抗辩。

域名注册
域名注册 版主萌新站长 👑黑卡会员 #3651 2楼 2026-10-28 09:22
阿乐:能当证据,但它的证明力很窄——Whois 只能证明「谁、在什么时间注册了这个域名」,证明不了「他在侵权」。 在 UDRP 或国内域名争议程序里,Whois 打…

补几条阿乐没展开的,尤其是时间轴这块有个致命细节容易被漏掉:域名一旦掉签被重新注册,Whois 上的 Creation Date 会被重置成新日期,这时候你手里那份"注册时间早于商标"的证据链就断了。

所以时间轴不能只查当前 Whois。真实的案子要同时拉三样东西:archive.org 的历史快照(看站点最早什么时候存在)、历史 Whois 数据库记录(DomainTools、WhoisXMLAPI 这类商业库有快照存档)、以及当年的注册商邮件和付款流水。这三样凑齐才叫"首次注册时间"站得住,只靠 now-whois 在当前持有人手里其实很脆。

另外 UDRP 的三要素里,恶意是分"注册时"和"使用中"两段的。域名注册明显早于对方商标申请日的情况下,投诉人基本只能从注册后行为去推定恶意,那你要防的就是商标公告日之后的动作:有没有主动报价兜售、有没有挂停放页挂广告、有没有在页面上蹭对方品牌词。相反,如果域名注册晚于商标而且页面还跟对方业务重合,那善意使用的抗辩空间非常小,这时候谈和解比硬扛划算。

还有个反向的筹码:如果注册时间明显早于商标、对方又是知名主体,答辩里主张反向域名劫持(RDNH)是合理动作,一旦被专家组认定,对后续和解谈判的实际价值比多辩几句"善意"大得多。

固定证据这块,国内做联合信任时间戳比公证便宜也快,效果在多数争议程序里够用。

最后呼应阿乐那句——别在争议期间转移注册商。除了被解读为规避,转移本身还有 60 天锁定期,等于自己把域名卡死在一个不能动的位置上,比改 Whois 更被动。

lqyyzz
lqyyzz 观望站长 #3654 3楼 2026-10-28 09:41
域名注册:补几条阿乐没展开的,尤其是时间轴这块有个致命细节容易被漏掉:**域名一旦掉签被重新注册,Whois 上的 Creation Date 会被重置成新日期**,这时…

这几条补得比原帖本身更值钱,只有一处需要说清楚:**「Creation Date 重置」只看是否真的掉签重注,正常续费不算法定意义上的新注册**。

UDRP 体系里,多数专家组意见是域名正常续费不构成新的注册行为,所以商标注册在前的人没法靠「你又续了十年」来主张恶意注册;真正会打断你时间轴的是域名过期后被人抢注、你再赎回或重新注册,这时 Creation Date 才会变成新日期,你的证据链也就断了。所以「注册时间早于商标」这条抗辩,重点盯的应该是域名有没有过掉签记录,而不只是当前 Whois 显示什么。历史 Whois 商业库能查到的年限有限,早年记录往往要回 archive.org 从站点快照倒推,这点你说得对。

转移这块再补一句:UDRP 投诉正式提交后,注册商按规则必须锁定域名,本来也转不动,那 60 天锁更多影响的是你自己主动折腾的情况。另外域名注册提到的 RDNH 门槛其实不低,专家组认定投诉人滥用的比例并不高,把它当谈判筹码可以,别当成主攻方向。

固定证据再加一个细节:保存 RDAP 返回的 JSON 原文并算一份哈希一起归档,比纯截图抗质疑得多。CN 域名还有个现实问题,Whois 字段本来就少,走国内争议时直接找注册商开局注册证明往往比打印 Whois 管用。

阿乐
阿乐 资深会员 #3660 4楼 2026-10-28 09:50
lqyyzz:这几条补得比原帖本身更值钱,只有一处需要说清楚:**「Creation Date 重置」只看是否真的掉签重注,正常续费不算法定意义上的新注册**。 UDRP …

续费不构成新注册这点没争议,但有个技术细节容易误伤自己人:RDAP 返回的 events 数组里,转注册商会新增或更新 last changed,而 registration 事件是注册局侧的首次注册时间,一般不动。看到日期变了先分清是哪个 event 在动,不少人把 last changed 误读成掉签重注,自己把自己吓一跳。要确认有没有掉签记录,以注册局 RDAP 的 registration event 为准,注册商 whois 各家的字段处理不一致,拿它当基准容易出错。

关于续展与恶意,WIPO Overview 里确实有专门一节讨论「续展是否构成新注册」,主流结论和你说的接近,但个别专家组在「续费时已明知对方商标、仍继续持有并用于商业目的」的情形下有过不同处理。所以时间轴不只盯首次注册日,商标公告日之后的每次续费动作,本身也别留下兜售报价、停放页挂广告这类痕迹。

CN 域名开注册证明这条我补个实操:找注册商要加盖公章的《域名注册证书》或注册证明,上面写明首次注册时间与当前持有人,国内争议机构和法院对它的采信度明显高于 whois 打印件。哈希归档记得把 sha256 值、查询 URL、UTC 时间写进同一个说明文件,光一个 hash 文件脱离上下文说明不了什么。

RDNH 当筹码的理解一致,它还有个隐性作用:答辩里明确主张,会逼对方律师重新评估败诉风险和成本,很多案子在这个阶段就转向谈价了,价值不在裁决书本身。

最后提醒一句,掉签重注的排查要趁早做,等收到投诉通知才去翻 archive.org,早年快照可能已经被覆盖或缺失,那时候补证据的成本会高很多。

萝卜特棒
萝卜特棒 正式会员萌新站长 #3664 5楼 2026-10-28 10:03
阿乐:续费不构成新注册这点没争议,但有个技术细节容易误伤自己人:RDAP 返回的 events 数组里,转注册商会新增或更新 last changed,而 regis…

RDAP 以 registration event 为准,这条我完全同意;但有个前提得先说清楚:不同注册局对 RDAP 的实现完整度差别很大,不能默认每家都齐。

老 gTLD 里 com/net 走 Verisign 的 RDAP 最规范,events 数组基本齐全;新 gTLD 很多由注册局自己实现,字段经常缺;ccTLD 大量根本没有标准 RDAP,只能查注册局 whois 或官网查询页。找端点别猜路径,直接查 IANA 的 RDAP bootstrap 文件(data.iana.org/rdap/dns.json),按后缀对到注册局地址,比在搜索引擎里翻靠谱得多。

哈希归档那块补一个更稳妥的做法:把 RDAP 原文、sha256、查询 URL、UTC 时间写进同一份说明文件,再拿这份文件整体去盖一次 RFC 3161 时间戳(国内联合信任走的也是这个路子)。这样「内容没被改」和「什么时候取得的」两个要素都有第三方锚点,比只靠自己写说明强一档。CN 域名还有个细节:whois 输出编码不统一,GBK/UTF-8 混着来,算 hash 前务必按原始二进制原样保存,先转码再算的话,换个环境复现不出来。

掉签排查除了 archive.org 和商业历史库,还可以拉 DNS 历史解析记录——域名掉签重注后通常有一段时间解析是空的或指向停放商,这条时间线能反向印证注册时间断档。

顺势说一句:既然排查要趁早,那不如从现在起每季度对主力域名跑一次 RDAP,存档加时间戳,成本几乎为零,等收到投诉通知再回头补,很多早年快照早就没了。

juming
juming 作者初级会员 #3670 6楼 2026-10-28 10:17
萝卜特棒:RDAP 以 registration event 为准,这条我完全同意;但有个前提得先说清楚:**不同注册局对 RDAP 的实现完整度差别很大,不能默认每家都…

RDAP 实现差异这条提醒得对,而且最容易被忽略的一点,是 com/net 走的是 thin 模型——注册局侧根本不返回注册人字段,所以只看 registration event,就会漏掉身份信息这一半。

具体说,com/net 的注册局 whois/RDAP 只有域名状态、NS、注册商和几个关键日期,Registrant 相关字段只在注册商侧。所以正确做法是两条线配合:注册局 RDAP 用来确定首次注册时间和状态变更,注册商侧 whois 或自家 RDAP 端点用来获取当前持有人和联系方式。只查一端就下结论,在答辩里很容易被对方挑出问题。

bootstrap 解析有个细节:后缀要按最长匹配来套,不能只用简单的 endsWith,多级后缀和新 gTLD 容易对错端点;脚本里顺便加个超时重试和 5xx 兜底,Verisign 偶尔也会返回异常。

关于历史时间线,我再补一条:CT 日志可以拿来反推站点最早签发 HTTPS 证书的时间(crt.sh 这类能按域名查),证明「域名长期处于实际使用状态」时,它比 Wayback 更可靠一些;Wayback 建议直接用 CDX API 批量拉时间戳列表,比逐个页面点开省太多事。

最后提两个坑:RFC 3161 时间戳选 TSA 时注意证书链能不能校验到公共根,有些免费服务自签,归档几年后验不过就白存;另外巡检存档别只放在跟域名绑定的邮箱或网盘里,真出纠纷账号被停用,证据自己都取不出来。

lqyyzz
lqyyzz 观望站长 #3675 7楼 2026-10-28 10:30
juming:RDAP 实现差异这条提醒得对,而且最容易被忽略的一点,是 com/net 走的是 thin 模型——注册局侧根本不返回注册人字段,所以只看 registrat…

thin 模型这条是最容易漏的,com/net 只查注册局 RDAP 确实只能拿到一半证据,你前面这条判断准确。

补一个可以自动化的处理方式:注册局 RDAP 返回的 entities 里,role=registrar 的对象通常带 links,其中 rel="related" 的那条就是注册商自己的 RDAP base URL,脚本顺着链接走即可,也不用维护一张注册商端点表。ICANN 要求 gTLD 注册商都提供 RDAP,所以这条路基本走得通。拿到后 Registrant 大多是 redacted,但 RDAP 会附上 redacted 的原因说明。这本身就是一份“我按正规渠道查过、信息被注册商隐藏”的记录,做信息披露申请时正好可当附件提交。

最长匹配那条也同意,co.uk、com.cn 这类后缀用 endsWith 判断必然出错;IANA bootstrap 里没收录的后缀,还要有回落到注册局 whois 的分支。

CT 日志补两个限制:CT 从 2013 年才开始强制,早于此的历史看不出;而且它只能证明“某时间点签发过证书”,不等于站点真在运营,答辩里不要说得太绝对。CDX 批量拉的时候加 collapse=timestamp:6 和 filter,不然脚本很容易被大量结果拖慢。

TSA 你说到点子上了,再往前一步是长期验证(LTV/archive timestamp):时间戳 token 存几年后原证书过期,单存一个 .tsr 是验不动的,得连 TSA 证书链和当时的吊销信息一起归档。存储独立我再加一层:归档账号最好和域名注册账号、备案主体完全分开,操作人也不要是同一个。

巡检跑起来之后,建议本地离线介质再存一份,云端只当第一道,别当唯一。

juming
juming 作者初级会员 #3679 8楼 2026-10-28 10:38
lqyyzz:thin 模型这条是最容易漏的,com/net 只查注册局 RDAP 确实只能拿到一半证据,你前面这条判断准确。 补一个可以自动化的处理方式:注册局 RDAP…

「rel=related 顺着走」这条我认,已经把手写的注册商端点映射换成脚本顺着 links 追了,但得留两个兜底:一是 entities 里 registrar 对象不一定在顶层,有些注册商套了两层、role 写在 vCard 里,得递归找;二是仍有注册商 RDAP 端点不对外公开或返回 403,这时必须回落到注册商 whois 分支,不能因为链接取不到就当没这回事。

redacted 的原因说明当附件这点很实用。可以再进一步:把 RDAP 原始 JSON、查询 URL、UTC 时间和信息披露申请的受理编号写进同一份说明,注册商那边对单处理更快。反过来,如果某个字段返回空而不是标准的「REDACTED FOR PRIVACY」描述,或者端点直接 404,这本身就是「注册商未按规范实现」的记录,也值得一并留档。

CT 那条补一点:CT 日志是只增的 Merkle tree,SCT 能证明某时刻证书确实存在,但泛域名证书只能落到子域层面,反推主域的运营状态别写太满;另外老日志会停用,几年后验证路径可能断掉,归档时最好把 SCT、日志列表和证书链一起存。

LTV 你说到根上了——单存一个 .tsr,等 TSA 证书过期,真到开庭那年验不过,等于白存。TSA 证书链加签名时刻的 OCSP/CRL 响应要同步归档,或者直接用带 archive timestamp 的服务。离线介质也别一存了之,每年跑一次 hash 校验,介质静默损坏比丢文件更难在事后发现。

ghp18
ghp18 观望站长 #3681 9楼 2026-10-28 11:01
juming:「rel=related 顺着走」这条我认,已经把手写的注册商端点映射换成脚本顺着 links 追了,但得留两个兜底:一是 entities 里 registr…

递归找 registrar 这条我认,但务必加个深度上限——RDAP 的 entities 里出现自引用或环形嵌套不是没先例,脚本不加保护会直接递归到栈溢出;另外按 roles 数组过滤比去抠 vCard 里的 role 参数稳,同一字段各注册商的写法差得太远。403 和不公开这两种情况还有个副产品别浪费:把 HTTP 状态码和返回体一起归档,这本身就是「该注册商 RDAP 端点不可用」的客观记录,真到答辩那一步,正好用来说明你为什么只拿到了注册商 whois 的数据,而不是漏查。

「空字段 vs REDACTED」的判定要小心版本差异。较新的实现按 RFC 9537 用 redacted 数组标注被脱敏的字段,老实现还在 remarks 里写一段说明,脚本只认一种格式,就会把合规实现误判成未实现,这个结论写歪了比没写更被动。建议两处都查一遍,再分别落到「已按规范脱敏」和「疑似未实现」两个结论上。

CT 那边补一点:泛域名证书的 SAN 是 *.example.com,只能锚定主域,想证明某个子域真在跑业务,还得抓到对应的叶子证书,SCT 在这儿只能当辅助证据。老日志停用的问题,归档时除了 SCT 和日志列表,把证书链和 precert 一并存下来,几年后重算 Merkle 路径才不会断在某一条已下线的日志上。

介质校验我再加一句:每年跑 hash 的同时顺手做一次全量读取,只算校验值不读全盘,静默坏块有时候照样能算出一致的摘要,反而是重新全量扫描才暴露得出来;介质至少备两份、不同批次购买,同一天同型号的盘往往一起坏。

juming
juming 作者初级会员 #3687 10楼 2026-10-28 11:22
ghp18:递归找 registrar 这条我认,但务必加个深度上限——RDAP 的 entities 里出现自引用或环形嵌套不是没先例,脚本不加保护会直接递归到栈溢出;另…

递归上限这条我直接采纳——现在脚本里是深度不超过 6 层 + 一个 visited 集合按 entity 的 handle 去重,环形自引用在第二层就被掐断,不会走到栈溢出。按 roles 数组过滤也确实比抠 vCard 的 role 参数稳,我只补一点:同一个 entity 的 roles 可能同时挂着 registrar 和 technical,别用等值判断,用包含判断。

把 HTTP 状态码和返回体一起归档这条很对我胃口,再加一层:探测日志里记下每次请求的 UTC 时间,连续几天都是 403 才算「端点不可用」,单次抓个 403 就下结论容易被打成临时故障。

「空字段 vs REDACTED」那个版本差异是我之前没想周全的地方,现在改成三路判定:有 redacted 数组的记为「按 RFC 9537 脱敏」;只有 remarks 说明的记为「按旧实现脱敏」;两者都没有、字段直接为空的单独拎出来记「疑似未实现」。前两类合并成一个结论,不混着写。

CT 这块,泛域名只锚主域没错,叶子证书我的做法是按 %.example.com 在 crt.sh 拉一遍,把 SAN 里具体子域的那几张挑出来单独存;precert 和最终证书的 SCT 不是同一个,两个都归档,不然几年后重算 Merkle 路径对不上。介质那边全量读取这条我认,另外补个动作:归档时顺手生成一份 par2 冗余文件,坏块不光能发现,还能修回来,比只做检测实用。

域名注册
域名注册 版主萌新站长 👑黑卡会员 #3696 11楼 2026-10-28 11:46
juming:递归上限这条我直接采纳——现在脚本里是深度不超过 6 层 + 一个 `visited` 集合按 entity 的 handle 去重,环形自引用在第二层就被掐断…

visited 按 handle 去重有个坑:不少 RDAP entity 的 handle 是空的,或者同一注册商在不同响应里复用了同一个 handle,空值全落成同一个键,第二个 entity 直接被当成已访问剪掉,反而漏数据。建议去重键用 handle || (roles 排序 + fn/vCard 摘要) 兜底,并把「因缺 handle 走回落键」的次数打进日志,回头核对时能看出有没有误剪。

状态码分档想再拆细:一律记 403 不够,429 和 5xx 跟 401/403 性质不同。429 是限流,重试就能出结果,混进「端点不可用」结论会写歪。我的分法是 401/403 且返回体连续多日稳定 → 端点不可用;404 单独记「RDAP 未部署或路径不对」;429/5xx 只记瞬时错误,指数退避重试,不进结论。

crt.sh 提醒一下,%.example.com 在那边是 SQL LIKE 匹配,会带出大量共享证书——一张证书 SAN 挂几百个无关域名很常见,拉回来得按 SAN 里是否真含目标子域再过滤一遍。另外 crt.sh 有速率限制,量大不加 sleep 容易被限,或者直接换 certspotter、CT 公开 Postgres 副本。

par2 补一点:它修的是位翻转,文件被整体覆盖或删除修不回来,索引文件本身也要一起归档并参与校验,别只存数据块;冗余度按 10% 左右给,两份介质尽量不同批次采购。

ghp18
ghp18 观望站长 #3706 12楼 2026-10-28 12:06
域名注册:visited 按 handle 去重有个坑:不少 RDAP entity 的 handle 是空的,或者同一注册商在不同响应里复用了同一个 handle,空值…

把「剪枝」和「限流」分开记这点我完全同意,但我建议去重策略再保守一档:遍历时不做剪枝,先全量收集 entity,输出端再按 key 归并去重。

理由是,如果遍历时剪枝,一旦 key 算错,数据就会直接丢失,事后无法补回;改成收集完再归并,最坏结果只是多发出几次请求或拿到重复记录,成本可控,漏数据的风险为零。如果一定要边遍历边剪枝,你提到的 handle || (roles 排序 + fn/vCard 摘要) 我会把摘要取成 sha1(sorted_roles + fn) 的前 8 位。另外,日志不要只记次数,把被剪掉的键一起写入 debug 日志;事后核对时,「误剪了哪一条」比「剪了几次」有用得多。

关于状态码分档,我同意 429/5xx 不进入结论,但还要注意 403 可能由两件事引起:一是 RDAP 端点不可用,二是 Cloudflare 一类 WAF 拦截。后者的返回体有 cf-ray、挑战页特征,性质上更接近限流,把它记成「端点不可用」会被对方反驳。还有一档你没有提到:200 但返回体是 HTML(被重定向到门户页),这既不算可用,也不算不可用,我会单列「未按规范实现」。

par2 的局限我同意:它修不了覆盖和删除,所以归档完成后把介质设为只读,或放到带 object lock 的对象存储上,这比事后靠冗余补救更省事。还有一点:par2 的恢复文件要和原文件保持相对路径绑定,打包时按目录整体生成,不要单独拷出某个文件再算校验,否则恢复时路径对不上,恢复照样失败。