Python监控网页状态：requests异常处理实战

本文深入剖析了Python网页监控中requests库异常处理的关键实战要点，强调必须显式设置合理的超时参数（如timeout=(3, 7)）以避免进程卡死，并指出仅依赖HTTP状态码200远远不够——还需校验响应内容是否包含预期关键词，从而真正判断网页是否“可用”，帮你构建稳定、精准、生产就绪的网页健康监控系统。

requests.get() 超时没设，监控脚本会卡死

不加 timeout 参数，requests.get() 默认无限等待，遇到网络抖动或目标服务器假死，整个监控进程就挂住，后续检查全停摆。

实操建议：

• 必须显式传 timeout=(3, 7)：前者是连接超时（DNS+TCP），后者是读取超时（响应体接收）
• 别只写单个数字如 timeout=5，它只设连接超时，读取仍可能卡住
• 生产环境建议连接超时 ≤ 3s，读取超时 ≤ 10s；太短容易误报，太长拖累轮询频率

HTTP状态码200不等于网页“能用”

很多监控只看 r.status_code == 200，但页面可能返回 200 却是空白页、JS错误页、登录跳转页，甚至 CDN 缓存的 502 错误页。

实操建议：

• 加一层内容校验：比如检查 r.text 是否包含预期关键词 " 或特定
• 对 API 类接口，验证 r.headers.get("Content-Type", "") 是否含 "application/json"，再尝试 r.json()
• 避免用 in r.text 查大段 HTML，性能差；优先用 r.content[:1024] 截头部做轻量判断

ConnectionError 和 Timeout 异常类型要分开捕获

统一用 except Exception: 会掩盖真实问题——比如 DNS 失败、目标端口关闭、SSL 证书过期，这些都该归为不可恢复错误，而临时超时可以重试。

实操建议：

• 单独捕获 requests.exceptions.Timeout，可立即重试 1–2 次
• 捕获 requests.exceptions.ConnectionError（含 MaxRetryError）时，大概率是目标不可达，记录后跳过重试
• 别忽略 requests.exceptions.SSLError，尤其监控 HTTPS 站点时，自签名证书或系统 CA 过旧都会触发它

Session 复用能省开销，但跨域名要小心 Cookie 泄露

用全局 requests.Session() 复用 TCP 连接和 SSL 上下文，比反复新建 requests.get() 快 30%+，但 Session 默认持久化 Cookie。

实操建议：

• 同域名多 URL 监控（如 /health、/api/status）适合复用一个 Session
• 不同域名之间绝不能共用同一 Session 实例，否则前一个站点的 Set-Cookie 可能被带到后一个请求里，引发鉴权异常或 403
• 需要复用又需隔离时，按域名建字典：sessions = {"example.com": requests.Session(), "api.example.com": requests.Session()}

监控不是发个请求就完事，真正难的是区分“暂时连不上”和“服务彻底崩了”，以及怎么让失败日志一眼看出是 DNS、SSL 还是后端超时——这些细节不抠清楚，报警就会要么太吵，要么太哑。

今天关于《Python监控网页状态：requests异常处理实战》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！