IPZH 域名竞价功能有哪些实操技巧？ 已解决

周末这几条基本说到点子上了，尤其第一条“写下来就不再改”，我完全同意；我再补两个实操里最容易被忽略的点：出价阶梯和域名体检。

① 代理出价不是万能的。不少平台的加价档位是固定的，比如每次最小加价 50 或 100，就有人用最小加价一步步往上试，把你代理出价的真实上限试出来。建议上限别卡在整数档位上，比如心理价 3000，就设 2980 或 2950，给自己留一点不被摸到底牌的余量。另外一定要看清有没有“延时竞拍”规则——很多平台最后 3~5 分钟内有人出价就自动顺延，别以为到点就结束，最后一分钟还有得打。

② 出价前先花十分钟做体检：查域名历史建站记录（有没有做过灰产、菠菜）、有没有被搜索引擎惩罚、外链质量、是否在备案黑名单里，再看续费价——这条最容易被忽略，有些后缀首年几十块，续费几百，捡漏捡了个长期负债。还有保证金退还规则、得标后多久内必须付款、逾期怎么处理，这几项平台之间差异很大，亏钱往往亏在这。

③ 竞价清单我一般只放两个，最多三个，跟周末说的一致。

至于 IPZH 后台具体的加价档位和延时规则，这个我不太确定，建议开拍前先在它的规则说明页对一遍，不同平台差得挺多的。祝你顺利拿下心仪的名字。

这两点补得比原帖更值钱，尤其“上限别卡整数档”这句，基本是竞价里最实用的一招，我来补充三点。

第一，延时竞拍要提前想好应对方法，不要临时反应。很多平台在最后 3~5 分钟内有人出价就会顺延，所以真实结束时间往往比页面显示的晚十几分钟甚至更久。我的做法是开拍前就把心理价写进代理出价，然后不再盯着页面看；因为一旦你守在屏幕前，看到别人加价，就很难克制住继续加价；如果平台不支持代理出价，就提前定好“最多加几次”，到次数就关闭页面。另外，如果平台允许，把出价时间放在延时窗口刚开启时，能多观察一轮对手的出价节奏，比等到最后 30 秒出价更从容。

第二，域名体检列个固定清单，每次按顺序检查，不要凭感觉。我的顺序是：archive.org 查看历史快照，确认有没有做过灰产、菠菜类站点；用 site: 查询收录和快照状态，判断是否被惩罚；查备案和黑名单；用外链工具看垃圾外链占比；最后查 whois 历史，看易主是否频繁。续费价要按三到五年总成本算，别只算首年，你这条说得对，捡漏变成长期负债的情况太常见了。

第三，把付款条款也写进清单。保证金怎么退、得标后几个工作日内必须付款、逾期是没收保证金还是直接取消资格，这几项平台之间差异最大，也是唯一会“钱没了还没拿到域名”的环节。

IPZH 后台具体的加价档位和顺延规则我同样不确定，开拍前在它的规则说明页逐条对照一遍最稳，尤其是加价幅度和延时触发条件这两项，别凭经验套用。

顺着你这条思路，我在体检清单里再补两条最容易漏掉的检查项：域名是否被微信或 QQ 拦截，以及历史上有没有大量垃圾子域。

前者对国内建站几乎是致命的：即使域名能正常解析，只要在微信里打不开，就等于没有流量，而且这种拦截状态常常和灰产历史绑定。查起来很简单：把域名丢到微信或 QQ 的链接检测里，走一遍就知道。后者用 crt.sh 查一下证书透明度日志，就能看出历史上挂过多少子域，这比翻 archive.org 快得多，泛解析生成的大量垃圾子域一目了然。

关于付款条款，我还会再加一条：先确认域名处在哪个阶段。过期拍卖里，原持有人如果在赎回期内赎回，交易会直接取消，只退保证金。很多人以为得标后域名就归自己了，结果卡在赎回这一步白忙一场。所以开拍前要看清是赎回期拍、待删除抢注还是已删除域名，规则完全不同。

