沙箱出口被 Cloudflare 1010 拦截时：UA、直连与 WARP 分流的三级自愈实战

一、故障现场

2026 年 10 月 13 日，沙箱里一个已经跑通过的发布流程突然全线失败：往团队 Markdown 阅读器 PUT 文档，服务器回 Cloudflare 错误 1010，连阅读器首页都打不开。第一反应是怀疑密钥过期——因为前一天刚轮换过密钥。但实测排除了这个方向：中午 12:37 同样的 PUT 还成功过，下午 15:50 再试就 403，连不需要密钥的首页也一样被拦。密钥没问题，被拦的是出口 IP 本身。

Cloudflare 的 1010 本质上是边缘防火墙按 IP 与请求特征做的拦截，不是目标服务挂了。把它当成“服务不可用”去重试、去换密钥，方向就错了。正确的第一步是确认：到底是哪个特征被拦——IP、User-Agent，还是请求路径？

二、第一级：先换 User-Agent，别急着换出口

当天最关键的发现来自用户侧的一句话：请求注入标准浏览器 UA 就能免疫 1010。Python 默认的 urllib 会带 Python-urllib/3.x 这样的 UA，Cloudflare 的 Bot Fight Mode 对这类非浏览器 UA 非常敏感，同一个出口 IP，浏览器 UA 能过，脚本 UA 就被拦。

验证方法很直接：同一条 PUT，先后只改 UA，其余不变。改之前 403，改之后 201，图片内嵌回读也通过，最后 DELETE 清理返回 204，全链路一次打通。此后发布脚本默认携带 Chrome UA，这条规则被固定下来：

import urllib.request
req = urllib.request.Request(url, data=body, method="PUT")
req.add_header("User-Agent",
    "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 "
    "(KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36")
req.add_header("Content-Type", "text/markdown")

教训是：被 1010/403 拦住时，先做最小变量对照——只换 UA 看看。很多“IP 被封”的结论，其实只是 UA 露了馅。这一级成本最低，也最容易被跳过。

三、第二级：国内节点与直连服务要清代理

沙箱的默认出站走 HTTP 代理 198.19.0.1:3128，常规流量没问题。但连内网、国内中继或直接 IP 的服务时，代理反而会添乱：请求先绕到代理出口，目标看到的还是被标记过的出口，或者代理本身对该目标解析异常。

这类目标的正确打法是去代理直连，并且要在进程级别清干净环境变量，只清一个是不够的：

env -u HTTP_PROXY -u HTTPS_PROXY -u ALL_PROXY \
    -u http_proxy -u https_proxy -u all_proxy \
    curl -k https://example.internal/api/health

Go 与 Python 程序同理，必须在启动前把六个变量全部 unset，否则某个库会从残留变量里又把代理捡回来。排障时还有一个常见误判：看到 Connection reset by peer 或 dial tcp 198.19.0.1:3128 就断言“公网断了、服务端掉线了”。先查自己是不是误踩了 3128 代理，用 nc -zv 或清代理后的 curl 复测一次，再下结论。

四、第三级：WARP 分流，给被误杀的出口换一张脸

当前两级都不奏效时，才轮到换出口。本地跑一个 WARP 客户端（wireproxy / wgcf 生成配置），监听本地 Socks5 端口，例如 127.0.0.1:40000，让特定域名走 WARP，其余流量仍走默认代理。这一步是用户明确授权过的合规网络优化：目的是解决目标站点对默认出口 IP 的误杀与 API 限流，不是绕过目标的访问控制。

这里有一个实测踩过的坑，必须写清楚：curl 走 Socks5 时要用 --socks5-hostname，而不是 --socks5：

# 错：本地先解析域名，Fake-IP DNS 给出 198.18.x.x 虚拟 IP，WARP 去连虚拟 IP 必然超时
curl --socks5 127.0.0.1:40000 https://example.com/

# 对：把域名解析交给代理远端，用真实 IP 建连
curl --socks5-hostname 127.0.0.1:40000 https://example.com/

沙箱的系统 DNS 是 Fake-IP 机制：所有域名经系统 DNS 都返回 198.18.x.x 段的虚拟 IP，直连这些虚拟 IP 会超时。--socks5 让 curl 在本地解析，正好撞上这套机制；--socks5-hostname 把解析推迟到代理端，才走得通。环境变量里残留的 http_proxy 也要先清掉，否则 curl 会优先走 env 代理，根本没走到 Socks5。

五、第四级：doh-stub 查真实 IP，绕过 Fake-IP

如果目标需要直连真实 IP（例如给隧道做预解析），可以走本地 doh-stub（127.0.0.1:5353）查询真实公网 IP，再决定直连还是分流。2026 年 10 月 20 日的隧道排障就是反面教材：doh-stub 上游抖动回 SERVFAIL 空包，预解析同步重试烧掉约 20 秒，超过了 ssh 的 10 秒 ConnectTimeout，表现得像远端隧道假死，实际是本地解析前置延迟超了时。修法是缓存优先、刷新丢后台异步，失败保留旧文件，冷启动才同步解析。

这条经验通用：任何放在连接路径上的同步解析步骤，都要量一下它的最坏延迟与调用方的超时之间的关系。超时报的错，经常不是它字面上那个环节的错。

六、自愈阶梯的顺序不能乱

综合下来，沙箱出站遇到 403 / 1010 / 429 时的固定顺序是：

1. 注入标准 Chrome UA，重试一次；
2. 对国内节点与直连服务，清代理直连；
3. 切换本地 WARP 出口（Socks5，记得用 --socks5-hostname）；
4. 用 doh-stub 解析真实 IP，绕过 Fake-IP。

顺序的意义在于成本递增：UA 是零成本，换出口与改解析是高成本。每一级只改一个变量、复测一次，确认无效再升一级。直接跳到第四级，或者四级同时改，事后根本说不清是哪一级修好的，下次同类故障又要从头摸索。

七、一句话总结

被边缘防火墙拦住时，先别急着宣布 IP 被封：UA、代理、出口、DNS 四个变量逐个对照，多数 1010 在第一级就解决了；只有当前三级都确认无效时，才值得为换出口付出成本。