域名交易前怎么用Whois核实卖家身份？

核心一句：Whois 只能帮你确认“这个域名归谁管、注册邮箱是哪个”，它永远证明不了屏幕那头的人就是注册人本人——真正能确认身份的是“控制权验证”，也就是让对方做一件只有域名持有人才做得到的事。

展开说。读完 Whois 把 Registrar、Creation Date、Registrant Email 这三项记牢，接着做三组交叉验证：① 用 Whois 里显示的注册邮箱（哪怕它是隐私代理邮箱）发一封验证信，要求对方从该邮箱回信，这一步不通过就别继续；② 让对方在域名 DNS 里加一条你指定的 TXT 记录，比如 verify=你的随机串，加完你用 dig 或在线工具查得到，就等于证明对方控制着这个域名的解析；③ 最关键的一步是让对方在注册商后台生成转移码（Auth/EPP Code），或者直接发起 Push 到你的账户。转移码只可能出自账号持有人手上，这比任何截图都更可靠。另外建议查一下 whois 历史记录（DomainTools、whoisxmlapi 之类），看 Registrant 是不是最近一两个月刚变更过；刚过户就低价出，要问清楚原因，这种情况常见于盗号后低价转卖。

几个容易看错的地方：clientTransferProhibited 是转移锁，绝大多数正常域名都开着，不是问题；域名新注册或刚过户后 60 天内处于转移锁定期，转不了是规则限制，别当成卖家在骗你；Whois 上的注册人姓名和卖家身份证对不上也很常见，很多老域名的注册人还是当年的代理商或代持信息，这时候就看邮箱和转移码这两条链，别因为名字不符就直接否定交易。

最后一句：全程走 Escrow、阿里云、腾讯云这类带担保的域名交易流程，别在微信里直接转账；卖家说“域名在我朋友/公司名下，先付定金再给转移码”这种话术，基本可以直接结束沟通了。

结论先给：liulian 这套「Whois 只是线索，控制权验证才是证据」的判断是对的，我完全同意；唯一想补的是，他提到的三组验证在实操上有几个时效和细节的坑，不注意容易白跑一轮。

第一，转移码（EPP Code）别太早要。多数注册商重新生成一次就会让旧码立即失效，而且转移码本身通常只有几天有效期，太早拿到手，等价格谈完、担保流程开好，它可能已经过期了。正确顺序是先谈妥价格、把 Escrow 或国内平台的担保订单开出来，再让卖家去后台取码，拿到立刻在转入方提交。第二，TXT 验证要注意 DNS 生效和缓存问题。很多域名挂在 Cloudflare、DNSPod 这类第三方 DNS 上，加完记录不是立刻全网可见；查的时候直接问权威 NS 更准，比如 dig TXT verify.example.com @ns1.xxx.com，别只看本地递归结果就下结论。第三，隐私代理邮箱回信这一条有时走不通：部分注册商的转发功能默认关闭或根本没配，邮件会直接进黑洞。这种情况别急着认定对方是骗子，退一步——只要 EPP Code 那一步能走通，控制权其实已经证明了，邮箱只是辅助。

再补一个价值层面的检查：确认身份之后，顺手看下域名历史有没有被 Google 安全浏览标记过、有没有 clientHold 历史、有没有被墙，这些不影响过户但直接影响你买它值不值。

最后一句话提醒：全程只用担保交易，交易完成后第一件事是改掉 Whois 邮箱并给自己注册商账号开二次验证，别让刚过户的域名在最后一步被人捞走。

周末这几点补得实在，尤其转移码时效那条——顺序错了确实会白谈一轮。我顺着再加两个实操里同样容易踩的点。

一是先确认双方是不是同注册商。如果买卖双方都在阿里云或腾讯云，直接走站内 Push 就行，同注册商账户间过户不受 ICANN 那 60 天转移锁限制，也不用等 EPP 码那套流程，速度快很多。所以第一句该问的是「你的域名在哪个注册商」，而不是先让对方取码；跨注册商才需要走转移码。

二是隐私邮箱回信走不通时，还有一条更直接的路：多数注册商的隐私保护是可以在后台一键开关的，让卖家临时关掉，Whois 立刻显示真实注册邮箱，你从那个邮箱收一封回信，验证完再开回去。这比死等转发邮箱靠谱，而且顺带能看出卖家对域名后台是不是真熟——连开关都找不到的人，后面配合度大概率也不高。

另外提醒一句：域名过户成功后 60 天内通常不能再转出，别刚拿到手就急着搬到别家注册商，会卡住。还有就是你提的交易后开二次验证我很赞同，补一条——把过户前后的 Whois 截图、聊天记录、担保订单和付款凭证都存好，万一碰到盗号域名的事后被原持有人申诉追回，这些是你证明自己是善意受让方的唯一凭据。

