cURL 在全球估計有 200 億次安裝——macOS、多數 Linux 發行版，以及 Windows 10/11 都已內建。即便如此，如果你問十位開發者：要怎麼正確透過 proxy 轉送 cURL 請求？你大概會得到十種略有不同的答案，而且其中一半只要牽涉到驗證或 SOCKS 就會立刻失效。
這正是我想補上的落差。大多數教學只會給你一條指令，告訴你「這樣就能用」，然後就結束了。它們不會教你如何確認 proxy 是否真的有在工作（劇透：有時候其實沒有），更不會帶你逐一拆解那些只要設定稍微偏離理想路徑就會跳出的錯誤碼。這份指南會完整涵蓋 HTTP/HTTPS proxy、SOCKS4/SOCKS5/socks5h、環境變數（以及它們非常常見的陷阱）、實用的除錯對照表，還有當 cURL 加上 proxy 依然不夠用時，該怎麼辦。
什麼是 cURL？為什麼要搭配 Proxy 使用？
cURL 是一個用來從 URL 傳送與接收資料的命令列工具。就這樣——沒有圖形介面、沒有花俏功能，它就是一個支援 HTTP、HTTPS、FTP 和其他幾種協定的程式。最簡單的用法像這樣：
curl https://example.com
這會抓取頁面，並把原始 HTML 直接輸出到終端機。單獨使用就很有幫助，但開發者與技術型商務使用者真正愛用 cURL 的原因，是拿來測試 API、抓取資料、檢查地區限制內容，以及在 CI/CD 流程中執行請求。
proxy 會介於你的裝置與目標伺服器之間，代替你轉發請求。目標伺服器看到的是 proxy 的 IP，而不是你的。這在一些正當情境下非常重要，例如：測試網站在不同國家的呈現方式、在 QA 階段繞過速率限制，或是把流量導向公司要求的企業 gateway。cURL 支援完整的 proxy 協定範圍——HTTP、HTTPS、SOCKS4 與 SOCKS5——而你會在這份指南中反覆看到的旗標有 -x / --proxy（proxy 位址本身）、-v（詳細輸出，你最好的除錯夥伴），以及 -k（略過 SSL 驗證，除了測試之外，基本上不該使用）。
在往下之前先提醒一下：這份指南談的是透過 cURL 使用 proxy 的網路機制。這不代表你可以無視目標網站的服務條款或你所屬組織的資安政策。proxy 只會改變你的網路路徑，不會改變什麼是合法或被允許的。
開始之前
難度： 初學者到中階 所需時間： 約 15 分鐘即可跑完核心範例 你需要準備：
- 已安裝 cURL（可用
curl --version檢查——如果你使用的是 macOS、Linux 或 Windows 10/11，通常早就內建了） - 來自 proxy 服務商的憑證：主機、埠號、協定（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 當作 proxy 位址，user:pwd 當作帳密。請把它們換成你自己的實際資料，而且千萬不要把真實憑證貼到 shell history、截圖或 Slack 訊息裡。我在 Slack 頻道看過的 proxy 密碼外洩案例，比我願意承認的還多。
如何用 cURL 連接 HTTP 或 HTTPS Proxy
這是最常見的設定，也是你處理絕大多數 proxy 任務時會用到的方式。
使用 -x / --proxy 旗標
基本語法如下：
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
-x 和 --proxy 功能完全相同——你記哪個順手就用哪個。由於 HTTP 是 cURL 預設的 proxy scheme，技術上你可以省略 http:// 前綴，直接寫 proxy.example:8080。不過我仍建議明確寫出來，因為六個月後你會感謝自己當初寫得夠清楚。
請用雙引號把整個 URL 包起來。若密碼裡包含 @、# 或 &，沒加引號的字串在 cURL 看到之前，就可能先被 shell 解析壞掉。
透過 HTTPS Proxy 連線
有些服務商會對「連到 proxy 本身」這段連線使用 TLS，而不只是 proxy 到目標站點的那一段。這和抓取 HTTPS 網站是兩回事——proxy 協定和目標協定是彼此獨立的變數。要指定它，像這樣：
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
如果這裡遇到憑證錯誤，請不要急著加上 -k 然後就當沒事。這個旗標會完全關閉 SSL 憑證驗證，做五分鐘的本機測試還行，但只要碰到正式環境或真實使用者資料，就非常不建議。如果你面對的是會攔截 TLS 的企業 proxy（也就是常見於企業環境的 MITM 架構），正確解法是匯入 proxy 的 CA 憑證，而不是關掉驗證。
使用 --proxy-user 進行驗證
你也可以把帳密拆成獨立旗標，而不是硬塞進 URL：
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
注意，大寫 -U 跟目標網站驗證（小寫 -u / --user）不是同一件事——這兩個搞混，很容易把你的 proxy 密碼送到錯的地方。若是企業環境使用 NTLM 或 Digest 驗證，而不是 Basic，請搭配 --proxy-user 加上 --proxy-ntlm 或 --proxy-digest。
如何用 cURL 連接 SOCKS Proxy：SOCKS4、SOCKS5 與 socks5h 的差別
SOCKS proxy 的運作層級比 HTTP proxy 更低——它不在乎你透過它轉送的是哪種協定，因此特別適合非 HTTP 流量、Tor 連線，或任何重視隱私的情境。多數競品指南只會在這裡丟一條指令就帶過，但這其實是錯的，因為 SOCKS4、SOCKS5 與 socks5h:// 之間的差異真的很重要。
| 功能 | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| TCP 支援 | 是 | 是 | 是 |
| UDP 支援 | 否 | 是 | 是 |
| 驗證 | 否 | 是 | 是 |
| 遠端 DNS 解析 | 否 | 否（本機 DNS） | 是（由 proxy 解析） |
| 相容 Tor | 否 | 有風險（DNS 洩漏） | 是 |
真正最容易出問題的是 DNS 解析這一列。使用 socks5:// 時，你的電腦會先解析主機名稱，再把連線交給 proxy——也就是說，你本機的 DNS 解析器（進一步來說，你的 ISP）會知道你要連去哪個網域，儘管實際的 HTTP 流量是走 proxy。socks5h:// 則改成讓 proxy 來處理主機名稱解析，讓本機不會洩漏目標資訊。這也是 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://。它不會增加額外成本，卻能避免一個你平常根本不會察覺的洩漏。
用環境變數設定 Proxy（以及避開常見陷阱）
每次都在每條指令前加 -x，很快就會讓人煩。環境變數可以讓你在每個 shell session 只設定一次 proxy，後續所有 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 的協定」，不是 proxy 的協定。所以 http_proxy 是管 http:// 開頭的請求，而 HTTPS_PROXY 是管 https:// 開頭的請求——兩者完全可以指向同一台 HTTP proxy server，這是很正常的做法。
用 NO_PROXY 進行繞過
export NO_PROXY="localhost,127.0.0.1,.internal.example"
逗號分隔，且 .internal.example 前面的點代表可匹配任何子網域。NO_PROXY 會覆蓋其他所有設定——即使你在命令列上明確指定了 -x，只要目標符合 NO_PROXY，該請求就會繞過 proxy。
真正最常害人踩雷的地方
- 忘了加
export。 如果你只輸入http_proxy=http://...卻沒有export，這個變數只存在於目前 shell，對於作為子程序執行的 cURL 來說是完全看不到的。就我經驗而言，這是「proxy 不能用」這類支援單最常見的原因。 - 大小寫敏感。 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可以移除那些默默把所有請求導向舊 proxy、最後還全部失敗的殘留設定。
如果你只是想快速切換，在 .bashrc 裡加幾個 alias 真的很省時間：
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 永遠走 Proxy（設定檔）
如果你 95% 的時間都在企業 proxy 後面工作，可以用 .curlrc（Unix-like 系統放在家目錄）或 _curlrc（Windows 放在 app-data 資料夾）來設定永久預設值，完全不必碰環境變數：
proxy="http://proxy.example:8080"
如果某次單獨請求需要跳過它，可用 --noproxy "*" 覆蓋那一次執行的設定。優先順序通常是：命令列旗標 > 環境變數 > 設定檔，所以只要命令列有 -x，遇到衝突時永遠以命令列為準。
一個重要提醒：不要把明文密碼直接寫進 .curlrc，尤其當它可能被同步、備份，或不小心提交到 repo 時。若是 CI pipeline，請改用平台的 secret manager，並以遮罩過的環境變數注入憑證。
如何確認你的 Proxy 真的有在運作
這一段幾乎是其他教學最常略過的，但卻是最能省下除錯時間的部分。把 proxy 設好，然後直接假設流量有走 proxy，這正是很多人花好幾個小時排查爬蟲卻發現根本沒用 proxy 的原因。
方法 1：比較你的對外 IP
同一個 IP 回應請求跑兩次——一次直連，一次透過 proxy——然後比較：
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
如果兩個指令回傳相同的 IP，代表你的 proxy 根本沒有發揮作用。請檢查旗標語法、環境變數，或看看是不是 NO_PROXY 不小心把目標也排除了。
方法 2：閱讀詳細輸出
在任一 proxy 請求加上 -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。這一串流程——先連 proxy，再用 CONNECT 建立到目標站的隧道——就是 HTTP CONNECT method 的實際運作方式，也是 HTTPS 目標透過 HTTP proxy 時應該出現的行為。如果你完全看不到 CONNECT 那行，代表 proxy 旗標根本沒有套用上。順帶提醒：只有在除錯時才開 -v，而且分享之前務必把輸出遮掉，因為詳細模式可能會把 proxy 憑證以明文顯示。
方法 3：左右對照比對
如果是做地區測試，可以把兩份輸出都存成檔案再比對：
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
如果回應內容（或是地區限制內容的標頭）不同，就能明確證明 proxy 確實改變了你的網路路徑——這是一個快速、低成本的方法，可以在你繼續深入排查前先消除疑慮。
常見 cURL Proxy 錯誤排查
多數教學在這裡只會輕描淡寫地提到一次 -k。但這個主題值得一張真正的參考表。
| 錯誤 | 可能原因 | 解法 |
|---|---|---|
curl: (7) Failed to connect | proxy 主機或埠號錯誤，或 proxy 當機 | 檢查位址；用 telnet host port 或 nc -zv host port 測試基本連通性 |
407 Proxy Authentication Required | proxy 憑證缺失或錯誤 | 加上 --proxy-user user:pass；確認服務商是否要求 NTLM/Digest/Negotiate，而不是 Basic |
curl: (56) Recv failure: Connection reset by peer | proxy 在傳輸途中把連線切斷 | 向供應商確認 proxy 穩定性；若是會終止 TLS 的 proxy，請檢查憑證處理，不要直接關閉驗證 |
curl: (28) Connection timed out | 防火牆阻擋、舊 proxy、或埠號錯誤 | 執行 env | grep -i proxy 檢查殘留變數；清除舊設定；直接發送請求以縮小範圍 |
| 憑證驗證失敗 | 不受信任或會攔截流量的 proxy 憑證 | 取得正確的 CA 鏈並使用 --proxy-cacert；避免在非一次性診斷情境下關閉驗證 |
這些情況的萬用第一步，都是加上 -v。它能直接告訴你連線是卡在 DNS 解析、TCP 連線、TLS 握手，還是 proxy 驗證交換，而不是讓你只靠三位數錯誤碼瞎猜。
針對企業 proxy，--proxy-ntlm 和 --proxy-negotiate 可支援 Windows 網域驗證機制。cURL 確實有一件事原生處理不了：PAC 檔（某些企業用來動態分配 proxy 的 Proxy Auto-Config 腳本）。如果你的公司有用 PAC，你就得手動找出實際的 proxy host 和 port——通常可以從瀏覽器的網路設定裡查到——因為 cURL 沒有內建 PAC 解析器。
當 cURL + Proxy 還是不夠用時
cURL 配上 proxy，處理靜態 HTML、REST API 呼叫，以及簡單資料擷取，基本上已經相當夠用了。但它最容易卡住的，是現代網站最愛用的防護：JavaScript 渲染的單頁應用、像 Cloudflare 或 Akamai 這類 anti-bot 系統，以及 CAPTCHA 閘門。把 cURL 指向一個被這些機制保護的 React 或 Vue 應用，你通常只會拿回一個空的 <div id="root"></div>——技術上請求成功了，但實際上沒有任何可用資料。這不是 cURL 的 bug，它只是本來就不是瀏覽器，也從沒假裝自己是瀏覽器。
如果你已經很習慣在終端機裡跑 cURL，卻碰上這道牆，下一步通常不是換一套完全不同的工具，而是加上一層能幫你處理渲染與結構化輸出的能力。這正是 Thunderbit 開發者工具想補上的缺口。
| 情境 | cURL + Proxy | Thunderbit API (POST /extract) |
|---|---|---|
| 靜態 HTML 頁面 | 完全可用 | 可用，而且會回傳結構化資料 |
| JS 渲染的 SPA | 只會拿到空白或不完整 HTML | renderMode: "full" 可處理 JS |
| Anti-bot / CAPTCHA | 會被擋下 | 內建處理機制 |
| 結構化資料輸出 | 原始 HTML——你得自己解析 | 依你的 schema 直接輸出 JSON |
| 批次處理（100+ URLs） | 手動迴圈 + 自己處理速率限制 | POST /batch/extract |
Thunderbit 的 Open API 提供 /extract endpoint，可直接從 JS 很重的頁面回傳符合 schema 的 JSON；另外還有 /distill endpoint，能把內容整理成乾淨的 Markdown——這兩者都能在你一路以來使用 cURL 的同一個終端機環境中呼叫。它也提供給 Claude 或 Cursor 這類 AI coding assistant 使用的 MCP server，以及 CLI（npx @thunderbit/thunderbit-cli extract <url> --schema fields.json），如果你想完全維持在 script 內運作，也沒問題。這些都不是要取代 cURL 擅長的工作，只是補上 cURL 結構上無法再往前走的部分。如果你想更全面了解 AI 輔助擷取與自行撰寫爬蟲邏輯的差異，我們的 AI web scraping 概述與 best AI web scrapers 比較會更深入說明；如果你是從商務角度切入，web scraping without coding 這篇也很適合作為入門。
結語
當你知道真正的失敗點在哪裡之後，讓 cURL 和 proxy 正常溝通其實不難——而事實證明，幾乎沒有一個問題真的是 proxy 本身造成的。忘了 export。把 -u 和 -U 搞混。該用 socks5h:// 卻用了 socks5://。在 PowerShell 裡呼叫別名 curl，而不是 curl.exe。這些都會產生看起來很像 proxy 問題、其實一點關係都沒有的通用錯誤。
最省時間的習慣是：先驗證，再排查。先跑 IP 回顯測試，看看 -v 輸出，先確認 proxy 真的有進入請求路徑，再假設後面哪裡壞了。當你的目標站開始回你 JavaScript，而不是乾淨的 HTML，那就不是靠多加幾個旗標能解決的 cURL 問題了——這代表你該換成專門處理渲染的工具，例如 Thunderbit 的 API。如果你想親自比較「輸出 JSON」和「原始 HTML」的差異，它也提供免費方案可先試用。
常見問題
cURL 預設會使用 proxy 嗎？
不會。除非你已設定 http_proxy / HTTPS_PROXY 環境變數，或配置了 .curlrc 檔，否則 cURL 都會直接連到目標，不會經過 proxy。
要怎麼讓 cURL 在單次請求中不要用 proxy？
在那條特定指令後加上 --noproxy "*"。如果要整個 shell session 都關掉，執行 unset http_proxy && unset https_proxy 即可。
cURL 可以搭配輪換 proxy 使用嗎？
可以——如果你的服務商提供輪換 gateway（單一入口、每次請求都分配新 IP），只要像一般 proxy 一樣，把 -x 指向那個 gateway 位址即可。若面對更複雜、且有 JS 渲染的目標，像 Thunderbit 這類 API 層會在內部處理輪換與 anti-bot，讓你不用手動管理 retry 邏輯。
為什麼 socks5:// 會洩漏 DNS 請求，但 socks5h:// 不會？
使用 socks5:// 時，你的本機會先解析目的地主機名稱，再把連線請求送給 proxy——也就是說，你 ISP 的 DNS 解析器看得到你正在造訪的網域。socks5h:// 則把主機名稱解析交給 proxy 本身處理，因此本機不會看到任何目標資訊。
用 cURL 搭配 proxy 合法嗎？
在多數司法管轄區，單純使用 proxy 本身是合法的。真正重要的是你拿它來做什麼——請始終遵守目標網站的服務條款、適用時的 robots.txt，以及任何相關的資料隱私法規。本指南只談技術操作，不構成任何特定用途的法律背書。
延伸閱讀
