代理流量预算：先预留、再放行、最后对账

扩容之前，先在新任务前放置一个原子字节账本：预留估算上限，只有剩余本地预算不为负才放行，再用可核验的本地用量记录替换预留。这样多个并发工作进程不会把同一份剩余额度都当作自己的。它不使供应商计量实时化，不保证账单上限，也不把本地响应体估算变成 IPHTML 的限额。

本文面向持续运行经授权采集或网站 QA 工作流的工程负责人、支持负责人：当在途请求的实际用量还未知时，需要一个保守的暂停规则。下方账本是明确构造、可手工复算的示例；它控制本地记录的请求／响应正文字节，不是供应商账单计量器、金额硬上限，也不声称 IPHTML 的套餐、价格、容量或性能。

一、放行前先约定记账边界

先写清一个结算周期、一个单位和一个决策负责人。本例使用 MiB（1 MiB＝1,048,576 字节）的本地周期。还要记录时区和重置／关账边界：上一周期未解决的预留不能在午夜自动消失。选择客户端确实能稳定采集的字节字段，例如应用已接收后的请求和响应正文，并说明排除了什么。请求头、连接开销、失败传输、重试、压缩、供应商取整，以及供应商计入的流量都可能不同。在核对周期、单位和计量定义前，不能把这本账悄悄等同于发票。

字段	本文中的含义	不能被理解为
上限 `B`	本周期的本地规划限额，单位 MiB。	供应商配额、发票总额或保证的消费上限。
缓冲 `H`	为未建模或延迟信息保留、不可用的余量。	一定能覆盖所有计量差异的保证。
已结算 `C`	已完成工作中，由可核验的本地用量记录支持的实际正文字节。	供应商已经按相同数额计费的证明。
未结算预留 `R`	已放行、但实际字节尚无可核验本地记录的工作预留。	已被证明发生的流量。

每个决策点都计算 可用量 = B − H − C − R。只有拟预留量 q 不超过可用量时才放行，并在同一个持久化事务中按幂等键写入预留。若无法从可测量的工作负载估出有限预留上限，就应暂缓，直到可以估算；不能把缓冲当作上限的替代品。客户端先检查、稍后再分别写入，并不构成准入控制：两个工作进程都可能看到 350 MiB，然后各自预留 250 MiB。

二、复算一份构造的预留账本

设 B=1000、H=100、C=400、R=150 MiB。可用量为 1000 − 100 − 400 − 150 = 350 MiB。工作进程 A 请求预留 250 MiB；单一协调器原子写入 A 的预留后，R 变为 400，可用量变为 100 MiB。因此并发的 B 若也请求 250 MiB，就必须暂缓，不得放行。

事件	上限 B	缓冲 H	已结算 C	未结算 R	可用量	决定／证据
期初状态	1000	100	400	150	350	已有结算记录和一笔先前未关闭的预留
A 预留 250	1000	100	400	400	100	放行；持久化预留 ID 为 A
B 请求 250	1000	100	400	400	100	暂缓；不写入预留
A 按实际 180 结算	1000	100	580	150	170	可核验的本地用量记录替换 A 的 250 预留
未知的 U 仍预留 150	1000	100	580	150	170	暂缓；没有完成记录不等于可以退款
U 按实际 120 结算	1000	100	700	0	200	之后获得可核验的本地用量记录
新任务 C 预留 180	1000	100	700	180	20	仅能经同一协调器放行；这不是把 B 缩小后重新放行

下载双语预留账本 CSV。它把这些行保留为建模值，并故意把全部操作者“实际值”和“证据引用”字段留空。表中的数字不是已观测流量。将下载文件保存为 proxy-traffic-budget-control.csv 后，可用下面只依赖标准库的检查独立重算每一行，不会相信 CSV 展示的可用量。

import csv

