代理IP套餐合并后显示“用完”：先看资源是否转入保留套餐

代理IP套餐合并后，原订单显示“用完”，不一定代表可用 IP 真的被消耗完。部分套餐合并规则会把相同 IP 时效、套餐类型和 IP 类型的包量合并到一个保留套餐，原套餐随后变更为“用完”，原有 IP 总量计入保留套餐。先看合并记录和保留套餐的数量，再决定是否补购，避免把状态变化误判成资源耗尽。

本文只讨论套餐合并后的订单状态，不把它和余量预警、订单到期、产品升级或开通失败混在一起。

“用完”指的是哪一个套餐

在控制台打开合并前后的订单详情，至少记录四项：原套餐编号、保留套餐编号、合并时间、合并后的 IP 总量。可以用下面的关系判断：

“用完”是被合并套餐的状态标签时，通常应以保留套餐的剩余数量和有效期作为当前使用依据。页面中的状态文字不能替代合并明细，最好保存合并前后的脱敏截图或导出记录。

先确认是否满足合并条件

套餐合并通常不是任意两个订单都能操作。根据操作说明，至少要核对 IP 时效、套餐类型和 IP 类型是否一致；城市、运营商、带宽或其他产品限制也可能影响可合并范围，具体以当前控制台规则为准。不要因为两个套餐名称相似，就把不同规则的订单强行归为同一组。

提交合并前，暂停会批量提取或修改订单的自动任务，记录两笔套餐的数量、有效期和当前状态。合并操作可能改变后续提取入口，先留存原始信息，便于确认数量是否按预期转移。不要在状态未知时连续点击合并或新建补购订单。

用一次只读回查判断资源是否转移

合并完成后，先刷新订单详情，再分别读取原套餐和保留套餐。重点比较：

1. 原套餐是否变为“用完”或其他明确的已合并状态；
2. 保留套餐的 IP 总量是否增加了原套餐应转入的数量；
3. 保留套餐有效期、套餐类型和 IP 类型是否符合预期；
4. 当前 API 或提取页面是否只允许从保留套餐获取资源。

不要只看总数量一个数字。若总量增加但有效期缩短、类型改变或提取入口仍指向原套餐，应把它记录为待核对，而不是立即恢复全部任务。查询接口返回 HTTP 200 也不能证明合并成功，仍要检查业务状态和数量字段。

和三类相似问题分开处理

余量预警：套餐仍是正常状态，只是剩余数量低于提醒阈值。处理重点是核对消耗速度和补充计划，不是寻找合并回滚。

订单到期：有效期结束导致资源不可用。应查看到期时间和续费规则，不能因为另一个套餐显示“用完”就判断到期。

开通或提取失败：订单状态可能正常，但资源尚未生成或接口返回错误。应保留下单、支付、开通或提取证据，不能把套餐合并当作通用重试手段。

如果保留套餐数量没有增加，或合并记录与订单详情相互矛盾，先暂停自动提取和补购，向官方支持提交脱敏的两笔订单标识、合并时间、原始状态和当前数量。不要提交包含 Token、Cookie 或代理密码的完整请求。

验收通过后再恢复任务

确认保留套餐状态正常、数量和有效期符合预期后，只用一个低风险任务做一次提取和连接测试，核对入口、鉴权和实际出口。测试通过，再按原有节奏恢复其他任务；如果只有原任务失败而新测试正常，继续查任务配置，不要重复合并套餐。

代理IP套餐合并后显示“用完”，关键是确认被合并套餐的资源是否已经计入保留套餐。先核对合并条件和前后数量，再区分余量、到期与接入故障，才能避免误补购和重复操作。