如何解决代理状态错误码：读懂 4xx、5xx 与连接中断

代理错误一旦你把它读成一句话，就不再神秘。状态码告诉你是谁出了问题（你的客户端、代理还是目标服务器），响应体或响应头通常会告诉你原因。麻烦在于，同一个状态码可能有两种含义，取决于它来自代理跳点还是源服务器，而这种模糊性正是让人兜圈子的根源。来自目标的 403 是封锁；来自代理的 407 是认证问题；502 则可能是任意一端超时。搞清楚哪一层发出了响应，修复方法几乎总是显而易见的。

这是一份可以在调试时随时查阅的参考资料。它将你在通过代理服务器爬取时实际遇到的状态码，对应到其在代理语境下的含义及解决方法，并特别点出代理专属的情形（认证、速率限制、网关故障、地理封锁），而非泛泛地当作普通 HTTP 处理。先扫一眼表格，跳到你的错误码，按方法修复。

代理错误码一览

从这里开始。表格涵盖了真正会中断爬取的状态码；下面各节会深入讲解其中有代理专属陷阱的部分。

在进入细节之前，有一条阅读规则：先问哪个跳点产生了这个状态码。带有"proxy"字样的 4xx（407）是代理在说话；几乎所有其他 4xx 都是目标通过正常工作的代理在说话。瞬间到达的 5xx 通常是代理无法连接上游；长时间等待后才到的 5xx 通常是源服务器超时。这一个区分比背诵每个状态码更能快速引导你找到正确的修复方法。

4xx：请求到达了目标但被拒绝

这类状态码意味着请求已通过代理，但遭到了拒绝。有一个例外（407），其余情况下代理完成了自己的工作，裁决来自源服务器。

403 Forbidden：你被封锁了，并非永久禁止

这是爬虫最常见的状态码。目标接受了连接，审查了请求，然后决定不予响应。在代理语境下，这几乎总意味着出口 IP 被标记（已知的数据中心范围、已被限速的地址），或者请求指纹看起来像自动化操作（缺失或默认的请求头、不真实的 User-Agent、没有任何浏览器会发送的请求头顺序）。

修复是分层的。首先轮换到新的出口 IP 并重试；单次封锁并不意味着整个 IP 池都被烧毁。如果干净的 IP 仍然收到 403，问题在于信任度而非运气：强化的目标会一眼识别数据中心范围，此时需要升级到住宅 IP。参阅数据中心代理与住宅代理的对比了解这条界线在哪里。如果轮换和更高信任等级都无效，封锁是在指纹层面，你需要真实的请求头，通常还需要渲染后的页面而非原始抓取。更全面的攻略见如何在不被封锁的情况下爬取。

407 Proxy Authentication Required：是代理在问，不是目标网站

407 是唯一来自代理跳点本身的 4xx，也是最常被误读的。目标从未看到你的请求；代理拒绝转发，因为你没有向代理认证。导致这一情况的原因有两个：凭据错误或缺失，或者使用 IP 白名单认证的代理不认识你调用时的地址。

根据你的套餐使用的认证方式，在代理 URL 中发送凭据，或在提供商控制台中将你的来源 IP 加入白名单。使用 curl 时，凭据放在 -x 参数中，而非目标请求中。

# 407 fix: authenticate TO the proxy in the -x URL.
# user:pass here are the proxy's credentials, not the site's.
curl -x "http://USER:[email protected]:8080" \
     "https://httpbin.org/ip"

# IP-whitelist plans take no credentials; the proxy
# checks your source IP instead. Confirm it is allowed.

如果其他请求认证都正常，偶尔出现 407，检查你的出站 IP 是否发生了变化（新容器、VPN、CI 运行器），并重新将其加入白名单。更多 curl 与代理的使用模式见如何使用 curl 配合代理。

401 Unauthorized：目标需要凭据

容易与 407 混淆，但恰恰相反。401 意味着代理转发了你的请求，而目标回复说该资源需要你未提供的认证。代理工作正常。修复方法是发送该网站自己的凭据、API 密钥或会话 token，就像没有代理时一样。如果你看到 401 和 407 交替出现，说明你有两个叠加的独立认证问题：一个对代理，一个对源服务器。

