Linux 上的 AI Booster

Linux 用戶端是一款 Qt 6 / QML 桌面應用程式。安裝包發佈於 GitHub Releases。

它在 Ubuntu 22.04 (Qt 6.2) 和 Ubuntu 24.04 (Qt 6.4) 上建置和執行。其他裝有 Qt 6.2 或更新版本的發行版通常也能運作，但只有這兩個版本經過實際測試。

安裝

從 releases 頁面 下載適用於您架構的安裝包，並使用您發行版的套件管理器進行安裝。

發行版安裝包內含預先建置的隧道引擎，因此安裝後即可立即運作，無需再擷取任何其他東西。

程式架構

這點值得了解，因為它解釋了一些您可能會誤認為是程式錯誤 (bug) 的情況：

使用者介面和隧道引擎是兩個獨立的程式。用戶端會將引擎作為子進程啟動，並透過環回 (loopback) 與其通訊——它絕不會將引擎載入到自身進程中。這個界線是刻意設計的：引擎是 GPL-3.0 授權的獨立作品，將其保持在進程之外也意味著，當引擎崩潰時，只會在視窗中顯示為錯誤，而不會拖垮整個應用程式。

您會看到一個結果：如果引擎啟動失敗，使用者介面會保持運作並回報錯誤。這是設計正常運作的表現，而不是半崩潰狀態。

用戶端是開源的——僅指介面，不包含引擎。程式碼倉庫位於 AllianceInterStellar/aibooster-linux，如果您想自行編譯，裡面附有建置說明。請注意，從原始碼建置的版本不包含引擎；您需要另外提供。

桌面 proxy，以及如何復原

這是本頁面上最重要的部分。

當您連線時，用戶端會將您桌面的 proxy 設定重新導向至引擎的本機傳入埠——在 GNOME、Cinnamon 和 MATE 上使用 gsettings，在 KDE Plasma 上則使用 kioslaverc。這是一個全域的機器狀態，其生命週期超過該進程。如果用戶端在 proxy 被重新導向時意外消失，桌面上的每個應用程式都會不斷嘗試連線到一個沒有任何服務在監聽的埠，其症狀就是「電腦失去網際網路連線」，且沒有明顯原因。

用戶端的設計旨在避免讓您陷入這種情況：

• 在進行任何變更之前，它會將您先前的設定寫入 $XDG_STATE_HOME/aibooster/system-proxy-restore.json，並在下次啟動時重播該檔案以還原設定。
• 程式處理了 SIGINT、SIGTERM 和 SIGHUP 信號，因此正常關閉——如關閉視窗、登出、重新開機——會立即還原 proxy 設定。
• 任何程式都無法處理 SIGKILL 信號。在這種情況下，proxy 會保持重新導向狀態，直到您再次啟動應用程式，屆時它會被還原。

如果您需要手動復原而不是等待：

# GNOME, Cinnamon, MATE
gsettings set org.gnome.system.proxy mode none
 
# KDE Plasma
kwriteconfig6 --file kioslaverc --group 'Proxy Settings' --key ProxyType 0

新增 profile

貼上單一節點連結或 subscription URL。所有平台上可辨識的協定（scheme）都相同：vless://、vmess://、trojan://、ss://、hysteria2://（也作 hy2://、hy://）、tuic://、wg://、ssh:// 和 warp://。一個 http:// 或 https:// 的 URL 會被視為一個 subscription——它會被擷取並可刷新，而不是作為一個固定的節點儲存。

介面顯示內容

• Subscriptions 和 profiles，並可在其間切換
• 包含延遲測量值的伺服器列表，以及引擎自有的 selector 和 url-test 群組
• 從引擎的本機 API 讀取的即時流量和連線數
• 視窗中顯示的引擎日誌串流
• 路由、DNS、傳入、TLS 和 WARP 設定

疑難排解

應用程式啟動了，但引擎沒有。 視窗中會顯示此訊息。請檢查安裝包是否已完整安裝——從原始碼建置的版本依設計本來就沒有捆綁引擎。

崩潰後整個桌面失去網路連線。 再次啟動 AI Booster；它會在啟動時重播儲存的 proxy 設定。如果您想直接修復，請使用上面提到的兩個指令。

已連線，但無法載入任何內容。 這通常是節點問題，而不是用戶端問題。請先嘗試同一個 profile 中的另一個節點；其餘的排查步驟請參閱完整的診斷順序。

解除安裝

使用您發行版的套件管理器移除安裝包。在執行此操作之前，請先在應用程式內中斷連線，以還原桌面 proxy 設定——一旦安裝包被移除，已儲存的設定檔將不會再為您自動重播。