從 403/429、指紋辨識、驗證碼、動態頁面與登入工作階段出發，說明網頁擷取受限的真實原因，並提出 API 優先、限速退避、增量快取與合規帳號環境的處理方式。
網頁擷取遇到 403、429、驗證碼或登入失效時，正確方向不是先輪換 IP、偽裝指紋或「模擬真人」。這些訊號通常代表請求頻率、存取範圍、驗證方式或自動化行為已超出網站允許的邊界。繼續規避會讓臨時限制升級，也可能違反服務條款、合約、著作權或資料保護規範。
更穩定的處理方式：先確認授權與可用介面，再減少請求、做好快取與退避，最後才使用瀏覽器自動化處理確實需要渲染或人工登入的頁面。驗證碼應視為暫停訊號，而不是需要破解的技術障礙。
依現象定位問題
| 現象 | 常見原因 | 合規處理 |
|---|---|---|
| 429 Too Many Requests | 請求過快、並發過高、重複抓取 | 降低速率，讀取 Retry-After，採用指數退避 |
| 403 Forbidden | 未授權路徑、政策攔截、工作階段缺失 | 檢查權限、條款、robots.txt 與驗證方式 |
| 出現驗證碼 | 網站要求人工確認或阻擋自動化 | 暫停任務，人工處理或聯絡站台取得 API |
| 登入反覆失效 | Cookie 過期、多人覆蓋工作階段、身分驗證失敗 | 使用官方 OAuth 或服務帳號，規範工作階段交接 |
| 頁面有內容，腳本拿不到 | JavaScript 渲染、介面非同步載入 | 使用官方 API；獲准後用瀏覽器渲染再讀取 DOM |
| 選擇器突然失效 | DOM 改版、A/B 測試、語言變更 | 使用語意定位、結構測試與告警，不硬編碼階層 |
| 資料重複或缺漏 | 翻頁、游標、時區、更新窗口錯誤 | 建立唯一鍵、增量水位與重跑機制 |
一次只改一個變數並保留日誌。若同時換 IP、User-Agent、帳號與解析器，即使偶然成功，也難以判斷真正的問題根因。
第一步：確認你有權擷取這些資料
開始前回答四個問題：
- 資料是否公開，還是登入後、付費後或僅供特定角色存取？
- 網站是否提供 API、匯出、Feed、Webhook 或合作資料介面？
- 服務條款、robots.txt、合約與當地法律是否允許目前用途？
- 資料是否包含個人資訊、受著作權保護內容或其他敏感欄位？
robots.txt 是站台向自動化用戶端表達允許與禁止路徑的標準機制。RFC 9309 規定了 Robots Exclusion Protocol 的語法與比對方式，同時也明確指出它不是存取授權。換句話說，robots.txt 允許擷取不代表你取得複製、處理或商業使用資料的全部權利；被禁止的路徑更不應透過其他入口繞過。
企業專案應保留資料來源、存取依據、用途、欄位、保存期限與刪除機制。能用聚合資料解決問題時，不要收集可辨識個人的資訊。
第二步：優先選擇穩定的資料入口
優先順序通常應為：
- 官方 API、Webhook 或資料匯出；
- 公開 Feed、Sitemap 或批次檔案；
- 獲得許可的一般 HTTP 頁面；
- 必須渲染 JavaScript 時才使用瀏覽器自動化；
- 需要人工帳號與互動的頁面最後處理。
API 通常提供欄位定義、分頁、速率限制與錯誤碼，維護成本低於解析 UI。網頁只是給人看的介面，隨時可能改版，不應視為穩定的資料庫。
若網站沒有合適介面，先聯絡資料所有者說明用途、頻率、欄位與商業規模。一份明確的資料授權通常比長期對抗限制更划算。
第三步：解決 429 與 IP 封鎖——減少負載，而不是隱藏來源
設定速率與並發上限
從單一並發與較長間隔開始，觀察回應時間與錯誤率。伺服器回傳 Retry-After 時依其指示等待；若沒有，使用指數退避並加入隨機抖動，避免多個任務同時重試。
示意策略：
等待時間 = min(上限, 基礎時間 × 2^重試次數) + 隨機抖動
達到最大重試次數後停止並告警，不要無限迴圈。
做快取與增量更新
對同一 URL 設定快取，使用 ETag、Last-Modified 等條件請求（若服務支援）。記錄最後更新時間或游標，只抓取新增與變動內容。全量任務與日常增量任務分開，可顯著降低請求量。
誠實識別你的用戶端
合規的爬蟲應使用穩且真實的 User-Agent，說明用途並提供聯絡頁面或電子郵件。偽裝成一般瀏覽器、頻繁更換身分會讓站台更難區分善意流量，也增加被阻擋的機率。
當某個 IP 被限制，先暫停任務並核對原因。為繼續存取而輪換代理可能被視為規避存取控制，而不是修復方案。
第四步：處理指紋辨識與行為分析
瀏覽器指紋會組合 User-Agent、作業系統、語言、時區、解析度、Canvas、WebGL 等訊號。網站還可能分析請求節奏、導覽路徑與工作階段行為。OWASP 將 Fingerprinting、Scraping、CAPTCHA Defeat、Credential Stuffing 等列為不同的自動化威脅情境，這說明了網站為何會綜合多種訊號判斷自動化風險。
對授權任務，目標不是製造大量「像真人」的身分，而是讓環境穩定、可解釋：
- 同一業務帳號使用固定環境與正常驗證；
- 瀏覽器參數與實際地區與裝置一致；
- 不隨機修改指紋以規避封鎖；
- 把擷取頻率、任務 ID 與負責人寫入日誌；
- 與站台約定允許的帳號數、並發與資料範圍。
若站台仍將已授權任務誤判，向對方提供時間、User-Agent、出口位置與請求樣本，請求加入白名單或提供專用介面。
第五步：驗證碼出現時停止自動化
驗證碼用於確認真人或阻擋可疑自動化。不要使用 OCR、打碼平台、驗證碼破解外掛或其他服務自動繞過。
正確處理流程：
- 立即暫停目前帳號與任務佇列；
- 儲存觸發前的請求速率、路徑與錯誤日誌；
- 由有權限的人員在官方頁面完成必要驗證；
- 檢查是否請求過快、工作階段過期或存取不被允許的路徑；
- 需長期自動化時聯絡站台申請 API、服務帳號或白名單。
即使人工完成一次驗證，也不表示之後可無限自動請求。應先修復觸發原因。
第六步：登入與多帳號登入要使用正式權限
登入後的資料比公開頁面更敏感。優先使用 OAuth、服務帳號、API Token 或平台官方團隊權限，不要讓腳本儲存個人主密碼。
確實需要瀏覽器工作階段時：
- 一個合法業務帳號對應一個穩定環境；
- Cookie 加密儲存並設定到期與撤銷；
- 開啟 MFA，自動化不得繞過二次驗證；
- 禁止多人同時重設密碼或複製 Cookie；
- 記錄誰在何時啟動了哪個任務；
- 離職、專案結束或權限變動後立即撤銷存取。
多帳號只適用於你確實擁有或獲授權的帳號。網站限制一個主體只能有一個帳號時，環境隔離不能用於突破該限制。
第七步：讓動態頁面解析更耐改版
使用語意與穩定屬性
優先定位標題、表頭、可存取性屬性與站台公開的測試識別，避免依賴 div:nth-child(7) 這類脆弱階層。頁面刷新後重新讀取 DOM，不假設舊節點仍存在。
把擷取與業務邏輯分開
擷取層只負責把頁面轉成結構化欄位，驗證層檢查型別、範圍、唯一鍵與必填項。如此頁面改版時只需調整解析器，不會同時破壞後續分析。
建立樣本與告警
儲存少量合規的 HTML 或結構快照作為測試樣本，不要儲存完整帳號頁或敏感資料。監測欄位缺漏率、記錄數、重複率與頁面標題；異常時停止寫入正式資料。
PurpleMark 在授權擷取中的合理作用
當團隊需要同時維護多個已授權帳號、不同客戶或不同地區環境時，可以在 PurpleMark 網頁版中為每個業務帳號建立獨立的瀏覽器環境，把對應的 Cookie、登入後預設開啟的頁面與正常的網路設定一起保存下來。這樣下次再開啟這個環境，瀏覽器會直接回到上次的工作階段與工作頁，避免多人共用同一份 Cookie 或反覆重新登入。
若帳號需要依客戶、平台或地區區分，可使用環境分組把不同業務帳號歸到不同分組，再透過成員權限、共享與轉移指定誰能開啟哪個環境。操作日誌會記錄每個環境在何時、由誰開啟或調整，授權擷取出現爭議時可快速回溯到具體的帳號與負責人。
PurpleMark 協助團隊把「帳號、環境、工作階段與責任」長期管理在同個工作區，但它不應用於繞過 IP 封鎖、驗證碼、帳號數量限制或網站的反自動化控制。先取得權限，再談自動化。
一套可維護的擷取架構
建議將系統拆成五層：
- 排程層：控制頻率、並發、任務優先順序與暫停；
- 存取層：API、HTTP 或獲准的瀏覽器工作階段；
- 解析層：把回應轉成結構化欄位；
- 品質層：去重、型別驗證、缺漏告警與版本記錄；
- 治理層：權限、來源、用途、保存期限與刪除。
每筆紀錄保留來源 URL、擷取時間與解析版本。發生錯誤時可定位並重跑，而非重新抓取整個網站。
常見問題
換代理能解決 IP 封鎖嗎？
它也許暫時改變了出口位置，卻沒解決頻率、權限或行為問題。為繼續存取而輪換代理可能構成規避。應先停止任務、降低請求並聯絡站台。
可以自動辨識驗證碼嗎？
不應。驗證碼是要求暫停或人工確認的訊號。需要持續自動化時，申請 API、服務帳號或白名單。
robots.txt 允許就一定能擷取嗎？
不一定。robots.txt 不是存取授權，還須考慮條款、著作權、隱私、合約與資料用途。
指紋瀏覽器能讓擷取「不被發現」嗎？
無法保證，也不應以規避偵測為目的。它更適合把合法帳號工作階段與團隊權限分開管理，減少 Cookie 混用與誤操作。
結語
網頁擷取受限不是單純的「反爬技術題」。403、429、指紋辨識、驗證碼與多登限制共同指向權限、負載與身分管理。
穩定方案始終是 API 優先、授權明確、請求克制、增量快取、解析可測試與帳號可稽核。遇到驗證碼或封鎖就停下來修復流程，而不是繼續隱藏自動化來源。
