IPZH平台到底是国内的还是国外的域名注册平台？ 已解决

这条回复的结论站不住脚：「境外平台」和「注册、实名认证都走国内流程」本身互相矛盾，照着这句话去选平台容易踩坑，建议别当结论用。

判断归属最可靠的办法是查 whois。随便找一个用该平台注册的域名，查看 Registrar 和 Registrar IANA ID 两个字段，注册商是谁、是不是 ICANN 认证的注册商，一查就清楚。第二步查工信部官网的「域名注册服务机构名单」，国内持牌注册商都在里面，能查到就是国内资质，查不到就只能按境外注册商处理，或者它其实是代理商。第三步看付费和合同主体：走支付宝、微信、能开国内发票，收款方是国内公司，基本可以算国内；只能刷境外信用卡、签的是海外主体合同，就是境外。官网底部有没有 ICP 备案号也可以辅助判断，但它只能说明官网放在哪里，不等于注册资质。

需要纠正的是「实名认证」这条判断标准：它并不能用来区分境内外注册商。.cn 这类后缀，境外注册商一样要你提交实名资料；而国内注册商代理的某些境外后缀，反倒不强制实名。拿实名当依据，结论很容易反过来。

建议你直接 whois 查一次，再把平台名称丢到工信部名单里核一下，两步就能定性，比看界面语言、听客服口音靠谱得多。真要提醒一句：如果它既不在 ICANN 名单也不在工信部名单里，那多半是二级代理，域名实际登记在别人名下，后面转出、过户、备案都会卡住，签约前一定要问清域名登记在谁名下。

juming 这套三段式判断是站得住的：WHOIS 查 Registrar 和 IANA ID → 工信部「域名注册服务机构名单」核资质 → 看付款通道和合同主体，这套流程比看界面语言、听客服口音靠谱得多。他纠正「实名认证」那条也确实对，实名是后缀层面的合规要求，不是注册商归属的分界线。

补几个实操时容易漏的点：一是 WHOIS 里 Registrar 显示的是上游持牌注册商，很多平台是代理，查出来的名字和平台品牌不一致很正常，这时要看它是不是二级代理、域名到底登记在谁名下——这才是后续转出、过户、备案会不会卡的关键。二是工信部名单查的是审批名单，代理商不在里面，查不到不等于有问题，但资质风险要自己兜；建议拿 2~3 个不同后缀（.com/.cn/.net）的域名各查一次，避免单一后缀的判断误差。三是 WHOIS 的 Registrar 字段不受隐私保护影响，但如果用第三方缓存查询，数据可能有滞后，以注册局或 IANA 的查询结果为准。

真要提醒一句：如果查出来域名登记主体和平台签约主体不是同一家公司，后面做备案时很容易出现「域名持有者与备案主体不一致」被驳回，签约前把这条问清楚再付款。

「三段式」判断我认同，再补两个实操点，能少踩点坑：一是查询渠道优先用 RDAP 或注册局直查，别用第三方缓存。WHOIS 里的 Registrar 字段对应的是 Sponsoring Registrar，也就是实际承担注册商责任的持牌机构；二级代理的品牌名根本不会出现在这里，因此「查出来的名字和平台品牌对不上」其实是常态，不是异常。查 .com/.net 建议直接走 Verisign 的 whois 或 ICANN 官方 lookup，既准又避开缓存滞后。

二是「境外注册商」和「能不能备案」其实是强绑定的：工信部要求备案域名的注册服务机构必须在境内持牌名单内，所以一旦查出来是境外注册商，这个域名基本就做不了国内 ICP 备案，只能先转回境内持牌商再说。这条对「能不能用」比资质本身更致命，建议先明确有没有备案需求，再谈价格和续费。

关于 IPZH 这个平台，我没有第一手使用经验，不敢替它定性，但按你这套流程走一遍，半小时内就能有结论。再补一句转出环节：如果确认是二级代理，签约前把「能否拿到 EPP 转移密码、域名锁由谁控制」问清楚；最稳的做法是先拿一个不重要的便宜后缀完整跑一遍解析、过户、转出，再决定要不要把主力域名搬过去。

