ApiCatcher核心功能介紹及使用場景

ApiCatcher 是給 iOS、Android、macOS 和 Windows 用的 HTTP/HTTPS 抓包與除錯工具。手機上用本機 VPN 接手流量，不必再把裝置代理到電腦；桌面版可以在系統代理和 TUN 之間切換，TUN 用來抓那些不走系統代理的請求。

名字裡的 Api，來自一開始要解決的問題：抓到的請求不該只躺在歷史列表裡，而該變成還能繼續用的介面。下面說明這八項能力各自解決什麼問題，以及對應的使用場景。

抓包

抓包是後面所有功能的入口。開啟後，App 或瀏覽器發出的 HTTP/HTTPS 會經過本機代理，安裝並信任 CA 憑證後就能看 HTTPS 明文。WebSocket 的握手和資料幀也會留下，資料幀按聊天紀錄的方式排列，JSON 會格式化並標示語法，也可以按 Payload 搜尋。

日常會用到的配套能力：

• 黑白名單：按 Host 過濾。白名單不是空的時，只記錄命中的網域；黑名單裡的網域不記錄。支援 *，例如 *.example-api.com。
• Session：從開始到停止是一個 Session，請求歷史可以只看這一次抓包，也可以整段刪掉。
• 搜尋：URL、請求標頭、回應標頭、請求 Body、回應 Body 都能搜。也可以按方法、協定、Content-Type、狀態碼和時間範圍過濾。
• 匯出：單筆請求可以匯出 Raw、cURL、Markdown；一批請求可以匯出 HAR。圖片、影片、音訊會分開歸類，帶 Range 的分段會先合併再匯出。

場景：介面問題排查。 把出錯的操作再做一次，在歷史裡打開這筆請求，對照用戶端實際發出的 URL、Header、Body，以及伺服器回來的狀態碼和回應 Body。請求本身就不對，問題在用戶端；請求是對的、回應不對，問題在伺服器。先分清兩邊，再往下查。

場景：確認某個功能用了哪些介面。 把這個功能按不同業務情境各操作一遍。抓包歷史裡就能確定它打了哪些介面，以及不同情境下的傳參有何不同。

自動產生 API

符合條件的 HTTP/HTTPS 請求會整理成按 Host 分組的介面文件。介面的唯一鍵是「方法 + Host + Path」。同一個介面被抓到多次時，Query、Header、Body 只補上還沒出現過的欄位，不會用後一次的欄位名稱蓋掉前一次。回應範例只在狀態碼為 200 時更新。

文件可以按 Host 整包匯出，也可以只匯出一個介面，或從 API 收藏匯出。目標是 Postman、Apifox，或一份 Bruno 的 ZIP。

場景：匯出到介面管理。 介面文件產生之後，按 Host 整包匯出，或只匯出一個介面、一個收藏目錄，送到 Postman、Apifox 或 Bruno，在介面管理工具裡維護和共享。

與匯出 HAR 再匯入 Postman 等 API 管理平台產生 API 不同，ApiCatcher 產生的 API 會隨著捕獲到的請求覆蓋的業務情境變多，欄位也越來越完整。

重放請求

重放是 ApiCatcher 自己再當一次用戶端：從歷史裡取出一筆 HTTP/HTTPS 請求，改或不改查詢參數、請求標頭、請求 Body，發給伺服器，在重放頁看狀態碼和回應。App 不會因為這次重放而重新整理畫面。WebSocket 則是在這裡重連，手動發一幀、看對端回包。

抓包開著時，重放會經過本機代理，所以已經設定的重寫和腳本會作用在這次重放上，歷史裡也會再出現這筆記錄。

場景：介面聯調。 後端改完介面，或在介面裡加上排查日誌後，用戶端一鍵重放剛才抓到的那筆請求。一次重放就能確認問題是否已經修好，也能讓這次請求打進新日誌裡，繼續排查。

組合重放

組合重放把多筆 HTTP/HTTPS 請求放在一張畫布上，按依賴執行。沒有互相依賴的節點並行；有依賴的節點串行，上一層全部成功後才跑下一層。

四個常用編輯動作：

場景：鏈路聯調。 多個請求要按順序一起調，後面的請求要用前面的回應。給下游設定依賴，用依賴注入把上游回應填入下游請求，按依賴順序執行。例如 GET /user 依賴 POST /login，POST /order 依賴 GET /user，在後兩個請求上把 token 注入 Authorization，按登入、取得使用者資訊、下單的順序執行。

場景：測同一介面多種入參。 同一個介面要一次驗證多組不同入參。把該請求添加多次，若要串行執行，就把所有節點串成一條線（只建立依賴，不必設定依賴注入），各節點用預設參數寫入各自的請求體。執行後對比各節點結果。例如把登入請求添加三次，請求體分別是正常帳號、密碼錯誤、空密碼。

重寫

重寫在請求真正到達業務伺服器之前，或回應回到 App 之前，按規則改流量。一條規則由作用範圍和動作組成。作用範圍是 Host，加上可選的 Path 和 Method。

