網頁爬蟲如何避免被封鎖？2026 防封鎖實戰指南與合規做法

要在不被封鎖的情況下爬取網站，我的答案依序是：遵守 robots.txt 與網站服務條款、把請求速率控制在真人瀏覽也說得通的範圍並搭配指數退避、送出完整且擬真的瀏覽器標頭、在同一個 Session 內維持 Cookie 一致，並在合法的大流量需求下，才把流量分散到輪替式住宅 IP，同時持續監控狀態碼，及早捕捉封鎖徵兆。

被封鎖不是運氣不好，而是網站的反爬蟲機制正確辨識出「看起來不像真人瀏覽」的流量——或是網站早已明白要求離開的流量。本文整理讓合法爬蟲專案（價格監控、SEO 排名追蹤、廣告驗證、AI 訓練資料、市場調查——例如追蹤 PChome、momo購物網或蝦皮購物上的商品價格）穩定運作的工程實務，同時明確劃出我們不會協助任何人跨越的界線。想完整了解網頁爬蟲從頭到尾怎麼運作，請先從我們的網頁爬蟲完整指南開始。

先搞懂規則：robots.txt 與服務條款

在優化任何技術細節之前，先確認你到底該不該爬這個目標。

1. 抓取並解析 robots.txt。 網站根目錄下的這個檔案宣告了哪些路徑不歡迎爬蟲，通常也包含 Crawl-delay 指令。遵守它是專案善意運作最清楚的訊號，多數成熟的爬蟲框架都能自動強制執行。
2. 詳讀服務條款。 有些網站全面禁止自動化存取，有些則限制特定用途。條款是否具法律拘束力因司法管轄區與個案而異——我們在網頁爬蟲合法嗎一文整理了主要判例——但了解網站怎麼規定是基本義務，不是可有可無的加分項。
3. 優先使用官方管道。 如果網站提供 API、資料饋送或授權方案且涵蓋你的使用情境，就直接用。這比爬蟲穩定得多，也徹底消除封鎖問題。
4. 限縮蒐集範圍。 只取需要的欄位、只爬公開頁面，並排除任何可識別個人的資料。在 GDPR 與類似法規之下，個人資料伴隨的法律義務是多數爬蟲專案無力承擔的。

我們的合規立場，直接說清楚： ProxyFacts 不提供任何繞過付費牆或登入牆、透過解題農場大規模破解驗證碼、爬取個人資料，或自動化搶購（球鞋機器人、黃牛搶票、批量開設帳號）的教學。本文談的防封鎖工程，目的是讓合法存取穩定可靠——不是幫你取得你從未被允許的存取權限。

了解網站為什麼封鎖爬蟲

反爬蟲系統尋找的是真人不會產生的模式。認識這些偵測層，你就知道該修什麼：

由此可以得出兩個結論。第一，光靠 IP 輪替只能解決一層——IP 會換但仍掛著 Python 預設 User-Agent 的爬蟲，照樣在第二層被逮。第二，各層會互相加乘：標頭一致但 Session 前後矛盾，比單獨一項缺陷更可疑。有效的防封鎖工程，是讓每一層都講出同一個真實的故事：一個合理的客戶端，發出合理數量的請求。

請求頻率與退避策略：投報率最高的修正

最快被封鎖的方法，就是用連線允許的最高速度狂發請求。如果只能修一件事，我會先修這裡——因為修正的成本幾乎是零：

• 設定保守的基準速率。 對多數網站來說，每個網域每隔幾秒發一個請求是合理起點。如果 robots.txt 宣告了 Crawl-delay，把它當成下限，而不是參考建議。
• 加入隨機抖動（jitter）。 隨機化請求之間的延遲（例如基準延遲乘上 0.5 到 1.5 之間的隨機係數）。完美規律的間隔就是機器的簽名。
• 實作指數退避。 收到 HTTP 429 或 503 時先等待，再以倍增的延遲重試：1 秒、2 秒、4 秒、8 秒，依此類推，並設定合理上限。若回應帶有 Retry-After 標頭，就分秒不差地照辦。
• 以網域為單位配置並行數，而不是全域。 二十個並行工作分散在二十個網站沒問題；二十個工作同時打一個網站，就是看起來像攻擊的爆量。
• 避開流量高峰時段。 在 momo購物網或蝦皮購物這類電商平台的尖峰時段爬取，等於和真實顧客搶伺服器資源。離峰爬取既有禮貌，也較不會觸發以負載為基準的防禦。

遵守這些規則的爬蟲，中小型任務通常不需要任何額外的防封鎖工作。以下內容主要在流量規模成長後才變得重要。

送出擬真且一致的 HTTP 標頭

HTTP 客戶端的預設標頭會把你的身分昭告天下。先修掉這些明顯的破綻：

