Shadowrocket HTTPS 解密怎麼設？MitM 憑證與網址改寫實測

Shadowrocket 的 HTTPS 解密（MitM）適合在你有權管理的裝置與網域上，檢查請求內容或驗證測試環境中的網址導向。它不是一般瀏覽功能：安裝並信任 MitM 憑證後，App 才能在指定範圍內檢視 TLS 加密流量；若設定過廣，可能暴露登入資訊、Cookie 或其他敏感資料。本文以使用者已有自己的連線資料為前提，示範如何限定網域、使用 URL Rewrite，並透過可控測試確認結果。

先理解 MitM 解密範圍與使用風險

HTTPS 會在用戶端與網站之間建立加密連線。MitM 解密需要用戶端信任一張由 Shadowrocket 管理的根憑證，並由 Shadowrocket 在設定允許的網域上處理連線。這會改變原本的信任邊界：如果把所有網域都納入，帳戶登入、付款、郵件及其他敏感請求也可能出現在可檢視的資料中。因此，測試時應採取最小範圍原則，只加入自己管理或已獲明確授權的網域，完成後立即移除。

MitM 憑證信任與 VPN 連線狀態是兩件事。Home 的連線開關已開啟，不代表憑證已安裝或已被系統信任；憑證已信任，也不代表目標網域已加入解密清單。若要按設定檔規則測試，請在 Home → Global Routing 選擇 Config，並確認目前使用的設定檔；若使用 Proxy 或 Direct，結果可能不符合預期的分流設定。

產生憑證、安裝並完成 iOS 信任

開始前先確認裝置由你管理，並備份目前使用的設定。Shadowrocket 不同版本的選單排列或文字可能略有差異；以下以 Settings 中的 Certificate 或 MitM 憑證管理項目為定位依據。若頁面沒有相同名稱，請在 App 內確認憑證管理入口，不要安裝來源不明的設定描述檔。

1. 產生憑證

   開啟 Shadowrocket → Settings，進入 Certificate 或 MitM 憑證管理頁面，使用 App 提供的產生憑證功能。若畫面顯示既有憑證，先確認是否為目前裝置與測試用途所建立，不要任意覆寫仍在使用的憑證。

2. 安裝設定檔

   依 Shadowrocket 顯示的提示安裝 CA Certificate。系統若要求允許下載或安裝描述檔，請先核對來源確實是你正在使用的 Shadowrocket 流程，再前往 iOS/iPadOS Settings 中的 VPN 與裝置管理或描述檔頁面完成安裝。

3. 啟用完整信任

   前往 iOS/iPadOS Settings → General → About → Certificate Trust Settings，找到剛安裝的 Shadowrocket 根憑證並開啟完整信任。請確認名稱與來源符合預期；僅安裝描述檔而未完成此步驟，通常不足以讓系統信任該根憑證。

4. 限定測試網域

   返回 Shadowrocket → Settings → MitM，啟用 HTTPS 解密功能，並在 Hostname 清單中只加入一個已授權的測試網域，例如 www.example.com。這是文件示例網域，應替換為你管理的測試網域；不要加入萬用字元或不相關的網域。

5. 發起新請求

   確認 Home 中已選取預期連線，且 Global Routing 與設定檔符合測試條件。關閉原有測試頁面後重新載入目標頁，避免把舊的 TLS 連線或快取結果當成新設定的驗證結果。

如果裝置受學校、公司或其他管理政策控制，系統可能限制憑證安裝或信任設定。此時應先向裝置管理員確認允許的測試方式，不要嘗試繞過管理政策。憑證只應留在測試所需的裝置上；工作完成後，移除測試網域、關閉 HTTPS 解密，並在不再需要時撤銷系統對該根憑證的信任。

設定 URL Rewrite，使用可控網址驗證

URL Rewrite 是依符合條件的 URL 規則修改或重新導向請求，不等於 DNS 規則，也不會自動讓所有 HTTPS 網域都可解密。若 Rewrite 目標是 HTTPS 網址，相關網域必須符合 MitM 設定，並且請求確實經過 Shadowrocket。修改前先保留原始 Config；如果目前使用的是遠端設定檔，請確認編輯方式不會被下次更新覆蓋。

在 Config 編輯目前生效的設定檔時，可將測試規則放入 [URL Rewrite] 區段。以下只適用於你控制的測試主機，作用是將完全符合的舊路徑暫時導向新路徑：

[URL Rewrite]
^https:\/\/www\.example\.com\/old$ https://www.example.com/new 302

範例中的正規表示式以完整 URL 為比對對象：句點使用反斜線跳脫，舊路徑以結尾符號限定，避免意外匹配到其他路徑；空格後是重新導向目的網址，最後的 302 表示暫時重新導向。實際使用時，請把網域與路徑替換成自有測試環境的值，並確認目前 Shadowrocket 版本接受該設定格式。不要直接把範例貼到生產環境，也不要以改寫方式攔截他人登入流程。

如果只想確認改寫結果，使用沒有登入資訊的測試路徑與測試頁面。觀察原始 URL、回應狀態及最終網址是否符合預期；一次只更動一條規則，並在每次修改後重新發出請求。使用 302 可降低測試時被永久重新導向快取影響的機會，但瀏覽器、網站服務或中間快取仍可能保留狀態，因此應以全新請求及可控測試環境交叉確認。

確認解密與改寫結果，按層排查

完成設定後，先確認 Shadowrocket 的連線狀態與路由模式，再使用全新的測試請求。若 Shadowrocket 的請求或連線記錄可顯示目標主機，核對其是否符合 Hostname 清單；如有 HTTPS 解密後可檢視的請求資訊，僅查看測試資料，並遮蔽 Cookie、Authorization、帳戶識別資料與其他敏感欄位。畫面顯示 VPN 已連線，不足以證明 MitM 解密或 URL Rewrite 已生效。

• 目標請求沒有出現在預期記錄：確認測試 App 的流量由 Shadowrocket 處理、Global Routing 使用預期模式，並重新載入頁面建立新連線。
• 請求可見但 HTTPS 內容未解密：依序核對系統完整信任、MitM 開關、Hostname 是否精確匹配，以及測試主機是否使用憑證固定。
• 解密正常但沒有轉址：檢查 URL Rewrite 是否在目前生效的 Config、規則是否放在正確區段、正規表示式是否匹配完整 URL，並確認請求是新發出的。
• 停用 MitM 後仍無法連線：移除測試規則並還原原設定，再確認網站本身、目前網路與既有連線是否正常，避免把網站故障誤判為憑證問題。

部分 App 或網站會使用憑證固定、額外的 TLS 驗證或其他保護機制，因此即使系統信任根憑證，連線仍可能拒絕解密；這不應透過削弱驗證或擴大攔截範圍來處理。HTTP/3、QUIC、應用程式自有網路堆疊、重新導向快取及網站端政策也可能讓測試結果不同。排查時記下測試時間、網域、路由模式與單次改動，並在完成後恢復原設定。