死链检测需综合处理重定向、反爬、假200等场景:用requests.head()配合allow_redirects=True与max_redirects=5,捕获TooManyRedirects;区分404/410/503/500为死链,403/401为受限;对200响应校验Content-Type及正文内容。

死链检测不能只靠 requests.get() 加个超时就完事——真实网页常有重定向、反爬响应、HTTP/HTTPS 混用、301/302 循环、甚至返回 200 却是“页面不存在”模板,直接判断状态码会漏判或误报。
用 requests.head() 避免下载正文,但得手动处理重定向
HEAD 请求比 GET 更轻量,适合批量探测,但它默认不跟随重定向(allow_redirects=False),而很多死链实际卡在跳转链末端。必须显式开启并限制跳转次数,否则可能陷入循环或超时:
- 设置
allow_redirects=True,同时用max_redirects=5控制跳转深度(requests 默认是 30,太高风险) - 捕获
requests.TooManyRedirects异常,这类链接大概率已失效或配置错误 - 对
404、410、503、500明确标记为死链;403和401视为“访问受限”,单独归类,不等同于死链
识别“假 200”:检查响应内容或 Content-Type
有些网站对无效路径仍返回 200,但响应体含 “Not Found”、“404 Page” 或 Content-Type: text/html 却无正文内容。这时要加一层校验:
- 若状态码是 200,且
response.headers.get("Content-Type", "").startswith("text/html"),再用len(response.text) 或正则匹配常见错误提示(如 <code>r"404|not found|page does not exist",忽略大小写) - 避免全文本解析:只取前 2KB(
response.content[:2048])做检查,防止大页面拖慢速度 - 不要依赖
BeautifulSoup做全量解析——死链检测是 IO 密集型任务,HTML 解析是 CPU 密集型,混在一起会严重拖慢吞吐
并发控制与请求头伪装,绕过基础反爬
批量扫链接时,不加限制的并发容易被封 IP 或触发 429;不带请求头则大概率被当成爬虫直接拒收:
调用 Cutout.Pro 视觉处理 API 进行背景移除、人像抠图和照片增强,支持文件上传与图片 URL 输入。
立即学习“Python免费学习笔记(深入)”;
- 用
concurrent.futures.ThreadPoolExecutor控制线程数(建议 5–10,取决于目标服务器承受力),别用asyncio+aiohttp——多数死链场景下 DNS 解析和 TLS 握手才是瓶颈,多线程更稳 - 必设
User-Agent,例如{"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"};部分站点还检查Accept,补上"Accept": "text/html,application/xhtml+xml" - 每域名加
time.sleep(0.3)级别的节流(非全局),比统一限速更贴近真实浏览器行为,也降低被识别概率
输出结果要区分“不可达”“拒绝访问”“真死链”三类状态
单纯标“失败”没意义。一个链接可能是 DNS 失败(requests.exceptions.ConnectionError)、SSL 验证失败(requests.exceptions.SSLError)、超时(requests.exceptions.Timeout),或是服务端明确返回 404。这三类问题修复路径完全不同:
- “不可达”(DNS/连接/SSL 类)需检查网络或 URL 格式(比如漏了
https://) - “拒绝访问”(401/403/429)要确认权限或加 Cookie / Token
- “真死链”(404/410)才该通知编辑删链接
- 输出 CSV 时,列名建议为:
url,status_code,final_url,error_type,checked_at,其中error_type填connection/timeout/http_404等可筛选字符串
真正难的不是发请求,而是定义“什么是死链”——它取决于你的业务场景:是面向搜索引擎优化?还是内部 Wiki 维护?前者要严格识别 410 和 noindex,后者可能连 301 跳转都算“链有效”。工具可以跑起来,但阈值和分类逻辑得你亲手调。

















