# 常見問題 Canonical: https://galaxnet.dev/zh-hant/nova/faq/ Language: zh-Hant ## 與官方 Tailscale 客戶端有何不同？ NovaScale 使用的是改造版 libtailscale，並在應用內直接建立 Tailnet 通信，因此在此場景下無需申請 iOS 系統 VPN 權限。 參考資料： ## 為何在將 NovaScale 放到背景後，某些情況 SSH 會話仍可恢復？ NovaScale 某些場景依賴 userspace 網路行為與記憶體中的會話狀態。若 iOS 因記憶體壓力終止進程，當前會話將無法恢復。 ## 升級至 NovaScale 1.6.0 後，為什麼會提示 SSH 主機金鑰不相符？ NovaScale 1.6.0 重構了 SSH 通訊基礎。NovaScale 1.5.0 儲存的部分受信任主機金鑰採用較舊的表示格式，因此升級後首次重新連線時，1.6.0 可能會將未變更的主機金鑰顯示為不相符。在 1.6.0 中首次信任的主機不受影響。 移除已儲存的主機金鑰前，請先確認連線的確實是預期主機，並與從伺服器本機或管理員處取得的指紋進行核對。然後前往 **更多 > 主機金鑰**，找到受影響的主機，向左滑動並選擇 **移除**。重新連線後，請核對新顯示的指紋，確認一致後再信任。通常只需移除受影響的項目，無需使用 **清除全部**。 ## 為何在開啟某些 VPN App 後 NovaScale 無法載入主機清單？ 部分 VPN App 會啟用 `FakeIP` 功能，對 DNS 查詢回傳保留 IP 空間中的位址。 NovaScale 的底層基於 Tailscale 內核組網，會直接綁定到用戶的非 VPN 介面（例如 5G 或 Wi‑Fi）並從該介面發起請求。 NovaScale 1.6.0 已針對這些 VPN App 常用的 FakeIP 位址範圍加入緩解措施。大多數使用者不再需要修改 VPN 設定。如果開啟 VPN 時 NovaScale 能正常載入主機，無需進行任何操作。 部分 VPN App 允許使用不同或自訂的 FakeIP 位址範圍。如果該範圍未被 NovaScale 識別，Tailscale 相關網域或自建 Headscale 驗證網域仍可能回傳 FakeIP，導致請求失敗。此時需在 VPN App 中將這些網域設定為回傳真實 IP。 以 Surge 為例，若使用官方 Tailnet 驗證端點，可在 **[General]** 中加入： ```text [General] always-real-ip = *.tailscale.com ``` 若使用自建 Headscale 控制伺服器，還需加入其驗證網域。其他 VPN App 中對應的設定可能稱為「真實 IP」、「FakeIP 過濾」或「排除 FakeIP」。修改後請重新連接 VPN，並重新啟動 NovaScale。 ## NovaScale、Codex CLI 與 Codex 桌面 App 之間會共享哪些 Codex 狀態？ 這些用戶端可以讀取主機上由 Codex 管理的同一份狀態。執行緒識別與名稱、對話記錄和已完成回合、最新模型與思考強度，以及 Goal 狀態會由 Codex 持久化，並可由其他用戶端還原。 即時狀態的邊界不同。正在執行的回合、待處理的核准、目前權限選擇、沙盒與核准原則可能僅屬於發起它們的 Codex 執行環境。NovaScale 無法總是從獨立的 CLI 或桌面 App 執行環境接管這些工作。在 NovaScale 中選擇的權限僅適用於從 NovaScale 發起的回合，不會改變其他用戶端的目前工作階段。 NovaScale Pro 的 iCloud 同步會在你的 Apple 裝置之間同步 NovaScale 的 Codex 主機項目。Codex 對話記錄、原始碼或工作區資料不會上傳到 iCloud；這些資料仍保留在 Codex 主機上。 ## 為什麼 Codex 的模型與思考強度通常能在不同用戶端之間保持一致？ Codex 會將最新模型與思考強度持久化為執行緒中繼資料。當 NovaScale、Codex CLI 或其他 app-server 用戶端在沒有明確覆寫設定的情況下恢復執行緒時，Codex 會還原這些值。用戶端也可以主動選擇其他值，此時明確設定優先。 NovaScale 不會維護固定的模型清單，而是從該主機上的 Codex app-server 取得可用模型與思考強度。因此，選項可能隨 Codex 版本、帳戶、伺服器分階段發布與主機設定而變化。如果更新 Codex CLI 後仍未出現新模型，請使用 NovaScale 的主機維護診斷，並依提示重新啟動或更新 NovaScale Codex 主機服務。 參考資料： ## 為什麼 Codex 0.147 提示該執行緒已有作用中的寫入端？ Codex 會將每個執行緒儲存在持久化的 rollout 檔案中。Codex 0.147 對該檔案套用單一寫入端保護：如果 Codex CLI、Codex 桌面 App 或其他 app-server 執行環境仍擁有該執行緒，NovaScale 可以讀取其已持久化的記錄，但傳送新回合可能會被阻止。即使另一個用戶端的最新回合已完成，只要該工作階段仍開啟著執行緒，也可能出現此情況。 NovaScale 不會強制接管，也不會直接修改 rollout 檔案。出現衝突時，NovaScale 提供以下選擇： - 結束或關閉目前擁有該執行緒的工作階段，然後在 NovaScale 中選擇**再試一次**。 - 等候擁有權到期後重試。對 Codex 0.147 的測試中，未繼續寫入的擁有權會在約 30 分鐘後釋放；如果原用戶端又發起新回合，則會重新開始一輪等候週期。 - 選擇**新工作階段**，在同一工作區中獨立開始。 - 選擇**分支執行緒**，保留現有記錄並在獨立執行緒中繼續。 app-server 協定仍處於實驗階段，因此後續 Codex 版本可能調整具體的擁有權逾時時間。 參考資料：