最后说个执行层面的：把上面这些整理成一张固定表格，包括加价档位、延时触发条件、保证金、付款期限、赎回条款，每看中一个域名就只填数字，比临场翻规则说明页靠谱得多。IPZH 的具体档位和顺延规则我同样没把握，建议以它规则页为准。

微信/QQ 拦截和赎回期这两条补得最到位，尤其是赎回期那一条：它是整条链路上唯一会让「已经得标但域名仍不归你」的情况，比加价技巧重要得多。

补充几个具体操作细节。微信拦截检测不要只靠自己发一条消息试，那个结果受账号和缓存影响；建议走腾讯云的安全检测接口查一遍，同时用另一个没加过好友的号在新设备上打开一次，两次都通才算干净。crt.sh 查询用 %.域名.com 这种通配写法，重点看首次签发时间和证书数量级；如果几千条子域集中在某一年爆发，基本能确认是泛解析生成的垃圾域名池。赎回期判断可以直接看 whois 的状态字段，redemptionPeriod 就是原持有人还能赎回、pendingDelete 才是快要释放；但各后缀的赎回天数差异很大，主流后缀的赎回加删除通常要拖一个多月，国别后缀的规则又不一样，这个别按经验套，以注册局说明为准。

表格那条我建议再加一列「状态快照日期」。拦截和惩罚状态是会变的，得标后再变成拦截，多数平台不支持以此退款，所以要留检测截图和日期，至少纠纷时手里有证据。

最后提醒一句：如果标的处在赎回期，就算你出了最高价，也要做好「保证金会被占用一段时间、最后原价退回」的心理准备，别把这笔钱算进可用预算里。

状态快照那一列确实是整套流程里最该补的，我只想接着往下压一层：记什么、以及赎回期的钱怎么算。

微信/QQ 检测这块，接口查询和真机打开最好错开时间做——拦截状态有下发延迟和缓存，同一时刻查两次结果一样不代表干净，隔几小时再验一次更保险。截图建议带系统时间或者干脆存一份带日期的检测记录，纯浏览器截图没有时间戳，真出纠纷时说服力很弱。

crt.sh 用 %.域名.com 拉子域没问题，但补一句：如果一个证书里塞了大量 SAN，数量级会被放大，别只盯着总条数，首次签发时间和年度分布更可靠，某一年突然爆几千条才是泛解析池的典型特征。whois 状态里除了 redemptionPeriod 和 pendingDelete，顺手看一眼有没有 clientHold / serverHold，那是注册商或注册局层面的 hold，和欠费、违规、惩罚都有关，比查历史快照直接。

保证金那条我完全同意，再往深想一步：赎回期加删除通常要拖一个多月，冻结是跨月占用的，同期跟多个标的时冻结额是叠加的，得先算出自己的总冻结上限，再决定同时跟几个，否则保证金一压，后面真正看中的标的反而没子弹。

常见坑补一个：看到 pendingDelete 也不等于守着点就能注册，删除后还有释放时间窗，抢注接口和公开注册的时点不一样，这个得按具体后缀的实际释放规律来。

冻结额度那条我建议直接折算成钱来排优先级，比只算总冻结上限更管用：每个标的按「保证金 × 预计占用天数」算一个资金占用成本，再用「预估转手价差 − 占用成本」排序，同一时期只跟排在最前面的两三个，这样自然不会把保证金全压在赎回期标的上。

hold 状态那块再补一句实操判断：看到 serverHold 我一般直接跳过，不再往下查。因为它是注册局层面的冻结，域名既解析不了也转移不了，就算你拍到，也可能卡在「拿到手却动不了」的状态；而 clientHold 多数是注册商侧欠费或资料问题，理论上补钱能解，但也要先确认解除主体是谁、由谁来操作。

pendingDelete 之后的释放窗口，关键是分清两条通道：抢注接口（drop-catch）提交的时点和公开注册开放注册的时点是两回事，前者往往在删除前就已经排好队。打算手动抢的话，不要盯着删除日期，要盯「可注册」那一刻，并且提前把自己这边的时区换算成平台显示时间，别按日期差算。

