云服务器出网IP被目标站限速或封禁，主因是云厂商IP段被标记为爬虫池，导致429、503或静默丢包；需通过curl对比验证，并优化timeout、Session连接池、重试策略及DNS解析。
云服务器出网IP被目标站限速或封禁
本地跑通的爬虫一上云就超时，大概率不是代码问题，而是云服务器的公网IP已被目标网站标记为“爬虫IP池”。国内主流云厂商（阿里云、腾讯云）的出口IP段长期被大量爬虫滥用，很多网站直接对这些IP段做429响应或静默丢包，导致requests.get()卡在ReadTimeout或根本收不到响应。
验证方法：在云服务器上执行curl -v https://目标域名，观察是否返回HTTP/2 429或连接直接挂起；再用本地网络复现同一请求，对比状态码和耗时。
- 不要依赖“云服务器网络更好”这种直觉——多数情况下，它的出网IP信誉比你家宽带还差
- 部分CDN或WAF（如Cloudflare）会主动对云厂商IP返回
503或520，而非标准429，需结合curl -I看Header里的Server或CF-RAY - 免费代理或共享代理池同样高危，它们的IP往往已出现在多个黑名单中
timeout参数没拆开设置，掩盖了真实瓶颈
云环境下的网络路径更长（可能跨AZ、经NAT网关、过安全组），连接建立快但首字节响应慢是常态。若只写timeout=5，实际是(5, 5)，连接阶段耗掉3秒后只剩2秒等响应，极易触发ReadTimeout。
正确做法是显式分离：连接超时设为3（略大于TCP重传窗口），读取超时放宽到15甚至30，尤其对含JS渲染、大图或视频的页面：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
response = requests.get(
url,
timeout=(3, 15), # 连接3秒内必须建连，建连后最多等15秒首字节
headers={"User-Agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36"},
)- 避免设
timeout=None——云服务器上一旦卡住，进程就永久阻塞，无法被监控或自动重启 - 某些云厂商的安全组或防火墙会对“长时间空闲连接”主动中断，此时
ReadTimeout反而比ConnectTimeout更常见
未启用Session复用与连接池，触发系统级资源限制
云服务器默认的文件描述符限制（ulimit -n）常为1024，而未用requests.Session()的脚本每发一次请求都新建TCP连接+SSL握手，短时间内打满fd，后续请求直接抛OSError: [Errno 24] Too many open files，表现就是随机超时。
必须用Session并配置连接池：
s = requests.Session()
adapter = requests.adapters.HTTPAdapter(
pool_connections=10,
pool_maxsize=20,
max_retries=3
)
s.mount("http://", adapter)
s.mount("https://", adapter)
response = s.get(url, timeout=(3, 15))- 不配
pool_maxsize时，urllib3默认只维护10个空闲连接，高并发下仍会频繁新建连接 - 云服务器DNS解析可能较慢，加
pool_block=True可避免连接池争抢，但会略微增加首次请求延迟 - 如果目标站支持HTTP/2，考虑换用
httpx——它原生复用连接且默认开启keep-alive
没处理Max retries exceeded背后的重试风暴
这个错误表面是重试次数用尽，实际常因云服务器到目标站链路不稳定（如中间BGP抖动），导致大量请求在ConnectTimeout和ReadTimeout间反复失败，urllib3不断重试，最终耗尽所有连接槽位。
关键不是关重试，而是让重试更聪明：
- 用
urllib3.util.Retry定制重试策略，仅对429、503、ConnectTimeout重试，跳过403或404 - 启用指数退避：
backoff_factor=1，第一次重试等1秒，第二次2秒，第三次4秒……避免雪崩式重试 - 云环境建议加
respect_retry_after_header=True，有些WAF会在Retry-After头里明示冷却时间
真正棘手的是那些不返回明确状态码、只静默丢包的场景——这时超时值和重试逻辑再精细也没用，得靠代理轮换或切换出口网络。别在单点优化上死磕，先确认是网络层问题还是应用层问题。
