如何識別代理資料收集中的陳舊快取回應
代理請求可以快速完成並回傳 200，但其資訊仍可能過舊，無法用於價格檢查、庫存監控、市場研究快照或在地化稽核。輪換出口 IP 也不保證取得新表示：瀏覽器快取、共享中介層、CDN、Service Worker、應用程式快取與來源伺服器本身都可能重用資料。
正確問題不是「是否使用快取」。快取通常正常且合理。真正問題是：「回應是否符合本任務的新鮮度契約，以及能否證明由哪一層提供？」
公開來源說明：RFC Editor，RFC 9111《HTTP Caching》，2022 年 6 月。
用業務語言定義新鮮度
請求前先寫明最大可接受年齡：
| 工作流程 | 新鮮度契約範例 |
|---|---|
| 市場研究目錄 | 必須在排定的收集時段內觀察 |
| 價格或庫存檢查 | 表示年齡不得超過核准門檻 |
| 廣告或在地化 QA | 素材與到達狀態適用於活動時段 |
| 合規歸檔 | 保存指定 UTC 時間實際觀察到的表示 |
| 靜態參考資料 | 即使位元組未變，也需驗證器確認仍有效 |
不要設定單一全域門檻。季度目錄的「新鮮」不適用於短期促銷。將契約與結果一同保存，方便日後解釋通過原因。
理解各回應標頭能證明什麼
記錄回應標頭，但不要把任何單一欄位視為絕對事實：
Date表示來源伺服器聲明的訊息產生時間。Age在重用快取回應時回報其在快取中的估計時間。Cache-Control描述快取與再驗證指示。Expires可以定義到期時間。ETag與Last-Modified是條件式請求可用的驗證器。Vary指出哪些請求欄位參與快取選擇。Warning或中介層專用診斷欄位可補充脈絡，但可攜式邏輯不應依賴未公開的供應商欄位。
時鐘偏差會扭曲時間比較。時間戳記使用同步 UTC，請求耗時使用單調時鐘，詳見代理時鐘偏差指南。
缺少 Age 不證明回應直達來源伺服器；存在 Age 也不代表本文不可接受。所有證據都必須與任務契約比較。
建立受控樣本
使用可自行更新的已授權端點，在本文中回傳無敏感資訊的版本標記，並支援 ETag、Last-Modified、Cache-Control、Date 與條件式請求。
至少執行以下階段：
- 發布版本 A，透過直連對照與每條代理路線取得。
- 在聲明的新鮮期內重複請求，確認合理重用。
- A 仍在新鮮期時發布版本 B，記錄業務契約是否允許繼續使用 A。
- 等待進入必須驗證的階段後再請求。
- 使用版本 A 的驗證器傳送條件式請求。
- 模擬已授權的來源伺服器故障，觀察是否明確允許提供陳舊回應。
- 恢復來源伺服器並確認路線最終收斂到版本 B。
不要使用隨機正式環境頁面作為樣本。內容若不可預測變化，就無法區分快取行為與來源差異。
保存結果信封
每次嘗試記錄：
test_case_id
observed_at_utc
route_id
exit_region
session_id_hash
request_header_profile
final_status
redirect_chain_digest
date_header
age_seconds
cache_control
expires
etag_hash
last_modified
vary
content_type
body_byte_count
body_digest
semantic_version_marker
duration_ms
freshness_contract_seconds
freshness_result驗證器可能包含內部識別時應保存摘要。不得記錄代理憑證、授權標頭、Cookie、權杖、個人資料或完整敏感本文。
使用請求標頭完整性測試證明對照與代理請求採用相同相關欄位。若 Accept-Language、編碼偏好、Cookie 或授權資訊不同，本文差異可能是正確變體而非陳舊資料。
重試前先分類
使用明確狀態：
- 新鮮且等價： 符合契約，版本或驗證器符合預期，業務語意正確。
- 新鮮但屬於變體： 符合契約，但因
Vary、區域、帳號或實驗維度而不同。 - 陳舊但允許： 超過一般新鮮期，但回應政策明確允許且任務可以接受。
- 陳舊且不可接受： 超出業務契約，或必須驗證後仍持續回傳舊內容。
- 來源已更新、快取未收斂： 受控來源為 B，某條路線在政策外仍回傳 A。
- 無法判定： 缺少時鐘、回應標頭、本文或對照證據。
- 內容無效： 攔截頁、登入外殼、殘缺本文或錯誤結構；新鮮度無法補救。
不要把所有摘要差異標示為「新鮮」。不同的錯誤頁不是有效新表示。傳輸成功後仍需檢查必要欄位、語言、記錄數與版本標記。
再驗證時保留首次證據
先執行原始請求並保存結果。隨後在來源契約允許時，使用已記錄驗證器發起受控再驗證。304 Not Modified 可以確認已儲存表示仍有效，但不會提供新本文。
測試需要強制驗證時可使用 Cache-Control: no-cache，不要將其與 no-store 混淆，也不要預設加入隨機查詢參數。快取破壞參數可能改變應用程式資源、伺服器行為、分析或簽章要求，而且測試的是另一個快取鍵。
若必須測試唯一 URL，只能使用自有或已授權受控端點，並將其標記為獨立實驗。不得對第三方網站執行無界限的快取破壞。
每次只改變一個維度
矩陣至少包括：
- 直連對照與代理路線；
- 各目標區域；
- 新連線與重用連線；
- 乾淨與有記錄的瀏覽器設定檔；
- 一般取得與條件式驗證；
- 完全相同的 URL、方法、相關請求標頭與帳號狀態；
- 來源伺服器健康及已核准故障模擬。
同時改變出口 IP、Cookie、語言、瀏覽器版本、請求標頭與 URL 會破壞歸因。代理連線池年齡測試可協助分離連線重用與回應重用。
常見故障模式
舊本文相同，Age 持續增加
在回應或業務新鮮期到期前可能完全合理。超出政策後，保存快取指示、驗證器行為、路線與本文摘要再升級處理。
舊本文相同，但沒有 Age
檢查瀏覽器快取、Service Worker、應用程式回應與來源伺服器。沒有 Age 不等於直達來源。
輪換 IP 後本文不同
確認語言、帳號狀態、實驗分組與 Vary 輸入。新本文可能只是區域變體，而不是更新的表示。
回傳 304，但業務資料仍顯得陳舊
驗證器可能正確確認表示未改變，而來源應用程式本身的資料已經陳舊。快取驗證證明的是相對於驗證器的表示狀態，不是業務事實。
把快速回應當作快取命中
延遲不是可靠的快取證據。附近來源可以很快，壅塞快取也可能很慢。應使用回應標頭、驗證器、受控版本變化與本文摘要。
操作檢查清單
- 為每項任務定義新鮮度門檻。
- 記錄精確 URL、方法、請求標頭、路線、區域與用戶端組建。
- 保存
Date、Age、Cache-Control、Expires、驗證器與Vary。 - 對本文計算摘要並驗證業務語意。
- 與受控直連路線比較。
- 在再驗證或重試前保存首次結果。
- 每次只改變一個維度。
- 區分合理變體與陳舊內容。
- 避免無界限查詢參數快取破壞。
- 將憑證、識別符、Cookie 與敏感本文去識別化。
- 針對契約失敗告警，而不是針對使用快取告警。
常見問題
輪換住宅代理是否保證內容最新？
不保證。輪換改變網路出口，但瀏覽器、中介層、CDN、Service Worker、應用程式或來源快取仍可能重用表示，也可能只產生不同區域變體。
Age: 0 能否證明來源產生了新本文？
不能。它只是一項快取訊號。還需結合驗證器、受控版本標記、本文摘要與直連比較。
每個收集請求都應使用 no-cache 嗎？
不應。這會增加來源負載並失去合理效能收益。只在業務需要驗證且目標允許時使用，並與已記錄的新鮮度契約一致。
陳舊回應是否可能被接受？
可以，前提是 HTTP 政策允許且業務契約接受，例如已核准來源故障期間的非關鍵參考資料。必須明確標記，不能簡單稱為新鮮。
合規說明
只測試你獲准使用的端點、帳號、資料集與代理基礎設施。遵守快取指示、存取控制、合約、隱私、著作權、適用的 robots 規則與速率限制。控制樣本流量，不得利用快取測試繞過限制或迫使來源伺服器承受過量負載。