動作包括：

• 重新導向：把正式網域轉到本機或預發。
• Mock：不發真實請求，直接回傳預設狀態碼、回應標頭和 Body。
• 丟棄請求 / 丟棄回應：模擬發不出去，或伺服器一直不回。
• 延遲：給回應加上等待，看弱網下的 Loading 和逾時提示。
• 修改：改 Header、整段替換 Body，或用正規表示式在 Body 裡尋找替換。正規表示式可以用 AI 按自然語言產生。

場景：介面 Mock。 後端介面還沒就緒，或要讓用戶端走到某種狀態時，不發真實請求，直接回傳預設的狀態碼和回應體。例如給訂單列表配一條 Mock，回傳待付款和已完成兩種狀態，畫面可以先做完，介面就緒後關掉規則。

場景：改寫回應。 只改回應裡的個別欄位，看用戶端接著怎麼表現，不用改伺服器資料。例如用正規表示式把 "balance": 100 換成 "balance": 0，看餘額不足時按鈕怎麼灰。

腳本

規則蓋不住「每次都不一樣」的邏輯時，用 JavaScript。啟用後，命中的請求進入 interceptRequest，回應進入 interceptResponse。可以自己寫，也可以讓 AI 產生，或填一個區域網路腳本 URL，由團隊統一下發。

腳本裡可以直接用：

• crypto：MD5、SHA、HMAC、Base64，用來補簽名或做 Body 加解密。
• localStore：跨請求保存 Token 等狀態。
• httpClient：在腳本裡再發一個 HTTP 請求，例如 Token 過期時先登入再注入。

場景：動態計算請求。 簽名、時間戳這類值每次都不一樣，固定替換做不到。在腳本裡按當次請求算完再放行。例如重放總是 401 時，用目前時間和 Body 做 HMAC，寫回 X-Timestamp 和 X-Signature。重放前必須先啟動捕獲，腳本才會作用到這次請求上；不啟動捕獲，腳本不會執行。

場景：Body 加解密。 企業內部專案通常會把 Body 再加密一層，HTTPS 解開後看到的仍是密文。用腳本在請求發出前加密、在回應回來後解密，才能看明文、改明文。例如在 interceptResponse 裡把回應 Body 解密後查看；重放時在 interceptRequest 裡把改過的明文再加密發出。重放前必須先啟動捕獲，腳本才會執行。

DNS 欺騙

產品裡的名稱是 DNS 映射。它做的是代理層的 DNS 欺騙：不改系統 hosts，也不改 Wi-Fi 的 DNS。開啟抓包後，命中規則的連線繞過公網解析，直接連你填的 IP。HTTP 的 Host 和 TLS 的 SNI 仍是原網域，App 無感知。規則支援萬用字元，例如 *.apicatcher.net。

場景：同網域切測試和預發。 測試、預發、正式環境使用同一個網域。要存取測試環境或預發環境時，透過修改 DNS 把這個網域指到對應環境。例如在 DNS 映射裡把該網域指到測試環境或預發環境的 IP，開啟抓包後生效，不用每次改 Wi-Fi 的 DNS，也沒有系統 DNS 快取問題。

定時任務

定時任務按計畫執行一筆請求重放，或一整條組合重放。排程有兩種：

• Cron：6 段，順序是「秒 分 時 日 月 週」。0 * * * * ? 表示每分鐘的第 0 秒。不確定寫法時，用 AI 按自然語言產生。
• 自訂：按間隔秒循環，可限制次數或持續分鐘數。

命中自動終止條件後任務停止。執行歷史裡可以看到耗時和成功率。手機上要先開始抓包，任務才會跑；桌面版只要應用程式開著就會跑。

場景：定時提交。 時間窗口很短，手動點容易錯過。把一筆請求或一條組合重放按間隔自動執行，並用回應內容自動停。例如秒殺開賣前幾秒開始，每 1 秒提交一次下單請求，回應裡 code 為 200，或 Body 出現「搶購成功」「活動已結束」時停掉。

場景：定時巡檢。 按週期反覆請求同一條介面，看它是否可用、是否變慢。例如健康檢查用 Cron 0 * * * * ?，每分鐘一次，不配自動終止，在執行歷史裡看 P95。

場景：定時回歸。 把已經編排好的組合重放按計畫反覆執行，檢查結果是否仍符合預期。例如在組合重放裡把同一介面添加多次，每個節點用預設參數寫入不同入參，這些節點就是一組測試用例，再把這條組合重放設成每週執行一次。（若這些請求要先登入，組合規則先加一個登入請求，作為其它所有請求的共同前置；其它請求彼此只能並行。）

更細的操作步驟在文件裡：用戶手冊、重寫、腳本、組合重放、定時任務。

以上功能並非 ApiCatcher 的全部功能，更多功能可前往官網了解。本文列舉的使用場景也並非只能用於這些場景，只是我們提供這些功能最初想要解決的問題。