分享代理偵錯紀錄前，如何安全清理 HAR 檔案
瀏覽器產生的 HTTP Archive（HAR）能把複雜的代理故障轉成可重現證據。它會記錄請求順序、重新導向、狀態碼、各階段耗時、標頭，有時還包含請求與回應內容。也因為資訊完整，未經檢查的 HAR 很危險：工作階段 Cookie、Bearer 權杖、代理帳號、客戶識別碼、搜尋詞、表單內容、內部主機名稱及完整 API 回應都可能在其中。
現代瀏覽器工具會預設排除部分敏感欄位，但這只是擷取階段的一層保護。版本與匯出選項行為不同，其他工具匯入的紀錄也可能包含完整資料，使用者還能主動選擇包含敏感資料的匯出方式。因此，任何 HAR 在經過確定性清理與獨立複核之前，都應視為敏感檔案。
先定義疑難排解真正需要什麼
不要一開始就錄製整天的瀏覽活動。先寫下要回答的問題。代理疑難排解通常只需要：
- 瀏覽器是否經過預期代理，而非直接連線；
- 失敗請求、重新導向順序、狀態碼與回應類型；
- DNS、連線、TLS、傳送、等待與下載耗時；
- 一個允許對外揭露的關聯識別碼；
- 瀏覽器版本、作業系統、代理區域、位址家族與 UTC 時間窗。
真實帳戶 Cookie、完整網頁、其他分頁、付款資料、聊天內容及擴充功能產生的無關請求通常不需要。不能協助回答問題的欄位就不要擷取。
擷取最小可重現工作階段
使用隔離的瀏覽器設定檔或只含合成資料的暫時測試帳戶。關閉無關擴充功能及分頁，清空 Network 面板，在重現動作前一刻開始錄製，故障出現後立即停止。
目標必須是你獲准測試的系統。需要登入時，使用短期測試憑證，並在擷取後立即撤銷，即使瀏覽器表示已自動隱藏該憑證。
在 HAR 以外另行記錄 UTC 時間、瀏覽器完整版本、代理產品與請求區域、IPv4 或 IPv6、單一重現步驟，以及預期和實際結果。說明中不得放代理密碼、工作階段權杖或原始客戶識別碼。
解析 JSON 後再清理，不要直接全文取代
HAR 是結構化 JSON。正確方式是解析、走訪已知位置並產生新的輸出檔。全域正規表示式容易漏掉跳脫值、破壞 JSON，或刪除無害文字卻留下另一位置的真正密鑰。
先建立不分大小寫的標頭禁止清單：
authorization
proxy-authorization
cookie
set-cookie
x-api-key
x-auth-token接著檢查每個請求 URL、查詢參數、請求內容、回應標頭與回應內容。應用程式欄位名稱各異，應補上實際使用的 access_token、refresh_token、session、signature、key 與 code。
最小轉換邏輯可以是：
const blocked = new Set([
"authorization", "proxy-authorization", "cookie",
"set-cookie", "x-api-key", "x-auth-token"
]);
function redact(headers = []) {
return headers.map((h) => blocked.has(h.name.toLowerCase())
? { ...h, value: "[REDACTED]" }
: h);
}
function sanitize(entry) {
entry.request.headers = redact(entry.request.headers);
entry.response.headers = redact(entry.response.headers);
entry.request.cookies = [];
entry.response.cookies = [];
entry.response.content.text = undefined;
return entry;
}這只是起點，不是通用成品。程式必須處理可選物件不存在的情況；原始檔與清理檔要使用不同路徑及清楚名稱，避免支援人員拿錯。若制度要求保留原件，只能放在權限嚴格且期限明確的受控位置。
URL 與內容採用允許清單
URL 會透過查詢參數、路徑片段與 fragment 洩漏資料。敏感參數可保留參數名稱但取代數值，以便分析請求結構。若路徑中包含帳戶、電子郵件、訂單編號或簽署物件鍵，應將整個片段改為穩定預留位置。
請求及回應內容應更嚴格。預設移除所有內容；只有沒有內容就無法排錯時，才按允許的媒體類型與欄位清單保留。JSON 要遞迴移除敏感鍵；表單預設取代所有值；二進位、壓縮、多段或未知內容直接捨棄。
不要為了辨識方便而保留密鑰首尾字元。部分權杖仍可協助攻擊與跨資料集關聯。如果確實需要比對同一個非敏感識別碼，應使用本工單專屬鹽值產生雜湊，結案時銷毀鹽值。
有意識地保留診斷價值
去識別不能讓 HAR 變成空殼。安全且與問題有關時，可以保留：
- 請求方法與去識別後的目標標籤；
- HTTP 版本、狀態碼、重新導向順序及不含使用者資料的錯誤文字；
- 分階段耗時與傳輸大小；
- Content-Type、Cache-Control 和審核過的關聯 ID；
- 經批准可揭露的連線識別碼、伺服器位址與憑證中繼資料；
- 失敗請求以及解釋它所必需的少量相依項目。
若主機名稱不能對外揭露，可使用 proxy-gateway、target-api、identity-service 等穩定標籤。真實對照只放在內部工單，不放進共享檔案。
假設第一次清理會失敗，再做獨立驗證
不能只看程式結束碼，必須執行第二輪獨立檢查：
- 重新解析輸出，確認 JSON 有效且結構仍符合 HAR。
- 不分大小寫搜尋禁止標頭與已知密鑰欄位。
- 搜尋擷取時使用的測試使用者名稱、電子郵件、租戶、權杖、Cookie 名稱、代理端點與內部主機名稱。
- 掃描 Bearer、類似 JWT、雲端密鑰、私鑰與高熵權杖模式。
- 在乾淨測試設定檔中開啟清理檔，確認故障順序仍可理解。
- 高風險紀錄外發前必須由第二人複核。
掃描命中不一定代表洩漏，但每個命中都要有解釋。在工單記錄清理器版本、規則版本、輸出校驗和、複核人及複核時間。
透過受控工單包分享
使用具備指定收件者、有效期限及下載紀錄的受控工單系統。不要使用公開連結、個人雲端硬碟、聊天上傳或一般郵件附件。共享包應包含清理後的 HAR、簡短重現說明、預期結果、實際結果及安全關聯識別碼。
傳送前就設定刪除日期，結案時要求接收方確認刪除。若資料跨組織或跨區域，應先核對資料處理協議、保存期限、獲准支援位置與事件回應聯絡人。
相關排錯可繼續閱讀 98IP 的安全重送失敗請求、代理驗證 407 故障診斷及區分代理限流與目標站限流。
發布前檢查清單
- [ ] 使用隔離設定、合成資料與最短時間窗擷取。
- [ ] 短期憑證已在擷取後撤銷。
- [ ] 清理器解析 JSON 並寫入獨立輸出檔。
- [ ] Authorization、Proxy-Authorization、Cookie、API Key 與業務權杖均已移除。
- [ ] URL、路徑、查詢參數、請求與回應內容均已檢查。
- [ ] 未知與二進位內容已移除。
- [ ] 輸出通過第二輪密鑰掃描與人工複核。
- [ ] 剩餘內容仍能解釋故障順序。
- [ ] 存取範圍、收件者、保存期、刪除與跨境處理已獲批准。
常見問題
瀏覽器預設匯出的 HAR 是否足夠安全？
它是有價值的第一層控制，但不能取代外發審核。版本、匯出選項、擴充功能、匯入資料及業務自訂欄位都會改變實際內容，仍需獨立清理及驗證。
Proxy-Authorization 與 Authorization 是否應分開處理？
不應。兩者都可能包含可重用憑證或挑戰回應，都要移除；也要檢查 URL 或工具中繼資料是否嵌入代理使用者名稱。
能否只分享失敗的單一項目？
很多情況可以。只補充解釋它所需的重新導向或相依項目。最小化資料通常優於對大型擷取包做大量取代。
對個人資料做雜湊就足夠嗎？
不一定。穩定且無鹽的雜湊可能被猜出，也仍可用於關聯。可以刪除就刪除；確需比對時，按批准制度使用工單專屬鹽值。
合規說明
只擷取你獲准測試的流量、帳戶與系統。遵循最小權限、資料最小化、目的限定、受控存取、短期保存及安全刪除。即使自動工具回報成功，HAR 仍可能包含個人資料或驗證材料，因此離開事件邊界前必須人工複核。
內部研究說明：Chrome DevTools 的 Chrome 130 文件說明 HAR 預設匯出會排除敏感資料；2026 年 8 月 25 日發布的 Chrome DevTools 152 資料反映目前 Network 工具背景。外部資料位址只保存在內部營運紀錄中。