400 Bad Request：请求本身格式错误

400 意味着请求在任何人评估其内容之前就已经格式错误：语法无效、URL 编码错误、重复或过大的请求头，或者请求体与声明的内容类型不匹配。通过代理时，当你将目标 URL 作为查询参数传给 API 时要注意双重编码，以及字符串拼接导致的请求头注入。记录你发送的确切字节并仔细阅读；缺陷几乎总是在你的请求构建器里，而非网络层。

429 Too Many Requests：触发了速率限制

你在一个时间窗口内发送的请求超过了目标（或你的代理套餐）允许的数量。正确的修复是放慢速度并分散请求：在请求之间添加延迟，限制并发，并轮换出口 IP，使负载分散到多个地址而非集中在一个。如果响应中包含 Retry-After 请求头，请遵守它，而非盲目猛打。

轮换 IP 是结构性修复，因为按 IP 计算的速率限制会随 IP 的变化而重置。参阅如何使用轮换代理了解机制，在目标同时对 IP 信任度进行指纹识别时参阅轮换住宅代理。

451 Unavailable For Legal Reasons：地理或政策封锁

451 意味着内容因法律或地区原因被屏蔽，而非技术故障。在代理语境下，这通常是地理限制：出口 IP 所在地区是目标不提供服务的地区。修复方法是从允许的国家出口。选择支持地理定向的代理，确认其实际覆盖你需要的地区，然后在假设覆盖之前用回声服务验证出口位置。

5xx：故障在上游，但是哪个跳点？

这类状态码来自服务器而非你的请求，但通过代理时"服务器"是模糊的：可能是代理无法连接源服务器，也可能是源服务器本身出了问题。时机能区分两者。

502 Bad Gateway：代理从上游收到了垃圾响应

502 意味着网关（此处为你的代理）从它试图连接的服务器收到了无效或空的响应。它通常很快到达，因为代理很快就放弃了。原因分两类：代理本身不健康或配置错误，或者它选择的上游出口已死。先重试，因为 502 通常是短暂的；如果重试持续失败，切换到不同的出口 IP，并通过向已知良好的回声服务发送请求来确认代理端点本身是否正常。如果那也收到 502，问题在代理层，而非目标。

503 Service Unavailable：过载或宕机

503 意味着服务器暂时无法处理请求：过载、维护中或在甩负载。通过代理时，它可能是目标专门甩掉你的流量（伪装成 503 的软封锁），也可能是对所有人真正宕机。退避并带抖动重试；如果某个出口 IP 收到 503 而其他出口正常，说明该 IP 被限速，需要轮换。如果所有出口同时收到 503，目标就是宕机了，唯一的办法是等待。

504 Gateway Timeout：链路中某处超时了

504 是网关跳点上的超时：代理等待源服务器，源服务器迟迟未响应；或者代理本身响应太慢。与 502 不同，它是在长时间等待后才到达的。对于真正慢速的页面，增大客户端超时；重试（超时通常是短暂的）；如果某条路由持续偏慢，切换出口。如果页面需要浏览器完成渲染，原始抓取可能看起来超时，但真正的问题是 JavaScript 执行不完整，这需要渲染层来解决，而非更长的超时。

连接层故障：根本没有 HTTP 状态码

有些故障根本不会到达产生 HTTP 状态的阶段。这些是套接字错误，几乎总意味着代理配置错误，而非请求被拒绝。

连接拒绝意味着你拨打的主机和端口没有任何东西在监听：端口错误、主机错误、代理未运行，或协议不匹配（向仅支持 HTTPS 的端点发送了 HTTP）。核实提供商给你的确切 host:port 和协议。

连接重置/超时意味着套接字打开了但被丢弃或从未响应：出口 IP 已死、防火墙过于激进，或目标静默地丢弃了被标记的流量。用新出口重试；如果重置集中在某个 IP 上，说明它已被烧毁。TLS/证书错误通过代理时通常意味着某些东西在中间终止了 TLS。对 HTTPS 使用 CONNECT 隧道，让代理在不检查加密字节的情况下转发；详情见HTTP 代理与 HTTPS 代理的对比。

