在傳送那份 HAR 檔案之前，先讀一讀它裡面有什麼
「您能傳一份 HAR 檔案給我們嗎？」是一個合理的要求——也是日常支援工作中最不經意的危險檔案交接之一。HAR 檔案是瀏覽器會話的完整錄製：每一個請求和回應，帶有使它們運作的 Cookie、授權標頭、權杖和表單內容。它正是支援工程師重現你的問題所需要的，也正是攻擊者重演你的會話所想要的。本文解釋 HAR 檔案是什麼、如何在 Chrome、Edge 或 Firefox 中擷取一份、它會洩漏什麼，以及如何在它去任何地方之前檢查並去識別化它。
HAR 檔案是什麼
HAR——HTTP 存檔——是一種記錄 HTTP 流量的 JSON 格式，由 HAR 1.2 規格標準化，被每個主流瀏覽器的開發者工具以及 mitmproxy 等偵錯代理匯出。該檔案含有一個帶 entries 陣列的 log 物件：每個請求一條記錄，每條都帶有方法與完整 URL、請求與回應標頭、雙向的 Cookie、拆解為參數的查詢字串、任何 POST 正文、回應的狀態、大小和內容類型，以及按階段細分的用時——DNS、連線、TLS、傳送、等待、接收。
換句話說，它不是問題的截圖；它就是問題本身，可以重演。任何處理 HTTP 流量的工具都使用這一格式——瀏覽器工具、效能分析器、支援工程師，以及越來越多的智能體：AI 智能體能逆向工程你的應用嗎？ 中介紹的 REA 技術堆疊原生讀取 HAR 擷取，因為對許多應用來說，API 流量比程式碼更能說明問題。正是這種有用性，讓該檔案在值得傳送之前先值得閱讀。
為什麼支援團隊和廠商索要它
因為它終結爭論。「頁面很慢」變成了帶命名請求和用時的瀑布圖。「API 失敗了」變成了那條回傳 500 的確切請求，帶有確切的負載和確切的標頭。「在我的機器上是好的」不再重要，因為錄製來自你的機器、你的網路、你的帳戶，就在它出問題的那一刻。一位好的支援工程師用一份誠實的 HAR 檔案能做到的，比一週的截圖和回憶還多。
這也是為什麼這個要求如此常被不假思索地轉寄。工單說「附上一份 HAR」，使用者三十秒就匯出一份，而這份檔案——在他登入著、做著真實工作時錄製的——開始旅行：進入工單系統、郵件執行緒，有時是公開論壇或共用磁碟機，在每一跳累積副本。這條鏈上沒有誰稱得上粗心；只是這種格式隱藏了它包含的內容。一個 .har 檔案看起來像惰性的診斷資料。它其實更接近一串金鑰。
如何在 Chrome、Edge 或 Firefox 中擷取一份
在 Chrome 或 Edge 中：打開頁面，按 F12 打開開發者工具，進入網路面板（Chrome DevTools 網路參考記錄了每個控制項）。確保紅色錄製按鈕已開啟，如果問題跨越頁面導覽則勾選保留記錄。從頭到尾重現一次問題。然後在清單中右鍵任何請求，選擇將所有內容另存為 HAR（含內容）（Edge 的說法是儲存網路記錄）。在 Firefox 中流程形狀相同：開發者工具 → 網路，重現，右鍵 → 全部另存為 HAR。
兩個擷取習慣比任何設定都重要。第一，錄製能顯示問題的最短會話：多瀏覽的每一分鐘都是檔案裡多餘的流量——和多餘的秘密，包括其他標籤頁和背景請求當時在做的事情。第二，如果可以，在一個全新的瀏覽器設定檔或隱私視窗中重現問題，只登入出問題的那一個服務。來自乾淨設定檔的擷取只包含那一個會話，別無其他：沒有銀行標籤頁，沒有網頁郵箱，沒有其他應用的權杖混在其中。
它會洩漏什麼
首先是你的會話。Cookie 和 Set-Cookie 標頭以及 Cookie 清單攜帶著你的會話識別符，而大多數會話 Cookie 以最直白的意義就是持有者憑證：出示它的人在它過期或被撤銷之前都會被當作你。Authorization 標頭還加上持有者權杖，有時還有 Basic 憑證。這種格式不會把這些標記為特殊內容；它們只是標頭，被忠實地記錄下來。
然後是沒人會當作標頭的東西。權杖一直在 URL 裡搭車——API 金鑰、密碼重設和郵箱驗證連結、簽章下載 URL、OAuth 回呼——而 HAR 記錄完整 URL，還把查詢字串拆出來方便閱讀。POST 正文攜帶著表單攜帶的一切：你在擷取期間登入時用的密碼、資料編輯、訊息、個人資料。回應正文能帶回同一類資料。一次真實會話的 HAR 檔案實際上是你帳戶的部分實錄——這就是為什麼在線路上讀取網路流量的工具如 PCAP Analyzer、以及在瀏覽器中讀取它的工具如本頁，都被造成明明白白地展示憑證，好讓你看清自己拿著什麼。
在傳送之前檢查並去識別化它
所以：在任何其他人之前打開這個檔案。這正是本站 HAR File Analyzer 的用途——把 .har 拖入頁面，它在本機、你的裝置上剖析，永不上傳，敏感值預設遮罩：Authorization、Cookie 和 Set-Cookie 標頭、每個 Cookie 值，以及任何名稱像權杖、金鑰、秘密、會話或密碼的標頭、查詢參數、表單欄位或 JSON 鍵。瀏覽摘要和最慢、最大的請求；檢查出現了哪些主機——一份擷取有時含有你根本沒在看的網站的流量——並且只在你自己的螢幕上使用「顯示值」開關，如果你需要確認裡面到底有什麼的話。
然後下載去識別化版 .har，改為傳送那一份。去識別化保留支援工程師需要的結構——同樣的條目、標頭、作為形態的 URL、狀態和用時——並將憑證值替換為字面文字 REDACTED，在標頭、Cookie、查詢字串、表單資料和 JSON 正文一視同仁。一個限制印在工具上、這裡再重複一遍：既不是 JSON 也不是普通表單資料的 POST 正文無法被安全剖析，因此會原樣保留——如果你的擷取含有這樣的正文，在檔案出行之前自己讀一讀它。遮罩的 CSV 摘要出於同樣的原因存在：當工程師要求「只要請求的清單」時，它就是你要附加的檔案。
去識別化做不到什麼
去識別化移除了金鑰；它沒有移除地圖。去識別化後的 HAR 仍然顯示你的主機和端點、你的參數名稱、回應的形態和大小、呼叫的順序和用時——一張你的應用 API 的工作草圖，這本身可能就是你不發布的資訊。它也無法召回副本：一旦原始檔案進入了工單系統或收件匣，去識別化你的副本並不能改變他們的副本。透過廠商給你的私密渠道分享去識別化檔案——工單本身，而不是公開貼文或公開檔案連結——並在工單中請求在案件關閉時刪除該檔案。有信譽的支援機構通常都會這樣做；開口問一句不花什麼。
而如果一份原始的、未去識別化的 HAR 已經流出——傳到了錯誤的地址、附在了公開問題上、留在了共用資料夾裡——就把該會話當作已暴露，因為它確實暴露了：登出該服務（這通常會使會話在伺服器端失效），重新登入，並輪換其中出現過的任何 API 金鑰。這與任何洩漏的憑證適用同一規則，也是本站其他檔案工具上的小字完全相同的原因——Binary File Inspector 在本機讀取執行檔，與本頁在本機讀取擷取出於同一原因：最需要檢查的檔案，恰恰是不應該上傳去檢查的檔案。