Python用requests监控网页状态

在用Python的requests库监控网页状态时，仅设置超时参数和检查HTTP状态码远远不够：不显式指定timeout（推荐使用timeout=(3, 7)）会导致脚本在网络异常时无限阻塞，彻底中断监控；而单纯依赖status_code==200更存在严重盲区——页面可能返回200却实际不可用（如空白页、JS错误、登录跳转或CDN缓存的错误内容）。真正可靠的监控必须双管齐下：严格控制连接与读取超时，并对响应正文进行关键词校验（如确认包含“首页”等业务标识），才能避免误报漏报，保障线上服务可观测性。

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学习网公众号，给大家分享更多文章知识！