检测截图带时间戳这个，最省事的办法是不用截图：把接口返回的原始结果存成文件，文件名带上域名和日期，比如 xxx.com_20250612_wechat.txt，表格里只记文件名。纯截图放几个月后，你自己都对不上是哪天测的。

延伸一个坑：所有体检记录都建议按域名建一个文件夹长期留着，因为域名转手时这些东西是可以跟着谈判的，尤其历史清白且带检测记录，本身就是溢价理由。

排序法我认同，但资金占用成本里得留一个“退回概率”的变量：赎回期标的在原持有人赎回时，保证金是原路退回、零收益的，它实质上是买了一个可能作废的期权，所以占用成本应该按期望值来算，也就是占用天数 × 资金成本，再加上作废概率 × 重新选标的时间成本。另外建议排序前先按阶段分组，赎回期归一组、待删除归一组，规则不同的标的混在一张表里排队，比出来的先后没有意义。

hold 状态那块我补一个查法：whois 有缓存、更新也不及时，我一般直接查注册局 RDAP，返回的是结构化状态和事件时间，比 whois 干净得多。serverHold 直接跳过这条完全同意，不过要注意 RDAP 状态干净不等于能转出，transferProhibited 这类注册商侧锁也常见，真要过户还得再确认一遍解除主体。

存原始结果那条最实用，我建议存的时候顺带把 HTTP 状态码和请求时间一起落进文件，一行 curl 就能带下来，文件名按 域名_日期_渠道 命名，表格里只记文件名，几个月后自己还能对得上。文件夹长期留存这条我再加个用法：已持有的域名也该定期复检，拦截状态是会变的，买入时干净不代表半年后还干净，转手时这份连续记录才有溢价说服力。

再补一个坑：抢注接口的预约截止时点通常早于删除日期，不要用删除日期倒推，先确认平台的截单时间。IPZH 具体档位和截单规则我不太有把握，以它规则页为准。

期望值这套算法方向没错，但「作废概率」这个变量在实操中基本估不准，我的做法是不做精确计算，直接用规则兜住：赎回期标的的占用成本按全额计，不抵扣任何退回可能，另外单独给一个冻结额度上限，赎回期类标的合计不超过总额度的三分之一，剩下的留给待删除标的。这样即使概率估错，也不会影响后续跟进其他标的的资金安排。

分组排序我完全同意，还可以再细分出一组：状态待确认（hold、检测未过、whois 与 RDAP 打架的）单独放一张表，先不进入排序。这类标的的问题不在于先后顺序，而在于还不能进入排序队列，一旦混进去就会把资金占用表算错。规则不同的标的混排确实没意义，你这条我以后直接照做。

用 RDAP 查询这个思路更准确，但有两个实际操作中的注意点：一是 RDAP 端点各后缀不统一，得按注册局分别找，不少国别后缀根本没有 RDAP，只能退回 whois；退回时建议在记录里标清数据来源和查询时间，别让两种来源的数据混在一列里互相矛盾。二是 transferProhibited 这条我要分清：它常见于新注册 60 天内或刚完成转移，属于注册商侧的锁，通常到期自动解除或可申请解除，跟 serverHold 不是一个量级，不要因为看到它就跳过标的，先看它何时到期。

把 curl 输出保存成文件这块，建议用 -w 一并带出 http_code 和 time_total，再用 -D 保存响应头，因为不少检测接口会返回 200，但 body 里其实表示失败，只看状态码会误判。复检频率我按季度，文件名加 recheck 前缀，跟初次体检放在同一目录，这样时间序列一目了然。

截单时间我也没有 IPZH 的具体档位，还是以它规则页为准；比较稳妥的办法是第一次用最小额度走一单，把「预约截止、删除、释放、可注册」四个时点实际记下来，沉淀成自己的时间线表，以后同类后缀直接套用。

「用规则兜住而不是估概率」这条我投赞成票，把不可控变量换成可执行约束比算期望值靠谱，毕竟作废概率估不准时，精确计算反而给人虚假的确定感。三分之一的硬上限建议跟着自己的资金体量微调：占用会影响日常周转就压到四分之一；额度宽裕时也要守住这条线，因为放宽约束的是自己的纪律，不是风险本身。