1. 設定真實的瀏覽器 User-Agent——使用當前版本的 Chrome 或 Firefox 字串，不要用函式庫預設值，也不要用過時好幾年的瀏覽器版本。
2. 送出該瀏覽器會送的完整標頭組合： Accept、Accept-Language、Accept-Encoding，以及現代 Chrome 會附帶的 Sec-CH-UA 客戶端提示標頭。掛著 Chrome User-Agent 卻沒有客戶端提示，是指紋辨識系統一抓一個準的矛盾。
3. 維持標頭內部一致。 Accept-Language 應與 IP 宣稱的地理位置相符。一組德國住宅 IP 卻只搭配單獨的 en-US 語言標頭，就是不一致。
4. 合理設定 Referer。 網站深處的頁面通常是從某個地方連過來的，不會憑空冒出。
5. 謹慎且正確地輪替 User-Agent。 若要輪替，就把整組一致的標頭捆綁一起換——絕不要把一個瀏覽器的 User-Agent 混搭另一個瀏覽器的客戶端提示。

如果目標網站以 JavaScript 渲染內容並挑戰非瀏覽器客戶端，光靠標頭是不夠的；你會需要真正的無頭瀏覽器，而我的判斷是：自建無頭瀏覽器架構的長期維護成本幾乎總是被低估，到了那一步，託管式爬蟲 API 往往更划算——這個取捨的臨界點，請見我們的爬蟲 API 與純代理比較。

有意識地管理 Session 與 Cookie

網站用 Cookie 追蹤訪客的連續性。爬蟲被標記，往往就是因為連續性斷裂：

• 在邏輯 Session 內接受並保存 Cookie。 收到 Session Cookie 卻從不回傳的客戶端，看起來不是壞掉就是不懷好意。
• 讓 IP 與 Cookie Jar 綁定成對。 同一個 Session Cookie 十分鐘內從三個國家出現，是不可能的旅行者。若要輪替 IP，Cookie Jar 也要跟著一起輪替。
• 依任務挑選 Session 類型。 無狀態任務——抓取數千個彼此獨立的商品頁面——適合逐請求輪替 IP、不留 Cookie。有狀態流程——逐頁翻閱搜尋結果、走完多頁清單——則需要黏性 Session，讓 IP 與 Cookie 在整段流程中固定不變。
• 像真人一樣讓 Session 過期。 沒有人會連續瀏覽同一個網站 72 小時。讓 Session 身分在合理的存活時間後退役，換新的重來。

主要住宅代理供應商提供 Session 控制，正是為了這件事。根據各家產品頁面（2026 年 7 月擷取）：Oxylabs 提供輪替與最長 24 小時的黏性 Session；Decodo（前身為 Smartproxy）提供逐請求輪替，黏性 Session 從數分鐘到數天；IPRoyal 支援最長 7 天的黏性區間；Bright Data 則同時提供黏性與輪替模式。你需要多長的時間窗，完全取決於你最長的有狀態流程要跑多久。

用輪替式住宅 IP 支撐合法的大量需求

當專案真的需要規模——比方說每天監控 100,000 個商品頁面，或從 20 個國家查核搜尋排名——單一 IP 不可能在不超出合理單 IP 速率的前提下扛住負載。把請求分散到住宅 IP 池，可以讓每個 IP 的請求速率維持在真人合理範圍，整體任務又能如期完成。住宅 IP 也帶有一般消費者的正常信譽，不像資料中心網段常被網站整批封鎖——基本原理請見我們的什麼是住宅代理解說。

我們追蹤的四家供應商公布了以下相關能力（所有數據皆取自各家產品與政策頁面，2026 年 7 月擷取；IP 池規模為供應商宣稱，未經獨立驗證）：

請注意最後一列。每一家正派供應商都會審查客戶，因為他們的生意仰賴把濫用行為擋在網路之外。Bright Data 將住宅網路的使用權限制在通過人工審核 KYC 的驗證企業，見其 KYC FAQ。Oxylabs 要求每位客戶在註冊時填寫 KYC 表單並依風險升級審查，見其 KYC 與安全政策。Decodo 在每次註冊時執行自動化詐欺檢查與 KYC，並主動封鎖銀行、票務等高風險目標，見其安全與合規頁面。IPRoyal 透過第三方服務 iDenfy 執行 KYC，見其 KYC 政策。如果你的使用情境過不了供應商的合規審查，有問題的是使用情境，不是供應商。

工程師觀點（友田）： 看這張表時，我第一個看的數字不是 IP 池規模，而是黏性 Session 的時間窗——它直接決定你最長的有狀態流程能不能在不換供應商的前提下跑完；在宣稱池規模中位數已達 54M 的市場裡，池子大小早就不是瓶頸。成本也別只比每 GB 單價：假設要每天監控 100,000 個商品頁、每頁以 100 KB 估算，一個月大約是 300 GB，單價差 2 美元就是每月 600 美元的差距，這筆帳應該在申請試用之前就先算好。反過來說，如果你的用量一個月連幾 GB 都用不到，我會直言：問題多半出在頻率控制與標頭，不在代理——先把零成本就能修的部分修完，再考慮花錢。

針對合法大量需求的實務輪替建議：