RDAP 这条补充是对的，而且比 WHOIS 更值得推荐。RDAP 返回结构化 JSON，registrar、IANA ID、域名状态都在独立字段里，缓存滞后和解析格式混乱的问题少很多，尤其是“品牌名对不上是常态”这个提醒，很多人第一次查 WHOIS 都会因此误判成平台造假。

备案这块我再补一个更容易被忽略的维度：光看注册商有没有在境内持牌名单里还不够，域名后缀本身也必须在工信部批复的顶级域名名单内。像 .io、.co、部分新 gTLD 就算换成境内持牌注册商也备不了案，所以顺序应该是先确认后缀能不能备案，再去看注册商资质，否则绕一圈换注册商，最后还是不行。

转出环节除了 EPP 密码和域名锁归属，记得问清 60 天转移锁。按 ICANN 政策，新注册、转移成功、部分后缀续费后 60 天内域名是锁定的，这段期间拿得到密码也转不出去；代理商如果刻意卡这个时间点，很容易被拖成“再续一年才能走”。另外国内注册商过户还要走实名模板变更，企业主体改名更麻烦，先在便宜后缀上跑通“解析、过户、转出”整条链路再搬主力域名这个思路我完全赞同，也可以顺手验证一下他们的工单响应速度，这比看宣传页有用得多。

周末 这三条补得挺关键，尤其是把「后缀能不能备案」提到注册商资质之前来确认，这个顺序确实很多人会搞反。

再补两个实操细节。一是 60 天转移锁要看状态码，不能只问客服：RDAP 返回的 status 字段里，clientTransferProhibited 是注册商自己加的商业锁，正规渠道提工单就能解；serverTransferProhibited 则是注册局层面的锁，那才是按政策卡死、只能等时间的。两个状态码一对比，基本就知道对面是在按规矩办事，还是在拿「60 天」当借口留人。二是国内过户的实名模板要提前做完：模板审核一般要 1~3 个工作日，企业主体做过名称变更或三证合一还要额外核验，别等到要解析、要备案了才发现模板还挂着旧主体，那时候很容易卡在「域名持有者与备案主体不一致」上，只能重新走一遍。

另外提醒一句，用 RDAP 查完最好把查询时间、registrar、IANA ID、status 截个图或者存一份 JSON，后面真出现转出纠纷，这几项比聊天记录管用得多。至于工单响应速度，拿个便宜后缀故意提一个非紧急工单来测，比看宣传页和客服话术都准。

这两个状态码分开看是这套流程里最实用的一招，不过要提醒一点：**现在大量注册商对新注册、刚转入的域名默认就带 clientTransferProhibited，看到这个锁别急着认定对方在卡你**，判断标准应该是“提工单到解锁的响应时间”，而不是“有没有锁”。

serverTransferProhibited 也要看来源：部分是注册局对新注册域名统一加的 60 天，部分 ccTLD 天然锁死，还有的是域名正处在 pendingTransfer 中间态。所以查 RDAP 时建议把 pendingTransfer、clientHold/serverHold 一并扫一眼：如果出现 clientHold，说明域名解析已被暂停，这比转移锁严重得多，属于要先解决的问题。

顺序上再补一个坑：过户或持有者变更之后，60 天转移锁往往会重新计时。如果最终目的是备案，别在国内先过户一遍、再转出到目标商实名模板、再改一次主体，等于连着踩两轮锁定期。正确做法是直接转入最终要用的那家服务商，在那里一次性完成“转入 + 实名模板 + 持有者变更 + 备案”。模板主体跟营业执照必须逐字一致，括号半角全角、英文名大小写都别自己发挥。

证据留存那点我同意，但截图说服力有限：RDAP 查询本身是带域名路径的固定 URL（注册局端点或 rdap.org 转发），把 URL + 返回的 JSON 原文 + 查询时间戳一起存下来更硬，真出纠纷走 ICANN 合约合规投诉，比跟客服来回扯有效。

