通过代理访问目标站返回 503 Service Unavailable，表示处理请求的某一层暂时无法提供服务。它可能来自代理网关、内容分发节点、负载均衡器或目标站，也可能只在特定地区、协议或时间窗口出现。先保存完整网址、请求方法、状态码、响应头、响应体摘要、发生时间、代理协议、出口 IP 和请求耗时，再判断错误来自哪一层。
排查目标是在 5 到 15 分钟内回答三个问题：谁返回了 503；它是短暂维护、容量不足还是上游连接异常；下一次请求应该等待多久。不要立即并发重试或连续轮换 IP。503 常常意味着服务端需要恢复时间，过密重试会放大负载，也会让原始证据被新的失败样本淹没。
先用对照表判断 503 来自哪一层
| 观察结果 | 优先证据 | 主要判断 | 下一步 |
|---|---|---|---|
| 直连和代理都返回 503 | 响应头、维护提示、时间窗口 | 目标站或其上游暂不可用 | 遵守等待提示并低频复测 |
| 直连正常，固定代理稳定返回 503 | 网关标识、出口地区、代理耗时 | 代理路径或区域上游异常 | 固定请求，比较另一条受控线路 |
| 不同出口只有一个地区返回 503 | 出口 IP、地区、解析结果 | 区域节点或路由差异 | 核对地区节点与域名解析 |
| 响应包含 Retry-After | 秒数或日期格式的等待字段 | 服务端给出恢复节奏 | 等待到期后只做一次复测 |
| 没有 HTTP 状态码 | 连接、握手和超时日志 | 尚未进入 503 响应层 | 转到连接与超时排查 |
1. 保存原始响应，确认是谁返回 503
不要只记录“服务不可用”页面。保留响应头中的服务器标识、网关标识、缓存字段、追踪标识、Retry-After 和日期，并保存响应体前几行。若响应来自代理网关，重点检查该线路的上游状态；若来自目标站或内容分发节点，代理只能作为对照变量，不能被直接认定为故障原因。
503 与 502、504 都可能涉及上游，但含义不同。502 更偏向网关收到无效上游响应，504 更偏向等待上游超时，503 则明确表示当前暂时不能处理。需要区分时，可按上游连接与网关超时对照表核对响应来源和耗时。
2. 用同一请求做直连与固定代理对照
选择一个低风险、只读、允许重复访问的地址，固定设备、目标域名、请求方法和时间窗口。先直连一次，再通过固定代理发送一次；两次都关闭自动重试，并记录状态码、最终网址、首字节时间、总耗时和出口 IP。若两条路径都返回 503，优先等待服务恢复；若只有代理路径失败，再检查路径差异。
若连 HTTP 响应都没有建立，不要继续套用 503 结论。先按代理连接超时排查顺序核对地址、端口、认证、握手和 DNS，确认请求确实到达能返回状态码的节点。
3. 正确读取 Retry-After 和维护窗口
Retry-After 可能是等待秒数，也可能是具体日期。先结合响应中的日期字段换算本地时间，避免把日期格式误读为秒数。若页面或响应体同时给出维护窗口，以可验证的服务端时间为准，并记录时区。没有 Retry-After 时，也不要把“立即重试”当成默认策略。
等待期内停止自动刷新、并发探测和批量任务。到期后只发送一次最小只读请求；若仍返回 503，延长间隔并保存新样本。不要通过缩短间隔试图猜测恢复时刻，更不要在服务过载时提高并发。
4. 区分服务过载、计划维护和区域节点异常
计划维护通常有较稳定的开始时间、结束提示或统一页面；服务过载更可能随请求量和时段变化；区域节点异常则常表现为特定出口地区失败、其他地区正常。三类现象可能同时存在，因此要用同一目标、同一方法和相近时间窗口比较，不能拿不同页面或不同任务互相证明。
如果只在高峰期出现，记录请求时间、响应耗时和同一时段的成功率，但不要凭一次恢复就断言容量问题已解决。可把线路延迟、可用率和失败原因写入住宅代理健康检查清单，形成可重复的时间序列。
5. 检查代理连接池和上游连接复用
客户端到代理的连接正常，不代表代理到目标站的上游连接正常。连接池耗尽、失效连接复用、空闲连接被回收或并发上限触发，都可能让网关暂时无法分配资源。固定一个节点，将并发降到 1，关闭自动重试，重新建立连接后发送一次最小请求。
如果新连接成功、复用连接失败，记录连接建立时间、空闲时长和失败发生位置，再检查客户端连接池参数。不要一次同时修改池大小、超时、重试和代理节点；每轮只改一个变量，才能判断哪项调整有效。
6. 检查请求频率、并发和队列积压
部分系统在过载保护时返回 503，而不是 429。先把并发降到 1，暂停队列新增任务，并确认是否存在多个进程共享同一出口。记录每分钟请求数、并发连接数、排队时长、失败比例和首次出现时间。若响应明确是频率限制，则转到请求频率与重试间隔检查表，不要混用两类处理逻辑。
降低并发后恢复，只能说明负载与结果有关，不能证明代理节点或目标站的内部容量。没有管理权限时，应把结论写成“在当前请求节奏下可复现”，而不是声称已确定服务端阈值。
7. 设计有限次数的退避重试
只有在请求是只读或明确幂等、响应来源已经确认、等待时间已经满足时，才适合重试。优先遵守 Retry-After；没有该字段时，采用逐步延长的间隔并加入少量随机偏移，避免多个任务在同一时刻再次冲击服务。每次重试都要保留原请求标识和结果。
建议把最大次数、总等待上限和停止条件写入任务配置，而不是无限循环。提交订单、支付、发信或修改数据等可能产生副作用的请求，在无法确认上一次是否执行成功时必须停止，并交给人工或业务幂等机制处理。
8. 按通过、失败和停止条件复测
| 复测结果 | 判断 | 处理 |
|---|---|---|
| 等待后直连与代理均恢复 | 短暂维护或过载已缓解 | 小流量恢复并继续观察 |
| 直连恢复，固定代理仍为 503 | 代理路径或区域上游仍异常 | 保留样本，受控比较另一线路 |
| 仅某个出口地区失败 | 区域节点、解析或路由差异 | 核对地区和 DNS 后再判断 |
| 降低并发后稳定恢复 | 请求节奏与容量相关 | 维持低并发并重新设定队列 |
| 结果随每次请求变化 | 变量尚未固定 | 停止批量测试，重建单一样本 |
把每轮结果写入代理测试记录模板，至少记录时间、目标地址、方法、出口 IP、状态码、响应来源、Retry-After、并发数、重试次数和最终判断。连续两轮低频复测一致，才算结果可重复。
9. 什么时候才需要切换代理线路
只有在直连已经恢复、固定代理仍稳定返回 503，并且响应来源、维护窗口、请求频率、连接池和 DNS 都已对照后，切换线路才有诊断意义。新线路必须保持目标地址、请求方法、请求头和时间窗口不变，否则无法区分线路差异与请求差异。
确认异常只与当前出口路径相关后，可以从住宅代理测试线路选择一个低流量入口做隔离测试。切换线路是为了验证路径差异，不是为了绕过目标站限制，也不能替代等待服务恢复。
结论：先识别返回层，再决定等待、降载或换线
代理访问返回 503 时，可靠顺序是保存原始响应、确认返回层、做直连与固定代理对照、读取等待提示、区分维护与过载、检查连接复用和请求节奏，最后按有限次数和明确停止条件复测。只有证据指向代理路径时，才进行受控换线。
只要响应来源仍不明确、等待窗口尚未结束、请求可能产生副作用，或结果每次都不同，就应停止重试并保存证据。清晰的时间、路径和请求节奏记录，比连续刷新或批量更换节点更容易定位问题。