每一篇「最佳 proxy API」清單文都很容易犯同一個分類錯誤：把 Bright Data、Thunderbit 和 Apify 當成是在搶同一份工作。其實不是。某個產品可能提供路由過的 IP 連線，另一個可能直接回傳結構化 JSON，還有一個可能負責執行排程式爬取流程。拿這些產品只比起始價格，就像把花園水管和淨水廠拿來比，根本不是同一件事。
本指南根據 2026 年 8 月 10 日取得的官方文件，整理了十款 proxy、代管爬取、資料擷取與平台型產品。這裡不會宣告哪一款是放諸四海皆準的冠軍，也不會重複那些無法移植的成功率說法。相反地，這篇文章會教你如何先定義「有效結果」，再依產品類別縮小名單，最後用你自己的目標站點跑一個經授權的試驗。
為什麼「Proxy API」不是單一概念
每次有人問「我該用哪個 proxy API」時，最核心的混淆點就在這裡：這個詞其實涵蓋了至少四種完全不同的產品。
原始 proxy 網路只提供 IP 與路由控制——其餘事情還是要你自己處理，包括撰寫請求邏輯、重試、必要時渲染 JavaScript，以及解析回傳內容。這是最接近教科書定義的 proxy： RFC 9110 把它描述成由用戶端選擇使用的訊息轉送中介，僅此而已。
代管式解鎖或瀏覽器 API負責更多請求生命週期。你丟一個 URL 給它，它會幫你挑 IP、必要時渲染頁面、失敗時重試，最後回傳 HTML、截圖，有時甚至是 Markdown。
擷取 API則再往上一層——你拿到的是結構化 JSON 或乾淨文字，而不是必須自己解析的原始 HTML。
爬蟲平台則把以上功能連同排程、儲存，甚至預先建好的爬蟲市集一起打包。
這也是為什麼「選擇 proxy API」這個主題不能只看價格和「成功率」：住宅 proxy 網路按流量計費，代管 API 按請求計費，兩者解決的問題根本不同。分母、包含的工作內容與輸出語義都不一樣，直接拿首頁價格排名只會誤導人。所以以下每個產品介紹，都先從產品類別開始。
還有一點先說在前面：有 proxy 存取權，不代表你就能隨便爬任何東西。是否授權、目標站點的服務條款、以及資料隱私義務，都是和「哪家供應商 IP 池最大」完全不同的議題；不管 proxy API 再怎麼強大，都不能把這些問題消掉。
如何評估這十個方案
沒有一套誠實的固定權重，能適用於所有團隊。原始 HTML 歸檔、與地理位置相關的價格監控、結構化資料補全流程，需求都不一樣。你可以先用下列標準，自己定義權重總和為 100，並且只根據你自己的試驗結果或明確需求來打分：
| 評估項目 | 衡量方式 |
|---|---|
| 有效結果率 | 通過語意驗證器的嘗試比例，而不只是 HTTP 200 |
| 每個有效結果成本 | 將請求、流量、渲染、重試、解析、儲存與操作成本全部除以有效輸出數量 |
| 輸出契合度 | 原始回應、渲染後 HTML、截圖、Markdown，或符合 schema 的資料 |
| 連線與地理控制 | 你實際需要的地區、城市、ASN、session、輪換、header、cookie 與協定控制 |
| 可觀測性與限制 | Request ID、計費單位 header、log、重放、併發控制，以及預算停止機制 |
| 合規證據 | 來源說明、合約、目標可用性、稽核性與支援流程 |
| 工程投入 | 整合、parser 維護、監控與人工修復時間 |
不支援的欄位就保持空白，或標記為「不適用」。重點是做出與工作負載相關的決策，而不是做出看起來很精準、其實失真的分數。
1. Thunderbit
Thunderbit 在這份清單裡是個例外，因為它更接近擷取 API，而不是要塞進 HTTP client 的原始 proxy 網路。它的公開 API 文件描述了用於 Markdown 的 Distill、用於 schema 化 JSON 的 Extract，以及支援非同步 URL 集合的 Batch。當你真正需要的是內容或資料列，而不是 proxy 連線時，這個邊界可以直接省掉好幾個下游步驟。
實際差異在你發出第一個請求時就能看出來。傳統 proxy API 成功回應時，通常只會拿到原始 HTML——事情只完成一半。使用 Thunderbit 的 POST /extract 端點時，你只要提供目標 URL 和描述欄位的 JSON Schema，回傳內容就已經是符合 schema 的結構化 JSON。不需要寫 CSS selector，也不用在網站第三季改版商品頁時一直維護 parser。
這個產品邊界本身就是實際賣點：呼叫端可以直接描述輸出 schema，而不是自己維護 proxy、renderer 與 parser 的整套堆疊。不過，它仍然需要真實試驗。正式導入前，請先針對經授權的 URL 驗證欄位完整度、目標支援性、延遲、目前單位消耗、併發能力與失敗行為。
主要特色：
- 預設輸出即為結構化資料 — 回傳的是你定義的 schema JSON，而不是原始 HTML
- 有文件說明的渲染與路由控制 — 這些功能是擷取端點的一部分，而不是獨立的原始 proxy 產品
- HTTP API 邊界清楚 — Distill、Extract 與 Batch 分別涵蓋 Markdown、結構化 JSON 與非同步 URL 集合
- Batch 模式可處理多 URL 的非同步工作，適合不只幾個頁面的批次任務
- schema 化擷取能降低欄位層級驗證與維護成本，但無法完全消除
計費單位：Distill 與 Extract 使用的是文件化的每頁單位，而不是 proxy 頻寬。請在預算前先確認最新的 Thunderbit pricing 與 API 文件，因為單位與方案可能會變。
適合對象：想要直接拿到經驗證的結構化資料、又不想自己建立並維護 proxy 輪換加 parser 管線的開發者。
傳統 proxy API 什麼時候還是更好：如果你需要原始 HTML 來做自訂管線、批次歸檔，或使用非 HTTP 協定，那 Thunderbit 的結構化輸出模型就不是對的工具——你其實需要的是後面九個方案中的某一個。
2. Bright Data
Bright Data 幾乎是這個產業的老大哥，提供 residential、datacenter、ISP 與 mobile proxy 網路，另外還有一個叫 Web Unlocker 的獨立代管產品。這裡「獨立」兩字很重要——Bright Data 不是單一產品，而是一整個產品家族；你買哪一塊，價格與行為都差很多。
Residential 網路文件列出了國家、地區、城市、ZIP 與 ASN 定位。Web Unlocker 則是另一個代管層，採成功付費並設有每月支出上限。這些控制很有用，但它們的準確度與適配性仍需在買方自己的試驗中驗證；本指南沒有做跨供應商的地理基準測試。
主要特色：
- 提供 residential、datacenter、ISP 與 mobile 多種 proxy 類型，並具備細緻的地理定位
- Web Unlocker 代管 API 採成功付費與支出上限機制
- Residential IP 有公開的自願加入來源說明
- 除錯欄位（request ID、計費狀態、對端國家）便於排查問題
計費單位：原始 proxy 產品與 Web Unlocker 使用不同計費方式。預算前請先在官方價格頁確認精確產品、承諾條件、目標可用性與最新費率。
適合對象：需要所有 proxy 類型、並願意接受較複雜產品組合以換取規模的企業團隊。
3. Oxylabs
Oxylabs 和 Bright Data 同屬高階梯隊：同樣有 residential、datacenter、ISP 與 mobile proxy 網路，外加一個名為 Web Unblocker 的代管存取產品。它的 session 處理使用專用的 X-Oxylabs-Session-Id header，讓你能在有限時間內維持 IP 連續性，對於像分頁搜尋結果這類多步驟流程特別實用。
主要特色：
- 多種 proxy 類型，具備供應商文件化的地理控制
- Web Unblocker 用於 JS 渲染與代管解鎖，最新價格以 GB 計費
- 透過 header 型 session ID 維持 session 持續性
- 範例回應中包含 job/session header，方便除錯
計費單位：本次研究取得的 Web Unblocker 頁面使用的是按 GB 計費方案，且方案有專屬速率限制；其他 Oxylabs 產品則採不同單位。請重新查看你所選產品的最新頁面。
適合對象：需要大量流量、地理多樣性，且不介意跨產品管理 GB 型計費的大型營運團隊。
4. ScrapingBee
ScrapingBee 是一個代管 HTML API：你送出 URL，它回傳頁面內容，而下游的驗證與解析通常還是由你負責。文件中公開了依功能而變動的信用點數系統、Auto-Mode、成本 header，以及可以限制單次 Auto-Mode 請求上限的 max_cost 參數。
主要特色：
- Auto-Mode 會自動逐步升級設定（proxy 層級、渲染）直到成功
max_cost參數可限制單次請求支出- Auto-Mode 在所有組合下的失敗嘗試不會消耗信用點數
- 每次回應都會帶有使用/成本 header，便於即時追蹤
計費單位：信用點數會因渲染、proxy 層級與其他啟用功能而不同。不要把基礎方案直接當成每請求價格，而是要看最新的信用階梯與併發限制。
適合對象：小到中型專案，重視快速上線勝過深度客製化；一旦搞懂信用點數機制，成本其實很好預測。
5. ZenRows
ZenRows 把 Universal Scraper API、Scraping Browser 與 residential proxies 打包在同一個平台下，並針對 JavaScript 渲染與高級 proxy 使用設有請求倍數。這裡有個特別值得注意的點：ZenRows 在計費上把 HTTP 404 和 410 視為「成功」，這正好提醒我們——供應商帳單上的「成功」和你驗證器中的「成功」根本不是一回事。
主要特色：
- 組合式工具：scraper API、瀏覽器自動化與 residential proxies
- 宣稱支援多種輸出格式（JSON、Markdown、截圖、純文字）
- 代管渲染與存取元件的實際行為，仍需在經授權目標上驗證
- 依 URL 的使用量限制，超過後需加購容量才能繼續請求
計費單位：請求信用點數，並針對 JavaScript 渲染與高級 proxy 等功能有明確倍數。請確認目前方案與倍數規則。
適合對象：想用同一家供應商評估 scraper API、瀏覽器與 proxy 產品的團隊，同時在經授權的目標上測試各個產品。
到目前為止，有哪些模式浮現？
走到五款工具，你會發現一個很明顯的模式：幾乎沒有哪一家產品的實際邊界，和它的行銷文案完全一致。Bright Data 與 Oxylabs 都把「原始 proxy」與「代管解鎖」拆成不同產品，且各自有不同定價模型；這代表供應商首頁並不能直接回答「我到底會花多少錢」，你必須先選定具體產品。ScrapingBee 與 ZenRows 都採用信用點數制，並隨功能出現倍數變化；這比 GB 計費透明，但你還是得仔細看哪些條件會觸發倍率。
另一個反覆出現的主題是：「成功請求」的定義是供應商說了算，不是你說了算。ZenRows 把 404 算進可計費成功，並不是惡意，只是定義不一致；如果你以為「計費成功」就代表「我真正要的資料已經拿到了」，那就很容易踩雷。
6. Scrape.do
Scrape.do 提供代管 Web Scraping API，採「Successful API Credits」計費模型——你只會為目前的核心端點付費，因為該公司價格導覽中的獨立 proxy 與 scraping-browser 產品都還標示為「coming soon」（所以別急著以為 Scrape.do 已經在賣原始 proxy）。其 API 介面涵蓋地理定位、session、header、cookie，以及瀏覽器/proxy 模式切換。
主要特色：
- 採信用點數制，達到月額上限後就停止請求，預設不會有意外超額費用
- 對符合資格的目標可切換 premium network
- Session 與地理控制應該對照實際工作負載測試
- 具備適用於 JS 密集頁面的瀏覽器渲染模式
計費單位：打包式成功 API 點數，附月度限制；請確認目前方案上限、併發與加購容量規則。
適合對象：預算敏感、但又不想採用 GB 型計費的團隊。
7. Smartproxy / Decodo
Smartproxy 已更名為 Decodo，而目前的 residential proxy 價格頁則列出按 GB 與 PAYG（隨用隨付）方案，並支援 ASN 層級定位，以及在 HTTP(S)/SOCKS5 上的 rotating 與 sticky sessions。取得的頁面引用了 Proxyway 研究作為效能宣稱來源。這個來源很有參考價值，但並不代表同樣結果可以轉移到其他目標、地區、時間窗或帳號設定。
主要特色：
- Residential、datacenter、ISP 與 mobile 多種 proxy 類型
- ASN 與地理位置層級定位
- 支援 HTTP(S) 與 SOCKS5 的 rotating 與 sticky session
- 效能宣稱來自第三方研究，而非自我宣告
計費單位：本次研究取得的 residential 頁面顯示按 GB 與 PAYG 方案。請在選定產品頁確認目前費率與包含的控制項。
適合對象：電商監控與中等規模營運，想要多樣 proxy 類型但又不想碰企業級定價。
8. Scrapfly
Scrapfly 是一個代管爬取 API，附帶可選的 Anti Scraping Protection（ASP）功能。它的文件明確指出：目標防護會持續演進，被封鎖後的恢復時間不確定，而與資源相關的成本也可能變動。這個提醒很重要：代管存取不等於永續存取。
主要特色：
- ASP 會根據目標難度動態提高成本
cost_budget參數與失敗爬取公平保護機制（排除的狀態碼不算在你頭上）- 每個回應都有成本 header，並提供 request replay / 除錯儀表板
- 可選擇瀏覽器渲染與 residential proxy 池
計費單位：信用點數，其成本會因 proxy 池、渲染與 ASP 設定而變化。回應 header、cost_budget 與專案限制有助於量測並控制這些成本。
適合對象：特別重視抗偵測工具，並且希望清楚知道每個請求實際花了多少信用點數的團隊。
9. Zyte
Zyte（如果你在這個領域待得夠久，應該還記得它以前叫 Scrapinghub）提供的 API，可以依請求回傳原始 HTTP 回應、瀏覽器渲染後的 HTML、截圖，或自動擷取後的結構化物件。價格會依 target/request tier 而定，不是固定費率；而且和這裡其他幾款工具一樣，失敗回應與被 rate limit 的請求通常不會計費。
主要特色：
- 多種輸出模式：HTTP、瀏覽器、截圖或自動擷取
- 與 Python 開發者常用的 Scrapy 原生整合
- 可預先設定支出上限與封鎖門檻
- 依 target/request tier 計價，會隨網站難度調整
價格：可按用量付費；實際費率依目標 tier 而定。
適合對象：需要代管 HTTP／瀏覽器／擷取 API 的團隊，尤其是本來就使用 Scrapy 的使用者。目標適配性與 tier 穩定性必須靠試驗確認。
10. Apify
Apify 與其說是 proxy API，不如說是完整爬蟲平台——運算資源、預先建立好的「Actors」（也就是它對封裝爬蟲的稱呼）、排程、資料集儲存與 proxy 服務全都包在一起，而且每一項都有獨立計費。對於想要直接使用常見網站現成爬蟲的團隊來說，這很有優勢；但如果你只是想要 proxy，卻被端上一整個平台，事情就變得複雜了。
主要特色：
- 針對常見爬取目標提供預建 Actors 市集
- 可作為其中一項組件的 residential、datacenter 與 SERP proxy 服務
- 排程、資料集儲存與 webhook 支援流程自動化
- 提供詳細的診斷 proxy 狀態碼，方便除錯失敗請求
計費單位：預付式平台使用費可能分成運算、Actor、proxy、資料集與儲存等多項費用。請從整體工作負載來建模，不要只報 proxy 那一欄。
適合對象：比起原始 proxy 控制，更重視現成爬蟲與流程自動化的團隊。
看不見的成本問題：請用「每個有效結果成本」來算
標價只是一個分子。真正有用的分母不是請求數、傳輸位元組數或 HTTP 200 回應數，而是通過你自己語意驗證器的輸出數量。
試驗前先定義好量測方式：
每 1,000 個有效結果成本 = 總試驗成本 / 有效結果數量 * 1,000
總試驗成本應該包含實際會因供應商不同而改變的項目：請求或網路單位、渲染與 premium routing 倍數、重試、解析、運算、儲存、監控，以及操作人力。有效結果則只計算那些具備必要欄位、地區正確、新鮮度可接受，而且不是拿 challenge 或同意頁假裝成內容的回應。
舉個刻意假設的例子：供應商 A 的測試批次成本是 3.00 美元，產出 600 筆有效資料；供應商 B 成本 3.50 美元，產出 950 筆。換算後，它們的正規化成本分別是每 1,000 筆有效資料 5.00 美元與約 3.68 美元。這些數字只是示意，並不是對任何供應商、目標類型或防護系統的實際聲明。
如果是像 Thunderbit 這樣的擷取 API，就要把拿到 schema 化資料、而不是原始 HTML 的價值與成本一起納入。若是原始 proxy，就要把下游 parser 與維護工作一起算進去。這兩條邊界沒有哪一個永遠比較便宜；答案取決於工作負載真正需要的輸出。
如果你想更深入了解 AI 擷取和選擇器式爬取的差異，我們的 AI 網頁爬蟲 文章有完整拆解其底層方法。
Proxy API vs. AI 爬取 API：你真的需要 proxy 嗎？
所有這類排名文章都預設讀者一定需要 proxy，卻沒有人質疑這個前提——這其實很奇怪，因為現在越來越多人問的更基本問題是：我真的需要原始 HTML 嗎，還是我只是需要資料？
| 面向 | 傳統 Proxy API | AI 爬取 API（例如 Thunderbit） |
|---|---|---|
| 你拿到什麼 | 需要自己解析的原始 HTML | 符合你 schema 的結構化 JSON |
| 代管存取行為 | 由你的 proxy/client 堆疊或獨立的代管產品控制 | 作為擷取服務的一部分，受其文件化限制約束 |
| 解析/擷取 | 你自行建立與維護 parser | AI 依照 schema 擷取欄位 |
| 頁面版型變動時的維護 | 你負責 selector 與 parser 變更 | 服務端承擔更多擷取邏輯，但你團隊仍需驗證輸出 |
| 適合用途 | 大量 HTML 歸檔、自訂管線、特殊協定 | 結構化資料、RAG ingestion、潛在客戶名單 |
| 整合邊界 | Proxy 端點或供應商 API | Distill、Extract、Batch 等 HTTP 擷取端點 |
誠實的結論是：如果你的管線真的需要原始 HTML、proxy 層級 session 控制或自訂請求堆疊，那傳統 proxy API 可能就是正確的邊界。如果你要的是結構化商品資料、潛在客戶紀錄，或可直接匯入試算表／檢索管線的搜尋結果，那擷取 API 可以把路由、渲染與擷取統一包進一個服務邊界。這樣能重新定義選擇，但不能證明哪一種模式普遍更好。
如果你的團隊主要是想找名單或結構化紀錄，而不是原始網頁，則 AI 潛在客戶開發 與 AI for sales 這兩篇指南，會展示哪些工作流程天然就以結構化資料列作為輸出。
合規與來源問題，也必須列入評估
技術可達性與授權是兩件事。試驗前，請先明確記錄組織被允許蒐集哪些 URL、需要哪些資料欄位、保存規則、隱私義務、適用的目標條款，以及誰負責升級處理。買了 proxy 訂閱，並不會自動擴大這些權限。
對於 residential 網路，請向供應商索取最新的來源與同意文件、目標可用性規則、身分驗證或 KYC 要求、稽核證據，以及當某個 IP 區段或目標不可用時的應對流程。供應商的官方聲明可以作為有用證據，但不能取代獨立的供應鏈稽核。
在試驗過程中，如有需要可記錄地區與 ASN 觀察結果，但不要因為一次查詢就推論整個網路的來源。若出現差異，應視為需要向供應商與採購團隊確認的問題。如果授權條件改變、政策檢查失敗、重試上限達到，或預算上限觸發，就應立即停止執行。
對於擷取與平台型服務，來源與存取責任並沒有消失，而是移到了另一個服務邊界之後。採購方仍應審查合約、可支援用途政策、失敗行為與資料處理方式。本指南提供的是技術評估建議，不是法律意見。
一眼看懂的比較
| 工具 | 產品邊界 | 常見輸出 | 需確認的計費單位 | 有用的試驗問題 |
|---|---|---|---|---|
| Thunderbit | 擷取 API | Markdown 或 schema 化 JSON | 每頁單位 | 必要欄位在不同目標模板下是否仍然有效？ |
| Bright Data | 原始 proxy 家族加上代管 Unlocker | 連線、原始內容或代管輸出 | 流量或成功請求，視產品而定 | 這個工作負載到底需要哪一種產品與地理控制？ |
| Oxylabs | Proxy 家族加上 Web Unblocker 與 scraper API | 連線或代管內容 | 依產品而定；本次取得的 Unlocker 頁面為 GB 制 | 回應大小與 session 持續性會如何影響成本？ |
| ScrapingBee | 代管 HTML API | HTML | 依功能變動的信用點數 | 哪種設定能成功，且每個有效頁面的成本是多少？ |
| ZenRows | Scraper API、瀏覽器與 residential proxies | 多種供應商文件化格式 | 含功能倍數的請求點數 | 404/410 的計費語意如何與你的驗證器互動？ |
| Scrape.do | 代管 Web Scraping API | 頁面內容 | 成功 API 點數 | premium、地理、session 與瀏覽器控制是否符合工作負載？ |
| Decodo | Proxy 與爬取產品家族 | 連線或產品特定輸出 | 本次取得的 residential 頁面為 GB 或 PAYG | 位置、ASN、協定與 sticky-session 控制是否夠準確？ |
| Scrapfly | 代管爬取 API | 頁面內容、瀏覽器輸出、可選擷取 | 依功能變動的信用點數 | 成本預算、log 與失敗保護的表現是否如預期？ |
| Zyte | 代管 HTTP、瀏覽器、擷取與 Scrapy 介面 | HTTP、渲染 HTML、截圖或物件 | 目標/request tier 加上選項 | tier 是否穩定，而請求模式限制是否符合實作？ |
| Apify | 爬蟲平台、市集與 proxy | Actor 或 crawler 資料集 | 運算、Actor、proxy、儲存與資料集費用 | 這個工作流程帶來的效益是否足以合理化整體平台成本？ |
上表中的類別與計費單位，都是根據 2026 年 8 月 10 日取得的官方頁面整理而成。方案、限制、名稱與功能倍數都可能變動，所以在預算前一定要重新確認你選定的產品。
決策流程圖：你到底在爬什麼？
在 proxy 相關論壇裡最常見的問題，大概就是某種版本的「我不知道哪個最好，有人推薦嗎？」——接著通常會看到一份泛泛而談的清單，但其實沒有真正回答問題。下面試著把它變成更接近實際決策路徑的流程。
你需要什麼輸出？
- 需要 proxy 協定控制、原始回應、自訂 header，或自己的 parser？先把原始 proxy 產品列入名單。
- 需要渲染後 HTML，但不想自己操作瀏覽器與重試層？先看代管爬取或瀏覽器 API。
- 需要經驗證的欄位、資料列或 Markdown？先看擷取 API，包括 Thunderbit 文件中的 Distill 與 Extract 端點。
- 需要排程、儲存、市集任務與團隊作業？先看爬蟲平台。
哪些控制是不能妥協的？ 把必需的地區、session 時長、輪換行為、請求方法、cookie、header、渲染、截圖、資料形狀、併發、log 與支出停止條件全部寫下來。先把無法滿足硬性需求的候選者排除，再測試軟性偏好。
我們談的是什麼量級？ 不要用一個泛泛的頁數門檻來選供應商。流量大小會跟回應尺寸、併發、功能倍數、有效結果率、談判條件與工程投入互相影響。請建模預期的目標模板組合，並在具代表性的併發下跑試驗。
要原始 HTML 還是結構化資料？ 這仍然是主要分歧點。如果你需要原始 HTML 來做自訂管線，就測試 proxy 或代管 HTML 產品。如果交付物是經驗證的資料列、JSON 或 Markdown，就應該把擷取邊界當成獨立類別來測，不要硬拿來和 proxy 做一對一比較。
建立你自己的加權評分表
功能清單本身無法做決策，因為效能與成本取決於目標集合與設定。請依照你自己的需求與試驗結果建立評分表。下面的權重欄位故意留白。
| 評估項目 | 你的權重 | 供應商 A 分數（1–5） | 證據 | 供應商 B 分數（1–5） | 證據 |
|---|---|---|---|---|---|
| 有效結果率 | |||||
| 每個有效結果成本 | |||||
| 輸出契合度 | |||||
| 地理 / session / 請求控制 | |||||
| 可觀測性與預算控制 | |||||
| 合規與來源證據 | |||||
| 支援與營運契合度 | |||||
| 工程與維護投入 | |||||
| 總計 | 100 |
只有在證據存在時，才給 1–5 分。請把「不適用」和 0 分清楚區分。結果旁邊也要附上權重，讓同事看得出來哪些假設影響了最後結論。
下面這段簡短的 Python 範例會在輸入缺失或無效時直接失敗關閉。30 次嘗試的最低門檻只是教學上的防呆，不是普遍適用的統計樣本數聲明：
from dataclasses import dataclass
@dataclass(frozen=True)
class PilotResult:
attempts: int
valid_results: int
request_cost: float
engineering_cost: float = 0.0
def cost_per_1000_valid(self) -> float:
if self.attempts < 30:
raise ValueError("本教學至少需要 30 次嘗試")
if not 0 < self.valid_results <= self.attempts:
raise ValueError("valid_results 必須介於 1 和 attempts 之間")
if self.request_cost < 0 or self.engineering_cost < 0:
raise ValueError("成本不能是負數")
total = self.request_cost + self.engineering_cost
return total / self.valid_results * 1000
def weighted_score(weights: dict[str, float], scores: dict[str, float]) -> float:
if set(weights) != set(scores):
raise ValueError("每個加權項目都必須有分數")
if abs(sum(weights.values()) - 100.0) > 1e-9:
raise ValueError("權重總和必須為 100")
if any(not 1 <= score <= 5 for score in scores.values()):
raise ValueError("分數必須介於 1 到 5 之間")
return sum(weights[name] * scores[name] for name in weights) / 100
請至少在不同時間、固定條件下跑兩輪試驗。每次都要記錄目標群組、地區、設定、狀態、語意驗證結果、延遲、重試次數、計費單位、位元組數、request 或 job ID，以及無效原因。較大的採購需要依照團隊風險與目標多樣性設計樣本；教學中的最低門檻無法取代真正的實驗設計。
如果你剛接觸爬蟲，想先搞懂基礎再看各家供應商比較，可以先讀我們的 什麼是網頁爬蟲 入門文，以及 免程式碼網頁爬蟲 指南。
選擇 proxy API 其實不是在問「哪家供應商最好」，而是在問「哪個產品邊界最符合我的輸出需求」，然後再透過試驗確認供應商的行銷說法是否經得起你實際目標的檢驗。十家供應商、四種產品類別，以及一個公式（每個有效結果成本）就能讓你走完大部分路。最後那一哩路，就是自己跑測試，而不是相信別人的基準。
如果你的真正目標是結構化資料，而不是一堆要解析的 HTML，你也可以把 Thunderbit 的 Chrome 擴充功能 或 API 列入候選名單，並在試驗前先確認目前試用或方案限制。Thunderbit 的 YouTube 頻道 也提供產品教學；請把它們當成示範，而不是獨立的基準證據。
延伸閱讀
常見問題
1. proxy 網路和爬取 API 的真正差別是什麼？
原始 proxy 網路只提供 IP 與路由控制——渲染、重試與解析都得自己處理。爬取 API（不論是代管式或 AI 式）則負責更多生命週期，並依產品不同回傳 HTML、JSON 或 Markdown。兩者不是可直接互換的，硬拿價格比較通常只會得到誤導性的結論。
2. 我該怎麼量測真正有意義的成功率？
不要把 HTTP 200 當成功。請把成功定義為「我實際需要的內容或欄位已存在且正確」，再用你真實目標站點的代表性樣本測試，而不是供應商的 demo site。
3. 我要怎麼計算每次成功請求的成本？
把標價（按請求或按 GB）除以你在特定目標上的實測成功率。即使某家供應商單價比較低，如果成功率也比較低，加上重試後，最終成本很可能反而更高——所以在決定方案前一定要先算數。
4. 如果我只要結構化資料，不要原始 HTML，還需要 proxy API 嗎？
不一定。像 Thunderbit 這類擷取 API 可以回傳結構化 JSON，並把渲染與路由放在服務邊界內，這樣你的工作流程可能就不需要另外購買原始 proxy。仍需測試目標支援度與欄位有效性；當你需要原始回應或 proxy 層級控制時，傳統 proxy 產品才是相關類別。
5. 在註冊前，我應該問供應商哪些 IP 來源問題？
請詢問目前 residential IP 的同意與來源文件、可支援用途政策、合規證據、可稽核性，以及當某個子網路或目標不可用時的處理流程。若風險足夠高，第一方聲明也應由採購或法務審閱；它們不能取代獨立的供應鏈稽核。
