爬虫任务出现“偶发超时”时最有价值的不是换一组配置继续跑而是把失败拆成可量化的指标。同一目标站点在不同时间段可能出现连接超时、读取超时、429、5xx 或 DNS 解析失败。只看一次请求是否返回 200无法判断问题在客户端、网络链路、目标服务还是请求频率。一、质量评估应该记录哪些指标单个“平均耗时”不足以说明稳定性。一个实用的最小指标集包括成功率成功响应次数占总请求次数的比例。P50 与 P95 延迟P50 表示典型耗时P95 用于观察较慢的一段请求。状态码分布403、404、429、5xx 的含义和连接异常不同应分别统计。异常类型DNS、连接、读取、TLS、代理认证错误需要分开记录。测试条件目标 URL、开始时间、超时值、请求间隔、运行环境必须写入日志。P95 不等于“最慢的一次”。使用最近邻定义时排序后取排名为ceil(n × 0.95)的样本样本数较小P95 会很接近最大值。因此它适合做趋势比较不适合在 5 次请求后得出长期结论。二、为什么状态码与异常必须分开结果说明排查方向2xx / 3xxHTTP 服务已返回响应记录耗时与响应大小4xx请求已到达 HTTP 服务但不符合接口要求权限、参数、频率、资源状态5xx服务端或中间层处理失败服务端日志、重试策略、维护窗口ConnectTimeoutTCP 连接未在限定时间内建立地址、端口、路由、防火墙ReadTimeout连接已建立但未及时收到数据服务端负载、响应体、读取超时SSLErrorTLS 验证或握手失败系统时间、证书链、主机名、CA 包例如429 不是连接故障而是服务端或网关明确给出的限流响应。将它和超时混在“失败率”里会掩盖根因也会导致不合适的重试行为。三、可运行的测量脚本下面脚本以一个公开测试 URL 为默认值。运行生产或业务测试时请替换为拥有访问授权的接口并把请求次数、间隔和超时与服务方要求保持一致。import math import os import time from collections import Counter from statistics import median import requests URL os.getenv(TARGET_URL, https://httpbin.org/get) REPEAT int(os.getenv(REPEAT, 20)) TIMEOUT (3.05, 15) def p95(values: list[float]) - float | None: if not values: return None return sorted(values)[math.ceil(len(values) * 0.95) - 1] latencies: list[float] [] statuses: Counter[str] Counter() exceptions: Counter[str] Counter() with requests.Session() as session: for index in range(REPEAT): started time.perf_counter() try: response session.get(URL, timeoutTIMEOUT) except requests.RequestException as exc: exceptions[type(exc).__name__] 1 else: statuses[str(response.status_code)] 1 if 200 response.status_code 400: latencies.append((time.perf_counter() - started) * 1000) if index 1 REPEAT: time.sleep(0.5) successes sum( count for code, count in statuses.items() if 200 int(code) 400 ) print(success_rate:, round(successes / REPEAT * 100, 1), %) print(p50_ms:, round(median(latencies), 1) if latencies else None) print(p95_ms:, round(p95(latencies), 1) if latencies else None) print(status_codes:, dict(statuses)) print(exceptions:, dict(exceptions))安装并运行python -m pip install requests python quality_check.py四、脚本的统计边界脚本把 2xx 和 3xx 视为成功响应用于计算延迟分位数4xx、5xx 会保留在状态码统计中但不计入成功延迟。这不是唯一口径如果你的业务允许 304或要求接口必须返回 200可以在代码中按业务契约调整。此外requests.Session()会复用适当的连接。它更接近日常客户端的连续请求行为但不等于从零开始建立连接的冷启动耗时。需要测试冷启动时应在每次请求中创建独立 Session并明确在报告中标注测试方式。五、如何解释 P50、P95 与失败率P50 上升典型请求整体变慢如果 P50 从 100ms 升到 500ms说明大部分请求都变慢。应检查最近的目标服务变更、DNS 解析结果、运行环境负载和网络路径变化。P95 上升而 P50 稳定尾部波动变大这常见于偶发拥塞、连接复用失效、服务端排队或少量慢响应。此时应保留每次请求的时间戳确认慢请求是否集中在特定时段。失败率上升先按错误类别分组连接超时、读取超时、HTTP 429 和 HTTP 503 的后续动作不同。针对可重试的临时错误可遵循接口文档配置有限次数的指数退避对 4xx 权限类错误重复请求通常没有帮助。六、合规采集任务的运行建议只访问已授权接口、公开可访问资源或拥有明确许可的测试环境。遵守目标站点服务条款、robots.txt 与接口频率要求robots.txt 不是访问授权本身。设置明确超时和请求间隔避免无界循环与无限重试。日志中不要写入 Authorization、Cookie、个人数据或完整查询参数。对业务接口使用脱敏的测试样本并为网络异常设置告警阈值。七、FAQ为什么不直接用平均延迟平均值容易被少量极慢请求拉高或掩盖。P50 与 P95 同时记录可以更直观看到典型体验和尾部波动。429 是否应该重试应以接口文档和响应头为准。若服务端提供Retry-After应优先遵守没有明确规则时不要立即高频重试。脚本能判断网络质量的全部原因吗不能。它记录的是 HTTP 客户端视角的结果。需要进一步定位时还应结合 DNS 查询、系统资源、服务端日志和链路监控。总结网络质量评估不是一次“测速”而是用一致的测试条件记录成功率、延迟分位数、状态码和异常类型。只要这些数据可复现后续无论是优化超时、调整连接池还是与服务方沟通都有明确的技术依据。