with open("proxy-traffic-budget-control.csv", newline="") as f:
    for row in csv.DictReader(f):
        if row["cap_mib"]:
            available = int(row["cap_mib"]) - int(row["buffer_mib"]) - int(row["settled_mib"]) - int(row["outstanding_mib"])
            assert available == int(row["available_mib"]), row["event_en"]
print("ledger arithmetic checks")

三、每笔预留只结算一次，不重复计数

预留是临时的最坏情况分配，不是一笔额外收费。A 的可核验本地用量记录显示为 180 MiB 时，应把这 180 计入 C，同时从 R 中移除 A 的 250 MiB。只加 180 而不移除 250 会重复计算；移除 250 却不增加任何实际值会少算。请把结算 ID 与预留 ID 关联，并让重试提交结算的动作具备幂等性，避免延迟消息把同样的 180 MiB 再入账一次。

只有存在“从未发出”或“发出前已取消”的证据时，才能释放预留。若已经发出、但缺少完成证据，仍应以未知保留预留；不能因为超时、工作租约结束或报告期限到达就自动退回。之后抵达的本地完成记录可以结算它。周期结束仍无证据时，把未解决预留带入保守的关账／对账流程，并记录后续负责人。

四、未知、截止时间和超额都不是零

状态	账本处理	运行操作
有证据表明未发出	只释放一次对应预留。	记录取消或队列证据及幂等键。
已发出、实际值缺失	把预留保留在 `R`。	暂缓新的非必要放行，调查缺失的完成证据。
实际值超过预留	按真实实际值结算；可用量可能为负。	停止新的放行，记录超额并对账。本地停止不能撤回已经产生的计费。
周期截止已到	不得把未知自动变成零。	保守结转，或按有证据链的明确关账政策处理。

可用量为负，是本地控制已被突破的证据，不是因为仪表盘还没变化就继续发请求的许可。云成本预算文档可以作为一个类比：告警和成本数据可能延迟，因此通知不是实时停止机制。AWS 仅对其自家成本工具说明此限制；它并不描述 IPHTML、代理计费或本工作表。同样，Oxylabs 的文档展示了供应商特定的限制模式及 GB、WebAPI 请求等不同单位。这只说明应阅读适用供应商条款，不能据此推定 IPHTML 有某项设置或计量方式。

五、完成对账后，才判断是否该扩容

不要因为一个任务被暂缓就立刻购买或开启更多容量。先判断暂缓来自本地上限刻意设小、没有证据支持的缓冲、单请求预留过大、重复工作，还是未知完成记录。减少重复代理请求指南用于减少不必要需求；重试预算指南制定单任务停止规则；工作负载估算指南区分传输额度、速率和并发。需要更宽的结果视角时，可使用可靠性记分卡；它们都不被本文账本取代。

维持当前上限：证据完整，暂缓符合预期，且获准工作负载适合既定本地政策。
先改善测量：正文长度字段、发出证据或完成记录缺失。扩容只会掩盖记账缺口。
重新估算预留：可比较的已完成工作持续显示有文档支持的差异，同时保留保守缓冲和复核日期。
讨论服务需求：准备周期、工作负载形态、本地账本、未知状态政策和适用供应商条款；不要发送凭据或敏感目标。

带着有证据的预算问题联系支持

对于经授权的工作流，先整理本地周期、单位定义、请求／响应正文采集规则、并发预留峰值、未知状态数量，以及需要澄清的供应商条款。通过 IPHTML 轮换代理页面梳理配置问题，再使用官方联系页（英文）讨论具体服务需求。作出采购或扩容决定前，应确认当前条款与计量定义；本工作表不承诺额度、告警、价格、性能或计费结果。

方法说明：AI 辅助编辑分析。2026 年 10 月 29 日核对的资料包括 AWS Budgets 管理成本页面，仅用于延迟告警／可能超额的类比；以及 Oxylabs 限制设置文档，仅用作供应商计量单位和控制方式不一的示例。文中数字与账本均为构造示例。仅离线检查 CSV 算术；未进行真实代理测试、供应商计量对账、客户效果、支付或续费验证。