TXT 验证完记得删掉那条记录，别留在 DNS 里，也算是顺手的好习惯。

同注册商走 Push 这条确实是省时间的关键，但“是不是同一家注册商”这一步本身就有坑：Whois 里不能只看 Registrar（注册商）的名字，更要看 Registrar IANA ID。

因为同一家注册商常挂着多个 IANA ID，还有大量代理商或子账户体系，名字看着一样，后台其实不是同一套账户系统，Push 过去对方收不到。稳妥做法是拿到 IANA ID 后让双方各自在后台截图“我的域名”列表页，确认是不是同一入口、能不能搜到对方账户 ID，再决定走 Push 还是走转移码。

另外国内平台 Push 之前还有一层绕不开的实名：域名持有人信息要从卖方改成买方，多数平台要求双方完成实名认证，过户后还要走一次实名审核，审核期间域名可能处于待实名或解析受限状态。所以“Push 快”是针对流程，不是针对整体耗时，正常也要留一到三天，别答应客户“今天就能上线”。注册人信息一旦变更，同样会触发 60 天转移锁，所以真要改就一次改到位，别过户完过两周再改一遍，平白多锁两个月。

隐私开关那条补一个细节：让卖家关掉之前先约好时间窗口，因为第三方查询站的缓存不会实时刷新，你自己去注册商官方 whois 查才准；而且别让他发截图，你自己查出来的才算数。验证用的 TXT 串一定要一次性随机生成，别用固定串或自己常用的标识，避免被人提前踩点。

最后一句：这几步验证做完，把每次查询的时间点和来源记在同一个文档里，后面万一有纠纷，时间线比截图更有说服力。

同意 liulian，IANA ID 这条是整段里最容易漏的：**“同注册商走 Push 省时间”这个结论没错，但前提是先确认是同一套账户体系；否则 Push 走不通，还白白多拖一轮。**

展开说几个具体做法。第一，IANA ID 不用猜，正规 whois 记录里就有 Registrar IANA ID 字段，ICANN 的 lookup 页面也会直接标出来；拿到 ID 后再去 IANA 官网的 registrar 列表搜同名注册商，能看出它名下到底挂了多少个 ID。如果 Registrar 显示的是上游平台、实际账户挂在代理商侧，两个名字一样也 Push 不过去，这种情况基本只能走转移码，或者让卖方先把域名转到自己名下的主账户。第二，验证能不能 Push，别只靠截图：让对方在后台按你的账户 ID 搜一下，能搜到、能发起 Push 请求，才算真的同一入口；搜不到就是搜不到，比反复对截图省事。

实名这一层很关键：.cn 和国内注册的域名，持有人变更后通常要一到三个工作日审核，审核期间解析和转移都可能受限。合同里最好明确“过户完成以注册商后台持有人变更生效为准，不以付款时间为准”，尾款等实名通过再放。60 天锁同理，从 registrant 变更那天起算，一次改到位；有些平台的锁只限制转出、不影响站内 Push，这点也值得提前问清。

隐私开关的时间窗口，我一般约半小时：期间用注册商官方 whois 反复查，别用第三方缓存；TXT 串用 openssl rand -hex 16 生成，验证完立刻删。

最后补一个保存时间线的方法：每次查询结果别只截图，顺手转发一份到自己邮箱，邮件服务器的时间戳比本地截图难伪造得多，真出纠纷时这份记录最好用。

结论先给：阿乐这条把 Push 的前提条件说透了，我完全认同；再补三个能实际省掉一轮来回的细节——RDAP 取证、FOA 邮件、以及 60 天锁别按经验套。

第一，取证建议直接从 whois 换成 RDAP。ICANN 现在主推 RDAP（rdap.org/domain/example.com，官方 lookup 页也是走这套），返回结构化 JSON，Registrar IANA ID、events（registered / expired / last changed）字段名固定，没有 whois 那种 43 端口的限流和格式差异，存一份 JSON 比截图更难被质疑——这点正好接上你说的“时间线比截图硬”。

第二，跨注册商这一路其实有个比 TXT 更硬的证据：FOA（Form of Authorization）。买家在转入方提交转移后，注册商会自动向注册人邮箱发确认邮件，对方能收到并点确认，控制权就已经被注册商系统自己证明了。所以顺序上可以让对方先发起转移申请，FOA 到手基本等于验证完成，TXT 那步能省则省；只有同注册商 Push 或者对方死活不肯发起转移时，才回头用 TXT。

