每一份「最佳 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，或結構化資料 |
| 連線與地理控制 | 你實際需要的地區、城市、ASN、session、輪換、header、cookie 與 protocol 控制 |
| 可觀測性與限制 | Request ID、計費單位 header、日誌、重播、併發控制與預算停損 |
| 合規證據 | 來源說明、合約、目標資格、可稽核性與支援流程 |
| 工程投入 | 整合、解析器維護、監控與人工修復時間 |
不支援的欄位就留白，或標記為「不適用」。重點是針對特定工作負載做出判斷，而不是做出看似精準、其實有誤導性的分數。
1. Thunderbit
Thunderbit 在這份清單中比較特別，因為它屬於相鄰的擷取 API，而不是要你接到 HTTP client 裡的原始 proxy 網路。它的公開 API 文件描述了用於 Markdown 的 Distill、輸出結構化 JSON 的 Extract，以及可處理非同步 URL 集合的 Batch。當你要的是內容或資料，而不是單純的 proxy 連線時，這條邊界可以直接省掉好幾個下游步驟。
實務上的差異，會在你送出第一個請求時立刻看出來。傳統 proxy API 成功後通常只會拿到原始 HTML，工作才完成一半；但在 Thunderbit 的 POST /extract 端點中，你只要提供目標 URL，以及一份描述欄位的 JSON Schema，回來的就已經是符合該 schema 的結構化 JSON。不需要寫 CSS selector，也不用在網站於 Q3 改版產品頁時一直維護 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 的結構化輸出模式就不是正確工具——你其實會想用後面九個選項中的其中一個。
跳過 Proxy，直接用 AI 擷取 Thunderbit 的代理式網頁爬蟲會自行處理渲染與反機器人阻擋，因此許多工作根本不需要另外的 proxy API。 Get Started Free
2. Bright Data
Bright Data 幾乎就是這個產業裡的老大哥，提供 residential、datacenter、ISP 和 mobile proxy 網路，另外還有一個獨立的代管產品 Web Unlocker。這個「獨立」很重要——Bright Data 不是單一產品，而是一整個產品家族，價格與行為會依你買的是哪一項而差很多。
住宅網路文件列出了國家、地區、城市、ZIP 與 ASN 目標控制。Web Unlocker 則是另一個代管層，採成功才計費並設有每月支出上限。這些控制很實用，但其準確度與適配性仍需要買方在試跑中驗證；本指南沒有做跨供應商的地理位置基準測試。
主要特色：
- 提供 residential、datacenter、ISP 與 mobile proxy 類型，並支援細粒度地理定位
- Web Unlocker 代管 API，採成功才計費並可設定支出上限
- 住宅 IP 有公開的自願來源說明文件
- 提供除錯欄位（request ID、計費狀態、peer country）方便排查問題
計費單位：原始 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 提供 JavaScript 渲染與代管解鎖，現行定價依 GB 計費
- 透過 header 型 session ID 維持 session 持續性
- 範例回應會帶有 job/session header，方便除錯
計費單位：本次研究取得的 Web Unblocker 頁面使用的是 GB 型方案，且有方案專屬速率限制；Oxylabs 其他產品則使用不同單位。請再次確認所選產品的最新頁面。
適合對象：需要大規模、地理多樣性高的操作，而且不介意跨產品管理 GB 計費的團隊。
4. ScrapingBee
ScrapingBee 是一個代管 HTML API：你送出 URL，它回傳頁面內容，而下游驗證與解析通常仍由你負責。文件中提供了依功能而變動的 credit 制度、Auto-Mode、成本 header，以及可限制單次 Auto-Mode 請求支出的 max_cost 參數。
主要特色：
- Auto-Mode 會自動提高設定（proxy 層級、渲染）直到成功為止
max_cost參數可限制單次請求支出- 所有 Auto-Mode 組合都失敗時，不會扣任何 credits
- 每個回應都有 usage/cost header，方便即時追蹤
計費單位：credits 會依渲染、proxy 層級與其他啟用功能而變動。不要把基礎方案當成單次請求價格，而是要查看最新的 credit 階梯與併發限制。
適合對象：規模中小、重視快速上手勝過深度自訂的專案——只要理解 credit 階梯，成本其實相當可預測。
5. ZenRows
ZenRows 把 Universal Scraper API、Scraping Browser 與 residential proxy 整合在同一個方案下，並且針對 JavaScript 渲染和高階 proxy 使用設定請求倍率。有一個值得明確指出的特殊規則：ZenRows 會把 HTTP 404 與 410 視為「成功」並計費，這正好提醒我們，供應商帳單上的「成功」和你驗證器中的「成功」不是同一件事。
主要特色：
- 組合式工具：scraper API、瀏覽器自動化與 residential proxy
- 宣稱支援多種輸出格式（JSON、Markdown、截圖、純文字）
- 代管渲染與存取元件，實際行為仍需在授權目標上驗證
- 基於 URL 的用量限制，超量後會暫停請求直到加購容量
計費單位：請求 credits，並針對 JavaScript 渲染與高階 proxy 等功能有文件化倍率。請確認最新方案與倍率規則。
適合對象：希望從同一供應商評估 scraper API、瀏覽器與 proxy 產品，且會在授權目標上逐一測試所選產品的團隊。
目前為止出現了哪些模式
做到第五個工具時，一個規律已經很明顯：幾乎沒有任何產品邊界會和行銷文案完全一致。Bright Data 與 Oxylabs 都把「原始 proxy」和「代管解鎖」分成不同產品與不同定價模式，因此供應商首頁本身無法直接回答「這要多少錢」——你得先選定具體產品。ScrapingBee 與 ZenRows 都採用 credit 制計費並逐步加乘，這比 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，以及 browser/proxy 模式切換。
主要特色：
- Credit 型計費，月額上限達到後請求即停止，不會預設產生意外超額費用
- 可對符合條件的目標使用高階網路切換
- Session 與地理控制應針對實際工作負載測試
- 支援瀏覽器渲染模式，適合 JavaScript 很重的頁面
計費單位：打包式成功 API credits，並有每月上限；請確認目前方案限制、併發與額外容量規則。
適合對象：想用代管 API、又不想承擔 GB 計費的預算導向團隊。
7. Smartproxy / Decodo
Smartproxy 已改名為 Decodo，而它目前的住宅 proxy 定價頁列出了每 GB 與即付即用方案，並支援 ASN 級目標控制，以及透過 HTTP(S)/SOCKS5 的 rotating 與 sticky session。本次取得的頁面引用了 Proxyway 的研究來支撐所展示的效能數據。這些來源脈絡很有參考價值，但不能證明在其他目標、地區、時間窗口或帳號設定下會得到相同結果。
主要特色：
- Residential、datacenter、ISP 與 mobile proxy 類型
- ASN 與地點層級目標控制
- 支援 HTTP(S) 與 SOCKS5 的 rotating 與 sticky session
- 效能宣稱來自第三方研究，而非供應商自行聲稱
計費單位：本次研究取得的住宅頁面列出每 GB 與 PAYG 選項。請在所選產品頁面確認最新費率與包含的控制項。
適合對象：想要 proxy 多樣性、但又不想付企業級價格的電商監控與中型規模作業。
8. Scrapfly
Scrapfly 是代管爬取 API，並提供可選的 Anti Scraping Protection（ASP）功能。它自己的文件明確指出，目標防護會持續演進，遭封鎖後恢復時間無法保證，而資源相關成本也可能變動。這個提醒很重要：代管存取，不等於永久可用的保證。
主要特色：
- ASP 會根據目標難度動態提高成本
cost_budget參數與失敗爬取公平性保護（被排除的狀態碼不會計入）- 回應層級的成本 header 與 request replay／debug 儀表板
- 可選瀏覽器渲染與住宅 proxy 池
計費單位：credits，成本會隨 proxy 池、渲染與 ASP 設定而改變。回應 header、cost_budget 與專案限制可幫助衡量並控制這筆成本。
適合對象：特別重視 anti-detection 工具，且希望清楚看到每次請求在 credit 上究竟花了多少的團隊。
9. Zyte
Zyte（對這個領域夠久的人來說，或許還記得它以前叫 Scrapinghub）提供的 API，可以依請求回傳原始 HTTP 回應、瀏覽器渲染後 HTML、截圖，或自動擷取的結構化物件。價格是依目標／請求層級而不是固定費率，和這裡其他幾個工具一樣，失敗回應與被限速的請求通常不會計費。
主要特色：
- 多種輸出模式：HTTP、瀏覽器、截圖或自動擷取
- 與 Scrapy 原生整合，適合已在該生態系中的 Python 開發者
- 可事先設定支出上限與封鎖閾值
- 依 target/request tier 定價，會依網站難度調整
定價：可採 pay-as-you-go；實際費率取決於目標層級。
適合對象：需要代管的 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
試跑總成本 應包含實際在各候選方案之間會不同的成本：請求或網路單位、渲染與高階路由倍率、重試、解析、運算、儲存、監控與操作人力。有效結果 則只計算那些具備必要欄位、正確地區、可接受的新鮮度，且不是假裝成內容的驗證頁或同意頁的回應。
舉一個刻意假設性的例子。Provider A 的測試批次成本是 3.00 美元，產生 600 筆有效紀錄；Provider B 的成本是 3.50 美元，產生 950 筆。那麼它們的標準化成本分別是每 1,000 筆有效紀錄 5.00 美元與約 3.68 美元。這些數字只是為了示範算式，並不是對任何供應商、目標類型或防護系統的宣稱。
對像 Thunderbit 這類擷取 API 來說，成本計算應把拿到 schema 型資料，而非原始 HTML 的價值與費用一起納入。對原始 proxy 來說，則要把下游 parser 與維護成本算進去。這兩種邊界沒有哪一種永遠比較便宜；答案取決於這個工作負載真正需要什麼輸出。
如果你想更深入了解 AI 型擷取和 selector 型爬取的差異，可以參考我們的 AI web scraping 解析，裡面會說明底層做法。
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 輸入、名單整理 |
| 整合邊界 | proxy 端點或供應商 API | Distill、Extract 與 Batch 這類 HTTP 擷取端點 |
誠實的結論是：如果你的流程真的需要原始 HTML、proxy 級 session 控制，或自訂請求堆疊，傳統 proxy API 可能才是正確邊界。如果你要的是結構化商品資料、潛在客戶紀錄，或可直接放進試算表／檢索流程的搜尋結果，那擷取 API 可以把路由、渲染與擷取都收斂到同一個服務邊界裡。這樣的重構，不代表哪個模型絕對更好，只是讓決策更精準。
如果你的目標是名單開發或結構化紀錄，而不是原始頁面，可以參考 AI lead generation 和 AI for sales 這兩篇指南，看看哪些工作流程天然就會輸出結構化資料列。
先確認你到底需不需要 Proxy 免費方案每月含 6 頁——在買 proxy 容量前，先測試 Thunderbit 內建渲染是否足以處理你的目標網站。 Get Started Free
合規與來源問題也應納入評估
技術存取權和授權是兩回事。在試跑前，請先整理組織被允許蒐集的 URL、必需資料欄位、保留規則、隱私義務、適用的目標條款，以及出問題時的升級負責人。購買 proxy 訂閱，並不會自動擴大這些權限。
對於住宅網路，請向供應商索取目前的來源與同意文件、目標資格規則、身分或 KYC 要求、稽核證據，以及當 IP 範圍或目標不可用時的處理流程。官方供應商聲明固然是有用的證據，但它並不是獨立的供應鏈稽核。
在試跑過程中，如果情況有關，請記錄地區與 ASN 的觀察結果，但不要把單次查詢誤認成整個網路來源的證明。若出現來源差異，應把它視為需要向供應商與採購團隊確認的問題。如果授權變更、政策檢查失敗、重試上限達到，或預算上限觸發，就應立即停止執行。
對擷取與平台服務來說，來源與存取責任並沒有消失，只是轉移到不同的服務邊界之後。買方仍應審查合約、允許用途政策、失敗行為與資料處理方式。本指南提供的是技術評估建議，不是法律意見。
一目了然的比較
| 工具 | 產品邊界 | 常見輸出 | 需確認的計費單位 | 試跑時最值得問的問題 |
|---|---|---|---|---|
| Thunderbit | 擷取 API | Markdown 或 schema 型 JSON | 每頁單位 | 所需欄位在不同目標模板下是否仍然有效？ |
| Bright Data | 原始 proxy 家族 + 代管 Unlocker | 連線、原始內容或代管輸出 | 流量或成功請求，視產品而定 | 這個工作負載究竟需要哪個產品與哪些地理控制？ |
| Oxylabs | Proxy 家族 + Web Unblocker 與 scraper APIs | 連線或代管內容 | 依產品而定；本次取得的 Unlocker 頁面為 GB 計費 | 回應大小與 session 持續性會如何影響成本？ |
| ScrapingBee | 代管 HTML API | HTML | 依功能而變動的 credits | 哪種設定最容易成功，而每個有效頁面的成本是多少？ |
| ZenRows | Scraper API、瀏覽器與住宅 proxy | 多種供應商文件化格式 | 帶功能倍率的請求 | 404/410 的計費語意會如何影響你的驗證器？ |
| Scrape.do | 代管 Web Scraping API | 頁面內容 | 成功 API credits | 高階、地理、session 與瀏覽器控制是否符合工作負載？ |
| Decodo | Proxy 與爬取產品家族 | 連線或產品專屬輸出 | 本次取得的住宅頁面為 GB 或 PAYG | 地點、ASN、協定與 sticky-session 控制是否夠準？ |
| Scrapfly | 代管爬取 API | 頁面內容、瀏覽器輸出、可選擷取 | 依功能而變動的 credits | 成本預算、日誌與失敗保護的表現是否符合預期？ |
| Zyte | 代管 HTTP、瀏覽器、擷取與 Scrapy 介面 | HTTP、渲染後 HTML、截圖或物件 | target/request tier 加上選項 | 該 tier 是否穩定，請求模式限制是否符合實作？ |
| Apify | 爬取平台、市集與 proxy | Actor 或 crawler 資料集 | 運算、Actor、proxy、儲存與資料集費用 | 這個工作流程是否真的值得整個平台成本？ |
以上分類與計費單位，反映的是 2026 年 8 月 10 日取得的官方頁面。方案、限制、名稱與功能倍率都可能變動，所以在預算前請再次確認精確產品。
決策流程圖：你到底在爬什麼？
在 proxy 相關論壇貼文中，最常見的問題大概就是某種變形版的「我不知道哪個最好，有人可以推薦嗎？」——接著貼出來的是一份沒有真正回答問題的通用清單。下面試著把它整理成更接近實際的決策路徑。
你需要什麼輸出？
- 需要 proxy 協定控制、原始回應、自訂 header，或自己維護 parser？先把原始 proxy 產品列入候選。
- 需要渲染後 HTML，但不想自己操作 browser 與 retry 層？先看代管爬取或瀏覽器 API。
- 需要已驗證欄位、紀錄或 Markdown？先看擷取 API，包括 Thunderbit 文件中的 Distill 與 Extract 端點。
- 需要排程、儲存、市集任務與團隊操作？先看爬取平台。
哪些控制是不可妥協的？ 把必需的地區、session 時長、輪換行為、請求方法、cookie、header、渲染、截圖、資料形狀、併發、日誌與支出停損逐一寫下來。在測試軟性偏好前，先排除無法滿足硬性要求的候選。
我們談的是什麼量級？ 不要用一個通用的頁面數門檻來挑供應商。量級會和回應大小、併發、功能倍率、有效結果率、談判承諾以及工程投入互相作用。請建立預期的目標模板組合，並以具代表性的併發量做試跑。
要原始 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("pilot needs at least 30 attempts for this tutorial")
if not 0 < self.valid_results <= self.attempts:
raise ValueError("valid_results must be between 1 and attempts")
if self.request_cost < 0 or self.engineering_cost < 0:
raise ValueError("costs cannot be negative")
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("every weighted criterion needs a score")
if abs(sum(weights.values()) - 100.0) > 1e-9:
raise ValueError("weights must sum to 100")
if any(not 1 <= score <= 5 for score in scores.values()):
raise ValueError("scores must be in the 1–5 range")
return sum(weights[name] * scores[name] for name in weights) / 100
請至少在不同時間、固定條件下跑兩輪。每次嘗試都要記錄目標群組、地區、設定、狀態、語意驗證結果、延遲、重試次數、計費單位、位元組數、request 或 job ID，以及無效原因。更大規模的採購，需要能反映團隊風險與目標多樣性的樣本；教學中的最低門檻，不能取代這種設計。
如果你剛接觸爬蟲，想先打好基礎再看供應商比較，可以先讀我們的 什麼是網頁爬蟲 與 免寫程式的網頁爬蟲 這兩篇入門文。
選擇 proxy API，其實不是在問「哪家供應商最好」，而是在問「哪個產品邊界最符合我的輸出需求」，接著再用試跑確認供應商的行銷說法能不能在你的真實目標上站得住腳。十家供應商、四種產品類別，加上一個公式（每個有效結果成本），就已經能幫你解決大部分問題。最後那一小段路，只是自己跑測試，而不是相信別人的 benchmark。
如果你的真正目標是結構化資料，而不是一大堆要解析的 HTML，可以把 Thunderbit 的 Chrome 擴充功能 或 API 納入候選名單，並在試跑前確認目前的試用或方案限制。Thunderbit YouTube 頻道 也有產品操作示範；請把它們當成展示，而不是獨立的 benchmark 證據。
試試 Thunderbit 的代理式網頁爬蟲 Get Started Free
延伸閱讀
常見問題
1. Proxy 網路和爬取 API 的真正差別是什麼？
原始 proxy 網路只提供 IP 與路由控制——渲染、重試與解析都要你自己處理。爬取 API（不論代管或 AI 型）則會接管更多生命週期，並依產品回傳 HTML、JSON 或 Markdown。兩者不能互換，直接比較價格通常也會得到誤導性的結論。
2. 我要怎麼用真正有意義的方式衡量「成功率」？
不要把 HTTP 200 當成功。成功應定義為「我真正需要的內容或欄位有出現且正確」，然後拿你的真實目標站點代表性樣本來測，不要只測供應商的 demo 網站。
3. 我要怎麼計算每次成功請求的成本？
把標示價格（按請求或按 GB）除以你在特定目標上的實測成功率。就算某供應商看起來比較便宜，如果成功率較低，把重試算進去後，最後可能反而更貴——在承諾方案前先算清楚。
4. 如果我只想要結構化資料，不要原始 HTML，還需要 proxy API 嗎？
不一定。像 Thunderbit 這類擷取 API 可以直接回傳結構化 JSON，並把渲染與路由收在服務邊界內，對某些工作流程來說，可能就不需要另外買原始 proxy。不過仍然要測試目標支援度與欄位有效性。若你需要原始回應或 proxy 級控制，傳統 proxy 產品才是相關類別。
5. 在註冊前，關於 IP 來源我應該問供應商什麼？
請索取目前住宅 IP 的同意與來源文件、允許用途政策、合規證據、可稽核性，以及當子網路或目標不可用時的處理流程。若風險夠高，第一方聲明應交由採購或法務審查；它們並不是獨立的供應鏈稽核。