• 依速率決定池子大小，不是比排場。 真正重要的是「每個 IP 每小時的請求數」在你的特定目標上是否維持真人合理範圍，而不是廣告上的池子數字。Proxyway 的 Proxy Market Research 2026（資料蒐集於 2026 年 3 至 4 月）指出，住宅代理宣稱池規模的中位數為 54M 組 IP——每一家主要供應商的位址數量，都遠超過任何合法任務的實際需要。
• 有目的地使用地理定位。 如果你監控的是德國市場的價格，就申請德國 IP 並送出與德國一致的標頭。地理定位是為了看到當地真實使用者看到的內容，不是為了規避地區層級的封鎖。
• 讓輪替與 Session 策略保持對齊，做法如上一節所述。

至於封鎖以外的選商標準——計價結構、試用方案、客服支援——請見我們的住宅代理推薦總整理。

為什麼免費代理只會讓封鎖更嚴重

這條看似誘人的捷徑，在證據面前站不住腳。一項發表於 NDSS MADWeb 2024、追蹤 11 家供應商超過 640,600 個免費代理長達 30 個月的縱貫性學術研究發現：僅 34.5% 曾經真正可用；在代理 IP 上識別出 4,452 個不重複的弱點——其中 1,755 個允許遠端程式碼執行——並抓到 16,923 個在傳輸過程中竄改內容的代理。

單就防封鎖而言，免費代理更是反效果：這些 IP 由所有其他使用免費方案的爬蟲共用，鎖定的往往還是同樣的目標，因此抵達主要網站時，早已被列入封鎖名單、形同報廢。你不但承擔自己的風險，還繼承了別人的壞名聲。完整論證請見我們的免費與付費代理比較。

持續監控封鎖徵兆

封鎖很少一次到位，而是逐步升級。如果由我來設計一條價格監控管線，監控儀表會和爬蟲本體同一天上線——沒有儀表，你連自己正在被封鎖都察覺不到：

1. 各網域的狀態碼組成。 403、429 或 503 佔比上升是第一道警報。針對趨勢設警示，不要對單次失敗大驚小怪。
2. 偵測驗證碼與挑戰頁面。 許多網站會回傳 HTTP 200，內容卻是挑戰頁面而非正文。替挑戰頁面建立指紋（標題模式、已知標記結構）並計為失敗，否則你的成功率指標會騙你。
3. 回應大小與內容異常。 商品頁面突然從 80 KB 縮成 5 KB，或解析後一個欄位都取不到，多半是封鎖頁面或誘餌資料。
4. 延遲變化。 漸進式限速——回應時間從 300 ms 慢慢拉長到 5 秒——是硬封鎖前的軟性警訊。
5. 各代理子網段與各 Session 的成功率。 若失敗集中在特定 IP 網段，就讓那些網段退役；若集中在存活過久的 Session，就縮短 Session 壽命。

警訊亮起時，正確的回應是放慢速度、找出原因——而不是加大火力。先把請求速率砍半，確認標頭仍與當前瀏覽器一致，檢查網站是否改了結構或條款，然後才恢復爬取。遇到封鎖就硬推的爬蟲，只會把暫時性的限速變成永久封鎖。

我們刻意不談的主題

有些防封鎖問題的答案，我們不會發表，因為那些技術存在的唯一目的就是破解存取控制：

• 繞過付費牆或登入牆。 需要驗證才能看的內容，本來就是刻意受控的存取。用自動化繞過這道控制就是未經授權的存取，用什麼工具都一樣。
• 驗證碼解題農場。 驗證碼就是網站對自動化說「不」。工業規模的解題服務，存在的目的就是推翻這個拒絕。
• 爬取個人資料。 姓名、Email、個人檔案與聯絡方式伴隨法律義務（GDPR、CCPA）與實際傷害風險。正派供應商在可接受使用政策中封鎖這些用途，理由充分。
• 自動化搶購。 球鞋機器人、黃牛搶票與帳號農場，正是讓代理背上罵名的使用情境，也是供應商 KYC 機制要過濾掉的對象。

如果一個專案需要以上任何一項，它面對的不是封鎖問題，而是權限問題——沒有任何工程手段能解決權限問題。

檢查清單：合乎道德的防封鎖架構

• 詳讀 robots.txt 與服務條款；確認資料屬於公開且非個人資料
• 有官方 API 或資料饋送就優先使用
• 以網域為單位限速並加入抖動；遵守 Retry-After；以指數退避重試
• 送出完整、內部一致、對應當前瀏覽器版本的標頭組合
• 在 Session 內保存 Cookie；讓 Cookie Jar 與 IP 成對綁定；以合理壽命讓 Session 過期
• 流量真正需要時，才使用有 KYC 審查的供應商提供的輪替式住宅 IP
• 讓黏性 Session 時間窗對齊你最長的有狀態流程
• 逐網域監控狀態碼、挑戰頁面、內容異常與延遲
• 遇到封鎖警訊就放慢並診斷，絕不加大火力

照這套方法做，防封鎖不是軍備競賽——而是用工程語言表達的基本禮貌。網站封鎖的是行為惡劣的流量；治本之道就是讓流量行為良好。想了解工具、法律與架構的完整脈絡，請繼續閱讀我們的網頁爬蟲完整指南。