同一个 URL，一个工具抓全部失败，另一个工具抓立刻成功——地址一样、目标一样、数据一样。这种"换个工具就好"的现象，往往不是工具的问题，而是它们从不同的网络出口出去。
现象
某个网页抓取工具抓某些站点全部失败，看起来像是被目标站点拦截了。奇怪的是，用命令行 HTTP 工具抓同一个 URL，却能正常拿到数据。
两个工具的行为差异如此明显，以至于你几乎要相信"是那个抓取工具不好用"。但真正的原因不在工具本身。
根因
抓取工具走的是受限的网络出口策略。
这是企业/团队环境里很常见的一种部署：某些工具被配置为通过特定的出口（代理、网关、出口策略）访问外网，而这个出口可能：
- 被目标站点的风控规则识别并拦截；
- 走的是一条受限的链路，只能访问白名单内的域名；
- 经过了会修改请求特征（比如注入/剥离头部）的中间设备。
而命令行工具直接用系统/账号配置的代理，走的是另一条出口。同一条 URL 从不同出口出去，结果可能完全不同——这就是为什么"换个工具就通了"。
解决
改用命令行 HTTP 工具（配合代理设置）抓取。核心是显式指定出口，别依赖工具的默认策略：
# 通过代理走命令行抓取
curl -x "http://<IP>:<port>" \
-A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
-o page.html \
"https://<target-host>/path"
# 或设置环境变量，让所有命令行工具统一走这个出口
export HTTP_PROXY="http://<IP>:<port>"
export HTTPS_PROXY="http://<IP>:<port>"
curl -A "Mozilla/5.0 ..." "https://<target-host>/path"
如果是在脚本里，就用 Python 的 urllib / requests 显式带上代理（见相关案例），把出口固定下来。
需要注意的一点：换出口能解决"被拦"的问题，但换了出口之后要重新验证结果——不同出口可能拿到不同地区/语言/登录态的页面，确认你拿到的是想要的那份内容。
延伸与预防
这个案例的核心洞察是："抓取失败"要先问"它到底从哪个出口出去"，而不是先问"目标站是不是拦我了"。
排查思路可以固化成一张清单：
- 确认出口——这个工具走的是系统代理、还是自己配置的出口？两台工具是不是同一个出口？
- 对比请求——同时用两个工具抓同一 URL，比对实际发出的请求（头、IP、TLS 指纹）；
- 隔离变量——把 A 工具的出口配到 B 工具上试，看问题是否跟着"出口"走；
- 再谈拦截——只有确认出口相同、请求相同，才轮到讨论目标站的风控。
预防上，在团队环境里，给采集类任务固定一条可用的出口并写进文档，比让每个工具各自为政要稳得多。当不同工具行为不一致时，第一个怀疑对象应该是"出口策略"，而不是工具的实现质量。
一句话：同一条 URL 从不同出口出去，结果可能完全不同。 遇到"换工具就好"的现象，先去看出口，别急着换工具。