問題彙整¶
本章節彙整了部分常見問題及其解決或處理方式，任何情況下，您應優先透過將服務、用戶端升級到最新版本來解決，如果無法解決，請根據下列方案進行檢查。
常見問題¶
FIRERPA 的理想執行環境為自帶原生 root 權限的系統或客製化系統；如果您的裝置存在 Magisk 且安裝了其他模組，在繼續處理下列問題前，請先停用所有模組並重新啟動，以免造成干擾。
部分軟體無法正常檢視介面佈局，介面沒有任何可操作元素。
請下載此腳本 user-home/modules/script/enhanced_automation_wechat.yaml 並將其放置到裝置的 ~/modules/script 目錄下即可。
firerpa 安裝之後其他軟體無法正常開啟。
老舊版本可能在部分環境下會產生此問題，請改用目前的最新版本。若最終問題仍然出現，請關閉所有 Magisk 模組並重新啟動。
服務無法正常啟動，錯誤訊息指向 avtab 或 unsupported policy database format。
這種情況可能出現於 Android 16，但也不排除較低版本存在相同情況。首先，請務必確保您使用的是最新版本的伺服器端。如果仍然出現此問題，請檢查您使用的 Root 軟體是否為 KernelSU。執行階段崩潰是因為舊版 ksu 損壞了系統的 SELinux policy image；請嘗試使用最新版 ksu。如果仍然崩潰，請改用 Magisk，或降級以 shell 權限執行。
升級到 10.x 版本後，在 9.x 正常的 frida 腳本無法正常使用，或 frida 本身無法正常使用。
10.x 使用的預設 frida 版本可能在部分低版本 Android 上存在問題；由於 frida 17.6.x 及之後版本更新的注入邏輯，導致部分應用程式無法正常注入，或是在舊版安裝時相容性不佳、腳本報錯等問題。從 10.8 版本開始，伺服器端開始隨附兩個版本的 frida-server， 預設情況下，一律使用最新版的 frida-server；如果您遇到上述問題，可以透過設定 frida.version=17.5.2 來指定使用舊版的 frida-server。
執行服務後，特定應用程式無法開啟、閃退或被偵測為異常。
這可能是因為某些 APP 使用了 app-zygote 來偵測 Frida。您可以嘗試在遠端桌面中設定 enhanced-stealth-mode=true 來規避此問題（副作用是無法使用 Frida 的 spawn 相關功能）。在 10.x 中，預設情況下您無需設定此項；10.x 使用的預設 frida-server 版本本身已規避該問題。（但如果您手動切換為 17.5.2 版本，則可能需要進行此項設定）。若最終問題仍然出現，請關閉所有 Magisk 模組並重新啟動。
抓包相關功能釋疑。
無需提問抓包功能是否完善，FIRERPA 已安排好一切，它已經為您完成抓包所需的任何流程。如果您使用的其他抓包軟體抓不到封包，FIRERPA 一定抓得到；如果 FIRERPA 抓不到，那麼沒有任何相同邏輯的軟體能抓到。無需擔心憑證不信任問題，FIRERPA 會在抓包時自動為應用程式安裝系統級根憑證，無需您手動操作。針對 QUIC 降級，startmitm 會自動停用 UDP 協定；正常情況下，APP 無法使用 UDP 時會自動降級而不使用 QUIC，這一切都無需您手動介入。
執行了抓包腳本，但發現抓不到資料封包。
可能原因：一是 APP 本身存在憑證校驗或憑證固定（certificate pinning）機制；二是沒有正確進行前後期處理。如何確定 APP 是否具有憑證校驗機制：開啟全域抓包，然後開啟瀏覽器等其他 APP，確認是否可正常抓取。多嘗試幾個聯網 APP 進行確認：如果有的應用程式可以抓包、有的不行，那麼無法抓包的應用程式極可能採用了私有協定或憑證校驗機制；這通常會在 startmitm 的日誌中輸出 Client TLS handshake failed 等資訊，但這並非重點。若確認 APP 存在憑證校驗，則應透過逆向等其他手段動態繞過校驗機制，才能繼續抓包。關於沒有正確進行前後期處理：一般情況下，部分使用者可能未關閉系統防火牆，導致代理埠無法被手機存取，因此沒有任何反應。另一種情況是，APP 在您啟動抓包之前已建立必要的網路連線，導致抓包啟動後的流量仍透過這些既有連線傳送，而未經過代理。您需要在啟動 startmitm 後，手動完全結束 APP（強制停止），再重新開啟 APP 即可。
使用一鍵抓包後，手機疑似斷網了。
首先，請檢查防火牆是否已關閉。其次，查看在手機瀏覽器瀏覽網站時，一鍵抓包腳本是否輸出日誌。如果出現類似 No route to host 的錯誤，且能與瀏覽器存取動作對應（即每次存取時腳本都輸出該錯誤），那麼可能的原因是：手機本身支援 IPv6 網路存取，且預設 DNS 解析也使用 IPv6；但執行腳本的電腦未開啟或不支援 IPv6，導致出現 No route to host。如果您的寬頻支援 IPv6，請在電腦網路設定中手動開啟；或在腳本命令列中嘗試指定 --proxy-dns 114.114.114.114，並測試是否恢復正常。若這兩種方法均無效，請聯絡支援。
使用 startmitm 抓包時，顯示 No route to host 且應用程式沒有網路。
此問題同上。您可以先測試其他一些 APP 是否能正常抓包，以排除服務問題。如果可以正常代理，那麼這種情況可能是因為裝置支援 IPv6，但您執行 startmitm 的機器不具備有效的 IPv6 位址。如果您的網路存在可用的公有 IPv6，請為您的電腦指派一個；或在路由器端徹底停用 IPv6。
抓包腳本顯示 Client TLS handshake failed, does not trust the proxy's certificate。
如果您可以正常抓取相關應用程式的資料封包，無需理會此輸出；這可能是系統內其他 APP，或 APP 的第三方 SDK 之憑證校驗機制所產生的日誌。
我安裝了自動啟動 APK，但服務沒有正常啟動、無法存取。
自動啟動 APK 受限於不同系統的設定，可能不會隨系統自動啟動。如果開機後無法存取，請透過 APP 中的 手動啟動 按鈕點選手動啟動，等待一分鐘後重試存取。若仍無法啟動，請嘗試手動安裝或模組安裝方式。
使用 Python 介面或抓包時顯示 Service Unavailable。
請確保您已完成 環境準備 章節中的相關設定內容，隨後嘗試多次重新啟動裝置（約 3 次）。