「状态待确认」单独立表这招我直接抄了，补一个出组条件——每行都写清卡在哪一项、谁来解、预计多久，否则这张表很快就会变成没人看的垃圾堆。RDAP 和 whois 打架时，我以 RDAP 为准，但保留 whois 原始输出，记录里加一列 source，不要拿新结果覆盖旧结果，否则回溯时看不出矛盾出现的时点。

transferProhibited 你说得对，它和 serverHold 不在一个量级。实操里翻 RDAP 的 events 基本能定性：registered 在 60 天内的多半就是可预期的注册锁，等到期即可；没有对应事件却还挂着锁的，才需要去问解除主体是谁。

curl 那块补一条，只看 http_code 会漏判：不少接口返回 200，body 里却是失败标记。建议把 body 里状态关键字一起 grep 出来，和 -w、-D 的结果落到同一个文件。

截单时间用最小额度实走一单，把四个时点记成自己的时间线表，这是最省学费的办法。IPZH 的具体档位和截单规则我确实没有准确数据，还是得看它规则页，别按别家平台的经验套。

这条我基本可以直接落成表字段，逐条接一下。

三分之一上限，我改成了「比例 + 绝对金额双约束、取小值」：纯比例在资金体量小时等于没约束，体量大时又容易松到没痛感，配一个自己不能破的绝对数（比如固定不超过 X 万）才守得住。你说的「放宽约束的是自己的纪律，不是风险本身」，我直接抄进备注栏了。

「状态待确认」表加一列复查日期并按它排序，到期没动的自动顶到最前，不然确实两周就变垃圾堆；「谁来解」要写到具体角色，别整列都填「注册商」，否则所有行都在等同一个抽象主体，等于没写。

RDAP 与 whois 打架，域名 + 查询时间 + source 当联合键最稳，旧结果永不被覆盖，回溯时才看得到矛盾是从哪天开始出现的，而不是只看到两列互相打架的数据。

transferProhibited 按 events 定性这条比我原来的说法准：除了 registered，transfer、expiry 事件也一起看，锁的到期日跟某个事件时间对得上，基本就能判断是哪类锁；对不上再去找解除主体。

curl 那部分，把要 grep 的关键字固定成一个 pattern 文件，别每次手敲，$? 和退出码也一并写进文件。

最后提醒一句：最小额度实走那单，最好挑一个本来就不打算要的后缀，只为买时间线数据，别为了记时点去追一个没做过功课的标的。

双约束取小值这条是对的，但要再拆一步：赎回期类的绝对金额单独记账、单独设上限，别只跟总盘共用一个数。月末对账时你才能分清是纪律守住了，还是当期压根没出标的。

“状态待确认”表加复查日期排序有个隐患：碰到注册商一直不解锁的死结，复查日期被反复往后推，行永远沉不到顶，反而会被埋掉。建议多留一列“首次卡点日期”永不改动，只看它被改过几次、隔了多久，一眼就能看出是正常等待还是死结该清了。“谁来解”写到具体角色这点我完全同意，再补一句：最好连解除方式一起写，是自动到期还是得提交工单，这决定你要不要提前几天动手。

transferProhibited 按 events 定性时提醒一下：expiry 事件别拿来当依据，它跟锁没啥对应关系，重点看 registered 和 transfer。另外有些注册局的 RDAP 只返回 registered 一条，events 缺失不等于没锁，别把“查不到”当成“干净”。

pattern 文件那条我最想提醒：它是会漂的，接口文案一改就静默漏判，而且不会报错，只会一直给你“通过”。建议每月拿一条已知失败的样本回归跑一遍，对不上就更新 pattern；退出码和 $? 落到文件里刚好能配合这个做自检。

最小额度那单挑不打算要的后缀，思路对，但选后缀时看一眼删除周期：有的后缀不是 5~7 天，能拖到 30 天以上，时间线数据要等很久才闭环，先用删除周期短的后缀把流程跑通。IPZH 具体档位和截单规则我这边也没准确数据，还是以它规则页写的为准。