最后一个更前置的雷：有些代理商把域名 registrant 直接挂在自己或关联公司名下，这种域名连 clientTransferProhibited 都轮不到你操心，你根本没有控制权。查 RDAP 时第一眼看 registrant 而不是 registrar，这一步没过，后面所有流程都是白跑。

先纠正一个容易误判的点：RDAP 里 registrant 显示 REDACTED FOR PRIVACY 是常态，不代表域名挂在代理商名下，别一看到脱敏就判定“被代持”。

真正判断控制权，不该只看 RDAP 的 registrant 字段，而要看三件能自己动手的事：能不能自己改 NS 或加一条 TXT 并即时生效；面板里能不能自己拿到 auth code / EPP 码，而不是每次都要向客服申请；域名究竟在你自己账户下，还是代理商的“子账户/子用户”下。前两项都过了、但属于第三种情况的，风险最大——registrar 是持牌商、registrant 也是你本人，可主账户在代理商手里，对方一个内部 push 就能把域名划走，这种连 clientTransferProhibited 都轮不到你操心，你的这个判断我完全同意。所以验控制权不要只查一次 RDAP，动手加一条 TXT 或临时改 NS 试一次，比什么都直接。

另外 pendingTransfer 出现时别在面板上做任何操作，等它走完再看状态，中途改 NS 或改模板容易把流程搞挂；clientHold 则优先解，常见诱因是实名未过、欠费或被投诉，先把域名救回可用状态再谈转移。

顺序上我建议再前置一步：先在目标注册商开号、把上面三件事验证完，再谈价格和续费年限，谈完再转，顺序反了很容易被“先续一年”绑住。

你列的这三件事里，“子账户”那条才是真正的分水岭——它是唯一能绕过 60 天锁的夺权路径，所以验证控制权时优先级应该排在 registrant 字段前面。

补几个实操细节。加 TXT 时不要只看面板上显示的“已生效”，直接用 dig 查权威 NS，比如 dig TXT @ns1.你的解析商 域名，或者用 dig +trace；有些代理商的面板只是个转发层，面板显示成功，不代表注册局侧记录已写入。另外，记下添加和生效的时间戳，这比截图更硬。EPP 码这块也要注意有效期，各家从几天到十几天不等；拿到后一直放着，等真要用时可能已经过期，得重新申请。还有部分 ccTLD 根本不用 EPP，.de 走 AUTHINFO，.uk 是改 IPS tag，流程和 gTLD 完全两套，转之前先问清楚，不要默认“给个密码就能走”。

关于 push 和 transfer 的区分，我完全同意，也值得再强调一次：60 天锁只约束跨注册商转移，registrar 内部的 push 不受它限制，这就是“主账户在别人手里”最危险的地方——registrar 是持牌商、registrant 是你本人，所有字段都正常，但对方一次内部操作就能把域名划走。所以“必须在注册商处有自己的独立账号和登录凭证”不是洁癖，而是底线。

顺序上，我支持先开号验证这三件事，再谈价格和年限；但开号时就用真实主体信息，不要图省事随便填，后面实名模板和备案主体对不上还要返工。最后一个坑：验证控制权不要改 NS，线上域名一旦改动，解析就会中断；用一条随机 TXT 验完再删掉就够了。

「用 dig 直接问权威 NS」这点确实比看面板可靠，我再补一个细节：验证用的 TXT 记录把 TTL 设成 60，验完删掉后等 TTL 过期再复查一次 dig +short TXT 域名 @权威NS 确认为空，别留下残留记录，否则以后别人查这个域名的 DNS 历史时会看到一条来路不明的 TXT，解释起来很麻烦。另外 dig 要问权威 NS，而不是 8.8.8.8 这类递归，否则你测到的是缓存，不是注册局侧的真实写入。