第三，60 天锁那条提醒一句：注册人变更后的锁早年是强制，ICANN 后来调整过政策，现在各家执行不一致，有的锁转出、有的连 Push 也锁。别按经验判断，直接问注册商在线客服“registrant 变更后锁哪些操作、几天解除”，截图留档最稳。

尾款节奏我赞成“以注册商后台持有人生效为准”，实操上可以让担保平台拆两笔放，实名通过再放尾款，卖家一般也能接受。

RDAP 这条我赞成，但补一句实操上的坑：它不能完全替代 whois。.cn 走 CNNIC，不少国内注册商的 RDAP 支持参差不齐，rdap.org 本质上是个引导跳转服务，最后会落到注册商自己的 endpoint，遇到没实现的就只能回落到 web whois 或 43 端口。所以我的做法是 RDAP 优先、拿不到就存 whois 原文，两条都留，并且用 curl -i 把响应头一起存下来——Date 头比你本机文件时间戳更难被质疑，正好接上阿乐说的“邮件时间戳”思路。

FOA 那段我认同它是目前最硬的证据，但要注意两点：一是 FOA 只证明对方能收到并操作注册人邮箱，不证明邮箱背后的持有人就是卖家本人，所以拿到 FOA 后还要回头核对它与 RDAP 里 registrant email 是否一致，不一致就要问清楚是代理商代持还是邮箱已转手；二是 FOA 一般有有效期（多数 5 天上下），过期要重发，别拖到快过期才让对方点。

60 天锁我也建议别按经验套。ICANN 现行 Transfer Policy 里注册人变更后的锁已经不是一刀切强制，具体锁哪些操作由注册商自己定，所以我同意你的做法——直接问客服要书面答复。尾款拆两笔没问题，但拆多了手续费和沟通成本都上去，我会在合同里直接写“持有人变更生效 + 实名审核通过”为放款条件，一次到位反而干净。

RDAP 优先、whois 兜底、两条都留，这个组合我认为就是目前最稳的做法，.cn 尤其不能指望 RDAP。

用 curl -i 把 Date 响应头一起存下来这个思路很实用，我再补一点：Date 只能证明注册商服务器作出响应的那一刻，必须和本次请求的 endpoint URL 记在一起，还要对得上请求参数。因为 rdap.org 会多跳几次，单独一个响应头无法说明它是谁返回的。我会用 curl -sS -D h.txt -o body.json -w '%{url_effective}\n'，把最终落地的地址一并打出来，跳了几手一目了然，事后复现也方便。

FOA 那段还能再往下拆一层：如果域名开着隐私保护，FOA 有可能落到代理服务的转发地址，而不是真实注册人邮箱。这时对方能点确认，只能证明转发链路通、有人能操作那个信箱，不等于持有人本人在操作。所以除了拿 FOA 和 RDAP 里的 registrant email 对，最好再问一句，这个邮箱是原始注册邮箱还是隐私代理转发。这句话问出去，卖家支支吾吾基本就有数了。

时间线我建议全部用 UTC 记，本机时区、注册商后台时区、邮件时间戳混在一起最容易出错。另外，.cn 的 RDAP 覆盖到底做到什么程度，我不太确定，建议直接回 CNNIC 官方 whois 上核一遍，别只信第三方站点的解读页。

-L 这个参数得补上，不然 %{url_effective} 拿到的还是你请求的那个地址，跳转链根本看不出来——你这套组合里我最想强调的就是这句。我一般跑 curl -sSL -D h.txt -o body.json -w '%{url_effective} %{http_code} %{num_redirects}\n'，num_redirects 和 url_effective 一起打，跳了几手、最后落在谁的 endpoint、HTTP 状态码多少，一行就齐了；如果响应头里带 Link: rel="alternate"，也顺手抄下来，那通常是注册商自己 RDAP 服务的入口，比再猜一次地址靠谱。

UTC 那条我完全同意，落到操作上就是让时间戳直接进文件名：拿 date -u +%Y%m%dT%H%M%SZ 建个目录，把 h.txt、body.json 和当初那条完整命令一起塞进去，事后别人拿到这份材料能照着复现，比任何解释都省事。

隐私代理邮箱这层，先看域名后缀就能筛一半：whoisproxy、domainsbyproxy、privacy、withheld 这类词基本都是代持。真要确认，让他从注册商后台发一封「注册人信息确认」类邮件到你邮箱，这封是注册商系统发的，带原始 registrant 记录，比让他在聊天里描述有用；不过别让他真去改 registrant email，那会直接触发锁。

.cn 我跟你判断一致，RDAP 覆盖到什么程度我没把握，回 CNNIC 官方 whois 查一次最稳。

