峰值带宽好看，不等于业务在防护开启后仍然稳定。制定高防产品试用期性能验收清单，要把正常访问、受控压力测试和异常处置分开验证，同时记录测试时间、线路、请求类型和产品配置。不同服务的部署方式与承诺能力并不相同，以下指标应作为验收框架，具体阈值以双方确认的服务范围和业务基线为准。
先把测试边界和基线定下来
试用前先确认防护覆盖哪些业务入口、测试流量由谁发起、是否需要服务商书面许可，以及异常时如何停止测试。不要对未授权目标发起压力或攻击流量；需要验证攻击处置能力时，使用服务商提供的演练环境或经批准的受控方案。
- 选定代表性业务请求：包括首页、登录或接口等实际会影响用户的请求，并区分静态内容与动态请求。
- 在防护开启前采集基线：记录响应时间的中位数和P95、成功率、吞吐量及服务端资源使用情况。可用 k6 或 Apache JMeter 发起经授权的常规负载，用 sar 观察 Linux 主机指标。
- 固定测试条件：尽量使用相同客户端区域、请求比例、并发增长方式和持续时间；每个阶段运行约15至30分钟，并重复至少数次，减少偶然波动影响。
基线若随时段明显变化，先分时段测量再比较，不要把网络拥塞或业务发布造成的变化直接归因于防护产品。
验收时逐项核对的关键指标
延迟、成功率与吞吐
对照防护前后的中位响应时间和P95，另记请求成功率、超时率与稳定吞吐。可将“防护开启后P95相对基线增加不超过约10%至20%”作为讨论起点，但它不是通用标准：动态请求、跨地域线路和后端处理时间都会改变结果。更重要的是，实际业务是否仍满足自身响应目标，且没有持续上升的超时或失败。
丢包率、清洗时延与误拦截率
丢包率应在同一测试线路、相近时段比较，并区分客户端网络问题与服务链路问题。验证清洗时延时，记录经批准的演练开始、产品告警、策略生效和业务恢复时间，明确计时起止点；只看控制台显示的峰值流量无法证明恢复速度。另用正常用户请求检查误拦截率，核对登录、接口调用等关键流程是否被错误拒绝。
回源能力与处置可见性
观察回源带宽、后端连接数和响应错误是否随压力增长而异常。若产品提供多种转发或防护模式，应分别记录配置，不能把一种模式的结果推广到另一种。还要确认告警是否包含时间、影响范围和处置动作，日志能否用于事后核对；只提供流量图、没有事件记录，会增加故障定位难度。
把结果整理成可复核的验收记录
把每轮数据放进同一张记录表，至少包含时间、配置版本、测试请求、并发或请求速率、持续时长、响应P95、成功率、丢包率、清洗时延、误拦截情况及回源表现。验收结论分为通过、需复测和不通过，并写明对应证据与责任方。
出现偏差时，先重复相同条件，再逐项调整单一变量，例如测试区域或防护策略；不要同时改配置和请求模型，否则难以判断原因。最终将门槛写进试用确认单：测试范围、允许波动、告警响应方式、复测条件和未达标后的处理办法都应可查。这样形成的高防产品试用期性能验收清单，比单独比较峰值更能反映实际业务能否稳定运行。
常见问题
峰值越高，防护能力就一定越好吗？
不一定。峰值反映某种条件下的流量处理能力，不能代替延迟、业务成功率、误拦截和恢复过程的验证。
没有攻击流量，能否完成试用验收？
可以先验收正常业务性能、告警链路、日志和配置流程；攻击处置能力应通过服务商认可的演练方式验证，不能自行对线上目标施压。
不同产品的测试结果可以直接横向比较吗？
只有在测试入口、请求内容、线路、持续时间和判定口径相近时才有参考价值。部署方式不同的产品，还应分别说明测试条件。