cURL 在全球的安装量估计高达 200 亿次——它默认内置于 macOS、绝大多数 Linux 发行版，以及 Windows 10/11。可即便如此，随便问十个开发者“如何让 cURL 请求正确走代理”，你多半会得到十种略有差异的答案，而且其中一半会在认证或 SOCKS 参与进来后立刻翻车。
这正是我想在这里补上的空白。大多数教程只会给你一个命令，告诉你“能用”，然后就结束了。它们不会告诉你如何确认代理真的在转发流量（剧透：有时它其实没有），更不会带你逐一拆解那些一旦配置稍有偏离“理想路径”就会出现的错误码。这份指南会把 HTTP/HTTPS 代理、SOCKS4/SOCKS5/socks5h、环境变量（以及它们非常具体的坑）、完整的故障排查表，以及当 cURL 和代理实在无能为力时该怎么办，一次讲透。
什么是 cURL？为什么要配合代理使用？
cURL 是一个用于通过 URL 在本地与远端之间传输数据的命令行工具。就这么简单——没有图形界面，没有花里胡哨的功能，它只是一个支持 HTTP、HTTPS、FTP 以及少量其他协议的程序。最基础的用法如下：
curl https://example.com
这条命令会抓取网页，并把原始 HTML 输出到终端。单独使用也很有价值，但开发者和技术型业务用户真正依赖 cURL 的原因，通常是测试 API、抓取数据、查看地域限制内容，以及在 CI/CD 流水线中执行请求。
代理服务器位于你的设备和目标服务器之间，代替你转发请求。目标站点看到的是代理的 IP，而不是你的 IP。这在很多正当场景下都很有用：例如测试网站在其他国家/地区的显示效果、在 QA 环节绕开速率限制，或者把流量导向公司要求使用的企业网关。cURL 支持完整的代理协议范围——HTTP、HTTPS、SOCKS4 和 SOCKS5——而你在本文中会反复见到的参数主要是 -x / --proxy（代理地址本身）、-v（详细输出，是你最好的调试帮手）以及 -k（跳过 SSL 校验，除测试场景外基本不该使用）。
继续之前先说明一点：这篇指南讨论的是在网络层面如何让 cURL 使用代理。它并不意味着你可以无视目标网站的服务条款或组织的安全政策。代理只会改变你的网络路径，不会改变什么是合法或被允许的。
开始前准备
难度： 初级到中级
所需时间： 约 15 分钟即可完成核心示例
你需要准备：
- 已安装 cURL（可用
curl --version检查——如果你用的是 macOS、Linux 或 Windows 10/11，通常它已经自带了） - 代理服务商提供的凭据：主机、端口、协议（HTTP/HTTPS/SOCKS），以及用户名/密码（如果需要）
- 一个终端（macOS 上的 Terminal、Linux 上的任意 shell、Windows 上的 PowerShell 或 CMD）
如果你的系统里确实没有 cURL，也很容易安装：macOS 可通过 Homebrew 执行 brew install curl，Debian/Ubuntu 执行 sudo apt install curl，RHEL/CentOS 执行 sudo yum install curl。在 Windows 上，自 Windows 10 build 17063 起它就已经随系统附带。
下文我会用占位符——代理地址用 proxy.example:8080，凭据用 user:pwd。请把它们替换成你的真实代理信息，也千万别把真实凭据贴到 shell 历史、截图或者 Slack 消息里。说真的，我见过太多代理密码在 Slack 频道里意外泄露的案例了。
如何通过 HTTP 或 HTTPS 代理使用 cURL
这是最常见的配置，也是你在绝大多数代理任务中会用到的方式。
使用 -x / --proxy 参数
基础写法如下：
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
-x 和 --proxy 的作用完全一样，选你更容易记住的那个即可。由于 HTTP 是 cURL 默认的代理方案，技术上你甚至可以省略 http:// 前缀，直接写成 proxy.example:8080。不过我仍建议显式写出来，因为半年后你会感谢当时自己留的清晰痕迹。
整个 URL 最好都用双引号包起来。如果密码里包含 @、# 或 &，不加引号的话，shell 会在 cURL 看到之前就把字符串弄乱。
通过 HTTPS 代理连接
有些代理服务会把“到代理本身”的连接也用 TLS 加密，而不仅仅是代理到目标站点的连接。这和抓取 HTTPS 网站是两回事——代理协议和目标协议是彼此独立的变量。要指定它，写法如下：
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
如果这里出现证书错误，别急着直接加个 -k 糊过去。这个参数会彻底关闭 SSL 证书验证，做五分钟本地测试还行，但凡涉及生产环境或真实用户数据，都不是好主意。如果你面对的是会拦截 TLS 的企业代理（也就是常见的 MITM 方案），正确做法是导入该代理的 CA 证书，而不是关闭校验。
使用 --proxy-user 进行认证
你也可以把凭据单独放到参数里，而不是塞进 URL：
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
注意，大写的 -U 并不是目标站点认证（-u / --user，小写）——这两个参数混淆很容易把你的代理密码送到错误的位置。对于使用 NTLM 或 Digest 认证而不是 Basic 的企业环境，可以在 --proxy-user 之外再加上 --proxy-ntlm 或 --proxy-digest。
如何使用 SOCKS 代理：SOCKS4、SOCKS5 和 socks5h 的区别
SOCKS 代理的工作层级比 HTTP 代理更低——它们并不关心你在隧道里传的是什么协议，这让它们在非 HTTP 流量、Tor 链路以及任何对隐私敏感的场景中都非常有用。很多竞品教程只给一条命令就结束了，但这其实是个错误，因为 SOCKS4、SOCKS5 和 socks5h:// 之间的差异真的很重要。
| 功能 | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| TCP 支持 | 是 | 是 | 是 |
| UDP 支持 | 否 | 是 | 是 |
| 认证 | 否 | 是 | 是 |
| 远程 DNS 解析 | 否 | 否（本地 DNS） | 是（由代理解析） |
| 兼容 Tor | 否 | 有风险（DNS 泄露） | 是 |
真正容易踩坑的是 DNS 解析这一行。使用 socks5:// 时，你的本机会在把连接交给代理之前先解析主机名——也就是说，你本地的 DNS 解析器（进一步说，甚至你的 ISP）都能看到你要访问哪个域名，虽然真正的 HTTP 流量是经代理传输的。socks5h:// 的做法则是把主机名解析交给代理来完成，这样本地就不会泄露目标信息。Tor 文档之所以强烈要求使用 socks5h://，原因就在于此——如果只用普通的 socks5://，会破坏 Tor 原本应提供的大部分匿名性。
下面是 cURL 中的几种写法：
curl --socks4 "proxy.example:1080" "http://example.com"
curl -x "socks5://user:pwd@proxy.example:1080" "http://example.com"
curl -x "socks5h://user:pwd@proxy.example:1080" "http://example.com"
除非你有明确理由不用，否则默认选择 socks5h://。它不会带来额外成本，却能避免一个你平时根本察觉不到的数据泄露点。
使用环境变量设置代理（以及如何避开这些坑）
每条命令都手动写 -x 很快就会烦。环境变量允许你在一个 shell 会话里设置一次代理，之后所有 cURL 调用都会自动继承这一配置——cURL 的手册支持的变量包括 http_proxy、HTTPS_PROXY、ALL_PROXY 和 NO_PROXY。
基础写法
export http_proxy="http://user:pwd@proxy.example:8080"
export HTTPS_PROXY="http://user:pwd@proxy.example:8080"
export ALL_PROXY="socks5h://proxy.example:1080"
最容易让人困惑的一点是：变量名指的是目标 URL 的协议，不是代理本身的协议。也就是说，http_proxy 负责处理 http:// 请求，HTTPS_PROXY 负责处理 https:// 请求——这两个变量完全可以都指向同一个 HTTP 代理服务器，这很正常。
使用 NO_PROXY 绕过代理
export NO_PROXY="localhost,127.0.0.1,.internal.example"
多个值用逗号分隔，.internal.example 前面的点表示它对所有子域名都生效。NO_PROXY 的优先级高于其他所有设置——即使命令行里显式写了 -x，只要目标匹配 NO_PROXY，该请求仍然会绕过代理。
真正会让人翻车的几个坑
- 忘记写
export。 如果你只是输入http_proxy=http://...却没有export，这个变量只存在于当前 shell 中，对作为子进程运行的 cURL 完全不可见。以我的经验，这几乎是“代理为什么不生效”这类工单最常见的原因。 - 大小写问题。 cURL 会优先检查小写的
http_proxy，如果大小写两种都存在，它会优先采用小写版本。某些其他工具只读取大写。若你在排查“变量没被识别”时卡住了，先看看是不是有一份大小写不一致的重复配置。 - PowerShell 别名陷阱。 在 PowerShell 5.1 中，输入
curl并不会真正调用 cURL，而是执行Invoke-WebRequest——这是另一个完全不同的工具，参数也不同。如果你在 Windows 上发现-x报出各种离谱错误，请显式输入curl.exe，确保跑的真的是 cURL。 - Windows 语法差异。 CMD 里要用
set http_proxy=...；PowerShell 里则是$env:http_proxy = "..."。不同终端会话之间把这些语法混用，很容易把一整个下午都搭进去。 - 残留的旧变量。
unset http_proxy和unset https_proxy可以清除已经失效的代理配置，避免它们悄悄地把每个请求都导向错误路径并导致失败。
如果你想快速切换，给 .bashrc 加两个别名会省很多时间：
alias proxyon='export http_proxy="http://proxy.example:8080"; export https_proxy="http://proxy.example:8080"'
alias proxyoff='unset http_proxy; unset https_proxy'
让 cURL 始终使用代理（配置文件方式）
如果你 95% 的时间都在企业代理后面工作，那么可以在 Unix 类系统的主目录里放一个 .curlrc 文件，或者在 Windows 的 app-data 目录里放 _curlrc，这样就能设置一个持久默认值，而无需碰环境变量：
proxy="http://proxy.example:8080"
如果某次请求需要临时绕过它，可以在那条命令里加 --noproxy "*"，它会覆盖当前配置。一般来说，优先级是：命令行参数 > 环境变量 > 配置文件，因此一旦有冲突，命令行里的 -x 永远优先生效。
一个重要提醒：不要把明文密码写进 .curlrc，尤其当它可能被同步、备份，或者不小心提交到代码仓库时。对于 CI 流水线，最好使用平台自带的密钥管理器，把凭据以脱敏环境变量的方式注入。
如何确认代理真的在工作
这部分几乎是其他教程最常省略的，但它往往最能节省排查时间。先把代理配上，然后“想当然”地以为流量已经走代理了——这正是很多人花几个小时排查一个其实从来没用过代理的爬虫的原因。
方法 1：对比你的出口 IP
同样发两次 IP 回显请求，一次直连，一次走代理，然后对比结果：
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
如果两条命令返回的 IP 地址一样，说明你的代理根本没生效。检查参数语法、环境变量，或者看看是不是 NO_PROXY 意外匹配了目标地址。
方法 2：查看详细输出
给任意代理请求加上 -v，cURL 就会打印完整握手过程：
curl -v -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
重点看是否出现类似 * Connected to proxy.example (xx.xx.xx.xx) port 8080 的行，随后是 > CONNECT httpbin.org:443 HTTP/1.1，最后变成 < HTTP/1.1 200 Connection established。这一串过程——先连接代理，再通过 CONNECT 建立到目标站点的隧道——就是 HTTP CONNECT 方法在发挥作用，也正是 HTTPS 目标经 HTTP 代理转发时应该发生的事情。如果始终看不到 CONNECT，那就说明代理参数根本没有被应用。再提醒一次：-v 只应在调试时使用，分享日志前务必脱敏，因为详细输出里可能会直接打印代理凭据明文。
方法 3：左右对比 diff
如果是做地理位置测试，最直观的办法就是把两次结果分别保存成文件，然后做 diff：
curl https://httpbin.org/ip > direct.json
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip > proxied.json
diff direct.json proxied.json
如果响应体（或地理限制内容的响应头）不同，就能很直观地确认代理确实改变了你的网络路径。在继续深入排查前，这是一种快速、低成本、能立刻消除疑虑的方法。
常见 cURL 代理错误排查
很多教程在这里只是轻描淡写地提一句 -k，但这个主题值得一张真正的参考表。
| 错误 | 可能原因 | 解决办法 |
|---|---|---|
curl: (7) Failed to connect | 代理主机/端口错误，或代理服务本身宕机 | 检查地址；使用 telnet host port 或 nc -zv host port 测试基础连通性 |
407 Proxy Authentication Required | 代理凭据缺失或错误 | 添加 --proxy-user user:pass；确认服务商是否要求 NTLM/Digest/Negotiate，而不是 Basic |
curl: (56) Recv failure: Connection reset by peer | 代理在传输中途断开了连接 | 与服务商确认代理稳定性；如果是终止 TLS 的代理，请检查证书处理，而不是强行关闭验证 |
curl: (28) Connection timed out | 防火墙拦截、旧代理失效，或端口填写错误 | 执行 env | grep -i proxy 查看是否残留旧变量；清理后再测试直连请求，以便定位原因 |
| 证书验证失败 | 代理证书不受信任，或代理正在拦截证书 | 获取正确的 CA 链并使用 --proxy-cacert；除非只是一次性诊断，否则不要关闭校验 |
遇到这些问题时，通用的第一步都是加上 -v。它会明确告诉你连接究竟卡在哪一步——DNS 解析、TCP 连接、TLS 握手，还是代理认证交换——而不是让你对着一个三位数错误码瞎猜。
对于企业代理，--proxy-ntlm 和 --proxy-negotiate 可以覆盖 Windows 域认证方案。cURL 有一个确实不支持原生处理的东西：PAC 文件（某些企业用来动态分配代理的 Proxy Auto-Config 脚本）。如果你所在公司使用这类配置，你需要手动提取真实的代理主机和端口——通常可以在浏览器的网络设置中找到——因为 cURL 没有内置 PAC 解析器。
当 cURL + 代理仍然不够用时
cURL 配合代理，处理静态 HTML、REST API 调用以及简单数据抓取，已经是非常能打的组合了。但在现代网页最常见的防护面前，它也会失灵：比如 JavaScript 渲染的单页应用、Cloudflare 或 Akamai 这类反爬系统，以及 CAPTCHA 门禁。把 cURL 指向一个被这些机制保护的 React 或 Vue 应用，你往往只会拿回一个空的 <div id="root"></div>——从技术上看请求成功了，实际上却毫无用处。这不是 cURL 的 bug，它本来就不是浏览器，也从未假装自己是浏览器。
如果你已经习惯在终端里跑 cURL，但又碰到了这个瓶颈，那么下一步通常不是换一整套完全不同的工具链，而是在其上增加一层负责渲染和结构化处理的能力。这正是 Thunderbit 的开发者工具想要填补的空缺。
| 场景 | cURL + 代理 | Thunderbit API (POST /extract) |
|---|---|---|
| 静态 HTML 页面 | 完全可用 | 可用，而且还能返回结构化数据 |
| JS 渲染的 SPA | 只能拿到空白/不完整 HTML | renderMode: "full" 可处理 JS |
| 反爬 / CAPTCHA | 会被拦截 | 内置处理 |
| 结构化数据输出 | 原始 HTML，需要自己解析 | 按你自己的 schema 输出 JSON |
| 批量（100+ URL） | 需要手动循环和限速 | POST /batch/extract |
Thunderbit 的 Open API 提供 /extract 端点，可以直接从 JS 密集型页面返回符合 schema 的 JSON；还有一个 /distill 端点，用于干净地转换为 Markdown。这两个接口都能在你一直使用的同一个终端会话中调用。它还提供适用于 Claude 或 Cursor 这类 AI 编程助手的 MCP 服务器，以及一个 CLI（npx @thunderbit/thunderbit-cli extract <url> --schema fields.json），如果你更喜欢完全留在脚本里操作，也完全可以。它并不是要取代 cURL 擅长的工作，而是负责补上 cURL 无法继续深入的那一段。如果你想更全面地了解 AI 辅助提取和自己编写爬虫逻辑之间的差别，我们的 AI 网页抓取 综述和 最佳 AI 网页爬虫 对比会讲得更细；如果你是从业务角度而非工程角度切入，无代码网页抓取 这篇文章也很适合作为入门。
总结
只要掌握了真正的故障点，cURL 和代理之间的配合其实并不难——而且你会发现，出问题的几乎都不是代理本身。忘了 export。把 -u 和 -U 搞混。该用 socks5h:// 的时候用了 socks5://。在 PowerShell 里调用了别名 curl，而不是 curl.exe。这些都会产生看起来很像代理问题、实则完全无关的模糊错误。
最省时间的习惯就是：先验证，再排查。先跑 IP 回显检查，看一眼 -v 输出，在怀疑下游出问题之前，先确认请求路径里真的已经用了代理。当目标站点开始返回 JavaScript 而不是干净的 HTML 时，这就不是靠多加几个参数能解决的 cURL 问题了——这其实是在提醒你换用专门负责渲染的工具，比如 Thunderbit 的 API。它提供免费层，方便你亲自感受“返回 JSON，而不是原始 HTML”的差别。
常见问题
cURL 默认会使用代理吗？
不会。除非你设置了 http_proxy / HTTPS_PROXY 环境变量，或者配置了 .curlrc 文件，否则 cURL 会直接连接目标站点，不经过代理。
如何让 cURL 在单次请求中不走代理？
在那条特定命令里加上 --noproxy "*" 即可。如果想对整个 shell 会话都清除代理，运行 unset http_proxy && unset https_proxy。
cURL 可以搭配轮换代理使用吗？
可以——如果你的服务商提供轮换网关（即一个单一入口，每次请求都会分配新的 IP），只需像使用其他代理一样，把 -x 指向这个网关地址即可。如果要面对更复杂的轮换逻辑，尤其是针对 JS 渲染目标，像 Thunderbit 这样的 API 会在内部处理轮换和反爬环节，这样你就不用自己手写重试逻辑了。
为什么 socks5:// 会泄露 DNS 请求，而 socks5h:// 不会？
使用 socks5:// 时，你的本机在把连接请求发给代理之前，会先解析目标主机名——也就是说，你的 ISP 的 DNS 解析器能看到你访问的域名。socks5h:// 则把主机名解析交给代理自己完成，因此本地不会暴露目标信息。
使用 cURL 配合代理合法吗？
在大多数司法辖区，仅仅使用代理本身是合法的。真正重要的是你如何使用它——务必遵守目标网站的服务条款、适用时的 robots.txt，以及相关数据隐私法规。本指南只讨论技术机制，不构成对任何具体用例的法律许可。
了解更多