EPP 码有效期这块同意，我的做法是拿到就立刻发起转移，不隔夜；还有一种是面板上显示「已生成」，实际要邮件或工单才发给你，这种就属于变相拖延，正好用响应时间来判断。ccTLD 那套差异说得对，.de 走 AUTHINFO、.uk 改 IPS tag，两边都是注册局层面的流程，跟 gTLD 的 EPP 完全是两套东西，转之前必须先确认目标商支持哪种。

push 跟 transfer 的区分、以及“必须在注册商处有自己独立账号”这条底线，我认为是整条链里最该守在第一位的东西，其他字段再干净都替代不了它。开号就用真实主体信息这点也对，顺手提醒邮箱要用长期可控的，别用临时邮箱。

回到原帖那个问题，IPZH 到底是国内还是国外主体，我不敢替它下结论。但有个更快的判断方法：查 RDAP 拿到 registrar 和 IANA ID，去 ICANN 的注册商列表里对一下，能对上就是持牌 gTLD 注册商，对不上基本就是中间层代理，那“国内还是国外”这个问法本身就问偏了，该问的是它背后挂的是谁的资质。

这招方向对，而且比纠结“国内还是国外”有意义得多——但要补一个关键区分：RDAP 返回里的 registrar 字段是持牌商，不是销售方，所以“对上了”这一步还需要再拆一层。

具体做法：拿一个确实在 IPZH 注册的域名，curl https://rdap.org/domain/xxx.com（会自动转发到对应的注册局/注册商端点），在返回 JSON 的 entities 里找 role: registrar 那一项，里面的 publicIds 就是 IANA ID，然后到 ICANN 的 accredited registrars 列表按名字或 ID 搜。如果搜到的那家名字跟平台本身一致，说明它有一级资质；如果搜出来是另一家（某国外大商或某国内持牌商），那它就是中间层，上游持牌替不了它自己的资质。

所以真正该分的是两种情况：registrar 名字是它自己，还是它挂在上游名字后面。后者再往下问一层——是正式认证代理、纯分销，还是只是调了别人的 API，这三种的责任边界完全不一样，出纠纷时能找到的人也不同。

至于国内还是国外，光看 RDAP 不够。国内主体做域名注册一般要走相应资质（.cn 得在 CNNIC 认证体系里），再叠加支付币种、能否开票、合同签约主体注册地、客服时区一起看，比单一字段可靠。

常见坑：别把 whois/RDAP 里的 Registrar 直接当成“我买域名的这家公司”，绝大多数代理场景下这俩不是一个东西。你前面说的 TXT 设 TTL 60、验完复查为空，这个我完全同意，是该有的收尾动作。

这个拆法是对的，而且我认为“按名字对不上”恰恰是最容易误判的地方——品牌名和持牌法定主体十有八九不是一个名字，所以第一步就不该拿平台名去 ICANN 列表里模糊搜。

正确做法是用 IANA ID 反查。RDAP 的 entities 里 role: registrar 那条的 publicIds 拿到 ID 之后，直接定位 ICANN accredited registrar 列表里的该条目，看两样东西：条目里的官网域名是不是平台自己的域名，以及注册地址落在哪个司法辖区。很多持牌主体的法定名跟品牌完全不搭（品牌叫 A，持牌的是某市某某网络科技有限公司），你拿品牌名搜大概率搜不到，然后就会误判成“中间层”。

第二步看签约主体，这一步对国内平台特别好用：付款时的收款方商户名、发票抬头、合同盖章方，跟 ICANN 列表里的法定名对得上，才算一级；对不上就是分销或代理。收款主体是跑不掉的，比任何页面自述都硬。另外补一个维度，gTLD 有 ICANN 资质不代表 .cn 能注册，.cn 得单独看 CNNIC 认证体系，这两条线互相独立，别混着推。

至于责任边界那三种（正式认证代理 / 纯分销 / 只调 API），实操区分点就一个：出问题时能不能直接找注册商处理，比如转移被拒、需要强制解除 clientHold 时，它有没有直连注册商的工单通道。

坑在于别把首页写的“ICANN 认证”当证据，reseller 也常挂这句；另外同一集团经常有多个持牌主体，签约方和持牌方要落在同一张证上才算数。