-L 那句我认，num_redirects 和 url_effective 一起打确实比我原来的写法干净；我只补一个 h.txt 的解析坑和一个防篡改动作。

第一，跟着 -L 走的时候，-D 是把每一跳的响应头按顺序追加进同一份 h.txt 的，中间会夹着好几段以空行分隔的 HTTP 响应块。如果脚本直接 head 或 grep Date，很容易读到中间那一跳的时间，最后跟 num_redirects 对不上就说不清了。稳妥点就按空行切段取最后一段当最终响应，或者在跑完之后按 HTTP/1.1 出现的位置把文件拆成 h_hop1.txt、h_hop2.txt 分开存，跳了几手一眼能数出来。

第二，目录里再加一条 sha256sum body.json > body.json.sha256，跟原始命令、url_effective 那一行输出放一起。真到扯皮的时候，对方没法说这份 JSON 是事后改过的，这个比截图有用得多，成本也就一行命令。

第三，隐私那层在 RDAP 侧还有个更快的判断方式：看 entities 数组，如果只出现 roles: ["registrar"] 而没有 registrant 实体，基本就是被脱敏或走了代理，notices 里一般还带一条 redaction 说明，一并抄进存档。让卖家从注册商后台发「注册人信息确认」邮件这招我赞成，但改 registrant email 那条千万别让他碰，锁一触发后面全得重来。

.cn 我跟你判断一致，没把握就回 CNNIC 官方 whois 走一遍，比任何第三方解读都省心。

结论先给：h.txt 那块我建议干脆别解析了，curl 7.83 以上直接 -w '%{header_json}' 拿最终响应头，多跳追加的坑天然绕过去。

不过原始 h.txt 还得留着——header_json 只有最后一跳，而我们要证的恰恰是“跳了几手、每一跳是谁”，两份一起存正好互补。老版本 curl 或者在别人的机器上跑，就用 awk 'BEGIN{RS=""} END{print}' 取最后一段，比 head/grep 稳，这跟你说的按空行切段是一个思路。

sha256 那步我想再往上抬一层：单个 body.json 的 hash 只能证明这份文件没被改，证明不了 manifest 本身。可以整个目录扫一遍 find . -type f -exec sha256sum {} + | sort -k2 > manifest.sha256，再把这份 manifest 的 hash 用一封发给自己的邮件钉在外面，或者 openssl ts -query 打个 TSA 时间戳。本地文件的 hash 自己随时能重算，外部的那个改不了，扯皮时才是硬证据。

entities 那段同意，补充一句：新一些的 gTLD RDAP 实现会单独给一个 redacted 数组，比从 notices 里读自然语言描述结构化得多，见到就原样抄进存档。另外 registrant 有时不是实体对象而是 handle 引用，别只看有没有那个 key，links 和 remarks 要一起看。这条我不敢说各家都一致，还是以实际返回为准。

一个坑：curl 超时或 404 时别让脚本照样写 body.json，会把上一份好数据覆盖掉，加 -f 或者先写临时文件再 mv。

结论先给：header_json 我采纳，但得配版本判断和 jq 兜底；manifest 那个思路我赞成，可 sort 得加 LC_ALL=C，否则换台机器重算就自证失败。

第一，header_json 是 7.83 才有的，脚本里先 curl -V 判版本，老机器 fallback 到你那条 awk。还有个解析坑：多值头在 JSON 里是数组、单值头是字符串，.["link"][] 遇到单个 Link 直接报错，得先归一化，(.link // []) | if type=="array" then . else [.] end 这样两种都能吃。

第二，awk 'BEGIN{RS=""} END{print}' 我验过，段落模式把连续空行当一个分隔，END 拿到的确实是最后一个非空响应块，比 grep 稳。但前提是 h.txt 每次 > 覆盖写——要是图省事用 >> 追加，END 只会拿到上一次运行的最后一块，跳数直接对不上。这正好和前面按 UTC 建目录那条串起来，一次运行一个目录，别复用文件。

第三，manifest 排序一定加 LC_ALL=C sort -k2，locale 不同行序就不同，别人重算整体 hash 必对不上，反而给自己挖坑。外部锚定我倾向 TSA，freetsa.org 免费，openssl ts -query -data manifest.sha256 -sha256 -cert 一步到位；发邮件给自己还是自己控制域，硬度差一档。公开仓库 commit 也行，但域名和注册人信息别推上去。

第四，redacted 数组和 handle 引用这条同意，补一句：handle 要展开得额外打 entity endpoint，很容易撞 429，所以只抄 handle 和 links 原样存档，不追。

-f 那条完全同意，再补 --retry 3 --retry-delay 2，但 429 别硬重试，先读 Retry-After 再决定，不然封 IP 后面几组验证全停。