让整类错误消失

注意表格中的规律：403、429、502、503 以及大多数连接重置都有一个共同的修复方法，即轮换到干净的出口并重试。自己实现这一点意味着需要一个健康的 IP 池、轮换策略、带抖动的退避以及按错误码分类的重试逻辑。托管的轮换端点会替你完成这些工作，这就是为什么一旦轮换和重试转移到服务端，几类错误就会直接停止出现。

读懂状态码的重试循环

无论使用哪种代理，你的客户端都应该根据状态码采取行动，而非对所有失败一视同仁。最简版本：对短暂类带退避重试，对按 IP 封锁的情况轮换，对你无法通过重试修复的真实客户端错误则停止。

import time, requests

RETRY = {429, 502, 503, 504}  # transient: back off and retry
ROTATE = {403, 429}        # per-IP: try a fresh exit

def fetch(url, get_proxy, tries=5):
    for n in range(tries):
        proxy = get_proxy()  # new exit IP each call
        r = requests.get(url, proxies=proxy, timeout=30)
        if r.status_code == 200:
            return r
        if r.status_code not in RETRY and r.status_code not in ROTATE:
            r.raise_for_status()  # 400/401/451: stop, fix the request
        wait = int(r.headers.get("Retry-After", 2 ** n))
        time.sleep(wait)
    r.raise_for_status()

结构比语言更重要：对状态码分类，对短暂故障退避，对按 IP 封锁的情况轮换，对重试无法修复的错误快速失败。托管端点将轮换和重试的那一半内化于自身，你的循环只需处理真正的客户端错误。

常见问题

403 和 407 代理错误有什么区别？

407 来自代理本身：代理拒绝转发你的请求，因为你没有向它认证，目标从未看到该请求。403 来自目标，在代理成功转发请求之后：网站审查了你的 IP 或指纹并拒绝提供服务。用代理凭据或 IP 白名单修复 407；用轮换出口 IP 或提升代理信任等级修复 403。

爬取时遇到 429 Too Many Requests 错误怎么修复？

放慢速度并分散请求。在请求之间添加延迟，限制并发，如果存在 Retry-After 请求头则遵守它而非立即重试。由于速率限制通常按 IP 计算，轮换出口 IP 是结构性修复：每个新地址都从新的配额开始。将间隔与轮换相结合，可以解决绝大多数 429 问题。

通过代理出现 502 Bad Gateway 是什么原因？

502 意味着你的代理（作为网关）从它试图连接的服务器收到了无效或空的响应，通常很快到达。原因要么是代理不健康，要么是上游出口 IP 已死。先重试，因为很多 502 是短暂的；如果持续出现，切换到不同的出口，并通过向已知良好的回声服务发送请求来确认代理端点本身是否正常。

为什么我收到的是连接拒绝而非 HTTP 错误码？

连接拒绝是套接字层面的故障，发生在任何 HTTP 响应出现之前：你拨打的主机和端口没有任何东西在监听。检查代理主机、端口和协议是否与提供商给你的完全一致，代理进程是否在运行，以及你是否在向仅支持 HTTPS 的端点发送普通 HTTP。这是配置错误，而非你的请求被拒绝。

轮换代理能消除代理错误码吗？

轮换能消除按 IP 产生的错误类，主要是 403 封锁和 429 速率限制，因为两者在出口 IP 变化时都会重置；它也有助于处理短暂的 5xx，因为在新路由上重试。它无法修复来自你自己请求的状态码（如 400 或 401），也无法修复法律地理封锁（如 451）。将轮换与正确的请求构建和地理定向结合，覆盖其余情况。

我应该自动重试每一个代理错误吗？

不应该。对短暂类（429、502、503、504）带指数退避和抖动进行重试，对按 IP 封锁（403、429）轮换出口 IP。不要盲目重试你造成的客户端错误（400、401、451），因为用同样的请求再试一次仍会失败，还可能延长速率限制的冷却时间。先对状态码分类，再选择重试、轮换或停止。

HR

Hassan Rehan

软件工程师 · Crawlbase

Crawlbase 软件工程师，撰写关于轮换代理、抓取，以及把代理接入真实代码的实战细节的实操指南。